Knowledge Evolution

1. 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

2. 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

3. 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

4. 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

5. 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

6. 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 gun holds(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)))?

7. 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 (commonsenselaw of inertia) • In 1st order logic it is difficult to express this • With a nonmonotonic logics this should be easy

8. 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.

9. 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

10. 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.

11. 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

12. 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

13. 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

14. 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.

15. 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

16. 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 gun initiates(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)?

17. 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

18. 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

19. 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.

20. 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

21. 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. • Staticrules describe the rules of the domain • Dynamicrules describe effects of actions.

22. Action Languages (cont) • 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

23. 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

24. 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 ?

25. 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.

26. 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.

27. 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

28. 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

29. 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 and TM = {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!

30. Yale shooting in C caused ¬alive ifTrue after shoot loaded caused ¬loaded ifTrueafter shoot caused loaded ifTrueafter load • We still need to say that alive and loaded are inertial: caused alive if alive after alive caused loaded if loaded after loaded

31. 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 ifTrueafter 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 • …

32. 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