From: AAAI-90 Proceedings. Copyright ©1990, AAAI (www.aaai.org). All rights reserved.

The Intelligent Interface: Integrating AI and Database Systems

Donald P. McKay and Timothy W. Finin and Anthony O’Hare* Unisys Center for Advanced Information Technology Paoli, Pennsylvania [email protected] and [email protected]

Abstract its tuple-at-a-time inference mechanisms. The ID1 has also been used to implement a query server supporting The Intelligent Database Interface (IDI) is a cache-based interface that is designed to provide Artificial Intelligence a database used for an Air Trorvel Information System systems with efficient access to one or more on one which is accessed by a spoken language system imple- or more remote database management systems (DBMSs). mented in Prolog [Dahl, et. al., 19901. It can be used to interface with a wide variety of different In addition to providing efficient access to remote DBMSs with little or no modification since SQL is used to DBMSs, the ID1 offers several other distinct advan- communicate with remote DBMSs and the implementation tages. It can be used to interface with a wide vari- of the ID1 provides a high degree of portability. The query ety of different DBMSs with little or no modification language of the ID1 is a restricted subset of function-free since SQL is used to communicate with the remote Horn clauses which is translated into SQL. Results from the DBMS. Also, several connections to the same or differ- ID1 are returned one tuple at a time and the ID1 manages a cache of result relations to improve efficiency. The ID1 is ent DBMSs can exist simultaneously and can be kept one of the key components of the Intelligent System Server active across any number of queries because connec- (ISS) knowledge representation and reasoning system and is tions to remote DBMSs are abstract objects that are also being used to provide database services for the Unisys managed as resources by the IDI. Finally, accessing spoken language systems program. schema information is handled automatically by the IDI, i.e., the application is not required to maintain Introduction up-to-date schema information for the IDI. This signif- icantly reduces the potential for errors introduced by The Intelligent Database Interface (IDI) is a portable, stale schema information or by hand entered data. cache-based interface designed to provide artificial intel- The ID1 can be viewed as a stand-alone DBMS inter- ligence systems in general and expert systems in par- ticular with efficient access to one or more databases face which accepts queries in the form of IDIL clauses on one or more remote database management systems and returns the result relation as a set of tuples (i.e., (DBMS) which support SQL [Chamberlm, et. al., a list of Lisp atoms and/or strings). IDIL queries are 19761. The of the ID1 is the Intelligent translated into SQL and sent to the appropriate DBMS Database Interface Language (IDIL) [O’Hare, 19891 and for execution. The results from the DBMS are then is based on a restricted subset of function-free Horn transformed by the ID1 into tuples of Lisp objects. Al- clauses where the head of a clause represents the tar- though the IDI was not designed to be used directly get list (i.e., the form of the result relation) and the by a user, the following descriptions will be couched body is a conjunction of literals which denote database in terms of using the ID1 as a stand-alone system so relations or operations on the relations and/or their at- that we may avoid complicating our discussions with tributes (e.g., negation, aggregation, and arithmetic op- the details of an AI system such as the ISS. erations). The design of the ID1 was heavily influenced by pre- The ID1 is one of the key components of the In- vious research in the area of AI/DB integration [Kellog, telligent System Server (ES) [Finin, et. al., 19891 et. al., 1986, O’Hare, 1987, O’Hare and Travis, 1989, which is based on Protem [Fritzson and Finin, 19881 O’Hare and Sheth, 19891. One of the more significant and provides a combined logic-based and frame-based design criteria that this lead to is the support of non- knowledge representation system and supports forward- trivial queries in IDIL. That is, to allow for queries in- chaining, backward-chaining, and truth maintenance. volving more than just a single database relation. This The ID1 was designed to be compatible with the logic- capability allows the AI system to off-load computa- based knowledge representation scheme of the ISS and tions that are more efficiently processed by the DBMS instead of the AI system (e.g., join operations). In many *current address: IBM, Research Triangle Park, North cases, this also has the effect of reducing the size of data Carolina set that is returned by the DBMS.

MCKAY ET AL. 677 the AI system is extended with DBMS capabilities to provide efficient access to, and management of, large amounts of stored data. In general, such systems do

Ertmdhg Re Al system ldxse coupling not incorporate full DBMS technology. Rather, the emphasis is on the AI system and the DBMS capabil- ities are added in an ad hoc and limited manner, e.g., [Ceri, et. al., 19861 implements only the data access layer. Alternatively, a new generation knowledge-based system such as LDL [Chimenti, et. al., 19871 may be constructed. In either ease, this approach effectively Figure 1: Of the four alternative approaches to AI/D5 inte- involves “re-inventing” some or all of DBMS technol- gration, the Intelligent Database Interface is an example of ogy. While such systems typically provide sophisticated an enhanced AI/DB interface. tools and environments for the development of applica- tions such as expert systems, they can not readily make While the ID1 is to some small degree system depen- use of existing databases. Thus, the development of AI dent, it does offer a high degree of portability because applications which must access existing databases will it is implemented in Common Lisp, communicates with be exceedingly difficult if not impossible (e.g., when the remote DBMSs using SQL and standard UNIX pipes, database is routinely accessed and updated via more and represents IDIL queries and their results as Com- traditional kinds of applications). mon Lisp objects. Extending the DBMS System: This approach In the following sections we present a brief overview extends a DBMS to provide knowledge representation of the area of AI/DB integration which represents a and reasoning capabilities, e.g., POSTGRES [Stone- large part of the motivation for the IDI, a discussion breaker, et. al., 19871. Here, the DBMS capabilities are of some of the more significant features of the IDI, the the central concern and the AI capabilities are added in organization and major components of the IDI, and fi- an ad hoc manner. The knowledge representation and nally an example of how the ID1 is being used in two reasoning capabilities are generally quite limited and applications. - they lack the sophisticated tools and environments of most AI systems. Such systems do not directly sup- AI/DB Integration port the use of existing DBMSs nor can they directly support existing AI applications (e.g., expert systems) The integration of AI and DBMS technologies promises without substantial effort on the part of the applica- to play a significant role in shaping the future of com- tion developer. In some sense, this is the opposite of puting. As noted in [Brodie, 19881, AI/DB integration the previous approach. is crucial not only for next generation computing but also for the continued development of DBMS technology Loose Coupling: The loose coupling approach to and for the effective application of much of AI technol- AI/DB integration uses a simple interface between the ogy* two types of systems to provide the AI system with ac- While both DBMS and AI systems, particularly ex- cess to existing databases, e.g., KEE-connection [Abar- pert systems, represent well established technologies, bane1 and Williams, 19861. While this approach has research and development in the area of AI/DB inte- the distinct advantage of integrating existing AI sys- gration is comparatively new. The motivations driv- tems and existing DBMSs, the relatively low level of ing the integration of these two technologies include integration results in poor performance and limited use the need for (a) access to large amounts of shared of the DBMS by the AI system. In addition, access data for knowledge processing, (b) efficient manage- to data from the database, as well as the data itself, ment of data as well as knowledge, and (c) intelli- is poorly integrated into the representational scheme of gent processing of data. In addition to these moti- the AI system. The highly divergent methods repre- vations, the design of ID1 was also motivated by the senting data (e.g., relational data models vs. frames) is desire to preserve the substantial investment repre- generally left to the application developer or knowledge sented by most existing databases. To that end, a engineer with only minimal support from the AI/DB key design criterion for ID1 was that it support the interface. use of existing DBMSs as independent system compo- Enhanced AI/DB Interface: The last approach nents. As illustrated in Figure 1 and described below, to AI/DB integration represents a substantial enhance- several general approaches to AI/DB integration have ment of the loosely coupled approach and provides a been investigated and reported in the literature (e.g., more powerful and efficient interface between the two [Bocca, 1986, Chakravarthy, et. al., 1982, Chang, 1978, types of systems. As with the previous approach, this Chang and Walker, 1984, Jarke, et. al., 1984, Li, 1984, method of AI/DB integration allows immediate advan- Minker, 1978, Morris, 1988, Naish and Thorn, 1983, tage to be taken of existing AI and DB technologies Reiter, 1978, Van Buer, et. al., 19851). as well as future advances in them. The problems of Extending the AI System: In this approach, performance and under-utilization of the DBMS by the

678 KNOWLEDGEREPRESENTATION AI system are handled with differing degrees of suc- e The AI system generates many DBMS queries that tend cess first by increasing the functionality of the interface to yield, on average, small results and the AI system uses itself, and then if necessary, enhancing either the AI most or all of the result. system or the DBMS. For example, the BERMUDA system [Ioannidis, et. al., 19881 uses a form of result In the first case, it would be best to avoid the cost caching to improve efficiency and performs some sim- of processing the entire result by using demand-driven ple pre-analysis of the AI application to identify join techniques to produce only one tuple at a time from operations that can be performed by the DBMS rather the result stream of the DBMS. However, this requires than the AI system. The BrAID system [O’Hare and that separate connections be created for each DBMS Sheth, 19891 is similar except that it supports more gen- query. Thus the overhead of creating such connections eral caching and pre-analysis capabilities and allows for must be less than the cost of processing the entire result experimentation with different inference strategies. relation. The ID1 is an interface that can be used to facili- tate the development of AI/DB systems using this last In the second case, it would be best to avoid the cost approach. That is, the ID1 is cache-based interface to of creating numerous connections to the DBMS by using DBMSs and is designed to be easily integrated into var- a single connection for multiple queries. However, this ious types of AI systems. The design of the ID1 also al- requires that the entire result ofeach query be processed lows it to be used as an interface between DBMSs and so that successive queries can be run using the same other types of applications such as database browsers connection. The cost of processing DBMS results (i.e., and general query processors. reading the entire result stream and storing it locally) must be less than the cost of creating a new connection Design Features _ , for each DBMS query. The ID1 supports several features which simplify its use For most systems, it seems reasonable to assume that in an AI system. These include the total cost for creating a new DBMS connection will Connections to a DBMS are managed transparently so be relatively high. Thus, using the same connection for that there can be multiple active queries to the same different DBMS queries would result in a net savings. database using a single open connection. While specific break-even points could be estimated, it Connections to a given database are opened upon de- is not clear one need go that far since there are other mand, i.e. at first use instead of requiriig an explicit reasons for minimizing the number of DBMS connec- database open request. tions that are open at the same time. Foremost among information is loaded kom the database these is the limit that most operating systems have on either when the database is opened or when queries re- the number of streams that can be open simultaneously. quire schema information based upon user declarations. This can severely limit the number of DBMS connec- The query interface is a logic-based language but uses tions that we can have at one time. If one is also inter- user supplied functions to declare and recognise logic vari- ested in allowing connections to different databases, on ables. either the same or a different DBMS, then it is impor- Results of queries to a DBMS are cached, improving tant to minimize the number of open connections for a the overall performance system and the cache is accessed single database. transparently by a query manager. All but the last of the features are described in this sec- Yet another consideration is the use of caching for tion. The cache system and initial performance results DBMS results. That is, if DBMS results can be cached are described in subsequent sections. locally by the AI system or an agent serving it then all of the DBMS results will probably be processed by the Making Connect ions caching mechanism. Thus, the first alternative (where it is assumed that the DBMS results will not, in general, As suggested above, there are numerous approaches to be totally consumed) is no longer applicable. interfacing an AI system with existing DBMSs. How- ever, the basic alternatives involve balancing the costs In light of these constraints and requirements, it of creating the connection to the DBMS and of process- seems best to minimize the number of DBMS connec- ing the result relations from a DBMS query. Deciding tions that can be open simultaneously. Briefly, the which alternative is the best requires knowledge about approach taken in the ID1 is to open a connection the typical behavior of the AI system as well as other, when a DBMS query is encountered against a database more obvious factors, such as communication overhead for which no connection exists and process the result (cf. [O’Hare and Sheth, 19891). Consider the following stream one tuple at a time until and unless another two modes of interaction between an AI system and a DBMS query on the same database is encountered. At DBMS: that point, the new query is sent to the DBMS, the re- e The AI system generates a few DBMS queries that tend mainder of the result stream for the previous query is to yield very large results and the AI system uses only a consumed and stored locally, and then the new result fraction of the result. stream is processed one tuple at a time as before.

MCKAY ET AL. 679 Automating Access to Schema Information Get supplier names for suppliers who do not SUpp1y part p%. ( (an8 ,Sname) One of the key features of the ID1 is the automatic <- management of database schema information. The user (supplier -Sno ,Sname -Status -City) or application program is not required to provide any (not (supplier,part ,Sno "p2" ,Qty))) schema information for those database relations that are accessed va’u IDIL queries. The ID1 assumes the responsibility for obtaining the relevant schema infor- Get supplier namea and quantity supplied for supplier8 that mation from the appropriate DBMS. This provides sev- supply more than ,900 units of part p.% eral significant advantages over interfaces which rely on ((am ,Snme ,Wy) the user to provide schema information. Most impor- <- tantly, the schema information will necessarily be con- (supplier -Sno ~Snanw -Status -City) sistent with that stored in the DBMS and thus any (supplier-part ,Sno "p2" -t&y) errors introduced by hand-coding the schema informs 0 ,qty 300)) tion are eliminated. The only exception to this occurs when the schema on the DBMS is modifled after the Figure 2: Two example lDlL queries using the “suppliers” ID1 has accessed it since the ID1 caches the schema database. Symbols beginning with a “/’ character have been information and thus maintains a private copy of it. declared to be logic variables. While this stale data problem exists for any system which maintains a separate copy of the schema informa- of inputs or requests to the IDI: (a) a database dec- tion, the ID1 provides a simple mechanism for forcing laration; (b) an IDIL query and subsequent retrieval the schema information to be updated. In addition, requests against the result of an IDIL query; and (c) this approach greatly facilitates the implementation of advice to the Cache Manager.. Database declarations database browsers since users need not know the names convey simple information about a given database, e.g., or structure of relations stored in a particular database. the type of the DBMS on which the database resides and the host machine for the DBMS. For each IDIL Logical Glue query, the ID1 returns a generator which can be used to Another significant feature of the ID1 is the relative retrieve the result relation of an IDIL query one tuple at ease with which it can be integrated with different AI a time. The ID1 also supports other types of requests, systems. Aside from the use of Common Lisp as the e.g., access to schema information, which are described implementation language for the IDI, this is achieved elsewhere [O’Hare, 19891. by employing a logic-based language as the query lan- The Schemu Munuger (SM) is responsible for manag- guage for the IDI. The language, IDIL, may be used ing the schema information for all declared databases as a totally independent query language or, more im- and it supplies the Query Manager with schema infor- portantly, it may be more closely integrated with the mation for individual database relations. This entails knowledge representation language of a logic-based AI processing database declarations, accessing and storing system. In the later case, the key is to allow the ID1 to schema information for declared databases, and man- share the same definition of a logic variable as the host aging relation name aliases which are used when two or AI system. This is accomplished be simply redefining a more databases contain relations with identical names. small set of functions within the ID1 which are used to Whenever a connection to a database is created, the SM recognize and create instances of logic variables. automatically accesses the list of relation names that The IDIL 1 query language is a restricted subset of are contained within the database. This list is then function-free Horn clauses where the head of a clause cached for later access in the event that the connection represents the target list (i.e., the form of the result is closed and re-opened at some later time. In this event relation) and the body is a conjunction of literals which the SM will only access the DBMS schema information denote database relations or operations on the relations if it is explicitly directed to do so, otherwise the cached and/or their attributes (e.g., negation, aggregation, and list of relation names will be used. arithmetic operations). Figure 2 shows some example The DBMS Connection Manager (DCM) manages all queries. database connections to remote DBMSs. This includes processing requests to open and close database connec- tions as well as performing all the low-level I/O opera- ID1 Organization tions associated with the connections. Within the IDI, As Figure 3 illustrates, there are four main components each database has at most one active connection associ- which comprise the ID1 - the Schema Manager, the ated with it and each connection has zero or more query DBMS Connection Manager, the Query Manager, and result streams or generators associated with it but only the Cache Manager. There are three principal types one generator may be active. The Query Manager (QM) is responsible for process- ’ “IDIL” is pronounced as “idle” and should not be con- ing IDIL queries and managing their results. IDIL fused with “idyll”. queries are processed by translating them into SQL

680 KNOWLEDGEREPRESENTATION are unreliable - critical database relations can be ac- Database cessed in advance to ensure their availability when Declarations needed. I e resuZtts caching - which query results should be saved in the cache? Both base and derived relations vary in their general utility. Some will definitely be worth caching since they are likely to be accessed soon and others not. Q pery generalization - which queries can be usefully generalized before submitting them to the DBMS? Query generalization is a useful technique to reduce the number of queries which must be made against the database in many constraint satisfaction expert systems. It is also a general technique to handle expected subsequent queries after a “null answer” [Motro, 19861. . . . 0 replacement - which relations should be removed when the cache becomes full?

Additional kinds of advice and examples can be found in [O’Hare and Travis, 1989, O’Hare and Sheth, 19891. Figure 3: The IDI includes four main components: the As with any type of cache-based system, one of the Schema Manager manages the schema information for all de- clared databases; the Connection Manager handles connections more difficult design issues involves the problem of to remote DBMSs; the Query Manager is responsible for pro- cache validation. That is, determining when to inval- idate cache entries because of updates to the relevant cessing IDIL queries and their results; and the Cache Manager controls the cache of query results in accordance with the ad- data in the DBMS. Our current implementation does not attempt cache validation, which will be a focus of vice supplied by the application. future research. This still leaves a large class of applica- tions for which cache validation is not a problem. These which is then sent to the appropriate DBMS by the includes access to databases that are write-protected DCM. If the query is successfully executed by the and updated infrequently, such as the Ojg;&l Airline DBMS then the QM returns a generator for the result Guide database, and databases that are static relative relation. A generator is simply an abstract data type to the time scale of the AI application accessing them. used to represent the result of an IDIL query. There are Moreover, this problem is common to any AI system two basic type of operations which may be performed which gets some of its data from an external source and on a generator: (a) get the next tuple from the result stores in its knowledge base. Most current interfaces relation and (b) terminate the generator (i.e., discard between AI systems and databases (e.g. KEE Connec- any remaining tuples). Generators are actually created tion [Intellicorp, 19871) simply do not worry about this and managed by the DCM since there is more than one problem at all. Our approach attempts to minimize possible representation for a result relation, e.g., it may the AI system’s copying of database data in two ways. be a result stream from a DBMS or a cache element. First, by providing convenient and efficient access to The QM merely passes generators to the DCM along the information in the database, the AI system devel- with requests for the next tuple or termination. opers will have less need to make a local copy of the The Cuche Munager is responsible for managing the data. Second, all of the database information that is cache of query results. This includes identifying IDIL copied (i.e., in the cache) is isolated in one place and queries for which the results exist in the cache, caching can therefor be more easily “managed” - reducing the query results, and replacing cache elements. In addi- problem to “cache validation”. tion, our design allows the AI system to provide the There are a number of approaches to the validation cache manager with u&ice to help it decide how to manage its cache and make the following kinds of crit- problem which vary in completeness and ease of im- plementation. Examples of possible components of a ical decisions: cache validation system include: only caching relations (D pre-fetching - which relations (and when) should be declared to be non-volatile, only caching data between fetched in anticipation of needing them? This can scheduled DB updates, using heuristics (e.g., a decay yield a significant increase in speed since the database curve) to estimate data validity, and implementing a server is running as a separate process. This can “snoopy cache” which monitors the database transac- also be used to advantage in an environment in which tions for updates which might invalidate the cached databases are accessed over a network in which links data.

MCKAYETAL. 681 Without Empty Nrazre~‘Y Min Mean Caching Cache

Figure 4: The aggregate processing time is broken down in Figure 5: Cache performance is measured for three cases: terms of the three main stages of processing: translution, ex- (a) the without caching or base-line case where caching was ecution, and coZ2ection. For each processing stage, the mini- disabled, (b) the empty cache case where caching was enabled mum, mean, and maximum processing times are shown. but the cache was cleared before each repetition of the test set, and (c) the non-empty cache case where the cache contained Current Status the results for all queries in the test set. Performance The IDI, as described here, has been implemented in of the relative processing times for each stage could be Common Lisp and tested as a stand-alone query pro- established. cessor against two different databases running on RTI The differences in translation time reflect a depen- INGRES and is also being used as a query server for dence on the number of relations in the IDIL query. the Unisys spoken language project. The performance Similarly, the collection time is a function of the num- results obtained thus far are, at best, preliminary since ber of tuples in the result relation. In both cases, the the size of the test suite was comparatively small and processing times are significantly less than the execu- the ID1 is just now being integrated with an AI system. tion time which is effected by the complexity of the However, the results are encouraging and indicate the SQL query, the communication overhead, and the load potential for efficient database access afforded by the on the remote DBMS host (since only elapsed time was IDI. The following summarize some of the more inter- recorded). esting of these performance results. Figure 5 indicates the effects of result caching on One test set of IDIL queries used consisted of 48 performance. The results represent the mean process- queries where there were 22 unique queries, i.e., each ing times (in seconds) for all queries. Three different query was repeated at least once in the test set. The cases are represented: (a) the without caching or base- queries ranged from simple (i.e., only project and select line case where caching was disabled, (b) the empty operations were required) to complex (i.e., a four-way cache case where caching was enabled but the cache join with two aggregation operations as well as projects was cleared before each repetition of the test set, and and selects). The size of the result relations varied from (c) the non-empty cache c8se where the cache was con- zero to 17 tuples. The statistics presented here are tained the results for all queries in the test set. The based on the mean processing times for 20 repetitions difference between the base-line and empty cache cases of the test set of queries. is due to the number of repeated queries (i.e., 26 out Figure 4 shows a breakdown of the aggregate process- of 48 were repeated). The fact that the base-line case ing time in terms of the three main stages of processing: is more than twice the empty cache indicated that the translation (i.e., the time to translate and IDIL query overhead required for result caching is not significant. into SQL), ezecvtion (i.e., the elapsed time between The non-empty cache case indicates the maximum p

682 KNOWLEDGEREPRESENTATION Application of the ID1 cache Imanager to allow it to make intelligent choices about query generalizations, pre-fetching and replace- Clearly, more detailed performance results need to be ment. We currently have an initial ATIS server running obtained using more exhaustive test sets. It will be and will be collecting statistics on its transactions which particularly important to integrate the ID1 with an AI can then be used to define a effective advice strategy. system and measure its performance with a variety of different applications. We are currently using the ID1 Conclusion to provide a for the Unisys spoken lan- guage understanding system and are investigating the Although the implementation of the ID1 is not com- integration of the ID1 with the Intelligent System Server plete, it does provide a solid foundation for easily cre- and its Protem representation and reasoning engine, ating a sophisticated interface to existing DBMSs. The The ID1 and the ISS. Protem is a hybrid system key characteristics of ID1 are efficiency, simplicity of containing both a frame-based representation system use, and a high degree of portability which make it an and a logic-based reasoning component. The integrrt ideal choice for supporting a variety of AI and related tion of a frame-based representation system with a rela- applications which require access to remote DBMSs. tional database management system is not straightfor- Among the various extensions to the IDI that have ward. Our current approach labels some of the classes been planned for the future, most involve the Cache in the frame system as “database classes”. Any knowl- Manager. At present, the implementation of the CM edge base activity which searches for the instances of has been focused on efficient result caching and most this class will be handed a stream of “database in- other cache management functions have not been im- stances” which will be the result of a query sent to the plemented. One of the first steps will be to impose database via the IDI. In order to avoid filling the knowl- a parameterized limit on the size of the cache and to edge base memory with database information, these in- implement a cache replacement strategy. Other exten- stances are not installed as persistent knowledge base sions to the CM include cache validation, and the abil- objects but exist as “light weight objects” which are ity to perform DBMS-like operations on cache elements garbage collected as soon as active processes stop ex- [O’Hare and Sheth, 19891. amining them. They are also not “fully instantiated”. If the ID1 is extended so that it is capable of perform- That is, the values for the frame’s roles are not neces- ing DBMS-like operations on the contents of its cache sarily installed. Instead, ifan attempt is made to access then, given an IDIL query, it will have three general their roles, additional database queries to retrieve the courses of action which it may take to produce the re- information will generated automatically. Once again, sults: (a) the entire IDIL query can be translated into this information is not added as permanent knowledge SQL and sent to the remote DBMS for execution; (b) base data, but only last as long as the currently active the entire IDIL query can be executed locally by the process is using it. ID1 (including simple retrieval from the cache); and (c) This approach has three advantages: it is relatively the IDIL query can be decomposed so that part of it simple to implement, transparent to the user and is is executed on the remote DBMS and part of it is exe- the key to isolating the data copy problem to cache cuted locally by the IDI. The decision of which action validation as stated earlier. Once the relationship be- to take would depend on a number of factors includ- tween a database class and its database tables is de- ing the current contents of the cache and the estimated clared, the class and its instances can be treated as costs for each alternative. any other knowledge base objects. However, without the ID1 cache implementation, it would be prohibitively References slow. [Abarbanel and Wilhams,1986] R. Abarbanel and M. The ID1 ATIS Server. The second AI system that Williams, “A Relational Representation for Knowledge the ID1 is being used to support is a spoken language in- Bases,“, Technical Report, Intellicorp, Mountain View, terface to an Air level Information System database. CA, April 1986. In this project, spoken queries are processed by a speech [Bocca, 19861 J. Bocca, “EDUCE a Marriage of Conve- recognition system and interpreted by the Unisys Pun- nience: Prolog and a Relational DBMS,” Third Sympo- dit natural language system [Hirschman, et. al., 19891. sium on Logic Progra mming, Salt hlce City, Sept. 1986, The resulting interpretation is translated into a IDIL pp. 36-45. query which is then sent to the ATIS Server for evalua- [Brodie, 19881 M. Brodie, uFutu.re Intelligent Informa- tion. This server is a separate process running the ID1 tion Systems: AI and Database Technologies Working which, in turn, submits SQL queries to an INGRES Together” in Readings in Artificial Intelligence and database server. Databases, Morgan Kaufman, San Mateo, CA, 1988. The utravel agent” domain is one in which there is a [Ceri, et. al., 19861 S. Ceri, G. Gottlob, and G. Wiederhold, rich source of pragmatic information that can be used “Interfacing Relational Databases and Prolog Efficiently,” to infer the user’s intentions underlying their queries. Proc. of the 1st Intl. Conf. on Expert Database Systems, These intentions can be used to generate advice to the South Carolina, April 1986.

MCKAY ET AL. 683 [Chakravarthy, et. al., 19821 U.. Chakravarthy, J. Minker, Management System,” in Proceedings of the 12th In- and D. Tran, “Interfacing Predicate Logic Languages ternational Conference on Very Large Databases, Kyoto, and Relational Databases,” in Proceedings of the First Japan, 1986. International Logic Programming Conference, pp. 91-98, [Li, 19841 D. Li, A Prolog Database System, Research Stud- September 1982. ies Press, Letchworth, 1984. [Chamberhn, et. ah, 19761 D. Chamber&n, el al.. ‘SE- [Minker, 19781 J. Minker, “An Experimental Relational QUELZ: A Unified Approach to Data Definition, Manip- Data Base System Based on Logic,” in Logic and ulation, and Control”, IBM Journal of R&D, 20, 560-575, Databases, ed. J. Minker, Plenum Press, New York, 1978. 1976. [Morris, 19881 K. Morris, J. Naughton, Y. Saraiya, J. Ull- [Chang, 19781 C. Chang, “DEDUCE 2: Further investiga- man, and A. Van Gelder, “YAWN! (Yet Another Window tions of deduction in relational databases,” in Logic and on NAIL!),” IEEE Data Engineering, vol. 10, no. 4, De- Database+ ed. H. Gallaire, pp. 201-236, New York, 1978. cember 1987, pp. 28-43. [Chang and Walker, 19841 C. Chang and A. Walker, [Motro, 19861 Amihai Motro, UQuery Generalization: “PROSQL: A Prolog Programming Interface with A Method for interpreting Null Answers”, in Ex- SQL/D&” Proc. of the 1st Intl. Workshop on Expert pert Database Systems, ed. L. Kerschberg, Ben- Database Systems, Kiawah Island, South Carolina, Octo- jamin/Cummings, Menlo Park CA, 1986. ber 1984. [Naish and Thorn, 19831 L. Naish and J. A. Thorn, “The [Chimenti, et. al., 19871 D. Chimenti, A. O’Hare, R. Krish- MU-Prolog Deductive Database,” Technical Report 83- namurthy, S. Naqvi, S. Tsur, C. West, and C. Zaniolo, 10, Department of Computer Science, University of Mel- “An Overview of the LDL System,” IEEE Data Engi- bourne, Australia, 1983. neering, vol. 10, no. 4, December 1987, pp. 52-62. [O’Hare, 19871 A. O’Hare, Towards Declarative Control [Dahl, et. al., 19901 D. Dahl, L. Norton, D. McKay, M. of Computational Deduction, University of Wisconsin- Linebarger and L. Hirschman, “Management and Evahra- Madison PhD Thesis, June 1987. tion of Interactive Dialogue in the Air Travel Information [O’Hare, 19891 A. O’Hare, uThe Intelligent Database Inter- System Domain”, submitted to The DARPA Workshop face Languagen, Technical Report, Unisys Paoli Research on Speech and Natural Language, June 2427,1990, Hid- Center, June 1989. den Valley, PA. [O’Hare and Sheth, 19891 A. O’Hare and A. Sheth, “The [Finin, et. al., 19891 Tim Finin, Rich Fritzson, Don Mckay, interpreted-compiled range of AI/DB systems”, SIGMOD Robin McEntire, and Tony O’Hare, “The Intelligent Sys- Record, 18(l), March 1989. tem Server - Delivering AI to Complex Systems”, Pro- ceedings of the IEEE International Worbhop on Tools [O’Hare and Travis, 19891 A O’Hare and L. Travis, “The for Artificial Intelligence - Architectures, languages and KMS Inference Engine: Rationale and Design Objec- AZgorithms, March 1990. tivesn , Technical Report TM-8484/003/00, Unisys - West Coast Research Center, 1989. [Fritzson and Finin, 19881 Rich Fritsson and Tim Finin, “Protem - An Integrated Expert Systems Tool”, Tech- [O’Hare and Sheth, 19891 Anthony B. O’Hare and Amit nical Report LBS Technical Memo Number 84, Unisys Sheth. The architecture of BrAID: A system for efi- Paoli Research Center, May 1988. cient AI’DB Integration. Technical Report PRC-LBS- 8907, Unisys Paoli Research Center, June 1989. [Hirschman, et. al., 19891 Lynette Hirschman, Martha Palmer, John Dowding, Deborah Dahl, Marcia [Reiter, 19781 R. Reiter, UDeductive Question-Answering Linebarger, Rebecca Passonneau, Fransois-Michel Lang, on Relational Data Bases,” in Logic and Databases, ed. Catherine Ball, and Carl Weir. The pundit natural- J. Minker, Plenum Press, New York, 1978. language processing system. In AI Systems in Gotrem- [Sheth, et. al., 19881 A. Sheth, D. van Buer, S. Russell, and ment Conference. Computer Society of the IEEE, March S. Dao, “Cache Management System: Preliminary Design 1989. and Evaluation Criteria,” Unisys Technical Report TM- 8484/000/00, October 1988. [Intellicorp, 19871 Intellicorp, “KEEConnection: A Bridge Between Databases and Knowledge Bases”, An Intel- [Stonebreaker, et. al., 19871 M. Stonebraker, E. Hanson licorp Technical Article, 1987. and S. Potamianos, UA Rule Manager for Relational Database Systems,” in The Postgres Papers, M. Stone- [Ioannidis, et. al., 19881 Y, Ioannidis, J. Chen, M. Fried- braker and L. Rowe (eds), Memo UCM/ERL M86/85, man, and M. Tsangaris, “BERMUDA - An Architec- Univ. pf California, Berkeley, 1987. tural Perspective on Interfacing Prolog to a ,” Proceedings of the Second International Con- [Van Buer, et. al., 19851 D. Van Buer, D. McKay, D. Ko- ference on Expert Database Systems, April 1988. gan, L. Hirschman, M. Heineman, and L. Travis, “‘The Flexible Deductive Engine: An Environment for Proto- [Jarke, et. al., 19841 M. Jarke, J. Clifford, and Y. Vassiliou, typing Knowledge Based Systems,” Proceedings of the “An Optimizing Prolog Front-End to a Relational Query Ninth International Joint Conference on Artificial Intel- System,” Proceedings of the 1984 A CM-SIGMOD Con- Zigence, Los Angeles CA, August 1985. ference on the Management of Data, Boston, MA, June 1984.

[Kellog, et. al., 1986] C. Kellogg, A. O’Hare, and L. Travis, “Optimizing the Rule/Data Interface in a Knowledge

684 KNOWLEDGEREPRESENTATION