The Use of Ooject-Specl flc Knowledge in Natural Language Processing 
Mark H. Bursteln 
Department of Computer Science, Yale University 
1. INTRODUCTION 
it is widely reco~nlzed that the process of 
understandln~ natural language texts cannot be 
accomplished without accessin~ mundane Knowledge about 
the world \[2, 4, 6, 7\]. That is, in order to resolve 
ambiguities, form expectations, and make causal 
connections between events, we must make use of all 
sorts of episodic, stereotypic and factual knowledge. 
In this paper, we are concerned with the way functional 
knowledge of objects, and associations between objects 
can be exploited in an understandln~ system. 
Consider the sentence 
(1) Jonn opened the Oottle so he could pour the wine. 
Anyone readin~ this sentence makes assumptions about 
what happened which go far beyond what is stated. For 
example, we assume without hesitation that the wine 
beln~ poured came from inside the bottle. Although this 
seems quite obvious, there are many other 
interpretations wnlcn are equally valid. Jonn could be 
fillin~ the bottle rather than emptyln~ the wine out of 
it. In fact, it need not be true that the wine ever 
contacted the bottle. There may have been some other 
reason Jonn had to open the bottle first. Yet, in the 
absence of a larger context, some causal inference 
mechanism forces us (as human understanders) to find the 
common interpretation in the process of connecting these 
two events causally. 
In interpreting this sentence, we also rely on an 
understanding of what it means for a bottle to be 
"open". Only by usin~ Knowledge of what is possible 
when a bottle Is open are able we understand why John 
had to open the Pottle to pour the wine out of It. 
Stron~ associations are at work here nelpin~ us to make 
these connections. A sentence such as 
(2) John closed the bottle and poured the wine. 
appears to be self contradictory only because we assume 
that the wine was in the bottle before applyln~ our 
knowledge of open and closed bottles to the situation. 
Only then do we realize that closing the bottle makes it 
impossible to pour the wine. 
Now consider the sentence 
(3) John turned on the faucet and filled his glass. 
When reading this, we immediately assume that John 
filled his glass with water from the faucet. Yet, not 
only is water never mentioned in the sentence, there is 
nothing there to explicitly relate turning on the faucet 
and filling the glass. The glass could conceivably be 
filled with milk from a carton. However, in the absence 
of some greater context which forces a different 
interpretation on us, we immediately assume that the 
glass is being filled with water from the faucet. 
Understanding each of these sentences requires that we 
make use of associations we have In memory between 
oPJects and actions commonly InvolvlnE those objects, as 
• This wore was supported in part by the Advanced 
Research Projects Agency of the Department of Defense 
and monitored by the Office of Naval Research under 
contra:t N0001~-75-C-1111. 
well as relations between several different objects. 
This paper describes a computer program, OPUS (Object 
Primitive Understanding System) which constructs a 
representation of the meanings of sentences such as 
those above, including assumptions that a human 
understander would normally make, by accessin~ these 
types of associative memory structures. This 
stereotypic knowledge of physical objects Is captured in 
OPUS using Object Primitives \[5\]. Object Prlmitlves 
(or) were designed to act in conjunction with Scnank's 
conceptual dependency representational system \[11\]. The 
processes developed to perform conceptual analysis in 
OPUS involved the integration of a conceptual analyzer 
similar to RlesOec~'s ELl \[g\] with demon-like procedures 
for memory interaction and the introduction of 
object-related inferences. 
2. OBJECT PRIMITIVES 
The primary focus In this research has been on the 
development of processes which utillze Information 
provided by Object Primitives to facilitate the 
"comprehension" of natural language texts by computer. 
That Is, we were primarily concerned with the 
introduction of stereotyplc knowledge of objects into 
the conceptual analysis of text. By encoding 
information in OP descriptions, we were able to increase 
the interpretive power of the analyzer in order to 
handle sentences of the sort discussed earlier. 
What follows Is a brief description of the seven Object 
Primitives. A more thorough discussion can be found in 
\[5\]. For those unfamiliar with the primitive acts of 
Schank's conceptual dependency theory, discussions of 
wnlch can be found in \[10,11\]. 
The Object Primitive CONNECTOR Is used to indicate 
classes of actions (described in terms of Sohank*s 
primitives acts) which are normally enabled by the 
object being described. In particular, a CONNECTOR 
enables actions between two spatial regions. For 
example, a window and a door are both CONNECTORs which 
enable motion (PTRANS) of objects through them when they 
are open. In addition, a window Is a CONNECTOR which 
enables the action ATT£ND eyes (see) or MTRANS 
(acquisitlon of Information) by the instrumental action 
AI"rEND eyes. These actions are enabled regardless of 
whether the window is open or closed. That Is, one can 
see through a window, and therefore read or observe 
things on the other side, even when the window is 
closed. In the examples discussed above, the open 
bottle ls glven a CONNECTOR description, rnis will be 
discussed further later. 
A SEPARATOR disenables a transfer between two spatial 
regions. A closed door and a closed window are both 
SEPARATORs which dlsenable the motion between the 
spatial regions they adjoin. In addition, a closed door 
is a SEPARATOR which dlsenables the acts MTRANS by 
A~END eyes (unless the door is transparent) or ears. 
That Is, one is normally prevented from seeing or 
hearing through a closed door. Similarly, a closed 
window is a SEPARATOR which dlsenables MTRANS with 
Instrument ATTENO ears, although, as mentioned aoove, 
one can still see through a closed window to the other 
side. A closed bottle is another example of an object 
with a SEPARATOR description. 
It should be clear by now that objects de,bribed using 
Object Primitives are not generally described by a 
single primitive. In fact, not one out several sets of 
53 
primitive descriptions may be required. This Is 
illustrated above by the combination of CONNECTOR and 
SEPARATOR descriptions required For a closed window, 
while a somewhat different set Is required For an open 
window. These sets of descriptions form a small set of 
"states" which the object may Oe in, each state 
corresponding to a set of inferences and asSociations 
approriate to the object in that condition. 
A SOURCE description indicates that a aajor function of 
the object described is to provide the user of that 
object with some other object. Thus a Faucet is a 
SOURCE o\[ water, a wtne bottle ls a SOURCE of wine, and 
a lamp is a SOURCE of the phenomenon called light. 
SOURCEs often require some sort of activation. Faucets 
must be turned on, wine bottles must be opened, and 
lamps are either turned on or lit depending on whether 
or not they are elsctrJo. 
The Object Frlmltlve CONSUMER Is used to describe 
objects whose primary Function Is to cons, me other 
objects. A trash can is a CONSUMER of waste paper, a 
draln is a CONSUMER of liquids, and a mailbox ts a 
CONSUMER of mail. Some objects are both SOURCEs and 
CONSUMERS. A pipe is a CONSUMER of tobacco and a SOURCE 
of smoke. An Ice cube tray Is a CONSUMER of water and a 
SOURCE of ice cu~es. 
Many objects can be described In part by relationships 
that they assu~e with some other objects. These 
relations are described ustn~ the Object Primitive 
RELATZONAL. Containers, such as bottles, rooms, cars, 
etc., have as part of their descriptions a containment 
relation, which may specify defaults For the type of 
object contained. Objects, such as tables and chairs, 
wnloh are commonly used to support other objects will be 
described with a support relation. 
Objects such as buildings, cars, airplanes, stores, 
etc., are all things which can contain people. As such, 
they are often distinguished by the activities which 
people in those places engage in. One important way OF 
encoding those activities is by referring to the scripts 
which describe them. The Object Primitive SETTING is 
used to capture the asscclatlons between a place and any 
script-like activities that normally occur there. It 
can also be used to indicate other, related SETTINGs 
which the object may be a part of. For example, a 
dinin~ car has a SETTING description wlth a llnK both to 
the restaurant script and to the SETTING For passenger 
train. This information Is important For the 
establishment OF relevant contexts, giving access to 
many domain specl/lc expectations which wlll 
subsequently be available to guide processtn~ ~oth 
during conceptual analysis of lexical input and when 
making InFerences at higher levels oF nogntttve 
processing. 
The Final Object Primitive, GESTALT, is used to 
characterize objects which have recognizable, and 
separable, eubparts. " Trains, hi-Fi systems, and 
Kitchens, all evoke Images of objects charaoterlzable by 
describing their subparts, and the way that those 
subparts relate to fOrm the whole. The OcJect Primitive 
GESTALT is used to capture this type of description. 
Using thls set of prlmltlves as the Foundation For a 
memory representation, we can construct a more general 
hi-directional associative memory by introducing some 
associative links external to object primitive 
decompositions. For example, the conceptual description 
of a wine bottle will Include a SOURCE description For a 
bottle where the SOURCE output is specified as wine. 
This amounts to an associative link From the concept OF 
a wine bottle to the concept of wine. But how can we 
construct an assoolatlve llnK From wlne back to wlne 
bottles? ~lne does not have an object primitive 
decomposition wnloh involves wine bottles, so we must 
resort to some construction which Js external to object 
primitive decompOsitions. 
Four associative links have been proposed \[5\], each of 
which pOints to a particular object primitive 
description. For the problem of wine and wine Dottles, 
an associative OUTPUTFROH link is directed from wlne to 
tne SOURCE description of a wine bottle. This external 
link provides us with an associative link From wine to 
wine bottles. 
3. I~U~ROORAM 
I will now describe the processing ot two sentences very 
similar to those discussed earlier. The computer 
program (OPUS) which performs the Following analyses was 
developed usin~ a con:eptual analyzer written by Larry 
Eirnbaum \[1\]. OPUS was then extended to include a 
capacity For setting up and Firing "demons" or 
.triggers" as they are called In K~L \[3\]. The 
Functioning of these demons will be Illustrated below. 
3.1 THE INITIAL ANALXSIS 
In the processing of the sentence "Jo~n opened the 
bottle so he could pour the wine," the phrase "John 
opened the bottle," is analyzed to produce the Followin~ 
representation: 
SJohne : eDOe 
result 
ehottlee CONNECTOR 
ENABLES 
?HUMO <:> PTRANS ~- ?OBJ <--~>-- 
?X 
L. < (INSIDE SELF) 
(or) > (INSIDE SELF) 
r- 
PTRANS <- ?OBJ <-~ ?HUMO <=> L- < ?¥ 
(or) 
?HUMO <=> A'r'rzSD <. ?S£NS£ <--E~ ?OBJe 
• (where ?OBJ Is inside SELF) 
Here 3ELF refers to the object bein~ described (the 
bottle) and ?--- indicates an unfilled slot. eJohne 
here stands For the internal memory representation For a 
person wlth the name John. Memory tokens rot John and 
the bottle are constructed by a general demon which is 
trtg&ered during conceptual analysis whenever a PP (the 
internal representation For an object) is Introduced. 
OF descriptions are attached to each object token. 
This dtagrem represents the assertion that John did 
something which caused the bottle to assume a state 
where its CONNECTOR description applied. The CONNECTOR 
description indicates that something can be removed from 
the bottle, put into the bottle, or Its contents can be 
smelled, looked at, or generally examined by some sense 
modsltty. This CONNECTOR description Is not part oF the 
definition of the word 'open'. It is specific Knowledge 
that people have about what it means to say that a 
~ottle IS open. 
In striving at the ~bove representation, the program 
must retrieve From memory this OF description of what it 
means For a bottle to be open. This information is 
stored Peneath its prototype For bottles. Presumably, 
there Is also script-like information about the 
different methods For opening bottles, the different 
types of caps (corks, twist-off, ...), and which method 
is appropriate For which cap. However, For the purpose 
of understanding a text which does not re/er to a 
specific type of bottle, asp, or opentn~ procedure, what 
is important is the information aoout how the bottle can 
54 
then be used once it is opened. This is the kind of 
knowledge that OOJect Primitives were designed to 
capture. 
When the analyzer builds the state description of the 
bottle, a general demon associated with new state 
descriptions is triggered. This demon is responsible 
for updating memory by adding the new state information 
to the token in the ACTOR slot of the state description. 
Thus the bottle token is updated to include the gtven 
CONNECTOR description. For the purposes of this 
program, the bottle is then considered to be an "open" 
bottle. A second function of this demon is to set up 
explicit expectations for future actions based on the 
new information. In this case, templates for three 
actions the program might expect to see described can be 
constructed from the three partially specified 
conceptualizations shown above In the CONNECTOR 
description of the open bottle. These templates are 
attached to the state descrJptlon as possible 
consequences of that state, for use when attempting to 
infer the causal connections between events. 
3.2 CONCEPT DRIVEN INFERENCES 
The phrase "so ne could pour the wine." Is analyzed as 
eJohn~ ~.> enable PTRANS <- ewinee <~_>F ?X i 
< (INSIDE ?CONTAINER) 
When thls representation is built by the analyzer, we do 
not know that the the wine being poured came from the 
previously mentioned bottle. This inference Js made in 
the program by a slot-filling demon called the 
CONTAINER-FINDER, attached to the primitive act PTRANS. 
The demon, triggered when a PTRANS from Inside an 
unspecified container is built, looks on the iist of 
active tokens (a part of snort term memory) for any 
containers that might be expected to contain the 
substance moved, in this case wine. This is done by 
applying two tests to the objects In snort term memory. 
The first, the DEFAULT-CONTAINMENT test, looks for 
objects described by the RELATIONAL primitive, 
indicating that they are containers (link = INSIDE) with 
default object contained being wine. The second, the 
COMMON-SOURCE test, looks for known SOURCEs of wine by 
following the associative OUTPUTFROM link from wlne. If 
either of these tests succeed, then the object found is 
inferred to be the container poured from. 
At dlfferent times, either the DEFAULT-CONTAINMENT test 
or the COMMON-SOURCJ~ test may be necessary in order to 
establish probable containment. For example, it is 
reasonable to expect a vase to contain water since the 
RELATIONAL description of a vase has default containment 
slots for water and flowers. But we do not always 
expect water to come from vases since there is no 
OUTFUTFROM link from water to a SOURCE description of a 
vase. If we heard "Water spilled when John bumped the 
vase," containment would be established by the 
DEFAULT-CONFAINMENT test. AssoclatJve links are not 
always hi-directional (vase ---> water, but water -/-> 
vase) and we need separate mechanisms to trace links 
with different orlentatlons. In our wine example, the 
COMMON-SOURCE test Is responsible for establishing 
containment, since wine is known to be OUTPUTFROM 
bottles but bottles are not always assumed to hold wine. 
Another inference made during the initial analysis finds 
the contents of the bottle mentioned in the first clause 
of the sentence. Thls expectation was set up by a demon 
called the CONTENTS-FINDER when the description of the 
open bottle, a SOURCE with unspecified output, was 
built. The demon causes a search of STM for an object 
which could De OUTPUT-FROM a bottle, and the token for 
this particular bottle is then marked as being a SOURCE 
of that oCject. The description of this particular 
bottle as a SOURCE of wine Is equivalent, in Object 
Primitive terms, to sayin~ that the bottle is a wine 
bottle. 
3.3 CAUSAL VERIFICATION 
Once the requests trying, to fill slots not filled during 
the initial analysis nave been considered, the process 
which attempts to find causal connections between 
conceptualizations is activated, in this particular 
case, the analyzer has already indicated that the 
appropriate causal link is enablement. In ~eneral, 
however, the lexical information which caused the 
analyzer to build this causal llng is only an lndJcatlon 
that some enabling relation exists between the two 
actions (opening the bottle and pouring the wine). In 
fact, a long causal cnaJn may Oe required to connect the 
two acts, with an enaClement link being only one link in 
that chain. Furthermore, one cannot always rely on the 
text to indicate where causal relationships exist. The 
sentence "John opened the bottle and poured the wine." 
must ultimately be Interpreted as virtually synonymous 
with (1) above. 
The causal verification process first looks for a match 
between the conceptual representation of the enabled 
action (pouring the wine), and one of the potentially 
enabled acts derived earlier from the OP descrJptlon of 
the opened oottle. In this ex&mple, a match is 
immediately found between the action of pourln~ from the 
bottle and tne expected action generated from the 
CONNECTO~ descrJptlon of the open bottle (PTRANS FROM 
(INSIDE PART SEL~)). Other Object Primitives may also 
lead to expectations for actions, as we snail see later. 
When a match Js found, further conceptual checks are 
made on the enabled act to ensure that the action 
described "makes sense" with the particular objects 
currently fJlllng the slots In that acts description. 
When the match Is based on expectations derlved from the 
CONNECTO~ description of a container, the check Is a 
"contalner/contents check," which attempts to ensure 
that the object found in the container may reasonably be 
expected to be found there. The sentence "John opened 
the bottle so ne could pull out the elephant", is 
peculiar because we no associations exist wnlch would 
lead us to expect that elephants are ever found in 
bottles. The strangeness of this sentence can only be 
explained by the application of stereotypic knowledge 
about what we expect and don't expect to find inside a 
bottle. 
The contalner/contents cnecK is similar to the test 
described above In connection with the CONTAINER-FINDER 
demon. That is, the bottle is checked by both the 
DEFAULT-CONTAINMENT test and the COMMON-SOURCE test for 
known links relatin~ wlne and botles. When this check 
succeeds, the enable llnk has been verified by matcnlng 
an expected action, and by checking restrictions on 
related objects appearing intne slots of that action. 
The two CD acts that matched are then merged. 
The merging process accomplishes several tnJn~s. First, 
it completes the linking of tne causal chain between tne 
events described in the sentence. Second, it causes the 
filling of empty slots appearing in either the enabled 
act or In the enabling act, wherever one left a slot 
unspecified, and the other had that slot filled. These 
newly filled slots can propagate back along the causal 
chaln, as we shall see in the example of the next 
section. 
55 
3.~ CAUSAL CHAIN CONSTRUCTION 
In processin~ the sentence 
(~) John turned on the faucet so he could drinK. 
the causal chain cannot be built by a direct match with 
an expected event. Additional inferences must he made 
to complete the chain between the actions described in 
the sentence. The representation produced by the 
conceptual analyzer for "John turned on the faucet," Is 
*John* <~> *ooe 
\]J~ result 
Sfaucet e ~ (SOURCE with OUTPUT • ~water e) 
As with the bottle in the previous example, the 
description of the faucet as an active SOURCE of water 
is based on information found beneath the prototype for 
faucet, descrlbLnE the "on" state for that object. The 
principle e~pectatlon for SOURCE objects is that the 
person ~o "turned on" the SOURCE object wants to take 
control of (and ultimately make use of) whatever it is 
that Is output from that SOURCE. In CD, this is 
expressed by a template for an ATRANS (abstract 
transfer) of the output object, in this case, water. An 
important side effect of the construction of this 
expectation is that a token for some water is created, 
which can be used by a slot-filling Inference later. 
The representation for "he could drink" Is partially 
described ~y an INGEST with an unspecified liquid in the 
OBJECT slot. A special request to look for the missing 
liquid Is set up ~y a demon on the act INGEST, similar 
to the one on the PTRANS in the previous example. This 
request finds the token for water placed In the short 
term mamory ~nen the expectation that someone would 
ATRANS control of some water was generated. 
• faucet* ~ (SOURCE with OUTPUT = *watere) 
III ,. (possible enaOled action) 
HI 
;i,1" "El ?HUMO ?HUMO <=> ATRANS <- ewatere < 
The causal chain completion that occurs for thls 
sentence is somewhat more complicated than It was for 
the previous case. As we nave seen, the only 
expectation set up by the SOURCE description of the 
faucet was for an ATRANS of water from the faucet. 
However, the action that is described here is an INGEST 
with Instrumental FTRANS. When the chain connector 
rails to find a match between the ATRANS and either the 
INGEST or its instrumental PTRANS, inference procedures 
are called to ~enerate any oOvlouS intermediate states 
that might connect these two acts. 
The first inference rule that is applied Is the 
resultatlve inference \[8\] that an ATRANS of an object TO 
someone results in a state where the object Is possessed 
by (POSS-BY) that person. Once this state has been 
~enerated, it is matched a~alnst the INGEST in the same 
way the ATRANS was. When this match fails, no further 
forward inferences are ~enerated, since possession of 
water can lead to a wide ran~ e of new actions, no one of 
wnich is strongly expected. 
The backward chaining Inferencer Is then called to 
generate any ~nown preconditions for the act INGEST. 
The primary precondition (causative inference) for 
drinking is that the person doing the drinking has the 
liquid which ~e or she Is about to drink. This inferred 
enaolln~ state is then found to match the state (someone 
possesses water) Inferred from the expected ATRANS. The 
=arch completes the causal cnaln, causing the merging of 
the matched concepts. In this case, the mergln~ process 
causes the program to infer that it was procaoly John 
who took (AT~ANSed) the water from the faucet, in 
addition to turning it on. Had the sentence read "John 
turned on the faucet so .Mary could drlnK."p the program 
would infer that Mary took the water from the faucet. 
efaucete ~ (SOURCE with OUTPUT = ewatere) i 
enable 
?HUMO ATRANS (- ewater • TO ?HUGO 
result 
°watere (POSS-B¥ ?HUHO) \ 
match? 
yes...lnfer ?HUMO • mJonnJ 
--~ewatere q~ (POSS-B~ mJohnO) 
bacgwar~J 
inference ,I~, enable 
L ..tJohnl <.> INGEST <- ?LIQUID ~ 
inst 
OJonne <=> PTRANS <- ?LIQUID 
One should note hers that the additional inferences used 
to complete the causal chain were very basic. The 
primary connections came directly from oOJect-specific 
expectatlons derived from the OOject Primitlve 
descriptions of the objects Involved. 
4. C~ 
It ta important to understand how OPUS differs from 
previous inference strateKies in natural language 
processing. To emphasize the original contributions of 
OPUS we will compare it to Rie~er's early work on 
inference and causal chain construction. Since Rie~er*s 
research is closely related to OPUS, a comparison of 
this system to Rieger's pro;rum will illustrate which 
aspects of OPUS are novel, and which aspects have been 
inherited. 
There is a ~reat deal of similarity between the types of 
inferences used In OPUS and those used by Rte~er in his 
description of Mt~qORX \[8\]. The causative and 
resultative inferences used to complete the causal chain 
in our last example came directly from that work. In 
addition, the demons used by OPUS are similar in flavor 
to the forward inferences and specification 
(slot-filling) inferences described by Rieger. 
Expectations are explicitly represented here as they 
were there, allowing them to be used In more then one 
way, as In the case where water is inferred to be the 
~/Gg~Ted liquid solely from its presence in a previous 
expectation. 
There are, however, two ways in which OPUS departs from 
the inference strategies of Mb~OR¥ In significant ways. 
(1) On one the level of computer implementation there is 
a reorganization of process control in OPUS, and (2) on 
a theoretical level OPUS exploits an additional 
representatLonal system which allo~m inference 
generation to be more stronBly directed and controlled. 
In terms of implementation, OPUS integrates the 
processes of conceptual analysis and memoryohased 
inference prooeantnB. By using demons, inferences can 
be made during conceptual analysis, as the conceptual 
memory representations are ~enerated. This eliminates 
much of the need for an inference discrimination 
procedure aoting on completely pre-analyzed 
comoeptuaiizations produced Py a separate program 
module. In ,~tOR~, the processes of conceptual analysis 
and inference ~sneration were sharply modularized for 
reasons which were more pragmatic than theoretical. 
~ough is Known about the interactions of analysis and 
inference at this time for us to approach the two as 
56 
concurrent processes which share control and contribute 
to each other In a very dynamic manner, ideas from KRL 
\[3\] were Instrumental In desJgnJn~ an integration of 
previously separate processing modules. 
On a more theoretical level, the Inference processes 
used for causal chain completion Jn OPUS are more highly 
constrained than was possible in Rle~er's system. In 
MEMORY, all possible inferences were made for each new 
conceptualization which was input to the program. 
Initially, input consisted of concepts coming from the 
parser. MEHORX then attempted to sake inferences from 
the conceptualizations which it itself had produced, 
repeating this cycle until no new inferences could be 
~enerated. Causal chains were connected ~nen matches 
were found between inferred concepts and concepts 
already stored In Its ~emory. However, the Inference 
mecnanlsms used were in no way dlrected speclflcally to 
tne task of making connections between concepts found In 
its Input text. This lead to a comblnatorlal explosion 
in the number of inferences made from each new input. 
In OPUS, forward expectations are based on specific 
associations from the objects mentioned, and only when 
the objects in the text are described in a manner that 
indicates they are being used functionally. In 
addition, no more than one or two levels of forward or 
backward Inferences are made before the procedure Is 
exhausted, the system stops once a match Is made or It 
runs out of highly probable inferences to make. Thus, 
there is no chance for the ~Jnds of comblnatorlal 
explosion Rieger experlenced. By strengthenln~ the 
representation, and exploiting an integrated processing 
strategy, the comblnatorJal explosion problem can be 
eliminated. 
OPUS makes use of a well structured set of memory 
associations for objects, the Object Primitives, to 
encode Information which can be used in a variety of 
Rleger's qeneral inference classes. Because this 
Information is directly assoclated with memory 
representations for the objects, rather than being 
embodied Jn disconnected inference rules elsewhere, 
appropriate Inferences for the objects mentioned can be 
found directly. By using this extended repressntatlonai 
system, we can begin to examine the kinds of associative 
memory required to produce what appeared from Rieger's 
model to ~e the "tremendous amount of 'hidden' 
computation" necessary for the processing of any natm'al 
language text. 
REFERENC£S 
\[11 Blrnbaum, L., and Selfrldge M. (1978). On 
Conceptual Analysis. (unpublished) Yale 
University, New Haven, CT. 
\[2\] Bobrow, D. G., Kaplan, R.M., Kay, M., Norman, 
D.A., Thompson, H., and Winograd, T. (1977). 
GUS, a frame driven dialog system, Artificial 
Intelligence, Vol. 8, No. 1. 
\[31 Bobrow, D. G., and Wlnograd, T. (1977). An overview of KRL, a Knowledge representation 
language. Co=nltive Science 1, no. 1 
\[~\] Charntak, E. (1972). Toward a model of childrens 
story comprehension. AITR-266, Artificial 
Intelligence Laboratory, MZT, Cambridge, HA. 
Lehnert, W.G. (1978). Representing physical 
objects in memory. Technical Report #111. 
Dept. of Computer Science, Yale University, New 
Haven, CT. 
C6\] Minsky, M. (1975). A framework for representing 
Knowledge. In Winston, P. H., ed., The~1.~JZg~L~ 
of C~Dutar Vlslon, McGraw-Hill, New York, NY. 
C71 
C81 
C91 
Norman, D. A., and Rumelhart, D. £., and the LNR 
Research Group (1975) ExDlorationslnCo=nltton. 
W. H. Freeman and Co., San granslsco. 
Rleger, C. (1975). Conceptual memory. Zn 
R. C. Schank, ed., Concectual 
Prdceasinm. North Holland, Amsterdam. 
Rlesbeok, C. and Schank, R. C. (1976). 
Comprehension by computer: expectation-baaed 
analysis of sentences in context. Technical Report 
#78. Dept. of Computer SCience, Yale University, 
New Haven, CT. 
\[10\] 3ohank, R.C., (1975). Conceptual Dependency 
Theory. in Schank, R. C.(ed.), 
Processinl. North Holland, Amsterdam. 
\[111 5ohank, R. C. and Abelson, R. P. (1977). ~criots, 
Plans, ~oals, ~ Understandtn¢. Lawence Rrlba ,,m 
Press, Hlllsdale, NJ. 
57 

