Mathl. Comput. Modelling Vol. 16, No. 617, pp. 137-144, 1992 Printed in Great Britain All rights reserved

9895-7177192 $5.clcl+ 0.00 Copyright@ 1992 Pergamon Press Ltd

CENTRAL KNOWLEDGE MANAGEMENT FOR EXPERT SYSTEMS

STEVEN SALVINI AND M. HOWARD WILLIAMS

Department of Computer Science, Electrical and Electronic Engineering

Heriot-Watt University, 79 Grassmarke.t, Edinburgh EHl 2HJ, Scotland

Abstract-The position of the knowledge base management system in relation to expert systems ls analogous to that of the database management system in relation to standard applications. Just as database management systems provide facilities to store and manipulate data for user applications, so knowledge base management systems provide facilities to store and manipulate knowledge for user

knowledge-based or expert systems. A number of different approaches have been taken in trying to build prototypes of knowledge base management systems. One such approach is to extend an exist- ing deductive database, and one such prototype system is described. An associated demonstration

application from the domain of dentistry is examined, to show the practical use of the system and its utility in knowledge sharing.

1. INTRODUCTION

Just as the database management system (DBMS) was a product of the increased use of data- intensive applications in the 70’s, so the idea of a knowledge base management system (KBMS) is becoming more and more important as the investment in expert systems continues to rise. Not only is the number of expert systems in regular use continuing to grow at a rapid pace, but also the size of the knowledge base is increasing. This leads to the need for reliable and efficient facilities for the storage and manipulation of knowledge.

A number of strategies for building KBMSs are being prototyped. This includes work being done on deductive databases [1,2], object oriented databases [3,4], and on providing specialised hardware for knowledge bases [5]. This paper is concerned with work developed on deductive databases, as these are well-suited to providing a starting point for building KBMSs.

A deductive database is a database system based on first order logic, in which is stored a

collection of clauses. These clauses include facts (which correspond to the explicit tuples in a relational database) and rules (which can be used to generate implicit tuples). Thus, if a retrieval query selects a set of tuples satisfying some condition, the tuples which are produced may be any combination of explicit and implicit tuples.

Since a deductive database stores as objects a set of clauses, it must provide facilities to insert, delete and update these clauses. This facility provides the basis for building a KBMS in that the rules of an expert system may be expressed as clauses and stored in the deductive database, and then retrieved as objects when required,

While a deductive database system has an inbuilt inference mechanism for deriving implicit tuples from rules, this is not sufficient to replace the inference mechanism within an expert system, particularly since each expert system has its own characteristic variations in this regard. Thus, the deductive database merely acts as a repository for the knowledge required by the expert systems, storing and retrieving it as required.

The dental knowledge bases used in this project were developed in conjunction with Dr. Denis F. Kinane of the Department of Oral Medicine and Pathology, University of Glasgow, to whom we are greatly indebted for his time and patience. This work was partly funded under the Alvey initiative (R-LPI 085), and the authors wish

to acknowledge both this support and that from our industrial “uncle,” ICL. Finally, we should llke to express our gratitude to the other members of the Heriot-Watt University Logic Database Group for their help in the preparation of this paper.

Typeset by A&-‘QX

137

138 S. SALVINI. M.H. WILLIAMS

However, one important property of a database is that it facilitates sharing of data among applications. This means that several different applications may wish to use the stored set of data, and the system will deliver to each the data it requires in the form in which it needs it. This avoids duplication of data (and the problems of maintaining several copies of the same data) and the attendant problem of inconsistency which may arise if all copies of the same data are not updated correctly and at the same time.

This property is important in a knowledge base management system too. If one has one or more expert systems which make use of the same knowledge, one would like this knowledge to be stored as a single copy, so that any changes to it will be consistently transmitted to all expert systems which make use of it. Thus if one expert system has rules which determine whether or not a particular patient is likely to be vulnerable to a given infection, and another expert system has rules for determining whether or not a particular patient is a compromised host, it can readily be seen that a number of these rules will overlap. It would seem very worthwhile to be able to store all the rules in a central knowledge store, with only a single instance of each of the overlapping rules being stored and with the rules being made available to the user expert systems in whatever format they require.

