0.3 Overview of the Thesis
1.1.1 Constraint Language
In this section, we introduce the constraint language which we will use throughout this thesis.4
1.1.1.1 Sorted Feature Terms
Our conception of sorted feature terms is based on Carpenter’s Logic of Typed Feature Structures5 from which it differs only in one respect: in our system, the sort hierarchy is not required to be a bounded complete partial order. As a conse-quence, a feature structure can be described by two or more different sorts which do not have a common subsort; and two different sorts can have several common subsorts, even though they do not have a unique most general common subsort.
In this respect, our constraint language is similar to thecufformalism [D¨orre and Dorna, 1993]. More details about our sorted feature term language can be found in [Erbach, 1994b; Erbach, 1994c] and in section 5.1.
We follow the distinction betweenfeature termsas syntactic objects andfeature structures which are the abstract mathematical objects described by the feature terms. The feature term language consists of five different kinds of sorted feature terms (SFT):
• A constraint that the described feature structure must be subsumed (sym-bolised by the “smaller than” sign <) by a given sort (<Sort); e.g. the structure described by the term <phrasal_signmust be subsumed by the sort phrasal sign.
• A feature constraint (F!SFT), which constrains the value of the featureFof the described feature structure to be subsumed by the structure described by SFT. For example, the feature constraint subcat! <elistdenotes a struc-ture whosesubcat-value is an empty list.
• A Prolog term. Besides sort constraints, Prolog terms are the only other way to “bottom out”. Prolog terms can be either variables, atoms, or com-pound terms. This arrangement makes it possible to take advantage of the
4This constraint language was developed in the project “The Reusability of Grammatical Resources”, and is the joint work of Suresh Manandhar, Wojciech Skut and the author. It is described more fully in [Manandhar, 1994; Manandhar, 1995; Erbachet al., 1994a; Erbachet al., 1994b; Erbachet al., 1995b].
5We prefer to speak of sorted feature structures since the usage of the term type in logic programming and computational linguistics is ambiguous: For Carpenter, a type denotes a subset of the domain (for example the typesign, for which the featuresphon, synsem, qstoreand retrievedare appropriate); for other authors like Emele and Zajac [Emele and Zajac, 1990;
Zajac, 1992], a type can be a complex recursively defined relation (e.g., the typeappend/2 or sign of english/1). To avoid terminological confusion, we follow the usage established in CLP (cf.
[D¨orre and Seiffert, 1991; A¨ıt-Kaci and Podelski, 1991]) and the recenthpsgliterature [Pollard and Sag, 1994], and use the term sort for symbols that denote a subset of the domain, and relation orpredicate for defined relations.
SFT :=<Sort Term of a sort Sort
| Feature!SFT Feature-Value pair
| PROLOGTERM Any Prolog term
| SFT & SFT Conjunction of terms
| SFT or SFT Disjunction
Figure 1.2: Syntax of sorted feature terms
term language (e.g. cyclic terms) and constraint language (e.g. inequal-ity constraints) of the Prolog system underlying the implementation of our constraint language. The use of normal first-order Prolog terms in the fea-ture term constraint language constitutes no problem, since ann-ary Prolog with functorF term can be regarded as a notational convention for a sorted feature structure of the sort F, for which the features arg1 . . .argn are appropriate, and which has no sortal restrictions for the features.6
• A conjunction of terms (SFT1 & SFT2), which constrains the described struc-ture to be subsumed by bothSFT1andSFT2, i.e., the set of described struc-tures is the intersection of the strucstruc-tures described by SFT1andSFT2.
• A disjunction of terms (SFT1 or SFT2), which constrains the described structure to be subsumed by either SFT1or SFT2, i.e., the set of described structures is the union of the structures described bySFT1andSFT2.
The syntax of the sorted feature term language is summarised in figure 1.2. In later chapters, we will alternatively make use of the more readable notation for sorted feature terms as attribute-value matrices.
1.1.1.2 Finite Domains
Finite domains provide a way of handling certain subclasses of disjunctions in logic programs without the creation of choice points. Finite domains are disjunctions with a finite set of possible values. Finite domains have been introduced for the logic programming language chip [van Hentenryck and Dincbas, 1986; van Hentenryck, 1989]; they can also be expressed by more powerful sort inheritance hierarchies in languages such ascuforlife.
A finite domain variable is a variable that can only take on one of a fixed finite (and reasonably small) set of values. A description can constrain the value of the variable to be any subset of this set. When two finite domain variables are unified,
6In the implementation, we actually go in the opposite direction, and compile sorted feature terms into a Prolog term representation (cf. section 5.1).
the resulting value’s constraint is the intersection of the possible values for both variables. The unification fails if the intersection is empty.
Finite domains are useful for providing efficient processing for many cases of disjunction that arise in NLP without the need for computationally expensive treatments of disjunction, such as distributed disjunctions.7
The following is the syntax for defining finite domains:
Name fin dom [Val1.1, . . . ,Val1.n] * . . . * [Valm.1, . . . ,Valm.l]. (1.1) The following example defines a finite domain which contains all possible com-binations of the agreement featuresperson, numberandgender.
agr fin dom [first,second,third] * [sg,pl] * [masc,fem,neut]. (1.2) The resulting finite domain consists of 3*2*3 = 18 values, all possible combinations of one person, number and gender value. Subsets of this finite domain can be described by making use of the logical connectives∧(conjunction),∨(disjunction), and¬(negation), e.g.,¬(third∧sg).
1.1.1.3 Inequations
In addition to equality constraints between sorted feature structures, we allow also inequality constraints. Inequality has been introduced in CLP with Prologii [Colmerauer, 1982; Giannesiniet al., 1985], and is supported by all modern logic programming languages.
1.1.1.4 Set Descriptions and Set Constraints
Inhpsg[Pollard and Sag, 1994], sets are used for the nonlocal featuresslash, rel andque, for quantifier storageqstore, for the context featurebackground, for conjuncts in a coordination structure, for restrictions on semantic indices; and in other hpsg proposals also for features such as subcat. Since we have a strong interest in handling hpsg grammars, which make heavy use of sets, we allow set constraints in our formalism, following Manandhar’s attributive logic of set descriptions [Manandhar, 1994]. The set descriptions and set constraints shown in figure 1.3 are allowed in definite clauses.
Disjoint union is not available in the logic, but it can be defined as follows by employing set disjointness and set union operations:
x]y=def disjoint(x, y)u(x∪y) (1.3)
7(cf. [Eisele and D¨orre, 1990; B¨ottcher, 1993; Maxwell III and Kaplan, 1991; Matiasek, 1993;
Trost, 1993])
Set Constraint Meaning Syntax for variable X
empty set X is the empty set { }
element E is an element of X exist(E)
set description X contains the elements E1 . . .En (but they need not be disjoint)
{E1, . . . , En}
fixed cardinality set X contains the disjoint {E1, . . . , En}=
elementsE1 . . .En
subset X is a subset of Y subset(Y)
union X is the union of Y and Z Y ∪Z intersection X is the intersection Y ∩Z
of Y and Z
disjointness X is disjoint from Y disjoint(Y) Figure 1.3: Syntax of set constraints 1.1.1.5 Linear Precedence Constraints
Linear precedence constraints have various uses in linguistic descriptions. Their most obvious use is the modelling of word order phenomena. Other uses are in natural language semantics in the description of temporal precedence relations and of underspecified quantifier scope.
In figure 1.4 we describe the syntax of the linear precedence constraints sup-ported by our implementation; for the formal semantics, refer to [Manandhar, 1995].
1.1.1.6 Guarded Constraints
Guarded constraints are used in logic programming to delay a constraint if not enough information is available for its deterministic execution. Such situations arise frequently in natural language processing when the same grammar is used bidirectionally for parsing and generation.
Therefore, it is a natural move to include guarded constraints into grammar for-malisms. Our constraint language for guarded constraints supports the following general purpose syntax:
case( [ condition1 ⇒ choice1, . . .
conditionn ⇒ choicen ])
else choicen+1
(1.4)
Each of the choicei can be any term or another guarded constraint. Each of
LP Constraint Meaning Syntax for variable X
precedence X precedes Y precedes(Y)
precedence equals X precedes or precedes equals(Y) is equal to Y
first daughter X precedes all other fst daughter(Y) elements of domain Y
domain precedence (every element of) dom precedes(Y) domain X precedes
(every element of) domain Y
guard on precedence if X precedes Y then if precedes(Y) X is unified with S, then S
otherwise else T
X is unified with T
Figure 1.4: Syntax of linear precedence
theconditioni(also known asguard) is restricted to one of the following forms (the variables ∃x1, . . . , xn stand for existentially quantified variables). Our constraint language is restricted to what is known asflat guardssince no embedding is allowed in the guard (condition) part. However, this restricted language appears to be sufficient for linguistic applications.
condition−→ ∃x1, . . . , xn feature term
| ∃x1, . . . , xn exists(feature term)
|precedes(x, y)
(1.5) Guarded constraints can be thought of asconditional constraintswhose execu-tion depends on the presence of other constraints. The acexecu-tionchoicei is executed if the current set of constraintsentailthe guardconditioni. The actionchoicen+1 is executed if the current set of constraintsdisentailthe all the guardscondition1 throughconditionn. If the current set of constraints neither entail nor disentail conditioni then the execution isblockeduntil more information is available.
The constraint solving machinery needed for implementing guards on feature constraints has been worked out in [Smolka and Treinen, 1994] and [A¨ıt-Kaci and Podelski, 1994]. Our constraint language extends this to permit guards on set-memberships and guards on precedence constraints.