Declarative Derivation of Database Queries from

Declarative Derivation of Database Queries from Meaning Representations H. Alshawi, M. Rayner, and A. G. Smith October 1991

URL: http://www.cam.sri.com/tr/crc020/paper.ps.Z Proceedings of the BANKAI Workshop, 1991

1 Introduction In this paper we show how declarative knowledge and meta-knowledge about a database domain can be applied in natural language access (both query and update) to information systems. In particular, the domain model is applied to principled derivation of database oriented logical forms from natural language oriented logical forms, and also to reasoning about the completeness of answers to database queries. The methods described have been implemented as part of the CLARE system, with project resource management as an example application. CLARE is a combined natural language and reasoning system which includes the Core Language Engine (or CLE, Alshawi 1991) as its language component. The CLE is a general purpose system for analysing English into logical form meaning representations. It oers a substantial coverage of the syntax and semantics of English as well as facilities for application speci c lexical acquisition. Initially, the CLE component of CLARE produces purely linguistic representations independently of the in uence of context by applying a uni cation grammar and lexicon for English. These intermediate representations are then resolved according to the linguistic and extra-linguistic context with the help of the CLARE reasoning components. This results in a contextually disambiguated logical form which can be paraphrased back into English (using the same grammar in the reverse direction) to allow the user to con rm the interpretation of referring or vague expressions in the original input. The selected interpretation is then further processed by the reasoning component to produce an answer or achieve some other result. Here we concentrate on this nal phase of processing, particularly the automatic generation of database queries and assertions. In section 2 we discuss several hard problems that arise in building a natural language interface to an information system. Section 3 begins to describe our solution to these problems with an outline of the way English utterances are transformed into executable database queries and 

Also appears in S.W.I.F.T., ed. Intelligent Information Access: Proceedings of the BANKAI

Workshop 1991, Elsevier 1992

1

processed. In section 4 we describe the various components of a domain model for CLARE, and show in a bit more detail how such a model is used to mediate between the linguistic and database worlds. The concluding section summarizes the issues and discusses the research still needed. In the examples given in the paper, the formulae correspond to queries, but the same translation process is also used in CLARE for converting English statements into new database assertions.

2 Two Hard Problems

2.1 The Domain Mapping Problem

In any natural-language interface to a database, a key problem is to provide a mapping from the wide range of concepts and expressive forms that can be re ected in the English input to the more limited, and usually quite dierent, set of relations and datatypes that appear in the database itself. For example, generating answers to the following questions  What is the most recent invoice from Bond Stationers?  How much did we spend on project 1152 in January? may in both cases require reference to the database relation TRANSACTION(,,,,...)

Neither of the English questions mentions transactions, and (let us assume) there is no database relation providing either monthly project expenditure summaries nor information about invoices. The information is there to be extracted, but not in the form suggested by the question. In the one case, the response must re ect the fact that the only information about invoices is contained in the records about the transactions involved in paying them. In the second case, an implicit summation over a set of records from the TRANSACTION relation is called for, though there is no mention of a sum in the question. The diculty is not simply to create a transformation that will make particular kinds of query work in the expected way, but to provide a consistent and declarative way to describe a set of database relations so that an appropriate mapping can be constructed automatically.

2.2 Incomplete Data and the Closed-World Assumption

Knowledge bases and databases inevitably contain only partial information about the world, and to someone trying to obtain information from such a system, it may not be clear what the system knows and what it doesn't. For example, a database may contain information about whether employees have cars, but have no information about those cars. In such a case, if a user asks the question \Does Steve have a car?", the system should be able to produce the correct answer. But if 2

the user then asks, \Did it cost more than $10,000?", not only will the system be unable to answer the question, it will not even be able to construct a valid query.1 But related problems can surface even if a syntactically valid query can be constructed. The English question \Which projects were active in 1990?" could generate a database query diering only in detail from the question \Which projects were active in 1970?". But even if the rst query produces reliable results, the second might produce results which are quite wrong, simply because the database records don't go back that far. This is an example of the kind of problem that is nessed but not solved by the so-called `closed-world assumption' and the related treatment of failure as negation, which many systems have adopted in default of a better solution. The closed-world assumption simply declares that all relevant facts are stored in the database, so that any statement that is true about the actual world can be deduced from facts in the system. This assumption is useful for designing logic programming environments, but it is untenable in the real world.

2.3 Distancing the User from the Database

