<?xml version="1.0" standalone="yes"?>
<Paper uid="J99-1002">
  <Title>Default Representation in Constraint-based Frameworks</Title>
  <Section position="2" start_page="0" end_page="62" type="abstr">
    <SectionTitle>
1. Introduction
</SectionTitle>
    <Paragraph position="0"> The utility of defaults in linguistic representation has been widely discussed (for an overview, see Daelemans, de Smedt, and Gazdar \[1992\]). The most common linguistic application for default inheritance is to encode lexical generalizations (e.g., Boguraev and Pustejovsky 1990; Briscoe, Copestake, and Boguraev 1990; Vossen and Copestake 1993; Daelemans 1987; Evans and Gazdar 1989a, 1989b, 1996; Flickinger, Pollard, and Wasow 1985; Flickinger 1987; Flickinger and Nerbonne 1992; Kilgarriff 1993; Krieger and Nerbonne 1993; Sanfilippo 1993; Shieber 1986a), but defaults have also been used for specification in syntactic theory (e.g., Gazdar 1987; Shieber 1986b), and for the analysis of gapping constructions (Kaplan 1987) and ellipsis (Grover et al. 1994). In Lascarides et al. (1996), we argued for the role of defaults both in descriptions of the lexicon and grammar and to allow the linguistic component to make defeasible proposals to discourse processing/pragmatics. Most current constraint-based systems either do not support defaults or only allow them at a metalevel, as part of an extended description language. Our aim is to allow defaults as a fully integrated part of a typed feature structure system. 1 In general, although there have been several approaches to formalizing default inheritance within feature structure languages by defining an operation of default unification (some examples are cited in Section 1.2), these have failed to achieve the combination of perspicuity, declarativity, and expressibility familiar from unification-based approaches to nondefault inheritance. The version of default unification described in  * Centre for Cognitive Science and Human Communication Research Centre, University of Edinburgh, 2, Buccleuch Place, Edinburgh EH8 9LW, Scotland, UK. E-maih alex~cogsci, ed. aC/. uk t Center for the Study of Language and Information, Stanford University, Ventura Hall, Stanford, CA 94305, USA. E-maih aac(c)csli, stan:Eord, edu 1 We will assume a notion of types very similar to that of Carpenter (1992), although we use the opposite polarity in hierarchies (i.e., for us the most general type is T, top)---details are given in Copestake (1992).</Paragraph>
    <Paragraph position="1"> (~) 1999 Association for Computational Linguistics  Computational Linguistics Volume 25, Number 1 Lascarides et al. (1996) was more satisfactory in this respect, but not without its problems (see Section 1.2). Our aim here is to present an alternative version of default unification, which overcomes those flaws, and also to give detailed examples of various ways in which constraint-based systems can utilize defaults, and the requirements that these impose on the formalism.</Paragraph>
    <Section position="1" start_page="0" end_page="56" type="sub_section">
      <SectionTitle>
