1. Updates plus Preferences Luís Moniz Pereira José Júlio Alferes Centro de Inteligência Artificial Universidade Nova de Lisboa Portugal JELIA’00, Málaga, España

2. Motivation zTo combine into one uniform framework: yresults on LP updates yresults on LP preferences zJoin these complementary results, in order to: yenforce preferences on the result of updates yallow preferences to be updated

3. Outline zMotivation zConcepts yUpdates versus Revisions yPreferences versus Updates zFormalizations yUpdating yPrefering yCombining both zExample zConclusions and Ongoing Work

4. Concepts : Updates versus Revisions

5. LP and World Knowledge zNow-a-days LP allows the non-monotonic addition of new knowledge, as rules or facts, about either a static world or a dynamic world. zTill recent work on updates, LP semantics did not envisage the evolution of knowledge where new rules contradict and override old ones. Instead, yLPs represented either revisable knowledge about a static world yor monotonically increasing knowledge about a dynamic world.

6. Knowledge Evolution zIn real settings, knowledge evolves by: ynon-monotonically adding information – revising ychanging to accompany the changes in the world itself – updating Example: I know now to have a flight booked for London, either to Heathrow or to Gatwick. Next: y if I learn it is not for Heathrow (revision), I conclude it is for Gatwick; y if I learn flights for Heathrow were canceled (update), then either I have a flight for Gatwick, or no flight at all.

7. Concepts : Preferences versus Updates

8. Prefering zPreferences are employed with incomplete knowledge, as modeled by default rules, so that several models are possible. zPreferences act by choosing just some of the possible models. zThey do this via a partial order among rules, so that rules will always fire if they are only defeated by less prefered ones, because these are prevented from firing.

9. Updating zUpdates model dynamically evolving worlds. Besides facts, these can contain rules: eg. legal or physical Laws, or Actions. zUpdates differ from revisions, which are about an incomplete static world model. zKnowledge, whether complete or incomplete, can be updated to reflect world change. zNew knowledge may contradict and override older one. New models may also be created by removing such contradictions.

10. Preferences and Updates Combined zDespite their differences preferences and updates display similarities. zBoth can be seen as wiping out rules: yin preferences the less prefered rules, so as to remove models which are undesired yin updates the older rules, including to obtain models in otherwise inconsistent theories zThis view helps putting them together into a single uniform framework. zIn this framework, preferences can be updated.

11. Formalization : Updating

12. Dynamic LPs zDLP is a framework for LP updates zIt provides meaning to sequences of LPs: P 1  P 2  …  P n zIntuitively, the meaning of such a sequence results from updating P 1 with the rules from P 2, and then updating the result with … the rules from P n  Inertia is applied to rules rather than to literals

13. Updates of LPs by LPs zTo represent negative information, DLP allows for not in rule heads. P 2 :not tv_on  p_failure. p_failure. P 1 :sleep  not tv_on. watch  tv_on. tv_on. M 1 = {tv_on, watch} zGoals are evaluated wrt the last state. M 2 = {sleep, p_failure} The 1st rule of P1 is inherited P 3 :not p_failure. M 3 = {tv_on, watch}

14. Generalized LPs z For deletions, default negation is needed in heads. z The semantics is given by a generalization of the stable models semantics. Definitions: where literals not A are considered as new atoms  Default(P,M) = {not A :  r  P, head(r) = A   M |= body(r) }  M is a stable model of P iff: M = least(P U Default(P,M))

15. Rejection of Rules z Older rules conflicting with more recent ones should be rejected, i.e. their inertia is stopped. z Given a model M and a state s, reject all rules in previous states for which a later rule exists having complementary head and true body:  Definition: Reject(s,M) = {r  Pi :  r’  Pj, head(r)=not head(r’)   i < j  s   M |= body(r’) }

16. Semantics of Updates z The models of a DLP at a state s are obtained by rejecting older rules, if in conflict, and by adding the default literals:  Definition: where P is the union of all program in the DLP M is a stable model of a DLP at state s iff: M = least( [P – Reject(s,M)] U Default(P,M) ) z A translation to a single GLP has been defined z An implementation exists

17. DLP example P 1 :sleep  not tv_on. watch  tv_on. tv_on. P 2 :not tv_on  p_failure. p_failure. P 3 :not p_failure. M 2 = {pf,s} is a SM at state 2 Reject(2,M 2 ) = {tv_on} Default(P 1 U P 2,M 2 ) = {not tv, not w} least(P 1 U P 2 - {tv_on} U {not tv, not w}) = {pf,s,not tv, not w} M 3 = {w,tv} is a SM at state 3 Reject(3,M 3 ) = {p_failure} Default(P,M 3 ) = {not s, not pf} least= {tv,w}

18. Formalization : Prefering

19. Prioritized generalized LPs zA generalized program P plus a strict partial order < over the rules of P. zr1 < r2 means “r1 is prefered to r2” zGiven the priorities among the rules, what stable models to prefer? yBrewka and Eiter defined prefered answer-sets yThe definition is based on two general principles xOne capturing minimality xAnother capturing relevance

20. Principles for preferences zPrinciple I (minimality) yIf M1 is a SM generated by rules R U {r1}, M2 by rules R U {r2}, and r1 < r2, then M2 cannot be prefered zPrinciple II (relevance) yAdding a rule not applicable (i.e. with false body) in a prefered stable model M, cannot render M unprefered