Natural-language interfaces to computer-based information systems are designed with the goal of making human access to that information simpler and easier. But a concomitant (and intended) eect is to distance end-users from the internal organization of the information, so that it becomes much harder for them to see the boundaries of the information itself. We regard it as essential for a natural-language based system to be able to recognize and point out those instances where the tacit assumptions of the end-user and the working assumptions of the database designer may be in con ict. The scheme we have been developing in CLARE for query derivation, described in the remainder of the paper, provides a mechanism for tackling all of these problems in a uniform and principled way. With this scheme, the closed-world assumption is unnecessary, and a database administrator can provide the system with declarations about the range of validity of the information stored in the database. The query derivation process then uses this information in generating a query, ensuring that answers provided to the end-user are as informative and accurate as possible. It is a step in the direction of systems that \know what they know and what they don't know". It should be noted that we are reporting in this paper on work in progress. We have made considerable advances recently particularly in simplifying the kinds of declaration needed to specify a domain model, and we are experimenting with further simpli cations. By the time the project is complete, we hope to have a stepby-step procedure for users of the CLARE system to construct their own models, avoiding the problems discussed above, in a straightforward way. 1

This has sometimes been called the \doctor on board" problem (cf. Perrault & Grosz 1988).

3

3 Query Processing As discussed brie y in the introduction, the output of the language component of CLARE is, for each sentence or sentence fragment, a logical form to be evaluated. Earlier stages of processing have dealt with the vagaries of English syntax and word order, have established the referents of pronouns and other referring expressions, have discarded interpretations that don't make sense because of sortal mismatches, have resolved lexical ambiguities, and so on. The resulting LFs are expressions in a language which is a modest extension of rst order logic (cf. Alshawi 1991 for details). Each LF then consists of a recursive structure consisting of operators and predicates and their arguments. The LF represents the `meaning' of a sentence, but the predicates it contains still re ect the selected sense entries associated with words in the English lexicon. Thus for example the the sentence Does Smith work on project 8306? results in the logical form (LF) ynq(quant(exists, A, event(A), work_on_BeEmployedOn(A,Arnold Smith,SafeMOS)))