1.1 Criteria for Default Unification
</SectionTitle>
      <Paragraph position="0"> Lascarides et al. (1996) list a number of desiderata for default unification, which we repeat here (with some amendments to the justifications):</Paragraph>
      <Paragraph position="2"> Nondefault information can be distinguished from default information and is always preserved.</Paragraph>
      <Paragraph position="3"> We intend our representation language to supplement rather than supplant existing work using monotonic inheritance within frameworks such as HPSG. Nondefault processing is crucial to parsing and generation in a unification-based framework, because unification failure is required to prevent ungrammatical structures. From this perspective, it seems reasonable to expect grammars and lexicons to have a monotonic backbone, which encodes the main architectural properties of the feature structures. Since construction of grammars and lexicons is error-prone, we believe that grammar writers will want to prevent accidental overriding of such structural information by ensuring that it is indefeasible. We therefore believe that it is desirable that defaults be explicitly marked, and, as shown by Young and Rounds (1993), this is a necessary condition for the order-independence of default unification (criterion 5, below).</Paragraph>
      <Paragraph position="4"> Default tmification never fails unless there is conflict in nondefault information.</Paragraph>
      <Paragraph position="5"> The usual assumption about conflicting defaults is that they do not result in an inconsistent knowledge state (e.g., Reiter 1980). So, it is clearly desirable that unification failure does not occur as a side effect of the way default information is defined.</Paragraph>
      <Paragraph position="6"> Default unification behaves like monotonic unification in the cases where monotonic unification would succeed.</Paragraph>
      <Paragraph position="7"> We want to use the same notions of unification, subsumption, etc. with respect to both default and nondefault feature structures. This will enable us to use default unification to extend existing monotonic approaches to linguistic analysis, rather than replacing them.</Paragraph>
      <Paragraph position="8"> Default unification returns a single result, deterministically.</Paragraph>
      <Paragraph position="9"> As we will describe in Section 3, there are definitions of default unification in which a disjunction of feature structures may be produced. While there is nothing wrong with such definitions formally, they are practically inconvenient, since they can result in a multiplication of structures; and they are only suitable for implementations that allow disjunction.</Paragraph>
      <Paragraph position="10"> Default unification can be described using a binary, order-independent (i.e., commutative and associative) operation.</Paragraph>
      <Paragraph position="11"> The main failing of most definitions of default unification is that they are not order-independent. Having an order-dependent operation in the  Lascarides and Copestake Default Representation .</Paragraph>
      <Paragraph position="12"> description language is inelegant, but it has been regarded as acceptable, because all the structures to be unified are in a fixed hierarchy and an inheritance order can therefore be imposed (there will be a difference between top-down vs. bottom-up inheritance, for instance). However, order dependence undermines many of the arguments in favor of constraint-based grammar formalisms: that is, that processing can be seen as a uniform accumulation of constraints and is independent of the algorithm that controls evaluation order. For instance, an order-dependent operation causes problems for strategies such as lazy evaluation. More fundamentally, we have argued (e.g., in Lascarides and Copestake, in press) that it is necessary for the lexicon to propose default information that may be overridden by pragmatics. In a discourse situation, however, it is impossible to predict which pieces of information are to be unified in advance of starting the discourse parsing process, so the interface between discourse processing and order-dependent lexical processing would have to take into account the order in which the unification operations are done, which is impractical. Defaults can be given a precedence ordering such that more specific information overrides less specific information.</Paragraph>
      <Paragraph position="13"> This is the usual assumption made about inheritance hierarchies, and is necessary if exceptions to a generalization themselves have exceptions. The approach to default unification that we will describe in this paper allows any defaults to be overridden by defaults which are associated with more specific types: thus priority ordering reflects the type hierarchy ordering. (In Section 6.2, we will mention other possibilities for imposing a priority order on defaults.) Barring criterion 6, all of the above properties are necessary for making default unification behave as much like normal unification as possible, save that (default) information can be overridden. These criteria ensure that the default unification operation has properties familiar from monotonic unification, such as determinacy, the way information is accumulated, the conditions when unification fails, and order independence. Since this guarantees that default unification shares many of the properties of normal unification, a &amp;quot;seamless transition&amp;quot; is possible between the monotonic approach to linguistic analysis supplied by normal unification, and the extension to these analyses provided by supplying default constraints and default unification operating over them. We will justify these assumptions with respect to particular linguistic examples in Section 4. In this paper, we define an order-independent typed default unification operation called YADU (Yet Another Default Unification), which we believe is the first definition of default unification that fulfills all of the above criteria.</Paragraph>
    </Section>
    <Section position="2" start_page="56" end_page="62" type="sub_section">
      <SectionTitle>
