Knowledge Evolution• Up to now we have not considered evolution of the

knowledge• In real situations knowledge evolves by:

– completing it with new information

– changing it according to the changes in the world itself

• Simply adding the new knowledge possibly leads to contradiction

• In many cases a process for restoring consistency is desired

Revision and Updates• In real situations knowledge evolves by:

– completing it with new information (Revision)– changing it according to the changes in the world itself

(Updates)

• These forms of evolution require a differentiated treatment. Example:– I know that I have a flight booked for London (either for

Heathrow or for Gatwick).Revision: I learn that it is not for Heathrow

• I conclude my flight is for Gatwick

Update: I learn that flights for Heathrow were canceled • Either I have a flight for Gatwick or no flight at all

Reasoning about changes

• Dealing with changes in the world, rather than in the belief (Updates rather than revision) requires:– Methodology for representing knowledge about the

chang es, actions, etc, using existing languages

or

– New languages and semantics for dealing with a changing world

• Possibly with translation to the existing languages

Situation calculus

• Initially developed for representing knowledge that changes using 1st order logics [McCarthy and Hayes 1969]– Several problems of the approach triggered research in

nonmotonic logics• Main ingredients

– Fluent predicates: predicates that may change their truth value

– Situations: in which the fluents are true or false• A special initial situation• Other situations are characterized by the actions that were

performed from the initial situation up to the situation

Situation Calculus - Basis

• (Meta)-predicate holds/2 for describing which fluents hold in which situations

• Situations are represented by:– constant s0, representing the initial situation– terms of the form result(Action,Situation),

representing the situation that results from performing the Action in the previous situation

Yale shooting

• There is a turkey, initially alive:holds(alive(turkey),s0).

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

¬holds(alive(turkey),result(shoot,S)) ← holds(loaded,S).¬holds(loaded,result(shoot,S)).

• Loading a gun results in a loaded gunholds(loaded,result(load,S)).

• What happens to the turkey if I load the gun, and then shoot at the turkey?– holds(alive(turkey), result(shoot, result(load,s0)))?

Frame Problem

• In general only the axioms for describing what changes are not enough

• Knowledge is also needed about what doesn’t change.• Suppose that there is an extra action of waiting:

– holds(alive(turkey), result(shoot, result(wait,result(load,s0)))) is not true.

• By default, fluents should remain with the truth value they had before, unless there is evidence for their change (commonsense law of inertia)– In 1st order logic it is difficult to express this– With a nonmonotonic logics this should be easy

Frame Axioms in Logic Programming

• The truth value of fluents in two consecutive situations is, by default, the same:holds(F,result(A,S)) :- holds(F,S), not

¬holds(F,result(A,S)), not nonInertial(F,A,S).¬holds(F,result(A,S)) :- ¬holds(F,S), not

holds(F,result(A,S)), not nonInertial(F,A,S)

• This allows for establishing the law of inertia.

Representing Knowledge with the situation calculus

• Write rules for predicate holds/2 describing the effects of actions.

• Write rules (partially) describing the initial situation, and possibly also some other states

• Add the frame axioms• Care must be taken, especially in the case of

Stable Models, because models are infinite• Look at the models of the program (be it SM or

WF) to get the consequences

Yale shooting results

• The WFM of the program contains, e.g.holds(alive,result(load,s0))¬holds(alive,result(shoot,result(wait,result(load,s0))))¬holds(loaded,result(shoot,result(wait,result(load,s0))))

• Queries of the form?- holds(X,<situation>)

return what holds in the given situation.• Queries of the form

?- holds(<property>,X)

return linear plans for obtaining the property from the initial situation.

More on the rules of inertia

• The rules allow for, given information about the past, reasoning about possible futures.

• Reasoning about the past given information in the future is also possible, but requires additional axioms:

holds(F,S) :- holds(F,result(A,S)), not ¬holds(F,S), not nonInertial(F,A,S).

¬holds(F,S) :- ¬holds(F,result(A,S)), not holds(F,S), not nonInertial(F,A,S).

• Care must be taken when using these rules, since they may create infinite chains of derivation”