21. Preference by rule removal zSince r1 < r2, and r1’s head defeats r2’s body (i.e. r1 head is a, and r2 body contains not a), r2 should be removed. zThe only stable model of P - {r2} is SM1 r1: a  not b. r2: b  not a. r1 < r2 SM1 = {a} (generated by {r1}) SM2 = {b} (generated by {r2}) SM1 is prefered (by principle I) 4Remove less prefered rules, whose body is defeated by the head of a more prefered one

22. Preference by rule removal zBut, with the reasoning before, r3 is removed (defeated by the head of r1). zWhy shouldn’t r3 be removed? yr1’s body is defeated in whichever model yIn M2, b is true because of r4 and not of r1 yr1 is unsupported (true head and false body) in M2 r1: b  not c. r2: c  not d. r3: a  not b. r4: b  not a. r1 < r2 < r3 < r4 SM1 = {a,c} (generated by {r2,r3}) SM2 = {b,c} (generated by {r2,r4}) SM2 shouldn’t be prefered (by principle I)

23. Preference by rule removal zUnsupported rules cannot be used to defeat other rules. r1: b  not c. r2: c  not d. r3: a  not b. r4: b  not a. r1 < r2 < r3 < r4 SM1 = {a,c} (generated by {r2,r3}) SM2 = {b,c} (generated by {r2,r4}) SM2 shouldn’t be prefered (by principle I) zLeaving unsupported rules, doesn’t influence the least model (their body is false) 4Given a SM, remove unsupported rules

24. Preference by rule removal 4Remove less prefered rules, whose head defeats the true body of a more prefered one r1: a  not b. r2: b  not c. r1 < r2 SM = {b} (generated by {r2}) SM is not prefered (by principle II). Consider, eg, the addition of c  a.

25. Prefered Stable Models zHere we only consider rules without atoms in bodies. See the paper for the general case.  Def. (Unsupported and unprefered rules):  Unsup(P,M) = {r  P : M |= head(r)  M |  body(r)}  Unpref(P,M) is the least set including Unsup(P,M), and every rule r such that:  r’  P – Unpref(P,M): r’ < r  [ not head(r’)  body(r)   (not head(r)  body(r’)  M |= body(r)) ]

26. Preferred SMs (cont)  Definition: M is a prefered SM of (P,<) iff: M = least( [P – Unpref(P,M)] U Default(P,M) )  Proposition: If M is prefered SM of (P,<) then M is SM of P.  Theorem: Prefered stable models and BE’s prefered answer- set coincide on normal programs

27. Formalization : Combination of preferences and updates

28. Updating LPs with preferences zWith preferences and updates viewed as rejection of rules, it’s not difficult to combine both. zWe are given: ya DLP P 1  P 2  …  P n ya strict partial order over rules of all the P i s zTo allow updates in the preference relation, the order cannot be fixed  It must be described by a language for updates  another DLP for defining <

29. Dynamic Prioritized LPs zSequences of pairs: (P 1, R 1 )  (P 2, R 2 )  …  (P n, R n ) yThe alphabet of the P i s doesn’t include < yThe alphabet of the R i s includes < yThe set of constants in the R i s include all rules in the P i s

30. Semantics of prioritized DLPs zSemantics is given by a fixpoint definition. zM is a SM at state s if it’s the least model of the program obtained by: yFirst removing all rules rejected by updates yOnly then removing all unprefered rules, taking the relation < in M zMoreover the relation < in M must be a strict partial order.

31. Example zYou like fast cars, and your budget doesn’t allow expensive ones. Not buying expensive cars as preference over buying fast ones. zMoreover, you know: P 1 : Facts plus r1: not buy(X)  avoid(X). r2: avoid(X)  not buy(X), expensive(X). r3: buy(X)  not avoid(X), fast(X). r4: avoid(Y)  buy(X), fast(X), X  Y. safe(a). fast(b). expensive(b). safe(b). fast(c). R 1 :r2 < r3. r3 < r4. zThe only prefered SM includes {buy(c),avoid(a),avoid(b)}

32. Example (cont) zYour significant other insists that you should buy a safe car: P 2 :r5: buy(X)  not avoid(X), safe(X). r6: avoid(Y)  buy(X), safe(X), X  Y. R 2 :r5 < r3. r5 < r4. r6 < r4. r2 < r5. r2 < r6. zThe only prefered SM at state 2 includes {buy(a),avoid(b),avoid(c)}

33. Example (cont) zCars a are out of stock: P 3 :r7: not buy(a). R 3 :{} zAt state 3, r5 of state 2 is rejected by the newer rule r7, and the only prefered SM now includes: {buy(c),avoid(a),avoid(b)}

34. Conclusions and ongoing work

35. Conclusions zWe have motivated the need for coupling updates and preferences zAnd met it with the LP paradigm, via a fixpoint semantics, that allows for updating of preferences too zThis approach is more general than other ones

36. Ongoing work zA transformational semantics of the framework into normal LPs, generalizing the one for updates alone zAutomatically ensuring the strictness of < after an update zApplications to e-commerce B2B contracts, legal reasoning, security policy, software composition, and rational agents