1.2 Previous Definitions of Default Operations on Feature Structures
</SectionTitle>
      <Paragraph position="0"> There have been a number of previous definitions of default unification, including those given by: van den Berg and Pr6st (1991), Bouma (1990, 1992), Calder (1991), Carpenter (1993), Copestake (1992, 1993), Russell, Carroll, and Warwick-Armstrong (1991), and Russell et al. (1993). These definitions were all based on Kaplan's sketch of priority union (Kaplan 1987) and are asymmetric since one feature structure (FS) is taken to be indefeasible while the other is defeasible. This operation is not commutative or associative (Carpenter 1993). Although there are some applications for which an asymmetric operation is useful (see Section 6.5), the order dependency makes it un- null Computational Linguistics Volume 25, Number 1 desirable as a basis for inheritance, as we discussed above. Furthermore, since these definitions do not allow for statements of precedence order in defaults, the inheritance hierarchy has to be stipulated separately.</Paragraph>
      <Paragraph position="1"> Young and Rounds (1993) define an order-independent version of default unification using Reiter's default logic (Reiter 1980) to model the operation. But it does not allow for precedence between defaults based on specificity (criterion 6, above). The most straightforward way of extending the definition to meet criterion 6 would be to extend Reiter's default logic so that it validates specificity, but as Asher and Morreau (1991), Lascarides and Asher (1993), and Lascarides et al. (1996) argue, all such extensions to Reiter's default logic either impose ordering constraints on the application of logical axioms in proofs (e.g., Konolige 1988), or they impose a context-sensitive translation of the premises into the formal language (e.g,. Brewka 1991). So extending Young and Rounds' definition in this way comes at the cost of an underlying formal semantics that has separately defined order constraints on the logical axioms, or context-sensitive translation.</Paragraph>
      <Paragraph position="2"> Lascarides et al. (1996) use conditional logic to extend Young and Rounds' definition to typed feature structures, describing an operation called Persistent Default Unification (PDU). They use a conditional logic precisely because these logics are able to validate nonmonotonic patterns of inference involving specificity without imposing ordering constraints on the application of axioms or imposing context-sensitive translation on the premises. In order to allow default inheritance in type hierarchies, precedence of default values in PDU is determined by the specificity of the types at which the default is introduced. PDU thus meets criterion 6 for nonreentrant information, but it can't validate the overriding of default reentrancy by conflicting default values introduced by a more specific type. This is partly because the logic underlying PDU demands that the default values on paths are worked out independently of one another. Since PDU can't compare values on paths that, by default, share nodes, we were forced to make the design decision that default reentrancies always survive, and if the default values on the shared node that are introduced by a more specific type conflict, then the value on the shared node in the result is _1_, indicating unification failure.</Paragraph>
      <Paragraph position="3"> This failure to fully meet criterion 6 restricts PDU's linguistic application, as we will show in Section 4. There are also problems in interpreting FSs containing _1_. Such structures cannot be treated as normal FSs and the operation, DefFill, which converts a partially defeasible FS to a monotonic one (necessary, for instance, when defaults are being used to allow concise description of classes of lexical entry, as we will discuss in Sections 2 and 4) has a complex definition because of the need to allow for _1_.</Paragraph>
      <Paragraph position="4"> Furthermore, as we discuss briefly in Section 3.6.3, PDU can result in FSs that are not well-formed with respect to the distinction between simple values and FS values.</Paragraph>
      <Paragraph position="5"> We also found that the complexity of the definition of PDU made it difficult to use.</Paragraph>
      <Paragraph position="6"> These problems led us to develop the alternative definition, YADU, presented here.</Paragraph>
      <Paragraph position="7"> Like PDU, YADU can be formalized in a conditional logic, but in this paper we will give a definition in terms of an algebraic operation on FSs. These algebraic definitions are easier to follow, and provide much simpler proofs of theorems than the conditional logic (cf. the theorems for PDU in Lascarides et al. \[1996\]).</Paragraph>
      <Paragraph position="8"> In the next section, we give an informal overview of YADU, by means of a worked example. This is followed in Section 3 by the formal definitions, some illustrative examples, and an explicit comparison with PDU. In Section 4, we describe some linguistic examples in detail and discuss the requirements they impose on the default unification operation. Section 6 covers some alternative and extended definitions, including one that makes use of Carpenter's (1992) inequalities.</Paragraph>
      <Paragraph position="10"> Figure 1 Constraint descriptions for a type hierarchy for inflections: informal notation.  2. An Informal Overview of YADU YADU is based on the intuitively simple idea of incorporating the maximal amount of default information, according to its priority. We will use a simple example in order to illustrate the operation and to contrast it with the PDU operation discussed in Lascarides et al. (1996). Suppose we wish to encode the following information about the suffixes of English verbs: .</Paragraph>
      <Paragraph position="11"> 2.</Paragraph>
      <Paragraph position="12"> 3.</Paragraph>
      <Paragraph position="13">  Past participle and passive participle suffixes are always the same. Past tense suffixes are usually the same as participle suffixes. Most verbs have the past suffix +ed.</Paragraph>
      <Paragraph position="14"> We assume a paradigm style of encoding with separate features for each suffix: here the past tense suffix slot is indicated by the feature PAST, past participle by PASTP, and passive participle by PASSP. Figure 1 shows a fragment of a type hierarchy, which is intended to show informally how the generalizations above could be encoded in this way. The figure uses the conventional AVM notation for FSs, but with the addition of a slash, which indicates that material to its right is to be treated as default. All features have both nondefault and default values, but where the nondefault value is T (i.e., the most general type in the bounded complete partial order) we omit it: e.g.,/+ed is equivalent to T/+ed. We omit both the slash and the default value if the nondefault value is equal to the default value. Default reentrancy between nodes is indicated by slashes preceding the labels: e.g., in the constraint for verb in Figure 1, PASTP and PASSP are necessarily coindexed, while PAST is defeasibly coindexed with both of them. The intention of describing such a hierarchy is that verbs such as walk can be defined as regverbs, while sleep, for example, would be a pst-t-verb. We assume that inflectional rules are responsible for ensuring that the correct affix is realized, but we will not give details of such rules here.</Paragraph>
      <Paragraph position="15"> However the slashed notation used in Figure I cannot in general contain sufficient information to ensure order independence, as was shown in Lascarides et al. (1996). As we will show in more detail in Section 3, additional information is required, which encodes part of the history of a series of default unifications. Lascarides et al. referred</Paragraph>
      <Paragraph position="17"> pst-t-verb \] \[ pst-t-verb \]/((\[ +t \], pst-t-verb) } PAST: T J / \[ PAST: +t J'~'t PAST: Figure 2 Type hierarchy using PDU.</Paragraph>
      <Paragraph position="18"> to the structure that encoded this information as a tail. In that paper, a tail was notationally equivalent to a set of atomic feature structures labeled with a type. An atomic FS is defined as in Carpenter (1993), i.e., it cannot be decomposed into simpler FS. Intuitively, an atomic FS in the tail represents a piece of default information that was introduced at some point in the series of default unifications that resulted in the current structure. The type that labels an atomic FS in a tail serves to prioritize the default information given by the atomic FS--the priority being determined by the position of this type in the type hierarchy (more specific types have higher priority).</Paragraph>
      <Paragraph position="19"> In Lascarides et al. (1996), we used a tripartite structure consisting of an indefeasible typed feature structure, a defeasible TFS and the tail, written in a slashed notation: Indefeasible/Defeasible/Tail. The full PDU-style representation corresponding to Figure 1 is shown in Figure 2 (the atomic FSs shown here are notationally equivalent to the path:value pairs used in Lascarides et al.).</Paragraph>
      <Paragraph position="20"> Note that in Figure 2 the tails do not contain all the default information; in particular, they contain only path value structures, and do not contain equalities on paths (i.e., reentrancies). This contributed to PDU failing to achieve all the criteria mentioned in Section 1.1. YADU is different from PDU, in that it will achieve these criteria. In contrast, the tails in YADU contain information about reentrancy. This means that, unlike in PDU, it is not necessary to maintain the defeasible TFS as a substructure in the representation, since it can be calculated directly from the indefeasible structure and the tail. Thus for YADU we use bipartite structures, which we write Indefeasible/Tail. We will refer to these as typed default feature structures (TDFSs). The YADU representations corresponding to Figure 2 are shown in Figure 3.</Paragraph>
      <Paragraph position="21"> There are two operations in YADU: one involves combining two TDFSs to form &lt;&gt; another TDFS, which we will notate M, and another takes a TDFS and returns a TFS, as discussed below. M corresponds to unifying the indefeasible TFSs of the input TDFSs using the normal definition of typed unification, and taking the set union of their tails, with removal of elements that are inconsistent with the combined indefeasible structure. The full TDFSs corresponding to the constraints in Figure 3 after inheritance are shown in the left-hand column of Figure 4.</Paragraph>
      <Paragraph position="22"> Note that the tails may contain conflicting information. In general, for any operation that makes use of default information, we want to know which elements in the tail &amp;quot;win.&amp;quot; We therefore also define an operation on a TDFS, DefFS, which returns a</Paragraph>
      <Paragraph position="24"> TDFSs and default structures after inheritance using YADU.</Paragraph>
      <Paragraph position="25"> single default TFS (corresponding to the default structure in PDU). The default structures corresponding to the TDFSs are shown in the right-hand column in Figure 4. A default TFS is calculated from a TDFS by unifying in the maximal set of compatible elements of the union of the tails to the nondefault TFS in priority order. In this case, the priority order is given by the ordering in the type hierarchy, that is pst-t-verb is strictly more specific than regverb, which is strictly more specific than verb. In the case where there are no conflicts in the tail, this straightforwardly amounts to the unification of the atomic FSs in the tail, as in the structures shown for verb and regverb in Figure 4. For pst-t-verb, the intermediate results of successively unifying in the tail elements according to their specificity ordering are shown below.</Paragraph>
      <Paragraph position="26">  Thus the conflict between the information on regverb and pst-t-verb is resolved in the favor of the latter, since it is more specific. This is the reason for separating verb and reg-verb in the example above, since we want the +t value to override the +ed information on regverb while leaving intact the default reentrancy which was specified on verb. If we had not done this, there would have been a conflict between the defaults that was not resolved by priority. In such cases, we take the generalization of the competing defaults, but for simplicity we leave the details to Section 3, where the definition of YADU is given.</Paragraph>
      <Paragraph position="27"> Note that in examples such as this one, defaults are being used to capture lexical generalizations, but the suffixes seen by the morphological analyzer must be nondefeasible, otherwise incorrect strings such as sleeped would be accepted, because the default +t could be overridden. We refer to such defaults as nonpersistent since the tails of the TDFSs must be incorporated into the indefeasible structure at the interface between the lexicon and the rest of the system. This is the analogue of the operation called DefFill in Lascar|des et al. (1996), but, In contrast to PDU, YADU DefFill simply amounts to taking the defeasible structure, constructed as described above, since this is guaranteed to be a valid TFS that is more specific than the indefeasible structure.</Paragraph>
      <Paragraph position="28"> For our purposes, it is convenient to define DefFill as returning a TDFS with an empty tail (see Section 3.3 and Section 4). For instance:</Paragraph>
      <Paragraph position="30"> It will be apparent that the tail notation for TDFSs can become quite cumbersome. For cases where there are no conflicts in the tails and where the priority order corresponds to the type of the indefeasible TFS, we can use the slash notation that we initially introduced in Figure 1. This notation can be used as a shorthand for the description of type constraints, and in fact it is generally convenient to use it in the description language, rather than to specify tails individually. We will formalize the relationship between the abbreviatory notation and the full TDFSs in Section 3, and use it when discussing examples where possible.</Paragraph>
      <Paragraph position="31"> Before concluding this section, we should note that there is a contrast in behavior between the PDU and YADU operation, in that with YADU a default value could override a default reentrancy, which was not possible in the earlier work. The reason for making the reentrancy between PAST and PASSP default on verb was that these forms differ in some classes of irregular verbs (e.g., speak, spoke, spoken). In PDU, the default reentrancy could only have been overridden by a nondefault value. Arguably however, the specification of the vowel change and suffixation for this class ought also to be defeasible, because of a subclass of these verbs, such as weave, which are also found with the regular suffixation pattern (wove~weaved, woven~weaved) (cf. Russell et al. 1993). Since such a treatment of dual forms rests on a number of somewhat</Paragraph>
    </Section>
    <Section position="3" start_page="62" end_page="62" type="sub_section">
      <SectionTitle>
Lascarides and Copestake Default Representation
</SectionTitle>
      <Paragraph position="0"> aMb =_1_ aMc =_1_ bMc =_1_ Figure 5 Nonassociativity of asymmetric default unification. controversial assumptions, we will not give details here. However, we will discuss an alternative example where default values must survive when default reentrancies are overridden in Section 4.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>