Without worrying about the details2, one can see that \Smith" has been resolved to a particular individual, and \project 8306" has been resolved to an entity with the name `SafeMOS'. \work" and \on" have together been resolved to a predicate of three arguments (an event, a person, and a project), which comes from one of the senses of the verb \work" in the lexicon. If there were a complete one-to-one (or many-to-one) relationship between such lexical predicates and the relations in a database, one could simply have a specialized lexicon which supplied the appropriate database relation name for each word sense. But in practice the correspondence will almost never be that simple. English word senses overlap and cross-cut in ways that relations in a properly-structured database should never do. The actual relationship will almost invariably be a many-to-many mapping, with potentially complex conditions on the applicability of each correspondence. And even with a restricted lexicon, the linguistic coverage, in terms of the range of possible questions, will far exceed the coverage of the database. In the CLARE system, the process of constructing such a mapping from language to a set of database queries relies on several components which together can be thought of as CLARE's model of a particular application domain. The principal components of a domain model are  The domain lexicon, This is a yes-no question about whether there exists an event corresponding to Arnold Smith being-employed-on the SafeMOS project 2

4

Extensions to the CLE sort, or type, hierarchy,  De nitional equivalences  Functional relation declarations. Each of these components is described brie y in section 4. But rst we describe the process of query derivation in a little more detail. 

3.1 Query derivation and query evaluation

Once the linguistic phases of processing are complete, and a logical form has been constructed, it is then the responsibility of the interface manager to take appropriate action, including the delivery of an appropriate response to the user. This is a twostage process. The rst stage consists of deriving from the logical form an executable query in which  all expressions whose evaluation requires access to an external database have been transformed to use only database predicates,  all simpli cations that can be made on the basis of meta-level knowledge have taken place,  any remaining expressions can be evaluated directly with respect to the internal knowledge base. In order to produce a derivation satisfying these criteria, it may be necessary to postulate some assumptions that are not themselves immediately provable. Each assumption has an associated cost. As an assumption is made, the assumption itself is added to a list of required assumptions, and its cost is added to the total assumption cost for the current derivation path. Not surprisingly, the derivation corresponding to the lowest cost in assumptions is the one preferred. Some assumptions will be discharged by reference to other conjuncts in the LF resulting from the user's query. Others may be classi ed as suciently trivial that they can be adopted without further ado. But any remaining non-trivial undischarged assumptions will be reported to the user. The mechanisms for generating and discharging assumptions are described in the next section. Once a query has been satisfactorily derived, query evaluation takes place. This is the stage during which any actual data is retrieved from (or entered into) the database, and is suitably transformed for presentation as an answer to the user's question. Query derivation is a meta-level operation (it involves reasoning about facts about the domain), while query evaluation is the corresponding object-level operation (it involves reasoning about the domain). The key to CLARE's solution to the problems described in section 2 is that the information resulting from query derivation can be just as important as the information resulting from query evaluation. 5

3.2 Assumptions and Abductive Reasoning

Note that assumptions are made at several points during processing. Some assumptions can be required during phases prior to query processing in order to produce a fully-quali ed logical form from what may have been an elliptical (incomplete) input by the user. This kind of assumption is equivalent to elaborating what the system assumes the user meant. But the kind of assumption introduced during query derivation comes from constraints on what information the database is known to actually contain. If the user says What payments have we made to North Crest? and payment records in the system cover only the period October 1989 { July 1991, then the system can only answer the question under the assumption that the period covered by the database is the period the user wanted information about in asking his question. It will inform the user of this assumption in case he isn't aware of it, by preceding the answer with Payment records cover only the period from 1/10/89 to 13/7/91. followed by the list of payments: 100207 1989-9-4 North Crest Dairies Ltd $23.37 100217 1989-10-6 North Crest Dairies Ltd $27.58 100249 1989-11-3 North Crest Dairies Ltd $23.48 100286 1989-12-1 North Crest Dairies Ltd $31.63 100337 1990-1-9 North Crest Dairies Ltd $22.19 100370 1990-2-9 North Crest Dairies Ltd $28.77 100413 1990-3-9 North Crest Dairies Ltd $22.73 100446 1990-4-2 North Crest Dairies Ltd $20.76 100476 1990-5-14 North Crest Dairies Ltd $28.18 100537 1990-7-13 North Crest Dairies Ltd $48.70 100542 1990-7-27 North Crest Dairies Ltd $21.56 100590 1990-9-7 North Crest Dairies Ltd $25.15 100620 1990-10-4 North Crest Dairies Ltd $25.26 100669 1990-10-31 North Crest Dairies Ltd $23.67 100728 1990-12-4 North Crest Dairies Ltd $33.39 100767 1991-1-7 North Crest Dairies Ltd $21.20 100800 1991-2-4 North Crest Dairies Ltd $21.20 100893 1991-3-25 North Crest Dairies Ltd $26.60 If on the other hand, the user asks How much did we pay North Crest in 1990? then the system has no need to introduce such an assumption, because the question itself contains a restriction that makes the database relation completely applicable. Since no assumptions are needed, no warnings are needed, and the user is given a straight answer to his question: 6

$300.36

Finally, if the user had asked How much did we pay North Crest in 1985? no assumption can be made which will allow the translation to proceed, because the only legitimate assumption (the one used in the rst example) is one whose negation can be proved on the basis of one of the terms in the question. The result in this case, as in every case where no translation is possible, is Available information is insucient to answer your question. From these examples one can see that only statements that can neither be proved nor disproved in the current environment can be candidate assumptions. It also becomes clear why all of the terms in the question apart from the one whose translation is being tackled at any given moment must be temporarily made available as axioms in the current context. The process of generating assumptions as required during the course of deriving a formula and then attempting to discharge them later is known as abductive reasoning, and our approach to doing this is closely related to that taken by Hobbs and his colleagues (Hobbs et al 1988).

4 Domain Model (Knowledge-Base Schema) CLARE comes equipped with a certain amount of domain-independent knowledge about the world. This knowledge includes a model of time and temporal relations, and a core vocabulary of words and word senses roughly corresponding to Basic English. The time model is needed for handling tense and temporal reference, and is in any case important in a wide range of applications. A domain model extends the core coverage to include the words and concepts needed for a particular application. Where a database is involved|which is the case we are discussing here|the domain model must also supply the correspondence between the database relations and the linguistic concepts and predicates. The knowledge and factual information for a particular application can be spread across several sources: some of it can have been entered directly in English and stored declaratively in CLARE's internal representation language, and some of it may be contained in one or more conventional external relational databases. In addition, CLARE contains facilities for switching with a single command from one application or target domain to another. Separate domains are appropriate where the subject matter is suciently dierent that a dierent vocabulary is appropriate, or where dierent default interpretations of the same words are called for. In the following sections we describe brie y what the components of a domain model look like, how they are constructed, and how they are used in query interpretation and response. 7

4.1 Domain Lexicon

For extending the core lexicon, CLARE has an interactive lexical acquisition tool called VEX (described in Carter 1989) that is designed for the addition of new entries by people without expertise either in the CLARE system or in linguistics. An entry in the lexicon contains information about the syntactic roles of a word, its morphological properties (how the stem of the word can combine with various possible suxes), and an outline of its meaning. The meaning at this stage is characterized only in terms of broad categories (referred to internally as `sorts', described below) which serve primarily to distinguish dierent senses of the same word and to help reduce ambiguities during sentence interpretation.