This paper describes a system which has been developed to provide a shared knowledge capa- bility within the Logic Database Management System (LDBMS) [S].

2. ARCHITECTURE

The system is based on the LDBMS, which is a deductive database with a query language, SQUIRREL [7], h’ h w ic can handle rules and facts. SQUIRREL is a superset of IS0 standard SQL [8], and treats the SQL tables as comprising tuples derived either from facts explicitly stored in the database, or generated by the application of rules describing the tuples. It can be used to retrieve either the tuples themselves in a manner identical to traditional relational systems, or the facts and rules describing relations. Rules stored via SQUIRREL may be treated as “active” or “passive” rules. Rules are considered active when used to generate tuples in answer to a query; rules are passive when they are retrieved as objects in their own right. Normally, any rule in the logic database will be addressable in both modes; however, for the purposes of a KBMS, some rules can be treated as being passive-only rules. This means that they are stored in the normal way but are never fired.

The LDBMS is written in Prolog-X+ [9], a Prolog optimised for database applications, and closely linked to the CRS/CLARE (Clause Retrieval Server/CLAuse Retrieval Engine) system for efficient clause manipulation and storage.

Although SQUIRREL provides facilities for the manipulation of rules and facts, this is only possible providing that those rules and facts are in the standard format required by this query language. To overcome this restriction, a special interface was developed, which is referred to as the Expert System Interface (ESI) [2].

The ES1 makes available two groups of functions. On one hand, it provides knowledge engineers with facilities to manipulate the schemata associated with particular expert systems, and to enter knowledge bases into the LDBMS. On the other, it provides commands which can be directly incorporated in the code of user expert systems; for example, to retrieve a set of rules.

A knowledge engineer must set up schemata for expert systems because different expert system acting as users of the KBMS need not actually see all the knowledge contained in the virtual knowledge base. Whilst in the literature on KBMSs, it is usually assumed that all the knowledge in the KBMS should be available to all user expert systems by “knowledge sharing” (for exam- ple, [lo]), it would seem likely that such an approach may not be ideal in practical situations. Just as in the DBMS situation where, for example, it is usual to be able to restrict a video display unit (vdu) operator from seeing the salary of his or her superiors, so it would seem necessary to be able to also restrict that vdu operator. Perhaps a better description of the approach taken is “knowledge restriction,” rather than knowledge sharing.

