Logic Programming for Evolving Agents J.J. Alferes J.A. Leite L.M. Pereira A. Brogi

Logic Programming for agents LP paradigm provides: LP paradigm provides: Well-defined, general, integrative framework for specifying agents’ knowledge and behavior Well-defined, general, integrative framework for specifying agents’ knowledge and behavior Procedures (and accompanying implementations) for executing agents Procedures (and accompanying implementations) for executing agents To the latter accrues recent LP implementations for non-monotonic reasoning, such as: To the latter accrues recent LP implementations for non-monotonic reasoning, such as: XSB-Prolog ( XSB-Prolog ( DLV ( DLV ( smodels ( smodels (

LP for evolving agents LP can be seen as a good representation language for static knowledge 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: 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 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 rules about the transition between states Means for describing self-updates, and self-evolution of a program, and combining self-updates with external ones Means for describing self-updates, and self-evolution of a program, and combining self-updates with external ones

Updates of LPs by LPs Dynamic Logic Programming (DLP) [ALPPP] was introduced to address some of these concerns Dynamic Logic Programming (DLP) [ALPPP] was introduced to address some of these concerns It gives meaning to sequences of LPs It gives meaning to sequences of LPs Intuitively a sequence of LPs is the result of updating P 1 with the rules in P 2, … Intuitively a sequence of LPs is the result of updating P 1 with the rules in P 2, … Inertia is applied to rules rather than to literals Inertia is applied to rules rather than to literals Older rules conflicting with newer applicable rules are rejected Older rules conflicting with newer applicable rules are rejected

What was still missing By then we knew how to give meaning to sequences of LPs By then we knew how to give meaning to sequences of LPs But how to come up with those sequences? But how to come up with those sequences? Changes maybe additions or retractions Changes maybe additions or retractions Updates maybe conditional on a present state Updates maybe conditional on a present state Some rules may represent (persistent) laws 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 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

Summary Here we present EVOLP, a language generalizing LP to deal with updates and evolution. 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 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: For the implementation of EVOLP and the example, and also other implementations on updates (viz. DLP), see:

What do we need in EVOLP Programs must be allowed to evolve 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 Program evolution may me influenced by the outside  Allow external events  … written in the language of programs

EVOLP Syntax EVOLP rules are Generalized LP rules (possibly with nots in heads) plus special predicate assert/1 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) The argument of assert is an EVOLP rule (i.e. arbitrary nesting of assert is allowed) Examples: 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 EVOLP programs are sets of EVOLP rules

Meaning of Self-evolving LPs Determined by sequences of sets of literals Determined by sequences of sets of literals Each sequence represents a possible evolution 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 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 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 If assert(Rule) belongs to the n th set, then (n+1) th sets must consider the addition of Rule

Intuitive example a ← assert(b ←) assert(c ←) ← b At the beginning a is true, and so is assert(b ←) At the beginning a is true, and so is assert(b ←) Therefore, rule b ← is asserted Therefore, rule b ← is asserted At 2 nd step, b becomes true, and so does assert(c ←) At 2 nd step, b becomes true, and so does assert(c ←) Therefore, rule c ← is asserted Therefore, rule c ← is asserted At 3 rd step, c becomes true. At 3 rd step, c becomes true. <{a, assert(b ←)}, {a, b, assert(b ←), assert(c ←)}, {a, b, c, assert(b ←), assert(c ←)}>

Self-evolution definitions An evolution interpretation of P over L is a sequence of sets of atoms from L as An evolution interpretation of P over L is a sequence of sets of atoms from L as The evolution trace of is : The evolution trace of is : P 1 = P and P i = {R | assert(R)  I i-1 } (2 ≤ i ≤ n) Evolution traces contains the programs imposed by interpretations 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 We have now to check whether each n th set complies with the programs up to n-1

Evolution Stable Models, with trace, is an evolution stable model of P, iff, 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 I is a stable model of P 1  …  P n iff I is a stable model of P 1  …  P n iff I = least( (  P i – Rej(I))  Def(I) ) where: Def(I) = {not A |  A ← Body)   P i, Body  I} Def(I) = {not A |  A ← Body)   P i, Body  I} Rej(I) = {L 0 ← Bd in Pi |  not L 0 ← Bd’)  Pj, Rej(I) = {L 0 ← Bd in Pi |  not L 0 ← Bd’)  Pj, i < j ≤ n, and Bd’  I} i < j ≤ n, and Bd’  I}

Simple example is an evolution SM of P: is an evolution SM of P: a ←assert(not a ←) ← b assert(b ← a) ← not cc ← assert(not a ←) The trace is The trace is a, assert(b ← a) a, b, c, assert(not a ←)

Event-aware programs Events may come from the outside: Events may come from the outside: Observations of facts or rules Observations of facts or rules Assertion order Assertion order Both can be written in EVOLP language Both can be written in EVOLP language An event sequence is a sequence of sets of EVOLP rules. An event sequence is a sequence of sets of EVOLP rules., with trace, is an evolution SM of P given, iff, with trace, is an evolution SM of P given, iff  1 ≤ i ≤ n, I i is a SM of the DLP: P 1  P 2  …  P i  E i )

Simple example The program says that: whenever c, assert a ← b The program 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 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

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

EVOLP for 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. 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 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. 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. Some automatic way to resolve inconsistencies due to updates is needed.

EVOLP for Assistant (cont) EVOLP provides an automatic way of removing inconsistencies due to updates: 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. 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 We are not presupposing the user is contradictory, but just that he keeps updating its profile EVOLP further allows: EVOLP further allows: Postponed addition of rules, depending on user specified criteria Postponed addition of rules, depending on user specified criteria Dynamic changes in policies, triggered by internal and/or external conditions Dynamic changes in policies, triggered by internal and/or external conditions Commands that span over various states Commands that span over various states …

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

Simple EVOLP rules By default messages are stored in the inbox: 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: 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: The definition of spam can be done by LP rules: spam(F,S,B) ← contains(S,credit). This definition can later be updated: This definition can later be updated: not spam(F,S,B) ← contains(F,my_accountant).

More EVOLP rules Messages can be automatically moved to other folders. When that happens (not shown here) the user wants to be notified: 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: 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: 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).

Conclusions We’ve presented EVOLP, and illustrated its usage in an agent application 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 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 EVOLP: a firm formal basis in which to express, implement, and reason about evolving agents