<?xml version="1.0" standalone="yes"?>
<Paper uid="P86-1036">
  <Title>A Terminological Simplification Transformation for Natural Language Question-Answering Systems</Title>
  <Section position="3" start_page="2238" end_page="2238" type="intro">
    <SectionTitle>
PATIENTS =&gt; (PROJECT PATIENTS OVER PATID)
SPECIALTIES =&gt; (PROJECT DOCTORS OVER SPECIALTY)
TREATING-PHYSICIAN =&gt; (PROJECT (JOIN PATIENTS
TO DOCTORS
OVER PHYS DOCID)
OVER PATID DOCID)
</SectionTitle>
    <Paragraph position="0"> Note that while no table exists for physician SPECIALTIES, we can nonetheless give a rule for this predicate in way that is uniform with the rule given for the predicate PATIENTS.</Paragraph>
    <Paragraph position="1"> 2This term, while a standard one in formal logic, may be confused with other uses of the word &amp;quot;constant&amp;quot;. It simply refers to the function, predicate and ordinary constant symbols, such as &amp;quot;MOTHER&amp;quot; or &amp;quot;JOHN&amp;quot;. whose denotations depend on the interpretation of the language, as opposed to fixed symbols like &amp;quot;FORALL',&amp;quot;AND&amp;quot;, &amp;quot;TRUE&amp;quot;. One advantage of such local translation rules is their simplicity. Another advantage is that they enable us to treat database question-answering model-theoretically.</Paragraph>
    <Paragraph position="2"> The set-theoretic structure of the model is that which would be obtained by generating from the relations of the database the much larger set of &amp;quot;virtual&amp;quot; relations that are expressible as formulas of ERL. The interpretation function of the model is just the translation function itself. Note that it is a partial function because of the fact that some non-logical constants may not have translations. We speak therefore of the database constituting a &amp;quot;partially specified model&amp;quot; for the meaning representation language. Computation of a response to a user's request, instead of being characterizable only as a procedural operation, becomes interpretation in such a model.</Paragraph>
    <Paragraph position="3"> A similar model-theoretic approach is advocated in the work on PHLIQA1 \[8\], in which a number of difficulties in writing local rules are identified and overcome. One class of techniques presented there allows for quite complex and general expressions to result from local rule application, to which a post-translation simplification process is applied. Other special-purpose techniques are also presented, such as the creation of &amp;quot;proxies&amp;quot; to stand in for elements of a set for which only the cardinality is known.</Paragraph>
    <Paragraph position="4"> A more difficult problem, for which these techniques do not provide a general treatment, arises when we want to get at information corresponding to a complex property whose component properties and relations are not themselves stored. For example, suppose the query &amp;quot;List patients whose mother was a diabetic&amp;quot;, is represented by the meaning representation:</Paragraph>
    <Paragraph position="6"> The information to compute the answer may be found in the field DIAMOTHER above. It is very hard to&amp;quot; see how we will use local rules to get to it, however, since nothing constructable from the database corresponds to the non-logical constants MOTHER and DIABETIC.</Paragraph>
    <Paragraph position="7"> The problem is that the database chooses to highlight the complex property DIAMOTHER while avoiding the cost of storing its constituent predicates MOTHER and DIABETIC - the conceptual units corresponding to the words of the utterance.</Paragraph>
    <Paragraph position="8"> One way to get around these difficulties is of course to allow for a more general kind of, transformation: a &amp;quot;global rule&amp;quot; which would match against a whole syntactic pattern like the univerally quantified sub-expression above. The disadvantage of this, as is pointed out in \[8\], is that the richness of both natural language and logic allows the same meaning to be expressed in many different ways, which a complete &amp;quot;global rule&amp;quot; would have to match. Strictly syntactic variation is possible: pieces of the pattern may be spread out over the expression, from which the pattern match would have to grab them. Equivalent formulations of the query may also use completely different terms. For example, the user might have employed the equivalent phrase &amp;quot;female parent&amp;quot; in place of the word &amp;quot;mother&amp;quot;, presumably causing the semantic interpretation to yield a logical form with the different predicates &amp;quot;PARENT&amp;quot; and &amp;quot;FEMALE&amp;quot;. This would not match the pattern. It becomes clear that the &amp;quot;pattern-matching&amp;quot; to be performed here is not the literal kind, and that it involves unspecified and arbitrary amounts of inference.</Paragraph>
    <Paragraph position="9"> The alternative approach presented by this paper  takes explicit account of the fact that certain properties and relations, like &amp;quot;DIAMOTHER&amp;quot;, can be regarded as built up from others. In the next section we will show how the properties and relations whose extensions the database stores can be axiomatized in terms of the ones that are more basic in the application domain. This prepares the way for the simplification transformation itself, which will rely on a limited and sound form of inference to reverse the axiomatization and transform the meaning representation, where possible, to an expression that uses only these database properties and relations. In this way, the local rule paradigm can be substantially restored.</Paragraph>
    <Paragraph position="10">  3. Knowledge Representation and Question-Answering  The purpose of this section of the paper is to present a way of connecting the meaning representation language to a taxonomic knowledge representation system in such a way that the inference-making capability of the latter is available and useful for the problems this paper addresses. Our approach may be constrasted with that of others, e.g. TEAM in which such a taxonomy is used mainly for simple inheritance and attachment duties.</Paragraph>
    <Paragraph position="11"> The knowledge representation system used in this work is NIKL \[5\]. Since NIKL has been described rather fully in the references, I will give only a brief summary here.</Paragraph>
    <Paragraph position="12"> NIKL is a taxonomic frame-like system with two basic data structures: concepts and roles. Concepts are just classes of entities, for which roles function somewhat as attributes. At any given concept we can restrict a role to be filled by some other concept, or place a restriction on the number of individual &amp;quot;fillers&amp;quot; of the role there. A role has one concept as its &amp;quot;domain&amp;quot; and another as its &amp;quot;range&amp;quot;: the role is a relation between the sets these two concepts denote. Concepts are arranged in a hierarchy of sub-concepts and superconcepts; roles are similarly arranged. Both concepts and roles may associated with names. In logical terms, a concept may be identified as the one-place predicate with its name, and a role as the two-place predicates with its name.</Paragraph>
    <Paragraph position="13"> I will now give the meaning postulates for a termforming algebra, similar to the one described in \[2\] in which one can write down the sort of NIKL expressions I will need. Expressions in this language are combinable to yield a complex concept or role as their value.</Paragraph>
    <Paragraph position="15"> The key feature of NIKL which we will make use of is its classifier, which computes subsumption and equivalence relations between concepts, and a limited form of this among roles. Subsumption is sound, and thus indicates entailment between terms:</Paragraph>
    <Paragraph position="17"> If the classifier algorithm is complete, the reverse is also true, and entailment indicates subsumption.</Paragraph>
    <Paragraph position="18"> Intuitively, this means &amp;quot; that classified concepts are pushed down as far in the hierarchy as they can go.</Paragraph>
    <Paragraph position="19"> Also associated with the NIKL system, though not a part of the core language definition, is a symbol table which associates atomic names with the roles or concepts they denote, and concepts and roles with the names denoting them. If a concept or role does not have a name, the symbol table is able to create and install one for it when demanded.</Paragraph>
    <Paragraph position="20"> The domain model In order to be able to use NIKL in the analysis of expressions in the meaning representation language, we make the following stipulations for any use of the language in a given domain. First, any one-place predicate must name a concept, and any two-place predicate name a role. Second, any constant, unless a number or a string, must name an &amp;quot;individual&amp;quot; concept - a particular kind of NIKL concept that is defined to have at most one member. N-ary functions are treated as a N+I - ary predicates. A predicate of N arguments, where N is greater than 2, is reified as a concept with N roles. This set of concepts and roles, together with the logical relationships between them, we call the &amp;quot;domain model&amp;quot;.</Paragraph>
    <Paragraph position="21"> Note that all we have done is to stipulate an one-to-one correspondence between two sets of things - the concepts and roles in the domain model and the non-logical constants of the meaning representation language. If we wish to include a new non-logical constant in the language we must enter the corresponding concept or role in the domain model.</Paragraph>
    <Paragraph position="22"> Similarly, the NIKL system's creating a new concept or role, and creation of a name in the symbol table to stand for it, furnishes us with a new non-logical constant.</Paragraph>
    <Paragraph position="23"> Axiomatization of the database in terms of the domain model The translation rules presented earlier effectively seek to axiomatize the properties and relations of the domain model in terms of those of the database. This is not the only way to bridge the gap. One might also try the reverse: to axiomatize the properties and relations of the database in terms of those of the domain model. Consider the DIAMOTHER field of our sample database. We can write this in NIKL as the concept PATIENT-WITH-DIABETIC-MOTHER using terms already present in the domain model:</Paragraph>
  </Section>
class="xml-element"></Paper>