<?xml version="1.0" standalone="yes"?>
<Paper uid="P95-1009">
  <Title>User-Defined Nonmonotonicity in Unification-Based Formalisms</Title>
  <Section position="3" start_page="0" end_page="63" type="intro">
    <SectionTitle>
2 Preliminaries
</SectionTitle>
    <Paragraph position="0"> There are two main properties that will be assumed of a unification-based formalism in order to extend it with the possibility of defining nonmonotonic constructions. The first, and most important, is that we require a subsumption order on the set S of objects denoted by the formalism. Secondly it should be possible to define inheritance hierarchies on the linguistic knowledge described by the formalism.</Paragraph>
    <Paragraph position="1"> One very plausible subsumption order that can be used is the ordinary subsumption lattice of feature structures. It is, however, possible to use some other kind of subsumption order if that is more suitable for the domain to be modelled by the formalism. Examples of other subsumption orders that might be useful are typed feature structures, feature structures extended with disjunction, or simply an order based on sets and set inclusion.</Paragraph>
    <Paragraph position="2"> In this paper the notation a U b is used whenever a subsumes b (i.e. whenever a &amp;quot;is more specific than&amp;quot; or &amp;quot;contains more information than&amp;quot; b). Consequently, a I'- b is used whenever a _ b but a C/ b.</Paragraph>
    <Paragraph position="3"> The subsumption order is assumed to be a semi- null lattice and permits computing a unifier, denoted a N b, corresponding to the greatest lower bound, for every pair of elements within it. The element corresponding to the bottom of the order relation is denoted fail and represents inconsistent information or unification failure.</Paragraph>
    <Paragraph position="4"> The second constraint placed on the formalism, the possibility of defining an inheritance hierarchy, is not essential for the definition of nonmonotonic operations. It is, however, very useful when defining nonmonotonic constructions. The following notation will be used for describing an inheritance hierarchy.</Paragraph>
    <Paragraph position="5"> class the name of the class; isa its parent in the hierarchy; requires a structure.</Paragraph>
    <Paragraph position="6"> Thus, each member in the inheritance hierarchy is called a class, which is defined by giving it a name and a parent in the hierarchy. It is also possible to define some constraints, called requirements, which must hold for a class. These requirements can be both structures in the subsumption order and non-monotonic rules. The constraints on classes are inherited through the hierarchy. Every object in a class is assumed to contain at least the information given by the constraints specified for it and all its ancestors. For simplicity multiple inheritance between classes will not be allowed. This means that two classes where none of them is a subclass of the other, will always be considered inconsistent and thus yield a failure when unified.</Paragraph>
  </Section>
class="xml-element"></Paper>