Rule Updates

1. Rule Updates • These languages and methodologies are basically concerned with facts that change • There is a set of fluents (fact) • There are static rules describing the domain, which are not subject to change • There are dynamic rules describing how the facts may change due to actions • What if the rules themselves, be it static or dynamic, are subject to change? • The rules of a given domain may change in time • Even the rules that describe the effects of actions may change (e.g. rules describing the effects of action in physical devices that degrade with time) • What we have seen up to know does not help!

2. Languages for rule updates • Languages dealing with highly dynamic environments where, besides fact, also static and dynamic rules of an agent may change, need: • Means of integrating knowledge updates from external sources (be it from user changes in the rules describing agent behavior, or simply from environment events) • Means for describing rules about the transition between states • Means for describing self-updates, and self-evolution of a program, and combining self-updates with external ones • We will study this in the setting of Logic Programming • First define what it means to update a (running) program by another (externally given) program • Then extend the language of Logic Programs to describe transitions between states (i.e. some sort of dynamic rules) • Make sure that this deals with both self-updates (coming from the dynamic rules) and updates that come directly from external sources

3. Updates of LPs by LPs • Dynamic Logic Programming (DLP) [ALPPP98] was introduced to address the first of these concerns • It gives meaning to sequences of LPs • Intuitively a sequence of LPs is the result of updating P1 with the rules in P2, … • But different programs may also come from different hierarchical instances, different viewpoint (with preferences), etc. • Inertia is applied to rules rather than to literals • Older rules conflicting with newer applicable rules are rejected

4. Updating Models isn’t enough • When updating LPs, doing it model by model is not desired. It loses the directional information of the LP arrow. P: sleep  not tv_on. watch  tv_on. tv_on. M = {tv,w} Mu = {pf,w} {pf,s} U: not tv_on  p_failure. p_failure. {tv,w} Mu2 = {w} U2: not p_failure. • Inertia should be applied to rule instances rather than to their previous consequences.

5. Logic Programs Updates Example • One should not have to worry about how to incorporate new knowledge; the semantics should take care of it. Another example: Open-Day(X) ← Week-end(X) . Week-end(23) . Week-end(24). Sunday(24). Initial knowledge: The restaurant is open in the week-end New knowledge: On Sunday the restaurant is closed not Open-Day(X) ← Sunday(X) . • Instead of rewriting the program we simply update it with the new rules. The semantics should consider the last update, plus all rule instances of the previous that do not conflict.

6. Generalized LPs • Programs with default negation in the head are meant to encode that something should no longer be true. • The generalization of the semantics is not difficult • A generalized logic program P is a set of propositional Horn clauses L  L1 ,…, Ln where L and Liare atoms from LK , i.e. of the form A or ´not A´. • Program P is normal if no head of the clause in P has form not A.

7. Generalized LP semantics • A set M is an interpretation of LK if for every atom A in K exactly one of A and not A is in M. • Definition: An interpretation M of LK is a stable model of a generalized logic program P if M is the least model of the Horn theory P {not A: A  M}.

8. Generalized LPs example Example: K = { a,b,c,d,e} P : a  not b c  b e  not d not d  a, not c d  not e this program has exactly one stable model: M = Least(Pnot {b, c, d}) = {a, e, not b, not c, not d} N = {not a, not e, b, c, d} is not a stable model since N  Least(P {not a, not e})

9. Dynamic Logic Programming • A Dynamic Logic Program P is a sequence of GLPs P1  P2  …  Pn • An interpretation M is a stable model of P iff: M = least([UiPi – Reject(M)] U Defaults(M)) • From the union of the programs remove the rules that are in conflict with newer ones (rejected rules) • Then, if some atom has no rules add (in Defaults) its negation • Compute the least, and check stability

10. Rejection and Defaults • By default assume the negation of atoms that have no rule for it with true body: Default(M) = {not A |  r: head(r)=A and M |= body(r)} • Reject all rules with head A that belong to a former program, if there is a later rule with complementary head and a body true in M: Reject(M) = {r  Pi | r’  Pj, i ≤ j and head(r) = not head(r’) and M |= body(r’)}

