EVOEVOlving lving LLogic ogic PProgramsrograms

J.J. Alferes, J.A. Leite, L.M. J.J. Alferes, J.A. Leite, L.M. Pereira (UNL)Pereira (UNL)

A. Brogi (U.Pisa)A. Brogi (U.Pisa)

LP for KRRLP for KRR

LP has been widely used for LP has been widely used for representing static knowledgerepresenting static knowledge

Attempts have been made to define Attempts have been made to define LP frameworks that deal with LP frameworks that deal with dynamics of knowledge – dynamics of knowledge – LPs LPs UpdatesUpdates

Here we present a Here we present a simple and simple and powerfulpowerful approach for LPs Updates approach for LPs Updates Why another approach?Why another approach?

Model updates of [MT]Model updates of [MT] Language for updating KBs, with rules:Language for updating KBs, with rules:

in(Ain(A00) | out(A) | out(A00) ← in(A) ← in(A11), ..., out(A), ..., out(Ann)) Given the set of interpretations of an initial Given the set of interpretations of an initial

KB, and a set of revision rules, the set of KB, and a set of revision rules, the set of interpretations of the resulting KB is interpretations of the resulting KB is obtainedobtained

Problems:Problems: The resulting KB is only indirectly characterizedThe resulting KB is only indirectly characterized No intuitive results when the intentional part of No intuitive results when the intentional part of

the KB changes. Doesn’t work well for rules the KB changes. Doesn’t work well for rules updatesupdates

Updates of LPs by LPsUpdates of LPs by LPs

DLP [ALPPP] give meaning to DLP [ALPPP] give meaning to sequences of LPssequences of LPs

Intuitively a sequence of LPs is the Intuitively a sequence of LPs is the result of updating Presult of updating P11 with the rules in with the rules in PP22, …, …

Inertia is applied to rules rather than to Inertia is applied to rules rather than to literalsliterals

Older rules conflicting with newer Older rules conflicting with newer applicable rules are rejectedapplicable rules are rejected

What was still missing What was still missing By then we knew how to give meaning to By then we knew how to give meaning to

sequences of LPssequences of LPs But how to come up with those But how to come up with those

sequences?sequences? Changes maybe additions or retractionsChanges maybe additions or retractions Updates maybe conditional on a present Updates maybe conditional on a present

statestate Some rules may represent (persistent) lawsSome rules may represent (persistent) laws

LUPS [APPP], EPI [EFST], and KABUL LUPS [APPP], EPI [EFST], and KABUL [Leite] are (command) language defined [Leite] are (command) language defined for these purposesfor these purposes

Languages of UpdatesLanguages of Updates Sequences of commands build sequences Sequences of commands build sequences

of LPsof LPs There are several types of commands: There are several types of commands:

assertassert, , assert eventassert event, , retractretract, , alwaysalways, …, …alwaysalways (not a ← b, not c) (not a ← b, not c) whenwhen d, not e d, not e

EPI extends LUPS to allow for:EPI extends LUPS to allow for: commands whose execution depends on other commands whose execution depends on other

commandscommands external events to condition the KB evolutionexternal events to condition the KB evolution

KABUL extends LUPS and EPI with KABUL extends LUPS and EPI with nestingnesting

Problems with these Problems with these languageslanguages

Too many commandsToo many commands Far from the spirit of LPFar from the spirit of LP ComplexComplex Difficult to prove propertiesDifficult to prove properties

Fixed set of commandsFixed set of commands Each encodes a high-level behavior for additionsEach encodes a high-level behavior for additions Are those the only interesting behaviors? E.g.Are those the only interesting behaviors? E.g.

Make additions dependent upon conditions that span Make additions dependent upon conditions that span over statesover states

Model changes of (persistent) update commandsModel changes of (persistent) update commands

One could further extend the language. But, One could further extend the language. But, where to stop?where to stop?

How to proceedHow to proceed

Instead of extending with new Instead of extending with new commandscommands

Minimally add constructs and concepts Minimally add constructs and concepts to LP, to cope with evolution and to LP, to cope with evolution and updating (start from scratch)updating (start from scratch)

The result, The result, EVOLPEVOLP, provides a simpler, , provides a simpler, closer to traditional LP, and more closer to traditional LP, and more general formulation of LP Updatesgeneral formulation of LP Updates

What do we (really) needWhat do we (really) need

Programs must be allowed to evolvePrograms must be allowed to evolve Meaning of programs should be sequences of sets Meaning of programs should be sequences of sets

of literals, representing evolutionsof literals, representing evolutions Need a construct to assert new informationNeed a construct to assert new information? Do we need a construct to retract old information?Do we need a construct to retract old information? notnots in the heads to allow newer to supervene s in the heads to allow newer to supervene

older rulesolder rules Program evolution may me influenced by the Program evolution may me influenced by the

