Rule Updates• These languages and methodologies are basically

concerned with facts that change– There is a set of fluents (fact)– There are static rules describing the domain, which are not subject

to change– There are dynamic rules describing how the facts may change due

to actions

• What if the rules themselves, be it static or dynamic, are subject to change?– The rules of a given domain may change in time– Even the rules that describe the effects of actions may change (e.g.

rules describing the effects of action in physical devices that degrade with time)

• What we have seen up to know does not help!

Languages for rule updates• Languages dealing with highly dynamic environments where,

besides fact, also static and dynamic rules of an agent may change, need:– 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• We will study this in the setting of Logic Programming

– First define what it means to update a (running) program by another (externally given) program

– Then extend the language of Logic Programs to describe transitions between states (i.e. some sort of dynamic rules)

– Make sure that this deals with both self-updates (coming from the dynamic rules) and updates that come directly from external sources

Updates of LPs by LPs

• Dynamic Logic Programming (DLP) [ALPPP98] was introduced to address the first 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, …– But different programs may also come from different

hierarchical instances, different viewpoint (with preferences), etc.

• Inertia is applied to rules rather than to literals– Older rules conflicting with newer applicable rules are

rejected

Updating Models isn’t enough• When updating LPs, doing it model by model is not

desired. It loses the directional information of the LP arrow.

P: sleep not tv_on.watch tv_on.tv_on.

U: not tv_on p_failure.p_failure.

U2: not p_failure.

M = {tv,w}

Mu = {pf,w}

Mu2 = {w}

{pf,s}

{tv,w}

• Inertia should be applied to rule instances rather than to their previous consequences.

Logic Programs Updates Example• One should not have to worry about how to

incorporate new knowledge; the semantics should take care of it. Another example:

Open-Day(X) ← Week-end(X) . Week-end(23) . Week-end(24). Sunday(24).

Initial knowledge: The restaurant is open in the week-end

not Open-Day(X) ← Sunday(X) .

New knowledge:On Sunday the restaurant is

closed • Instead of rewriting the program we simply update it with the new

rules. The semantics should consider the last update, plus all rule instances of the previous that do not conflict.

Generalized LPs

• Programs with default negation in the head are meant to encode that something should no longer be true.

– The generalization of the semantics is not difficult

• A generalized logic program P is a set of propositional Horn clauses

L L1 ,…, Ln

where L and Li are atoms from LK , i.e. of the form A or ´not A´.

• Program P is normal if no head of the clause in P has form not A.

Generalized LP semantics

• A set M is an interpretation of LK if for every atom A in K exactly one of A and not A is in M.

• Definition:

An interpretation M of LK is a stable model of a generalized logic program P if M is the least model of the Horn theory P {not A: A M}.

Generalized LPs example

Example: K = { a,b,c,d,e} P : a not b c b e not d not d a, not c d not e

this program has exactly one stable model:

M = Least(P not {b, c, d}) = {a, e, not b, not c, not d}

N = {not a, not e, b, c, d} is not a stable model since

N Least(P {not a, not e})

Dynamic Logic Programming

• A Dynamic Logic Program P is a sequence of GLPs

P1 P2 … Pn

• An interpretation M is a stable model of P iff:M = least([UiPi – Reject(M)] U Defaults(M))

– From the union of the programs remove the rules that are in conflict with newer ones (rejected rules)

– Then, if some atom has no rules add (in Defaults) its negation

– Compute the least, and check stability

Rejection and Defaults

• By default assume the negation of atoms that have no rule for it with true body:Default(M) = {not A | r: head(r)=A and M |= body(r)}

• Reject all rules with head A that belong to a former program, if there is a later rule with complementary head and a body true in M: Reject(M) = {r Pi | r’ Pj, i ≤ j and

head(r) = not head(r’) and M |= body(r’)}

Example

