1 / 41

Languages of Updates

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

yana
Download Presentation

Languages of Updates

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • Logic Program Updates • Dynamic Logic Programming • Other Semantics • Languages of Updates • LUPS • EPI and KABUL • Evolving Logic Programs: EVOLP • Discussion Dagstuhl Seminar 02481

  3. 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 Dagstuhl Seminar 02481

  4. 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  B1,…, Bk, not C1,…,not Cm not A  B1,…, Bk, not C1,…,not Cm • The semantics is a generalization of SMs Dagstuhl Seminar 02481

  5. 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 Dagstuhl Seminar 02481

  6. DLP • A Dynamic Logic Program, P, is a sequence of generalized logic programs P1 P2 …  Pn • An interpretation Ms is a stable model of P at state 1s n iff Ms= least( [Ps – Reject(Ms)]  Def (Ms) ) Dagstuhl Seminar 02481

  7. DLP - semantics Ms= least( [Ps – Reject(Ms)]  Def (Ms) ) where: Reject(Ms) = {r Pi | r’ Pj , ijs, head(r)=not head(r’)  Ms |=body(r’)} Def(Ms) = {not A |  r Pj , js, head(r)=A  Ms |=body(r)} Dagstuhl Seminar 02481

  8. 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. Dagstuhl Seminar 02481

  9. 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? Dagstuhl Seminar 02481

  10. 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 Dagstuhl Seminar 02481

  11. 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 Dagstuhl Seminar 02481

  12. Knowledge state updating • 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. • Consecutive knowledge states are obtained as: KSn = KS0[U1][U2]...[Un], where Un represents consecutive sets of updates. We denote this by: KSn =U0  U1  ...  Un • 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]. Dagstuhl Seminar 02481

  13. LUPS Example The Statement: assertA B1,…, Bk, notC1,…,notCm whenD1,…,Dn,notE1,…, notEp The meaning of the assert statement is that if the precondition whenD1,…,Dn,notE1,…, notEp is true in the current knowledge state then the rule A B1,…, Bk, notC1,…,notCm is true in the next state, and persists from then on by inertia, until defeated by some future update or retracted. Dagstuhl Seminar 02481

  14. LUPS - Syntax • LUPS statements: they cause changes to the current state, leading to a successor state. [always] assert [event] Rule when <Conditions> [always] retract [event] Rule when <Conditions> cancel assert Rule when <Conditions> cancel retract Rule when <Conditions> <Conditions> ::= L1, L2, …, Ln. Dagstuhl Seminar 02481

  15. LUPS semantics • Sequences of commands are translated into Dynamic LPs. • Given P1 P2 …  Pi resulting from the translation of U0  U1  ...  Ui and Ui+1, obtain the new DLP P1 P2 …  Pi  Pi+1. • The semantics is then given by the semantics of the translated DLP. • This way LUPS programs specify sequences of LPs Dagstuhl Seminar 02481

  16. Translation example • Let P1 P2 …  Pi resulting from the translation of U0  U1  ...  Ui • Let Ui+1contain: assertRulewhenCond • If P1 P2 …  Pi |=Cond then RuleÎ Pi • The translation of all commands is rather extensive. Dagstuhl Seminar 02481

  17. 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 Dagstuhl Seminar 02481

  18. KABUL – Knowledge And Behaviour Update Language • Logic Programs in DLP describe knowledge at each state; • LUPS (and EPI) statements describe how to updatesuchknowledge, 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 Dagstuhl Seminar 02481

  19. KABUL - Syntax • KABUL statements: [always|once] assert (Rule|Stat)  <Cond> [always|once] retract (Rule|Stat)  <Cond> [always|once] assert [event] (Rule)  <Cond> [always|once] retract [event] (Rule)  <Cond> not assert|retract [event] (Rule|Stat)  <Cond> • Where <Cond> can include conditions on: • literals • concurrent execution of other commands; • existence of rule in the KB; • external observations Dagstuhl Seminar 02481

  20. 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? Dagstuhl Seminar 02481

  21. 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 Dagstuhl Seminar 02481

  22. 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 Dagstuhl Seminar 02481

  23. 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 Dagstuhl Seminar 02481

  24. 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 Dagstuhl Seminar 02481

  25. 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 )} > Dagstuhl Seminar 02481

  26. Self-evolution definitions • An evolution interpretation of P over L is a sequence <I1,…,In> of sets of atoms from Lassert • 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 Dagstuhl Seminar 02481

  27. 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 Dagstuhl Seminar 02481

  28. a, b, c, assert(not a ) assert(b  a) Simple example • Let P be: a  assert(not a )  b assert(b  a)  not c c  assert(not a ) • <{a, assert(b  a)}, {a, b,c,assert(not a )}, {assert( b  a)}> is an evolution SM of P. • The trace is <P,{b  a},{not a }> a, assert(b  a) Dagstuhl Seminar 02481

  29. 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 Dagstuhl Seminar 02481

  30. 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 Dagstuhl Seminar 02481

  31. 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 Dagstuhl Seminar 02481

  32. Simple example • Program P 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 Dagstuhl Seminar 02481

  33. 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)) Dagstuhl Seminar 02481

  34. 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 • … Dagstuhl Seminar 02481

  35. 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 Dagstuhl Seminar 02481

  36. … 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… Dagstuhl Seminar 02481

  37. Conclusions • Orthogonal in several respects: • Can be used in several LP based agent architectures; • Several semantics for sequences of LPs can be used; Dagstuhl Seminar 02481

  38. Open Issues • Well Founded Semantics; • Prune particular evolutions; Dagstuhl Seminar 02481

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

  40. 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. • 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. • 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. • 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. • 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. • Thomas Eiter, Michael Fink, Giuliana Sabbatini, Hans Tompits: On Properties of Update Sequences Based on Causal Rejection. TPLP 2(6): 711-767 (2002) Dagstuhl Seminar 02481

  41. 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. • 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. • 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. • 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. Dagstuhl Seminar 02481

More Related