File Information

File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/89/h89-1013_metho.xml

Size: 12,280 bytes

Last Modified: 2025-10-06 14:12:20

<?xml version="1.0" standalone="yes"?>
<Paper uid="H89-1013">
  <Title>PORTABILITY IN THE JANUS NATURAL LANGUAGE INTERFACE 1</Title>
  <Section position="4" start_page="112" end_page="113" type="metho">
    <SectionTitle>
WHAT KNACQ DOES
</SectionTitle>
    <Paragraph position="0"> KNACQ assumes that a taxonomic model of the domain exists, such as that typical in many expert systems, and assumes that it is encoded in an axiomatizable subset of KREME \[Brachman, 1985\]. At this point we have built translators for transforming KEE taxonomies and PCL hierarchies into KREME structures. 2 The browsing facilities, graphical views, and consistency checker of KREME are therefore at the disposal of the knowledge base administrator or knowledge engineer when using KNACQ.</Paragraph>
    <Paragraph position="1">  A yplicatlon stem N Using KREME, users may select any concept or role for processing. KNACQ presents the user with a few questions and menus to elicit the English expressions used to refer to that concept or role. From the user's answers, KNACQ creates simple structures which together with powerful general rules allow understanding of a wide range of expressions.</Paragraph>
    <Paragraph position="2"> To illustrate the kinds of information that must be acquired consider the examples in Figure 2. To handle these one would have to acquire information on lexical syntax, lexical semantics, and mapping to expert system structure for all words not in the domain-independent dictionary. For purposes of this exposition, assume that the following words, vessel, speed, Vinson, CROVL, C3, and deploy are to be defined. A vessel has a speed of 20 knots or a vessel's speed is 20 knots would be understood from domain-independent semantic rules regarding have and be, once lexical information for vessel and speed is acquired. In acquiring the definitions of vessel and speed, the system should infer interpretations for phrases such as the speed of a vessel, the vessel's speed, and the vessel speed. The vessel speed of Vinson The vessels speed is 5 knots Its speed Which vessels are deployed C37 The vessels with speed above 20 knots Vinson has speed less than 20 knots Which vessels have a CROVL of C37  Given the current implementation, the required knowledge for the words vessel, speed, and CROVL is most efficiently acquired using KNACQ; names of instances of classes, such as Vinson and C3 are automatically inferred from instances in the expert system taxonomy; and knowledge about deploy and its derivatives would be acquired via IRACQ. That is, we recommend using IRACQ for the diverse, complex patterns of syntax and semantics arising from verbs by providing examples of the verbs' usage, while using KNACQ for efficient acquisition of the more regular noun phrase information (excluding verb-based constructions).</Paragraph>
  </Section>
  <Section position="5" start_page="113" end_page="113" type="metho">
    <SectionTitle>
KNACQ FUNCTIONALITY
</SectionTitle>
    <Paragraph position="0"> Five cases are currently handled: one associated with concepts (or frames), two associated with binary relations (or slots), and two for adjectives. In each case, one selects a concept or binary relation (e.g., using the KREME browser) to provide lexicalizations for that domain entity.</Paragraph>
  </Section>
  <Section position="6" start_page="113" end_page="113" type="metho">
    <SectionTitle>
CONCEPTS OR CLASSES
</SectionTitle>
    <Paragraph position="0"> The association of English descriptions with concepts is the simplest case. It is fundamental knowledge about unmodified head nouns or frozen nominal compounds from which we can build more powerful examples. KNACQ must acquire one or more phrases for a given class, and their declension, if irregular. For the concept CARRIER of Figure 3, we provide KNACQ with the phrases carrier and aircr~t carrier, which can be treated as a frozen nominal compound. Since both are declined regularly, no further information is required. One can provide surface vessel for SURFACE-VESSEL in Figure 3, but that would not allow compositions, such as Count the surface and subsurface vessels. Rather, one should define surface and subsurface as non-comparative adjectives (Section 3.4) modifying phrases corresponding to VESSEL in order to define phrases for the concepts SURFACE-VESSEL and SUBSURFACE-VESSEL.</Paragraph>
  </Section>
  <Section position="7" start_page="113" end_page="114" type="metho">
    <SectionTitle>
