1. Languages of Updates João Alexandre Leite New University of Lisbon http://centria.di.fct.unl.pt/~jleite/ Dagstuhl, 25 November, 2002Dagstuhl Seminar 02481 Co-authors: José Alferes, Antonio Brogi, Luís Moniz Pereira, Halina Przymusinska and Teodor Przymusinski.

2. 25-11-2002Dagstuhl Seminar 024812 Outline ► Logic Program Updates  Dynamic Logic Programming  Other Semantics ► Languages of Updates  LUPS  EPI and KABUL ► Evolving Logic Programs: EVOLP ► Discussion

3. 25-11-2002Dagstuhl Seminar 024813 Motivation for LP&NMR ► The notion of agency has claimed a major role in modern AI research ► LP and Non-monotonic Reasoning are appropriate for rational agents:  Utmost efficiency is not always crucial  Clear specification and correctness are crucial  LP provides a general, encompassing, rigorous declarative and procedural framework for rational functionalities

4. 25-11-2002Dagstuhl Seminar 024814 Generalized Logic Programs ► To represent negative info in LP updates, we need LPs allowing not in heads ► Programs are sets of generalized LP rules: A  B 1,…, B k, not C 1,…,not C m not A  B 1,…, B k, not C 1,…,not C m ► The semantics is a generalization of SMs

5. 25-11-2002Dagstuhl Seminar 024815 Dynamic Logic Programming ► DLP was introduced to express LP’s linear evolution in dynamic environments, via updates ► DLP gives semantics to sequences of GLPs ► Each program represents a distinct state of knowledge, where states may specify:  different time points, different hierarchical instances, different viewpoints, etc. ► Different states may have mutually contradictory or overlapping information, and DLP determines the semantics for each state sequence

6. 25-11-2002Dagstuhl Seminar 024816 DLP ► A Dynamic Logic Program, P, is a sequence of generalized logic programs P 1  P 2  …  P n ► An interpretation M s is a stable model of P at state 1  s  n iff M s = least( [ P s – Reject(M s )]  Def (M s ) )

7. 25-11-2002Dagstuhl Seminar 024817 DLP - semantics where: Reject(M s ) = {r  P i |  r’  P j, i  j  s, head(r)=not head(r’)  M s  body(r’)} M s = least( [ P s – Reject(M s )]  Def (M s ) ) Def(M s ) = {not A |  r  P j, j  s, head(r)=A  M s  body(r)}

8. 25-11-2002Dagstuhl Seminar 024818 Other Semantics for Updates ► P-Justified Updates [Leite and Pereira 97] ► Dynamic Stable Models [Alferes, Leite, Pereira, Przymusinska and Przymusinski 98] ► Update Answer-sets [Eiter, Fink, Sabbatini and Tompits 01] ► U-Models [Leite 02] Each semantics is obtained by re-defining the set of rejected rules, and the set of defaults.

9. 25-11-2002Dagstuhl Seminar 024819 A language for updates ► Now we know how to give meaning to sequences of updating LPs ► How do we come up with such LPs?  Changes may be additions or retractions of rules  Some rules may represent (persistent) laws  Updates rules may be conditional on present state ► How, from these rule requirements, do we build a sequence of LPs?

10. 25-11-2002Dagstuhl Seminar 0248110 Two Options... ► Define a set of commands that is manageable and easy to write specifications with: LUPS  EPI  KABUL ► Identify the minimal set of commands needed, and then add (high level) macros to allow for easy specifications: EVOLP

11. 25-11-2002Dagstuhl Seminar 0248111 LUPS ► LUPS is a language to declaratively specify how knowledge evolves ► LPs specify states, DLPs specify evolution of states ► LUPS specify rules for state transition ► LUPS makes both state and state transitions declarative

12. 25-11-2002Dagstuhl Seminar 0248112 Knowledge state updating ► Consecutive knowledge states are obtained as: KS n = KS 0 [U 1 ][U 2 ]...[U n ], where U n represents consecutive sets of updates. We denote this by: KS n =U 0  U 1 ...  U n ► Given the current state KS, its successor state KS[U] is produced as a result of a non-empty set U of parallel updates. Each can be viewed as a (parallel) action. ► Update actions do NOT modify the current or any of the previous states. They only affect future states, beginning with the successor state KS[U].

13. 25-11-2002Dagstuhl Seminar 0248113 LUPS Example The Statement: assert A  B 1,…, B k, notC 1,…,  notC m when D 1,…,D n,  notE 1,…, notE p The meaning of the assert statement is that if the precondition when D 1,…,D n,  notE 1,…, notE p when D 1,…,D n,  notE 1,…, notE p is true in the current knowledge state then the rule A   B 1,…, B k, notC 1,…,  notC m A   B 1,…, B k, notC 1,…,  notC m is true in the next state, and persists from then on by inertia, until defeated by some future update or retracted.

