TRALE-EXTENSION:Introduction

TRALE-EXTENSION:Background

In the framework of Head-Driven Phrase Structure Grammar (HPSG, Pollard and Sag, 1994) and other current linguistic architectures, linguistic generalizations are often conceptualized at the lexical level. Among the mechanisms for expressing such generalizations, so-called lexical rules are used for expressing so-called horizontal generalizations (cf. Meurers, 2001, and references cited therein).

Generally speaking, horizontal generalizations relate one word-class (e.g., passive verbs) to a second one (e.g., their active counterpart). A lexical rule specifies that for every word matching the description on the left-hand side of the rule (the input) there must also be a word matching the description on the right-hand side of the rule (the output). Lexical rules in HPSG are generally interpreted based on the understanding that properties not specified in the output description are assumed to be identical to the input of a lexical rule, which is sometimes referred to as framing. Lexical rules can be thought of in a static sense, as capturing generalizations about the lexicon, or in a dynamic sense, as licensing derived lexical entries.

The lexical rule compiler implemented for the TRALE system encodes the treatment of lexical rules proposed in Meurers and Minnen (1997). The underlying idea of the approach is to make computational use of the generalizations encoded in lexical rules, instead of expanding out the lexicon at compile time, as in the common approach also available in the TRALE system. The lexical rule compiler of Meurers and Minnen (1997) takes a basic lexicon and a set of lexical rules to produce a set of lexical entries which is modified to license not only the base lexical entries, but also all possible derivations. The lexical rule compiler approach thus has two advantages over an approach that complies out the lexicon: the resulting lexicon is much smaller, and it allows for lexical rules that apply recursively, and thus can result in infinitely large lexicons.

TRALE-EXTENSION:The lexical rule compiler

The lexical rule compiler consists of the four steps shown in figure 8.1.

Figure 8.1: Overview of the lexical rule complier

A full discussion of this setup is provided in Meurers and Minnen (1997); we provide a brief summary of the overall approach here, to be followed by a discussion of our implementation of each step in the following sections.

In the first step we translate user-specified lexical rules to an internal Prolog representation. We generate the so-called frame predicates for each lexical rule, which transfer all information from the input to the output which is not specified in the output description. The internal Prolog representations are specified to call the frame predicates. In the second step, we develop a global interaction finite state automaton (global finite-state automaton), based on a follows relation, which is itself obtained from testing which lexical rule inputs can unify with which lexical rule outputs. We then perform the step of actually unifying the feature structures along all paths, propagating the specifications, which may allow the pruning of some arcs already during compile time instead of at runtime. This global finite-state automaton encodes all possible sequences of lexical rule application from a base lexical entry, on the basis of information in the lexical rules alone. In the third step, we take each lexical entry and run it through the global finite-state automaton, applying the lexical rules to the base or derived lexical entry (as the case may be) pruning those arcs where unification fails. In this way we end up with a finite-state automaton for each lexical entry. In the fourth step, we produce interaction predicates based on the automata and modify the lexical entries to call the appropriate interaction predicate, effectively grouping the lexical entries into lexical classes. That is, since each finite-state automaton is simply a pruned version of the original global finite-state automaton, we can easily check to see if an identical finite-state automaton has already been translated to an interaction predicate. If so, we forgo translating the current finite-state automaton, calling the previously asserted interaction predicate in the current lexical entry instead.

The lexical entries that ultimately result from this process are encodings of base lexical entries which also call the finite state automaton for their word class. This finite-state automaton encodes each possible sequence of lexical rule application as a path through the automaton, where the traversal of an arc results in the application of some lexical rule, the arcs leaving a particular state represent all possible lexical rule applications at that point, and every state is a final state. The start state corresponds to the base lexical entry, and every other state corresponds to some derived lexical entry, which is the output of some lexical rule, and may (possibly) serve as input to others. Thus, the lexical entry, as a whole, licenses any word object whose feature specifications unify with those at some point along a path in the finite-state automaton.

While we do provide general descriptions of the current state of implementation, the primary focus of this reference manual is lexical rule interpretation and the generation of frame predicates.

Before we begin discussion of frame generation, we define the terms feature description and feature structure. By feature description we refer to compound terms in ordinary TRALE syntax. Such terms are specified by the user, and may be partial representations with respect to type values and appropriate features. By feature structure, we refer to TRALE's internal representation, in which all type values and appropriate feature values are represented. A variety of built-in TRALE predicates can be called to obtain information about, or add information to, a feature description.