<?xml version="1.0" standalone="yes"?>
<Paper uid="P95-1008">
  <Title>DATR Theories and DATR Models</Title>
  <Section position="2" start_page="0" end_page="55" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> DATR was introduced by Evans and Gazdar (1989a; 1989b) as a simple, declarative language for representing lexical knowledge in terms of path/value equations. The language lacks many of the constructs found in general purpose, knowledge representation formalisms, yet it has sufficient expressive power to capture concisely the structure of lexical information at a variety of levels of linguistic description. At the present time, DATR is probably the most widely-used formalism for representing natural language lexicons in the natural language processing (NLP) community. There are around a dozen different implementations of the language and large DATR lexicons have been constructed for use in a variety of applications (Cahill and Evans, 1990; Andry et al., 1992; Cahill, 1994). DATR has been applied to problems in inflectional and derivational morphology (Gazdar, 1992; Kilbury, 1992; Corbett and Fraser, 1993), lexical semantics (Kilgariff, 1993), morphonology (Cahill, 1993), prosody (Gibbon and Bleiching, 1991) and speech (Andry et al., 1992). In more recent work, the language has been used to provide a concise encoding of Lexicalised Tree Adjoining Grammar (Evans et al., 1994; Evans et al., 1995).</Paragraph>
    <Paragraph position="1"> A primary objective in the development of DATR has been the provision of an explicit, mathematically rigorous semantics. This goal was addressed in one of the first publications on the language (Evans and Gazdar, 1989b). The definitions given there deal with a subset of DATR that includes core features of the language such as the notions of local and global inheritance and DATR's default mechanism. However, they exclude some important and widely-used constructs, most notably string (or 'list') values and evaluable paths. Moreover, it is by no means clear that the approach can be generalized appropriately to cover these features. In particular, the formal apparatus introduced by Evans and Gazdar in (1989b) provides no explicit model of DATR's notion of global contexL Rather, local and global inheritance are represented by distinct semantic functions PS: and G.</Paragraph>
    <Paragraph position="2"> This approach is possible only on the (overly restrictive) assumption that DArR statements involve either local or global inheritance relations, but never both.</Paragraph>
    <Paragraph position="3"> The purpose of the present paper is to remedy the deficiencies of the work described in (Evans and Gazdar, 1989b) by furnishing DATR with a transparent, mathematical semantics. There is a standard view of DATR as a language for representing a certain class of non-monotonic inheritance networks ('semantic nets'). While this perspective provides an intuitive and appealing way of thinking about the structure and representation of lexical knowledge, it is less clear that it provides an accurate or particularly helpful picture of the DATR language itself. In fact, there are a number of constructs available in DATR that are impossible to visualize in terms of simple inheritance hierarchies. For this reason, the work described in this paper reflects a rather different perspective on DATR, as a language for defining certain kinds of partial functions by cases. In the following sections this viewpoint is made more precise.</Paragraph>
    <Paragraph position="4"> Section 2 presents the syntax of the DATR language and introduces the notion of a DATR theory. An  informal introduction to the DATR language is provided, by example, in section 3. The semantics of DATR is then covered in two stages. Section 4.1 introduces DATR interepretations and describes the semantics of a restricted version of the language without defaults. The treatment of implicit information is covered in section 4.2, which provides a definition of a default model for a DATR theory.</Paragraph>
  </Section>
class="xml-element"></Paper>