Languages of Updates

1
Languages of Updates

• João Alexandre Leite

New University of Lisbon http//centria.di.fct.un
l.pt/jleite/
Co-authors José Alferes, Antonio Brogi, Luís
Moniz Pereira, Halina Przymusinska and Teodor
Przymusinski.
Dagstuhl, 25 November, 2002
Dagstuhl Seminar 02481
2
Outline

• Logic Program Updates
• Dynamic Logic Programming
• Other Semantics
• Languages of Updates
• LUPS
• EPI and KABUL
• Evolving Logic Programs EVOLP
• Discussion

3
Motivation for LPNMR

• 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
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

5
Dynamic Logic Programming

• DLP was introduced to express LPs 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
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) )
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)
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.

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?

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

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

12
Knowledge state updating

• Given the current state KS, its successor state
  KSU 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 KS0U1U2...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 KSU.

13
LUPS Example

• The Statement
• assert A ? B1,, Bk, notC1,, notCm
• when D1,,Dn, notE1,, notEp

• The meaning of the assert statement is that if
  the precondition
• when D1,,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.

14
LUPS - Syntax

• LUPS statements they cause changes to the
  current state, leading to a successor state.
• always assert event Rule when ltConditionsgt
• always retract event Rule when ltConditionsgt
• cancel assert Rule when ltConditionsgt
• cancel retract Rule when ltConditionsgt
• ltConditionsgt L1, L2, , Ln.

15
LUPS semantics

• Sequences of commands are translated into Dynamic
  LPs.
• Given P1? P2 ? ? Pi resulting from the
  translation of U0 ? U1 ? ... ? Ui and Ui1,
  obtain the new DLP P1? P2 ? ? Pi ? Pi1.
• The semantics is then given by the semantics of
  the translated DLP.
• This way LUPS programs specify sequences of LPs

16
Translation example

• Let P1? P2 ? ? Pi resulting from the
  translation of U0 ? U1 ? ... ? Ui
• Let Ui1contain assert Rule when Cond
• If P1? P2 ? ? Pi Cond then Rule Î Pi
• The translation of all commands is rather
  extensive.

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

18
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
KABUL - Syntax

• KABUL statements
• alwaysonce assert (RuleStat) ? ltCondgt
• alwaysonce retract (RuleStat) ? ltCondgt
• alwaysonce assert event (Rule) ? ltCondgt
• alwaysonce retract event (Rule) ? ltCondgt
• not assertretract event (RuleStat) ? ltCondgt
• Where ltCondgt can include conditions on
• literals
• concurrent execution of other commands
• existence of rule in the KB
• external observations

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?

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

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

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

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
  (n1)th sets must consider the addition of Rule

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.
• lt a, assert(b ?),
• a, b, assert(b ?), assert(c ?),
• a, b, c, assert(b ?), assert(c ?) gt

26
Self-evolution definitions

• An evolution interpretation of P over L is a
  sequence ltI1,,Ingt of sets of atoms from Lassert
• The evolution trace of ltI1,,Ingt is ltP1,,Pngt
• 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

27
Evolution Stable Models

• ltI1,,Ingt, with trace ltP1,,Pngt, is an evolution
  stable model of P, iff
• " 1 i n, Ii is a SM of the DLP P1 ? ? Pi

28
Simple example

• Let P be a ?
• assert(not a ?) ? b
• assert(b ? a) ? not c
• c ? assert(not a ?)
• lta, assert(b ? a), a, b,c,assert(not a ?),
  assert( b ? a)gt
• is an evolution SM of P.
• The trace is ltP,b ? a,not a ?gt

a, assert(b ? a)
29
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

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

31
Evolution Stable Models

• An event sequence is a sequence of sets of EVOLP
  rules.
• ltI1,,Ingt, with trace ltP1,,Pngt, is an evolution
  SM of P given ltE1,,Ekgt, 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

32
Simple example

• Program P says that whenever c, assert a ? b
• The events were 1st c was perceived 2nd an
  order to assert b 3rd an order to assert not a
• P assert(a ? b) ? c
• Events ltc ?, assert(b ?), assert(not a ?)gt

c, assert(a ? b)
assert(b ?)
b, a, assert(not a ?)
b
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))

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

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

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

37
Conclusions

• Orthogonal in several respects
• Can be used in several LP based agent
  architectures
• Several semantics for sequences of LPs can be
  used

38
Open Issues

• Well Founded Semantics
• Prune particular evolutions

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

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)

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.