This effect is achieved by each expert system having an associated schema in which its rules and facts are stored. In other words, each expert system is treated as a “user” in the usual database terminology. By granting the appropriate access privileges to an expert system (or

Central knowledge management

(5J @J

\ \ ,I \ \ ,I h L”

ES1 Command Processor Engincning

4 - Intiace

I a

139

external -> ESKIR

I I

ESKIR -> external

I I I

V I

Query Constructor Result Interpreter

ESI/LDBMS

Interface

I I I I I I f I Logic Database System I I I : I I

I :__________________________________J

Figure 1. ES1 architecture.

group of expert systems) on relations owned by other expert systems, it is possible to implement knowledge sharing in a secure manner. Three categories of knowledge can be identified in the KBMS:

(a) common knowledge which is available to any user expert system; (b) shared knowledge which is available to a group of expert systems; and (c) knowledge private to the owner expert system.

This simple concept is illustrated in Figure 2.

Once a knowledge engineer has set up the appropriate schema or schemata, he must then alter the code of the expert system which is to use the KBMS for knowledge storage. The

140 S. SALVINI, M.H. WILLIAMS

Expert System 1

Exped System 2 &pelt System 3

Figure 2. An illustration of the possible overlap of knowledge from three different expert systems.

alterations consist of changing the program, so that ES1 commands are used for accessing and manipulating knowledge. Commands are available to insert, delete and retrieve rules and facts, and for other purposes such as to identify a user expert system to the ESI. One such command is “insert-e”. This takes one parameter, an expert system rule, and inserts this into the appropriate schema for the owner expert system, creating any required tables both for the rule itself and any sub-parts of the rule, and automatically sets up the appropriate permissions on these for any other systems which have been granted use of this system’s knowledge.

These commands are designed to be as simple as possible, and to impose as little overhead on the knowledge engineer as possible. They greatly simplify the interface to the knowledge store by removing the necessity for any direct interaction between knowledge engineer or user expert system and the underlying SQUIRREL query language, as well as insulating from the internal knowledge representation format, (ESKIR [ll]) used in the system. They take as parameters objects and concepts from the user expert system’s own knowledge representation format and automatically transform these into the required knowledge representation format for the LDBMS. This transformation is a major part of the ESI’s functionality, and is considered fundamental to the acceptability of any KBMS, since it removes the need for a knowledge engineer to restrict himself to a given system for reasons of compatibility of knowledge representation format and also allows a wide range of pre-existing systems to be used with the KBMS.

The transformation of rules and facts and their sub-parts (for example, as selection criteria in retrieval queries) is carried out semi-automatically by means of a translator-generator system which is initially configured by the knowledge engineer providing a BNF description of his expert system’s knowledge representation format.

3. DENTAL APPLICATION

To demonstrate the potential of the KBMS, a system was developed for the domain of dentistry, building on previous experience gained in this area [12].

The system was intended to form the first step towards developing a complete expert system competent in all the specialties of dentistry. It was decided to begin by concentrating on a subset of Periodontology, namely, the diagnosis of dental pain, as this had already been investigated in part [ll] in earlier work, and then to construct a new expert system for use in Restorative Dentistry. This second system is concerned with the selection of therapy in the form of the correct bridge, partial denture or crown for a particular patient. Each expert system was built using a different expert system shell with different knowledge representation formats.

Whilst constructing the knowledge base for the periodontal expert system, rules were formed with the help of an appropriate dental expert clinician, concerning the development of a num- ber of conditions including, for example, dental abscesses. Many of these were dependent on information about the anatomical structure of the mouth. For example, the rules might describe

Central knowledge management 141

Shared Privale

_______________---------

KBMS

Figure 3. Schematic showing the relative overlapping of the knowledge for the dental application. The dotted lines represent the creation of the patient record from the information gathered by the patient record manager and the user interfaces of the two expert systems.

the hypothesis that pain due to a certain type of dental abscess is most common in or near the molars (i.e., the rear-most teeth). In a similar way, when working on the knowledge base for the restorative dentistry system, it became clear that there were a number of rules which required rules and facts describing the oral cavity itself. For example, in forming rules to represent the criteria for the selection of suitable teeth to act as abutments to hold bridges, the anatomical relationships must be very clearly described.

There were many similar areas of overlap, for example, rules concerned with the description of pain were common to both rule sets, and two strategies were used to handle this feature. By careful study of the two emerging rule bases, it became clear that to simplify the construction of the two expert systems, it would be useful to utilise the marked overlap of knowledge required about the positions of anatomical structures and lesions by developing a third system, the Oral Model (OM).

The Oral Model is a component-based central knowledge base whose knowledge is available to either user expert system. It contains deep knowledge in the form of facts and rules about the anatomy and physiology of the teeth and soft tissues of the oral cavity and about their inter-relationships. It also contains those shallow rules which are common to more than one user expert system, and rules to carry out translations such as from exact data values to more general statements or from the terminology of one speciality to that of another. For example, as noted above, the description of the position of the teeth is important in both expert systems although the fineness of description differs. In the restorative system, the positions must be more accurately described, as the clinician is trying to physically fit prostheses onto the teeth themselves, whereas in the periodontal system the position is often only important to locate the source of the pain in general terms in the history. Looking ahead to possible future additional expert systems required to develop a knowledge based system for a wide range of dental specialties, in Dental Prosthetics the description of the orientation and spatial relationships of the dentition must be even more accurate still. This means that if a patient ha.+ already consulted the prosthetics department the case records may already contain very detailed reports of the dentition, for example, from measurements taken from dental x-rays. If this information was held in the KBMS, it would seem futile to then ask a clinician to re-examine the patient to obtain what is in essence a less- detailed description of the patient’s mouth on consulting the restorative department. Rather than provide completely different rule sets for each system, it would appear that a cleaner approach is to provide a translation ruleset to carry out the conversion from the information already held about the patient to the level of detail required by a calling expert system.

142 S. SALVINI, M.H. WILLIAMS

The second strategy employed was to rely solely on the facilities of the KBMS to deal with the sharing of the many other rules which were common to both of these expert systems, but which would be unlikely to overlap with future components of the system quite so markedly. Thus, these rules were retained in the original expert systems’ knowledge bases and, when these knowledge bases were added to the central knowledge store, the KBMS facilities were used to allow the sharing of a single representation of each of these rules by the two systems involved.

Whilst this sharing of knowledge was to some extent expected, the fact that certain rules would require to be stored so that they could not be shared had been less apparent initially. These rules tended to involve terminology for which there was no common definition in the different specialties.

A separate module, the Patient Record Manager (PRM), performs a basic clerking function common to most dental specialties to produce a patient record with reference to the data in the OM.

The Oral Model Manager allows the user to inspect the oral model just as the PRM allows interrogation of the state of the current patient record.

Some example rules from the expert systems and the oral model showing the various degrees of sharing possible are as follows:

1. Common Rule-held in the oral model and used by the oral model and both expert systems:

If total width of teeth in arch is greater than the total width of the arch, then there is crowding present in this arch.

Example use by a rule in the restorative expert system:

If there is crowding present in this arch, then teeth can act as abutments for missing teeth, having up to a maximum of twice the

number of roots they themselves have.

Example use by a rule in the pain diagnosis expert system:

If there is crowding present in this arch, and the tooth in question is not virgin and it has a polished high-spot,

then there is strong evidence that the tooth may be pulpitic.

2. Shared Rule-held in the oral model and used by the oral model and the restorative expert system only:

If the 7 is missing and the 8 on the same side has erupted and

is present, then this 8 may function as a pseudo-?.

Example use by a rule in the restorative expert system:

If the 8 was functioning as a pseudo-y, and the 8 is extracted and the 6 on the same side

is present, then the appliance of choice is a Free Fixed Bridge for the 7 and 8.

3. Oral Model Fact-held in the oral model and used by the oral model and, thus, indirectly by both expert systems:

Fact: the 8 on either side and on either arch is a molar.

Example use by a rule in the pain diagnosis expert system:

If the tooth is tender to percussion and it is either a molar or a pre-molar, then there is strong evidence that there may be an associated abscess present.

The system operates as follows. Independent of which expert system the user opts to use, the PRM is run first to gather the basic information about the patient (i.e., name, age, sex, etc.), and create a patient record which it stores in the LDBMS. The appropriate expert system then uses the information in the patient record, the oral model and any additional information it may request from the user, which is also added to the patient record via the PRM. The knowledge bases of both expert systems, the oral model, and the patient record are all stored in the LDBMS. As noted above, for each expert system, some of the information is Private (i.e., can be accessed from the LDBMS only by that expert system), some is Shared (i.e., is held as part of the OM in

Central knowledge management 143

the LDBMS and is available only to expert systems or the OM), and some is Common (i.e., is held as part of the OM in the LDBMS and is available to either expert system and the OM).

All the interactions described here between the expert systems and OM on the one hand, and the LDBMS on the other, are handled by the ESI. Thus the user expert systems see the ESI/LDBMS combination as a single KBMS and at no time are required to use the LDBMS SQL-based interface directly.

4. CONCLUSIONS

The concept of a KBMS is regarded as important for the future. The main reason for this is the increasing size and complexity of the knowledge bases of current knowledge-based systems [13] and the proliferation of knowledge-based and expert systems themselves. For example, Stachowitz reports that by 1995 it is expected that KBMSs will handle lo6 rules although the Japanese are discussing rulebases of log rules [14]. Recognising its importance, it formed one of the key elements in the architecture of the Fifth Generation Computer Systems presented by the Japanese [15,16].

It is expected that KBMSs will make use of some of the ideas and techniques of DBMSs. How- ever, they may also raise new problems such as those arising from the authorisation requirements for knowledge stored in large shared knowledge bases. Whilst it is important that applications be able to share knowledge, it is equally important that certain knowledge can be hidden from certain applications or users. This is a similar problem to that encountered in DBMS, but with the additional difficulties posed by constraining access to knowledge generated through rules.

This paper has described one approach to providing some of the services of a full KBMS. This approach concentrates on providing the facilities of an underlying logic database to user expert systems, without requiring these users to make use of one fixed knowledge representation language imposed by the system. Rather, a user expert system retains its original knowledge representation format and any translations required between it and the underlying internal format are carried out automatically by the ESI. This has disadvantages in that it is not yet clear how to handle the representation of different uncertainty-handling mechanisms in a uniform manner, and also in the amount of knowledge format translation required; but it is thought that these will be offset in the long term by the advantages of the knowledge engineer having less to learn, and also by permitting the incorporation of existing expert systems within the KBMS rather than just systems written de novo with its use in mind.

The example from the domain of dentistry has shown the application of these ideas in a practical setting, and its construction has helped clarify some of the issues regarding knowledge sharing.

REFERENCES

1. J. Minker, Perspectives in Deductive Databases, Jovrnal of Logic Programming 5 (l), 33-60 (1988). 2. S. Sal&i and M.H. Williams, Towards a knowledge base management system, Technical Report TFl89612,

Department of Computer Science, Heriot-Watt University, Edinburgh, (1989).

3. G. Copeland and D. Maier, Making Smalhalk a database system, In Proceedings SZGMOD Conference, Boston, 1984, (Edited by P.A. Bernstein), pp. 52-59, ACM, Boston, (1984).

4. J. Banerjee, H.-T. Chou, J.F. G-, W. Kim, D. Woelk, N. Ballou and H.J. Kim, Data model issues for object-oriented applications, ACM Transactions on O&e Information Systems 5 (l), 3-26 (1987).

5. D. McGregor, S. McInnes and M. Henning, An architecture for associative processing of Large Knowledge Bases (LKBs), Computer Journal 22 (4), 32-37 (1987).

6. M.H. Williams, G. Chen, D. Ferbrache, P. Massey, S. Sal&i, H. Taylor and K.F. Wong, Prolog and deductive databases, In Knowledge-Based Systems, pp. 188-192, (June 1988).

7. K.G. Waugh, M.H. Williams, Q. Kong, S. Salvini and G. Chen, Designing SQUIRREL: An extended SQL for a deductive database system, Computer Journal 33 (6), 534-546 (1990).

8. ISO, Database Language SQL, IS0 9075-1987(E), International Standards Organisation, Geneva, (1987). 9. M.H. Williams, P.A. Massey and J.A. Crammond, Benchmarking Prolog for database applications, In Prolog

and Databases: Zmplementaiiona and Directions, (Edited by P.M.O. Gray), pp. 161-187, Ellis-Horwood Limited, Aberdeen, (1988).

10. F. Manola and M.L. Brodie, On knowledge bssed systems architectures, In On Knowledge Bare Management Systems, (Edited by M.L. Brodie and J. Mylopoulos), pp. 87-92, Addison-Wesley, Cambridge, (1986).

11. S. Salvini and A.J. Gammerman, PROTEST: A prototyping tool for knowledge engineering, In Proceedings of Medical Znjormatics Europe ‘87, (Edited by A. Serio, R. O’Moore, A. Tardini, P.H. Roger), pp. 1030-1035, M.I.E. 87 Organizing Secretariat, Borne, (1987).

144 S. SALVINI, M.H. WILLIAM

12. S. Salvini, A prototyping tool for expert systems, M.Sc. Dissertation, Heriot-Watt University, Edinburgh, (1986).

13. D. Lenat, M. Prakash and M. Shepherd, CYC: Using common sense knowledge to overcome brittleness and knowledge acquisition bottlenecks, AI Magazing 6 (4), 65-85 (1966).

14. M.L. Brodie, R. Balzer, G. Wiederhold, R. Bra&man and J. Mylopoulos, Knowledge base management systems: Discussions from the working group, In Expert Database Systems, (Edited by L. Kerschberg), pp. N-33, Benjamin Cummings, South Carolina, (1986).

15. K. Murakami, T. Kakuta and R. Onai, Architectures and hardware systems: Parallel inference machine and knowledge base machine, In Proceeding8 of the International Conference on Fifth Generation Computer Systems, Tokyo, November 1984, pp. 119-127, JCOT, Tokyo, (1984).

16. K. Furukawa and T. Yokoi, Basic Software System, In Proceedings of the International Conference on Fiffh Generation Computer Systems, Tokyo, November 1984, pp. 169-177, ICOT, Tokyo, (1984).