EVO lving L ogic P rograms

1. EVOlving Logic Programs J.J. Alferes, J.A. Leite, L.M. Pereira (UNL) A. Brogi (U.Pisa)

2. LP for KRR • LP has been widely used for representing static knowledge • Attempts have been made to define LP frameworks that deal with dynamics of knowledge – LPs Updates • Here we present a simple and powerful approach for LPs Updates • Why another approach?

3. Model updates of [MT] • Language for updating KBs, with rules: in(A0) | out(A0) ← in(A1), ..., out(An) • Given the set of interpretations of an initial KB, and a set of revision rules, the set of interpretations of the resulting KB is obtained • Problems: • The resulting KB is only indirectly characterized • No intuitive results when the intentional part of the KB changes. Doesn’t work well for rules updates

4. Updates of LPs by LPs • DLP [ALPPP] give meaning to sequences of LPs • Intuitively a sequence of LPs is the result of updating P1 with the rules in P2, … • Inertia is applied to rules rather than to literals • Older rules conflicting with newer applicable rules are rejected

5. What was still missing • By then we knew how to give 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 • LUPS [APPP], EPI [EFST], and KABUL [Leite] are (command) language defined for these purposes

6. Languages of Updates • 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

7. Problems with these languages • Too many commands • Far from the spirit of LP • Complex • Difficult to prove properties • Fixed set of commands • Each encodes a high-level behavior for additions • Are those the only interesting behaviors? E.g. • Make additions dependent upon conditions that span over states • Model changes of (persistent) update commands • One could further extend the language. But, where to stop?

8. How to proceed • Instead of extending with new commands • Minimally add constructs and concepts to LP, to cope with evolution and updating (start from scratch) • The result, EVOLP, provides a simpler, closer to traditional LP, and more general formulation of LP Updates

9. What do we (really) need • Programs must be allowed to evolve • Meaning of programs should be sequences of sets of literals, representing evolutions • Need a construct to assert new information • Do we need a construct to retract old 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

10. Self-evolving LPs - 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

11. 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

12. 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 ←)} >

13. 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

14. 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 • I is a stable model of P1 Å …Å Pn iff I = least( (ÈPi – Rej(I)) È Def(I) ) where: • Def(I) = {not A | Ø$(A ← Body) ÎÈPi} • Rej(I) = {L0 ← Bd in Pi | $(not L0 ← Bd’) Î Pj, i < j ≤ n, and Bd’ Í I}

15. a, b, c, assert(not a ←) assert(b ← a) Simple example • <{a, ast(b ← a)}, {a, b,c,ast(not a ←)}, {ast( 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)

16. 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

17. 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

18. Evolution Stable Models • 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 Å …Å (Pi È Ei) • Note that, this way, events from the outside do not persist by inertia

19. 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 ←)}> c, assert(a ← b) assert(b ←) b, a, assert(not a ←) b

20. 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))

21. 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 • …

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

23. … and also • EVOLP is a concise, simple and quite powerful language to reason about KB evolution • Powerful: it can do everything other update 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 • Opens up a number of research topics • Much remains do be done…