Logic Programming for Evolving Agents

1
Logic Programming for Evolving Agents

• J.J. Alferes jja_at_di.fct.unl.pt
• J.A. Leite jleite_at_di.fct.unl.pt
• L.M. Pereira lmp_at_di.fct.unl.pt
• A. Brogi brogi_at_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, its 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 EVOLPs 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
  (n1)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.
• lt a, assert(b ?),
• a, b, assert(b ?), assert(c ?),
• a, b, c, assert(b ?), assert(c ?) gt

11
Self-evolution definitions

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

12
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
• 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 lt j n, and Bd Í I

13
Simple example

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

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.
• 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 Å P2 Å Å (Pi È Ei)

15
Simple example

• The program 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
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 referees
  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

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