<?xml version="1.0" standalone="yes"?>
<Paper uid="C94-2135">
  <Title>ACHIEVING FLEXIBILITY IN UNIFICATION FORMALISMS</Title>
  <Section position="4" start_page="842" end_page="842" type="metho">
    <SectionTitle>
2 ACHIEVING FLEXIBILITY
</SectionTitle>
    <Paragraph position="0"> in this section l state some necessary properties of a flexible formalism.</Paragraph>
    <Paragraph position="1"> It is essential that the formalism does not provide a single basic construction in which all other structures must be defined, as this often leads to clumsy representations. Instead the user defines everything he needs. Theretbrc a flexible formalism must provide some way of defining structures and objects. These can be divided into two groups; those that are used as general elements in the t'ormalism, for example feature structures or the empty set; and those that m'e specific for a particular problem, for example the attribute number.</Paragraph>
    <Paragraph position="2"> In addition to the elements defined in a fonnalism the user needs other ways of describing his objects, e.g logical operators, such as conjunction and disjunction, and functions, such as concatenation of lists. Important to note here is that these constructs do not add further elements to the defined language, they just specify additional syntax for describing the objects.</Paragraph>
    <Paragraph position="3"> Another requirement tor a flexible formalism is that the user nmst define the behaviour of his elements, that is, how they unify with each otheL Similarly, when defining some additional syntax, he nmst specify the meaning of it. I have chosen to do this by stating constraint relations, which means that results from term rewriting systems (Middeltorp &amp; Halnoen, 1992) and algebraic specification (Ehrig &amp; Mahr, 1985) can be applied. Using constraint relations it can be specified that two defined objects should be interpreted as the same, or that one object should subsume some other object.</Paragraph>
    <Paragraph position="4"> The last property I want to mention is the use of an inheritance hierarchy fur the delinitions. This is a good way of taking advantage of similarities between different extensions and also a suitable way of defining linguistic knowledge (see, fi)r example, the articles in Computational Linguistics 18(2,3)).</Paragraph>
    <Paragraph position="5"> By using an inheritance net for defining new constructions in the formalism several other benefits arc obtained. One is that if the mathematical properties of a construction are known, this knowledge can be used instead of defining the construction with constraint relations. The inheritance net allows us to replace the construction defined with constraint relations with a predefined mathematical domain provided that both the properties of this domain and how objects unifies are known.</Paragraph>
    <Paragraph position="6"> The inheritance net also provides ways to iinprove the efficiency in in~plementations of the system.</Paragraph>
    <Paragraph position="7"> Since a defined construction corresponds to a node in ~cept noun;\]  the net (together with inherited information), known unification algorithms tbr objects corresponding to this node can be used. This gives the design of a full-scale implementation as a library of the most common extensions, where the user can choose which he wants and define new ones or change existing definitions only when necessary.</Paragraph>
  </Section>
  <Section position="5" start_page="842" end_page="843" type="metho">
    <SectionTitle>
3 THE FLUF FORMALISM
</SectionTitle>
    <Paragraph position="0"> In this section I show how the FLUF formalism works by defining feature structures as they are used in PATR-ll. I have defined conjunction and disjunction and some minimal linguistic knowledge. The inheritance hierarchy expressing the definition is shown in Fig. 1.</Paragraph>
    <Paragraph position="1"> First the objects needed to build feature structures are defined. This is done using classes. The objects needed are attributes and values. These are the two subclasses of top. Values are divided into atomic and complex values, corresponding to the two classes atom 'and fs'.</Paragraph>
    <Paragraph position="2"> The two chtsses top and value are used to build up the hierarchy and contain no object definitions of their own, all objects are defined in atom, attribute andf~, l show the definitions of Is' and attribute  below. The definition of atom is very similar to the definition of attribute.</Paragraph>
    <Paragraph position="3"> chtss Is; isa value; consmtctor empty; constructor add_pair: attribute,value,Is; constraint empty&gt;add pair(A,V, FS); constraint add_pair(A,U,add pair(A,V, FS))= add pair(A,and(U,V),FS); constraint add pair(A,U,add pair(B,V, FS))= add pair(B ,V, add pair(A ,U ,FS)).</Paragraph>
    <Paragraph position="4"> class attribute; isa top; constructor instances.</Paragraph>
    <Paragraph position="5">  A class definition contains the name of the class and the parent in the hierarchy. Furthermore, classes can contain constructor and constraint definitions. The constructor definitions state what elements the class contains. In the definition offs above, the class contains one element empty, and one element add_pair(A,V, FS) for each possible instantiation of A as an attribute, V as a value and FS as afs. In the definition of add~pair the symbols after : refer to the type of the arguments to addpair. Here it can be noted that FLUF makes use of typed terms. In the examples i omit the types when writing terms since they are clear from the context.</Paragraph>
    <Paragraph position="6"> The definition of attribute makes use of a special constructor instances. This constructor means that the elements in the class are defined as objects below it. In the definition offs constraint relations are used. In FLUF '=' is used to specify that two terms should be interpreted as equal and '&lt;'or '&gt;' to specify the subsumption order between the defined elements. The reason for having both &gt;- and &lt;-relations is that the left hand side of a relation is seen as the expression being defined and the right hand side as what it is defined as.</Paragraph>
    <Paragraph position="7"> In the example above the first constraint tells us that empty should subsume every constructor starting with add pair. 2 The second relation states thatfs's containing the same attribute more than once should have the same interpretation as the structure containing the attribute only once with the conjunction of the two values as its value. The third equation says that the attribute order in afs is irrelevant.</Paragraph>
    <Paragraph position="8"> Next conjunction and disjunction are added. They do not add any new elements to our language and are defined as functions. For a function the name of the function, the type of the result and the number and type of arguments to the function are specified. To give the meaning of function expression constraints are specified as relations in the same way as for classes. The definitions of and and or are given  below.</Paragraph>
    <Paragraph position="9"> function and; result value; arguments value,value; constraint and(X,Y)&lt;X; constraint and(X,Y)&lt;Y.</Paragraph>
    <Paragraph position="10"> function or; result value; 2. Here there is a slight difference from PATR-II since empty does not subsume atoms. The interpretation used in PATR-II can be obtained by defining empty as a value. arguments value,value; constraint or(X,Y)&gt;X; constraint or(X,Y)&gt;Y.</Paragraph>
    <Paragraph position="11"> By these definitions both functions give a value as  result and take two values as their arguments. The constraint definition of and tells us that and is subsumed by its arguments, while or subsumes its arguments. null Next, some linguistic knowledge is defined. First the attributes and atoms used by the application are given. This can be done using objects. An object is specified by just giving a name and a parent in the inheritance hierarchy. What is special here is that object definitions are only allowed if there is an ancestor in the hierarchy which has a constructor specified as instances. As an example I give the definition of cat.</Paragraph>
    <Paragraph position="12"> object cat; isa attribute.</Paragraph>
    <Paragraph position="13"> When defining linguistic knowledge, concept definitions are used to group it into conceptual parts. In a concept definition the name of the concept and its parent in the inheritance hierarchy are specified. It is also possible to specify a requirement as a typed term. The meaning of such a requirement specification is that all objects that are of this concept must contain at least the information given by the require~ ment. Two concept definitions from the example are wordcat and verb. Their definitions are given below. concept wordcat; isa atom.</Paragraph>
    <Paragraph position="14"> concept verb; isa fs; requires add pair(cat,v,empty).</Paragraph>
    <Paragraph position="15"> With this definition of PATR~II grammar rules can be represented as feature structures. The terms in FLUF allows assigning variables to subterms which gives a simple representation of coreferences in PATRdl. A declarative and operational the semantics of FLUF is given in S tr0mbgck (1994b). The declarative semantics is an initial algebra semantics where the elements given by a definition are interpreted on a partial order. The operational semantics amounts to giving a unification algorithm which in many ways is similar to narrowing (see, for example, Middeltorp &amp; Hamoen (1992)). The FLUF formalism is sound, but not fully complete.</Paragraph>
  </Section>
  <Section position="6" start_page="843" end_page="844" type="metho">
    <SectionTitle>
