<?xml version="1.0" standalone="yes"?>
<Paper uid="P79-1013">
  <Title>The Use of Ooject-Specl flc Knowledge in Natural Language Processing</Title>
  <Section position="4" start_page="54" end_page="55" type="metho">
    <SectionTitle>
&lt; (INSIDE ?CONTAINER)
</SectionTitle>
    <Paragraph position="0"> 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.</Paragraph>
    <Paragraph position="1"> 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.</Paragraph>
    <Paragraph position="2"> 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.</Paragraph>
    <Paragraph position="3"> 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 &amp;quot;Water spilled when John bumped the vase,&amp;quot; containment would be established by the DEFAULT-CONFAINMENT test. AssoclatJve links are not always hi-directional (vase ---&gt; water, but water -/-&gt; 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.</Paragraph>
    <Paragraph position="4"> 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.</Paragraph>
    <Section position="1" start_page="54" end_page="55" type="sub_section">
      <SectionTitle>
3.3 CAUSAL VERIFICATION
</SectionTitle>
      <Paragraph position="0"> 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 &amp;quot;John opened the bottle and poured the wine.&amp;quot; must ultimately be Interpreted as virtually synonymous with (1) above.</Paragraph>
      <Paragraph position="1"> 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&amp;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.</Paragraph>
      <Paragraph position="2"> When a match Js found, further conceptual checks are made on the enabled act to ensure that the action described &amp;quot;makes sense&amp;quot; with the particular objects currently fJlllng the slots In that acts description.</Paragraph>
      <Paragraph position="3"> When the match Is based on expectations derlved from the CONNECTO~ description of a container, the check Is a &amp;quot;contalner/contents check,&amp;quot; which attempts to ensure that the object found in the container may reasonably be expected to be found there. The sentence &amp;quot;John opened the bottle so ne could pull out the elephant&amp;quot;, 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.</Paragraph>
      <Paragraph position="4"> 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.</Paragraph>
      <Paragraph position="5"> The two CD acts that matched are then merged.</Paragraph>
      <Paragraph position="6"> 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.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="55" end_page="56" type="metho">
    <SectionTitle>
3.~ CAUSAL CHAIN CONSTRUCTION
</SectionTitle>
    <Paragraph position="0"> 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 &amp;quot;John turned on the faucet,&amp;quot; Is *John* &lt;~&gt; *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 &amp;quot;on&amp;quot; state for that object. The principle e~pectatlon for SOURCE objects is that the person ~o &amp;quot;turned on&amp;quot; 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.</Paragraph>
    <Paragraph position="1"> The representation for &amp;quot;he could drink&amp;quot; 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  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.</Paragraph>
    <Paragraph position="2"> 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.</Paragraph>
    <Paragraph position="3"> 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.</Paragraph>
    <Paragraph position="4"> The backward chaining Inferencer Is then called to generate any ~nown preconditions for the act INGEST.</Paragraph>
    <Paragraph position="5"> 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 &amp;quot;John turned on the faucet so .Mary could drlnK.&amp;quot;p the program would infer that Mary took the water from the faucet.</Paragraph>
    <Paragraph position="6">  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.</Paragraph>
    <Paragraph position="7"> 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.</Paragraph>
    <Paragraph position="8"> 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.</Paragraph>
    <Paragraph position="9"> 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.</Paragraph>
    <Paragraph position="10"> There are, however, two ways in which OPUS departs from the inference strategies of Mb~ORY= 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.</Paragraph>
    <Paragraph position="11"> ~ough is Known about the interactions of analysis and inference at this time for us to approach the two as  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.</Paragraph>
    <Paragraph position="12"> 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.</Paragraph>
    <Paragraph position="13"> 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.</Paragraph>
    <Paragraph position="14"> 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.</Paragraph>
    <Paragraph position="15"> 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 &amp;quot;tremendous amount of 'hidden' computation&amp;quot; necessary for the processing of any natm'al language text.</Paragraph>
  </Section>
class="xml-element"></Paper>