<?xml version="1.0" standalone="yes"?>
<Paper uid="J99-1002">
  <Title>Default Representation in Constraint-based Frameworks</Title>
  <Section position="5" start_page="94" end_page="98" type="relat">
    <SectionTitle>
6. Extensions and Alternatives
</SectionTitle>
    <Paragraph position="0"> In this section, we briefly consider some variants on the definition of YADU that are useful in specific circumstances.</Paragraph>
    <Section position="1" start_page="94" end_page="96" type="sub_section">
      <SectionTitle>
6.1 Inequalities
</SectionTitle>
      <Paragraph position="0"> We have come across a number of cases where it would be useful to be able to override a default reentrancy without specifying conflicting values for the paths involved.</Paragraph>
      <Paragraph position="1"> For example, consider the type hierarchy shown in Figure 10 and repeated in Figure 19 for convenience. For most of the subtypes of headed-phrase, the CONTENT of the mother should be equivalent to the CONTENT of the head daughter. This holds for head-subject-phrase, head-comps-phrase, and head-specifier-phrase and their subtypes, but it is not true for head-adjunct-phrases, where the content value of the mother is equal to the content value of the single non-head-daughter. It would seem natural to specify the generalization on the supertype headed-phrase as a default constraint, as shown in Figure 20, and to override the default on the subtype head-adjunct-phrase. This would allow the simplification of the hierarchy as shown in Figure 21. However, in standard YADU, there is no way to express the idea that the coindexation between mother and non-head-daughter should hold instead of the coindexation between mother and head-daughter, since, as far as this structure goes,  Inequalities overriding default equalities.</Paragraph>
      <Paragraph position="2"> hd-spr-ph these coindexations are mutually compatible. Of course, the CONTENT values of the head- and non-head- daughters should not be unified in any instantiation of this schema, but since the range of values for each is indefinitely large, there is no way of giving them mutually incompatible types. Thus the type head-nexus-phrase had to be introduced, as a place to state a monotonic constraint on the relationship between semantics values, but this type is otherwise unmotivated and somewhat unintuitive. This sort of situation can be avoided by making use of inequalities, as defined by Carpenter (1992). Intuitively, what is required in order to specify the constraint in Figure 21 on headed-phrase is to say that the constraint on the schema head-adjunct-phrase stipulates explicitly that its head-daughter content is not equal to the content on the mother, as shown in Figure 22.</Paragraph>
      <Paragraph position="3"> To achieve this formally takes only a very minor modification to the definitions already given. First, one must change the definition of TFSs and tails, so that they include inequalities. The relation ~/+C Q x Q is added to the tuple that currently defines TFSs (Definition 2), and a fifth condition is added to the four that are already in that definition, which ensures that ~ is a relation of the right sort (see Carpenter  Lascarides and Copestake Default Representation the existing path:values and path equalities)* The definition of TDFSs is the same as before, except that it is now based on this new definition of TFSs and the new tails. Second, the definition of subsumption changes as in Carpenter (1992)* First, some notation: re ~F re' means 6(r, re) ~ 6(r, re'), Where r is the root node of the TFS.  The definitions of M and U remain the same, save that the new notion of inequated subsumption is used. The resulting operations are still well behaved, in that they are order independent, and return a single result deterministically (see Carpenter \[1992\])* * . * &lt;&gt; The definitions of M and DefFS DefFill and BasicTDFS all remain the same, and the lemmas and theorems given in Sections 3.7 still hold, with the proofs unchanged as given in the appendix. These proofs still hold largely because they depend only on the well-behaved nature of set union, M, and U.</Paragraph>
      <Paragraph position="4"> Note that an inequality can arise in a derived TDFS (or its corresponding default TFS) only if that inequality existed in one of the TDFSs (or tails) that were used to build it via M. Inequalities not explicitly in this input never arise m the result* Consequently, this corresponds to a relatively weak notion of negation. One might learn through M &lt;&gt; v . . or through M that two nodes cannot be equal because they have mcompabble types, but this does not mean that these nodes stand in the inequality relation defined by ~z+. However, one can always convert a TFS into a unique most general fully inequated TFS, as defined in Carpenter (1992) (where a fully inequated TFS is one where any two incompatibly typed nodes in the TFS stand in the inequality relation defined by ~,z+). Thus, one can define a version of DefFS that always outputs a unique fully inequated default TFS also. Furthermore, every TDFS has a unique most general fully inequated TDFS: it amounts to the unique most general fully inequated TFS, plus the tail.</Paragraph>
      <Paragraph position="5"> As far as we are aware, no other version of default unification has been specified that allows for inequalities. In particular, PDU cannot be extended straightforwardly to handle inequalities, because it is computed on a path-by-path basis* Consequently, an attempt to PDU a TDFS with an indefeasible path equality and a TDFS with a default inequality on the same paths results in an ill-formed TDFS. We think that the fact that incorporating default inequalities is possible with such a small change to the definition of YADU attests to its elegance.</Paragraph>
    </Section>
    <Section position="2" start_page="96" end_page="97" type="sub_section">
      <SectionTitle>