11. Example P1: sleep  not tv_on. watch  tv_on. tv_on. P2: not tv_on  p_failure. p_failure. • {pf, sl, not tv, not wt} is the only SM of P1P2 • Rej = {tv } • Def = {notwt} • Least( P – {tv } U {notwt} = M • {tv, wt, not sl, not pf} is the only SM of P1P2P3 • Rej = {pf } • Def = {notsl} P3: not p_failure.

12. Another example P1 : not fly(X)  animal(X) P4 : animal(X)  bird(X) P2 : fly(X)  bird(X) bird(X)  penguin(X) P3 : not fly(X)  penguin(X) animal(pluto)  bird(duffy)  penguin(tweety) ProgramP1P2 P3P4 has a unique stable model in which fly(duffy) is true and both fly(pluto) and fly(tweety) are false.

13. Some properties • If M is a stable model of the union P  U of programs P and U , then it is a stable model of the update program P  U. • Thus, the semantics of the program P U is always weaker than or equal to the semantics of P  U. • If either P or U is empty, or if both P and U are normal programs, then the semantics of P  U and P U coincide. • DLP extends the semantics of stable models

14. What is still missing • DLP gives meaning to sequences of LPs • But how to come up with those sequences? • Changes maybe additions or retractions • Updates maybe conditional on a present state • Some rules may represent (persistent) laws • Since LP can be used to describe knowledge states and also sequences of updating states, it’s only fit that LP is used too to describe transitions, and thus come up with such sequences

15. LP Update Languages • Define languages that extend LP with features that allow to define dynamic (state transition) rules • Put, on top of it, a language with sets of meaningful commands that generate DLPs (LUPS, EPI, KABUL) or • Extend the basic LP language minimally in order to allow for this generation of DLPs (EVOLP)

16. What do we need do make LPs evolve? • Programs must be allowed to evolve • Meaning of programs should be sequences of sets of literals, representing evolutions • Needed a construct to assert new information • nots in the heads to allow newer to supervene older rules • Program evolution may me influenced by the outside • Allow external events • … written in the language of programs

17. EVOLP Syntax • EVOLP rules are Generalized LP rules (possibly with nots in heads) plus special predicate assert/1 • The argument of assert is an EVOLP rule (i.e. arbitrary nesting of assert is allowed) • Examples: assert( a ← not b) ← d, not e not a ← not assert( assert(a ← b)← not b), c • EVOLP programs are sets of EVOLP rules

18. Meaning of Self-evolving LPs • Determined by sequences of sets of literals • Each sequence represents a possible evolution • The nth set in a sequence represents what is true/false after n steps in that evolution • The first set in sequences is a SM of the LP, where assert/1 literals are viewed as normal ones • If assert(Rule) belongs to the nth set, then (n+1)th sets must consider the addition of Rule

19. Intuitive example a ← assert(b ←) assert(c ←) ← b • At the beginning a is true, and so is assert(b ←) • Therefore, rule b ← is asserted • At 2nd step, b becomes true, and so does assert(c ←) • Therefore, rule c ← is asserted • At 3rd step, c becomes true. < {a, assert(b ←)}, {a, b, assert(b ←), assert(c ←)}, {a, b, c, assert(b ←), assert(c ←)} >

20. Self-evolution definitions • An evolution interpretation of P over L is a sequence <I1,…,In> of sets of atoms from Las • The evolution trace of <I1,…,In> is <P1,…,Pn>: P1 = P and Pi = {R | assert(R) Î Ii-1}(2 ≤ i ≤ n) • Evolution traces contains the programs imposed by interpretations • We have now to check whether each nth set complies with the programs up to n-1

21. Evolution Stable Models • <I1,…,In>, with trace <P1,…,Pn>, is an evolution stable model of P, iff " 1 ≤ i ≤ n, Ii is a SM of the DLP: P1 Å …Å Pi • Recall that I is a stable model of P1 Å …Å Pn iff I = least( (ÈPi – Rej(I)) È Def(I) ) where: • Def(I) = {not A | Ø$(A ← Body) ÎÈPi, Body Í I} • Rej(I) = {L0 ← Bd in Pi | $(not L0 ← Bd’) Î Pj, i ≤ j ≤ n, and Bd’ Í I}

22. a, b, c, assert(not a ←) assert(b ← a) Simple example • <{a, assert(b ← a)}, {a, b,c,assert(not a ←)}, {assert( b ← a)}> is an evolution SM of P: a ← assert(not a ←) ← b assert(b ← a) ← not c c ← assert(not a ←) • The trace is <P,{b ← a},{not a ←}> a, assert(b ← a)

23. b,c,ast(a) ast(c) a,b,c,ast(a) ast(c) ast(b) ast(c) b,c,ast(b) ast(c) a,b,c,ast(b) ast(c) Example with various evolutions • No matter what, assert c; if a is not going to be asserted, then assert b; if c is true, and b is not going to be asserted, then assert a. assert(b) ← not assert(a). assert(c) ← assert(a) ← not assert(b), c • Paths in the graph below are evolution SMs

24. Event-aware programs • Self-evolving programs are autistic! • Events may come from the outside: • Observations of facts or rules • Assertion order • Both can be written in EVOLP language • Influence from outside should not persist by inertia

25. Event-aware programs • Events may come from the outside: • Observations of facts or rules • Assertion order • Both can be written in EVOLP language • An event sequence is a sequence of sets of EVOLP rules. • <I1,…,In>, with trace <P1,…,Pn>, is an evolution SM of Pgiven<E1,…,Ek>, iff " 1 ≤ i ≤ n, Ii is a SM of the DLP: P1 Å P2 Å …Å (Pi È Ei)

26. Simple example • The program says that: whenever c, assert a ← b • The events were: 1stc was perceived; 2nd an order to assert b; 3rd an order to assert not a P: assert(a ← b) ← c Events: <{c ← }, {assert(b ←)}, {assert(not a ←)}> assert(not a ←) c ← assert(b ←) c ← assert(a ← b) ← c assert(b ←) a ← b b assert(not a ←) not a← c, assert(a ← b) assert(b ←) b, a, assert(not a ←) b

27. Yale shooting with EVOLP • There is a turkey, initially alive: alive(turkey) • Whenever you shoot with a loaded gun, the turkey at which you shoots dies, and the gun becomes unloaded assert(not alive(turkey)) ← loaded, shoot. assert(not loaded) ← shoot. • Loading a gun results in a loaded gun assert(loaded) ← load. • Events of shoot, load, wait, etc make the program evolve • After some time, the shooter becomes older, has sight problems, and does not longer hit the turkey if without glasses. Add event: assert( not assert(not alive(turkey)) ← not glasses)

28. LUPS, EPI and KABUL languages • Sequences of commands build sequences of LPs • There are several types of commands: assert, assert event, retract, always, … always (not a ← b, not c) when d, not e • EPI extends LUPS to allow for: • commands whose execution depends on other commands • external events to condition the KB evolution • KABUL extends LUPS and EPI with nesting

29. LUPS Syntax • Statements (commands) are of the form: assert [event] RULE when COND • asserts RULE if COND is true at that moment. The RULE is non-inertial if with keyword event. retract [event] RULE when COND • the same for rule retraction always [event] RULE when COND • From then onwards, whenever COND assert RULE (as na event if with the keyword cancel RULE when COND • Cancel an always command

30. LUPS as EVOLP • The behavior of all LUPS commands can be constructed in EVOLP. Eg: • always (not a ← b, not c) when d, not e coded as event: assert( assert(not a ← b, not c) ← d, not e ) • always event (a ← b) when c coded as events: assert( assert(a ← b, ev(a ← b)) ← c ) assert( assert(ev(a ← b)) ← c ) plus: assert( not ev(R) ) ← ev(R), not assert(ev(R))

31. EVOLP features • All LUPS and EPI features are EVOLP features: • Rule updates; Persistent updates; simultaneous updates; events; commands dependent on other commands; … • Many extra features (some of them in KABUL) can be programmed: • Commands that span over time • Events with incomplete knowledge • Updates of persistent laws • Assignments • …

32. More features • EVOLP extends the syntax and semantics of logic programs • If no events are given, and no asserts are used, the semantics coincides with the stable models • A variant of EVOLP (and DLP) have been defined also extending WFS • An implementation of the latter is available • EVOLP was show to properly embed action languages A, B, and C.

33. EVOLP possible applications • Legal reasoning • Evolving systems, with external control • Reasoning about actions • Active Data (and Knowledge) Bases • Static program analysis of agents’ behavior • …

34. … and also • EVOLP is a concise, simple and quite powerful language to reason about KB evolution • Powerful: it can do everything other update and action languages can, and much more • Simple and concise: much better to use for proving properties of KB evolution • EVOLP: a firm formal basis in which to express, implement, and reason about dynamic KB • Sometimes it may be regarded as too low level. • Macros with most used constructs can help, e.g. as in the translation of LUPS’ always event command