• {pf, sl, not tv, not wt} is the only SM of P1 P2 – Rej = {tv }– Def = {not wt}– Least( P – {tv } U {not wt} = M

• {tv, wt, not sl, not pf} is the only SM of P1P2P3

– Rej = {pf }– Def = {not sl}

P1: sleep not tv_on.watch tv_on.tv_on.

P2: not tv_on p_failure.p_failure.

P3: not p_failure.

Another exampleP1 : not fly(X) animal(X) P4 : animal(X) bird(X)

P2 : fly(X) bird(X) bird(X) penguin(X)

P3 : not fly(X) penguin(X) animal(pluto)

bird(duffy)

penguin(tweety)

Program P1P2 P3P4 has a unique stable model in

which fly(duffy) is true and both fly(pluto) and fly(tweety) are false.

Some properties

• If M is a stable model of the union P U of programs P and U , then it is a stable model of the update program P U.– Thus, the semantics of the program P U is always

weaker than or equal to the semantics of P U.

• If either P or U is empty, or if both P and U are normal programs, then the semantics of P U and P U coincide.– DLP extends the semantics of stable models

What is still missing

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

LP Update Languages

• Define languages that extend LP with features that allow to define dynamic (state transition) rules– Put, on top of it, a language with sets of

meaningful commands that generate DLPs (LUPS, EPI, KABUL) or

– Extend the basic LP language minimally in order to allow for this generation of DLPs (EVOLP)

What do we need do make LPs evolve?

• Programs must be allowed to evolveMeaning of programs should be sequences of sets of

literals, representing evolutionsNeeded a construct to assert new informationnots in the heads to allow newer to supervene older rules

• Program evolution may me influenced by the outsideAllow 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• 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

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

Intuitive examplea ←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 ←)} >

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

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

• Recall that 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}

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 ←) ← bassert(b ← a) ← not c c ← assert(not a ←)

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

a,assert(b ← a)

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

assert(not a ←)

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

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 programs

• Self-evolving programs are autistic!

• Events may come from the outside:– Observations of facts or rules– Assertion order

• Both can be written in EVOLP language

• Influence from outside should not persist by inertia

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 P given <E1,…,Ek>, iff

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

P1 P2 …Pi Ei)

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) ← cEvents: <{c ← }, {assert(b ←)}, {assert(not a ←)}>

c,assert(a ←← b)

assert(b ←←)b, a,

assert(not a ←←)b

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

assert(b ←←)a ← b

bassert(not a ←←)

not a←

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

Yale shooting with EVOLP

• There is a turkey, initially alive:alive(turkey)

• Whenever you shoot with a loaded gun, the turkey at which you shoots dies, and the gun becomes unloaded

assert(not alive(turkey)) ← loaded, shoot.assert(not loaded) ← shoot.

• Loading a gun results in a loaded gunassert(loaded) ← load.

• Events of shoot, load, wait, etc make the program evolve• After some time, the shooter becomes older, has sight problems, and

does not longer hit the turkey if without glasses. Add event:assert( not assert(not alive(turkey)) ← not glasses)

LUPS, EPI and KABUL languages

• Sequences of commands build sequences of LPs• There are several types of commands: assert,

assert event, retract, always, …always (not a ← b, not c) when d, not e

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

commands– external events to condition the KB evolution

• KABUL extends LUPS and EPI with nesting

LUPS Syntax• Statements (commands) are of the form:

assert [event] RULE when COND– asserts RULE if COND is true at that moment. The RULE is non-

inertial if with keyword event.

retract [event] RULE when COND– the same for rule retraction

always [event] RULE when COND– From then onwards, whenever COND assert RULE (as na event if

with the keyword

cancel RULE when COND– Cancel an always command

LUPS as EVOLP

• The behavior of all LUPS commands can be constructed in EVOLP. Eg:

• always (not a ← b, not c) when d, not ecoded as event:

assert( assert(not a ← b, not c) ← d, not e )

• always event (a ← b) when ccoded 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))

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– Events with incomplete knowledge– Updates of persistent laws– Assignments– …

More features

• EVOLP extends the syntax and semantics of logic programs– If no events are given, and no asserts are used, the

semantics coincides with the stable models

– A variant of EVOLP (and DLP) have been defined also extending WFS

– An implementation of the latter is available

• EVOLP was show to properly embed action languages A, B, and C.

EVOLP possible applications

• Legal reasoning

• Evolving systems, with external control

• Reasoning about actions

• Active Data (and Knowledge) Bases

• Static program analysis of agents’ behavior

• …

… and also

• EVOLP is a concise, simple and quite powerful language to reason about KB evolution– Powerful: it can do everything other update and action

languages can, and much more– 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• Sometimes it may be regarded as too low level.

– Macros with most used constructs can help, e.g. as in the translation of LUPS’ always event command