1 / 32

Knowledge Evolution

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

lise
Download Presentation

Knowledge Evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related