<?xml version="1.0" standalone="yes"?>
<Paper uid="P90-1020">
  <Title>TYPES IN FUNCTIONAL UNIFICATION GRAMMARS</Title>
  <Section position="4" start_page="157" end_page="158" type="metho">
    <SectionTitle>
2 TRADITIONAL FUNCTIONAL
UNIFICATION ALGORITHM
</SectionTitle>
    <Paragraph position="0"> The Functional Unifier takes as input two descriptions, called functional descriptions or FDs and produces a new FD if unification succeeds and failure otherwise.</Paragraph>
    <Paragraph position="1"> An FD describes a set of objects (most often linguistic entities) that satisfy certain properties. It is represented by a set of pairs \[a:v\], called features, where a is an attribute (the name of the property) and v is a value, either an atomic s3anbol or recursively an FD. An attribute a is allowed to appear at most once in a given FD F, so that the phrase &amp;quot;the a of F&amp;quot; is always non ambiguous (Kay, 1979).</Paragraph>
    <Paragraph position="2"> It is possible to define a natural partial order over the set of FDs. An FD Xis more specific than the FD Y if X contains at least all the features of Y (that is X _c Y). Two FDs are compatible if they are not contradictory on the value of an attribute. Let X and Y be two compatible FDs. The unification of X and Y is by definition the most general FD that is more specific than both X and Y. For example, the unification of {year:88, time: {hour:5} } and {time:{mns:22}, month:10} is {year:88, month: i0, time: {hour: 5, mns:22 } }.</Paragraph>
    <Paragraph position="3"> When properties are simple (all the values are atomic), unification is therefore very similar to the union of two sets: XuY is the smallest set containing both X and Y. There are two problems that make unification different from set union: first, in general, the union of two FDs is not a consistent FD (it can contain two different values for the same label); second, values of features can be complex FDs. The mechanism of unification is therefore a little more complex than suggested, but the FU mechanism is abstractly best understood as a union operation over FDs (cf (Kay, 1979) for a full description of the algorithm).</Paragraph>
    <Paragraph position="4"> Note that contrary to structural unification (SU, as used in Prolog for example), FU is not based on order and length. Therefore, { a : 1, b : 2 } and { b : 2, a : 1 \] are equivalent in FU but not in SU, and { a : 1 } and {b:2, a:l } are compatible in FU but not in SU (FDs have no fixed arity) (cf. (Knight, 1989, p.105) for a comparison SU vs. FU).</Paragraph>
    <Paragraph position="5"> TERMINOLOGY: We introduce here terms that constitute a convenient vocabulary to describe our extensions. In the rest of the paper, we consider the unification of two FDs that we call input and grammar. We define L as a set of labels or attribute names and C as a set of constants, or simple atomic values. A string of labels (that is an element of L*) is called a path, and is noted &lt;11...11,&gt;. A grammar defines a domain of admissible paths, A c L*. A defines the skeleton of well-formed FDs.</Paragraph>
    <Paragraph position="6"> * An FD can be an atom (element of 6') or a set of features. One of the most attractive characteristics of FU is that non-atomic FDs can be abstractly viewed in two ways: either as a fiat list of equations or as a structure equivalent to a directed graph with labeled arcs (Karttunen, 1984). The possibility of using a non-structured representation removes the emphasis that has traditionally been placed on structure and constituency in language.</Paragraph>
    <Paragraph position="7"> * The meta-FDs NONE and ANY are provided to refer to the status of a feature in a description rather than to its value.</Paragraph>
    <Paragraph position="8"> \[label:NONE\] indicates that label cannot have a ground value in the FD resulting from the unification.</Paragraph>
    <Paragraph position="9"> \[label:ANY\] indicates that label ~- must have a ground value in the resulting FD. Note that NONE is best viewed as imposing constraints on the definition of A: an equation &lt;II...ln&gt;=NONE means that  &lt;ll...ln &gt; ~ A.</Paragraph>
    <Paragraph position="10">  * A constituent of a complex FD is a distinguished subset of features. The special label CSET (Constituent Set) is used to identify constituents. The value of CSET is a list of paths leading to all the constitueuts of the FD. Constituents trigger recursion in the FU algorithm. Note that CSET is part of the formalism, and that its value is not a valid FD. A related construct of the formalism, PATTERN, implements ordering constraints on the strings denoted by the FDs.</Paragraph>
    <Paragraph position="11"> Among the many unification-based formalisms, the constructs NONE, ANY, PATrEKN, CSET and the notion of constituent are specific to FUGs. A formal semantics of FUGs covering all these special constructs is presented in (Elhadad, 1990).</Paragraph>
  </Section>
  <Section position="5" start_page="158" end_page="158" type="metho">
    <SectionTitle>
3 TYPED FEATURES
</SectionTitle>
    <Paragraph position="0"> A LIMITATION OF FUGS: NO STRUCTURE OVER THE SET OF VALUES: In FU, the set of constants C has no structure. It is a fiat collection of symbols with no relations between each other. All constraints among symbols must be expressed in the grammar. In linguistics, however, grammars assume a rich structure between properties: some groups of features are mutually exclusive; some features are only defined in the context of other features.</Paragraph>
    <Paragraph position="1">  Let's consider a fragment of grammar describing noun-phrases (NPs) (cf Figure 1) using the systemic notation given in (Winograd, 1983). Systemic networks, such as this one, encode the choices that need to be made to produce a complex linguistic entity. They indicate how features can be combined or whether features are inconsistent with other combinations. The configuration illustrated by this fragment is typical, and occurs very often in grammars. 1 The schema indicates that a noun can be either a pronoun, a proper noun or a common noun. Note that these 1We have implemented a grammar similar to OVinograd, 1983, appendix B) containing 111 systems. In this grammar, more than 40% of the systems are similar to the one described here.  three features are mutually exclusive. Note also that the choice between the features { question, personal, demonstrative, quantified} is relevant only when the feature pronoun is selected.</Paragraph>
    <Paragraph position="2"> This system therefore forbids combinations of the type { pronoun, proper } and { common, personal }.</Paragraph>
    <Paragraph position="3"> The traditional technique for expressing these constraints in a FUG is to define a label for each non terminal symbol in the ~stem. The resulting gram2 mar is shown in Figure 2. This grammar is, however, incorrect, as it allows combinations of the type ( (noun proper) (pronoun question) ) or even worse ( (noun proper) (pronoun zouzou) ). Because unification is similar to union of features sets, a feature (pronoun question) in the input would simply get added to the output. In order to enforce the correct constraints, it is therefore necessary to use the meta-FD NONE (which prevents the addition of unwanted features) as shown in Figure 3.</Paragraph>
    <Paragraph position="4"> There are two problems with this corrected FUG implementation. First, both the input FD describing a pronoun and the grammar are redundant and longer than needed. Second, the branches of the alternations in the grammar are interdependent: you need to know in the branch for pronouns that common nouns can be sub-categorized and what the other classes of nouns are. This interdependence prevents any modularity: if a branch is added to an alternation, all other branches 2ALT indicates that the lists that follow are alternative noun types. 159 need to be modified. It is also an inefficient mechanism as the number of pairs processed during unification is O (n ~) for a taxonomy of depth d with an average ofn branches at each level.</Paragraph>
    <Paragraph position="5"> TYPED FEATURES: The problem thus is that FUGs do not gracefiilly implement mutual exclusion and hierarchical relations. The system of nouns is a typical taxonomic relation. The deeper the taxonomy, the more problems we have expressing it using traditional FUGs.</Paragraph>
    <Paragraph position="6"> We propose extracting hierarchical information from the FUG and expressing it as a constraint over the symbols used. The solution is to define a subsumption relation over the set of constants C. One way to define this order is to define types of symbols, as illustrated in Figure 4. This is similar to V-terms defined in (Ait-Kaci, 1984).</Paragraph>
    <Paragraph position="7"> Once types and a subsumption relation are defined, the unification algorithm must be modified. The atoms X and Y can be unified ff they are equal OR if one subsumes the other. The resuR is the most specific of X and Y. The formal semantics of this extension is detailed in (Elhadad, 1990).</Paragraph>
    <Paragraph position="8"> With this new definition of unification, taking advantage of the structure over constants, the grammar and the input become much smaller and more readable as shown in Figure 4. There is no need to introduce artificial labels. The input FD describing a pronoun is  personal)). Because values can now share the same label CAT, mutual exclusion is enforced without adding any pair \[ 1 : NONE\] .3 Note that it is now possible to have several pairs \[a :v i \] in an FD F, but that the phrase &amp;quot;the a of F&amp;quot; is still non-ambiguous: it refers to the most specific of the v i. Finally, the fact that there is a taxonomy is explicitly stated in the type definition section whereas it used to be buried in the code of the FUG. This taxonomy is used to document the grammar and to check the validity of input FDs.</Paragraph>
  </Section>
  <Section position="6" start_page="158" end_page="158" type="metho">
    <SectionTitle>