4.2 Sort Hierarchy Extensions

CLARE comes with a built-in classi cation scheme for describing the senses of English words. It is based on a hierarchy (actually a multiple-inheritance lattice) of categories for things. The classi cation is similar to an object-oriented class hierarchy, and could be aligned with an object-oriented representation scheme, although we do not currently use such a framework in CLARE. Individual objects are assigned a place in the lattice, and predicates associated with nouns, verbs and adjectives in the language are classi ed according to the types of object they can apply to. As mentioned above, sortal constraints are applied during linguistic processing to resolve potential ambiguities. It can be useful, therefore, to extend the supplied hierarchy, which is designed to cope broadly with the whole range of language, to provide ner distinctions for a particular area of application. CLARE provides tools for augmenting the sort hierarchy but we will not discuss them in this paper.

4.3 De nitional Equivalences

The most important component of the domain model is the set of de nitional equivalences, which describe how linguistic relations can be transformed into database relations and vice versa. It is the set of de nitional equivalences that determine the possible paths for a query derivation. Since the task of query derivation is to transform a formula composed of terms whose predicates come from the lexicon into a corresponding formula composed of terms specifying database relations, a de nitional equivalence relates formulas of the two kinds. As an example, take the database relation DB EMPLOYEE(S,X), which signi es that the person named X is an employee of SRI International, and is male if S is m and female if S is w. Some equivalence declarations are given below, the rst three showing how the DB EMPLOYEE relation is connected to the lexical predicates corresponding to the English words \employee", \man" and \woman". employee_of(X,'SRI International'),mw(S,X) DB_EMPLOYEE(S,X) payee_Recipient(X),mw(S,X) DB_PAYEE(S,X)

8

man_MalePerson(X) mw(m,X) woman_FemalePerson(X) mw(w,X) work_for(X,Y) employee_of(X,Y)

The notational conventions here are Prolog-like: upper-case letters as arguments represent variables, quoted strings and lower-case letters represent constants, and a list of terms separated by commas denotes the conjunction of those terms. The rst point to note is that the equivalences are bi-directional, and both the right-hand side and the left-hand side of a de nitional equivalence can consist of a conjunction of terms. Secondly, while all database relations (indicated here by using uppercase and a DB pre x for the relation names) appear only on the right-hand side, and all lexical predicates appear at least once on the left-hand side, intermediate relations, which are employed for expressive economy, can appear on either side. Existing lexical relations may serve this purpose (employee of is used this way above), but it is sometimes useful to introduce arbitrary new intermediate relations (like mw above) to reduce the total number of equivalences needed. The same formalism can be used for declaring that the tuples in a database relation cover only a restricted time period, for example. The next example shows an instance of this: transaction(Id,ChequeNo,Date,'SRI International',Payee), calen_before(date(89,8,1),Date),calen_before(Date,date(91,4,1)) DB_TRANSACTION(Id,ChequeNo,Date,Payee)

The calen before terms in this example express the temporal restriction on the corresponding database relation, and serve to illustrate how the assumption mechanism works. The translation of an LF into a database query in this case will depend on being able to satisfy the calen before predicates. (calen before is a predicate on two calendar dates, which is true if the rst date is prior to the second). If the negation of either of these predicates can be proved in the context that includes the rest of the user's question, then the entire equivalence will be blocked and the system will generate the response previously mentioned: Available information is insucient to answer your question. If they can both be proved with respect to the current context, then translation to the database form is straightforwardly successful. If they can neither be proved nor explicitly disproved, then these clauses become candidates for addition to the assumption list, and translation can proceed provided the current assumption cost threshold has not been reached. We have omitted here the details of how assumption costs are expressed and calculated as it is beyond the scope of this paper, and in any case because we are continuing to experiment with alternative representation schemes. 9

payment_PayingEvent(payment(Id)) transaction(Id,_,_,_,_) pay_GiveMoneyTo(payment(Id),Payer,Payee) transaction(Id,_,_,Payer,Payee) cheque_Document(cheque(ChequeNo)) transaction(_,ChequeNo,_,_,_) to(payment(Id),Payee) transaction(Id,_,_,_,Payee) from(payment(Id),Payer) transaction(Id,_,_,Payer,_)

