<?xml version="1.0" standalone="yes"?>
<Paper uid="P89-1005">
  <Title>Abstract Unification-Based Semantic Interpretation</Title>
  <Section position="3" start_page="0" end_page="34" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> Over the past several years, unification-based formalisms (Shieber, 1986) have come to be widely used for specifying the syntax of natural languages, particularly among computational linguists. It is less widely realized by computational linguists that unification can also be a powerful tool for specifying the semantic interpretation of natural languages. While many of the techniques described in this paper are fairly well known among natural-language researchers working with logic grammars, they have not been extensively discussed in the literature, perhaps the only systematic presentation being that of Pereira and Shieber (1987). This paper goes into many issues in greater detail than do Pereira and Shieber, however, and sketches what may be the first theoretical analysis of unification-based semantic interpretation. null We begin by reviewing the basic ideas behind unification-based grammar formalisms, which will also serve to introduce the style of notation to be used throughout the paper. The notation is that used in the Core Language Engine (CLE) developed by SKI's Cambridge Computer Science Research Center in Cambridge, England, a system whose semantic-interpretation component makes use of many of the ideas presented here.</Paragraph>
    <Paragraph position="1"> Fundamentally, unification grammar is a generalization of context-free phrase structure grammar in which grammatical:category expressions are not simply atomic symbols, but have sets of features with constraints on their values. Such constraints are commonly specified using sets of equations.</Paragraph>
    <Paragraph position="2"> Our notation uses equations of a very simple format--just ~eal;ure=value--and permits only one equation per feature per constituent, but we can indicate constraints that would be expressed in other formalisms using more complex equations by letting the value of a feature contain a variable that appears in more than one equation. The CLE is written in Prolog, to take advantage of the efficiency of Prolog unification in implementing category unification, so our grammar rules are written as Prolog assertions, and we follow Prolog conventions in that constants, such as category and feature names, start with lowercase letters, and variables start with uppercase letters. As an example, a simplified version of the rule for the basic subject-predicate sentence form might be written in our notation as (1) syn(s_np_vp, \[s: \[type=tensed\], np: \[person=P, hUm=N\] , vp: \[~ype=~ens ed, person=P, hum=N\] \] ).</Paragraph>
    <Paragraph position="3"> The predicate syn indicates that this is a syntax rule, and the first argument s_npovp is a rule identifier that lets us key the semantic-interpretation rules to the syntax rules. The second argument of syn is a list of category expressions that make up the content of the rule, the first specifying the category of the mother constituent and the rest specifying the categories of the daughter constituents. This rule, then, says that a tensed sentence (s: \[type=~ensed\]) can consist of a noun phrase (rip) followed by a verb phrase (vp), with the restrictions that the verb phrase must be tensed (type=tensed), and that the noun phrase and verb phrase must agree in person and number--that is, the person and num features of the noun phrase must have the same respective values as the person and mm features of the verb phrase.</Paragraph>
    <Paragraph position="4"> These constraints are checked in the process of parsing a sentence by unifying the values of features specified in the rule with the values of features in the constituents found in the input. Suppose, for instance, that we are parsing the sentence  Mary runs using a left-corner parser. If Mary is parsed as a constituent of category np:\[person=3rd,num=sing\], then unifying this category expression with np : \[person=P ,num=N\] in applying the sentence rule above will force the variables P and N to take on the values 3rd and s~_ug, respectively. Thus when we try to parse the verb phrase, we know that it must be of the category vp : \[type=tensed, person=3rd,num=sing\].</Paragraph>
    <Paragraph position="5"> Our notation for semantic-interpretation rules is a slight generalization of the notation for syntax rules. The only change is that in each position where a syntax rule would have a category expression, a semantic rule has a pair consisting of a &amp;quot;logical-form&amp;quot; expression and a category expression, where the logical-form expression specifies the semantic interpretation of the corresponding constituent. A semantic-interpretation rule corresponding to syntax rule (1) might look hke the following: (2) sem(s_np_vp,  \[(apply(Vp,Np), s : \[\] ), (~p,np: \[\] ), (Vp,vp: \[3 )\] ).</Paragraph>
    <Paragraph position="6">  The predicate sere means that this is a semantic-interpretation rule, and the rule identifier s..up_vp indicates that this rule applies to structures built by the syntax rule with the same identifier. The list of pairs of logical-form expressions and category expressions specifies the logical form of the mother constituent in terms of the logical forms and feature values of the daughter constituents. In this case the rule says that the logical form of a sentence generated by the s_np_vp rule is an applicative expression with the logical form of the verb phrase as the functor and the logical form of the noun phrase as the argument. (The dummy functor apply is introduced because Prolog syntax does not allow variables in functor position.) Note that there are no feature restrictions on any of the category expressions occurring in the rule. They are unnecessary in this case because the semantic rule applies only to structures built by the s_np_vp syntax rule, and thus inherits all the restrictions applied by that rule.</Paragraph>
  </Section>
class="xml-element"></Paper>