6.2 Specificity ordering
</SectionTitle>
      <Paragraph position="0"> Note that although we have consistently used the type hierarchy to give a specificity ordering to tail elements, the only real requirement to be able to define DefFS is that the tail elements have specificity markers that are in a partial order. Hence the defaults that &amp;quot;win&amp;quot; in a TDFS could be determined by an ordering other than the type hierarchy. In fact, any partial order could be utilized: all that is necessary is to indicate the specificity in the tails and to make the definition of the partition of tails sensitive to the relevant partial order. Specifically, the second member of the pairs in the tails, which we have defined as types, should be replaced with specificity information of the relevant sort, and the specificity partition of a tail defined accordingly. The definitions of ~ and DefFS then proceed as before.</Paragraph>
      <Paragraph position="1">  The fact that prioritization of defaults need not be linked to the type hierarchy means that it is straightforward to adapt YADU to untyped feature structures or, in general, to a system where some form of templatic inheritance is used instead of the type hierarchy. It also might be useful if an ordering is given by some component extrinsic to the FSs, such as an ordering based on probabilities. It would even be possible to add a finer grain of specificity to the type hierarchy by creating a specificity ordering of tail elements within types, for instance so that for a type t, specificity markers t 1, t 2 ..... t n were defined so that within-type priority followed numerical ordering. The potential utility of this is shown by the example in Section 2, where the two types verb and regverb were distinguished simply in order to acheive the correct prioritization.</Paragraph>
      <Paragraph position="2"> An alternative would have been to use a single type verb with two distinct specificity markers verb I and verb 2 to get the desired priorities on the defaults.</Paragraph>
    </Section>
    <Section position="3" start_page="97" end_page="98" type="sub_section">
      <SectionTitle>
6.3 Fine-Grained Structures
</SectionTitle>
      <Paragraph position="0"> One point that we glossed over slightly is the use of atomic FSs within a typed framework (as opposed to the untyped FSs assumed in Carpenter \[1993\]). In the definition for BasicTDFS given in Section 3, we assumed that if a path 7r had a value t, then there would be one corresponding path-value atomic FS in the tail. But there is another possibility, which is to have additional structures in the tail, corresponding to each supertype of t: e.g., if w were a supertype of t, then there would also be an atomic FS in the tail where the path 7r was associated with the value w. This would give a finer-grained notion of maximal incorporation of information, since there might be a situation where t was incompatible with a type u in the nondefault FS (or it was incompatible with a more specific default FS) but where u N w resulted in some more specific type v, which would survive in the YADU result (see Figure 23).</Paragraph>
      <Paragraph position="1"> To extend tails this way, one must change the definition of basic TDFSs, to remove the condition (c) from the original definition, which ensured that only the most specific information was included in the tail. So the new definition is: Definition 20: Fine-Grained Basic TDFSs Let I and ID be typed feature structures, where I is regarded as indefeasible and ID as defeasible. Furthermore, suppose that I N ID ~ 3_ (SO I and ID are compatible). Then the fine-grained basic TDFS BasicTDFS(I, ID) of I and ID is the TDFS I/T, such that:</Paragraph>
      <Paragraph position="3"> The existing definitions of ~ and DefFS will then provide the finer-grained notion  Lascarides and Copestake Default Representation of maximal incorporation of default information, from these fine-grained basic TDFSs. Extending tails this way is useful for the treatment of lexical rules, as discussed in Briscoe and Copestake (1995). However it has the obvious disadvantage of considerably increasing the number of atomic FSs that must be considered, with adverse effects on efficiency.</Paragraph>
    </Section>
    <Section position="4" start_page="98" end_page="98" type="sub_section">
      <SectionTitle>
6.4 Credulous YADU
</SectionTitle>
      <Paragraph position="0"> Another way in which the definition could be varied would be to omit the generalization step from DeJFS, which ensures that the default result of a TDFS is a single TFS, and to have a credulous variant of DefFS instead, which would be analogous to Carpenter's (1993) credulous asymmetric default unification: Definition 21: Credulous DefFS Let F be a TDFS I/T. Then</Paragraph>
      <Paragraph position="2"> where {#1 ..... #n/ is a specificity partition on T.</Paragraph>
      <Paragraph position="3"> We argued in Section 1.1 that a unique result is preferable in order to avoid multiplication of disjunctive structures, but disjtmctive results might be useful in cases where there are multiple alternative structures (e.g., in modeling dreamed~dreamt, see Russell et al. \[1993\]).</Paragraph>
    </Section>
    <Section position="5" start_page="98" end_page="98" type="sub_section">
      <SectionTitle>
6.5 Asymmetric Default Unification
</SectionTitle>
      <Paragraph position="0"> We should point out that although we believe order-independent default unification is preferable to asymmetric default unification for many applications, there are situations where the latter is required. YADU could not replace asymmetric default unification in Grover et al.'s (1994) treatment of ellipsis. It is also not directly suitable for encoding lexical rules: it is conventional to write lexical rules using a sort of default notation that is intended to be interpreted as meaning that the output of the rule is identical to the input except where otherwise specified, but formalizing this calls for an asymmetric notion of default (see Briscoe and Copestake \[1995\]). Similarly, Copestake (1992) argues that it is useful to be able to encode irregular lexical entries as inheriting by default from the output of lexical rule application (e.g., the entry for children could inherit from the result of applying a lexical rule for plural formation to the entry for child but override the orthography). This requires asymmetric default unification, where the TFS that results from the application of the lexical rule is treated as defeasible and the specification on the lexical entry is treated as hard information.</Paragraph>
      <Paragraph position="1"> The current LKB implementation thus allows both types of default unification (which is straightforward, since YADU is implemented using a series of asymmetric default unification operations).</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>