1. EVOlving L ogic P rograms 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 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 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 Here we present a simple and powerful approach for LPs Updates Why another approach? Why another approach?

3. Model updates of [MT] Language for updating KBs, with rules: Language for updating KBs, with rules: in(A 0 ) | out(A 0 ) ← in(A 1 ),..., out(A n ) 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 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: 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 DLP [ALPPP] give meaning to sequences of LPs Intuitively a sequence of LPs is the result of updating P 1 with the rules in P 2, … Intuitively a sequence of LPs is the result of updating P 1 with the rules in P 2, … Inertia is applied to rules rather than to literals Inertia is applied to rules rather than to literals Older rules conflicting with newer applicable rules are rejected 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 By then we knew how to give meaning to sequences of LPs But how to come up with those sequences? But how to come up with those sequences? Changes maybe additions or retractions Changes maybe additions or retractions Updates maybe conditional on a present state Updates maybe conditional on a present state Some rules may represent (persistent) laws Some rules may represent (persistent) laws LUPS [APPP], EPI [EFST], and KABUL [Leite] are (command) language defined for these purposes 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 Sequences of commands build sequences of LPs There are several types of commands: assert, assert event, retract, always, … 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: EPI extends LUPS to allow for: commands whose execution depends on other commands commands whose execution depends on other commands external events to condition the KB evolution external events to condition the KB evolution KABUL extends LUPS and EPI with nesting 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? 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 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 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 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 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) The argument of assert is an EVOLP rule (i.e. arbitrary nesting of assert is allowed) Examples: 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 EVOLP programs are sets of EVOLP rules

11. Meaning of Self-evolving LPs Determined by sequences of sets of literals Determined by sequences of sets of literals Each sequence represents a possible evolution Each sequence represents a possible evolution The n th set in a sequence represents what is true/false after n steps in that evolution The n th 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 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 n th set, then (n+1) th sets must consider the addition of Rule If assert(Rule) belongs to the n th 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 ←) At the beginning a is true, and so is assert(b ←) Therefore, rule b ← is asserted Therefore, rule b ← is asserted At 2 nd step, b becomes true, and so does assert(c ←) At 2 nd step, b becomes true, and so does assert(c ←) Therefore, rule c ← is asserted Therefore, rule c ← is asserted At 3 rd step, c becomes true. At 3 rd 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 of sets of atoms from L as An evolution interpretation of P over L is a sequence of sets of atoms from L as The evolution trace of is : The evolution trace of is : P 1 = P and P i = {R | assert(R)  I i-1 } (2 ≤ i ≤ n) Evolution traces contains the programs imposed by interpretations Evolution traces contains the programs imposed by interpretations We have now to check whether each n th set complies with the programs up to n-1 We have now to check whether each n th set complies with the programs up to n-1

14. Evolution Stable Models, with trace, is an evolution stable model of P, iff, with trace, is an evolution stable model of P, iff  1 ≤ i ≤ n, I i is a SM of the DLP: P 1  …  P i I is a stable model of P 1  …  P n iff I is a stable model of P 1  …  P n iff I = least( (  P i – Rej(I))  Def(I) ) where: Def(I) = {not A |  A ← Body)   P i } Def(I) = {not A |  A ← Body)   P i } Rej(I) = {L 0 ← Bd in Pi |  not L 0 ← Bd’)  Pj, Rej(I) = {L 0 ← Bd in Pi |  not L 0 ← Bd’)  Pj, i < j ≤ n, and Bd’  I} i < j ≤ n, and Bd’  I}

15. Simple example is an evolution SM of P: is an evolution SM of P: a ←assert(not a ←) ← b assert(b ← a) ← not cc ← assert(not a ←) The trace is The trace is a, assert(b ← a) a, b, c, assert(not a ←)

16. 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. 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 Paths in the graph below are evolution SMs ast(b) ast(c) b,c,ast(b) ast(c) b,c,ast(a) ast(c) a,b,c,ast(b) ast(c) a,b,c,ast(a) ast(c)

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

18. Evolution Stable Models An event sequence is a sequence of sets of EVOLP rules. An event sequence is a sequence of sets of EVOLP rules., with trace, is an evolution SM of P given, iff, with trace, is an evolution SM of P given, iff  1 ≤ i ≤ n, I i is a SM of the DLP: P 1  …  P i  E i ) Note that, this way, events from the outside do not persist by inertia 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 program says that: whenever c, assert a ← b The events were: 1 st c was perceived; 2 nd an order to assert b; 3 rd an order to assert not a The events were: 1 st c was perceived; 2 nd an order to assert b; 3 rd an order to assert not a P: assert(a ← b) ← c Events: Events: 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: The behavior of all LUPS commands can be constructed in EVOLP. Eg: always (not a ← b, not c) when d, not e 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 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: All LUPS and EPI features are EVOLP features: Rule updates; Persistent updates; simultaneous updates; events; commands dependent on other commands; … Rule updates; Persistent updates; simultaneous updates; events; commands dependent on other commands; … Many extra features (some of them in KABUL) can be programmed: Many extra features (some of them in KABUL) can be programmed: Commands that span over time Commands that span over time Events with incomplete knowledge Events with incomplete knowledge Updates of persistent laws Updates of persistent laws Assignments Assignments …

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

23. … and also EVOLP is a concise, simple and quite powerful language to reason about KB evolution 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 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 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 EVOLP: a firm formal basis in which to express, implement, and reason about dynamic KB Opens up a number of research topics Opens up a number of research topics Much remains do be done… Much remains do be done…