File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/86/p86-1005_metho.xml
Size: 32,924 bytes
Last Modified: 2025-10-06 14:11:53
<?xml version="1.0" standalone="yes"?> <Paper uid="P86-1005"> <Title>Semantic Acquisition In TELI: A Transportable, User-Customized Natural Language Processor</Title> <Section position="3" start_page="20" end_page="21" type="metho"> <SectionTitle> 3. Principles Behind Semantic Acquisition </SectionTitle> <Paragraph position="0"> As noted above, our goal is to devise techniques that enable end users of a natural language processor to furnish all domain-specific information to by the system. This information includes (1) the vocabulary needed for the data at hand; (2) various types of selectional restrictions that define acceptable phrase attachments; and most critically (3) the definitions of words and phrases. With this in mind, the primary criteria which the semantic acquisition component of TELI has been designed around are as follows.</Paragraph> <Paragraph position="1"> To allow users to define, examine or modify domain-specific il(ormation at any time. This derives from our beliefs that the needs of a user or group of users cannot all be predicted in advance, and will probably change once the system has begun operation.</Paragraph> <Paragraph position="2"> To enable users to impart new concepts to the system.</Paragraph> <Paragraph position="3"> We provide more than just synonym and paraphrase capabilities and, in fact. definitions may be arbitrarily complex, by being defined either (a) in terms of other definitions, which may be defined upon other definitions, or (b) as the conjuction of an arbitrary number of constraints.</Paragraph> <Paragraph position="4"> To provide definition capabilities independent of modifier type. In our system, adjectives, nouns, prepositional phrases, verb phrases, and so forth are all defined in precisely the same way. This is achieved in part by treating all modifiers as n-place predicates. To allow definitions to be given at various conceptual levels. Users are able to specify meanings (a) in English; (b) in terms of the meanings of previously defined words or phrases; (c) by reference to &quot;conceptual&quot; relationships, which have been abstracted to a level above that of the physical data files; or (d) in terms of database columns. We strive to minimize the need for low-level database references, since this helps (1) to avoid tedious and redundant references, and (2) to assure that most of our techniques will be applicable beyond the current conventional database setting.</Paragraph> <Paragraph position="5"> To provide alternate modalities of specification. For example, the menu scheme described in Section 7.2 offers the user more assistance in making definitions. but is less powerful, than the alternative English and English-like methods described in Section 7.3. We prefer to let users decide when each modality is appropriate, rather than force a compromise among simplicity, reliability, and power.</Paragraph> <Paragraph position="6"> To enable the system to proride help or guidance to the customizer. When defining a modifier, users may view all current modifiers of. or functions associated with, the object type(s) in question. Many other opportunities exist for co-operation on the part of the system. To avoid unnecessary limitations, however, users are generally able to override any hints made by the system.</Paragraph> </Section> <Section position="4" start_page="21" end_page="22" type="metho"> <SectionTitle> 4. Semantic Processing in TELI </SectionTitle> <Paragraph position="0"> The semantic model developed for TELI, in which definitions are acquired from users, assumes that (1) modifier meanings will be purely extensional, and can thus be treated as n-place predicates, and (2) semantic analysis will be almost entirely compositional. Concerning the latter assumption, we note that (a) some important disambiguations, including problems of word sense, will have been made during parsing by reference to selectional restrictions (Ballard and Tinkham, 1984), and (b) minimal re-ordering does occur in converting parse trees into internal representations.</Paragraph> <Section position="1" start_page="21" end_page="21" type="sub_section"> <SectionTitle> 4.1 Types of Semantics </SectionTitle> <Paragraph position="0"> All user-defined semantics, however acquired, are stored in a global Lisp structure indexed by the word or phrase being defined. Single-word modifiers are indexed by the word being defined, its part of speech, and the entity it modifies; phrasal modifiers are indexed by the phrase type and the associated case frame. For example, the internal references (new adj room) (prep-ph (restaurant in county)) respectively index the definitions of &quot;new&quot;, when used as an adjective modifier of rooms, and &quot;in&quot;, as it relates restaurants to counties. As suggested by this indexing scheme, word meanings arise only in the context of their occurrence, never in isolation. Thus, &quot;new room&quot; and &quot;restaurant in county&quot; receive definitions, not &quot;new&quot; or &quot;in&quot;. This decision lends generality to the definitional scheme, and any additional effort thereby needed to make multiple definitions is minimized by the provisions for borrowed meanings, as described in Section 7.4.</Paragraph> <Paragraph position="1"> Although our representation strategies allow for definitions that involve relatively elaborate traversals of the physical data files. TELI does not presently provide for arithmetic computations. Thus, the input &quot;Which restaurants are within 3 blocks of China Gardens?&quot; requires a 2-place &quot;distance&quot; function and, unless the underlying data files provide distances between restaurants (there are N-squared such distances to account for). the necessary semantics cannot be supplied.</Paragraph> </Section> <Section position="2" start_page="21" end_page="22" type="sub_section"> <SectionTitle> 4.2 Internal Representations </SectionTitle> <Paragraph position="0"> As an example of the &quot;internal representation&quot; (IR) of an input, which results from a recursive traversal of a completed parse tree, and which illustrates preparations for compositional analysis, the (artificially complex) input &quot;Which Mexican restaurants in the largest city other than New Providence that are not expensive are open for lunch'?&quot; will have \[roughly\] the internal representation</Paragraph> <Paragraph position="2"> This top-level interpretation of the input instructs the system to find all restaurants that satisfy (a) the negation of the 1-place predicate associated with &quot;expensive&quot;, and (b) the three 2-place predicates associated with the noun-noun, prepositional, and adjective phrases. Note that modifiers associated with phrasal modifiers are referenced by their case frame, e.g. &quot;restaurant in city&quot;. Within the scope of these references, case labels (e.g. &quot;subj&quot; and &quot;arg&quot;) indicate which slots have been instantiated and which slot has been relativized, the latter denoted by &quot;?&quot;. The list of slot names associated with each phrase type is stored globally. In most instances, the argument of a case slot can be an arbitrary IR structure, in keeping with the recursive nature of the English inputs being recognized.</Paragraph> <Paragraph position="3"> Since IR structures are built around the word and phrase types of the English being dealt with, and since the meanings of words and phrases are stored globally, IR structures should not be regarded as a &quot;knowledge representation&quot; in the sense of KL-ONE, logical form. and so forth. Systems similar in goals to TELI but which revolve around logical form include TEAM (Grosz, 1983; Grosz, Appelt. Martin, and Pereira 1985), IRUS (Bates and Bobrow, 1983; Bates, Moser, and Stallard 1984), and TQA (Plath, 1976; Damerau, 1985). One system similar to TELI in building intermediate structures that contain references to language-specific concepts is</Paragraph> </Section> </Section> <Section position="5" start_page="22" end_page="22" type="metho"> <SectionTitle> DATALOG (Hafner and Godden. 1985). 5. The Initial Phase of Customization </SectionTitle> <Paragraph position="0"> When a user asks TEL1 to begin learning about a new domain, the system spends from five to thirty minutes, depending on the complexity of the application, obtaining basic information about each table in the the database (see Figure 2). Users are first asked to give the key column of the table. This information is used primarily to guide the system in inferring the semantics of certain noun-noun and &quot;of&quot;-based patterns. Next, users are asked which columns contain entity values as opposed to property values.</Paragraph> <Paragraph position="1"> Typical properties are &quot;size&quot;, &quot;color&quot;, and &quot;length&quot;, which differ from entities in that (a) their values do not appear as an argument to arbitrary verbs and prepositions (e.g. other than &quot;have&quot;, &quot;with&quot;, etc.) and (b) they will not themselves have properties associated with them. Finally, users are asked to specify the type of value each column contains. This information allows subsequent references to concepts (e.g. &quot;color&quot;) rather than physical column names. It also aids the system in forming subsequent suggestions to the user (e.g. defaults that can be overridden).</Paragraph> <Paragraph position="2"> Having obtained the information above, the system constructs definitions simple questions to be answered, such as indicated that allow &quot;What is Sally's social security number?&quot; &quot;What is the age of John&quot; Along with information freely volunteered by the user, these definitions can be subsequently examined or changed at the user's request.</Paragraph> <Paragraph position="3"> Based upon the ans~crs to the questions described above, a small number of follow-up questions, mostly unrelated to the subject of this paper, will be asked. For example, the system will propose its best guess as to the morphological variants of nouns, verbs, and other words for the user to confirm or correct.</Paragraph> </Section> <Section position="6" start_page="22" end_page="23" type="metho"> <SectionTitle> 6. Intermediate Customizations </SectionTitle> <Paragraph position="0"> Having learned about each physical relation.</Paragraph> <Paragraph position="1"> TELI asks for information which, though not needed immediately, is either (a) more simply obtained at the outset, in a context relevant to its semantics, than at a later, arbitrary point, or (b) acquirable collectivelv.</Paragraph> <Paragraph position="2"> thus preventing several subequent acquisitions.</Paragraph> <Paragraph position="3"> Unlike the initial acquisitions described in Section 5, intermediate customizations could be excised from the system without any loss in processing ability. We now summarize three forms of intermediate customizations, the last of which may be requested by the user at any time. Allowing users to ask for the other forms as well would be a simple matter.</Paragraph> <Paragraph position="4"> First, the system will ask which columns contain values that either correspond to or are themselves English modifiers. In Figure 2-a, the values 'T' through &quot;G&quot; in the &quot;class&quot; column might correspond (respectively) to &quot;freshman&quot; through &quot;graduate student&quot;, in which case acquisitions might continue as suggested in Figure 3. From this information, the system constructs a definition for each user-defined modifier; for example the internal definition of &quot;sophomore&quot; will be ((sophomore noun student) ((class p-noun) = 2)) A second intermediate acquisition, carried out subject to user confirmation, involves the acceptability of hypothesized syntax and semantics for (a) phrases based on &quot;of&quot;, (b) phrases built around &quot;have&quot;, &quot;with&quot;. and &quot;in&quot;, and (c) noun-noun phrases. In deciding what case frames to propose. TELI considers the information it has already acquired about simple functional (&quot;of&quot;) relationships.</Paragraph> <Paragraph position="5"> A third form of intermediate acquisition involves the system's invitation for the user to give lexical and syntactic information for one or more user-defined categories, namely titles, adjectives.</Paragraph> <Paragraph position="6"> common nouns, noun modifiers, prepositions, and verbs. For example, the user might specify six adjectives and the entities they modify, followed by four or five verbs and their associated case frames.</Paragraph> <Paragraph position="7"> and so forth.</Paragraph> </Section> <Section position="7" start_page="23" end_page="27" type="metho"> <SectionTitle> 7. On-Line Customization </SectionTitle> <Paragraph position="0"> In general, definitions are supplied to TELl whenever (a) an undefined modifier is encountered during the processing of an English input, or (b) the user asks to supply or modify a definition. In each case, the same methods are available for making definitions, and are independent of the modifier type being defined. When creating or modifying a meaning, users are presented with information as shown in Figure 4-a; upon asking to &quot;add a constraint&quot;, they are given the menu shown in Figure 4-b.</Paragraph> <Paragraph position="1"> Multiple &quot;constraints&quot; appearring in a semantic specification are presently presumed to be conjoined.</Paragraph> <Paragraph position="2"> I Nh, ich, columns contain (er, coded) Engli:mh ~,3r,ds? SIUDEMT (BILL, DOUG, ...) = \[\] SSM (iii-22-3333, 12:3-4J-6789, ...) \[\] CLASS (i, 2 .... ) \[\] RDVIS (BACHEMK0, BALLARD, ...) \[\] Abort \[\] Return \[\] l Uords associated with the CLASS value 1: fre~hmar, I Uords associated with the CLASS value G: 9raduatel As suggested in Figure 4-a and below, definitions are made in terms of sample values, which the system treats as formal parameters. In this way we avoid the problem of defining a phrase two or more of whose case slots may be filled by the same type of entity (cf. &quot;a student is a classmate of a student if ...&quot;). To assure that any domain value may appear as a constant, the user is able to alter the system's choice of sample names at any time.</Paragraph> <Section position="1" start_page="23" end_page="23" type="sub_section"> <SectionTitle> 7.1 Specification at the Database Level </SectionTitle> <Paragraph position="0"> As noted in Section 3, semantic specifications at the database level are primitive but useful. As shown in Figure 5, a database level specification comprises (a) a relation, possibly arrived at via a user-defined join, and (b) references to columns that correspond to the parameters of the phrase whose semantics is being defined. In many cases, the system can utilize its column type information, acquired as described in Section 5, to predict both the relation to be used (or pair of relations for joining) and the appropriate columns to join over, in which case the menu(s) that are presented will contain boldface selections for the user to confirm or alter.</Paragraph> </Section> <Section position="2" start_page="23" end_page="24" type="sub_section"> <SectionTitle> 7.2 Specification by Menu </SectionTitle> <Paragraph position="0"> In our previous experience with LDC, we found that a large variety of meanings could be defined by a predicate in which the result of some function is compared using some relational operator to a specified benchmark value. In TELl. we provide an enhancement to this scheme where definitions (a) may involve more than one argument. (b) may contain more than one function reference, and (c) are acquired in menu form. The current internal representation of a menu specification is a triple of the form suggested by</Paragraph> <Paragraph position="2"> An example of how menu semantics operates is given in Figure 6. When a semantics menu first appears, its &quot;Function&quot; field contains a list of all functions known to apply to at least one of the entities that the definition relates to. This reduces the number of keystrokes required from the user and. more importantly, helps guard against an inadvertent proliferation of concept names.</Paragraph> </Section> <Section position="3" start_page="24" end_page="24" type="sub_section"> <SectionTitle> 7.3 English and English-Like Specifications </SectionTitle> <Paragraph position="0"> In addition, to the database and menu schemes just described, users may supply definitions in terms of English already known to the system. Some advantages to this are that (1) definitions may be arbitrarily complex, limited only by the coverage of the underlying syntactic component, and (2) users will implicitly be learning to supply semantics at the same time they learn to use the NLP itself. Some disadvantages are (1) a user might want to define something that cannot be paraphrased within the bounds of the grammatical coverage of the system, and (2) unless optimizations are carried out, references to user-defined concepts may entail inefficient processing.</Paragraph> <Paragraph position="1"> An alternative to English specification, which functions similarly from the user's standpoint, is to provide for &quot;English-like&quot; specifications in which an expression supplied by the user is translated by some pattern-matching algorithm different from. and probably less sophisticated than. the process involved in actual English parsing. The primary advantage of English-like specification, over English specification, is that translations into internal form can be more efficient, since definitions or parts of definitions will be handled on a case by case basis. One probable disadvantage is that the scheme will be less general, in terms of definable concetps, and perhaps &quot;spotty&quot; in terms of what it makes available.</Paragraph> <Paragraph position="2"> In TELI, both English and English-like specification are done in terms of sample domain values, which are treated as formal parameters. An example appears in Figure 7. In the current implementation, English-like specifications include (a) any definition definable by menu, and (b) definitions that involve (possibly negated) adjective or noun references. As of this writing, only English specifications that involve no nested parameter references can be processed.</Paragraph> </Section> <Section position="4" start_page="24" end_page="24" type="sub_section"> <SectionTitle> 7.4 Specification by Borrowing </SectionTitle> <Paragraph position="0"> In addition to whatever mechanisms an NL system specifically provides for semantic acquisitions, it is reasonable to allow users to define one meaning directly in terms of another (in addition to indirect dependence, as in the case of English specification).</Paragraph> <Paragraph position="1"> In TELI, users may ask to &quot;borrow&quot; from an existing meaning at any time. As shown in Figure 8, the system responds by finding all current items defined in terms of all or some of the parameters (i.e. entities) of the item for which the borrowing is being done. This assures that the entire borrowed meaning can be modified to apply to the item being defined. After being copied, a borrowed meaning may be edited just as though it had been entered from scratch.</Paragraph> <Paragraph position="2"> 8. Relation to Similarly Motivated Systems At the most abstract level, our approach to transportability is unusual in that we have begun by building a moderately sophisticated NLP'which, from the outset, fundamentally includes replete customization facilities. This contrasts with other efforts which have first built, perhaps over a period of several years, a highly sophisticated system, then sought to incorporate some customization features. Our work is also distinctive, though perhaps less so. in seeking to allow for customization by end users, as opposed to (say) a database administrator (cf. Thompson and Thompson, 1975, 1983, 1985; Johnson, 1985).</Paragraph> <Paragraph position="3"> Some of the systems which, like TEL1, seek to provide for user customization within the context of database query are ASK (Thompson and Thompson 1983, 1985). formerly REL (Thompson and Thompson, 1975). from Caltech; INTELLECT, formerly Robot (Harris, 1977), marketed by Artificial Intelligence Corporation; IRUS (Bates and Bobrow, 1983; Bates.</Paragraph> <Paragraph position="4"> Moser, and Stallard 1984), from BBN Laboratories; TQA (Damerau, 1985). formerly REQUEST (Plath, 1976), from IBM Yorktown Heights; TEAM (Grosz.</Paragraph> <Paragraph position="5"> 1983; Grosz et al, 1985). from SRI International; and USL (Lehmann, 1978), from IBM Heidleberg. Other high-quality domain-independent systems include DATALOG (Hafner and Godden. 1985). from General Motors Research Labs; HAM-ANS (Wahlster. 1984), from the University of Hamburg; and PHLIQA (Bronnenberg et al, 1978-1979). from Philips Research. We now provide a comparison of TELI's customization strategies with those of the TEAM, IRUS, TQA, and ASK systems (other comparisons would also have been instructive, time and space permitting). Although we have recently spoken with at least one designer of each of these systems (see the Acknowledgements), it is possible that, in addition to intended simplifications, we may have overlooked or misunderstood certain significant, perhaps undocumented, features, in which case we apologize to the reader. Also, we note that our remarks are principally concerned with the goals and the approaches of various projects, and should not be viewed as commenting on the accomplishments or overall quality of TELl or any other system.</Paragraph> </Section> <Section position="5" start_page="24" end_page="26" type="sub_section"> <SectionTitle> 8.1 A Comparison with TEAM </SectionTitle> <Paragraph position="0"> Both TEAM and TELI represent English-language interfaces that have been applied to several moderately complex relational database domains.</Paragraph> <Paragraph position="1"> Each system provides for a variety of customizations by non-natural language experts, though neither system has claimed success with actual users in either customization or English processing mode. In terms of method, each system obtains (among other things) information about each column of each relation (table) of the database. We proceed to point out some of the more significant differences between the projects, as suggested by Grosz et al (1985) and indicated by Martin (1986).</Paragraph> <Paragraph position="2"> To begin with, TEAM incorporates a more powerful natural language processor than does TELl, with provisions for quantifiers, simple pronouns, elaborate comparative forms, limited forms of conjunction, and numerous smaller features. Its &quot;sort hierarchy&quot; provides a taxonomy more general than that of TELI. It also incorporates disambiguation heuristics which seek to obviate the need for users to provide definitions for some phrase types (e.g.</Paragraph> <Paragraph position="3"> prepositional phrases based on &quot;on&quot;, &quot;from&quot;, &quot;with&quot;, and &quot;in&quot;), and its preparations to deal with time and place references are without counterpart in TELI.</Paragraph> <Paragraph position="4"> On the other hand, the customization features of TELl appear to offer greater sophistication, and sometimes more power, than the respective customization features of TEAM. In terms of sophistication, TELI always offers multiple ways of acquiring information, provides the ability to examine and borrow existing definitions, and is able to invoke the appropriate knowledge acquisition module when missing lexical, syntactic, or semantic information is required.</Paragraph> <Paragraph position="5"> Copncerning definitional power, TELl generally provides for more complex definitions of words and phrases than does TEAM, as described in Sections 5-7. For example, whereas the SRI system typically requires a verb to map into some explicit or virtual relation (e.g. a join of explicit relations), TELl also allows an arbitrary number of properties of objects to be used in definitions (e.g. an old employee is one hired before I980. or an employee admires a manager that works more hours than she does).</Paragraph> <Paragraph position="6"> In TEAM, &quot;acquisition is centered around the relations and fields in the database&quot;. In contrast, TELI provides several customization modes, as described in Section 3, and discourages low-level database specifications.</Paragraph> <Paragraph position="7"> In contrast to the principles we espoused for TELI in Section 3, TEAM couples its methods of acquisition with the type of modifier being defined.</Paragraph> <Paragraph position="8"> For example, when seeing a &quot;feature field&quot;, which contains exactly two distinct values, the system asks for &quot;positive adjectives&quot; and &quot;negative adjectives&quot; associated with these values (e.g. &quot;volcanic&quot; is a positive adjective associated with the database value &quot;Y&quot;). In TEL1, these relationships arise as a special case of the acquisitions shown in Figures 3.6, and 7b. An interesting similarity between TEAM and TELI is that each provides for English(like) definitions. For example. TEAM might be told that &quot;a volcano erupts&quot;, from which it infers that a mountain erupts just in case it is a volcano.</Paragraph> </Section> <Section position="6" start_page="26" end_page="26" type="sub_section"> <SectionTitle> 8.2 A Comparison with IRUS </SectionTitle> <Paragraph position="0"> Another recently developed facilitiy to allow user customizations of a database front-end is represented by the IRACQ component of the IRUS system (Ayuso and Weischedel, 1986). In addition to its practical value, IRACQ is intended as a vehicle that permits experimental work with sophisticated knowledge representation formalisms.</Paragraph> <Paragraph position="1"> IRACQ is similar to TELI in shielding the user from the layout of the underlying data files. Another similarity is that each system accepts case frame specifications in English-like form. but IRACQ allows proper nouns as well as common nouns to be used.</Paragraph> <Paragraph position="2"> Thus. a user might suggest the case frame of the verb &quot;write&quot; by saying &quot;Jones wrote some articles&quot;. Since IRUS provides for quite general taxonomic relationships among defined concepts (e.g. nouns), IRACQ proceeds to ascertain which of the possibly several classes that &quot;Jones&quot; belongs to is the most general one that can act as the subject of &quot;write&quot;. One important difference between TELI and IRACQ is that IRUS distinguishes conceptual information, which resides within its KR framework, from the linguistic information that characterizes the English to be used. Thus, while IRACQ supports definitions in terms of an arbitrary number of predicates, as does TELl, it assumes that any concepts needed to define a new language item have already been specified. These representations, acquired by a separate module called KREME, involve the KL-ONE notions of &quot;concept&quot; and &quot;relation&quot;, which are similar to, but more sophisticated than, the 1- and 2-place predicates that come into existence during a session with TELI.</Paragraph> <Paragraph position="3"> At present, IRACQ allows users to define case frame information for verb phrases, prepositional phrases, and noun phrases involving &quot;of&quot;. Its treatment of prepositional phrases is very much like that of TELI in that the head noun being modified is considered part of the the noun-preposition-noun triple for which a definition is beine acquired (cf.</Paragraph> <Paragraph position="4"> Section 4,1). Definitions for individual words (e.g.</Paragraph> <Paragraph position="5"> nouns and adjectives) are not supported but are being considered for future versions of the system, as are facilities that enable the system to inform the user of existing predicates that might be useful in defining a new language item. This facility will be similar in spirit to TELI's provisions for &quot;borrowing&quot; definitions. as described in Section 7.4.</Paragraph> </Section> <Section position="7" start_page="26" end_page="27" type="sub_section"> <SectionTitle> 8.3 A Comparison with TQA </SectionTitle> <Paragraph position="0"> Unlike most efforts at transportability, TQA has been designed as a working prototype, capable of being customizated for complex database applications by actual users. The primary responsibility of the customization module is to acquire information that relates language concepts, e.g. subject of a given verb, to the columns of the database at hand.</Paragraph> <Paragraph position="1"> Like TELI, TQA avoids having to copy all database values into the lexicon by constructing &quot;shape&quot; information to recognize numbers and similar patterns. For example, the system might deduce that all database values referring to a department are of the form &quot;letter followed by two digits&quot;, which allows for valuable disambiguations during parsing. Thus, in a database where employees manage projects and supervisors manage departments, the question &quot;Who manages K34?&quot; can be understood to be asking about supervisors without having to find &quot;K34&quot; in either the lexicon or the database.</Paragraph> <Paragraph position="2"> A related problem, which TQA addresses more squarely than most systems (including TELI), concerns the appearance and possible equivalence of database values. For example. &quot;vac lnd&quot; might indicate &quot;vacant land&quot;, &quot;grn&quot; and &quot;green&quot; might be used interchangeable, and so forth. Many practical applications require that these sorts of issues be addressed in order for a user to obtain reliable information.</Paragraph> <Paragraph position="3"> Another useful feature concerns the acquisition of information that enables non-trivial output formatting. In simple cases, a database administrator might want nine-digit values appearing in columns associated with social security numbers to be printed with dashes at the appropriate points (e.g. 123456789 becomes 123-45-6789), In more complicated situations, values might actually need to be decoded, so that 0910 becomes &quot;vacant land&quot;. This provision for decoding is similar to to the form of intermediate acquisition shown in Figure 3, though here it is being used for opposite effect.</Paragraph> </Section> <Section position="8" start_page="27" end_page="27" type="sub_section"> <SectionTitle> 8.4 A Comparison with ASK </SectionTitle> <Paragraph position="0"> The current ASK prototypes, which run on Sun, Vax, and HP desktop systems, are derived from earlier work on the REL system, which itself derives from work on the DEACON project, which stems from the early 1960's. Unlike most recent efforts, which have sought to incorporate customization features into an existing more-or-less single-domain system, the work with REL, the &quot;Rapidly Extensible Language&quot;, fundamentally included definitional capabilities as early as 1969.</Paragraph> <Paragraph position="1"> To begin with, ASK provides quite general customization facilities, allowing English definitions at least as sophisiticated as those outlined in Section 7.3. An example is &quot;ships 'carry' coal to Oslo if there is a shipment whose carrier is ships, type is coal and destination is Oslo&quot;. Arithmetic facilities are also provided, e.g. &quot;area equals length times beam&quot;. The most distinguishing features of ASK, however, derive from the designers' desire to incorporate natural language technology into an intergrated information management system, rather than provide simple sentence-by-sentence database retrieval. One feature allows ASK to be connected to several external database systems, drawing information from each of them in the context of answering a user's question. A second feature allows a user to provide bulk data input. This begins with the interactive specification of a record type, followed by information used to populate the newly created relation.</Paragraph> </Section> </Section> class="xml-element"></Paper>