<?xml version="1.0" standalone="yes"?>
<Paper uid="P90-1029">
  <Title>Multiple Underlying Systems: Translating User Requests into Programs to Produce Answers</Title>
  <Section position="4" start_page="229" end_page="231" type="metho">
    <SectionTitle>
4. Challenging Cases
</SectionTitle>
    <Paragraph position="0"> Here we present several well-known challenging classes of problems in translating from logical form to programs.</Paragraph>
    <Paragraph position="1"> 4.1. Deriving procedures from descriptions.</Paragraph>
    <Paragraph position="2"> The challenge is to find a compromise between arbitrary program synthesis and a useful class of program derivation problems. Suppose the user asks for the square root of a value, when the system does not know the meaning of square root, as in Find the square root of the sum of the squares of the residuals. Various knowledge acquisition techniques, such as KNACQ \[15\], would allow a user to provide syntactic and semantic information for the unknown phrase to be defined. Square root could be defined as a function that computes the number that when multiplied times itseff is the same as the input. However, that is a descriptive definition of square root without any indication of how to compute it. One still must synthesize a program that computes square root; in fact, in early literature on automatic programming and rigorous approaches to developing programs, deriving a program to compute square root was often used as an example problem.</Paragraph>
    <Paragraph position="3"> Rather than expecting the system to perform such complex examples of automatic programming, we assume the system need not derive programs for terms that it does not already know. For the example 'The distance function takes any physical objects as its arguments and looks up their location.  above, the system should be expected to respond I don't know how to compute square root.</Paragraph>
    <Paragraph position="4"> By making that assumption, we know that all concepts and relations in the domain model, that is, all primitives appearing in WML as input to the MUS component, have a translation specified by the applications programmer to a composition of underlying services. As stated in Section 2, we further restrict the goals of the MUS component to synthesize programs of a simple structure: acyclic data flow graphs of services where one of the services is applying a function to every element in a finite list. Therefore, the arbitrary program synthesis problem including arbitrary loops and/or recursions is avoided, limiting the scope of inputs handleable but allowing solution of a large class of problems.</Paragraph>
    <Paragraph position="5"> To our knowledge, no NL interface allows arbitrary program synthesis. Most assume equivalence at the abstract program level to synthesis of compositions of the select, project, and join operations of relational algebra. Our component goes beyond previous work in that the programs it generates include more than just the relational algebra.</Paragraph>
    <Paragraph position="6"> 4.2. Side-effects.</Paragraph>
    <Paragraph position="7"> It is well-known that generating a program with side-effects is substantially harder than generating a program that is side-effect free. If there are no side effects, transformations of program expressions can be freely applied, preserving the value(s) computed.</Paragraph>
    <Paragraph position="8"> Nevertheless, side-effects are critical to many interface tasks, for example, changing a display, updating a data base, and setting a value of a variable.</Paragraph>
    <Paragraph position="9"> Our component produces acyclic data flow graphs. The only node that can have side-effects is the final node in the graph. This keeps the MUS processing simple, while still allowing for side-effects at the final stage, such as producing output, updating data in the underlying systems, or running an application program having side-effects. All three of those cases have been handled in demonstrations of Janus.</Paragraph>
    <Paragraph position="10"> Though this issue has not been discussed in other NL publications to our knowledge, we believe this restriction to be typical in NL systems.</Paragraph>
    <Paragraph position="11"> 4.3. Collapse of information.</Paragraph>
    <Paragraph position="12"> It has long been noted \[5\] that a complex relation may be represented in a boolean field in a data base, such as the boolean field of the Navy Blue file which for a given vessel was T/F depending on whether there was a doctor onboard the vessel.</Paragraph>
    <Paragraph position="13"> There was no information about doctors in the data base, except for that field. In a medical data base, a similar phenomenon was noticed \[11\]; patient records contained a T/F field depending on whether the patient's mother had had melanoma, though there was no other information on the patient's mother or her case of melanoma.</Paragraph>
    <Paragraph position="14"> The challenge for such fields is mapping from the many ways that may occur linguistically to the appropriate field without having to write arbitrarily many patterns mapping from logical form to the data base. Just a few examples of the way the melanoma field might be referenced follow: Did Smith's mother ever have melanoma ? How many patients had a mother suffering from melanoma ? Was me/anoma diagnosed for any of the patients' mothers? Our approach to this problem has been to adopt disjunctive normal form (clause form) as the basis for matching services against requirements in the user request. No matter what the form of user request, transforming it to disjunctive normal form means that the information necessary for a disjunct is effectively isolated in one disjunct. The service represented by the field corresponding to &amp;quot;patient's mother had melanoma&amp;quot; covers two conjoined forms: (MOTHER x y) (HAD-MELANOMA y). All of the examples above, given appropriate definitions of suffer and diagnose, will have the two relations as conjuncts in the disjunctive normal form for the input, and therefore, will map to the required data base service.</Paragraph>
    <Paragraph position="15"> 4.4. Hidden joins.</Paragraph>
    <Paragraph position="16"> In data bases, a relation in English may require a join to be inferred, given the model in the underlying system. Suppose that a university data base associates an office with every faculty member and a phone number with every office. Additionally, some faculty members may be associated with a lab facility; labs have telphones as well. Then to answer the query, What is Dr. Ramehaw's phone number?, the relation between faculty members and phone numbers must be determined. There are two possibilities: the office phone number or the lab phone number.</Paragraph>
    <Paragraph position="17"> Most approaches treat this as an inference problem. It can be visualized as finding a relation between two nominal notions faculty member and phone number \[1,2\]. One such path uses the relation OFFICE(PERSON, ROOM) followed by the relation PHONE(ROOM,PHONE-NUMBER). A general heuristic is to use the shortest path. Computing hidden joins complicates the search space in searching for a solution among the underlying services, as can be seen in the architectures proposed, e.g., \[1,4, 9\]. In contrast to the typical approach where one  infers the hidden join as needed, we believe such joins are normally anticipatable, and provide support in our lexical definition tools (KNACQ) for specifying them. In KNACQ \[15\], a knowledge engineer, data base administrator, or other person familiar with the domain and with frame representation specifies for each frame (concept in KL-ONE terminology) and each slot (role in KL-ONE terminology) one or more words denoting that concept or role. In addition, the KNACQ user identifies role chains (sequences of role relations), such as RI(A, B) and R2(B, C), having special linguistic representation. In the example above, KNACQ would prompt the user to select from six possibilities for nominal compounds, possessives, and prepositional connectives relating PERSON to PHONE-NUMBER. In this way, the search space is substantially simplified, since hidden joins have been elicited ahead of time as part of the knowledge acquisition and installation process.</Paragraph>
    <Paragraph position="18"> 4.5. Data coercion.</Paragraph>
    <Paragraph position="19"> At times, the type required by the underlying functions is not directly stated in the input (English) expression but must be derived. One procedure may produce the measure of an angle in degrees, whereas another may require the measure of an angle in radians. Differing application systems may assume a person is referred to by differing attributes, e.g., by social security number in one, but by employee number in another. In How far is Vinson from Pear/ Harbor?, one must not only infer that the positions of Vinson and Pearl Harbor must be looked up, but also make sure that the coordinates are of the type required by the particular distance function chosen.</Paragraph>
    <Paragraph position="20"> In our approach, we assume that there are services available for translati~,g between each mismatch in data type. For the examples above, we assume that there is a translation from degrees to radians and vice versa; that there is a translation from person identified by social security number to person with employee number, and vice versa; that there is a translation function from ships and ports to their loca-tion in latitude and longitude. Such translations may already exist in the applications or may be added as a new application. If there are n different ways to identify the same entity (the measure of an angle, a person, the position of a vessel or port, etc.), there need not be (n*'2)/2 translation functions of course; a canonical representation may be chosen if as few as 2n translation functions are available to provide intertranslatability to the canonical form.</Paragraph>
    <Paragraph position="21"> In constructing the data flow graph, we assume that the canonical representation is used throughout.</Paragraph>
    <Paragraph position="22"> Then translation functions are inserted on arcs of the data flow graph wherever the output/input assumptions are not met by the canonical form. Of the five challenging problems, this is the only one we have not yet implemented.</Paragraph>
  </Section>
  <Section position="5" start_page="231" end_page="232" type="metho">
    <SectionTitle>
5. Related Work
</SectionTitle>
    <Paragraph position="0"> Most previous work applying natural language interfaces provided access to a single system: e.g., a relational data base. Two earlier efforts (at Honeywell \[4, 9\] and at USC/Information Sciences Institute \[6\]) dealt with multiple systems. We will focus on comparison with their work.</Paragraph>
    <Paragraph position="1"> A limitation common to those two approaches is the minimal expressiveness of the input language: user requests must be expressed as a conjunction of simple relations (literals), equivalent to the select/project/join operations of a relational algebra. This restriction is relaxed in Janus, allowing requests to contain negation of elementary predicates, existential and universal quantification, cardinality and other aggregates, a limited form of disjunction (sufficient for the most common cases), and of course simple conjunction. Wh-questions (who, what, etc.), commands, and yes/no queries are handled, and some classes of helpful responses are produced.</Paragraph>
    <Paragraph position="2"> All three efforts employ a search procedure. In the Honeywell effort, graph matching is at the heart of the search; in the USC/ISI effort, the NIKL classifier \[10\] is at the heart of the search; in our effort, a beam search with a cost function is used.</Paragraph>
    <Paragraph position="3"> Only our effort has been tested on applications with a potentially large search space (800 services); the other efforts have thus far been tested on applications with relatively few services.</Paragraph>
    <Paragraph position="4"> 6. Experience in Applying the System The MUS component has been applied in the domain of the Reet Command Center Battle Management Program (FCCBMP), using an internal version of the Integrated Database (IDB) -- a relational database -- as one underlying resource, and a set of LISP functions providing mathematical modeling of a Navy problem as another. The system includes more than 800 services.</Paragraph>
    <Paragraph position="5"> An earlier version of the system described here was also applied to provide natural language access to data in Intellicorp's KEE knowledge-base system, to objects representing hypothetical world-states in an object-oriented simulation system, and to LISP functions capable of manipulating this data~ We have begun integrating the MUS component with BBN's Spoken Language System HARC.</Paragraph>
  </Section>
  <Section position="6" start_page="232" end_page="232" type="metho">
    <SectionTitle>
7. Conclusions
</SectionTitle>
    <Paragraph position="0"> The work offers highly desirable utility along the following two dimensions: * It frees the user from having to identify for each term (word) pieces of program that would carry out their meaning.</Paragraph>
    <Paragraph position="1"> * It improves the modularity of the interface, insulating the presentation of information, such as table i/o, from details of the underlying application(s). We have found the general approach depicted in Figure 2 quite flexible. The approach was developed in work on natural language processing; however, it seems to be valuable for other types of I/O modalities. Some preliminary work has suggested its utility for table input and output in managing data base update, data base retrieval, and a directly manipulable image of tabular data. Our prototype module generates code from forms in the intensional logic; then the components originally developed for the natural language processor provide the translation mechanism to and from intensional logic and underlying systems that actually store the data.</Paragraph>
  </Section>
  <Section position="7" start_page="232" end_page="232" type="metho">
    <SectionTitle>
Acknowledgments
</SectionTitle>
    <Paragraph position="0"> This research was supported by the Advanced Research Projects Agency of the Department of Defense and was monitored by ONR under Contracts N00014-85-C-0079 and N00014-85-C-0016. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S. Government.</Paragraph>
    <Paragraph position="1"> The current address for Philip Resnik is Computer &amp; Information Sciences Department, University of Pennsylvania, Philadelphia, PA 19104.</Paragraph>
    <Paragraph position="2"> We gratefully acknowledge the comments and assistance of Lance Ramshaw in drafts of this paper.</Paragraph>
  </Section>
class="xml-element"></Paper>