14. 25-11-2002Dagstuhl Seminar 0248114 LUPS - Syntax ► LUPS statements: they cause changes to the current state, leading to a successor state. [always] assert [event] Rule when [always] assert [event] Rule when [always] retract [event] Rule when [always] retract [event] Rule when cancel assert Rule when cancel assert Rule when cancel retract Rule when cancel retract Rule when ::= L 1, L 2, …, L n. ::= L 1, L 2, …, L n.

15. 25-11-2002Dagstuhl Seminar 0248115 LUPS semantics ► Sequences of commands are translated into Dynamic LPs. ► Given P 1  P 2  …  P i resulting from the translation of U 0  U 1 ...  U i and U i+1, obtain the new DLP P 1  P 2  …  P i  P i+1. ► The semantics is then given by the semantics of the translated DLP. ► This way LUPS programs specify sequences of LPs

16. 25-11-2002Dagstuhl Seminar 0248116 Translation example ► Let P 1  P 2  …  P i resulting from the translation of U 0  U 1 ...  U i ► Let U i+1 contain: assert Rule when Cond ► If P 1  P 2  …  P i |= Cond then Rule  P i ► The translation of all commands is rather extensive.

17. 25-11-2002Dagstuhl Seminar 0248117 EPI [Eiter et al.] ► Designed to allow the specification of KB update policies. ► Extends LUPS with:  external observations  Commands that depend on the concurrent execution of other commands

18. 25-11-2002Dagstuhl Seminar 0248118 KABUL – Knowledge And Behaviour Update Language ► Logic Programs in DLP describe knowledge at each state; ► LUPS (and EPI) statements describe how to update such knowledge, i.e. they describe the behaviour of the KB. ► How to update such behaviour? ► This is the purpose of: KABUL – Knowledge And Behaviour Update Language

19. 25-11-2002Dagstuhl Seminar 0248119 KABUL - Syntax ► KABUL statements: [always|once] assert (Rule|Stat)  [always|once] assert (Rule|Stat)  [always|once] retract (Rule|Stat)  [always|once] retract (Rule|Stat)  [always|once] assert [event] (Rule)  [always|once] assert [event] (Rule)  [always|once] retract [event] (Rule)  [always|once] retract [event] (Rule)  not assert|retract [event] (Rule|Stat)  not assert|retract [event] (Rule|Stat)  ► Where can include conditions on:  literals  concurrent execution of other commands;  existence of rule in the KB;  external observations

20. 25-11-2002Dagstuhl Seminar 0248120 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 behaviour  Are those the only interesting behaviors?  One could further extend the language. But, where to stop?

21. 25-11-2002Dagstuhl Seminar 0248121 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

22. 25-11-2002Dagstuhl Seminar 0248122 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

23. 25-11-2002Dagstuhl Seminar 0248123 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

24. 25-11-2002Dagstuhl Seminar 0248124 Meaning of Self-evolving LPs ► Determined by sequences of sets of literals ► 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 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

25. 25-11-2002Dagstuhl Seminar 0248125 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 2 nd step, b becomes true, and so does assert(c  ) ► Therefore, rule c  is asserted ► At 3 rd step, c becomes true. <{a, assert(b  )}, {a, b, assert(b  ), assert(c  )}, {a, b, c, assert(b  ), assert(c  )}>

26. 25-11-2002Dagstuhl Seminar 0248126 Self-evolution definitions ► An evolution interpretation of P over L is a sequence of sets of atoms from L assert ► The evolution trace of is : P 1 = P and P i = {R | assert(R) I i-1 } (2 ≤ i ≤ n) P 1 = P and P i = {R | assert(R)  I i-1 } (2 ≤ i ≤ n) ► 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

27. 25-11-2002Dagstuhl Seminar 0248127 Evolution Stable Models ►, 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

28. 25-11-2002Dagstuhl Seminar 0248128 Simple example ► Let P be: a  assert(not a  )  b assert(b  a)  not c c  assert(not a  ) ► ► is an evolution SM of P. ► The trace is ► The trace is a,  assert(b  a) a, b, c,  assert(not a  )

29. 25-11-2002Dagstuhl Seminar 0248129 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 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)

30. 25-11-2002Dagstuhl Seminar 0248130 Event-aware programs ► Self-evolving programs are autistic! ► Events may come from the outside:  Observations of facts or rules  Assertion orders ► Both can be written in EVOLP language ► Influence from outside should not persist by inertia

31. 25-11-2002Dagstuhl Seminar 0248131 Evolution Stable Models ► An event sequence is a sequence of sets of EVOLP rules. ►, 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 ) P 1  …  P i  E i ) ► Note that, this way, events from the outside do not persist by inertia

32. 25-11-2002Dagstuhl Seminar 0248132 Simple example ► Program P 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 P: assert(a  b)  c Events : Events : c,  assert(a  b)  assert(b  ) b, a,  assert(not a  ) b

33. 25-11-2002Dagstuhl Seminar 0248133 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))

34. 25-11-2002Dagstuhl Seminar 0248134 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  Updates of persistent laws  …

35. 25-11-2002Dagstuhl Seminar 0248135 EVOLP possible applications ► Dynamic Knowledge Representation ► Evolving Knowledge Bases  Legal Reasoning  User Profiling ► Evolving systems, with external control ► Reasoning about actions ► Active Data (and Knowledge) Bases

