The Layered Domain Class system (LDC) seeks to allow users of a natural language system to customize a processor to work with types of data unknown to the initial system designers (Ballard, Lusth and Tinkham 1984a, 1984b). A secondary but also important fea­ture of LDC is its ability to work with loosely-structured input files, as opposed to more formal structures required by conventional database manage­ment systems and assumed by typical NL front-ends. Besides the obvious technological advantage of a user-customizable system, in terms of time and cost needed to acquire a specialized processor, efforts at providing transportable systems have scientific value in that they disallow ad hoc solutions to seemingly domain-specific problems in favor or methods based upon an under­standing of the relation between the conceptual struc­ture of a domain and the mechanisms needed to proc­ess the language used in discussing it.

To render the customization problem tractable, LDC restricts itself to "layered" domains (Ballard 1982), which emphasize containment relationships among domain objects and thus generalize upon the domains of LDC and VIPS. The initial interaction between a user and LDC, which involves telling the system about a new domain, consists of a knowledge-acquisition session with the preprocessor, which we call "Prep". In particular, Prep asks for

(1) the names of each type of "entity" (object) of the domain; (2) the nature of the relationships among entities;

(3) the English words that will be used as nouns, verbs, and modifiers; and

(4) morphological and semantic properties of these new words.

Having completed a session with the user, Prep digests its newly acquired information to produce files that will be used during subsequent processing of English inputs.

Among the primary tasks to be undertaken in the foreseeable future are

(a) implementation of certain exotic and anaphoric modifier types, as described in Ballard 1984;

(b) user testing of the existing system, both in cus­tomization and in user mode;

(c) provisions for limited use of coordinate conjunc­tion;

(d) introduction of a generic hierarchy (taxonomy) so that, for example, a "large office" can be as­sumed to be a large room that is also an office, unless special provisions have been made to the effect that "large" applies differently to offices than to other types of rooms; and

(e) incorporation of the voice recognition capabilities developed for VNLC and VIPS.

Dialogues of the type that occur when one calls a trav­el agent, gives a weather report, or instructs a secre­tary in a routine task often manifest a repetitive or stereotypic structure, especially when the utterances of a single speaker are being considered. We call the set of all dialogues that may occur in a given environment a "dialogue type". While individual dialogues within a dialogue type may differ in content and style, they often have rather noticeable resemblances. For in­stance, reasonably stereotyped utterances may open a dialogue, convey significant facts, move from one sub­ject to another, and close the interaction. The exact wording and ordering of sentences may change from one dialogue to another, but often enough a basic pattern can be identified and used to create an "expectation" as to which of several possible continu­ations (e.g. at some point in a sentence or dialogue) are most likely for the current user.

With these thoughts in mind, we have attempted to utilize such information to enable error correction in the context of on-line voice-interactive natural lan­guage processors of the type discussed above. In par­ticular, we have devised methods that monitor incom­ing inputs to a voice-interactive natural language sys­tem and build up a graphical structure to capture the relevant portions of a dialogue type. This frame-like structure is then used as a predictor when a suspected voice recognition error has occurred. Experience indi­cates that speakers can in fact speak more rapidly (and less carefully) and still obtain acceptable recognition rates. Thoughts are being given to more liberal ways of utilizing the expectations built up during sessions with a user.

Seeking to take advantage of the benefits of both the familiar ATN formalism of Woods and the augmented phrase-structured grammars of Heidorn, we have de­veloped a hybrid grammatical formalism based on aug­mented phrase-structure rules that allows a simple but general parser to make its domain-specific decisions by reference to auxiliary files produced during a learning session of the sort carried out during the knowledge acquisition phase of LDC. Our grammatical formalism (Ballard and Tinkham 1984) is built around seven command types. Three of these are used to specify words, parts of speech, and syntactic categories, while the remaining four provide control facilities for option-ality, possible repetition, alternation, and sequence. In addition to the main function of each of the com­mands, through which the grammar writer can specify any context-free grammar, most commands allow for various forms of augmentations, useful in specifying the constraints needed for the parser to perform useful disambiguations. We are currently engaged in a rede­sign of our parser to be run on a Symbolics 3670.

In the context of our work on the LDC system de­scribed above, we have abandoned the common prac­tice of building a front end to an pre-existing retrieval system (e.g. DBMS). Instead, we have sought to de­velop methods whereby the sophisticated processing required by English inputs can be handled directly by a retrieval component. Roughly speaking, this allows an English processing component to concentrate upon syntactic matters, and relegate matters of semantic processing to the database retrieval component, where ideally they belong.

To accomplish this, we have designed a powerful but simple query language called DOMINO (Lusth and Ballard 1984), some of whose novel features are

(1) facilities to access text-edited files, as opposed to more restrictive database structures,

(2) several high-powered operators to loop through selected portions of the data file, with arbitrary levels of nesting permitted, and

(3) capabilities for "macro" specifications by users, wherein arbitrarily complex operations can be entered once, either before or during a session, and subsequently accessed in a single step, at any meaningful place within a query, just as though they had been supplied by the initial retrieval processor.

Current work with DOMINO involves the addition of further and still more powerful built-in looping capa­bilities, anaphoric macro calls, and a possible redesign for the Symbolics environment.