LDC-1

Abstract

During the 1970s, a number of systems providing limited English-language processing capabilities were developed to permit computer access by casual or untrained users. Our interest is in adapting and extending techniques developed for these systems, especially those used in database query systems and our own English-language programming language system (NLC), for use in office environments. This paper describes the Layered Domain Class system (LDC), a state-of-the-art natural language processor whose major goals are (1) to provide English-language retrieval capabilities for mediumsized office domains that have been stored on the computer as text-edited files, as opposed to more restrictive database structures; and (2) to eliminate the need to call in the system designer when extensions into new domains are desired, without sacrificing the depth or reliability of the interface. In this paper we (a) provide an overview of LDC, including sample inputs; (b) briefly discuss the role of each module of the system, with special attention to provisions for users to adapt the system to deal with new types of data; and (c) consider the relation of our system to other formal and natural language interfaces that are in use or under development.

User Models in Dialog Systems

“…[HOEP83b]), TEAM (cf. [MARP83]) and LDC [BALL84] are examples of transportable systems that can be adapted to different domains by the experts in these fields (rather than by AI or linguistics specialists).…”

Problems and some solutions in customization of natural language database front ends

“…One possible way to do algorithmic association is by computing a descriptor for each input token and storing the dictionary information with the descriptor. The notion of using shape or format to associate an input token with the database column to which it belongs has also been used by Ballard et al [2]. The implementation used for the TQA system is, however, somewhat different.…”

“…Consider a database with one table, a phone book with some additional information, shown in Figure 5. In [2] the user doing the customization is asked to supply representative examples of column contents. By contrast, the TQA customization program reads the data in nonnumeric columns, computing a shape descriptor for each entry encountered and entering it into a table (see Figure 6).…”

“…The preprocessor performs input tokenization and dictionary lookup. The parser is separable into four phases: (1) application of a set of string transformations for local rearrangement [15], (2) context-free parsing to produce surface structures, (3) application of the main transformational component to produce canonical underlying forms, and (4) application of database-oriented transformations to produce structures that reflect the content of the database (see Figure 4). The interpreter transforms the canonical sentence representation produced by the grammar first into an expression in the domain relational calculus [6] and then into an SQL expression.…”

KID Designing a Knowledge-Based Natural Language Interface

“…Although you will find the word "user" throughout this article, sophisticated users more closely resemble Ballard's "superuser." 6 Communications between natural language interface systems and users require a model for mutual comprehension, just as dialogues between human beings do. To mediate effectively between users and systems, a domain model must be represented in terms natural to concepts users would employ when thinking about a domain of discourse instead of semantically poor database schemata.…”