outsideoutside Allow external eventsAllow external events … … written in the language of programswritten in the language of programs

Self-evolving LPs - Self-evolving LPs - Syntax Syntax

EVOLP rules are Generalized LP rules EVOLP rules are Generalized LP rules (possibly with (possibly with notnots in heads) plus special s in heads) plus special predicate predicate assert/1assert/1

The argument of The argument of assertassert is an EVOLP rule is an EVOLP rule (i.e. arbitrary nesting of (i.e. arbitrary nesting of assertassert is allowed) is allowed)

Examples:Examples:assert( a ← not b) ← d, not eassert( a ← not b) ← d, not e

not a ← not assert( assert(a ← b)← not b), cnot a ← not assert( assert(a ← b)← not b), c EVOLP programs are sets of EVOLP rulesEVOLP programs are sets of EVOLP rules

Meaning of Self-evolving Meaning of Self-evolving LPsLPs

Determined by sequences of sets of literalsDetermined by sequences of sets of literals Each sequence represents a possible evolutionEach sequence represents a possible evolution The nThe nthth set in a sequence represents what is set in a sequence represents what is

true/false after n steps in that evolutiontrue/false after n steps in that evolution The first set in sequences is a SM of the LP, The first set in sequences is a SM of the LP,

where assert/1 literals are viewed as normal where assert/1 literals are viewed as normal onesones

If If assert(Rule)assert(Rule) belongs to the n belongs to the nthth set, then set, then (n+1)(n+1)thth sets must consider the addition of sets must consider the addition of RuleRule

Intuitive exampleIntuitive example

a ←a ←assert(b ←) assert(b ←) assert(c ←) ← bassert(c ←) ← b

At the beginning At the beginning aa is true, and so is is true, and so is assert(b assert(b ←)←)

Therefore, rule Therefore, rule b ← b ← is assertedis asserted At 2At 2ndnd step, step, bb becomes true, and so does becomes true, and so does

assert(c ←) assert(c ←) Therefore, rule Therefore, rule c ← c ← is assertedis asserted At 3At 3rdrd step, step, cc becomes true. becomes true.

<< {a, assert(b ←)},{a, assert(b ←)},{a, b, assert(b ←), assert(c ←)},{a, b, assert(b ←), assert(c ←)},{a, b, c, assert(b ←), assert(c ←)}{a, b, c, assert(b ←), assert(c ←)} >>

Self-evolution definitionsSelf-evolution definitions

An An evolution interpretationevolution interpretation of of PP over over LL is a is a sequence sequence <I<I11,…,I,…,Inn>> of sets of atoms from of sets of atoms from LLasas

The The evolution traceevolution trace of of <I<I11,…,I,…,Inn>> is is <P<P11,,…,P…,Pnn>>::

PP11 = P = P and and PPii = {R | assert(R) = {R | assert(R) I Ii-1i-1}} (2 ≤ i ≤ n)(2 ≤ i ≤ n)

Evolution traces contains the programs Evolution traces contains the programs imposed by interpretationsimposed by interpretations

We have now to check whether each nWe have now to check whether each nthth set set complies with the programs up to n-1complies with the programs up to n-1

Evolution Stable ModelsEvolution Stable Models

<I<I11,…,I,…,Inn>>, with trace , with trace <P<P11,…,P,…,Pnn>>, is an , is an evolution stable modelevolution stable model of of PP, iff, iff

1 ≤ i ≤ n1 ≤ i ≤ n, , IIii is a SM of the DLP: is a SM of the DLP: PP1 1 … …PPii

I is a stable model of I is a stable model of PP1 1 … …PPnn iff iff

I = least( (I = least( (PPii – Rej(I)) – Rej(I)) Def(I) ) Def(I) )where:where: Def(I) = {not A | Def(I) = {not A | A ← Body) A ← Body) PPii}} Rej(I) = {LRej(I) = {L00 ← Bd in Pi | ← Bd in Pi | not Lnot L00 ← Bd’) ← Bd’) Pj, Pj,

i < j ≤ n, and Bd’ i < j ≤ n, and Bd’ I} I}

Simple exampleSimple example

<{a, ast(b ← a)}, {a, b,c,ast(not a ←)}, {ast( b <{a, ast(b ← a)}, {a, b,c,ast(not a ←)}, {ast( b ← a)}>← a)}> is an evolution SM of P: is an evolution SM of P:

a ←a ← assert(not a ←) ← bassert(not a ←) ← bassert(b ← a) ← not cassert(b ← a) ← not c c ← assert(not a c ← assert(not a ←)←)

The trace is The trace is <P,{b ← a},{not a ←}><P,{b ← a},{not a ←}>

a,assert(b ← a)

assert(b ← a)a, b, c,

assert(not a ←)

Example with various Example with various evolutionsevolutions No matter what, assert No matter what, assert cc; if ; if aa is not going to is not going to

