ON KNOWLEDGE BASE MANAGEMENT SYSTEMS

This position statement examines briefly the purpose, nature and impact of Knowledge Base Management Systems and outlines a comparison with Database Management Systems. This position statement briefly examines the purpose, nature, and impact of Knowledge-Base Management Systems (hereafter KBMSs), and outlines a comparison with Database Management Systems (DBMSs). The background for this statement can be found in [MYL080], which sketches research on Knowledge Representation and its applications to databases carried out at the University of Toronto since 1975; also in [BM85] and [BROD85a] which discuss some of the underlying premises of this research. Our-long term objective has been to establish a new technology for software development. We assume that this software will include programs as well as databases (“persistent data”) and that it might or might not provide sophisticated interpretation capabilities (see the chapter by Szolovits) of the kind associated with so-called expert systems. Our basic premise has been that software development can be usefully viewed as a knowledge-base construction task. KBMSs are intended to provide the representational framework and the computational environment for carrying out this task. By analogy to DBMSs, we see the main purpose of KBMSs as being to facilitate the management of large, shared knowledge bases. At the same time, we see a number of major differences between DBMSs and KBMSs: I University of Toronto, and Senior Fellow, Canadian Institute for Advanced Research 4 Knowledge Base Management Systems • The former make a clear distinction between “generic” knowledge, incorporated in the schema, and “ground” knowledge that is included in the database. Moreover, the schema is constructed by designers during the database design phase, while the database is constructed and accessed by end users during the production phase. For KBMSs, the distinction between “generic” and “ground” knowledge disappears (or becomes a concern only during “physical design,” i.e., when an efficient version of the knowledge base is generated for a production environment). • The functions offered by DBMSs (query languages, report generators, etc.) concentrate on the end users and their needs. On the other hand, KBMSs focus on the needs of the knowledge-base designer. In fact, it makes more sense to think of a KBMS as a prototyping facility for a particular kind of software (a knowledge base) than as a facility that offers efficient and robust management of large databases.2 • As a consequence of the previous point, a KBMS, unlike a DBMS, should provide facilities for physical design through which efficient code can be generated once one is satisfied that the knowledge base is epistemologically adequate. A second area of comparison between DBMSs and KBMSs concerns their features. Both types of system need to address the issues of sharing by concurrent users, error recovery, and efficient access to information stored on primary and possibly secondary memory on one or several machines. For KBMSs, however, reasoning facilities need to be provided, which subsume aspects of deductive and abductive reasoning.3 In addition, explanation facilities are needed, to allow a user of the knowledge base to find out the state of the reasoning process, to offer advice, and to get justification for a particular conclusion reached by the system. Considering that an important goal of the KBMS user is to generate a piece of software for a production environment, implementation facilities need to be provided as well. These should support the interactive generation of conventional software (e.g., COBOL code) 2 If the KBMS is not intended to provide interfaces for the end user, it is fair to ask what does. An interesting possibility is to include in the KBMS framework facilities for representing lexical, grammatical, and pragmatic knowledge as well, so that one can generate a piece of software and its user interfaces. [PIL0831 provides an initial exploration of such an alternative. 3 The latter involves inferences of the type I! If A implies Band B has been observed, hypothesize AI! which are particularly useful for expert systems dealing with a diagnostic or other interpretation task. On Knowledge Base Management Systems 5 from a given knowledge base, taking into account issues of efficiency and robustness all-important in a production environment. The chapter by larke briefly sketches a well-thought-out framework for carrying out this “compilation” of a knowledge base. An interesting aspect of this proposal is that it takes a strong stand on the linguistic levels relevant to this transformation from knowledge bases to “code”, and on the features these levels should support. The starting point in designing a DBMS is to choose the data model that will be supported (Le., the data structures and operations to be used to store and operate on a database). A similar claim can be made for the design of a KBMS where the starting point is the knowledge-representation framework to be offered to the designer of a knowledge base; in other words, the nature of the units constituting a knowledge base. There are two sets of issues that need to be addressed by any such framework. Firstly, the framework should be descriptively adequate, allowing, among other things, for representing and reasoning with respect to negation, disjunction, and quantification. Secondly, since the knowledge bases to be developed may be large, a knowledge representation framework must support organizational principles, in the same sense that programming languages support program structuring principles intended to help the programmer in structuring a program. Candidates for such principles include generalization, aggregation, and classification, already used extensively in knowledge-representation languages and semantic data models. New principles are also included, such as: 1. Projection: This is intended to capture the semantic relationship between a physical object and its projection on some plane, or between a physiological event (e.g., a heart beat) and its projection on some medium (e.g., an ECG signal), or even a data structure with associated operations (e.g., a linked list along with push and pop operations) and its projection into an abstract plane (e.g., where the linked list may be viewed as a pushdown stack). Versions of this abstraction mechanism are used in [SHIB85] and [RICH82]. The mechanism also bears some resemblance to data abstraction as used in programming languages [LZ74b]. 2. Exceptions: Knowledge is viewed with respect to this dimension as a multilayered structure of rules, exceptions to the rules, exceptions to the exceptions, etc. It is important to note that exception handling constitutes an essential feature of any software development technology intended for flexible software systems. The proposals outlined in [BORG85b] can serve as a basis for the introduction of such an organizational dimension. 3. Reflection: “Control” knowledge (i.e., knowledge about the reasoning process itself rather than domain knowledge), has been a 6 Knowledge Base Management Systems topic of interest and importance in expert-system research. This dimension of knowledge organization would allow one to organize a knowledge base depending on whether it represents domain knowledge, knowledge about reasoning with respect to domain knowledge, knowledge about reasoning about reasoning with respect to domain knowledge, etc. [SMIT82] and [KRAM86] are just two examples of proposals for reflection mechanisms that would allow a system to “reflect” about its own state, goals, achievements, etc. 4. Relativity: By and large, present-day knowledge bases assume that there exists an objective view of the domain, and that differences in viewpoints (e.g., different accounts about how a hospital operates), can be resolved before knowledge is added to the knowledge base. Unfortunately, this is a naive view which is violated by many applications where large amounts of knowledge from many different sources are relevant. Well-accepted mechanisms for knowledge-base s.tructuring, such as contexts/partitions, [HEND75], are too simple-minded to deal with the complications that arise from the co-existence of multiple viewpoints within one knowledge base. Recent work within the OMEGA project [HEWI85b] includes a powerful notion of “viewpoint” which seems a more appropriate starting point towards a structuring mechanism that provides an adequate treatment of subjectivity in knowledge bases. This is necessarily a partial list of candidate mechanisms for knowledge organization. In closing this topic, it is important to stress that the organizational mechanisms supported by a particular knowledgerepresentation framework must assume that the units being organized are, in fact, representations of knowledge, rather than text, rules, program segments, or data structures. Also, to emphasize that the knowledge engineer needs structuring facilities permitting the structuring of a (large) knowledge base as much as software engineers, for their part, are concerned with the construction of (large) programs. DBMSs already exist, and are widely, and successfully, used. An important methodological question is whether we should treat them as starting points and move in an evolutionary fashion towards KBMSs4. Likewise, one can begin with existing environments for building expert systems like KEE and LOOPS5, and add to them features such as efficient use of secondary storage, concurrency control, error recovery, and query optimization. This is clearly a correct strategy for research 4 Semantic Data Models, including Prolog-related ones, seem to have been doing just that. 5 A more complete list of such environments can be found in [BM851. On Knowledge Base Management Systems 7 and development work with a relatively short-term outlook. An alternative, revolutionary, approach begins with a knowledgerepresent