IEEE TRANSACTIONS ON PATTERN ANALYSIS AND MACHINE INTELLIGENCE, VOL. PAMI-5, NO. 3, MAY 1983
Contexts and Data Dependencies: A SynthesisDREW MCDERMOTT
Abstract-Two data-organization devices that have come out of Al re-search are data pools ("contexts") and data dependencies. The latterare more flexible than the fonner, and have supplanted them. Datapools offer certain advantages of efficiency, however, so it is worthtrying to make the two mechanisms compatible. Doing this requiresgeneralizing the mark-and-sweep algorithms that maintain consistencyin a data-dependency network, so that the labels passed around do notsimply say whether a datum is IN or OUT, but say which data pools it ispresent in. The revised algorithm is essentially an algorithm for solvingsimultaneous Boolean equations. Other mechanisms are needed for per-forming useful chores like maintaining well-founded support links andorchestrating demon calls.
Index Terms-Al languages, contexts, databases, data dependencies,logic, theorem proving.
I. INTRODUCTIONT HE programming languages Conniver [20] and QA4 [1],
[18] had devices called contexts for keeping track ofmultiple databases of predicate-calculus formulas, or "asser-tions." Typically, each database was intended to represent ahypothetical state of affairs, whose plausibility or desirabilitywas to be checked [7]. In recent years, contexts have beenneglected, partly because they have been supplanted by datadependencies [2], [5], [19] which give a more detailed pic-ture of the reasons for belief in the facts in just one database.In this paper, I will show how the two concepts can be puttogether in a way that gives us the advantages of both. FirstI will explain each concept, then put them together.
A. Data PoolsI will use the phrase data pool instead of "context" from
now on. This is mainly because the notions of context inConniver and QA4 were rather different, so we might as wellcall them two different things.' A data pool is a view of adatabase, in which only a subset of the data are visible. I willuse examples in which the databases are the assertional PLAN-NER [8], [9] variety, but any kind will do, so long as there is
Manuscript received September 18, 1981; revised November 14,1982. This work was supported by the National Science Foundationunder Grant MCS-8013710.The author is with the Department of Computer Science, Yale Uni-
versity, New Haven, CT 06520.1The difference was this: QA4 used contexts for backtracking.
When a failure was encountered, its interpreter would return to themost recent context which still had a choice. This meant the contextswere used to keep track of the state of the interpreter as well as thestate of database. Conniver did not backtrack, and left the database'scontents to the user. The Conniver implementation therefore suppliedprimitives to allow the user to create contexts in various ways. TheQA4 implementation did not let users access contexts. Its use and con-straints made it possible to force contexts to grow in a tree structure.
some kind of identifiable datum, such as a link between twonodes, or a tuple in a relational database. I will use the wordassertion to refer to such a datum. In most respects, datapools are like modifiable sets of assertions, but they are imple-mented in such a way that it is cheap to copy a pool. The re-sult of this copy operation has all the assertions of the original,but later changes to the original will be seen in the copy. (Wesay the copy continues to "inherit" changes to the original.)For example, the initial data pool DP1 might contain the
assertion A 1 = (SALARY JOHN-SMITH 20K). We can copyDPI, giving DP2. The same assertion is visible in DP2. If weadd A2 = (STOCK-OPTIONS JOHN-SMITH) to DP2, it will notbe seen in DPI. This copy operation is often called pushingDPI down, giving DP2.Formally, I define a data pool as a pair (b, S), where b is a
natural number, and S is a set of natural numbers, such that bis an element of S.A database is a set of assertions. As I said above, an asser-
tion may be thought of as a predicate-calculus formula,capturing the content of a belief, but the actual content isirrelevant.A labeling is a function assigning to each assertion in a data-
base a Boolean combination of natural numbers, called thelabel of the assertion in that labeling.We think of the natural numbers as Boolean variables, taking
on values from the set {IN, OUT}. IN plays the role of 1, OUTthe role of 0. I use the term bead to refer to a natural numberused this way, and denote them bO, bl, b2, - * . The set S ina data pool plays the role of a valuation. A bead is IN with re-spect to a pool (or just "IN the pool") iff it is an element ofS.The distinguished bead b of a data pool is called its character-istic bead.The status of an assertion with respect to a data pool and
labeling is the value of its label with respect to S of the datapool. That is, to find the status of an assertion, we evaluate itslabel, letting every bead in S be IN and all others be OUT.We suppose that a program using the database always has a
"current data pool" kept in some register; and a "currentlabeling" implemented by pointers from the data structuresrepresenting assertions. If I say an assertion is just IN or OUT,without mentioning the data pool or labeling, I mean the cur-rent ones.The intent of the names IN and OUT (originally due to
Doyle [5] ) is this: the database machinery is supposed to hideOUT assertions from the program using the database, so thatthey are invisible. By changing the current data pool (which issimply a matter of resetting a register), we can change thecontents of the database. Intuitively, the currently IN asser-
tions are those the program believes, or is entertaining thepossibility of. OUT assertions are those the program does notbelieve to be true (and may or may not believe to be false).To copy, or push down, a data pool (b, S), we simply take
an unused bead, b' and create (b', S U {b'}). Since b' is new,all assertions have the same status in the new pool as the old. IfP2 is derived from P1 via a series of push-down operations,that is, if P2's bead set is a superset ofP l's, then P2 is said tobe a subpool ofPI.To add an assertion to a data pool, we change its label fromto I V b, where b is the characteristic bead of the pool. This
makes its status IN with respect to that pool. This shouldsuggest how to erase as well, but let us postpone defining thatformally for a while.To illustrate all this, I will give an example of the sort of
bookkeeping data pools are for. The example will be drawnfrom a (fictitious) political reasoning system. Suppose thatthis system has a data pool describing the current state of po-
litical affairs, and it is wishes to compare two possible out-comes of the next election. In one, McMoron wins, in theother, Simpleton. It pushes the top4evel pool down, twice,producing two new subpools. In one, it asserts
A 1: (IS-PRESIDENT MCMORON)
In the other, naturally, it asserts
A2: (IS-PRESIDENT SIMPLETON)
The state of affairs is shown in the top of Fig. 1. The originalpool consisted of bead bl6. The two new ones have character-istic beads b17 and b18. That is, A 1 is labeled with b17;A2,with b 18.Assume the program then devotes resources alternately to
one pool and the other. In the first, it deduces (using rulesabout Presidents and McMoron) the effects of McMoron beingelected. In the second, similar conclusions are drawn aboutSimpleton.Suppose in the midst of its meditation, the program decides
to think about the possibility of a war in El Salvador shouldMcMoron get elected. It pushes McMoron's data pool down,creating two new subpools, with characteristic beads bl9 andb20. In one, it is asserted that there is such a war; in theother, that there is not.Copying a pool a few times, then copying each copy, and so
forth, is a common operation in programs that use data pools[7], [12]. The result is a tree of data pools (Fig. 1). Eachnode of the tree represents a different hypothetical worldstate. Notice that the mechanism is useful only if more thanone branch of this tree is active at a time, that is, the programusing it often suspends thinking about one branch temporarily.If a database was always created, used, and discarded (i.e., ifthe tree of Fig. 1 was traversed only in depth-first order), wecould simply make permanent changes (additions and erasures)to one main database.Examples like those of Fig. 1 seem to imply that each data
pool is equivalent to the union of the assertions labeled witheach of its beads. An obvious alternative way of implementingthis sort of structure would be to have separate, "incremental"databases. Instead of each bead, we would just have an incre-mental database of the assertions labeled with that bead. A setof incremental databases could then be used the way the set ofbeads is used in the data pool system. (Rieger [17] describesone way of doing this.) An assertion would be IN if it werefound in at least one of the currently active incremental data-bases. One of them would be designated the "characteristicdatabase" of the pool; adding an assertion to a pool wouldmean adding it to the characteristic incremental database.One problem with this scheme is that a database must be
implemented as an index that enables us to find an assertiongiven a partial description of it. (In the predicate-calculuscase, this is typically a pattern that matches it.) The programwould have to repeat this index search once for every incre-mental database. In the current approach, we do the indexsearch once, then filter the assertions found to discard theOUT ones.The other problem is that it is not clear how you would
erase an assertion from a data pool in this approach (unless theassertion was found in the characteristic database). The datapool scheme handles this easily: to erase an assertion from adata pool, we change its label from I to l A -b, where b is thecharacteristic bead of the pool.For instance, in the example of Fig. 1, we erased (IS-PRES-
IDENT REAGAN) from the two topmost subpools (to avoidhaving two presidents). It was erased by changing its label tobl6 A -bl7 A bl8.Since labels are Boolean expressions, IN and OUT are them-
selves legal labels. Anything labeled IN is, of course, present inall data pools. Anything labeled OUT is absent from all ofthem. In practice one would attempt to erase assertionslabeled OUT from the database altogether, and reclaim theirstorage, since they can never be accessed.This mechanism is essentially that used in Conniver [20],
except that the original scheme restricted the allowed Booleancombinations of beads in assertion labels. The labels werestored in disjunctive normal form, that is, as disjunctions ofconjunctions of possibly negated beads. Each conjunction
238
MC DERMOTT: CONTEXTS AND DATA DEPENDENCIES
(WEAK CENTER)
(GOOD-MOVE (CASTLE K))
(NOT (ATTACK OPP K))
Fig. 2. A data dependency.
could have exactly one unnegated bead. This was the charac-teristic bead of the data pool to which the assertion was added.Any negated beads were of subpools from which it was re-moved. Since these were the only label-forming operations,the restriction did no harm. We wrln need the liberalizeddefinition below.
B. Data DependenciesIn the past five years, a new database management technique
has gained a lot of popularity in A l [10], [19], [21 ]. This isthe idea of keeping track of the reasons for every belief of areasoning program. For example, a chess program might notethat it should castle kingside, because its center is weak andthere is no kingside attack by its opponent. It adds the con-clusion to the database, along with its support, or justification,as shown in Fig. 2.
In Fig. 2, the parenthesized formulas are assertions, the cir-cles "justifications."A justification is a tuple-
(in-justifiers, out-justifiers, justificand)
where justificand is an assertion, and in-justifiers and out-justifiers are sets of assertions. The intent is that belief in theelements of in-justifiers, plus nonbelief in the elements of out-justifiers, is sufficient to justify belief in justificand. Thegraphical representation (as in Fig. 2) is a circle with linesdrawn from the justifiers to the circle, and an arrow from thecircle to the justificand. The in-justifiers are labeled with "+"the out-justifiers with "- ." In Fig. 2, there are two in-justifiersand no out-justifiers.A program using this system maintains a current justification
set, intuitively, the set of all deductive relationships it hasdiscovered so far. The set of all justifications with justificandA in the current set are called the justifications ofA.The current justification set then determines a status, IN or
OUT, for each assertion in the database, as I will discuss in thefollowing.
If we ignore its out-justifiers component for a moment, ajustification can be thought of as a record of the proof of itsjustificand. Keeping track of such proofs has several advan-tages. The program can explain its inferences by printing outtheir supports. If (NOT (ATTACK OPP K)) is erased, the pro-gram will also know to erase (GOOD-MOVE (CASTLE K)). Ifanother line of reasoning leads to (NOT (GOOD-MOVE (CAS-TLE K))), the program can trace backwards to see whatassumptions were at fault.The whole system is made much more useful by the pres-
ence of the out-justifiers, which make the system nonmono-tonic. [5] An assertion can be believed, or IN, because someother assertion is OUT. For example, our chess program mightreason that if it cannot see a kingside attack, then there is not
(ATTACK OPP K) 0 (NOT (ATTACK OPP K))Fig. 3. A nonmonotonic data dependency.
one. This would get recorded as the justification ({}, {(AT-TACK OPP K)}, (NOT (ATTACK OPP K))), represented graph-ically in Fig. 3. The minus sign indicates that (NOT (ATTACKOPP K)) iS IN whenever (ATTACK OPP K) iS OUT. As soon aswe detect such an attack, (NOT (ATTACK OPP K)) ceases to bejustified, and hence (Fig. 2) so does (GOOD-MOVE (CASTLEK)).To make this work, there must be a program that computes
the statuses of assertions given a justification set. This iscalled the reason maintenance system (RMS).2The RMS finds a consistent and well-founded assignment of
statuses, IN or OUT, for all the assertions in the database. Astatus assignment is a function L that maps every assertion inthe database into {IN, OUT}. I will use the phrase value ofAin L as a synonym for L (A). We can extend the function tojustifications by defining L ((in, out, A)) to be the conjunctionof the values L assigns to the in-justifiers and the negations ofthe values it assigns to the out-justifiers. (Let me remind youthat the concepts of "conjunction," "negation," etc. are withrespect to a Boolean algebra in which IN = 1 and OUT = 0.IN/OUT values are not the same as truth values. IN corre-sponds to "believed true," but OUT corresponds to "notbelieved true," which is different from "believed not true.")A status assignment is consistent if the status it assigns to
each assertion is equivalent to the disjunction of the statuses itassigns to its justifications. (That is, it is IN iff at least one ofits justifications has all its in-justifiers IN and all its out-justi-fiers OUT.)An assignment is well founded if there is no strictly ouTer
consistent assignment. An assignment L 1 is strictly ouTerthan another L2 if every assertion's value in L 1 subsumes itsvalue in L 2, and at least one assertion's value in L 2 does notsubsume its value in L1. V1 subsumes V2 if Vl is OUT orV2 iS IN.
A premiss is an assertion A with a justification of the form({ }, { }, A) in the current set. A justification of this formis called a premiss justification; anything it supports must beIN under any assignment.
Intuitively, an assignment is well-founded if every IN asser-tion is supported by a noncircular chain back to OUT asser-tions and premisses. To appreciate this point, suppose that anassertion has value IN, but there is no such chain. Then wecould change this assertion (and, to maintain consistency,some of its justifiers, and so forth) to OUT, producing a strictlyOUTer assignment.
2The term is due to Doyle [61. A good name for this program hasbeen -hard to find. Doyle, who wrote the first general-purpose RMS,originally called it the "Truth Maintenance System" [51, a term appar-ently coined by Sussman (Doyle, personal communication). This nameis obviously unsatisfactory. In [ 21, we called it the "database garbagecollector" (DBGC), because of its role in hiding OUT assertions, and be-cause it resembles traditional garbage collectors in superficial ways. Butthe name DBGC implies that the program reclaims storage, which itdoes not. I hope workers in this field can now agree on "reason main-tenance system," which indicates the important role the program playsin keeping track of the reasons for its beliefs. It is not clear whetherthe program described by McAllester in [III can be described by thisphrase, although it addresses many of the same issues.
239
IEEE TRANSACTIONS ON PATTERN ANALYSIS AND MACHINE INTELLIGENCE, VOL. PAMI-5, NO. 3, MAY 1983
bl
+ ASSERTIONb3
b4
Fig. 4. Data pool label as justification.
0 > bl7 %X_ o A1
Fig. 5. Data dependency simulation of a data pool.
b17 +
Al1
b18
Fig. 6. Simulating removing an assertion from a data pool.
The user ultimately controls the state of the data base byadding and removing justifications, including those of pre-misses. After each such change, it is the responsibility of theRMS to find a consistent and well-founded status assignment.There is an obvious resemblance between data pools and
data dependencies. (It was first pointed by Stallman andSussman [19].) If we think of a bead as a premiss, then thelabels on data are a kind ofjustification. In particular, a labellike bl V (b3 A -b4) may be thought of as two justifications(Fig. 4). To see the correspondence, put the label in disjunc-tive normal form, then translate each disjunct into a justifica-tion in the obious way, in-justifiers for beads, out-justifiers fornegations of beads.The "current data pool" is defined by the beads that are
premisses under the current justification set. We also designateone bead the "current characteristic bead," as before.As a more detailed example, consider the McMoron data
pool I described in the previous section. As before, suppose"bl 7" is the current characteristic bead. We can make "bl 7"a premiss supporting (IS-PRESIDENT MCMORON), as shown inFig. 5. Subsequent deductions from this assertion are alsolabeled with bl7 as a premiss. Everybody becomes invisiblewhen the premiss justification of bi7 is removed from thejustification set.We can erase an assertion from a data pool by altering each
of its justifications to depend negatively on the characteristicbead of the pool.3 For example, if bl8 is the characteristicbead, we remove assertion A 1 of Fig. 5 by changing its justifi-cation as shown in Fig. 6. A 1 is now IN the original pool, butOUT of the one with b18.So data pools are formally equivalent to a special case of
data dependencies. The two mechanisms are implementeddifferently, however, so they have different efficiencies.Switching data pools requires changing the state of each beadinvolved. Changing premisses requires an RMS call that ex-
amines every datum whose state might change. (This will beclear after the next section, cf. [2].) So if there are several
3Technically, we are changing the current justification set, not chang-
ing a justification.
data per bead, the RMS is more expensive. It is especially ex-pensive if there are "external" costs to be paid every time anassertion switches status. For example, if the assertions arekept in an index as I mentioned in Section I-A, then they mustbe deleted from the index and put back repeatedly as theirstatuses change. (The mechanics of getting this done are de-scribed below, in Section Ill-C.) Such costs are likely to beincurred repeatedly by programs that search trees like that ofFig. 1. As I mentioned before, such searches of alternativehypothetical world models are quite common (cf. [71, [12]).On the other side, data dependencies are more powerful.
Justifications can relate data to each other as well as to beads.In an old-fashioned bead-based system, all the new data de-duced in a data pool get tagged with its characteristic bead (asin the McMoron example). This makes it easy to discardeverything peculiar to a pool, by discarding its characteristicbead. It makes it harder to retain things that were discoveredduring the tenure of a data pool, but do not depend on it. Inthe data-dependency system, this comes easy; new conclusionsare justified by the data that support them, regardless of whichpremiss was assumed most recently. There is no "characteristicpremiss" of the current constellation. Premisses and assump-tions can change in any order, regardless of their history, andthe RMS will maintain consistency of the database. This hasled to interesting new programming styles, like "dependency-directed backtracking" [19].4For example, if in reasoning about McMoron's first term we
conclude that the energy crisis will lead to a depression, wewould like this conclusion to stick around even after we switchto reasoning about McMoron's opponent. In the old Conniver-style system, the depression would have to be rediscovered(unless special precautions were taken).5
II. PUTTING THEM TOGETHER
A. The IdeaWe can get the best of both worlds, flexible status computa-
tion and fast context switching. What we do is combine theidea of labeling with the idea of explicit justification: everyassertion will have both a label and a set of justifications. Thejustifications give a local record of support for an assertion.The label says which data pools the assertion is in.For example, look at the dependency network of Fig. 7. A
and B are assertions; bl and b2 are beads. I will use the termnode to mean either an assertion or a bead. As before, a smallcircle represents a justification. We do not count them asnodes. We must modify the definition ofjustification to allowin-justifiers and out-justifiers to be sets of nodes, that is, beads
4I should point out that the data pool and data dependency schemesboth suffer from the "filtering problem." This is that an OUT datumhas to be seen and discarded by some module somewhere. So the timefor the data management system to retrieve all assertions correspondingto a given key does not depend on the number retrieved, but on thetotal number of assertions in the database that match that key, whichcould be much larger [31.50f course, the newer systems work properly only if every scrap of
evidence leading to a conclusion is recorded explicitly. If the conclu-sion is arrived at by an arbitrary computation, it may be hard to gatheror represent all the reasons for believing things. So they may fail to beerased when they should. These issues have been explored by the MITgroup over the last five years [61.
240
MC DERMOTT: CONTEXTS AND DATA DEIPENDENCIES
[bl or -b2][b2]
[bl]
Fig. 7. A labeled dependency network.
and assertions. The justificand of an assertion is always anassertion.The expressions in brackets are the labels on nodes. As in
Section I-A, the label is a Boolean combination of beads. Inthe figure, A is IN if bl is IN or b2 is OUT. B is IN only if b2iS IN.
The label on a bead is just that bead itself. All other labelsare computed by a generalized RMS, instead of being suppliedby the user. At any given moment, the user supplies a currentdata pool as defined in Section I-A, and a current justificationset, as defined in Section I-B. The current labeling is com-puted from the justification set. The status assignment is com-puted from this labeling and the current data pool.Another way to state this is that a label gives the status of a
datum in all possible data pools. In Doyle's original algorithm,the label was never explicitly computed; status assignmentswere determined directly from the justification set. The sta-tuses had to be recomputed every time the pool was switched.The new version summarizes all these computations at once.In the figure, there are four combinations of bl and b2 beingIN or OUT.
bl b2 A B
OUT OUT IN OUT
OUT IN OUT IN
IN OUT IN OUT
IN IN IN IN
Notice that A and B cannot both be OUT. (The properties ofthis kind of dependency structure were first examined byDoyle [5 ].) So the interesting case is when bl and b2 are bothOUT. The given labeling selects A to be IN in this case. Thereis another labeling that selects B instead.The goal of the generalized RMS is to find a consistent and
well-founded labeling. These can be defined analogously tothe definitions of consistent and well-founded status assign-ments in Section I-B.Consistency now means that the label on a node is equiva-
lent to the disjunction of the labels on its justification. Thelabel of a justification is the conjunction of the labels on itsin-justifiers and the negations of the labels on its out-justifiers.These definitions now refer to conjunction, negation, equiva-lence, etc. of Boolean expressions rather than IN/OUT values.Similarly, I define well-foundedness of a labeling the way I
defined well-foundedness of a value assignment, in terms ofthe "strictly oUTer" relation: a labeling of a network is wellfounded if there is no strictly ouTer consistent labeling. Alabeling L1 is strictly ouTer than another L2 if every node'slabel in L1 subsumes its label in L2, and at least one node's
=A B
Fig. 8. Circular network.
b2
+ -A
B
b2
Fig. 9. A network fragment.
label in L2 does not subsume its counterpart in L 1. ForBoolean expressions, subsumption is defined thus: the Booleanexpression El subsumes another E2 if for every valuation,either the value of El is OUT in that valuation, or the value ofE2 is IN.For example, consider the network of Fig. 8. If we let A
and B stand for their labels, then consistency requires that A= B. The only well-founded labeling is A = B = OUT, which isstrictly ouTer than, say, A = B = bl. This is because OUTsubsumes bl, and bl does not subsume OUT.The other labeling for Fig. 7 is A = bl, B = b2 V -bl. Nei-
ther labeling is ouTer than the other, since b2 V- bI doesnot subsume b2, and bl V -b2 does not subsume bl.Now all we need is an algorithm for finding labelings. We
get one by thinking of the problem as the solution of a set ofsimultaneous Boolean equations. For each assertion, we makeup a variable to stand for its label, to be determined. In sche-matic figures, I will use the same letter to stand for the asser-tion and the unknown. In the initial set of equations, thisunknown will be set equal to a disjunction, with one disjunctper justification. Each disjunct is a conjunction, with oneelement per in-justifier and out-justifier. A bead appears asitself, while an assertion appears as its unknown. The out-justifiers are, of course, negated.
If n assertions are involved altogether, we will have n equa-tions in n unknowns. The goal is to solve for the unknowns interms of the beads.So, for example, the fragment of network in Fig. 9 gives us
an equation
A = b2 V (-b2 AB).
The first disjunct comes from the lower justification; thesecond, from the upper. The second occurrence of b2 isnegated because it appears as an out-justifier. This equationthen simplifies to
A = b2 V B.
Another example is the graph of Fig. 7, which gives equations
A =bl V- B
B = b2 V -A.
(1)(2)
241
IEEE TRANSACTIONS ON PATTERN ANALYSIS AND MACHINE INTELLIGENCE, VOL. PAMI-5, NO. 3, MAY 1983
A B
Fig. 10. Odd loops.
Let us solve this by substituting A from (1) into (2), togive
B = b2 V-(bl V-B)
=b2V(-bl AB).
This equation has the solution B = b2. Substituting back into(1) givesA = bl V - b2, the labeling given in that figure.
It turns out that this is all there ever is to it. To prove this,we need to invoke one further constraint on dependency net-works. We assume that a network contains no odd loops, no
loops in which an odd number of minus signs occurs, such as
that of Fig. 10. A loop in a justification set is a sequence ofjustifications (JO, J, - X Jn-l ) such that the justificand ofeach Ji appears as a justifier of Ji1+ (mod n) If the justificandof Ji appears as an out-justifier of Jis+1 there is a negative linkbetween them, else a positive link. A loop is odd if the num-ber of negative links in the loop is odd. As explained in [2],such a loop could signify that an assertion's being OUT was
sufficient reason for it to be IN. If such loops exist, then some
networks will fail to have consistent labelings, and the problemof finding a labeling becomes NP-complete. The standardpractice is to forbid them.Since odd loops are forbidden, then whenever a substitution
of variables in an equation set derived from a network resultsin an equation of the form
A =f(A)
then f is monotonically increasing in A. That is, if you ever
get an equation that looks like
A = ..* A ...
the A on the right occurs inside an even number of "-" 's. Sof(A) can be put into disjunctive normal form, to give
A =C1 VC2 V ... VCn VD, V * *VDm
where A occurs in the Di but not in the Ci. By factoring theA 's out, the equation can be put in the form
A =CV(A AD)
where C andD are disjunctions that do not include A.This equation may have more than one solution, but it al-
ways has the solution A = C. So we can solve the whole setof equations by repeated substitutions. The algorithm is topick any equation A = E, and use it to eliminate A from allthe other equations. If A occurs in E, then E = C V (A A D),where A does not occur in C or D; we substitute C for A in allthe other equations. IfA does not occur in E, we substitute Efor A in all the other equations.Obviously, the result of this algorithm is a consistent labeling.
It remains to show that it is well founded. The only way well-foundedness could fail is if some solution to an equation A =
s2+A
a3 \
a44C
b2 +B
b3M
b4 +
Fig. 1 1. Large labels.
C V (A AD) were ouTer than A = C. But, letting f(A) = C V(A AD), A = C corresponds to the solution A = f(ouT). Sincef is monotonic in A, any other solutionA = e wfll be subsumedbyA = C, because OUT subsumes e, and hence f(ouT) = C sub-sumes f(e) = e. So A = e is not strictly ouTer than A = C. Infact,A = C is the ouTest possible solution to this equation.
Finally, it is obvious that the algorithm will always halt,since every substitution leaves one less variable. So we haveproved the following theorem.The Boolean substitution algorithm always halts and finds aconsistent, well-founded labeling of a dependency network.The complexity of this algorithm may be analyzed as fol-
lows: in the worst case, it does n2 substitutions. This occurs ifevery assertion is connected directly to every other assertion,which is not likely. Furthermore, n is not equal to the size ofthe whole database, but to the number of assertions thatcould conceivably change when a justification is added or de-leted. When an assertion is added for the first time,n will be 1.McAllester has pointed out (personal communication) that
in some circumstances the labels on assertions can grow expo-nentially with the depth of their well-founded support. Ifthe label on A is (al A a2) V (a3 A a4), in disjunctive nor-mal form, and the label on B is (bI A b2) V (b3 A b4), and Cis supported byA AB (Fig. 1 1), then the label on C is
(al Aa2 A bl A b2)
V (alAa2Ab3Ab4)
V (a3Aa4AblAb2)
V (a3Aa4Ab3Ab4)
In the worst case, this would not simplify very much. In fact,in the implementation described below, the algorithm actuallydoes use disjunctive normal form, although that is irrelevant;the exponential explosion would occur somewhere, in storagespace or processing time or both.However, I do not expect the worst case to occur very often,
for two reasons. First, it only happens for assertions taggedwith a lot of different beads. In my experience, any givenassertion is associated with only one or two beads. So disjunc-tions will often be easily simplified. Second, the problemarises only if there are many different proofs of an assertion,giving rise to many disjuncts at the end. If this is rare, disjunc-
242
MC DERMOTT: CONTEXTS AND DATA DEPENDENCIES
tions will not occur to begin with. If it is common, then myalgorithm, which attempts to foresee all possible data poolsthat can be built out of existing beads, will be swamped. Myexpectation is that the cost of keeping track of bead combina-tions that will never actually arise will in practice be much lessthan the cost of switching assertions IN and OUT repeatedly.
B. Deductive ChainingIn a system with no data dependencies, forward chaining
works thus: if A and A -+ B are ever asserted simultaneously,then B is asserted. (Usually only some implications aremarked as being handled in this way.) In a data-pool system,B is asserted in the current data pool.Data dependencies present certain problems, because an
assertion can be indexed and still be OUT. So we have to de-cide when exactly to assert B. The usual decision [2] is toactually index and assert B only when both A and A -+ B bothcome IN.The generalized algorithm I have described has an even more
delicate problem, since the data-dependency system is nowone step removed from assigning an assertion IN or OUT status.What we want to avoid is this approach: when A is assertedwith label 11, and A -*B is asserted with label 12, then B isasserted with justification ({A,A - B}, { }, B) and hencelabel 11 A 12. The problem is that A and A -+ B may be presentin unrelated data pools, and the label 11 A 12 may never evalu-ate to IN in any likely data pool. Furthermore, this useless Bwill now interact with things like Be- C to generate moregarbage assertions. In fact, this approach amounts to makinginferences in all possible data pools, in anticipation of theiractually coming into existence.The solution is to wait until an assertion has been seen in at
least one data pool before indexing it and doing further chain-ing. Whenever B is deduced with a given label, and that labelevaluates to OUT in the current data pool, there must be a setof beads, one per disjunct of the label, whose absence or pres-ence is making the label OUT. It is not worth thinking aboutB again until one of those beads changes state. So we attachB to each such blocking bead as a latent assertion. These arechecked every time a bead leaves or enters a data pool. If thistransition causes a latent assertion to become present, theassertion is indexed and chained from. Otherwise, there mustbe a new set of blocking beads, and the latent assertion isshifted to them.This solution is potentially costly if many latent assertions
get shifted from bead to bead without getting asserted veryoften. For this to happen, there must be a pair of beads suchthat the pair is rarely in the current data pool, but each beadgoes in and out frequently, and some inference depends onboth. This is rare, I believe. One way it could arise is this:say a program was comparing two hypotheses, whose conse-quences were represented by two different data pools. In one,it might have the hypothesis, "Everything in BOXl is green."In the other, it might have, "Blockl is in Boxi." The infer-ence "Blockl is green" would remain latent, and would haveto be checked every time a data-pool switch occurred. For a
blo 3AX- 1B
b2
b2
Fig. 12. An example.
III. THE ACTUAL ALGORITHM
A. Description of the ProgramThe actual Lisp algorithm used is an optimized version of the
Boolean-equation algorithm. We do not bother to write out allthe equations at once. Instead, as in Doyle's original algorithm,we first sweep forward from an added or deleted justification,setting the labels of possibly affected assertions to *UNKNOWN.Then we sweep forward again, assigning labels. If an assertion'slabel depends on another assertion whose label is not yetknown, then it is assigned a provisional label containing theunknown assertion. In this way, we can calculate the newlabel on an assertion A, and discover that it depends on itself,A =f(A). In this case we let the new label bef(ouT); sincefis monotonic, f(f(ouT)) =f(ouT), as explained above. Everytime a label is assigned, it is substituted into the labels of allthe assertions that depend on it.For example, in Fig. 12, say that the new justification is the
one involving bl . We sweep forward, clobbering A, B, and Cto *UNKNOWN. Then we label the nodes in this order:
A <-bl VBB -(b2 AA)Vb2 VC= b2 VC
[The algorithm puts labels into disjunctive normal form,then simplifies by removing disjuncts that subsume anotherdisjunct, as b2 A A subsumes b2 here.]A -<bl Vb2VC
[by back substitution ofB]C b2 V C and hence C <- b2B -b2A v-bl Vb2
[by back substitution of C]
Notice that a loop, as at B, cannot always be detected by thearrival of a self-referential label. Simplification eliminates thereference to B before B's label is computed. So you alwayshave to do back-substitution.
B. Timing DataI did a few casual experiments to see how fast the code ran.
The program was written in ILISP [16] for a DEC 2060. Thecode was compiled and subroutine calls had been optimized;calling a subroutine required no property-list lookup.The experiments were done by setting up 200 nodes, such
that each supported the next, but number 99 supported num-ber 100 by being OUT. The initial equilibrium label assign-ment was nodes 0 through 99 OUT, nodes 100 to 199 IN.
Adding an always-IN justification to node 0 brought 0 through99 IN and sent 100 through 199 OUT. This took 65 ms and606 CONSes, or about 0.3 ms per node and 3 CONSes per
major inefficiency to result, this would have to happen a lot.
243
node. The complete list of experiments foflows. They were
IEEE TRANSACTIONS ON PATTERN ANALYSIS AND MACHINE INTELLIGENCE, VOL. PAMI-5, NO. 3, MAY 1983
done in this order, so the state ofprevious test. The first few comeand then undo it.
AddedJI ("IN") tO 0:
Deleted JI from 0:AddedJ4 ("199 OUT")to 0, introducinga cycle:
Deleted J4 from 0:AddedJ2 ("bead 2 IN") to 0:Added J4 to 0 (cycle):Added J3 ("bead 3 IN") tO 199:Deleted J4 from 0:The algorithm does worst when it hloop, as in the penultimate expertransaction, nodes 0 to 99 wereBEAD3)) Nodes 100 to 199 werecates the structure of Fig. 7, withIn the other cases, the labels were aThe complexity of the final labe
45 CONSes done in this case. Bulan average of 6 CONS cells. Thebe avoided (if necessary) by morethe label computations on a stacshown do not included any garbajinto account, one can assign so0.1 ms of garbage collection per CC
C. Other DetailsThroughout this paper, I have be
tions represented predicate-calculiearly on that this was only for conat this level has no idea what themally, this will not matter. For ir"data pool-relative" by flagging e;"assertion," and writing utility fuelements while ignoring its OUT 0Obecause each element is gated bystance, a program might keep a gatrying in a situation. The element!cations attached, so that thingstrying will be labeled OUT and igstract assertion for a given heuristibut that we do not actually have tthe heuristic visible in this list makeExamples like these illustrate t]
viewed differently by the data-delthe higher level system that is reslthe assertions. Let us call this highresentation" (KR) level. The KR-lto the DD system by adding and rthe current set. The DD system iby setting the labels, and hence iituses, of the assertions. The KItagged data structures.Sometimes we want more inforn
each test is that left by the For instance, we might want to print an error message if ain pairs that do something node representing contradiction is ever IN in any known data
pool. Or, in a gated-list application, we might want an element
0.3 3 CONSesto actually be deleted from the list if its label becomes a con-
0. emsper oNes stant OUT (i.e., it is visible nowhere). This kind of interface isnode, 3per node arranged by allowing the KR programs to attach a signalfunc-
03 tion to an assertion. Whenever the label has changed after anRMS call, the signal function is called, with the old label and
0.7 10new label as arguments. (This idea was first used in the imple-
0.3 3 mentation of Doyle's system [5].) This device allows arbitrary0.3 communication between the two levels without compromising0.4 the modularity of the DD system.1.0 17 In Section I-B, I mentioned that Doyle's algorithm produced
2.5 5 a well-founded assignment of labels to assertions, meaning that0.4 5 every label could be justified ultimately in terms of premisses
tas to contend with the long and OUT assertions. I failed to mention how important thisiment. At the end of this was to the operation of his algorithm and to user algorithrmslabeled (OR BEAD2 (NOT that referred to the database. As explained in [21, Doyle'slabeled BEAD3. This dupli- algorithm propagated tentative labels through the network. As
i a loop 200 elements long. it went, it recorded not just the new label, but the well-lways TRUE or FALSE. founded support that went into it. This was defined as a set ofls accounts for some of the assertions whose labels were sufficient to determine the statust the actual labels take only of the justificand. If the assertion was tentatively labeled IN,39 reclaimed CONSes could its well-founded support would be all the nodes in an appar-a complex algorithms to do ently satisfied justification. If the assertion was tentatively,k. In any case, the times labeled OUT, its well-founded support would be one "unsatis-ge collection. To take that fied" assertion, an in-justifier labeled OUT or an out-justifierime plausible number like labeled IN, for each justification.)NS on the average. These well-founded support notes attached to each assertion
were important, because the tentative labels could be upset.The only way an upset could occur would be if a guess that a
Den assuming that the asser- justifier was OUT turned out to be wrong. This could affectas propositions, but I said only the assertions of which the mislabeled node was a sup-icreteness. In fact, the code porter. So the algorithm would scrap label assignments of^ assertions represent. Nor- supportees of a assertion whose label changed from OUT to IN.istance, a list may be made The algorithm I have described does not need these notes.ach of its elements with an Whenever an assertion is assigned a label, this label is substi-nctions that process its IN tuted for all occurrences of the assertion as a Boolean un-nes. I call this a gated list, known in the network. But the well-founded support notesits assertion label. For in- were just as important to user algorithms as to the databaseited list of heuristics worth package itself. These notes summarized a messy graph of datas of this list can have justifi- dependencies as a tree, since from each IN assertion you couldnot deduced to be worth trace back a clean, loop-free line of support, which would,nored. Notice that the ab- ultimately lead to premisses and OUT nodes. This was handyic is "This is worth trying," for generating explanations of things, and for searching forto express this. Just having bugs.3s it mean that. The algorithms given above do not compute well-foundedhe fact that assertions are support. For one thing, the notion is now relative to a datapendency (DD) system and pool. A given assertion can have different proofs in differentponsible for the content of data pools. For another, it seems simpler to compute theseer level the "knowledge rep- supports when needed, from a given pool. Although careevel programs communicate must be taken to sidestep database cycles, the programs are*emoving justifications from straightforward.in turn communicates backn a given data pool the sta-R system ignores the OUT-
iation from the DD system.
IV. DISCUSSION
The algorithm I have described combines the advantages ofdata pools and data dependencies, which are devices formanaging multiple views of a database obtained from different
244
MC DERMOTT: CONTEXTS AND DATA DEPENDENCIES
premiss combinations. The algorithm applies to any databaserepresentation with identifiable units that can be believed or
not ("assertions"). It is worth using if premiss switchingoccurs often and there are substantial external costs (such as
indexing) associated with hiding and revealing assertions. Itbecomes less valuable if each assertion has many differentpotential well-founded supports, many of which will seldombe realized.This implementation of data pools is being used for two
applications: a rule-based Al language, and a temporal reason-
ing system. The former is a version of the "DUCK" program-
ming language, orginally used for pedagogical purposes, andnow being used for expert systems applications [151. In thislanguage, you can say things like
(NEGLECTING' (ATTACK OPP K)(ASSERT' (NOT (ATTACK OPP K))))
(See Fig. 3.) This adds an assertion (NOT (ATTACK OPP K)) tothe index, supported by the absence of (ATTACK OPP K). Thiscorresponds to an AMORD ASSUME [4], except that it inter-acts correctly with data pools. In any data pool in which(ATTACK OPP K) is asserted, (NOT (ATTACK OPP K)) will beOUT. The (NOT (ATTACK OPP K)) assertion can then triggerfurther deductions by interaction with "forward chaining"rules like
(+ (NOT (ATTACK OPP K))(- (WEAK CENTER)
(GOOD-MOVE (CASTLE K))))
which sets up the dependency structure of Fig. 2.The application to temporal reasoning is less traditional. Here
the problem is to keep track of many possible future timelines. The way we do this is to maintain several chronsets. Achronset, or "chronicle set," is a repository for inferencesabout all the chronicles satisfying some predicate. For in-stance, there are many possible futures in which there is a war
in El Salvador, and many in which there is not one. For eachof the two alternatives, we would like to sketch out the mostlikely scenario, in isolation from the other alternative.Each chronset must contain a data structure called a "time
line" that keeps track of the temporal relations among theoccurrences expected in that chronset. It is not certain whatthe implementation of time lines should be. We are currentlyadapting the spatial representation of [13], [14]. One majorchange this has entailed is "data-poolizing" the representation.That is, in every data structure where there is a list of objectsthat might vary from chronset to chronset (such as the inter-vals during which some fact is true), this list has been turnedinto a "gated list" of the kind described in Section 111- C. As Isaid there, this is simply a matter of attaching to every elementa data dependency node of the kind I have been discussingthroughout this paper. Then the programs that manipulate thelist must pretend they do not see the currently invisibleelements of it. We are optimistic that this approach will giveus an efficient, flexible implementation of chronsets withminimal complexity. (Of course, there are other complexitiesthat have nothing to do with the multiple-chronset problem.)In this application, there is a substantial indexing cost
associated with switching batches of data IN and OUT. Thesystem uses a discrimination tree to retrieve objects given theirtemporal properties (location, duration, etc.). The tree carvesup an abstract space of times and durations into cells, andindicates which objects are in which cells. Naturally, thecells an object is in depends on assertions about its time ofoccurrence, duration, and so forth. So different premisseswill put a given object in different parts of this tree. A straight-forward implementation of data dependencies would cost us ahigh overhead in reconfiguring the discrimination tree everytime we switched premisses. Using the algorithms I havedescribed here, we simply use gated lists to define the discrim-ination tree. This in effect enables several versions of thediscrimination tree to coexist, with rapid switching betweenthem (and slightly slower retrieval).There are interesting further lines to explore in this research
area. The current system assumes that any set of beads is aslikely to be made into a data pool as any other. In practice,data pools often form trees (see Fig. 1). (This occurs if onlythe "push-down" operation described in Section I-A is used tocreate data pools.) This establishes a "subsumption" relationon beads: bead BI subsumes B2 if BI never occurs in a poolwithout B2 (because Bi first appeared as the result of a "push"of a pool containing B2). This relation allows further simplifi-cations of assertion labels, since Bi A/B2 can simplify to B1,and BI VB2 can simplify to B2. This may help to alleviatethe exponential explosion problem even when assertions dohave multiple proofs.Another interesting problem is that of "cross-pool" depen-
dencies. In the chronset application, we have the problem oftagging an assertion as being present in one pool becauseanother assertion is present in another pool. For instance, theassertion "I will switch Train 1 onto track 12," is supportedby the presence of the assertion "Train 1 will hit Train 2" in achronset representing the course of events in which I do notswitch Train 1 onto track 12. The dependencies required hereare a special case of what Doyle calls "conditional-proofjustifications." [51 They can be handled, I believe, by anextension of the present algorithm. The new operator re-quired essentially tests whether the conjunction of beads inthe "remote" data pool entails the label on the assertion inquestion. This is a departure from the present situation,since such an operator is not truth-functional. However, it isstill monotonic, if we reinterpret the domain of labels to beBoolean polynomials rather than truth values. The details ofthis approach must wait for a later paper.
REFERENCES
[11 G. Bobrow and B. Raphael, "New programming languages forartificial intelligence research," Comput. Surveys, vol. 6, no. 3,p. 155, 1974.
[21 E. Charniak, C. Riesbeck, and D. McDermott, Artificial Intelli-genceProgramming. Lawrence Erlbaum Associates, 1980.
[31 E. Charniak, "A common representation for problem-solving andlanguage-comprehension information," Artificial Intell., vol. 16,no. 3, pp. 225-255, 1981.
[41 J. de Kleer, J. Doyle, G. L. Steele, and G. J. Sussman, "Explicitcontrol of reasoning," MIT AI Lab., Memo. 427, 1977; also in
Proc. Conf. Artificial Intell. and Programming Languages, Roch-cester, NY, and SIGARTNewsletter, no. 64, pp. 116-1 25.
245
IEEE TRANSACTIONS ON PATTERN ANALYSIS AND MACHINE INTELLIGENCE, VOL. PAMI-5, NO. 3, MAY 1983
[5] J. Doyle, "A truth maintenance system," Artificial Intell., vol.12, no. 3, pp. 231-272, 1979.
161 , "A model for deliberation, action, and introspection," MITAl Lab., Tech. Rep. 581, 1980.
[7] S. E. Fahlman, "A planning system for robot construction tasks,"Artificial Intell., vol. 5, no. 1, pp. 1-49, 1974.
[81 C. Hewitt, "PLANNER: A language for manipulating models andproving theorems in a robot," in Proc. IJCAI, vol. 1, 1969.
[91 C. Hewitt, "Procedural embedding of knowledge in PLANNER,"in Proc. IJCAI, vol. 2, 19 71.
[10] P. E. London, "A dependency-based modelling mechanism forproblem solving," in AFIPS Nat. Comput. Conf Proc., vol. 47,1978.
[111 D. A. McAllester, "An outlook on truth maintenance," MIT AlLab., Tech. Rep. 551, 1980.
[12] D. V. McDermott, "Assimilation of new information by a naturallanguage-understanding program," MIT Al Lab., Tech. Rep. 291,1974.
[131 , "A theory of metric spatial inference," in Proc. AAAI,vol. 1, 1980.
[141 D. V. McDermott and E. Davis, "Planning and executing routesthrough uncertain territory," Artificial Intell., to be published.
[15] D. V. McDermott and R. Brooks, "Arby: diagnosis with shallowcausal models," in Proc. AAAI, vol. 2, 1982.
[161 J. R. Meehan, The New UCI Lisp Manual. Lawrence ErlbaumAssociates, 1979.
1171 C. Rieger, "Spontaneous computation in cognitive models,"Dep. Comput. Sci., Univ. Maryland, Tech. Rep. 459, 1976.
[181 J. F. Rulifson, J. A. Derksen, and R. J. Walding, "QA4: a pro-cedural calculus for intuitive reasoning," SRI Al Center, Tech.Note 73, 1972.
[191 R. Staliman and G. Sussman, "Forward reasoning and depen-dency-directed backtracking in a system for computer-aidedcircult analysis," Artificial Intell., vol. 9, no. 2, 1977.
[201 G. Sussman and D. V. McDermott, "From planning to conniv-ing-A genetic approach," in Proc. FJCC, vol. 41, 1972, p. 1171.
[211 A. Thompson, "Network truth maintenance for deduction andmodeling," in Proc. IJCAI, vol. 6, 1979, pp. 877-879.
Drew McDermott was educated at the Arti-ficial Intelligence Laboratory, MassachusettsInstitute of Technology, Cambridge.He has been with the Department of Com-
puter Science, Yale University, New Haven,CT, since 1976, and is currently an AssociateProfessor. His research has concentrated onproblem solving, logic, and spatial and temporalreasoning. He is a coauthor of the book Arti-ficial Intelligence Programming.
Prof. McDermott is a member of the Execu-tive Council of the American Association for Artificial Intelligence.
Planning in Time: Windows and Durationsfor Activities and Goals
STEVEN A. VERE, MEMBER, IEEE
Abstract-A general purpose automated planner/scheduler is describedwhich generates parallel plans to achieve goals with imposed time con-straints. Both durations and start time windows may be specified forsets of goal conditions. The parallel plans consist of not just actions butalso of events (triggered by circumstances), inferences, and scheduledevents (completely beyond the actor's control). Deterministic dura-tions of all such activities are explicitly modeled, and may be any com-putable function of the activity variables. A start time window for eachactivity in the plan is updated dynamically during plan generation, inorder to maintain consistency with the windows and durations of adja-cent activities and goals. The plans are tailored around scheduledevents. The final plan network resembles a PERT chart. From this aschedule of nominal start times for each activity is generated. Ex-amples are drawn from the traditional blocksworld and also from a real-istic "Spaceworld," in which an autonomous spacecraft photographsobjects in deep space and transmits the information to Earth.
Manuscript received November 23, 1981; revised July 29, 1982. Thiswork was supported by the National Aeronautics and Space Adminis-tration under Contract NAS 7-100 and presents the results of one phaseof research carried out at the Jet Propulsion Laboratory, California In-stitute of Technology.The author is with the Information Systems Research Section, Jet
Propulsion Laboratory, Pasadena, CA 91109.
Index Terms-Duration, goal directed simulation, planning, problemsolving, relational production, scheduled event, scheduling, start timewindow, temporal planning, time, time constraint.
I. INTRODUCTION
IN PLANNING a course of action to achieve a set of goals,time is often a key parameter. The need to account for
time explicitly in artificial intelligence planners has been rec-
ognized for a long time [51, [8] . This paper describes featuresand mechanisms of a general purpose automated planner/scheduler called DEVISER. The program synthesizes plans toachieve goals which may have time restrictions on when sets ofgoals should be achieved and on how long the goal conditionsshould be preserved. Actions and events may have computable,deterministic durations. Scheduled events may occur overwhich the actor has no control. The principal output ofDEVISER is a partially ordered network of activities. Foreach activity, a duration and a start time "window" are pre-sented. This provides all the information of an activity-on-
