previous up contents next
Left: Representing lists Up: DATR techniques Right: Multiple inheritance

Lexical rules

  A lexical representation language needs to be able to express the relations that are now widely thought to be in the domain of lexical rules. Canonically, such rules deal with the phenomena that used to be described by the ``cyclic rules'' of late 1960s transformational grammar. Characteristically, they pertain to rather specific classes of lexical items (e.g., transitive verbs, or tensed auxiliary verbs) and they are subject to exceptions of various kinds. Radically lexicalist frameworks, which lack any construction-specific grammatical rules outside the lexicon, do not restrict the use of lexical rules to ``cyclic'' phenomena. Thus, for example, Evans et al. (1995) report the use of DATR to formulate a lexical rule for wh-questions in LTAG , inter alia.. It is these characteristics that have led many linguists to consign them to the lexicon. They usually involve a difference in argument structure and this is sometimes accompanied by a morphological difference. The combination of evaluable paths with a standard encoding of argument lists make it rather easy to define lexical rules in DATR. Evaluable paths are not essential in this domain: thus Kilgarriff (1993) does not employ them in his DATR analysis of verbal alternations in the context of an HPSG lexicon, although he does use the standard encoding of argument lists.

Here, by way of illustration, is a partial analysis of verbs that implements a lexical rule for syntax of the (agentless) passive construction. Since our purpose here is expository, we have deliberately kept the analysis to minimum. Dealing with the semantics of passive, for example, involves more of the same rather than any issue of principle.

    VERB:
        <mor past> == "<mor root>" ed
        <mor form> == "<mor "<syn form>">"
        <syn cat> == verb
        <syn subcat> == "<syn args>"
        <syn args> == NP_ARG:<>
        <syn args first syn case> == nominative.
    PASSIVE_VERB:
        <> == VERB
        <mor passive> == "<mor past>"
        <syn subcat rest> == "<syn args rest rest>".
    TR_VERB:
        <syn args rest> == NP_ARG:<>
        <> == <<mood "<syn form>">>
        <mood> == active
        <mood passive> == passive
        <active> == VERB:<>
        <passive> == PASSIVE_VERB:<>.
This example introduces several new techniques. Firstly, in TR_VERB we have a double parametrisation 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 subcategorisation 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 subcategorisation frame is the same as the argument list. But if the mood of the form is passive, then the part of the subcategorisation frame that deals with objects and complements is stripped of its first item - i.e., its direct object. By default, this dependency of subcategorisation 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:
    Word5:
        <mor form> = donate ed
        <syn form> = past tense
        <syn subcat first syn cat> = np
        <syn subcat first syn case> = nominative
        <syn subcat rest first syn cat> = np
        <syn subcat rest first syn case> = accusative
        <syn subcat rest rest first syn cat> = pp
        <syn subcat rest rest first syn pform> = to
        <syn subcat rest rest rest> = nil.
    Word6:
        <mor form> = donate ed
        <syn form> = passive participle
        <syn subcat first syn cat> = np
        <syn subcat first syn case> = nominative
        <syn subcat rest first syn cat> = pp
        <syn subcat rest first syn pform> = to
        <syn subcat rest rest> = nil.
Finally, notice that the equation that specifies passive morphology appears on the PASSIVE_VERB node. This ensures that passive morphology is undefined for verbs which are not syntactically passive.

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 (Shieber 1986) we have adopted in our example. Thus, as noted above, Evans et al. (1995) formulate various lexical rules for LTAG . They 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).

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. 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 parameterisation of the components, lexical rules can be reified in a language like DATR, allowing one to inherit from another.

---------------------------------------------------------

previous up contents next
Left: Representing lists Up: DATR techniques Right: Multiple inheritance
Copyright © Roger Evans, Gerald Gazdar & Bill Keller, Tuesday 10 November 1998