• On the other hand, it is difficult with this representation to deal with simultaneous actions

Fluent Calculus

• Extends by introducing a notion of state [Thielscher 1998]• Situation are representations of states• State(S) denotes the state of the world in situation S• Operator o is used for composing fluents that are true in the

same state.• Example:

– State(result(shoot,Soalive(turkey)oloaded) = S– State(result(load,S)) = Soloaded

• Axioms are needed for guaranteeing that o is commutative and associative, and for equality

• This allows inferring non-effects of action without the need for extra frame axioms

Event Calculus

• It is another methodology developed for representing knowledge that changes over time [Kowalski and Sergot 1986]

• Solves the frame problem in a different (simpler) way, also without frame axioms.

• It is adequate for determining what holds after a series of action being performed

• It does not directly help for planning and for general reasoning about the knowledge that is changing

Event Calculus - Basis

• Fluents are represented as terms, as in situation calculus• Instead of situations, there is a notion of discrete time:

– constants for representing time points– predicate </2 for representing the (partial) order among points– predicates </2 should contain axioms for transitive closure, as

usual.

• A predicates holds_at/2 defines which fluents hold in which time points

• There are events, represented as constants.• Predicate occurs/2 defines what events happen in which

time points.

Event Calculus – Basis (cont)

• Events initiate (the truth) of some fluents and terminate (the truth) of other fluents.

• This is represented using predicates initiates/3 and terminates/3

• Effects of action are described by the properties initiated and terminated by the event associated to the action occurrence.

• There is a special event, that initiates all fluents at the beginning

Yale shooting again

• There is a turkey, initially alive:initiates(alive(turkey),start,T). occurs(start,t0).

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

terminates(alive(turkey),shoot,T) ← holds_at(loaded,T).terminates(loaded,shoot,T).

• Loading a gun results in a loaded guninitiates(loaded,load,T).

• The gun was loaded at time t10, and shoot at time t20:occurs(load,t10). occurs(shoot,t20).

• Is the turkey alive at time t21?– holds_at(alive(turkey), t21)?

General axioms for event calculus

• Rules are needed to describe what holds, based on the events that occurred:holds_at(P,S) :- occurs(E,S1), initiates(P,E,S1),

S1 < S, not clipped(P,S1,S).clipped(P,S1,S2) :- occurs(E,S), S1 ≤ S < S2,

terminates(P,E,S).

• There is no need for frame axioms. By default thing will remain true until terminated

Event calculus application

• Appropriate when it is known which events occurred, and the reasoning task is to know what holds in each moment. E.g. – reasoning about changing databases– reasoning about legislation knowledge bases, for determining what

applies after a series of events– Reasoning with parallel actions.

• Not directly applicable when one wants to know which action lead to an effect (planning), or for reasoning about possible alternative courses of actions– No way of inferring occurrences of action– No way of representing various courses of actions– No way of reasoning from the future to the past

Event calculus and abduction

• With abduction it is possible to perform planning using the event calculus methodology– Declare the occurrences of event as abducible– Declare also as abducible the order among the time

events occurred– Abductive solutions for holds_at(<fluent>,<time>)

give plans to achieve the fluent before the given (deadline) time.

Representing Knowledge with the event calculus

• Write rules for predicates initiates/3 and terminates/3 describing the effects of actions.

• Describe the initial situation as the result of a special event e.g. start, and state that start occurred in the least time point.

• Add the axioms defining holds_at/2• Add rule for describing the partial order of time

– These are not need if e.g. integer are used for representing time

• Add occurrences of the events• Query the program in time points

Action Languages

• Instead of– using existing formalism, such as 1st order logics, logic

programming, etc, – and developing methodologies

• Design new languages specifically tailored for representing knowledge in a changing world– With a tailored syntax for action programs providing ways of

describing how an environment evolves given a set external actions

– Common expressions are static and dynamic rules.• Static rules describe the rules of the domain• Dynamic rules describe effects of actions.

• Usually, the semantics of an action program is defined in terms of a transition system.– Intuitively, given the current state of the world s and a set

of actions K, a transition system specifies which are the possible resulting states after performing, simultaneously all the actions in K.

• The semantics can also be given as a translation into an existing formalism– E.g. translating action programs into logic programs

(possibly with extra arguments on predicates, with extra rules, e.g. for frame axioms) assuring that the semantics of the transformed program has a one-to-one correspondence with the semantics of the action program

Action Languages (cont)

The A language

• First proposal by [Gelfond Lifshitz, 1993].• Action programs are sets of rules of the form:

– initially <Fluent>– <Fluent> after <Action1>; … ; <ActionN>– <action> causes <Fluent> [if <Condition>]

• A semantics was first defined in terms of a transition system (labeled graph where the nodes are states – sets of fluents true in it – and where the arc are labeled with action)

• Allows for– non-deterministic effects of actions– Conditional effects of actions

The Yale shooting in A

initialy alive.

shoot causes ¬alive if loaded.

shoot causes ¬loaded.

load causes loaded.

• It is possible to make statements about other states, e.g.¬alive after shoot; wait.

• and to make queries about states:¬alive after shoot; wait; load ?

Translation A into logic programs

• An alternative definition of the semantics is obtained by translating A-programs into logics programs. Roughly:– Add the frame axioms just as in the situation calculus– For each rule

• initially f add holds(f,s0).• f after a1;…;an add holds(f,result(a1,…result(an,s0)…)• a causes f if cond add

holds(f,result(a,S)) :- holds(cond,S).

• Theorem: holds(f,result(a1,…,result(an,s0)…) belongs to a stable model of the program iff there is a state resulting from the initial state after applying a1, … an where f is true.

The B Language

• The B language [Gelfond Lifshitz, 1997]. extends A by adding static rules.

• Dynamic rules, as in A, allow for describing effects of action, and “cause” a change in the state.

• Static rules allow for describing rules of the domain, and are “imposed” at any given state

• They allow for having indirect effects of actions• Static rules in B are of the form:

<Fluent> if <Condition>

• Example:dead if ¬alive.

Causality and the C language

• Unlike both A and B, where inertia is assumed for all fluents, in C one can decide which fluents are subject to inertia and which aren’t:– Some fluents, such as one time events, should not be

assumed to keep its value by inertia. E.g. action names, incoming messages, etc

• Based on notions of causality:– It allows for assertion that F is caused by Action,

stronger than asserting that F holds

• As in B, it comprises static and dynamic rules

Rules in C

• Static Rules:caused <Fluent> if <Condition>

– Intuitively tells that Condition causes the truth of Fluent

• Dynamic Rules:caused <Fluents> if <Condition> after <Formula>

– The <Formula> can be built with fluents as well as with action names

– Intuitively this rules states that after <Formula> is true, the rule caused <Fluents> if <Condition> is in place

Causal Theories and semantics of C

• The semantics of C is defined in terms of causal theories (sets of static rules)– Something is true iff it is caused by something else

• Let T be a causal theory, M be a set of fluents andTM = {F| caused F if G and M |= G}

M is a causal model of T iff M is the unique model of TM.• The transition system of C is defined by:

– In any state s (set of fluents) consider the causal theory TK formed by the static rules and the dynamic rules true at that state U K, where K is any set of actions

– There is an arc from s to s’ labeled with K iff s’ is a causal model of TK.

– Note that this way inertia is not obtained!

Yale shooting in C

caused ¬alive if True after shoot loaded

caused ¬loaded if True after shoot

caused loaded if True after load

• We still need to say that alive and loaded are inertial:caused alive if alive after alive

caused loaded if loaded after loaded

Macros in C

• Macro expressions have been defined for easing the representation of knowledge with C:– A causes F if G

• standing for caused F if True after G A– inertial F

• standing for caused F if F after F

– always F• standing for caused if ¬F

– nonexecutable A if F• standing for caused if F A

– …

Extensions of C

• Several extensions exist. E.g.– C++ allowing for multi-valued fluents, and to

encode resources

– K allowing for reasoning with incomplete states

– P and Q that extend C with rich query languages, allowing for querying various states, planning queries, etc