File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/96/j96-2002_metho.xml
Size: 81,646 bytes
Last Modified: 2025-10-06 14:14:18
<?xml version="1.0" standalone="yes"?> <Paper uid="J96-2002"> <Title>DATR: A Language for Lexical Knowledge Representation</Title> <Section position="5" start_page="169" end_page="171" type="metho"> <SectionTitle> 6 And hence also the extensional version, Wordl : <syn cat> = verb. </SectionTitle> <Paragraph position="0"> Computational Linguistics Volume 22, Number 2 We have two statements at Wordl that (after applying the abbreviation introduced above) both inherit from VERB: Word1: <syn cat> == VERB <syn type> == VERB.</Paragraph> <Paragraph position="1"> Because they have a common leading subpath <syn>, we can collapse them into a single statement about <syn> alone: Wordl: <syn> == VERB.</Paragraph> <Paragraph position="2"> If this were the entire definition of Wordl, the default mechanism would ensure that all extensions of <syn> (including the two that concern us here) would be given the same definition--inheritance from VERB. But in our example, of course, there are other statements concerning Word1. If we add these back in, the complete definition looks like this: The paths <syn type> and <syn cat> (and also many others, such as <syn cat foo>, <syn baz>) obtain their definitions from <syn> using the default mechanism just introduced, and so inherit from VERB. The path <syn form>, being explicitly defined, is exempt from this default behavior, and so retains its value definition, present participle; any extensions of <syn form> obtain their definitions from <syn form> rather than <syn> (since it is a more specific leading subpath), and so will have the value present participle also.</Paragraph> <Paragraph position="3"> The net effect of this definition for Wordl can be glossed as &quot;Wordl stipulates its morphological form to be love ing and inherits values for its syntactic features from VERB, except for <syn form>, which is present participle.&quot; More generally, this mechanism allows us to define nodes differentially: by inheritance from default specifications, augmented by any nondefault settings associated with the node at hand. In fact, the Wordl example can take this default inheritance one step further, by inheriting everything (not just <syn>) from VERB, except for the specifically mentioned values: Wordl:</Paragraph> </Section> <Section position="6" start_page="171" end_page="173" type="metho"> <SectionTitle> <> == VERB </SectionTitle> <Paragraph position="0"> <syn form> == present participle <mor form> == love ing.</Paragraph> <Paragraph position="1"> Here the empty path < > is a leading subpath of every path, and so acts as a &quot;catch all&quot;--any path for which no more specific definition at Word1 exists will inherit from VERB. Inheritance via the empty path is ubiquitous in real DATR lexicons but it should be remembered that the empty path has no special formal status in the language. In this way, Word1 and Word2 can both inherit their general verbal properties from VERB. Of course, these two particular forms have more in common than simply being verbs--they are both instances of the same verb: love. By introducing an abstract Love Evans and Gazdar Lexical Knowledge Representation lexeme, we can provide a site for properties shared by all forms of love (in this simple example, just its morphological root and the fact that it is a verb).</Paragraph> <Paragraph position="2"> == <mor root> ing.</Paragraph> <Paragraph position="3"> == passive participle == <mor root> ed.</Paragraph> <Paragraph position="4"> So now Wordl irrherits from Love rather than VERB (but Love inherits from VERB, so the latter's definitions are still present at Word1). However, instead of explicitly including the atom love in the morphological form, the value definition includes the descriptor <mor root>. This descriptor is equivalent to Wordl:<mor root> and, since <mor root> is not defined at Wordl, the empty path definition applies, causing it to irtherit from Love : <mor root>, and thereby return the expected value, love. Notice here that each element of a value can be defined entirely independently of the others; for <mor form> we now have an irfl~eritance descriptor for the first element and a simple value for the second.</Paragraph> <Paragraph position="5"> Our toy fragment is beginning to look somewhat more respectable: a single node for abstract verbs, a node for each abstract verb lexeme, and then individual nodes for each morphological form of each verb; but there is still more that can be done. Our focus on a single lexeme has meant that one class of redundancy has remained hidden. The line <mor form> == <mor root> ing will occur in every present participle form of every verb, yet it is a completely generic statement &at can be applied to all English present participle verb forms. Can we not replace it with a single statement in the VERB node? Using the mechanisms we have seen so far, the answer is no. The statement would have to be (i), which is equivalent to (ii), whereas the effect we want is (iii): (i) VERB:<mor form> (ii) VERB:<mor form> (iii) VERB:<mor form> == <mor root> ing == VERB:<mor root> ing == Wordl:<mor root> ing Using (i) or (ii), we would end up with the same morphological root for every verb (or more likely no value at all, since it is hard to imagine what value VERB: <mor root> might plausibly be given), rather than a different one for each. 2rod of course, we cannot simply use (iii) as it is, since it only applies to the particular word described by Word1, namely loving.</Paragraph> <Paragraph position="6"> Computational Linguistics Volume 22, Number 2 The problem is that the inheritance mechanism we have been using is local, in the sense that it can only be used to inherit either from a specifically named node (and/or path), or relative to the local context of the node (and/or path) at which it is defined. What we need is a way of specifying inheritance relative to the the original node/path specification whose value we are trying to determine, rather than the one we have reached by following inheritance links. We shall refer to this original specification as the query we are attempting to evaluate, and the node and path associated with this query as the global context. 7 Global inheritance, that is, inheritance relative to the global context, is indicated in DATR by using quoted (&quot;...&quot;) descriptors, and we can use it to extend our definition of VERB as follows: VERB: <syn cat> == verb <syn type> == main <mor form> == &quot;<mor root>&quot; ing.</Paragraph> <Paragraph position="7"> Here we have added a definition for <mor form> that contains the quoted path &quot;<mor root>&quot;. Roughly speaking, this is to be interpreted as &quot;inherit the value of <mor root> from the node originally queried.&quot; With this extra definition, we no longer need a <mor form> definition in Wordl, SO it becomes: Wordl:</Paragraph> </Section> <Section position="7" start_page="173" end_page="177" type="metho"> <SectionTitle> <> == Love </SectionTitle> <Paragraph position="0"> <syn form> == present participle.</Paragraph> <Paragraph position="1"> To see how this global inheritance works, consider the query Wordl : <mor form>. Since <mor form> is not defined at Wordl, it will inherit from VERB via Love. This specifies inheritance of <mot root> from the query node, which in this case is Wordl. The path <mor root> is not defined at Wordl but inherits the value love from Love. Finally, the definition of <mor form> at VERB adds an explicit ing, resulting in a value of love ing for Wordl:<mor form>. Had we begun evaluation at, say, a daughter of the lexeme Eat, we would have been directed from VERB : <mor form> back to the original daughter of Eat to determine its <mor root>, which would be inherited from Eat itself; we would have ended up with the value eat ing.</Paragraph> <Paragraph position="2"> The analysis is now almost the way we would like it to be. Unfortunately, by moving <mor form> from Wordl to VERB, we have introduced a new problem: we have specified the present participle as the (default) value of <mor form> for all verbs. Clearly, if we want to specify other forms at the same level of generality, then <mor form> is currently misnamed: it should be <mor present participle>, so that we can add <mor past participle>, <mor present tense>, etc. If we make this change, then the VERB node will look like this:</Paragraph> <Section position="1" start_page="174" end_page="177" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation </SectionTitle> <Paragraph position="0"> <mor present> == &quot;<mor root>&quot; <mor present participle> == &quot;<mor root>&quot; ing <mor present tense sing three> == &quot;<mor root>&quot; s. In adding these new specifications, we have added a little extra structure as well. The passive form is asserted to be the same as the past form--the use of global inheritance here ensures that irregular or subregular past forms result in irregular or subregular passive forms, as we shall see shortly. The paths introduced for the present forms illustrate another use of default definitions. We assume that the morphology of present tense forms is specified with paths of five attributes, the fourth specifying number, the fifth, person. Here we define default present morphology to be simply the root, and this generalizes to all the longer forms, except the present participle and the third person singular.</Paragraph> <Paragraph position="1"> For Love, given these changes, the following extensional statements hold, inter</Paragraph> <Paragraph position="3"> present tense sing one> = love present tense sing two> = love present tense sing three> = love s present tense plur> = love present participle> = love ing past tense sing one> = love ed past tense sing two> = love ed past tense sing three> = love ed past tense plur> = love ed past participle> = love ed passive participle> = love ed.</Paragraph> <Paragraph position="4"> There remains one last problem in the definitions of Wordl and Word2. The morphological form of Word1 is now given by <mor present participle>. Similarly, Word2's morphological form is given by <mor passive participle>. There is no longer a unique path representing morphological form. This can be corrected by the addition of a single statement to VERB:</Paragraph> <Paragraph position="6"> <mor form> == &quot;<mor &quot;<syn form>&quot;>&quot;.</Paragraph> <Paragraph position="7"> This statement employs a DATR construct, the evaluable path, which we have not encountered before. The right-hand side consists of a (global) path specification, one of whose component attributes is itself a descriptor that must be evaluated before the outer path can be. The effect of the above statement is to say that <mor form> globally inherits from the path given by the atom mor followed by the global value of <syn form>. For Wordl, <syn form> is present participle, so <mor form> inherits from <mor present participle>. But for Word2, <mor form> inherits from <mor passive participle>. Effectively, <syn form> is being used here as a parameter to control which specific form should be considered the morphological form. Evaluable paths may themselves be global (as in our example) or local, and their evaluable components may also involve global or local reference.</Paragraph> <Paragraph position="8"> As noted above, the passive forms of these subregular verbs will be correct now as well, because of the use of a global cross-reference to the past participle form in the VERB node. For example, the definition of the passive form of sew is:</Paragraph> <Paragraph position="10"> <syn form> == passive participle.</Paragraph> <Paragraph position="11"> If we seek to establish the <mor form> of Word3, we are sent up the hierarchy of nodes, first to Sew, then to EN_VERB, and then to VERB. Here we encounter &quot;<mot &quot;<syn form>&quot; >&quot;, which resolves to &quot;<mor passive participle>&quot; in virtue of the embedded global reference to <syn form> at Word3. This means we now have to establish the value of <mor passive participle> at Word3. Again, we ascend the hierarchy to VERB and find ourselves referred to the global descriptor &quot;<mor past participle>&quot; This takes us back to Word3, from where we again climb, first to Sew, then to EN_VERB.</Paragraph> <Paragraph position="12"> Here, <mor past participle> is given as the sequence &quot;<mor root>&quot; en. This leads us to look for the <mor root> of Word3, which we find at Sew, giving the result we seek: Word3: <mor form> = sew en.</Paragraph> <Paragraph position="13"> Irregularity can be treated as just the limiting case of subregularity, so, for example, the morphology of Do can be specified as follows: 1deg</Paragraph> <Paragraph position="15"> <mor past participle> == done <mor present tense sing three> == does. Likewise, the morphology of Be can be specified as follows: n</Paragraph> <Paragraph position="17"> <mor root> == be 10 Orthographically, the form does could simply be treated as regular (from do s). However, we have chosen to stipulate it here since, although the spelling appears regular, the phonology is not, so in a lexicon that defined phonological forms it would need to be stipulated.</Paragraph> <Paragraph position="18"> 11 In their default unification reconstruction of this DATR analysis of English verbal inflection, Bouma and Nerbonne (1994, 48) invoke &quot;a feature -SG3 to cover all agreement values other than third person singular&quot; in order &quot;to avoid redundancy,&quot; but they do not explain how they would then account for the first person singular present tense form of be without reintroducing the redundancy that they are seeking to avoid. Moreover, the use of this purely morphological feature leads them to introduce a set of lexical rules in order to map the relevant information across from the (different) syntactic features. Computational Linguistics Volume 22, Number 2 <mor present tense sing one> == am <mor present tense sing three> == is <mor present tense plur> == are <mor past tense sing one> == <mor past tense sing three> <mor past tense sing three> == was <mor past tense plur> == were.</Paragraph> <Paragraph position="19"> In this section, we have moved from simple attribute/value listings to a compact, generalization-capturing representation for a fragment of English verbal morphology. In so doing, we have seen examples of most of the important ingredients of DATR: local and global descriptors, definition by default, and evaluable paths.</Paragraph> </Section> </Section> <Section position="8" start_page="177" end_page="200" type="metho"> <SectionTitle> 3. The DATR Language </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="177" end_page="178" type="sub_section"> <SectionTitle> 3.1 Syntax </SectionTitle> <Paragraph position="0"> A DATR description consists of a sequence of sentences corresponding semantically to a set of statements. Sentences are built up out of a small set of basic expression types, which themselves are built up out of sequences of lexical tokens, which we take to be primitive.</Paragraph> <Paragraph position="1"> In the previous section, we referred to individual lines in DATR definitions as statements. Syntactically, however, a DATR description consists of a sequence of sentences, where each sentence starts with a node name and ends with a period, and contains one or more path equations relating to that node, each corresponding to a statement in DATR. This distinction between sentences and statements is primarily for notational convenience (it would be cumbersome to require repetition of the node name for each statement) and statements are the primary unit of specification in DATR. For the purposes of this section, where we need to be particularly clear about this distinction, we shall call a sentence containing just a single statement a simple sentence.</Paragraph> <Paragraph position="2"> 3.1.1 Lexical Tokens. The syntax of DATR distinguishes four classes of lexical token: nodes, atoms, variables, and reserved symbols. The complete list of reserved symbols is as follows:</Paragraph> <Paragraph position="4"> We have already seen the use of the first seven of these. Single quotes can be used to form atoms that would otherwise be ill-formed as such; Y, is used for end-of-line comments, following the Prolog convention; # is used to introduce declarations and other compiler directives. 12 The other classes, nodes, atoms, and variables, must be distinct, and distinct from the reserved symbols, but are otherwise arbitrary. 13 For this discussion, we have already adopted the convention that both nodes and atoms are simple words, with nodes starting with uppercase letters. We extend this convention to variables, discussed more fully in Section 3.4 below, which we require to start with the character $. And we take white space (spaces, new lines, tabs, etc.) to delimit lexical tokens but otherwise to be insignificant.</Paragraph> <Paragraph position="5"> 12 Aside from their use in Section 3.4, we will completely ignore such directives in this paper. 13 Formally, we require them to be finite classes, but this is not of great significance here.</Paragraph> </Section> <Section position="2" start_page="178" end_page="179" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation </SectionTitle> <Paragraph position="0"> sides of DATR equations are sequences of zero or more descriptors. 14 Descriptors are defined recursively, and come in seven kinds. The simplest descriptor is just an atom or variable: atoml $varl Then there are three kinds of local inheritance descriptor: a node, an (evaluable) path, and a node/path pair. Nodes are primitive tokens, paths are descriptor sequences (defined below) enclosed in angle brackets and node/path pairs consist of a node and a path, separated by a colon: Nodel <descl desc2 desc3 ...> Nodel:<descl desc2 desc3 ...> Finally there are three kinds of global inheritance descriptor, which are quoted variants of the three local types just described: &quot;Nodel&quot; &quot;<descl desc2 desc3 ...>&quot; &quot;Nodel:<descl desc2 desc3 ...>&quot; A descriptor sequence is a (possibly empty) sequence of descriptors. The recursive definition of evaluable paths in terms of descriptor sequences allows arbitrarily complex expressions to be constructed, such as: 15 &quot;Nodel : <&quot;<atoml>&quot; Node2 : <atom2>>&quot; &quot;<&quot;<&quot;<Nodel:<atoml atom2> atom3>&quot; Node2 &quot;<atom4 atom5>&quot; <> >&quot;>&quot; But the value sequences determined by such definitions are fiat: they have no structure beyond the simple sequence and in particular do not reflect the structure of the descriptors that define them.</Paragraph> <Paragraph position="1"> We shall sometimes refer to descriptor sequences containing only atoms as simple values, and similarly, (unquoted) path expressions containing only atoms as simple paths.</Paragraph> <Paragraph position="2"> 3.1.3 Sentences. DATR sentences represent the statements that make up a description. As we have already seen, there are two basic statement types, extensional and definitional, and these correspond directly to simple extensional and definitional sentences, which are made up from the components introduced in the preceding section. 14 DATR makes a distinction between a path not having a value (i.e., being undefined) and a path having the empty sequence as a value: NUM:</Paragraph> <Paragraph position="4"> In this example, NUM: <one> has the value one, RUM: <two> has the empty sequence as its value, and IoJg: <three> is simply undefined.</Paragraph> <Paragraph position="5"> 15 A descriptor containing an evaluable path may include nested descriptors that are either local or global. Our use of the local/global terminology always refers to the outermost descriptor of an expression. Computational Linguistics Volume 22, Number 2 Simple extensional sentences take the form Node:Path = Ext.</Paragraph> <Paragraph position="6"> where Node is a node, Path is a simple path, and Ext is a simple value. Extensional sentences derivable from the examples given in Section 2 include: Do:<mor past participle> = done.</Paragraph> <Paragraph position="7"> Mow:<mor past tense sing one> = mow ed.</Paragraph> <Paragraph position="8"> Love:<mor present tense sing three> = love s.</Paragraph> <Paragraph position="9"> Simple definitional sentences take the form Node:Path == Def.</Paragraph> <Paragraph position="10"> where Node and Path are as above and Def is an arbitrary descriptor sequence. Deftnitional sentences already seen in Section 2 include: Do:<mor past> == did.</Paragraph> <Paragraph position="11"> VERB:<mor form> == &quot;<mor &quot;<syn form>&quot;>&quot;. EN_VERB:<mor past participle> == &quot;<mor root>&quot; en. Each of these sentences corresponds directly to a DATR statement. However we extend the notion of a sentence to include an abbreviatory convention for sets of statements relating to a single node. The following single sentence:</Paragraph> <Paragraph position="13"> Extensional statements, and combinations of definitional and extensional statements, may be similarly abbreviated, and the examples used throughout this paper make extensive use of this convention. Such compound sentences correspond to a number of individual (and entirely independent) DATR statements.</Paragraph> <Paragraph position="14"> Finally, it is worth reiterating that DATR descriptions correspond to sets of statements: the order of sentences, or of definitions within a compound sentence, is immaterial to the relationships described.</Paragraph> </Section> <Section position="3" start_page="179" end_page="184" type="sub_section"> <SectionTitle> 3.2 Inheritance in DATR </SectionTitle> <Paragraph position="0"> DATR descriptions associate values with node/path pairs. This is achieved in one of three ways: a value is explicitly stated, or it is explicitly inherited, or it is implicitly Evans and Gazdar Lexical Knowledge Representation specified (stated or inherited) via the default mechanism. We have already seen how values are explicitly stated; in this and the following subsections, we continue our exposition by providing an informal account of the semantics of specification via inheritance or by default. The present subsection is only concerned with explicit (i.e., nondefault) inheritance. Section 3.3 deals with implicit specification via DATR's default mechanism.</Paragraph> <Paragraph position="1"> of a value by local inheritance. Such specifications may provide a new node, a new path, or a new node and path to inherit from. An example definition for the lexeme Come illustrates all three of these types: Come:</Paragraph> <Paragraph position="3"> Here the empty path inherits from VERB so the value of Come:<> is equated to that of VERB: <>. And the past participle inherits from the root: Come:<mor past participle> is equated to Come : <mor root) (i.e., come). In both these inheritances, only one node or path was specified: the other was taken to be the same as that found on the left-hand side of the statement (<> and Come respectively). The third type of local inheritance is illustrated by the final statement, in which both node and path are specified: the syntax of Come is equated with the empty path at INTRANSITIVE, an abstract node defining the syntax of intransitive verbs} 6 There is a natural procedural interpretation of this kind of inheritance, in which the value associated with the definitional expression is determined by &quot;following&quot; the inheritance specification and looking for the value at the new site. So given a DATR description (i.e., a set of definitional statements) and an initial node/path query, we look for the node and path as the left-hand side of a definitional statement. If the definitional statement for this pair provides a local descriptor, then we follow it, by changing one or both of node or path, and then repeat the process with the resulting node/path pair. We continue until some node/path pair specifies an explicit value. In the case of multiple expressions on the right-hand side of a statement, we pursue each of them entirely independently of the others. This operation is local in the sense that each step is carried out without reference to any context wider than the immediate definitional statement at hand.</Paragraph> <Paragraph position="4"> Declaratively speaking, local descriptors simply express equality constraints between definitional values for node/path pairs. The statement:</Paragraph> <Paragraph position="6"> since the latter is equivalent to</Paragraph> <Paragraph position="8"> Computational Linguistics Volume 22, Number 2 can be read approximately as &quot;if the value for Node2 : Path2 is defined, then the value of Nodel:Pathl is defined and equal to it.&quot; There are several points to notice here. First, if Node2:Path2 is not defined, then Nodel:Pathl is unconstrained, so this is a weak directional equality constraint. However, in practice this has no useful consequences, due to interactions with the default mechanism (see Section 5.1 below).</Paragraph> <Paragraph position="9"> Second, &quot;defined&quot; here means &quot;defined by a definitional statement,&quot; that is, a &quot;==&quot; statement: local inheritance operates entirely with definitional statements, implicitly introducing new ones for Nodel :Path1 on the basis of those defined for Node2:Path2.</Paragraph> <Paragraph position="10"> Finally, as we shall discuss more fully in the next subsection, &quot;value&quot; here technically covers both simple values and global inheritance descriptors.</Paragraph> <Paragraph position="11"> types: node, path, and node/path pair. However, when either the node or the path is omitted from a global inheritance descriptor, rather than using the node or path of the left-hand side of the statement that contains it (the local context of the definition), the values of a global context are used instead. This behavior is perhaps also more easily introduced procedurally rather than declaratively. As we saw above, we can think of local inheritance in terms of following descriptors starting from the query.</Paragraph> <Paragraph position="12"> The local context is initially set to the node and path specified in the query. When a local descriptor is encountered, any missing node or path components are filled in from the local context, and then control passes to the new context created (that is, we look at the definition associated with the new node/path pair). In doing this, the local context also changes to be the new context. Global inheritance operates in exactly the same way: the global context is initially set to the node and path specified in the query. It is not altered when local inheritance descriptors are followed (it &quot;remembers&quot; where we started from), but when a global descriptor is encountered, it is the global context that is used to fill in any missing node or path components in the descriptor, and hence to decide where to pass control to. In addition, both global and local contexts are updated to the new settings. So global inheritance can be seen as essentially the same mechanism as local inheritance, but layered on top of it--following global links alters the local context too, but not vice versa.</Paragraph> <Paragraph position="13"> For example, when a global path is specified, it effectively returns control to the current global node (often the original query node) but with the newly given path.</Paragraph> <Paragraph position="14"> Thus in Section 2, above, we saw that the node VERB defines the default morphology of present forms using global inheritance from the path for the morphological root: VERB:<mor present> == &quot;<mor root>&quot;.</Paragraph> <Paragraph position="15"> The node from which inheritance occurs is that stored in the global context: a query of Love : <mor present> will result in inheritance from Love : <mor root> (via VERB: <mor present>), while a query of Do:<mor present> will inherit from Do:<mor root>.</Paragraph> <Paragraph position="16"> Similarly, a quoted node form accesses the globally stored path value, as in the following example:</Paragraph> <Paragraph position="18"> Here, the value of Declension3:<accusative> inherits from Declension2:<vocative> and then from Declensionl : <accusative>, using the global path (in this case the query path), rather than the local path (<vocative>) to fill out the specification.</Paragraph> <Paragraph position="19"> The resulting value is -am and not -a as it would have been if the descriptor in Declension2 had been local, rather than global.</Paragraph> <Paragraph position="20"> We observed above that when inheritance through a global descriptor occurs, the global context is altered to reflect the new node/path pair. Thus after Love:<mor present> has inherited through &quot;VERB: <mor root>&quot;, the global path will be <mor root> rather than <mor present>. When we consider quoted node/path pairs, it turns out that this is the only property that makes them useful. Since a quoted node/path pair completely respecifies both node and path, its immediate inheritance characteristics are the same as the unquoted node/path pair. However, because it also alters the global context, its effect on any subsequent global descriptors (in the evaluation of the same query) will be different: In this example, the value of Declension3 : <accusative> inherits from Declension2 : <vocative> and then from Declension1 : <vocative> and then from Declension2 : <nominative> (because the global node has changed from Declension3 to Declension2) giving a value of -u and not -i as it would have been if the descriptor in Declension3 had been local, rather than global.</Paragraph> <Paragraph position="21"> There are a number of ways of understanding this global inheritance mechanism.</Paragraph> <Paragraph position="22"> The description we have given above amounts to a &quot;global memory&quot; model, in which a DATR query evaluator is a machine equipped with two memories: one containing the current local node and path, and another containing the current global node and path. Both are initialized to the query node and path, and the machine operates by repeatedly examining the definition associated with the current local settings. Local descriptors alter just the local memory, while global descriptors alter both the local and global settings.</Paragraph> <Paragraph position="23"> This model is the basis of at least one implementation of DATR but it is not, of course, declarative. Nevertheless, the notion of global inheritance does have a declarative reading, very similar to local inheritance but, as we have already suggested, layered on top of it. Recall that local inheritance establishes a network of weak equality relationships among node/path pairs, and these equalities are used to distribute values across this network. Formally speaking, the local inheritance network controls the distribution not only of simple values, but also of global descriptors, as we mentioned above. That is, to local inheritance, values and global descriptors are one and the same, and are inherited through the network. Indeed, this is the intuitive warrant for the use of the quote notation: the quotes turn an inheritance descriptor into a (kind Computational Linguistics Volume 22, Number 2 of) value. Consequently, global descriptors are also distributed through the local inheritance network, and so are implicitly present at many node/path pairs in addition to those they are explicitly defined for. In fact, a global descriptor is implicitly present at every node/path pair that could ever occur as the global context for evaluation of the descriptor at its original, explicitly defined location. This means that once distributed in this way, the global descriptors form a network of weak equality relationships just as the local descriptors do, and distribute the simple values (alone) in the same way. To see this interpretation in action, we consider an alternative analysis of the past participle form of Come. The essential elements of the analysis are as follows: BARE_VERB: <mor past participle> == &quot;<mor root>&quot;.</Paragraph> <Paragraph position="24"> Come: <mor root> == come <mor past participle> == BARE_VERB.</Paragraph> <Paragraph position="25"> Local inheritance from BARE_VERB to Come implicitly defines the following statement (in addition to the above): Come: <mor past participle> == &quot;<mor root>&quot;.</Paragraph> <Paragraph position="26"> Because we have now brought the global inheritance descriptor to the node corresponding to the global context for its interpretation, global inheritance can now operate entirely locally--the required global node is the local node, Come, producing the desired result: Come: <mor past participle> = come.</Paragraph> <Paragraph position="27"> Notice that, in this last example, the final statement was extensional, not definitional. So far in this paper we have almost entirely ignored the distinction we established between definitional and extensional statements, but with this declarative reading of global inheritance we can do so no longer. Local inheritance uses definitional inheritance statements to distribute simple values and global descriptors. The simplevalued definitional statements thereby defined map directly to extensional statements, and global inheritance uses the global inheritance statements (now distributed), to further distribute these extensional statements about simple values. The statements must be of a formally distinct type, to prevent local inheritance descriptors from distributing them still further. In practice, however, we need not be too concerned about the distinction: descriptions are written as definitional statements, queries are read off as extensional statementsJ 7 The declarative interpretation of global inheritance suggests an alternative procedural characterization to the one already discussed, which we outline here. Starting from a query, local descriptors alone are used to determine either a value or a global descriptor associated with the queried node/path pair. If the result is a global descriptor, this is used to construct a new query, which is evaluated in the same way. The 17 However, in principle, there is nothing to stop an extensional statement from being specified as part of a DATR description directly. Such a statement would respect global inheritance but not local inheritance, and might be useful to achieve some exotic effect.</Paragraph> <Paragraph position="28"> Evans and Gazdar Lexical Knowledge Representation process repeats until a value is returned. The difference between this and the earlier model is one of perspective: When a global descriptor is encountered, one can either bring the global context to the current evaluation context (first model), or take the new descriptor back to the global context and continue from there (second model). The significance of the latter approach is that it reduces both kinds of inheritance to a single basic operation with a straightforward declarative interpretation. Thus we see that DATR contains two instances of essentially the same declarative inheritance mechanism. The first, local inheritance, is always specified explicitly, while the second, global inheritance, is specified implicitly in terms of the first.</Paragraph> <Paragraph position="29"> Extending these inheritance mechanisms to the more complex DATR expressions is straightforward. Descriptors nested within definitional expressions are treated independently-as though each was the entire value definition rather than just an item in a sequence. In particular, global descriptors that alter the global context in one nested definition have no effect on any others. Each descriptor in a definitional sequence or evaluable path is evaluated from the same global state. In the case of global evaluable paths, once the subexpressions have been evaluated, the expression containing the resultant path is also evaluated from the same global state.</Paragraph> </Section> <Section position="4" start_page="184" end_page="186" type="sub_section"> <SectionTitle> 3.3 Definition by Default </SectionTitle> <Paragraph position="0"> The other major component of DATR is definition by default. This mechanism allows a DATR definitional statement to be applicable not only for the path specified in its left-hand side, but also for any rightward extension of that path for which no more specific definitional statement exists. In effect, this &quot;fills in the gaps&quot; between paths defined at a node, on the basis that an undefined path takes its definition from the path that best approximates it without being more specific. TM Of course, to be effective, this &quot;filling in&quot; has to take place before the operation of the inheritance mechanisms described in the previous section.</Paragraph> <Paragraph position="1"> Consider for example, the definition of Do we gave above.</Paragraph> <Paragraph position="3"> <mor past participle> == done <mor present tense sing three> == does. Filling in the gaps between these definitions, we can see that many paths will be implicitly defined only by the empty path specification. Examples include:</Paragraph> <Paragraph position="5"> <mor present tense sing one> == VERB.</Paragraph> <Paragraph position="6"> If there had been no definition for < >, then none of these example paths would have 18 For formal discussion of the semantics of the DATR default mechanism, see Keller (1995). Computational Linguistics Volume 22, Number 2 been defined at all, since there would have been no leading subpath with a definition. Note how <mor> itself takes its definition from <>, since all the explicitly defined <mor ...> specifications have at least one further attribute.</Paragraph> <Paragraph position="7"> The definition for <mor past> overrides default definition from <> and in turn provides a definition for longer paths. However, <mor past participle> blocks default definition from <mor past>. Thus the following arise: 19 tense plur> == did tense sing three> == did participle plur> == done participle sing one> == done.</Paragraph> <Paragraph position="8"> Similarly all the <mor present> forms inherit from VERB except for the explicitly cited <mor present tense sing three>.</Paragraph> <Paragraph position="9"> Definition by default introduces new DATR sentences, each of whose left-hand-side paths is an extension of the left-hand-side paths of some explicit sentence. This path extension carries over to any paths occurring on the right-hand side as well. For example, the sentence: VERB: <mor present tense> == &quot;<mor root>&quot; <mor form> == <mor &quot;<syn form>&quot;>.</Paragraph> <Paragraph position="10"> gives rise to the following, inter alia: VERB: <mor present tense sing> == &quot;<mor root sing>&quot; <mor present tense plur> == &quot;<mor root plur>&quot; <mor form present> == <mor &quot;<syn form present>&quot; present> <mor form passive> == <mor &quot;<syn form passive>&quot; passive>. This extension occurs for all paths in the right-hand side, whether they are quoted or unquoted and/or nested in descriptor sequences or evaluable paths. The intent of this path extension is to allow descriptors to provide not simply a single definition for a path but a whole set of definitions for extensions to that path, without losing path information. In some cases this can lead to gratuitous extensions to paths--path attributes specifying detail beyond any of the specifications in the overall description. However, this does not generally cause problems since such gratuitously detailed paths, being unspecified, will always take their value from the most specific path that is specified; effectively, gratuitous detail is ignored. 2deg Indeed, DATR's approach to default information always implies an infinite number of unwritten DATR statements, with paths of arbitrary length.</Paragraph> <Paragraph position="11"> 19 The past participle extensions here are purely for the sake of the formal example---they have no role to play in the morphological description of English (but cf. French, where past participles inflect for gender and number). 20 Thus, for example, the path <mor plur acc> is a gratuitous extension of the path <mor plur> for English common nouns, since the latter are not differentiated for case.</Paragraph> </Section> <Section position="5" start_page="186" end_page="189" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation 3.4 Abbreviatory Variables </SectionTitle> <Paragraph position="0"> The default mechanism of DATR provides for generalization across sets of atoms by means of path extension, and is the preferred mechanism to use in the majority of cases. However, to transduce atoms in the path domain to atoms in the value domain (see Section 4.3, below), it is extremely convenient to use abbreviatory variables over finite sets of atoms. This is achieved by declaring DATR variables whose use constitutes a kind of macro: they can always be eliminated by replacing the equations in which they occur with larger sets of equations that spell out each value of the variables.</Paragraph> <Paragraph position="1"> Conventionally, variable names begin with the S character and are declared in one of the following three ways: Here, the first case declares a variable $Varl that ranges over the values Rangel, Range2 .... where each RangeN is either an atom or a variable name; the second case declares $Var2 to range over the same range, but excluding values in RangeA RangeB ...; and the third declares SVar3 to range over the full (finite) set of atoms in the language. 21 For example: Caution has to be exercised in the use of DATR variables for two reasons. One is that their use makes it hard to spot multiple conflicting definitions: # vars $vowel: a e i o u.</Paragraph> <Paragraph position="2"> DIPTHONG:</Paragraph> <Paragraph position="4"> Here, <e> appears on the left hand side of two conflicting definitions. Exactly what happens to such an improper description in practice depends on the implementation, and usages of this kind can be the source of hard-to-locate bugs (see also Section 5.1, below).</Paragraph> <Paragraph position="5"> The other reason is that one can fall into the trap of using variables to express generalizations that would be better expressed using the path extension mechanism. Here is a very blatant example: # vars Snumber: singular plural.</Paragraph> <Paragraph position="6"> 21 Undeclared variables are similarly assumed to range over the full set of atoms. Some implementations may also include implicit definitions of more restricted variables, such as $integer. However, the components of <syn form>, present, sing, third are themselves values of features we probably want to represent independently. One way to achieve this is to define a value for <syn form> which is itself parameterized from the values of these other features. And the appropriate place to do this is in the VERB node, thus:</Paragraph> <Paragraph position="8"> This says that the default value for the syntactic form of a verb is a finite form, but exactly which finite form depends on the settings of three other paths, <syn tense>, 22 More generally, evaluable paths provide structured inheritance in the sense of Daelemans and De Smedt (1994, 161-168).</Paragraph> <Paragraph position="9"> This approach has the advantage that the attribute ordering used in the <mor... > paths is handled internally: the leaf nodes need not know or care about it. 23</Paragraph> </Section> <Section position="6" start_page="189" end_page="190" type="sub_section"> <SectionTitle> 4.2 Boolean Logic </SectionTitle> <Paragraph position="0"> We can, if we wish, use parameters in evaluable paths that resolve to true or false.</Paragraph> <Paragraph position="1"> We can then define standard truth tables over DATR paths: <or false false> == false.</Paragraph> <Paragraph position="2"> This node defines the standard truth tables for all the familiar operators and connectives of the propositional calculus expressed in Polish order rather than infix order. 24 Notice, in particular, how the DATR default mechanism completes most of the truth table rows without explicit listing. The definability of the propositional calculus may appear, at first sight, to be a curiosity, one which has no relevance to real-life lexical representation. But that is not so. Consider a hypothetical language in which personal proper names have one of two genders, masculine or feminine. Instead of the gender being wholly determined by the sex of the referent, the gender is determined partly by sex and partly by the phonology. Examples of this general type are quite common in the world's languages. 2s In our hypothetical example, the proper name will have feminine gender either if it ends in a consonant and denotes a female or if it ends in a stop consonant but does not denote a female. We can encode this situation in DATR as follows: 26</Paragraph> <Paragraph position="4"> 23 Word3 remains unchanged, overriding the definition of <syn form> and so not requiring these additional features to be defined at all.</Paragraph> <Paragraph position="5"> 24 We can, of course, use the same technique to define many-valued logics if we wish. 25 For example, Fraser and Corbett (1995) use DATR to capture a range of phonology/morphology/semantics interdependencies in Russian. And Brown and Hippisley (1994) do the same for a Russian segmental phonology/prosody/morphology interdependency. But one can find such interdependencies in English also: see Ostler and Atkins (1992, 96-98).</Paragraph> <Paragraph position="6"> 26 Note that complex expressions require path embedding. Thus, for example, the well-formed negation of a conditional is <not <if . . . >> rather than <not if ... >.</Paragraph> </Section> <Section position="7" start_page="190" end_page="192" type="sub_section"> <SectionTitle> 4.3 Finite-state Transduction </SectionTitle> <Paragraph position="0"> Perhaps surprisingly, DATR turns out to be an excellent language for defining finite-state transducers (FSTs). 29 A path carl be used as the input tape and a value as the output tape (recall that the DATR default mechanism means that extensions to left-hand-side paths are automatically carried over as extensions to right-hand-side paths, as discussed in Section 3.3, above). Nodes can be used for states, or else states can be encoded in attributes that are prefixed to the current input path. Here, for example, is a very simple DATR FST that will transduce a path such as <subj 1 sg futr obj 2 27 For the sake of simplicity, we have assumed that the truth values of <ends_in_consonant> and <ends_in_stop> are just stipulated in the entries, and indeed the second definition in Personal_name means that <ends_in_stop> implies <ends_in_consonant>. But if the entries represented the phonology of the words in DATR also, then these predicates could be defined on the basis of the feature composition of the stem-final segment. As a number of researchers have shown, the highly defaulty character of lexical phonology and morphophonology makes DATR a very suitable medium of representation (Bleiching 1992, 1994; Cahill 1993b; Gibbon 1990, 1992; Gibbon and Bleiching 1991; Reinhard 1990; Reinhard and Gibbon 1991).</Paragraph> <Paragraph position="1"> 28 It is straightforward to add extra DATR code so as to derive <gender> = feminine when <gender_is_feminine> is true and <gender> ---- masculine when <gender_is_feminine> is false, or conversely.</Paragraph> <Paragraph position="2"> 29 Cf. Krieger, Pirker, and Nerbonne (1993), who reconstruct finite-state automata in a feature description language.</Paragraph> <Paragraph position="3"> <subj i sg> == ni 82:<> <subj 2 sg> == u S2:<> <subj 3 sg> == a $2:<> <subj i pl> == tu $2:<> <subj 2 pl> == m $2:<> <subj 3 pl> == wa $2:<>.</Paragraph> <Paragraph position="4"> <past> == li $3:<> <futr> == ta S3:<>.</Paragraph> <Paragraph position="5"> <obj i sg> == ni S4:<> <obj 2 sg> == ku $4:<> <obj 3 sg> == m S4:<> <obj 1 pl> == tu $4:<> <obj 2 pl> == wa $4:<> <obj 3 pl> == wa $4:<>.</Paragraph> <Paragraph position="6"> <like> == penda.</Paragraph> <Paragraph position="7"> Although the example is trivial, the technique is both powerful and useful. Gibbon (1990), for example, has made notably effective use of it in his treatments of African tone systems. 31 Much of the computational phonology and morphology of the last decade and a half has depended on FSTs (Kaplan and Kay 1994). Potential lexical applications come readily to mind--for example, the orthographic spelling rules for English suffixation (such as sky~skies). We give below a small fragment of such an FST in which + is used as a morpheme boundary marker. Note the role of DATR variables in giving concise expression to the rules: # vars Sabc: a b c d e f g h i j k I m n o p q r s t u v w x y z. # vars Svow: a e i o u.</Paragraph> <Paragraph position="9"> These axioms then give rise to theorems such as these: SPELL: <love> =love <love+s> =loves <i o v e + e d> = i o v e d <i o v e + e r> = 1 o v e r <i o v e + I y> = 1 o v e 1 y 30 For clarity, this FST does not exploit default inheritance to capture the 50% overlap between the subject and object pronoun paradigms. See Gazdar (1992) for a version that does. 31 And see McFetridge and Villavicencio (1995) for a less exotic application.</Paragraph> </Section> <Section position="8" start_page="192" end_page="192" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation </SectionTitle> <Paragraph position="0"> <i o v e + i n g> = 1 o v i n g <i o v e + a b 1 e> = 1 o v a b 1 e.</Paragraph> </Section> <Section position="9" start_page="192" end_page="192" type="sub_section"> <SectionTitle> 4.4 Representing Lists </SectionTitle> <Paragraph position="0"> DATR's foundation in path/value specifications means that many of the representational idioms of unification formalisms transfer fairly directly. A good example is the use of first and rest attributes to represent list-structured features, such as syntactic arguments and subcategorized complements. The following definitions could be used to extend our verb fragment by introducing the path <syn args>, which determines Here extensions of <syn args first> specify properties of the first syntactic argument, while extensions of <syn args rest> specify the others (as a first/rest list). UNDEF is the name of a node that is not defined in the fragment, thus ensuring that <syn args rest first>, <syn args rest rest>, and so forth, are all undefined.</Paragraph> <Paragraph position="1"> The fragment above provides a default specification for <syn args> for verbs consisting of just one argument, the subject NP. Subclasses of verb may, of course, override any part of this default; for instance, transitive verbs add a second syntactic argument for their direct object: This example introduces several new techniques. Firstly, in TR_VERB we have a double parametrization on <syn form>: the value of <syn form> is evaluated and used to create a <mood> path; the value returned by this path is then used to route the inheritance. This allows us to employ the default mechanism to make the default mood active (for arbitrary <syn form> values other than those that begin with the atom passive), and thus just pick out <syn form> passive (and its extensions) for verbs in the passive mood. Secondly, <active> and <passive> path prefixes are provided for the explicit purpose of controlling the inheritance route. Thirdly, the example presupposes a distinction between the syntactic arguments list (<syn args>) associated with a lexeme and the subcategorization frame list (<syn subcat>) associated with a particular syntactic form of a lexeme. If the mood of the form is active (and the TR_VERB node says that anything that is not passive is active), then the subcategorization frame is the same as the argument list. But if the mood of the form is passive, then the part of the subcategorization frame that deals with objects and complements is stripped of its first item i.e., its direct object. By default, this dependency of subcategorization frame on mood will be inherited by all the descendants of TR_VERB, whether these be instances of simple transitive verb lexemes or nodes defining specific types of transitive verbs (ditransitives, object-plus-infinitive verbs, bet-class verbs, etc.) and their descendants. Thus, if we assume, for example, that the lexeme Donate is an instance of DI_VERB as defined above, and that Word5 and Word6 are inflected tokens of Donate, then we will be able to derive the following theorems: subcat rest first syn cat> = pp subcat rest first syn pform> = to subcat rest rest> = nil.</Paragraph> <Paragraph position="2"> Finally, notice that the equation that specifies passive morphology appears on the PASSIVE_VERB node. This ensures that passive morphology is undefined for verbs not syntactically passive.</Paragraph> <Paragraph position="3"> The techniques used in this rather simple treatment of passive can be readily adapted for use in encoding other lexical rules and for grammatical frameworks other than that implicit in the PATRish syntax we have adopted in our example. Thus, Evans, Gazdar, and Weir (1995) formulate various lexical rules for LTAG (see note 33). These techniques can also be readily adapted for use in the semantic domain and used, for example, to implement the distinction between fixed and projective inheritance of lexical semantic information proposed by Pustejovsky (1991, 433-437).</Paragraph> <Paragraph position="4"> It is advantageous to express lexical rules in the same formal language as is used to express the lexical hierarchy, since lexical rules themselves may well exhibit exactly the kinds of defaulty relations, one to another, that lexical classes do. 36 Thus a lexical rule for direct Wh-questions may be a variant of that for indirect Wh-questions: similar, sharing components, but not identical. With a suitable degree of abstraction, achieved by parameterization of the components, lexical rules can be reified in a language like DATR, allowing one to inherit from another.</Paragraph> </Section> <Section position="10" start_page="192" end_page="197" type="sub_section"> <SectionTitle> 4.6 Representing Ambiguity and Alternation </SectionTitle> <Paragraph position="0"> DATR is a language that allows the lexicon writer to define sets of partial functions from sequences of atoms to sequences of atoms. That is actually all that it allows the lexicon writer to do. Because DATR deals in functions, it does not embody any notion of disjunction or any possibility of multiple values being associated with a single node/path pair. It might seem, at first glance, that such a language would be quite inappropriate to a domain such as the lexicon, where ambiguities are common.</Paragraph> <Paragraph position="1"> In practice, however, this turns out not to be the case. Consider the homonymy of bank:</Paragraph> <Paragraph position="3"> This is simply the traditional analysis of homonymy, encoded in DATR: there are two entirely distinct lexemes, with unrelated meanings, that happen both to be nouns and to have indistinguishable mort~hological roots.</Paragraph> <Paragraph position="4"> Or consider the polysemy of cherry: 37 36 Cf. Krieger (1994, 279) who notes some other advantages. 37 The example is due to Kilgarriff (1995) who shows that the kind of polysemy exhibited by cherry applies generally to fruit trees and can thus be specified at a higher node in the lexical network, removing the need for stipulation (as in our example) at the Cherry node, the Apple node, and so on. Kilgarriff and Gazdar (1995) also present an extended example showing how DATR can be used to Again, this is a rather traditional analysis. There are (at least) three distinct but related senses. 38 They are not freely interchangeable alternative values for a single attribute or path. Instead, DATR allows their relatedness of meaning to be captured by using the definition of one in the definition of another.</Paragraph> <Paragraph position="5"> A very few words in English have alternative morphological forms for the same syntactic specification. An example noted by Fraser and Hudson (1990, 62) is the plural of hoof which, for many English speakers, can appear as both hoofs and hooves. 39 DATR does not permit a theorem set such as the following to be derived from a consistent Of course, as far as DATR is concerned { hoof s , hooves } is just a sequence encode the regular and subregular polysemy associated with the crop, fiber, yarn, fabric, and garment senses of words like cotton and silk. See also Copestake and Briscoe (1995) for related work on regular and subregular polyserny.</Paragraph> <Paragraph position="6"> 38 For perspicuity, we provide these in DATR-augmented English here. But in a serious treatment they could just as well be given in a DATR-encoding of the lambda calculus, as used in Cahill and Evans (1990), for example.</Paragraph> <Paragraph position="7"> 39 See also the dreamt~dreamed verb class discussed by Russell et al. (1992, 330-331).</Paragraph> <Paragraph position="8"> Computational Linguistics Volume 22, Number 2 of seven atoms. It is up to some component external to DATR that makes use of such complex values to interpret it as a two-member set of alternative forms. Likewise, if we have some good reason for wanting to put together the various senses of cherry into a value returned by a single path, then we can write something like this: Cherry: <sem glosses> == { <sem gloss i> , <sem gloss 2> , <sem gloss 3> }.</Paragraph> <Paragraph position="9"> which will then provide this theorem: Cherry: <sem glosses> = { sweet red berry with pip , tree bearing sweet red berry with pip , wood from tree bearing sweet red berry with pip }.</Paragraph> <Paragraph position="10"> Also relevant here are the various techniques for reducing lexical disjunction discussed in Pulman (forthcoming).</Paragraph> </Section> <Section position="11" start_page="197" end_page="198" type="sub_section"> <SectionTitle> 4.7 Encoding DAGs </SectionTitle> <Paragraph position="0"> As a feature-based formalism with a syntax modeled on PATR, it would be reasonable to expect that DATR can be used to describe directed acyclic graphs (DAGs) in a PATR-like fashion. Consider an example such as the following: DAGI: <vp agr> == <v agr> <v agr per> == 3 <vp agr gen> == masc.</Paragraph> <Paragraph position="1"> This looks like simple re-entrancy, from which we would expect to be able to infer: DAGI: <vp agr per> = 3.</Paragraph> <Paragraph position="2"> And, indeed, this turns out to be valid. But matters are not as simple as the example makes them appear: if DAG1 was really the DAG it purports to be, then we would also expect to be able to infer: DAGI: <v agr gen> = masc.</Paragraph> <Paragraph position="3"> This, however, is not valid; in fact, <v agr gen> is undefined. It might be tempting to conclude from this that the equality operator in DATR is very different from the corresponding operator in PATR, but this would be to misunderstand what has happened in this example. In fact, the semantics of the statement</Paragraph> <Paragraph position="5"> taken in isolation is very similar to the semantics of the corresponding PATR statement: both assert equality of values associated with the two paths. The DATR statement is</Paragraph> </Section> <Section position="12" start_page="198" end_page="200" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation </SectionTitle> <Paragraph position="0"> slightly weaker in that it allows the left-hand side to be defined when the right-hand side is undefined, but, even in DATR, if both sides are defined they must be the same, so in principle, the value of the left-hand side does semantically constrain the value of the right-hand side. However, in a DATR description, specifying explicit values for extensions of the left-hand side of such an equality constraint overrides its effect, and thus does not influence the values on its right-hand side.</Paragraph> <Paragraph position="1"> Another difference lies in the fact that DATR subpaths and superpaths can have values of their own: DAG2: <v agr> == sing <v agr per> == 3.</Paragraph> <Paragraph position="2"> From this little description we can derive the following statements, inter alia:</Paragraph> <Paragraph position="4"> From the perspective of a standard untyped DAG-encoding language like PATR, this is strange. In PATR, if <v agr per> has value 3, then neither <v agr> nor <v agr per num> can have (atomic) values.</Paragraph> <Paragraph position="5"> As these examples clearly show, DATR descriptions do not map trivially into (sets of) standard DAGs (although neither are they entirely dissimilar); but that does not mean that DATR descriptions cannot describe standard DAGs. Indeed, there are a variety of ways in which this can be done. An especially simple approach is possible when the DAGs one is interested in are all built out of a set of paths whose identity is known in advance (Kilbury, Naerger, and Renz 1991). In this case, we can use DATR paths as DAG paths, more or less directly: <referent referent referent> = < NP referent >.</Paragraph> <Paragraph position="6"> But these nonsensical theorems will be of no concern to a DATR-invoking NLP system that is able to specify in advance which paths are of interest for DAG-construction and to ignore all the rest. 4deg A more sophisticated approach uses DATR itself to construct a DAG description (in the notation of your choice) as a value: 41</Paragraph> <Paragraph position="8"> The sequence of atoms on the right-hand side of this equation is just a sequence of atoms as far as DATR is concerned. But a grammar or a parser that expects to see DAGs represented as they are here can interpret the DATR values as easily as it can the contents of a file. 42 40 In this connection, see the discussion of &quot;closure definitions&quot; in Andry et al. (1992, 259-261). 41 This approach is due to recent unpublished work by Jim Kilbury. He has shown that the same DATR theorems can have their values realized as conventional attribute-value matrix representations, Prolog terms, or expressions of a feature logic, simply by changing the fine detail of the transducer employed. 42 Indeed, it will be interpreting the contents of a file if DATR has been used to define a lexicon that has subsequently been compiled out, rather than being accessed directly by components of the NLP system (see Section 5.3, below). We are not, of course, claiming that textual representations will standardly provide the optimal interface between an implementation of DATR and the larger NLP system in which it is embedded (cf., e.g., Duda and Gebhardi 1994).</Paragraph> </Section> <Section position="13" start_page="200" end_page="200" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation </SectionTitle> <Paragraph position="0"/> </Section> </Section> <Section position="9" start_page="200" end_page="205" type="metho"> <SectionTitle> 5. Technical Issues </SectionTitle> <Paragraph position="0"> In this section we briefly discuss a number of technical issues, relating both to DATR as a formal language, and also to practical aspects of DATR in use.</Paragraph> <Section position="1" start_page="200" end_page="201" type="sub_section"> <SectionTitle> 5.1 Functionality </SectionTitle> <Paragraph position="0"> Most DATR descriptions consist only of definitional statements, and include at most one statement for each node/path pair. In this section we examine the significance of this observation from a formal perspective. As noted in Section 2, DATR nodes can be thought of semantically as denoting partial functions from paths (sequences of atoms) to values (sequences of atoms). 43 Generalizing this view in the obvious way, whole DATR descriptions can be thought of as denoting functions from nodes to (partial) functions from paths to values. This semantic notion induces a notion of consistency for DATR descriptions: we say that a DATR description is consistent if and only if it has a coherent interpretation as a function; that is, if the extensional sentences defined (explicitly or implicitly) for each node constitute a (partial) function from paths to values.</Paragraph> <Paragraph position="1"> The syntax of DATR does not itself prevent one from writing down inconsistent descriptions: VERB: <syn cat> == verb <syn cat> == noun.</Paragraph> <Paragraph position="2"> However, such descriptions are of no utility and it would be desirable to find a mechanical way of eliminating them. In pursuit of this, we can define a syntactic notion of functionality over DATR descriptions as follows: A DATR description is functional if and only if (i) it contains only definitional statements and (ii) those statements constitute a (partial) function from node/path pairs to descriptor sequences.</Paragraph> <Paragraph position="3"> The significance of this syntactic notion arises from the following property: 44 Every functional DATR description is consistent.</Paragraph> <Paragraph position="4"> To understand why this is, note first that the default extension process preserves functionality, since it only adds definitional statements about new node/path pairs not already present in the original description. Local inheritance derives new statements associated with a node/path pair, but at most one of these defines a value or global inheritance descriptor (since local inheritance ceases at that point). Thus although the local inheritance makes the description become syntactically nonfunctional, the specification of values or global descriptors remains functional. The value specifications map directly to extensional statements, while the global inheritance descriptors operate just as the local ones, adding at most one further value statement for each global 43 We continue to oversimplify matters here. As Keller (1995) points out, the meaning of a node depends on the global context, and a node thus really denotes a function from global contexts to partial functions from paths to values. Though important, this point is tangential to the issue addressed here. 44 For simplicity here, we consider only the case of descriptor sequences of length one--the general case involves complications not relevant to the main point.</Paragraph> <Paragraph position="5"> Computational Linguistics Volume 22, Number 2 inheritance statement, so that ultimately the consistency of the set of (extensional) value statements is assured.</Paragraph> <Paragraph position="6"> This theorem cannot be strengthened to a biconditional, however, since consistent but nonfunctional DATR descriptions exist, as in the following examples: In NONFUNC1, UNDEF is a node with no associated definitions, so the first statement imposes no constraint on the value of <a>; in NONFUNC2, two definitions for <a> are provided, which happen to define the same value; in NONFUNC3, we establish a mutual dependence between <a> and <b>, and then define a value for one (either) of them. However, we have not encountered any examples of nonfunctional but consistent descriptions that are not better expressed by a straightforward functional counterpart. 4s Indeed, we suspect (but have no proof) that every consistent DATR description is extensionally equivalent to (that is, defines the same extensional sentences as) a functional one.</Paragraph> <Paragraph position="7"> In the light of these considerations, we assume here, and elsewhere, that functionality is a reasonable restriction to place on DATR descriptions. 46 The advantage of this is that to check the functionality of a DATR description, and hence guarantee its consistency, is completely trivial. In other words, we can substitute a straightforward syntactic constraint on descriptions for the less tractable notion of semantic consistency, apparently without significant loss of expressive power. Among other things, this means that implementations of DATR can either treat apparent violations of functionality as syntactic errors and require the user to eliminate them, or (more commonly in existing implementations) treat them as intentional corrections and silently erase earlier statements for the node and path for which a violation has been detected.</Paragraph> </Section> <Section position="2" start_page="201" end_page="202" type="sub_section"> <SectionTitle> 5.2 Multiple Inheritance </SectionTitle> <Paragraph position="0"> Multiple inheritance, in inheritance network terminology, describes any situation where a node in an inheritance network inherits information from more than one other node in the network. Wherever this phenomenon occurs there is the potential for conflicting inheritance, i.e., when the information inherited from one node is inconsistent with that inherited from another. Because of this, the handling of multiple 45 NONFUNC3 perhaps comes closest, but adding statements about extensions of either <a> or <b> quickly breaks the illusion that the two are in some sense &quot;unified.&quot; 46 This only applies to original source descriptions: as we mentioned above, the formal inference mechanisms that implement inheritance necessarily add statements to make a description nonfunctional, but since these can always be automatically determined, they need never appear explicitly in source descriptions.</Paragraph> </Section> <Section position="3" start_page="202" end_page="203" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation </SectionTitle> <Paragraph position="0"> inheritance is an issue central to the design of any formalism for representing inheritance networks.</Paragraph> <Paragraph position="1"> For the formalism to be coherent, it must provide a way of avoiding or resolving any conflict that might arise. This might be by banning multiple inheritance altogether, restricting it so that conflicts are avoided, providing some mechanism for conflict resolution as part of the formalism itself, or providing the user of the formalism with the means to specify how the conflict should be resolved. Putting aside considerations of functionality for the moment, we see that, in DATR, both the second and third of these options are employed. The &quot;longest-defined-subpath-wins&quot; principle amounts to conflict resolution built into the formalism; however, it does not deal with every case. Definitions such as:</Paragraph> <Paragraph position="3"> may result in unresolvable conflicts. Such conflicts could, of course, just be ruled out by appealing to their inconsistency, which, following a logical tradition, is grounds for ruling the description to be &quot;improper.&quot; Touretzky (1986, 70ff) provides a formal description of a number of properties that an inheritance network may have, and discusses their significance with respect to the problem of multiple inheritance. Tree-structured networks, as their name suggests, allow any node to inherit from at most one other node, so multiple inheritance conflicts cannot arise. Orthogonal networks allow a node to inherit from more than one other node, but the properties it inherits from each must be disjoint, so that again, no conflict can possibly arise.</Paragraph> <Paragraph position="4"> The basic descriptive features of DATR allow the specification of simple orthogonal networks similar to Touretzky's. For example, if we write: then we are specifying a network of three nodes (A B, and C), and two &quot;predicates&quot; (Boolean-valued attributes coded as DATR paths <a> and <b>), with C inheriting a value for <a> from A, and for <b> from B. The network is orthogonal, since <a> and <b> represent distinct (sets of) predicates.</Paragraph> <Paragraph position="5"> Orthogonal multiple inheritance (OMI) is a desirable property of lexical representation systems. Consider an analysis in which we put the common properties of verbs at a VERB node and the (disjoint) common properties of words that take noun phrase complements at an NP_ARG node. A transitive verb (TR_VERB) is both a verb and a word that takes an NP complement, thus it should inherit from both VERB and NP_ARG in this analysis. In DATR, this might be expressed as follows: VERB: <cat> == verb.</Paragraph> <Paragraph position="6"> NP_ARG:</Paragraph> </Section> <Section position="4" start_page="203" end_page="205" type="sub_section"> <SectionTitle> Evans and Gazdar Lexical Knowledge Representation Theory Query Value </SectionTitle> <Paragraph position="0"> Conventional inference given given unknown Reverse query given unknown given Theory induction unknown given given Table 2 Possible inference tasks (adapted from Barg 1994). facts that provided our running example in Section 2, above. The conventional inference task presupposes that we have a description (such as that given in that section) and a query (such as Love: <mor past participle>): the task is to infer the appropriate value for this query, namely love ed. This task is crucial to lexicon development and maintenance, since it provides lexicon developers with the means to check the empirical adequacy of their analyses. It is also a task that is likely to figure in the on-line use of the lexicon in a language-processing system, once the relevant lexical entry (i.e., the relevant DATR node) has been determined, to recover information associated with the entry, and it is the task that does the compilation in systems that use a partially or fully compiled-out off-line lexicon (as in Andry et al. 1992). The reverse query task again presupposes that we have a description available to us, but instead of starting with a known query, we start instead with a known value love ed, say, and the task is to infer what queries would lead to that value (Love: <mor past participle>, Love: <mor past tense sing one>, etc.). 47 The ability to perform this kind of inference may also be useful in lexicon development and maintenance. However, its most obvious application is to &quot;bootstrap&quot; lexical access in language-processing systems that make direct use of an on-line lexicon: given a surface form (in analysis) or a semantic form (in generation), we need to identify a lexical entry associated with that form by reverse query, and then access other lexical information associated with the entry by conventional inference. Langer (1994) gives an inference algorithm, based on the familiar chart data structure, for reverse querying DATR lexicons; and Gibbon (1993) describes PSDQ\[ (Extended DATR Query Language) which permits quantification into components of multisentence DATR queries.</Paragraph> <Paragraph position="1"> The final task is that of theory induction. Here one starts with a set of known query-value pairs (Love: <mor past participle> = love ed., Love: <mor pres tense sing three> = love s., etc.) and the task is to induce a description that has those pairs as theorems under the application of conventional inference. In a world in which all the relevant data was already clearly set out in descriptive linguistic work, an algorithm that efficiently achieved this kind of induction would be the philosopher's stone to the construction of computational lexicons. In the real world, such an algorithm would still be useful for domains like morphology (where the quality and clarity of extant descriptive linguistic work is very high), for bootstrapping lexical descriptions for subsequent manual development by humans, for updating lexicons in the light of newly encountered lexical information, and for converting one kind of lexicon into a completely different kind of lexicon by inducing the latter from the output of the former. The automatic induction of (symbolic) lexicons from data is a very new research area in computational linguistics: Kilbury (1993), Kilbury, Naerger, and Renz (1994), Light (1994), and Light, Reinhard, and Boyle-Hinrichs (1993) have proposed a variety of incremental algorithms that take a partial lexical hierarchy and 47 An alternative formulation is to start with a known value and path, and the task is to infer the appropriate nodes.</Paragraph> <Paragraph position="2"> Computational Linguistics Volume 22, Number 2 elaborate it as necessary in the light of successively presented data sets, while Barg (1994) has presented a non-incremental algorithm that induces full DATR hierarchies from suitable data sets.</Paragraph> <Paragraph position="3"> Since DATR is no more than a language, it does not itself dictate how a DATR lexicon is to be used. As it turns out, different researchers have used it very differently. Andry et al. (1992), in the context of a speech recognition task involving the parsing of &quot;extremely large lattices of lexical hypotheses&quot; (p. 248), opted for off-line compilation of their 2,000 word DATR lexicons into pairs of on-line lexicons, one of which was encoded with bit-vectors for speed and compactness. At the other extreme, Duda and Gebhardi (1994) present an interface between a PATR-based parser and a DATR lexicon where the former is dynamically linked to the latter and able to query it freely, in both conventional and reverse modes, without restriction. Gibbon (1993) presents an implementation of a very flexible query language, EDQL, which allows quantification over any constituents of (possibly complex) DATR queries.</Paragraph> </Section> <Section position="5" start_page="205" end_page="205" type="sub_section"> <SectionTitle> 5.4 Implementations </SectionTitle> <Paragraph position="0"> As already noted, the inferential core of DATR is extremely simple to implement. We know of the existence of approximately a dozen different implementations of the language but there may well be others that we do not know of. The best known, and most widely available are our own (Brighton/Sussex), which is written in Prolog and runs on most Unix platforms, Gibbon's (Bielefeld) DDATR Scheme and NODE Sicstus Prolog implementations, and Kilbury's (Duesseldorf) QDATR Prolog implementation, which runs (in compiled form) on PCs and on Sicstus Prolog under Unix. All of these are freely available on request, as is an extensive archive of over one hundred example fragments, some of which illustrate formal techniques and others of which are applications of DATR to the lexical phonology, morphology, syntax, or semantics of a wide variety of different languages. 48 Other interesting implementations that we are familiar with include the experimental reverse query implementation by Langer (Osnabrueck), Duda and Gebhardi's (Berlin) implementation that is dynamically linked to PATR, and Barg's (Duesseldorf) implementation of a system that induces DATR descriptions from extensional data sets.</Paragraph> </Section> </Section> class="xml-element"></Paper>