Combining Narratives

A theory is elaboration tolerant to the extent that new information can be incorporated with only simple changes. The simplest change is conjoining new information, and only conjunctive changes are considered in this paper. In general adding information to a theory should often change, rather than just enlarge, its consequences, and this requires that some of the reasoning be non-monotonic. Our theories are narratives—accounts of sets of events, not necessarily given as sequences. A narrative is elaboration tolerant to the extent that new events, or more detail about existing events, can be added by just adding more sentences. We propose a new version of the situation calculus which allows information to be added easily. In particular, events concurrent with already described events can be introduced without modifying the existing descriptions, and more detail of events can be added. A major benefit is that if two narratives do not interact, then they can be consistently conjoined. 1 OBJECTIVES OF SITUATION CALCULUS The logical approach to AI ([McC59] and [McC89]) is to make a computer program that represents what it knows about the world in general, what it knows about the situation it is in, and also its goals, all as sentences in some mathematical logical language. The program then infers logically what action is appropriate for achieving its goal and does it. Since 1980 it has been widely known that nonmonotonic inference must be included. The actions our program can perform include some that generate sentences by other means than logical inference, e.g. by observation of the world or by the use of special purpose non-logical problem solvers. Simpler behaviors, e.g. actions controlled by servomechanisms or reflexes can be integrated with logic. The actions decided on by logic can include adjusting the parameters of ongoing reflexive actions. Thus a person can decide to walk faster when he reasons that otherwise he will be late, but this does not require that reason control each step of the walking.1 Situation calculus is an aspect of the logic approach to AI. A situation is a snapshot of the world at some instant. Situations are rich2 objects in that it is not possible to completely describe a situation, only to say some things about it. From facts about situations and general laws about the effects of actions and other events, it is possible to infer something about future situations. Situation calculus was first discussed in [McC63], but [MH69] was the first widely read paper about it. In this formalization of action in situation calculus, there are at least three kinds of problem—narrative, planning and prediction. Of these, narrative seems to be the simplest for humans. A narrative is an account of what happened. We treat it by giving some situations and some events and some facts about them and their relations. Situations in a narrative are partially ordered in time. The real situations are totally ordered3, but the narrative may not include full information about this ordering. Thus the temporal relations between situations need only be described to the extent needed to describe their interactions. Situations occurring entirely in different places give the most obvious examples, but even actions by the same person in the same place may not interact as far as the inferences we draw. If Thus we protect our flank from the disciples of Rod Brooks. Though rich, situations are still approximate, partial objects. The idea will be developed elsewhere. Hypothetical situations need not be totally ordered; the situation where Oswald missed Kennedy is neither in the past nor the future. we state that the traveler on certain flight reads a book and also drinks a Coca-cola, we humans don’t need to know any temporal relations between the two events unless they interact. In situation calculus as it was originally envisaged (and has been used,) events (mainly actions) in a situation produce next situations, e.g. s = Result(e, s). The original theory did not envisage more than one event occurring in a situation, and it did not envisage intermediate situations in which events occur. However, rarely did people write axioms that forbade4 these possibilities; it’s just that no-one took advantage of them. Our present formalism doesn’t really change the basic formalism of the situation calculus much; it just takes advantage of the fact that the original formalism allows treating concurrent events even though concurrent events were not originally supposed to be treatable in that formalism. Gelfond, Lifschitz and Rabinov [GLR91] treat concurrent events in a different way from what we propose here. In a narrative, it is not necessary that what is said to hold in a situation be a logical consequence (even nonmonotonically) of what was said to hold about a previous situation and known common sense facts about the effects of events. In the first place, in stories new facts about situations are often added, e.g. “When Benjamin Franklin arrived in London it was raining”. In the second place, we can have an event like tossing a coin in which neither outcome has even a non-monotonic preference.5 In interpreting the following formalizations, we regard situations as rich objects and events as poor. In fact, we are inclined to take a deterministic view within any single narrative. In principle, every event that occurs in a situation and every fact about following situations is an inevitable consequence of the facts about the situation. Thus it is a fact about a situation that a coin is tossed and that it comes up tails. However, such facts are only occasionally consequences of the facts about the situation that we are aware of in the narrative. Perhaps narrative seems easy, since it is not yet clear what facts must be included in a narrative and what assertions should be inferable from a narrative. We have however a basic model that handles some of the more basic features. Reiter [Rei93] did write such axioms. Nevertheless, some narratives are anomalous. If we record that Junior flew to Moscow, and, in the next situation mentioned, assert that he is in Peking, a reader will feel that something has been left out. We want to introduce a concept of a proper narrative, this is a narrative without anomalies. The fluents holding in a new situation should be reasonable outcomes of the events that have been reported, except for those fluents which are newly asserted, e.g. that it was raining in London when Franklin arrived. 2 ELABORATION TOLERANT REASONING A formalization of a phenomenon is elaboration tolerant to the extent that it permits elaborations of the description without requiring completely redoing the basis of the formalization. In particular, it would be unfortunate to have to change the predicate symbols. Ideally the elaboration is achieved by adding sentences, rather than by changing sentences. Often when we add sentences we need to use some form of non-monotonic reasoning. This is because we often want to add information that we would previously have assumed was false. Unless we use non-monotonicity we would get inconsistency. In this paper we concentrate on the easier case when there is no need for non-monotonicity. Natural language descriptions of phenomena seem to be more elaboration tolerant than any existing formalizations. Here are the two major kinds of elaboration tolerance that we examine in this paper. 2.1 NON-INTERACTING EVENTS Allowing the addition of a description of a second phenomenon that doesn’t interact with the first. In this case the conclusions that can be drawn about the combined narrative are just the conjunction of the conclusions about the component narratives. To infer the obvious consequences of events we need to assume that some other events do not occur. In this paper, a major novelty is that we do not assume that no other events occur. We only state that there are no events that would cause an event in our narrative to fail. Thus a narrative about stacking blocks will state that the only block moving actions6 are those mentioned. A block stacking narrative will not say that no traveling events occur. Nor will a narrative about traveling makes claims about what block stacking events happen. This allows noninteracting narratives to be consistently conjoined. Previous proposals could not conjoin two narratives, as they either assumed that the events that happened were picked out by the result function, or they assumed that the only events that occurred were those mentioned. 2.1.1 DETAIL OF EVENTS We can add details of an event. On the airplane from Glasgow to London, Junior read a book and drank a Coca-Cola. If we make the assumption that other relevant events do More precisely, no other actions that would move the blocks mentioned in the narrative occur. Other blocks might be stacked in Baghdad, if our narrative is about New York. Perhaps a theory of context, that would interpret a statement about all blocks in our narrative, as a statement about all the blocks in New York could be used here. not happen, we can elaborate by adding another event, so long as it is compatible with what we have said. However the notion of relevant must be formalized very carefully, as is apparent when we elaborate a particular event as a sequence of smaller events. “How did he buy the Kleenex? He took it off the shelf, put it on the counter, paid the clerk and took it home.” A narrative that just mentions buying the Kleenex should not exclude this particular elaboration. Moreover, if we elaborate in this way, we don’t want to exclude subsequent elaboration of component events, e.g. elaborating paying the clerk into offering a bill, taking the change, etc. Our formalism allows details of an event to be added by conjoining extra sentences. 3 MODIFYING THE SITUATION CALCULUS Formalisms such as the situation calculus of McCarthy and Hayes [MH69], and the event calculus of Kowalski [KS97] have been used to represent and reason about a changing world c.f [Sha97]. Neither of these formalisms is exactly what is needed to represent the kind of narratives we wish to consider. The situation calculus in its most limited version does not allow us to represent what events occur explicitly—rather every sequence of events is assumed to occur. We can specify that a particular sequence of events occurs by introducing a predicate, actual true of just the sequence of situations that occur7. This is not ideal, as it forces us to decide what events happened earlier, before we name the events that happen later. For this reason we use a modified situation calculus, adding a new predicate Occurs(e, s), that states what events occur. Thus, rather than the function Result(e, s) serving two purposes, stating that e occurred at s, and designating the resulting situation, we split these two functions. We keep Result(e, s), but it now only denotes the result of doing e in s when e Occurs at s. If e does not occur, then the value of this function is an arbitrary situation8. This adds an event calculus style of presentation to the underlying situation calculus formalism. In particular, it allows us to specify a sequence of events, without making any claims as to what other events may have happened in the meantime. 3.1 OUR ONTOLOGY OF SITUATIONS Reiter has suggested that the situations in the situation calculus be defined axiomatically. He suggests the following Pinto and Reiter [PR95] actually do this. We could choose instead to make Result a partial function, but this introduces the difficulties of partial functions. four axioms9 S0 : ∀s.¬s < S0 ∀a, s, s′.s < Result(a, s ′) ≡ (s = s ′ ∨ s < s ′) P : ∀a, a′, s, s′.Result(a, s) = Result(a ′, s ′)→ a = a′ ∧ s = s′ Ind : ∀φ.(φ(S0) ∧ (∀a.φ(s)→ φ(Result(a, s))))→ ∀s.φ(s). which determine equality of situations, relative to equality of events or actions. These axioms are categorical, that is relative to an interpretation of equality of actions, there is a unique model of situations. Rather than use these axioms, which state that no other situations exist between s and Result(a, s), we choose to say that situations can be ordered by a < predicate, which is a strict partial order, which we axiomatize as follows. ∀a, s.s < Result(a, s), ∀s, s, s.s < s → ¬(s < s), ∀s, s, s, s.s < s ∧ s < s → s < s (1) The predicate < is similar to the future(s, s) predicate, introduced by [MH69], which is true when s is in the future of s. We find it useful to write this in infix notation, and to use s ≤ s as the non-strict version. It also is useful to write s ≤ s ≤ s for s ≤ s ∧ s ≤ s. 4 SPECIFYING THE EFFECTS OF EVENTS In the situation calculus it is usual to specify the effects of actions by writing effect axioms, like10, ∀s.Holds(Loaded , s)→ Holds(Dead ,Result(Shoot , s)). If we move to a formalism that allows other events to occur between s and Result(e, s), then this way of specifying change needs to be adjusted. It is possible that something might occur in the time between s and Result(Shoot , s) that causes the event to have a different result. For this reason it seems natural to allow the preconditions, those things that hold on the left hand side, to mention properties of all times between s and Result(Shoot , s). In previous versions of the situation calculus the preconditions for an event were always modeled as a set of fluents, namely those fluents that had to hold at s, for the event to have an effect at Result(a, s). If we allow other things to Reiter’s notation differ from ours, he uses do(a, s), while we use Result(a, s). We use≤ s′ as a shorthand for s < s′∨s = s′. Reiter writes < as <. As is customary in Logical A.I. we write Holds(Dead , s) without saying who is dead. We can suppose the events occur in a context and lifting rules exist to make this Dead(V ictim) in an outer context. The outer context may contain further preconditions, like that shooter is present. happen during an event, we cannot just specify the preconditions that must hold at the beginning of the event. Consider a plane journey from Glasgow to London. It is necessary that the plane be in working order for the entire flight. It is also necessary to be in Glasgow at the beginning of the flight, but clearly, there is no need for this precondition to persist for the entire flight. It is necessary to have a ticket, until the airline steward takes it from you. This is an example of a precondition, “having a ticket” that must hold neither just at the moment the event starts, nor for the entire duration. Consider another example from the Yale Shooting Problem. In order to successfully shoot a person, the gun must be loaded when the trigger is pulled, but the target must remain in the cross-hairs until the bullet hits. We represent the fact the target is in the cross-hairs by aimed. Thus we write: ∀s.Occurs(Shoot , s) ∧Holds(Loaded , s)∧