be asserted, then assert be asserted, then assert bb; if ; if cc is true, and is true, and bb is not going to be asserted, then assert is not going to be asserted, then assert aa..

assert(b) ← not assert(a)assert(b) ← not assert(a).. assert(c) ←assert(c) ←assert(a) ← not assert(b), cassert(a) ← not assert(b), c

Paths in the graph below are evolution SMsPaths in the graph below are evolution SMs

ast(b)ast(c)

b,c,ast(b)ast(c)

b,c,ast(a)ast(c)

a,b,c,ast(b)ast(c)

a,b,c,ast(a)ast(c)

Event-aware programsEvent-aware programs

Self-evolving programs are autistic!Self-evolving programs are autistic! Events may come from the outside:Events may come from the outside:

Observations of facts or rulesObservations of facts or rules Assertion orderAssertion order

Both can be written in EVOLP Both can be written in EVOLP languagelanguage

Influence from outside should not Influence from outside should not persist by inertiapersist by inertia

Evolution Stable ModelsEvolution Stable Models

An An event sequenceevent sequence is a sequence of is a sequence of sets of EVOLP rules.sets of EVOLP rules.

<I<I11,…,I,…,Inn>>, with trace , with trace <P<P11,…,P,…,Pnn>>, is an , is an evolution SMevolution SM of of PP givengiven <E<E11,…,E,…,Ekk>>, iff, iff

1 ≤ i ≤ n1 ≤ i ≤ n, , IIii is a SM of the DLP: is a SM of the DLP:

PP1 1 … …PPi i E Eii)) Note that, this way, events from the Note that, this way, events from the

outside do not persist by inertiaoutside do not persist by inertia

Simple exampleSimple example The program says that: whenever The program says that: whenever cc, assert , assert a ← a ←

bb The events were: 1The events were: 1stst cc was perceived; 2 was perceived; 2ndnd an an

order to assert order to assert bb; 3; 3rdrd an order to assert an order to assert not anot a

P: assert(a ← b) ← cP: assert(a ← b) ← cEvents: <{c ← }, {assert(b ←)}, {assert(not a Events: <{c ← }, {assert(b ←)}, {assert(not a ←)}>←)}>

c,assert(a ←← b)

assert(b ←←)b, a,

assert(not a ←←)b

LUPS as EVOLPLUPS as EVOLP The behavior of all LUPS commands can The behavior of all LUPS commands can

be constructed in EVOLP. Eg:be constructed in EVOLP. Eg: alwaysalways (not a ← b, not c) (not a ← b, not c) whenwhen d, not e d, not e

coded as event:coded as event:assert( assert(not a ← b, not c) ← d, not e )assert( assert(not a ← b, not c) ← d, not e )

always eventalways event (a ← b) (a ← b) whenwhen c ccoded as events:coded as events:

assert( assert(a ← b, ev(a ← b)) ← c )assert( assert(a ← b, ev(a ← b)) ← c )assert( assert(ev(a ← b)) ← c )assert( assert(ev(a ← b)) ← c )

plus:plus:assert( not ev(R) ) ← ev(R), not assert( not ev(R) ) ← ev(R), not

assert(ev(R))assert(ev(R))

EVOLP featuresEVOLP features

All LUPS and EPI features are EVOLP features:All LUPS and EPI features are EVOLP features: Rule updates; Persistent updates; simultaneous Rule updates; Persistent updates; simultaneous

updates; events; commands dependent on other updates; events; commands dependent on other commands; …commands; …

Many extra features (some of them in KABUL) Many extra features (some of them in KABUL) can be can be programmedprogrammed:: Commands that span over timeCommands that span over time Events with incomplete knowledgeEvents with incomplete knowledge Updates of persistent lawsUpdates of persistent laws AssignmentsAssignments ……

EVOLP possible EVOLP possible applicationsapplications

Legal reasoningLegal reasoning Evolving systems, with external Evolving systems, with external

controlcontrol Reasoning about actionsReasoning about actions Active Data (and Knowledge) BasesActive Data (and Knowledge) Bases Static program analysis of agents’ Static program analysis of agents’

behaviorbehavior ……

… … and alsoand also

EVOLP is a concise, simple and quite powerful EVOLP is a concise, simple and quite powerful language to reason about KB evolutionlanguage to reason about KB evolution PowerfulPowerful: it can do everything other update : it can do everything other update

languages can, and much morelanguages can, and much more Simple and conciseSimple and concise: much better to use for : much better to use for proving proving

propertiesproperties of KB evolution of KB evolution EVOLP: a firm formal basis in which to EVOLP: a firm formal basis in which to

express, implement, and reason about express, implement, and reason about dynamic KBdynamic KB

Opens up a number of research topicsOpens up a number of research topics Much remains do be done…Much remains do be done…