Logic Programming for Evolving Agents

1. Logic Programming for Evolving Agents J.J. Alferes jja@di.fct.unl.pt, J.A. Leite jleite@di.fct.unl.pt, L.M. Pereira lmp@di.fct.unl.pt A. Brogi brogi@di.unipi.it

2. Logic Programming for agents • LP paradigm provides: • Well-defined, general, integrative framework for specifying agents’ knowledge and behavior • Procedures (and accompanying implementations) for executing agents • To the latter accrues recent LP implementations for non-monotonic reasoning, such as: • XSB-Prolog (http://xsb.sourceforge.net/) • DLV (http://www.dbai.tuwien.ac.at/proj/dlv/) • smodels (http://www.tcs.hut.fi/Software/smodels/)

3. LP for evolving agents • LP can be seen as a good representation language for static knowledge • In a dynamic environment, typical of the agency paradigm, classical LP is less than adequate. Lacks: • Means of integrating knowledge updates from external sources (be it from user changes in the rules describing agent behavior, or simply from environment events) • Means for describing rules about the transition between states • Means for describing self-updates, and self-evolution of a program, and combining self-updates with external ones

4. Updates of LPs by LPs • Dynamic Logic Programming (DLP) [ALPPP] was introduced to address some of these concerns • It gives 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 • Since LP can be used to describe knowledge states and also sequences of updating states, it’s only fit that LP is used too to describe transitions, and thus come up with such sequences

6. Summary • Here we present EVOLP, a language generalizing LP to deal with updates and evolution. • We illustrate EVOLP’s usage by specifying an e-mail Personal Assistant Agent • For the implementation of EVOLP and the example, and also other implementations on updates (viz. DLP), see: http://centria.di.fct.unl.pt/~jja/updates/

7. What do we need in EVOLP • Programs must be allowed to evolve • Meaning of programs should be sequences of sets of literals, representing evolutions • Needed a construct to assert new 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

8. EVOLP 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

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

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

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

12. 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, Body Í I} • Rej(I) = {L0 ← Bd in Pi | $(not L0 ← Bd’) Î Pj, i < j ≤ n, and Bd’ Í I}

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

14. Event-aware programs • Events may come from the outside: • Observations of facts or rules • Assertion order • Both can be written in EVOLP language • 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 Å P2 Å …Å (Pi È Ei)

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

16. Email agent core • Personal assistant agent for e-mail management able to: • Perform basic actions of sending, receiving, deleting messages • Storing and moving messages between folders • Filtering spam messages • Sending automatic replies and forwarding • Notifying the user of special situations • All of this may depend on user specified criteria • The specification may change dynamically

17. EVOLP for e-mail Assistant • If the user specifies, once and for all, a consistent set of policies triggering actions, then any existing (commercial) assistant would do the job. • But if we allow the user to update its policies, and to specify both positive (e.g. “…must be deleted”) and negative (e.g. “…must not be deleted”) instances, soon the union of all policies becomes inconsistent • We cannot expect the user to debug the set of policy rules so as to invalidate all the old rules (instances) contravened by newer ones. • Some automatic way to resolve inconsistencies due to updates is needed.

18. EVOLP for e-mail Assistant (cont) • EVOLP provides an automatic way of removing inconsistencies due to updates: • With EVOLP the user simply states whatever new is to be done, and let the agent automatically determine which old rules may persist and which not. • We are not presupposing the user is contradictory, but just that he keeps updating its profile • EVOLP further allows: • Postponed addition of rules, depending on user specified criteria • Dynamic changes in policies, triggered by internal and/or external conditions • Commands that span over various states • …

19. An EVOLP e-mail Assistant • In the following we show some policy rules of the EVOLP e-mail assistant. • A more complete set of rules, and the results given by EVOLP, can be found in the paper. • Basic predicates: • New messages come as events of the form: newmsg(Identifier, From, Subject, Body) • Messages are stored via predicates: msg(Identifier, From, Subj, Body, TimeStamp) and in(Identifier, FolderName)

20. Simple e-mail EVOLP rules • By default messages are stored in the inbox: assert(msg(M,F,S,B,T)) ← newmsg(M,F,S,B), time(T), not delete(M). assert(in(M,inbox)) ← newmsg(M,F,S,B), not delete(M). assert(not in(M,F)) ← delete(M), in(M,F). • Spam messages are to be deleted: delete(M) ← newmsg(M,F,S,B), spam(F,S,B). • The definition of spam can be done by LP rules: spam(F,S,B) ← contains(S,credit). • This definition can later be updated: not spam(F,S,B) ← contains(F,my_accountant).

21. More e-mail EVOLP rules • Messages can be automatically moved to other folders. When that happens (not shown here) the user wants to be notified: notify(M) ← newmsg(M,F,S,B), assert(in(M,F)), assert(not in(M,inbox)). • When a message is marked both for deletion and automatic move to another folder, the deletion should prevail: not assert(in(M,F)) ← move(M,F), delete(M). • The user is organizing a conference, assigning papers to referees. After receipt of a referee’s acceptance, a new rule is to be added, which forwards to the referee any messages about assigned papers: assert(send(R,S,B1) ← newmsg(M1,F,S,B1), contains(S,Id), assign(Id,R)) ← newmsg(M2,R,Id,B2), contains(B2,accept).

22. Conclusions • We’ve presented EVOLP, and illustrated its usage in an agent application • EVOLP is a declarative, concise, simple and quite powerful language to reason about agents that evolve • EVOLP: a firm formal basis in which to express, implement, and reason about evolving agents