<?xml version="1.0" standalone="yes"?>
<Paper uid="C90-3052">
  <Title>Typed Unification Grammars</Title>
  <Section position="4" start_page="293" end_page="293" type="metho">
    <SectionTitle>
JOHN
CONS \[Fm.s'r: CONS \[FroST: LIKES L,-,:ST: LR .&lt;T: ONS V&amp;quot;ST: AR*l\]t,, sr:
</SectionTitle>
    <Paragraph position="0"> j j which is a well-formed list. with respect to the LIST definition. (We shall use in the following a more concise syntax for lists: END will be written as 0; CONS\[FIRsT:WORD, nEs'r:klST\] will be written as (WORD . LIST); lists will be written using the usual abbreviation for lists: the list of words &amp;quot;John likes Mary&amp;quot; will then be written as (JOHN LIKES MARY}).</Paragraph>
    <Section position="1" start_page="293" end_page="293" type="sub_section">
      <SectionTitle>
3.2 The APPEND type as a relation
</SectionTitle>
      <Paragraph position="0"> One can also understand feature types as relations much like those in PROLOG. Let us recall the classical PROLOG definition of append: append( \[\] ,L,L).</Paragraph>
      <Paragraph position="1"> append( \[XlL1\] ,L2, \[XlL3\] ) :- append(L1,L2,L3). in I&gt;ROLOG, the arguments of a term are identified by their positions in the term, and the presence  of all arguments is mandatory. In an FS, arguments (feature vahles) are not identified by their position but by a label, the feature, and the absence of an attrilmte-value pair will denote any kind of value for this attribute (type T). Using the TFS syntax, where the symbol ':-' after an FS introduces a condition, a definition for append can be as follows: APPEND = iF: 0, iS: \[i~LIST, W: \[~\]\] V iF: (\[XJ * gi\]), .: \[\]~L,ST, w:(~ . 1i~1)\] : -- APPEND\[F: ~.t-~, 13: \[~\], W: \[~\].</Paragraph>
      <Paragraph position="2"> Note that the tagging syntax allows to specification of identity between structures and a partial instance of the structure. This possibility (together with the fact. that typing iv enforced by the system) allows the writing of a typed version of append, in contrast to the untyped PROLOG version.</Paragraph>
    </Section>
    <Section position="2" start_page="293" end_page="293" type="sub_section">
      <SectionTitle>
3.3 Type checking as deduction
</SectionTitle>
      <Paragraph position="0"> Contrary to PROLOG, there is no distinction in TFS between top-level types (which could be interpreted as predicates) and inner types (which could be interpreted as arguments): they are all typed FSs, and the same deduction mechanism applies for the top-level structure ~s well as for all substructures. A (typed) FS is consistent with respect to a set of type definitions if it unifies with the definition of its type, and if each of its substructures is also consistent.</Paragraph>
      <Paragraph position="1"> Conditions like in the definition of append above introduce additional constraints which are erased after having been successfidly evaluated. When a type iv defined as a disjunction, a structure has to be consistent with at, least, one element of the disjunction (but all possibilities are explored, creating as many possible solutions as there are disjuncts). When a type is defined as a conjunction (using the AND operator noted &amp;quot;A&amp;quot;), a structure has to be consistent with every single element of the conjunction. The order used for type checking (roughly top-down) guarantees that the solution the system finds is the GLB of the set of definitions augmented by the initial structure \[2\].</Paragraph>
      <Paragraph position="2"> For example, the (typed) FS AGR\[num:PLUR\] is consistent with regard to the set of definitions above (Sect.l). The interpreter will apply the definition of AGR at the root of the</Paragraph>
      <Paragraph position="4"> cause the types MASC ail(\] NUM have only J_, the bottom of the lattice, ~s a common snl)type representing inconsistent information. Note that this type checking process may introduce new type symbols also used for checking, thus defining a type inheritance mechanism.</Paragraph>
      <Paragraph position="5"> A full evaluation of APPEND\[w:(A B}\] produces a set of three FSs: i F: 0, &amp;quot;: ID(A B), w: ~\] v F: &lt;~A. (&gt;), .: ~(B), w: &lt;t~. r~&gt;\] v e: (~A. (m@,.: r~0,~: (@ * (m .~&gt;)\]</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="293" end_page="294" type="metho">
    <SectionTitle>
4 Typed unification grammars
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="293" end_page="294" type="sub_section">
      <SectionTitle>
4.1 DCGs
</SectionTitle>
      <Paragraph position="0"> In this section, we describe how one can (but should not) write grammars using this formalism. To make comparisons easier, we will start from the small example of DCG presented in \[Pereira and Warren 80\] and show how this grammar (Fig.2) can be written in TFS.</Paragraph>
      <Paragraph position="2"> is_determiner(all, plural).</Paragraph>
      <Paragraph position="3"> is_noun(man, singular, ma isJ~oun(men, phlral, man).</Paragraph>
      <Paragraph position="4"> is_name(mary).</Paragraph>
      <Paragraph position="5"> is_trans(likes,singular, like) is_trans(like, plural, like). In a specification like this, there are three different kinds of information mixed together. Take for example the rule &amp;quot;noun_phrase(Num, np(Det, Noun)) determiner(Num, Det), noun(Num, Noun)&amp;quot;. In &amp;quot;this rule we find:  1. a specification of a set of wcll-formed sub-strings using the CF skeleton: noun_phrase --~ determiner, noun; 2. a specification of well-formed (partial) syntactic structures: the structure np(Det, Noun) is well-formed if Det and Noun are a well-formed structure and if its agreement value (variable Num) is the same for the Det, the Noun, and the noun_phrase; 3. a specification of a relation between well- null formed (partial) syntactic structures and well-formed substrings by augmenting the CF skeleton with annotations representing those structures. null</Paragraph>
    </Section>
    <Section position="2" start_page="294" end_page="294" type="sub_section">
      <SectionTitle>
4.2 A TFS specification
</SectionTitle>
      <Paragraph position="0"> All this information mixed together can be separated out and specified in a more modular way.</Paragraph>
      <Paragraph position="2"> The relation between strings and structures should be stated independently of well-formedness conditions on syntactic structures.</Paragraph>
      <Paragraph position="3"> It is expressed here in CF manner by using the APPEND relation on strings. (However, we do not advocate the exclusive use of CF-like relations; more complex ones can be specified to gain expressive power, e.g. by incorporating linear precedence rules).</Paragraph>
      <Paragraph position="5"/>
    </Section>
    <Section position="3" start_page="294" end_page="294" type="sub_section">
      <SectionTitle>
4.3 Parsing and generation
</SectionTitle>
      <Paragraph position="0"> Both parsing and generation in the system amount to type inference. Either (1) for parsing or (2) generation yield the same result (3).</Paragraph>
      <Paragraph position="1">  (1) SENTENCE\[sTRING: (Mary likes all men)\] (2) SENTENCE NP: NP\[NAME: MARY\] Iv: LIKE ALL, o : MANIJ (3) SENTENCE &amp;quot;sTR,NG: (lEMony \[\]like, \[\]a, Rime.) C-STR: S ~: NP\[...E: MARY\[woRD: I~\], .oR: aSG\] vP: VP I v: UKE\[woRD: \[\], AGR: ~\] NP: NP \[DET: ALL\[WORD: \[~, AOR: \[~PL\]\] |NOUN: MAN\[woRD: \[~, AGR: \[b\]\] /</Paragraph>
    </Section>
  </Section>
  <Section position="6" start_page="294" end_page="295" type="metho">
    <SectionTitle>
L^o~: \[\] J
AGR: \[\]
</SectionTitle>
    <Paragraph position="0"> This shows that the formalism has the same power as PI~OLOG to synthesize unspecified arguments, and the same evaluation mechanism can be used for both generation and parsing, depending on the input.</Paragraph>
    <Section position="1" start_page="295" end_page="295" type="sub_section">
      <SectionTitle>
4.4 From DCG to HPSG
</SectionTitle>
      <Paragraph position="0"> In the following, we explain how one can generalize the principles used for describing a DCG grammar in TFS to write an HPSG-like grammar. HPSG linguistic objects of all kinds, be they syntactic, phrase-structural, or semantic, are modeled by feature structures \[14\]. In addition, HPSG relies heavily on the notion of type. Hence, TFS is perfectly suited for an implementation of HPSG. The grammar itself is purely declarative in the sense that it characterizes what constraints should hold on linguistic objects independently of the order in which these constraints are actually applied.</Paragraph>
      <Paragraph position="1"> We first generalize the description of linguistic structures: instead of defining explicit types for sentences, noun phrases, etc., we define a generic constituent structure for any kind of phrase. According to the specification of ItPSG linguistic objects, we define SIGNs as being either of type PHRASAL_SIGN or of type LEXICAL-SIGN \[15\]. A SIGN has a phonological value, represented as a list of words, and syntactic and semantic information (omitted for this comparison). The subtypes PHttASAL.SIGN and LEXICAL-SIGN inherit all the attributes and type restrictions of SIGN.</Paragraph>
      <Paragraph position="2">  by having an additional dtrs ('daughters&amp;quot;) attribute that gives information about the (lexical or phrasal) signs which are their immediate constituents. This attribute encodes the kind of information about constituency conventionally described as constituent structures. In addition, the various daughters are distinguished according to what kinds of information they contribute to the sign as a whole. Thus, daughters are classified as heads and complements as in the standard X-bar theory. In order to be a well formed object of type PHRASAL-SIGN, a linguistic object has to obey some general principles such as the &amp;quot;Head Feature Principle&amp;quot; and the &amp;quot;Sub- null categorization Feature Principle&amp;quot;.</Paragraph>
      <Paragraph position="3"> (5) phrasal-sign----(HEAD_FP A SUBCAT-FP A ... A (CH_CO_FP V HC*.CO-FP ...)) A LCOMP- DTI~S: LIST_OF_SIGNSJ (6) lexical_sign ----VERB V PNOUN V NOUN V DET V .</Paragraph>
      <Paragraph position="4">  General principles The &amp;quot;Head Feature Principle&amp;quot; ensures that the head features of the head-daughter always be shared with their phrasal projections. It generalizes the passing of agreement information from e.g. a verb to the VP for all kind of constituent and for all information related to agreement and subcatcgorisation.</Paragraph>
      <Paragraph position="5"> \[s.,.N: \[..E.,,o: I-~-al\] \] (7') HEAD_FP .--- L D~rp's: \[.EA~o&amp;quot;rp.: \[sv.: \[HEAD: Iii~\]\]\] In the DCG example, subcategorization was expressed by introducing different kinds of lexical categories like transitive verb (TV) vs. intransitive verbs IV). In HPSG, subcategorization is expressed by usng a list of signs. Thislist specifies the number and kind of signs that the head subcategorizes for the formation of a complete sign. Subcategorization information is described in lexical entries. The &amp;quot;Subcat Feature Principle&amp;quot; ensures that in any phrasal sign, the subcat list of the head-daughter is the concatenation of the list of complement daughters and the subcat list of the mother. (The order of the elements in the complements list does not reflect the surface order but rather the more abstract &amp;quot;obliqueness hi-</Paragraph>
      <Paragraph position="7"> Grammar rules Just as we have generalized the notion of constituency, we are also able to generalize the relations between phonological representations and their desired constituent structure representations. The specialized CF-like relations for a sentence, a noun phrase, and so on in the DCG example can be replaced by two more general rules which specify constituent structure configurations according to the X-bar theory.</Paragraph>
      <Paragraph position="8"> The &amp;quot;Complement Head Constituent Order Feature Principle&amp;quot; (9) simply states that a &amp;quot;saturated phrasal sign&amp;quot; (i.e. with \[syn: \[subcat:0\]\] ) is the combination of an unsaturated phrasal head with one phrasal complement (e.g. S --+ NP VP).</Paragraph>
      <Paragraph position="9">  sign&amp;quot; is the combination of a lexical head and any number of complements (e.g. VP --* V XP*). The relation ORDER_COMPL is used for specifyinl,,C/-the ordering of the phonological values of all complements. The phonological value of the whole phrase can then be specified as the concatenation of the head phonology value with the complement phonology value.</Paragraph>
      <Paragraph position="11"/>
    </Section>
  </Section>
class="xml-element"></Paper>