4 FURTHER EXAMPLES
</SectionTitle>
    <Paragraph position="0"> In this section I give two further examples that demonstrate the flexibility of FLUF. The first example</Paragraph>
    <Paragraph position="2"> constraint add_pair(A,U,add pair(B,V, FS))= add pair(B ,V, add pair(A,U ,FS)).</Paragraph>
    <Paragraph position="3"> Compared to the definition offi' given previously, a new constructor closed is added. The idea here is that a feature structure ended with closed has a fixed arity and can not be extended with new attributes. The given constraint relations would give us the subsumption order shown in Fig. 2. The most general structure is at the top. The shadowed areas represent feature structures not explicitly written in the figure. The next example shows how different interpretations of sets can be detined in FLUE First I give a definition of sets corresponding to that used in HPSG</Paragraph>
    <Paragraph position="5"> constraint add_elem(V, add elem(V,S))= add_elem(V,S); constraint add elem(Vl,add elem(V2,S))= add elem(V2,add_elem(V 1 ,S)).</Paragraph>
    <Paragraph position="6"> Here the two constructors for sets empty and add elem are detined. The two constraint relations in the definition say that each element only occurs once in a set and that the element order in a set is irrelevant. With this definition the unifications below hold. To increase readability I have used the common notation for sets.</Paragraph>
    <Paragraph position="7"> {X,Y}U{a}={a} {X,Y}U{a,b}={a,b} In the first example the first constraint rule, identifying X and Y, is used.</Paragraph>
    <Paragraph position="8"> For some linguistic phenomena it would be more useful to have an interpretation of sets where unification works like union. In FLUF this can be obtained by the definition below.</Paragraph>
    <Paragraph position="9"> class set; isa ...; constructor empty; constructor add elem(value,set); constraint empty&gt;add elem(V,S); constraint add Mem(V 1 ,add elem(V2,S))= add elem(V2,add_elem(V 1 ,S)).</Paragraph>
    <Paragraph position="10"> The difference between this detinition aM the previous one is that empty subsume all other sets. An element is also allowed to occur more than once in a set. With this second definition the first unification above has three possible results.</Paragraph>
    <Paragraph position="11"> \[{a,Y} {X,Y}U{a}= t {X,a} \[{x,Y,a} In the first result a is identified with X, in the second with Y, and in the third with neither of them. Presently FLUF gives all these three results as alternatives of the unilication.</Paragraph>
    <Paragraph position="12"> The reason why a set can be extended with new ele.. ments in the second definition but not in the first is that the semantics of FLUF assumes that if two expressions are not ordered by some constraint relation they are incomparable. Thus in the first definition sets are only related if all their elements are. FLUF assumes that all delined constructions are monotonic, so by the constraint relation given for empty in the second definition it can be concluded, for example, that (a}&gt;{a,b }.</Paragraph>
    <Paragraph position="13"> Other examples of what can be defined in FLUF are lists', trees and strings. It is also easy to define functions such as concatenation of lists in FLUF.</Paragraph>
  </Section>
class="xml-element"></Paper>