This set of examples illustrates a few more points. Another intermediate predicate has been introduced: the ve-argument transaction(), corresponding to the fourargument database relation DB TRANSACTION(). The intermediate predicate has unrestricted temporal validity, and it is this predicate that is tied to the various lexical predicates corresponding to the English words \payment", \pay", \cheque", \to", \from". Secondly, note that the database predicate has no explicit representation of the Payer eld|in the database the payer is implicitly SRI International. In English, however, users can ask about or explicitly refer to the payer of a transaction and the system will behave appropriately, admitting to no knowledge about payments from sources other than SRI. It turns out that the de nitional equivalences have several further uses besides query derivation. Because they relate variables in database tuples to lexical predicates, they can be used to automatically generate linguistic predicates to express facts that have been entered into a database via some other means. In addition, de nitional equivalences are used as a source of information for automatic resolution of vague relations during linguistic analysis. Vague relations include those implied by noun-noun combinations (does \SafeMOS payment" mean `payment on behalf of SafeMOS', `payment by SafeMOS', or `payment to be arged to the SafeMOS account'?), and also relations denoted by vague prepositions like \of". Because the equivalences characterize the information in the database in terms of linguistic predicates, they allow the language analyzer itself to use the database as a source of information about how objects are related in the world. Once again the details of these uses are beyond the scope of the present paper.

4.4 Functional Relation Declarations

A problem arising from the query derivation process which we have so far not mentioned is that the raw database queries it produces tend to contain a considerable amount of redundancy. The initial version of a translated query may contain several occurrences of the same database relation, and it is obviously useful if these can be merged into a single expression. The information needed to perform this reduction is equivalent to knowing which, 10

if any, of the elds of a database relation is a unique key for the remaining elds in the relation. The notation we use is a function declaration. . . function(DB_TRANSACTION(Id,ChequeNo,Payee,Date), [Id] -> [ChequeNo,Payee,Date])

This declaration would signify that a given transaction ID uniquely determines a cheque number, a payee, and a date. The notation allows for the key eld to uniquely specify all, or only some of the remaining elds, though the latter would be applicable only for databases that were not in \third normal form". Under some circumstances, query simpli cation using function declarations of this kind can allow a query to be satis ed immediately without requiring any database access at all. This of course is the extreme case, but is not uncommon if, for example, an earlier query has retrieved some related information.

5 Conclusion We have tried to show in this paper that treating the derivation of database queries as an inference process using a domain model solves several key problems in providing natural language interfaces to computer-based information systems. We have shown that it is possible to connect a natural-language front-end to a strictly constrained database without sacri cing either expressive exibility at the linguistic level or integrity constraints at the database level. We have illustrated a mechanism which allows a naive user to access a database without prior knowledge of the limitations of the information stored in it, relying on the system itself to alert him to mistaken assumptions when appropriate. A system based on these principles can alert the end-user (1) to possible gaps in the response he is presented with, (2) to assumptions implicit in the database design that may be pertinent to his query, and (3) to assumptions made by the system in interpreting his questions and statements. These capabilities depend, of course, on the system being able to access information about the domain of application and about the constraints on any associated databases. We have attempted to show that this information, in the form of a domain model, can be expressed in a declarative and reasonably intuitive way. Research continues, and we are experimenting with further simpli cations in the speci cation of domain models. In principle, much of the information required could itself be expressed in English, and translated into the required formalisms by CLARE itself.

6 Acknowledgements CLARE is being developed as part of a collaborative project involving SRI International, British Aerospace, BP Research, British Telecom, Cambridge University, the UK Defence Research Agency, and the UK Department of Trade and Industry. We are grateful to our partners for their inputs to the work reported here. 11

References Alshawi, Hiyan, ed. (to appear 1991). The Core Language Engine. Cambridge, Massachusetts: The MIT Press. Carter, D.M. (1989) \Lexical Acquisition in the Core Language Engine", Proceedings of the Fourth Conference of the European Chapter of the Association for Computational Linguistics, pp 137{144. Hobbs, J.R., M. Stickel, P. Martin and D. Edwards. 1988. \Interpretation as Abduction", in Proc. 26th ACL, Bualo, New York. Perrault, C. Raymond and Barbara J. Grosz (1988). \Natural Language Interfaces" in Exploring Arti cial Intelligence: Survey Talks from the National Conferences on Arti cial Intelligence, Morgan Kaufmann, San Mateo. Rayner, Manny and Sverker Janson (1987). \Epistemic Reasoning, Logic Programming, and the Interpretation of Questions". In Natural Language Understanding and Logic Programming 2, North-Holland. Stickel, Mark E (1986). \A Prolog Technology Theorem Prover: Implementation by an Extended Prolog Compiler", Technical Note 382, Arti cial Intelligence Center, SRI International, Menlo Park, California.

12