ATTRIBUTES
</SectionTitle>
    <Paragraph position="0"> Attributes are binary relations on classes that can be phrased as the &lt;relation&gt; of a &lt;class&gt;. For instance, suppose CURRENT-SPEED is a binary relation relating VESSEL to SPEED, a subclass of ONE-D-MEASUREMENT. An attribute treatment is the most appropriate, for the speed of a vessel makes perfect sense. KNACQ asks the user for one or more English phrases associated with this functional role; the user response in this case is speed. That  answer is sufficient to enable the system to understand the kernel noun-phrases listed in Figure 4. Since ONE-D-MEASUREMENT is the range of the relation, the software knows that statistical operations such as average and maximum apply to speed. The lexical information inferred is used compositionally with the syntactic rules, domain independent semantic rules, and other lexical semantic rules. Therefore, the generative capacity of the lexical semantic and syntactic information is linguistically very great, as one would require. A small subset of the examples illustrating this without introducing new domain-specific lexical items appears in Figure 4. It is this compositionality and the domain independent rules that provide the utility of KNACQ.</Paragraph>
    <Paragraph position="1"> the speed of a vessel</Paragraph>
  </Section>
  <Section position="8" start_page="114" end_page="114" type="metho">
    <SectionTitle>
KERNEL NOUN PHRASES
</SectionTitle>
    <Paragraph position="0"/>
  </Section>
  <Section position="9" start_page="114" end_page="114" type="metho">
    <SectionTitle>
CASEFRAME RULES
</SectionTitle>
    <Paragraph position="0"> Some lexicalizations of roles do not fall within the attribute category. For these, a more general class of regularities is captured by the notion of caseframe rules. Suppose we have a role UNIT-OF, relating CASUALTY-REPORT  (casrep) and MILITARY-UNIT. Besides asking about the unit of a casrep (the attribute use), a user will want to ask about the casreps on a unit (the inverse direction)--this is one case where caseframe rules are needed. KNACQ asks the user which subset of the following six patterns in Figure 5 are appropriate plus the prepositions appropriate. 1. &lt;CASUALTY-REPORT&gt; is &lt;PREP&gt; &lt;MILITARY-UNIT&gt; 2. &lt;CASUALTY-REPORT&gt; &lt;PREP&gt; &lt;MILITARY-UNIT&gt; 3. &lt;MILITARY-UNIT&gt; &lt;CASUALTY-REPORT&gt; 4. &lt;MILITARY-UNIT&gt; is &lt;PREP&gt; &lt;CASUALTY-REPORT&gt; 5. &lt;MILITARY-UNIT&gt; &lt;PREP&gt; &lt;CASUALTY-REPORT&gt; 6. &lt;CASUALTY-REPORT&gt; &lt;MIIJTARY-UNIT&gt;  For this example, the user would select patterns (1), (2), and (3) and select for, on, and of as prepositions. Normally, if pattern (1) is valid, pattern (2) will be as well and vice versa. Similarly, if pattern (4) is valid, pattern (5) will normally be also. As a result, the menu items are coupled by default (selecting (1) automatically selects (2) and vice versa), but this default may be simply overridden by selecting either and then deselecting the other. The most frequent examples where one does not have ~e coupling of those patterns is the preposition of.</Paragraph>
  </Section>
  <Section position="10" start_page="114" end_page="115" type="metho">
    <SectionTitle>