36. 25-11-2002Dagstuhl Seminar 0248136 … 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.  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…

37. 25-11-2002Dagstuhl Seminar 0248137 Conclusions ► Orthogonal in several respects:  Can be used in several LP based agent architectures;  Several semantics for sequences of LPs can be used;

38. 25-11-2002Dagstuhl Seminar 0248138 Open Issues ► Well Founded Semantics; ► Prune particular evolutions;

39. 25-11-2002Dagstuhl Seminar 0248139 Implementations ► There are public available implementations of several update frameworks (DLP, MDLP, LUPS and EVOLP) at: http://centria.di.fct.unl.pt/~jja/updates

40. 25-11-2002Dagstuhl Seminar 0248140 References (1) ► J. A. Leite, Evolving Knowledge Bases, vol 81 of Frontiers of Artificial Intelligence and Applications, IOS Press, pp xviii + 307, ISBN: 1 58603 278 X, 2003. vol 81 of Frontiers of Artificial Intelligence and Applicationsvol 81 of Frontiers of Artificial Intelligence and Applications ► J. J. Alferes, A. Brogi, J. A. Leite and L. M. Pereira, Evolving Logic Programs, In S. Flesca, S. Greco, N. Leone, G. Ianni (eds.), Proceedings of the 8th European Conference on Logics in Artificial Intelligence (JELIA'02), pages 50-61, Springer-Verlag, LNCS 2424, 2002. Evolving Logic ProgramsEvolving Logic Programs ► J. J. Alferes, L. M. Pereira, H. Przymusinska and T. C. Przymusinski, LUPS - a language for updating logic programs. Artificial Intelligence 138(1-2), 2002. LUPS - a language for updating logic programsLUPS - a language for updating logic programs ► J. A. Leite, A Modified Semantics for LUPS, In P. Brazdil and A. Jorge (eds.), Progress in Artificial Intelligence, 10th Portuguese International Conference on Artificial Intelligence (EPIA'01), pages 261-275, Springer- Verlag, LNAI 2258, December 2001. A Modified Semantics for LUPSA Modified Semantics for LUPS ► J. J. Alferes, J. A. Leite, L. M. Pereira, H. Przymusinska and T. C. Przymusinski, Dynamic Updates of Non-Monotonic Knowledge Bases, The Journal of Logic Programming 45(1-3): 43-70, September/October 2000. Dynamic Updates of Non-Monotonic Knowledge Bases Dynamic Updates of Non-Monotonic Knowledge Bases ► Thomas Eiter, Michael Fink, Giuliana Sabbatini, Hans Tompits: On Properties of Update Sequences Based on Causal Rejection. TPLP 2(6): 711-767 (2002)

41. 25-11-2002Dagstuhl Seminar 0248141 References (1) ► J. J. Alferes, J. A. Leite, L. M. Pereira, H. Przymusinska and T. C. Przymusinski, Dynamic Logic Programming, In A. Cohn, L. Schubert and S. Shapiro (eds.), Procs. of the Sixth International Conference on Principles of Knowledge Representation and Reasoning (KR'98), Trento, Italy, pages 98- 109, Morgan Kaufmann, June 1998. Dynamic Logic ProgrammingDynamic Logic Programming ► J. A. Leite, J. J. Alferes and L. M. Pereira, Multi-dimensional Dynamic Knowledge Representation, In T. Eiter, W. Faber and M. Truszczynski, Procs. of the Sixth International Conference on Logic Programming and Nonmonotonic Reasoning (LPNMR'01), pages 365-378, Springer-Verlag, LNAI 2173, 2001. Multi-dimensional Dynamic Knowledge RepresentationMulti-dimensional Dynamic Knowledge Representation ► J. A. Leite, J. J. Alferes and L. M. Pereira, On the Use of Multi-dimensional Dynamic Logic Programming to Represent Societal Agents' Viewpoints, In P. Brazdil and A. Jorge (eds.), Progress in Artificial Intelligence, 10th Portuguese International Conference on Artificial Intelligence (EPIA'01), pages 276-289, Springer-Verlag, LNAI 2258, December 2001. On the Use of Multi-dimensional Dynamic Logic Programming to Represent Societal Agents' ViewpointsOn the Use of Multi-dimensional Dynamic Logic Programming to Represent Societal Agents' Viewpoints ► J. A. Leite, J. J. Alferes and L. M. Pereira, H. Przymusinska and T. C. Przymusinski, A Language for Multi-dimensional Updates, In J. Dix, J. A. Leite and K. Satoh (eds.), Proceedings of the 3rd International Workshop on Computational Logic in Multi-Agent Systems, (CLIMA'02), in Electronic Notes in Theoretical Computer Science 70(5), 2002. A Language for Multi-dimensional UpdatesElectronic Notes in Theoretical Computer Science 70(5)A Language for Multi-dimensional UpdatesElectronic Notes in Theoretical Computer Science 70(5)