<?xml version="1.0" standalone="yes"?>
<Paper uid="W91-0102">
  <Title>Reversibility in a Constraint and Type based Logic Grammar: Application to Secondary Predication</Title>
  <Section position="1" start_page="0" end_page="0" type="abstr">
    <SectionTitle>
Abstract
</SectionTitle>
    <Paragraph position="0"> In this document, we present a formalism for natural language processing which associates type construction principles to constraint logic programming. We show that it provides more uniform, expressive and efficient tools for parsing and generating language. Next, we present two abstract machines which enable us to design, in a symmetric way, a parser and a generator from that formalism. This abstract machinery is then exemplified by a detailed study of secondary predication within the framework of a principled-based description of language: Government and Binding theory.</Paragraph>
    <Paragraph position="1"> Introduction Lexical as well as grammatical and discursive knowledge required to understand or to produce natural language utterances is usually a description which is independent of the sentence production or comprehension 'algorithms'. It comes naturally into mind to have a common, shared knowledge base of what language is, independently of its potential uses. Besides well-known advantages of uniformity and transparency, this point of view is very convenient for the computer scientist who does not have to integrate into his parsers or generators the unavoidable updafings required by grammar development. The linguistic knowledge is thus specified in a declarative way in different modules (lexical, grammatical, discursive .... ) and different strategies are applied which refer to these data (directly for interpreters or via the production of a compiled code for compilers). This approach can however be realiTed more or less easily depending on the formalisms used to describe language phenomena.</Paragraph>
    <Paragraph position="2"> In this document we introduce new advanced tools of the Logic Programming framework and show that they contribute to meeting the requirements imposed by the manipulation and the control of large amounts of data required by both the parsing and the generation procedure. We first consider logical types which are a declarative and easy-to-use tool and formalism which permit a grammar writer to encode knowledge in a very flexible and principled-based way.</Paragraph>
    <Paragraph position="3"> In addition to types, we introduce new active constraints of the Constraint Logic Programming (CLP) framework which allow us to treat and to check for consistency of constraints throughout the whole generation procedure and not to only evaluate them when they are given in the programme or grammar. These active constraints are fully declarative and can be used by any type of parsing/generation process.</Paragraph>
    <Paragraph position="4"> CLP introduces a greater expressive power together with a higher efficiency since the resolution of constraints is postponed till they can be properly evaluated and since constraints have to be always true and consistent with each other. Finally, a feature of active constraints is that they are usually independent of the way they are processed, they are thus strategy independent and can equivalently be used for parsing and for generation.</Paragraph>
    <Paragraph position="5"> To make reversibility concrete in our system, we develop in this document two different abstract machines based on type construction and constraint satisfaction which give the foundations of a parser and a generator using the same source of declarative linguistic knowledge. The differences between these machines exemplifies the 'technical' differences one may have between parsing and generation processes. i 1. A type based description language Three major types of operations are at the basis of the typed-based language we have designed for language processing, namely:  - the expression of type construction to generate phrase structures, - the expression of dependencies (either local or long-distance) between types, - the expression of well-formedness constraints on types.</Paragraph>
    <Paragraph position="6">  Types here refers to the usual data structures in computer science. We now informally present the syntax of our type-based language. It is directly derived from the syntax of Login (Ait-Ka~i and Nasr 86). The syntactic representation of a structured term  is called a V-term. It consists of: (1) a root symbol, which is a type constructor and denotes a class of entities, (2) attribute ~labels, which are record field symbols. Each attribute denotes a function in extenso, from the root to the attribute value. The attribute value can itself be a reference to a type. (3) coreference constraints among paths of  labels, which indicate that the corresponding attributes denote the same function. They are indicated by variabies. Here is an example:  person( id =&gt; name(first =&gt; string, last =&gt; X: string), born =&gt; date(day =&gt; integer, month =&gt; monthname, year =&gt; integer), father =&gt; person( id =&gt; name(last =&gt; X ))).</Paragraph>
    <Paragraph position="7">  The root symbol is person; id, born and father are three Sub-V-terms which have either constants or type s as values. X indicates a coreference. All different type structures are tagged by different symbols. Notice also that in the latter field only relevant information about person is mentioned. Infinite structures can also be specified by coreference links. Variables are in capital letters, constants in small letters.</Paragraph>
    <Paragraph position="8"> 2. Dealing with constraints We have extended the type description framework with active constraints and have given them a Constraint Logic Programming (Colmeraner 90, Jaffar and Lassez 87) interpretation, permitting us to have a more principled-based description of language. The general form of a type is : Type :- Constraints.</Paragraph>
    <Paragraph position="9"> We view constraints as part of the type:</Paragraph>
    <Paragraph position="11"> is itself a type, subsumed by Type.</Paragraph>
    <Paragraph position="12"> The simplest constraint is the precedence constraint: preeede(X,Y), where X and Y are of type string. This constraint imposes that the string X precedes of the string Y. When processing a sentence, precedence constraints on constituents are stated in the grammar rules and possibly at the lexical level. At each stage i of the processing, there is a partial order Pl(i) on the words and structures already processed. At the end of the process, precedence constraints give all the possible word orderings which meet the constraints of the grammar. In the case of parsing, constraints imposed by the order of words in the input string must be coherent with the precedence results of the parse.</Paragraph>
    <Paragraph position="13"> The next constraaint imposes the presence of an attribute in a type: has(Attribute, Type) where Attribute is either an attribute label or a full pair attribute-value and Type is a reference to a given type. This constraint imposes that at some stage there is an attribute in Type which is subsumed by or equal to Attribute. Informally, (1) when incoherence with Attribute is detected or (2) when Type is fully constructed, the non-satisfaction of has(Attribute,Type) will provoque backtracking. This constraint permits us to encode thematic role assignment and focus management, and also to encode the inclusion of a set of values into another.</Paragraph>
    <Paragraph position="14"> The last class of constraint is mainly related to the expression of long-distance relations between sentence constituents. Within the framework of types, the notion of long-distance is somewhat obsolete since there is no ordering relation on subtypes in a type (attributes may be written in any order). Thus, the notion of long-distance dependency will be here formulated as a sub-type co-occurence constraint. This constraint emerged from Dislog (Saint-Dizier 87, 89). Very briefly, the co-occurence of two or more subtypes in a larger type is expressed by the constraint: ponding(A,B) where A is a type specification and B is a list of type specifications. Informally, this constraint means that A originates the pending of the sub-types in B, in other terms that A can be used if, somewhere else in the main type (corresponding for example to a full sentence), all the sub-types in B are used with identical substitutions applied to identical variables.  3. Processing Language with types and constraints  We will mainly present here simple, motivational examples. A more abstract syntactic description will be given in section 6 which will more fully motivate our approach. The examples given in this text show that our description language can accomodate principled-based descriptions of language like Government and Binding theory as well as lexicaUy and head driven descriptions like in the HPSG framework.</Paragraph>
    <Paragraph position="15"> In the following simple examples, we only have two main type constructors: - x0 corresponding to lexical entries, - xp corresponding to phrase structures.</Paragraph>
    <Paragraph position="16"> Here is the description of the lexical entry corresponding to the verb to give: xO( cat =&gt; v, string =&gt; \[give\] ) :pending(xO(cat =&gt; v), \[xp( cat =&gt; n, string =&gt; $1, role =&gt; patient ), xp( cat =&gt; p, string =&gt; $2, role =&gt; recipient) \] ), precede(\[give\],S1), precede(S1, $2).</Paragraph>
    <Paragraph position="17"> This entry says that give is a verb which subcategorizes for an np with role patient and a pp with role recipient; np and pp are left pending. The string S 1 generated from the np has to precede the string $2 generated from the pp. These constraints will be treated at the level of the type describing the structure of a vp. The whole description xO construction and related constraints is the type of the verb to give, Let us now consider the construction of a vp with an np and a pp complements. To the construction of a vp type corresponds the generation of a (set of) string(s) corresponding to a via, this is stored in S. We then have the following construction: xp( cat =&gt; v, string =&gt; S,</Paragraph>
    <Paragraph position="19"> has(role, X), has(case, X), has(role, Y), has(case, Y).</Paragraph>
    <Paragraph position="20"> The constraints has(role,X) and has(role,Y) impose that the constituents const2 and const3 have a role assigned at some level of the type construction process. The same situation holds for case. This is a simple expression, for example, of the case filter in GB theory. Notice that most pending situations are satisfied locally, which limits complexity.</Paragraph>
    <Paragraph position="21"> 4. An abstract machine for type construction in a parsing process Parsing a sentence is constructing a well-formed type describing the sentence structure. We present in this section an abstract machine which describes how types are constructed. This machine is based on the procedural semantics of Prolog but it resembles a push-down tree automaton whose stack is updated each dine a subtype is modified.</Paragraph>
    <Paragraph position="22"> There are two kinds of type constructors: those corresponding to non-terminal structures (such as xp and x 1 in our examples) and those corresponding to terminal structures (e.g. x0). We now present a step in the construction of a type. It can be decomposed into 3 levels:  (1) current state o i : cO( a 1 =&gt; t 1, a 2 =&gt; t 2 ..... a n =&gt; tn), (2) selection in the current programme P of a type construction specification: cl(b 1 =&gt; t' 1 ..... b m =&gt;t' m) such that t 1 subsumes it or unifies with it modulo the mgn 0 i.</Paragraph>
    <Paragraph position="23"> (3) New state degi+l : tl is replaced by : el( b 1 =&gt; t' 1 ..... b m =&gt; t' m ),  with, as a result, the following type: co(a 1 =&gt; cl(b 1 =&gt; t' 1 ..... b m =&gt; t' m ), a 2 =&gt; t 2 ..... a n =&gt; t n) 0 i The process goes on and processes t' 1&amp;quot; The type construction strategy is here similar to Prolog's strategy and computation rule : depth-first and from left to right. The main difference at this level with SLD-resolution is that only types corresponding to non-terminal structures are expanded. Informally, when a type tj corresponds to a terminal structure, an attempt is made to find a terminal type description t'j in the programme which is subsumed by or unifies with t.j and, if so, a replacement, occurs, t'j is said to be in a final state. If t j does not exist, backtracking occurs. The next type description immediately to the right of t'j is then treated in the same manner. The type construction process successfully ends when all subtypes corresponding to terminal symbols are in a final state and it fails ff a terminal type description tp cannot reach a final state. The initial state: is : xp( cat =&gt; sentence i string =&gt; \[ string,to,parse\] ).</Paragraph>
    <Paragraph position="24"> 4.2. Extension of the abstract machine to constraints The above abstract machine can be extended in a simple way to deal with constraints. Constraint resolution mechanisms are similar to usual constraint logic programming systems like Prolog IH. The three above le~,els become: (1) current state degi represented by the couple: &lt; c0(a l=&gt;t 1, a 2=&gt;t 2 ..... a n=&gt;tn),S &gt; where S is the set of current constraints, (2) selection in the current programme P of a type construction specification: cl(b 1 =&gt; t'l, ...; b m =&gt; t' m ) :- R.</Paragraph>
    <Paragraph position="25"> where R is the set of constraints associated to cl, and t 1 subsumes Or unifies with t' 1 modulo the mgu 0 i.</Paragraph>
    <Paragraph position="26"> (3) New state o i+ 1 characterized by the following couple: &lt; c0(a 1 =&gt;cl(b 1 =&gt; t' 1 ..... b m =&gt; t' m), a 2 =&gt; t 2, .... a n =&gt; t n) 0 i ,</Paragraph>
    <Paragraph position="28"> with the condition that the new set of constraints must be satisfiable with respect to the constraint resolution axioms defined for each type of constraint and, if not,:a backtracking occurs. At this level constraints simplifications may also occur.</Paragraph>
    <Paragraph position="29"> The output of the parsing process may be simply a syntactic tree, but it may also be a logical formula, similar to the one used and presented in section 5. We however think that both processes, parsing and generating, need not necessarily respectively produce and start from the same abstract internal representation.</Paragraph>
  </Section>
class="xml-element"></Paper>