GRADABLE ADJECTIVES
</SectionTitle>
    <Paragraph position="0"> Certain auribute roles have ranges that may be compared, e.g., numbers or measurements. Adjectives can be given for these roles; assume fast is given by the user for the CURRENT-SPEED role or VESSEL discussed earlier.</Paragraph>
    <Paragraph position="1"> KNACQ can correctly predict the comparative and superlative forms of fast. Suppose x and y are instances of  VESSEL. The next information needed is whether x is faster than y means x% speed is greater than y's speed or x% speed is less than y's speed. Optionally, a threshold t can be given such that x's speed is greater than t means x is fast (for a vessel). Additionally, one can specify antonyms for fast, such as slow. The information above would enable understanding the expressions in Figure 6.</Paragraph>
    <Paragraph position="2"> Is Frederick fast~ than every carrier? How fast are the carriers? Is Vinson fast ? How fast is the fastest carrier? Which vessels are slower than 20 knots? Show the fastest vessel.</Paragraph>
    <Paragraph position="3"> Is Vinson as fast as Frederick?</Paragraph>
  </Section>
  <Section position="11" start_page="115" end_page="115" type="metho">
    <SectionTitle>
NON-GRADABLE ADJECTIVES
</SectionTitle>
    <Paragraph position="0"> Of the remaining types of adjectives, some correspond to refining a concept to another named concept in the hierarchy. For instance, surface and subsurface have that property given the network in Figure 3.. In such a case, one must indicate at the general concept, the adjective, any synonyms, and the refined concept.</Paragraph>
    <Paragraph position="1"> Others correspond to an arbitrary restriction on a concept having no explicit refined concept in the domain model.</Paragraph>
    <Paragraph position="2"> Though one could add such a refined concept to the hierarchy, we allow the user to state a logical form to define the adjective as a predicate of one argument.</Paragraph>
    <Paragraph position="3"> A case not yet covered in KNACQ is non-gradable adjectives that are predicates of more than one argument. An example in the FCCBMP domain is mission readiness ratings, M1, M2, M3, M4, and M5. An example is Enterprise is M2 on anti-air warfare, where both the vessel and the type of mission are arguments.</Paragraph>
  </Section>
  <Section position="12" start_page="115" end_page="116" type="metho">
    <SectionTitle>
EXPERIENCE THUS FAR
</SectionTitle>
    <Paragraph position="0"> There are several things we have learned even in the early stages of KNACQ's development based on porting Janus to CASES, an expert system in DARPA's Fleet Command Center Battle Management Program (FCCBMP). In this use of KNACQ, the original domain model pertinent to the portion requiring a natural language interface consisted of 189 concepts and 398 roles.</Paragraph>
    <Paragraph position="1"> First, no restructuring of that domain model was necessary, nor was any deletion required. Second, we found it useful to define some additional concepts and roles. Certain subclasses not critical to the expert system were nevertheless lexically significant. In total, only 123 concepts were added: 53 for classes that were treated as strings in the expert system and 70 domain-independent concepts pertaining to time, space, events, commands, etc.</Paragraph>
    <Paragraph position="2"> Similarly, 28 roles were added.&amp;quot; 24 domain-independent roles and 4 domain-specific roles. In addition, some roles were added to represent role chains that are lexically significant directly. For instance, the DISPLACEMENT of the VESSEL-CLASS of a VESSEL is lexicalizable as the vessel's displacement. Starting from a given concept, a procedure exists to run through a subhierarchy checking for role chains of length two to ask the user if any of those are significant enough to have lexical forms. For the example network we needed to add only 5 roles for this purpose. Third, 1093 proper nouns (e.g., ship and port names) were inferred automatically from instances.</Paragraph>
    <Paragraph position="3"> As a result, the time required to supply lexical syntax and semantics was much less than we had experienced before developing KNACQ. In two days we were able to provide 563 lexical entries (root forms not counting morphological variants) for 103 concepts and 353 roles. Together with the automatically inferred proper nouns, this was approximately 91% of the domain-dependent vocabulary used for the demonstration. That is about 5-10 dmes more productivity than we had experienced before with manual means.</Paragraph>
  </Section>
class="xml-element"></Paper>
Download Original XML