File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/80/c80-1058_metho.xml
Size: 15,103 bytes
Last Modified: 2025-10-06 14:11:19
<?xml version="1.0" standalone="yes"?> <Paper uid="C80-1058"> <Title>UNIT-TO-UNIT INTERACTION AS A BASIS FOR SEMANTIC INTERPRETATION OF JAPANESE SENTENCES</Title> <Section position="1" start_page="0" end_page="0" type="metho"> <SectionTitle> UNIT-TO-UNIT INTERACTION AS A BASIS FOR SEMANTIC INTERPRETATION OF JAPANESE SENTENCES Hozumi TANAKA ELECTROTECHNICAL LABORATORY, 1-1-4 UMEZONO, SAKURA-MURA, NIIHARI-GUN, IBARAKI-KEN, JAPAN </SectionTitle> <Paragraph position="0"> ABSTRACT: The notion of UNIT-to-UNIT interaction is introduced to analyse dependency relations between words in a sentence. A UNIT is a basic framework for concept representation and is composed of many slots. After generating a parsed tree from an input sentence, our semantic interpretation begins traversing.the tree from right to left to discern the case frame in a stage as early as possible, since Japanese is a language in which verb is in the sentence-final and has a case frame. UNIT-to-UNIT interaction, which is performed at each node of the parsed tree, follows a bottom-up progression.</Paragraph> <Paragraph position="1"> There are UNIT descriptions at terminal (bottom) nodes and the UNIT descriptions are modified or merged into other UNITs in the course of the interaction. The results of the interaction will be transferred to upper nodes. The interaction process continues on upward until the top node; at this point, the semantic structure of the input sentence is finally obtained. The notion of UNIT-to-UNIT interaction is feasibly applicable to semantic interpretation of English.</Paragraph> <Paragraph position="2"> i. INTRODUCTION Semantic processing is very important for us to build a natural language (NL) understanding system. It will be true that semantics takes precedence over syntax when human beings understand language. Based on this assumption, some NL understanding system designers have totally abandoned the traditional use of grammars for linguistic analysis. They are based on special procedures of semantic interpretation to build up semantic structures, and the result of syntactic parsing is not used.</Paragraph> <Paragraph position="3"> Such systems without grammar often lack formalism.</Paragraph> <Paragraph position="4"> We should not totally abandon a traditional use of grammars for linguistic analysis, since results of syntactic parsing fill the gap between an input sentence and its semantic structure. We have developed Extended LINGOL \[13,12\] that is the extended version of Pratt's LINGOL \[8,9\]. Pratt's LINGOL has a very good formalism to merge syntactic and semantic information. The idea is that the result of syntactic parsing, a parsed tree, is considered as a program tree which is evaluated at the time of semantic interpretation. In the course of the interpretation, UNIT-to-UNIT interactions are performed. Thus a parsed tree of LINGOL corresponds to an analysis tree of Montague grammar and the evaluation phase of the parsed tree is analogous to the translation phase of Montague grammar \[3\] (See the See.6).</Paragraph> <Paragraph position="5"> Our Extended LINGOL inherits the semantic interpretation method from the original Pratt's LINGOL. After generating a parsed tree from an input sentence, semantic interpretation is set out. The parsed tree is composed of context-free rules to each of which a LISP program is attached. In other words, at each node of the tree, there is a program for making semantic interpretation. As will be explained in the Sec. 5.,UNIT-to-UNIT interaction will take place at each node of the program tree. The interaction process continues on upward until the top node, at which it stops getting the results of the semantic interpretation.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="metho"> <SectionTitle> 2. 4SEM>-PROGRAM TREE AND PARSED TREE </SectionTitle> <Paragraph position="0"> Our Extended LINGOL produces a parsed tree using both grammar and dictionary. The format of our grammatical rule is: ~<left> <right> i<advice> <cog>~ <sem>~.</Paragraph> <Paragraph position="1"> The left-right pair represents a context-free rule in the form of A--> B or A > B C. The <advice>, which is introduced into our Extended LINGOL, is an arbitrary LISP program for controlling parsing process \[13\]. The role of <cog> and <sem> is the same as that of Pratt's LINGOL \[9\]. The <sem> is any LISP program to perform semantic interpretation. The Pratt's LINGOL offers us a flexible method of semantic interpretation.</Paragraph> <Paragraph position="2"> In order to understand UNIT-to-UNIT interaction, we will briefly illustrate the interpretation method. By means of <sem> attached to each (augmented) context-free rule, we can obtain a <sem>-program tree from a parsed tree. Consider the following very simple example.</Paragraph> <Paragraph position="3"> The input sentence is &quot;iOKGNOOMOSANOMIZU (water of i0 kg)',, grammatical rules are:</Paragraph> <Paragraph position="5"> Fig.l is a parsed tree of &quot;iOKGNOOMOSANOMIZU.&quot; Fig.2(a) is a <sem>-program tree obtained from Fig.l. Fig.2(b) is the nesting structure of the <sem>-program tree of Fig.2(a) which defines the scope of variables. At lower nodes, we see values of variables at upper nodes. For instance, fro~ <S-exprA>, one can refer to the value of variables in <S-expr2> and <S-exprl>.</Paragraph> <Paragraph position="6"> Semantic interpretation begins with the evaluation of S-expression at the top node.</Paragraph> <Paragraph position="7"> There are several built-in functions two of which are LG and RG, which are evaluated at each <sem>-tree node with left and right branches.</Paragraph> <Paragraph position="8"> The evaluation sequence of LG and RG determines the evaluation sequence of S-expressions at one-level-lower nodes. For example, in <S-exprl>, if the evaluation of RG precedes that of LG, <S-expr3> is evaluated and then <S-expr2>. The result of RG evaluation becomes equal to that of <S-expr3> evaluation.</Paragraph> <Paragraph position="9"> Usually, at each node of the <sem>-program tree, UNIT-to-UNIT interaction takes place and the results of the interaction are transferred to one-level-upper node. As will be explained before, the role of a parsed tree is similar to that of an analysis tree of Montague grammar.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="metho"> <SectionTitle> 3. UNIT DESCRIPTION </SectionTitle> <Paragraph position="0"> A UNIT is a basic framework for concept representation and is composed of many slots.</Paragraph> <Paragraph position="1"> Our UNIT description incorporates some useful features from KRL \[i\] which was developed by Bobrow and Winograd. Fig.3(a) is an example of our UNIT descriptions.</Paragraph> <Paragraph position="3"> .................. I .................... Bg dl~jolntneee of same level UNIT:)</Paragraph> <Paragraph position="5"> The &quot;self&quot; slot which is present in each UNIT description enables us to understand the UNIT framework as a whole. As in KRL, the &quot;self&quot; slot is used for the hierarchical organization of UNITs and enables all information (slots) to transfer from superordinate UNIT to subordinate UNITs. For example, the &quot;self&quot; slot in MIZU (water) UNIT indicates that the superordinate UNIT of MIZU (water) is EKITAI (liquid).</Paragraph> <Paragraph position="6"> Our UNIT descriptions are slightly different from KRL descriptions. Semantic features are incorporated into each special slot named &quot;sf&quot;. The &quot;sf&quot; slot in MIZU (water) indicates that the semantic feature of MIZU is \[+natural\]. In order to express gross semantics of a UNIT description, we can use logical expressions of first-order predicate calculus. For example, gross semantics of MIZU UNIT is expressed as: <precondition> .. > <action>.</Paragraph> <Paragraph position="7"> As will be explained later, <precondition> and <action> act as though they are to-fill and when-filled method of KRL \[i\].</Paragraph> <Paragraph position="8"> Two UNITs, which relate to each other in UNIT-to-UNIT interaction, are cilled FILLER and ORIGIN. During the interaction, FILLER must satisfy some slot of ORIGIN. <Precondition> specifies conditions of FILLER filled in the slot.</Paragraph> <Paragraph position="9"> \[A\] <PRECONDITION> In order to satisfy some slot of ORIGIN, FILLER has to satisfy the <percondition>, which specifies not only semantics of FILLER but also Japanese surface cases that can follow FILLER in the sentence. <Precondition> is divided into two parts, <f-constraint> and <J-case>:</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> > MIZU (UNIT) > +natural (UNIT). </SectionTitle> <Paragraph position="0"> Hierarchical organization of UNITs is expressed as a set of logical entailments \[I0\]. For example, from Fig. 3(a) we will have Fig.3(b).</Paragraph> <Paragraph position="1"> We can regard Fig.3(b) as a set of axioms which is used in performing UNIT-to-UNIT interactions. The details will be explained in the Sec.5.</Paragraph> <Paragraph position="2"> <precondition>::= i<f-constraint> deg <J-case>\[. Semantics of FILLER is expressed by <f-constraint>. On the other hand, Japanese surface cases, which can follow FILLER in a sentence, are specified in <J-case>.</Paragraph> <Paragraph position="3"> For example, in BUSSITU (material) UNIT of Fig.3(a), there is an <unsatisfied> slot: (OMOSA ((%value (a OMOSA)) - -NO)).</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 4. ORDINARY SLOT </SectionTitle> <Paragraph position="0"> Most UNITs include a block of ordinary slots which are classified into two categories, <satisfied> and <unsatisfied>: <ordinary-slot>::= <satisfied>l<unsatisfied>. The format of two ordinary slots is: <satisfied>::=i<slot-name>=<value>~ <unsatisfied>::=~<slot-name> <precondition> (<action>)~.</Paragraph> <Paragraph position="1"> As a proeedual attachment \[i\], we use a production rule \[2,7\]. A pair of <precondition> and <action> expresses a production rule in the form of: The <slot-name> and <precondition> are OMOSA (weight) and ((%value (a OMOSA)) -NO), respectively. The <f-constraint> and <J-case> are (%value (a OMOSA)) and (- -NO), respectively. The <f-constraint> is expressed as follows: > %value(FILLER)A OMOSA(FILLER).</Paragraph> <Paragraph position="2"> (Note that logical &quot;and&quot; is always omitted in the description of <f-constraint>.) It is possible to describe any we~l-formed formula by using @OR and @NOT in <f-constraint>. For example, (%value (@OR (a WEIGHT) (a VOLUME))) is expressed as: of some ordinary slot, the <action> which is any LISP program is activated. Typical effects of <action> are: (i) Modification of UNITs and slots (2) Creation of new UNITs and new slots (3) Deletion of UNITs and slots.</Paragraph> <Paragraph position="3"> If no <action> is specified, the <unsatisfied> slot becomes <satisfied> slot, whose <value> becomes FILLER's name but the <slot-name> remains unchanged.</Paragraph> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> 5. UNIT-to-UNIT INTERACTION </SectionTitle> <Paragraph position="0"> As explained before, UNIT-to-UNIT interaction usually occurs at each node of <sem>-program tree. In other word, the structure of <sem>-program tree determines what UNITs should be interacted to each ~ther. For example, at <S-expr4> of Fig.2(b), both UNITs of &quot;IOKG&quot; and &quot;OMOSA (weight)&quot; are related by UNIT-to-UNIT interaction.</Paragraph> <Paragraph position="1"> Two UNITs, which relate to each other in UNIT-to-UNIT interaction, are called FILLER and ORIGIN. During the interaction, FILLER must satisfy some <unsatisfied> slot of ORIGIN. If it is impossible to find out any satisfiable slot in ORIGIN, superordinate UNITs of ORIGIN will be retrieved through &quot;self&quot; until some satisfiable slot will be found. The satisfiability is determined by FILLER and <precondition> in an ordinary slot of ORIGIN.</Paragraph> <Paragraph position="2"> At first, a surface case which follows FILLER is checked by using <J-case> in <precondition>. If this checking succeeds, then the semantics of FILLER is checked by using <f-constraint> in <precondition>. These checkings are expressed as follows: Given the semantics of FILLER and a set of axioms as shown in Fig.3(b), then examine whether <f-constraint> hold or not.</Paragraph> <Paragraph position="3"> Let us consider two simple examples. As explained before, at <S-expr4> of Fig.2(b), the following two UNITs are interacted to each ..... .,.......o...).</Paragraph> <Paragraph position="4"> In this case, if a Japanese surface case of NO (&quot;of&quot;) follows FILLER, then FILLER can satisfy VALUE-slot of (VALUE ((%value (a OMOSA)) -NO) <action-l>), since the semantics of FILLER is:</Paragraph> <Paragraph position="6"> If the VALUE-slot is satisfied by FILLER, <action-l> will be activated to make further semantic interpretation if necessary. Let us consider another example: where the words, SOSOGU, EKITAI and MIZU in Japanese are POUR, LIQUID and WATER in English, respectively.</Paragraph> <Paragraph position="7"> If a Japanese surface case of WO follows FILLER, the slot (THEME ((a EKITAI) -WO)) is satisfied by FILLER, because the semantics of</Paragraph> <Paragraph position="9"> and from a set of axioms as shown in Fig.3(b), we get ~x (MIZU (x) ~> EKITAI (x)).</Paragraph> <Paragraph position="10"> It is easy to show that the following <f-constraint> holds: > EKITAI(FILLER).</Paragraph> <Paragraph position="11"> As the result of the interactions, the slot of (THEME ((a EKITAI) -WO)) becomes a <satisfied> slot of (THEME = MIZU).</Paragraph> </Section> <Section position="7" start_page="0" end_page="0" type="metho"> <SectionTitle> 6. SIMPLE EXAMPLE OF SEMANTIC INTERPRETATION BY UNIT-to-UNIT INTERACTION </SectionTitle> <Paragraph position="0"> Let us trace semantic interpretation - 386 process by UNIT-to-UNIT interaction, provided that the input sentence is &quot;IOKGNOOMOSANOMIZU.&quot; The parsed tree and its <sem>-program tree are shown in Fig.l, Fig.2(a) and Fig.2(b).</Paragraph> <Paragraph position="1"> Depending on the evaluation sequence of LG and RG, we can traverse <sem>-program tree in any order (see the Sec.2). Suppose <sem>-program of</Paragraph> </Section> class="xml-element"></Paper>