4 TYPED CONSTITUENTS: THE FSET
CONSTRUCT
</SectionTitle>
    <Paragraph position="0"> A natural extension of the notion of typed features is to type constituents: typing a feature restricts its possible values; typing a constituent restricts the possible features it can have.</Paragraph>
    <Paragraph position="1"> Figure 5 illustrates the idea. The define constituent statement allows only the four given features to appear under the constituent determiner. This statement declares what the 3In this example, the grammar could be a simple flat alternation ((cat ((alt (noun pronoun personal-pronoun .., common mass-noun count-noun))))), but this expression would hide the structure of the gIan~n~. 16 0 grammar knows about determiners. Define constituent is a completeness constraint as defined in LFGs (Kaplan &amp; Bresnan, 1982); it says what the grammar needs in order to consider a constituent complete. Without this construct, FDs can only express partial information.</Paragraph>
    <Paragraph position="2"> Note that expressing such a constraint (a limit on the arity of a constituent) is impossible in the traditional FU formalism. It would be the equivalent of putting a NONE in the attribute field of a pair as in NONE:NONE.</Paragraph>
    <Paragraph position="3"> In general, the set of features that are allowed under a certain constituent depends on the value of another feature. Figure 6 illustrates the problem. The fragment of grammar shown defines what inherent roles are defined for different types of processes (it follows the classification provided in (Halliday, 1985)). We also want to enforce the constraint that the set of inherent roles is &amp;quot;closed&amp;quot;: for an action, the inherent roles are agent, medium and benef and nothing else. This constraint cannot be expressed by the standard FUG formalism. A define constituent makes it possible, but nonetheless not very efficient: the set of possible features under the constituent inherent-roles depends on the value of the feature process-type. The first part of Figure 6 shows how the correct constraint can be implemented with define constituent only: we need to exclude all the roles that are not defined  for the process-type. Note that the problems are very similar to those encountered on the pronoun system: explosion of NONE branches, interdependent branches, long and inefficient grammar.</Paragraph>
    <Paragraph position="4"> To solve this problem, we introduce the construct FEET (feature set). FEET specifies the complete set of legal features at a given level of an FD. FEET adds constraints on the definition of the domain of admissible paths A. The syntax is the same as CSET. Note that all the features specified in FEET do not need to appear in an FD: only a subset of those can appear.</Paragraph>
    <Paragraph position="5"> For example, to define the class of middle verbs (e.g., &amp;quot;to shine&amp;quot; which accepts only a medium as inherent role and no agent), the following statement can be unified with the fragment of grammar given in Figure  The feature (FEET (medium)) can be unified vAth (FSET (agent medium benef)) and the result is (FSET (medium)).</Paragraph>
    <Paragraph position="6"> Typing constituents is necessary to implement the theoretical claim of LFG that the number of syntactic functions is limited. It also has practical advantages. 161 The first advantage is good documentation of the grammar. Typing also allows checking the validity of inputs as defined by the type declarations.</Paragraph>
    <Paragraph position="7"> The second advantage is that it can be used to define more efficient data-structures to represent FDs. As suggested by the definition of FDs, two types of data-structures can be used to internally represent FDs: a fiat list of equations (which is more appropriate for a language like Prolog) and a structured representation (which is more natural for a language like Lisp). When all constituents are typed, it becomes possible to use arrays or hash-tables to store FDs in Lisp, which is much more efficient We are currently investigating alternative internal representations for FDs (cf. (Pereira, 1985, Karttunen, 1985, Boyer, 1988, Hirsh, 1988) for discussions of data-structures and compilation of FUGs).</Paragraph>
  </Section>
class="xml-element"></Paper>