File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/81/j81-3002_metho.xml
Size: 29,212 bytes
Last Modified: 2025-10-06 14:11:22
<?xml version="1.0" standalone="yes"?> <Paper uid="J81-3002"> <Title>Translating Spanish into Logic through Logic</Title> <Section position="3" start_page="0" end_page="0" type="metho"> <SectionTitle> 3. The Internal Query Language: L3 </SectionTitle> <Paragraph position="0"> Informally, three kinds of L3 formulas can be distinguished: typed formulas t, statement formulas s, and integer formulas n.</Paragraph> <Paragraph position="1"> - a typed formula t denotes a subset of a given domain. It can be either a list of constants, a variable or an expression of the form &quot;those(x,s)&quot;.</Paragraph> <Paragraph position="2"> - a statement formula s evaluates to either true, false, or pointless. It can take any of the forms: r(tl ..... tn) where r is an n-ary predicate symbol corresponding to a distributive, collective or respective relation.</Paragraph> <Paragraph position="4"> - an integer formula nl denotes an integer number, and can take one of the forms: j where j is an integer such that j>0 card(t) Further details can be found in \[11\]. 4. Tools for Writing the Analyser A brief and informal introduction to logic programs and metamorphosis grammars is given here, for the sake of completeness. Fuller accounts can be found in \[5,19,20,29\].</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.1 On Logic Programming </SectionTitle> <Paragraph position="0"> Logic programs are essentially sets of clauses of the form: B <-- A1,A2 ..... An called Horn clauses, where B and Ai are atomic formulas, and all variables in the atomic formulas are understood to be universally quantified. &quot;<--&quot; is read &quot;if&quot;, and the commas stand for conjunction. An empty right-hand side denotes a non-conditional assertion of fact. For example,</Paragraph> <Paragraph position="2"> Rover likes every y who likes him In the rest of the paper (except for the figures), variables appear in italics in order to distinguish them from constants.</Paragraph> <Paragraph position="3"> With respect to a given set of clauses (i.e., a program), the user can ask for relations to be computed, by stating procedure calls, i.e., clauses of the form: <-- A1,A2,...,An This triggers an automatic demonstration process, during which the variables in the call take values for which &quot;A1 and A2 and ... and An&quot; holds. Here &quot;<--&quot; can be interpreted as a question mark. An unsuccessful termination implies that no such values exist.</Paragraph> <Paragraph position="4"> Thus, with respect to clauses 1 and 2 above, the following call:</Paragraph> <Paragraph position="6"> Who likes Rover? results in z being unified (bound) to &quot;mother(Rover)&quot;. The same result would have been obtained from the call: 4) <-- likes(z,Rover), likes(Rover,z) Who likes and is liked by Rover? Alternative results for the same call may be obtained within non-deterministic programs. For instance, if we add the clause: likes(Sweetie,Rover) <-then call 3 can alternatively result in z being bound to &quot;Sweetie&quot;.</Paragraph> <Paragraph position="7"> Practical logic program interpreters, such as PRO-LOG, also include some extra-logical features for input/output and control functions.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.2 On Metamorphosis Grammars </SectionTitle> <Paragraph position="0"> MGs are a powerful formalism for describing and processing languages, in which: - context-sensitive rewriting rules can be described. - any substring of any length can be rewritten into any other string.</Paragraph> <Paragraph position="1"> - grammar symbols may include arguments. - conditions on rule application may be specified. - sentence generation and parsing are provided by the processor.</Paragraph> <Paragraph position="2"> MGs can be regarded as a convenient alternative notation for logic programs. Rather than defining them precisely, we shall exhibit some sample grammar rules and show informally one way of translating them into Horn classes, that basically follows A. Colmerauer's PROLOG axiomatization of MGs. A formal and comprehensive description can be found in \[5\].</Paragraph> <Paragraph position="3"> 156 American Journal of Computational Linguistics, Volume 7, Number 3, July-September 1981 Grammar rules can be graphically represented by considering non-terminals as labeled arcs connecting phrase boundaries. A rule such as S --> A B is represented as</Paragraph> <Paragraph position="5"> or, in Horn-clause terms: arrow(S,xO,x2 ) <-- arrow(A,xO,xl ), arrow(B,xl ,x2 ) which can be read, for every xO, xl and x2, there is an arrow labeled S between points xO and x2 if there is an arrow labeled A between xO and xl and another one labeled B between xl and x2.</Paragraph> <Paragraph position="6"> Terminals in a rule are included as part of an edge's name and do not give rise to extra atoms. If a terminal symbol &quot;a&quot; labels an arc leading to point &quot;x&quot;, the starting point is named &quot;a.x&quot; (where .... is a binary operator in infix notation). Thus, the rule S --> a</Paragraph> <Paragraph position="8"> Strings of consecutive terminals are treated as a single one named after their concatenation.</Paragraph> <Paragraph position="9"> When the left-hand side of a rule contains more than one symbol, a single arrow is not enough to depict it: we need another path between the extreme points. For instance, the rule B a --> a B can be graphed as: B a.x a .......... >0 ...........</Paragraph> <Paragraph position="11"> where the lower path represents the right-hand side, as usual, and the upper path represents the left-hand side of the rule. In terms of Horn clauses, this gives: arrow(B,a.xO,a.x) <-- arrow(B,xO,x) Notice that no restrictions need be imposed on the length of the strings on either side of the rule.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.2.3 A Full Example </SectionTitle> <Paragraph position="0"> Completing the last two rules, we obtain an MG grammar for the language {anbncn}: where the value of x is of no interest to the user. In order that he need not specify it, a PROLOG predicate called &quot;syn&quot; (for &quot;synthesize&quot;) is made available. Its general form is syn(x,y) where x stands for the internal representation of the surface sentence y. The above commands are therefore actually written: MGs can also be written for the purpose of generating sentences. The same syn command is used for this purpose, except that this time the second argument is the one represented by a variable, e.g.: <-- syn(S,x) In some cases, it is even possible for the same grammar to work in both ways, although this requires a very careful design. In the rest of this paper, we shall only be concerned with parsing.</Paragraph> <Paragraph position="1"> We might normally want the parser to retrieve more information than mere recognition. The grammar shown above, for instance, can be also used to retrieve the substring of a's, if it is modified as follows: null Right-hand sides of rules may contain PROLOG calls (which we shall note between square brackets). They must be successfully evaluated for the rule to apply. For instance, retrieval of the number of a's can be obtained in the above grammar by changing the first two rules into:</Paragraph> <Paragraph position="3"> where &quot;plus&quot; is a PROLOG predicate defining addition of integers. PROLOG calls can also be used to enforce conditions on rule applications.</Paragraph> <Paragraph position="4"> PROLOG only accepts normalized G rules, i.e., of the form A x --> y The derivation graph for &quot;John laughs&quot; is shown in substitutions needed for applying the rule appear as right-hand side labels. Through them we can reconstruct the deep structure &quot;laugh(john)&quot;. where A is a non-terminal symbol, x is a string of terminals and y is any sequence of grammar symbols. This restriction is necessary, within the schema shown, for translating rules into Horn clauses (also called definite clauses), in which at most one left-hand side atomic formula is allowed. For this reason, they have also been called &quot;definite clause grammars &quot;t, in a recent article \[24\] which compares them favourably against the Augmented Transition Network formalism, introduced by Woods \[39\].</Paragraph> <Paragraph position="5"> As has been shown in \[5\], non-normalized rules can be easily replaced by an equivalent set of normalized ones. For instance, B a C b --> f g can be replaced by B a c b --> f g and C --> c, where c is a &quot;dummy&quot; terminal. From the parsing point of view, the results are equivalent.</Paragraph> <Paragraph position="6"> We can therefore safely ignore this restriction in all that follows, for the sake of clarity.</Paragraph> <Paragraph position="7"> Although MGs can be understood declaratively, it is sometimes useful to follow a sentence's complete derivation, by constructing a graph which depicts the top-down, left-to-right history of rule applications. We illustrate this through the grammar: 1) Sentence(s) --> Proper-noun(k) Verb(k,s) .</Paragraph> <Paragraph position="8"> 2) Proper-noun(tom) --> tom 3) Proper-noun(john) --> john 4) Verb(k,laugh(k)) --> laughs 1 In a restricted sense, DCGs only allow a single non-terminal on the left hand side, and are therefore an even more restricted form of MGs. A more accurate synonym for &quot;normalized MG&quot; might be &quot;full DCG&quot;--an expression suggested by D. Warren and F. Pereira in the first draft of \[24\].</Paragraph> <Paragraph position="9"> Notice that, once a variable takes a value, this value is propagated to each of its occurrences in the graph. Thus, when applying rule 4, we use the known value of k=john. Also, variable renaming must take place whenever necessary in order to ensure that the rule applied and the string it applies to share no variables. null</Paragraph> </Section> </Section> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> 5. Step-by-Step Development of a Spanish Analyser </SectionTitle> <Paragraph position="0"> We now develop a small Spanish parsing grammar, step by step. Although oversimplified, it illustrates practically all of the techniques used to develop the grammar shown in the Appendix (in the Microfiche Supplement). Deep structures and non-terminal symbols are in English, for the convenience of most readers. null</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 5.1 Elementary Statements </SectionTitle> <Paragraph position="0"> The following grammar describes some simple statements constructed around proper nouns, verbs and adjectives.</Paragraph> <Paragraph position="1"> Figure 5 shows the derivation graph for &quot;TomAs estA enojado con Juana&quot; (Tom is angry with Joan). Most of the substitutions shown concern the deep structure, x. The empty string is denoted by a lambda. Some non-terminal symbols are abbreviated. From the substitutions shown, we can see that x takes the value &quot;angry- with (tom,j oan)&quot;.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 5.2 Syntactic and Semantic Agreement </SectionTitle> <Paragraph position="0"> Syntactic agreement can be enforced by manipulating features such as gender and number within every rule concerned with syntactic checks. For instance, the modified rules: make it impossible to accept a sentence such as: TomAs estA enojada con Juana.</Paragraph> <Paragraph position="1"> Tom is angry (+fem.) with Joan.</Paragraph> <Paragraph position="2"> Semantic constraints can be enforced similarly. For a referential word to induce a distributive relation, for instance, we add a prefix such as 'dr' in the corresponding rule, e.g.:</Paragraph> <Paragraph position="4"> and establish the convention that unmarked predicates are assumed to be collective. The data base component of our system can thus distinguish each kind of relation and ensure an appropriate interpretation in each case.</Paragraph> <Paragraph position="5"> Types can be represented in the same way as syntactic information. But we want them to be built up during the parse, as a function of the various types involved in a given sentence. A quick way to achieve this is through unification. We can represent a type t in a manner that reflects set inclusion relations to other types, e.g.: nil&t&t l&...&tn where the ti are types such that E(t)cE(tl)c...cE(tn), and & is a binary operator in infix notation.</Paragraph> <Paragraph position="6"> Such representations may be partially specified, as in v&employee&human which can be matched with all those type representations for types contained in or equal to the &quot;employee&quot; type. For instance, v can take the values: nil nil&salesman nil&manager etc., according to the context.</Paragraph> <Paragraph position="7"> In general, noun definitions will have the most weight in determining types: since it is nouns that introduce data base domains, their associated types are usually completely specified. Although this convention American Journal of Computational Linguistics, Volume 7, Number 3, July-September 1981 159 Veronica Dahl Translating Spanish into Logic through Logic might result in rejecting as semantically anomalous sentences that might deserve closer inspection (e.g. &quot;Do all the animals speak Latin?&quot;), it would seem a reasonable compromise between speed and coverage.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 5.3 Noun Phrases </SectionTitle> <Paragraph position="0"> We now modify our grammar so as to handle quantified noun phrases. Agreement, both syntactic and semantic, is now left out for the sake of clarity.</Paragraph> <Paragraph position="1"> For explanatory purposes, let us imagine a NL quantifier as a device which creates a variable k and constructs a 'for' formula s out of k and of two given formulas sl and s2 (respectively standing for the noun phrase's and the verb phrase's translations). In terms of MG rules, this can be expressed as: Determiner(k,sl,s2,s) --> det where &quot;det&quot; is a given NL determiner. Two sample rules follow:</Paragraph> <Paragraph position="3"> A noun, in turn, can be imagined as a device that takes the variable created by the quantification and constructs a relation, as in the following example: NO1) Noun(k,friend(k)) --> amigo We can now relate a noun phrase to a verb phrase, through the rules:</Paragraph> <Paragraph position="5"> Thus, a noun phrase can be regarded as a device taking a formula s2 (the verb phrase's representation), and producing a variable k and a formula s that represents the whole statement. In the case of a proper noun, s merely takes the same value as s2.</Paragraph> <Paragraph position="6"> Notice that the order in which these devices are imagined to work is unimportant. They can be regarded as term (i.e., tree) constructors which fill in different gaps in those trees they share. For instance, the variable s2 in rule S, which stands for a term of the form r(tl ..... tn), is given such a form by the Verb device, while the Compls device fills in the values of its arguments. The Noun-phrase device, on the other hand, can be considered a consumer of s2: it uses s2 in order to build up s. It does not need s2 to be completely specified, however. It merely fits s2 into its place in s, expecting that sooner or later it will become completely specified. null We can now modify our rules for complements so that they will allow quantified noun phrases as well as proper nouns: Notice that these two simple rules are enough to handle verb, adjective, and noun complements. All we have to do is modify rules S and N2 as follows: and add extra rules for nouns, adjectives, or verbs that accept complements, e.g.: NO2) Noun(k l ,list(arg(of,k2),nil),friend-of(k l ,k2 ) ) --> amigo For uniformity, we rewrite NO1 into: NO1) Noun(k,nil,friend(k)) --> amigo The reader can now make a derivation graph for, for instance, &quot;El amigo de Juana ester enojado con Tom~s&quot; (Joan's friend is angry with Tom). The deep structure shown in Figure 6 should be obtained. where the Neg &quot;device&quot; takes a formula s and produces either s itself or not(s), according to whether the negation particle &quot;no&quot; is absent or present. In sentences like &quot;No vino ningfln alumno&quot; (No student came), there is subject-verb inversion, and negation is represented twice. The deep structure should read: &quot;For every student, it is stated that he did not come&quot;. To handle this situation, we take advantage of a non-terminal Case(c) which can explicitly record the role of a given noun phrase as subject. Our rules are augmented as follows: This marker is used to transform a surface 'ningfin' quantifier into 'todo' (every), provided it occurs in an inverted subject. Otherwise, the markers are erased: These rules implement our general treatment of negation described earlier.</Paragraph> <Paragraph position="7"> The non-terminal Case(c) is important also in handling complement noun phrases. Such noun phrases introduced by a preposition p will have associated case prep(p). Direct object noun phrases will have case &quot;dir&quot;, and so on. We generalize rule C2 to</Paragraph> </Section> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 5.5 Interrogative and Relative Clauses </SectionTitle> <Paragraph position="0"> As subject-verb inversion has already been defined, we can handle Spanish yes-no questions simply by adding:</Paragraph> <Paragraph position="2"> (Notice, by the way, that the analyser actually produces more information than the L3 formula s. The data base component uses this extra information to determine the form of the answer, to identify the set to be retrieved (as in rule SE3 below), etc.).</Paragraph> <Paragraph position="3"> Wh-questions, on the other hand, often require modifiers to be moved around and replaced by pronouns. For instance, &quot;D6nde vive Tomfis?&quot; (Where does Tom live?) can be considered as a variant for &quot;Tomfis vive en k&quot; (Tom lives in k), in which &quot;en k&quot; has been moved to the beginning of the sentence and replaced by &quot;D6nde&quot;.</Paragraph> <Paragraph position="4"> Relative clauses usually undergo similar transformations. For instance, &quot;El empleado cuya jefa es Juana&quot; (The employee whose manager is Joan) can be considered as a variant of &quot;El empleado \[la jefa del empleado\] es Juana&quot; (the employee \[the manager of the employee\] is Joan), where &quot;del empleado&quot; has shifted to just before &quot;jefa&quot; to be subsumed, together with &quot;la&quot;, by the relative pronoun &quot;cuya&quot;. To handle these clauses, we use markers in the form of grammar symbols; we move the concerned modifiers and then we use context-sensitive rules to replace the appropriate constituents by a pronoun. We illustrate this for interrogative sentences such as the above example. First we add an interrogative marker: Here &quot;...&quot; stands for any intermediate string of symbols, which the rule's application leaves untouched to the right of &quot;D6nde&quot;. Thus, the skeleton derivation graph would now be as shown in Figure 8. Two rules (C3 and SK) have been eliminated, and the resulting graph is clearer.</Paragraph> <Paragraph position="5"> Figure 7. MG skeleton derivation graph for &quot;Donde vive Tomas?&quot;. An alternative way of moving modifiers within MGs is by adding extra arguments to each non-terminal possibly dominating a modifier to be subsumed by a pronoun, as has been observed in \[25\]. It is however useful to be able to picture transformations through argument-stripped derivation graphs, as in the technique just exemplified. This leads naturally to ways of extending the MG formalism: Figure 7 suggests that movements might be achieved more easily if unidentified substrings can be referred to, so that whatever appears in between the expected pronoun and the mobile modifier can be skipped by the latter through a single rule. Such syntactic liberty is allowed in extraposition grammars (XGs) \[25\], where, for instance, rule PR cn be replaced by:</Paragraph> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> PR') Wh-l(k)... Modifier(k,sl,s2) --> D6nde 6. Extensions </SectionTitle> <Paragraph position="0"> Some of the limitations of our system are quite obvious from our discussion; e.g., pronoun references are not dealt with, other than for relative and interrogative pronouns. Possible extensions and related work include the following: More flexible modifier scoping rules. The ones described here were adopted as a compromise between linguistic power and computational speed. Our choice was constrained by the inconvenience of resorting to frequent tests within grammar rules. Although allowed in PROLOG, this facility was too costly in the minicomputer version available to us. Meaning distortions resulting from too rigid quantifier scoping were, however, partly compensated for by using contextual information available through unification to choose between alternative meanings of a given determiner. An interesting treatment of modifiers in logic grammars has been recently proposed in \[22\]. It involves a 162 American Journal of Computational Linguistics, Volume 7, Number 3, July-September 1981 Veronica Dahl Translating Spanish into Logic through Logic three-pass analyser, developed within a particularly modular framework, in which all syntactic structures are represented through a single format.</Paragraph> <Paragraph position="1"> ,4 subtler treatment of presupposition detection. Although the treatment discussed here allows for a quick detection of failed presuppositions, it fails to indicate their nature. More helpful answers should make explicit the user's wrong assumptions, and possibly correct them. The latest version of our system includes the former capability. These problems have been extensively addressed in \[17\], although not in the context of logic programs.</Paragraph> <Paragraph position="2"> Dialogue extensions, e.g. for data base creation and updating in natural language, for clarification of the user's intended meaning, etc. Some conversational facilities have been developed recently within a logic-programmed system for consulting library information in Portuguese \[2\].</Paragraph> <Paragraph position="3"> .4 wider linguistic output coverage. In its current version, our system only handles a few answer formats, constructed around the sets it retrieves and the truth values it assigns to the questions. A synthesizing grammar would be useful, particularly regarding more informative answers. Ideally, a single grammar should work both for sentence generation and parsing.</Paragraph> <Paragraph position="4"> Application to other language processing problems.</Paragraph> <Paragraph position="5"> Notice that our choice of using English words for the deep structures in Section 5 gives the parser a translating flavour. The fact that our system has been adapted to consultation in various natural languages without substantial modifications to either the parser or the internal language's features suggests that it might be possible to use a similar framework for language translation. Another possibility is to develop a single, multilingual grammar capable of switching to the user's mother tongue as soon as the dialogue opens.</Paragraph> <Paragraph position="6"> Finally, let us point out that the evolution in PROLOG's features is likely to make it possible to improve on the implementation, at least, of the ideas presented here. For instance, our set evaluation primitives rely too much upon exhaustive domain enumeration. While solving PROLOG's negation problem satisfactorily for small domains, this is inefficient for very large data bases.</Paragraph> <Paragraph position="7"> Our previous solution--query reordering \[6\]--was on the whole more adequate, but incurred the overhead of filtering each query through a coroutining interface. A recent DEC-10 PROLOG implementation of this solution \[31,32\], however, has proved very efficient in the Chat-80 system, which also shares other features with SOLAR 16 (namely, the minimization of the search space through query reordering and the addition of a set constructor predicate). Some of these features have actually been incorporated as standard into recent PROLOG versions (cf. in \[28\]), making it possible to develop more powerful systems at a low cost.</Paragraph> <Paragraph position="8"> Similarly, further MG extensions could make possible a wider linguistic coverage with no loss in efficiency. Provisions for right as well as left extraposition, for instance, would facilitate a full treatment of coordination. null</Paragraph> </Section> <Section position="7" start_page="0" end_page="0" type="metho"> <SectionTitle> 7. Concluding Remarks </SectionTitle> <Paragraph position="0"> Similar ideas to the ones discussed in this paper (in particular, those on quantification (cf. \[35\])) have influenced other NL data base systems, namely LUNAR \[30\] and PHLIQA1 \[1\]. But in spite of the points in common, our general approach is markedly different. We have tried to incorporate all relevant semantic as well as syntactic NL features into a single formalism, in order to do without intermediate sublanguages and have a single process perform the analysis of an input sentence. LUNAR, on the contrary, first generates deep structures and then maps them into a semantic representation. PHLIQA1 has several successive levels of semantic analysis, each requiring a special formal language. Some of them are meant to deal with ambiguity, which in our approach, as we have seen, is dealt with through the contextual typing of variables during the quantification process.</Paragraph> <Paragraph position="1"> A common disadvantage of this integrated approach--namely, that the syntactic/semantic grammar obtained is too domain-specific and therefore less transportable--is avoided by relegating all domain-specific knowledge to the domain-dependent part of the lexicon (i.e., noun, verb, and adjective definitions). Furthermore, the fact that semantic agreement is equated with syntactic well-formedness evens the relative costs of doing semantic versus syntactic tests.</Paragraph> <Paragraph position="2"> The use of logic as the single formalism underlying all aspects of our system's development is a distinctive feature of the approach. Logic serves both as the theoretical framework and as the implementation means, In particular, this gives our system a definitely non-procedural flavour: our programs, as we have seen, can be understood in purely declarative terms.</Paragraph> <Paragraph position="3"> The main strengths of our approach are, we feel: Uniformity. Within our data base system, programs, parser, data, semantic interpretation and query evaluation are uniformly represented.</Paragraph> <Paragraph position="4"> Formalization. Due to the generalized use of logic, important theoretical aspects--such as a rigorous characterization of our natural language subset and of the syntax and semantics of our internal query language--need not be dissociated from those practical aspects concerning the implementation.</Paragraph> <Paragraph position="5"> Conciseness. We have shown how a fairly compact, one-pass analyser can suffice to process a useful and extendible natural language subset.</Paragraph> <Paragraph position="6"> American Journal of Computational Linguistics, Volume 7, Number 3, July-September 1981 163 Veronica Dahl Translating Spanish into Logic through Logic Clarity. The parser is modular, in the sense that each rule can be understood declaratively by itself.</Paragraph> <Paragraph position="7"> Problem-independent concerns (e.g. backtracking, pattern-matching, etc.) are all left to PROLOG.</Paragraph> <Paragraph position="8"> Performance. These assets do not imply sacrificing efficiency. Parsing times have been shown to compare favourably against those of the LUNAR system \[30\], by using an adaptation of our Spanish analyser to English \[24, p.276\].</Paragraph> <Paragraph position="9"> As we have also seen, many improvements remain to be made. With the present study we hope to motivate further research into the uses of logic for natural language processing.</Paragraph> </Section> class="xml-element"></Paper>