PII: 0950-7051(88)90071-8 Socrates: a flexible toolkit for building logic-based expert systems R Corlett*, N Davies*, R Khan*, H Reichgeltt and F van Harmelent This paper describes the architecture o f the Socrates tool- kit ./'or building expert systems. The authors analyse the problems associated with existing expert system tools and propose a solution based on the use o f logic and meta-level inference. The abstract architecture f o r the toolkit is described which embodies this combination o f logic and meta-level inference. This architecture can be instantiated to create a system that is specialized for a particular application. This specialization process can be seen as a methodology f o r building expert systems. The three stages o f this methodology are discussed in detail, along with descriptions o f how the Socrates toolkit supports it. The current implementation o f Socrates, plus a number o f applications o f the toolkit are described, and the open problems are discussed. Keywords: expert systems, toolkit, architecture, building methodology Most o f the tools that are currently available for constructing expert systems fall into two categories, namely expert system shells and high level programming language environments. Both o f these types o f tool suffer from a number o f shortcomings which limit their useful- ness. The first type o f available tools, 'shells', are usually constructed by abstraction from an existing expert system. Thus, a shell normally consists o f an inference engine and an empty knowledge base, and some de- bugging and explanation facilities. Buyers o f a shell often believe, and manufacturers often claim, that the shell is appropriate for a number o f different applications. However, a large number o f people have expressed dis- satisfaction with expert system shells. The two most frequently heard complaints (e.g. A l v e y ' ) are first, that the view that the inference engine which was successful *GEC Research, Marconi Research Centre, Chelmsford, UK tDepartment of Artificial Intelligence, University of Edinburgh, Edinburgh EH8 9YL, UK 0950-7051/88/030132-11 $03.00 © 1988 132 in one application will also be successful in other applications is unwarranted, and second, that the knowledge representation scheme often makes the expression o f knowledge in another d o m a i n awkward, if not impossible. F o r example, a production rule language that was designed for solving a classification problem using backward chaining would probably not be very suitable for solving a design or planning problem. On the other hand, proponents o f high level program- ming language environments (sometimes known as 'hybrid systems'), such as LOOPS 2, K E E 3 or A R T 4, can be seen as taking a more pluralistic position: instead o f providing knowledge engineers with a single pre- fabricated inference engine, one provides them with a large set o f tools, each o f which has proven useful in other applications. LOOPS, for example, provides object-oriented programming with inheritance, a pro- duction rule interpreter and active values, as well as Lisp. While we accept that hybrid systems are useful as tools for program development, we would claim that they are less useful as tools for building expert systems. Their main problem is that they provide the knowledge engineer with a bewildering array o f possibilities, and little, if any, guidance as to the circumstances in which any o f these possibilities should be used. Unless used by experienced programmers, high level programming environments encourage an ad hoc programming style in which no attention is paid to a principled analysis o f the problem at hand to see which strategy is best suited for its solution. The conclusion that is drawn from the problems associated with shells and high level programming language environments is that a number o f different "models o f rationality' are needed, and that different applications require different models o f rationality. When constructing an expert system, the knowledge engineer then has to decide which model o f rationality is appropriate to the application at hand. A model o f rationality has both a 'static' and a 'dynamic' aspect. These two aspects correspond to the knowledge about Butterworth & Co (Publishers) Ltd Knowledge-Based Systems the application area plus a strategy that describes how to use this knowledge when solving a problem. The 'interpretation models' from Breuker and Wielinga s correspond closely to our models o f rationality. The distinction between the static and the dynamic aspects of a model of rationality corresponds to a dis- tinction one can make between two different aspects of an expert system. First, there is the 'domain' in which the expert system is to solve problems. For example, the domain of an expert system may be electronics, or internal medicine. Secondly, there is the 'task' which the knowledge engineer wants the expert system to perform. For example, the task of a system can be diagnosing a faulty electronic circuit or designing a new circuit. It is interesting to note that the problems with shells reflect these two aspects of an expert system. The first complaint about shells concerning the expressive- ness of the knowledge representation language is related to the structure of the domain. The second complaint concerning the rigidity of the inference engine is related to the task of the expert system. As pointed out by Chandrasekaran ~, typical expert system tasks such as diagnosis, planning, monitoring, etc. seem to require particular control regimes. Socrates allows the use of a variety of logical languages and a variety of control regimes to solve the problem o f the lack of flexibility associated with shells. By using logic as its unifying framework, and by provid- ing guidelines for the choice of both the representation language and the control regime, Socrates avoids the unstructured richness of the hybrid systems. These points are discussed in detail below. U S I N G L O G I C F O R K N O W L E D G E R E P R E S E N T A T I O N Socrates uses a 'logical language' as the main formalism to implement the static aspects of the required models of rationality for different domains. On the one hand, logical formalisms are rich enough to provide different models of rationality, while on the other hand the use of logic provides a unifying framework for the system which saves it from the unstructured richness of the hybrid systems. This choice o f logic as the main formalism implies that logical languages will serve as the representational scheme, while logical deduction will be the paradigm for the inference engine. Many advantages come with the use of logic as the main knowledge representation formalism. Logic comes with a formal semantics, it has well understood proper- ties regarding completeness, soundness, decidability, etc., and it has great expressive power. For a further elaboration on these arguments, see Corlett, Davies, Khan, Reichgelt and van Harmelen 7. U S I N G M E T A - L E V E L I N F E R E N C E F O R C O N T R O L The correspondence between the two aspects of a model of rationality and the problems with shells suggests that a model of rationality should be computationally realized as a knowledge representation formalism plus a control regime for using this formalism. A number of arguments can be given for the explicit and separate representation of control knowledge. First, a system with I - . . . . . . . . . . . . U ~ r - f ' r o n ' t end . . . . . . . . . . . . . . "I L . . . . . . . . - I / A - , , [ 2 - _ - - - - 2 - - _- ; _ . . . . . . . . . . . . ] Figure 1. Socrates architecture an explicit representation of its control strategies is easier to develop, debug and modify, as argued by Davis s, Bundy and Welham 9, Clancey ~° and Aiello and Levi 11. Second, the separation of control knowledge from domain knowledge (or 'object-level knowledge') increases the reusability of the system: the same object- level knowledge can be used for different purposes, and the same control knowledge can be used in different domains s. ~ o. 12 Finally Clancey ~ 3 stresses the importance of explicit control knowledge for the purpose of explanation. The separation of control knowledge from domain knowledge allows domain knowledge to be purely declarative in nature. While formulating domain knowledge we do not have to worry about efficiency, only about the 'representational adequacy' (in the words of McCarthy). In the control knowledge, on the other hand, the efficiency of the problem solving process is the most prominent aspect ('computational adequacy'). A B S T R A C T A R C H I T E C T U R E O F S O C R A T E S As argued in many other places in the literature (see ~0.~2.~4-20 among others), an architecture with a separate object-level and meta-level interpreter can be used to implement the required separation of domain and control knowledge. This architecture is shown in Figure 1. The two-layer architecture of object-level and recta-level interpreter is extended in Socrates with a third level, the scheduler, discussed below. Each of the three interpreters communicates with the knowledge base in order to store and retrieve logical propositions. As described below, the knowledge base can be organized into a number of partitions, each of which can be hierarchically organized into subpartitions. The Socrates architecture distinguishes between front- ends to be used by the 'end-user' and the 'knowledge engineer'*. Knowledge engineers and end-users will need different tools for communication with the system. For example, an end-user, when asking for an explanation, will not want to see the entire proof tree, but rather 'edited highlights'. A knowledge engineer, on the other hand, may want to be able to monitor the reasoning *The end-user is the person who uses the expert system application built with the Socrates toolkit, whereas the knowledge engineer is the person building such an application system. Vol 1 No 3 June 1988 133 process much more closely and m a y require the full p r o o f tree. Similarly, a knowledge engineer will need tools for adjusting the b e h a v i o u r o f the interpreters and for edit- ing the knowledge base, whereas an end-user only needs to browse in a read-only m a n n e r t h r o u g h the knowledge base. F u r t h e r m o r e , the levels o f abstraction at which the system communicates will differ between end-user and knowledge engineer. This general, application independent architecture needs to be "configured' for a particular expert systems application, given the characteristics o f the d o m a i n and the task o f that application. The use o f logic as the underlying framework for the system gives a very specific meaning to the process o f configuring the system for a particular application. R a t h e r than having to choose between a r b i t r a r y representational schemes and inference m e t h o d s (as is the case in the hybrid systems), the configuration process now consists o f three well defined stages; i.e. the declaration o f a 'logical language', the declaration o f a ' p r o o f theory" for that logical language, and the declaration o f a ' p r o o f strategy'. L O G I C A L R E P R E S E N T A T I O N L A N G U A G E D E C L A R A T I O N As the first step in the process o f configuring a system for a particular application, the knowledge engineer defines the logical language that will be used for representing the d o m a i n knowledge. In the context o f a knowledge-based system, where the logical language is to be used for representational purposes, the 'syntactic" declaration o f the language has to be augmented with a mechanism for 'storage and retrieval'. Each o f these aspects will be discussed in this section. R e p r e s e n t a t i o n l a n g u a g e As the first part o f the declaration o f the logical represen- tation language, the knowledge engineer has to declare the "vocabulary' o f the language. T h e predicate symbols, function symbols and constants that are going to be part o f the representation language have to be defined. Socrates uses ' m a n y - s o r t e d logics' o f the kind pro- posed by Waither 2~, making use o f typed quantification, where the sorts are organized in a hierarchy. Each sort is used to represent a n o n - e m p t y set o f individuals belonging to that sort. In such logics the sort hierarchy is defined by a partial ordering on the set o f sorts, corres- ponding to a lattice structure with the universal sort as the maximal, and the e m p t y sort* as the minimal element in the set. This lattice is m o r e general than a tree structure, since it allows sorts to have more than one supersort, thereby increasing the expressiveness o f the sort o f system. T h e use o f m a n y - s o r t e d logics over unsorted logics brings a n u m b e r o f advantages. First, complicated unsorted expressions can be reformulated in a much simpler m a n y - s o r t e d form. F o r example, the unsorted expression: V x 3 y [human(x) ~ h u m a n ( y ) & mother(y, x)] * T h e e m p t y s o r t , n o t a t i o n ~,~, is t h e o n l y s o r t r e p r e s e n t i n g a n e m p t y set o f individuals, a n d a s s u c h d o e s n o t fulfill a n y r e p r e s e n t a t i o n a l role. T h e r e a s o n w h y s o r t s m u s t c o r r e s p o n d t o n o n - e m p t y sets is d i s c u s s e d below. t T h e n o t a t i o n x . t is used to indicate t h a t v a r i a b l e x is o f s o r t t. can be rewritten, after the declaration o f human as a sort, as V x: h u m a n 3 y: h u m a n [mother(y, x)]'t This reduction in complexity o f axioms not only improves the readability o f the knowledge base, but it also causes a significant decrease in the size o f the search space for proofs. C o h n 2-" (in the context o f a resolution based theorem prover), and Davies 23 (in the context o f a natural d ed u ct i o n system) show that this reduction can a m o u n t to as much as an o r d e r o f magnitude. Second, the sort hierarchy allows the knowledge engineer to represent what Clancey 13 calls "structural knowledge', representing the taxonomical hierarchy o f the application domain. In sorted logics, the unification algorithm has to take the sort hierarchy into account. Th e rules for unification in a sorted logic are: a constant c,:t~ unifies with a co n st an t C2:/2 if c~ = c2 and ti = I 2 a variable x.'t~ unifies with a co n st an t c.'t 2 if t 2 = tt a variable x.'q unifies with a variable y:t2 if tj Th e third rule results in restricting the sorts o f both variables to t3 = t~ c~ t2. In o rd er to g u aran t ee that t 3 can be c o m p u t e d and is itself a legal sort, it is necessary that the system knows the values o f all pairwise intersec- tions o f all sorts, and that sort-intersection is closed o v er sorts. In o t h e r words, if T is the set o f all sorts (including ~ ) , then V t~. t=:tt • T & l 2 • T - , t~ c~ t2 • T F u r t h e r m o r e , in o r d e r to g u aran t ee that 13 is uniquely defined, we require that no two sorts are used to repre- sent the same set o f individuals. I f this were allowed, the unification algorithm would no longer be able to return a unique most general unifier. Th e knowledge engineer declares the sorts o f the logic by declaration first the set o f sorts, and then the hierarchy o f sorts using set-theoretic primitives, such as equality, subset, superset, intersection, union, set- difference, c o m p l e m e n t a t i o n an d disjointness. After this has been done, the system automatically checks whether the sort hierarchy satisfies the following criteria: • No two sorts are equal. • N o sort except .~,, is empty. • Intersection is closed o v er sorts. If an y o f these constraints is violated, or if the constraints are not satisfied by the current declarations (because the knowledge engineer has underspecified the sort hierarchy), the system asks the knowledge engineer for different o r additional declarations. T h e sorts o f the constants o f the logical language can be declared in two ways. T h e simplest way is by simply en u m erat i n g the constants o f a particular sort ('extensional' definition o f types). H o w ev er, for some sorts e n u m e r a t i o n is not feasible, either because the set o f constants o f that sort is not k n o w n in advance, or because this set is t o o large, o r indeed infinite. F o r these cases it is possible to define constants by declaring a "recognition procedure" for the sort. Every object for which the recognition p r o c e d u r e succeeds will be assumed to be a co n st an t o f t h at particular sort ('inten- sionai' definition o f types). T h e definitions o f the 134 Knowledge-Based Systems recognition procedures must be supplied in the imple- mentation language of the system. This allows an inter- face between the logical representation language and the computational data types supplied by the implemen- tation language o f the system. An example of a sort that can be declared via this mechanism is the sort of all integers, or as a second example, for any given sort T, the sort T L i s t consisting of all lists of elements of sort T. As part of declaring the vocabulary of the logical representation language, it is possible to exploit what Weyhrauch 24 calls 'semantic attachment'. This is done by declaring a special class of predicates called 'evaluable predicates'. When one of these predicates is encountered in a proof, it is possible (depending on the control decisions made by the meta-level interpreter, discussed below) to execute a procedure defined for this predicate to determine its truth value, and possibly provide bindings for any variables. These predicates provide an interface between the logical representation language and the computational environment of the system, enabling external systems interaction, input/output for interacting with the end-user, and the access of the facili- ties provided by the implementation language of the system. At this stage the representation language consists only of a sort hierarchy and a set of predicates, constants and functions. We still need to extend our language with 'logical connectives', such as implication, dis- junction, etc., and possibly non-standard operators*, such as modal and temporal operators. As part of the declaration of these logical connectives the knowledge engineer can declare their properties with respect to commutativity and associativity. These declarations will be used to configure a unifier for the defined logical language (see the section below on the declaration of the proof theory for a more detailed discussion of this subject). Socrates distinguishes between different kinds of logical connectives: 'Unary' connectives take one argument; binary connectives take two arguments, and can be divided on the basis o f their commutativity. Implication ( ~ ) is an example of a 'non-commutative binary' connective, whereas equivalence (4--,) is an example of a 'commutative binary' connective. If con- nectives are both commutative and associative (such as, for instance, conjunction), they are treated as so-called 'set-connectives'. This amounts to them taking any number o f arguments in any order. Furthermore, set connectives are assumed to be idempotent: all multiple occurrences of an argument can be reduced to only one occurrence. Other possible connectives are not currently implemented in Socrates: 'bag' operators, which are associative and commutative but not idempotent (i.e. the order of arguments does not matter, but multiple occurrences o f an argument cannot be reduced), and 'sequence' operators, where the order of the arguments is significant, and multiple occurrences cannot be reduced. S t o r a g e and retrieval mechanism Now that the vocabulary of the logical language is complete we need to declare a storage and retrieval *The terms logical connective and logical operator are used synonymously mechanism for expressions in the language. This is what is typically called the 'knowledge base' of the system. The knowledge base of Socrates is not a flat space of assertions in the declared logical language, but can be divided into a number of 'partitions'. Each o f these partitions can have a separate logical language asso- ciated with it (but see below for a restriction on this). This facility serves a number of different purposes. First, it allows the knowledge engineer to use mixed language representations of the domain. Different types of knowledge or different aspects of the domain can be represented in separate languages. A particular example of this is described below, where we discuss the control knowledge of the system. This meta-level knowledge is expressed in a different language from the object-level knowledge. Nevertheless, it can be stored in the same knowledge base, using the partitioning mechanism to separate the two. Second, the partition hierarchy can be used to reduce the search that needs to be done both by the retrieval mechanism and by the inference machinery. In many problem solving situations, only a subset of all the avail- able knowledge is applicable at any one time to a given problem. Partitioning allows useful subsets to be applied while others are ignored. In this way, Socrates can be used to model a blackboard architecture, with each of the partitions simulating the contents of a knowledge s o u r c e . An important aspect of the partitions in the knowledge base is that they can be recursively divided into sub- partitions, and that these subpartitions are organized hierarchically. Partitions lower down in this hierarchy inherit all the propositions from partitions higher up in the hierarchy, but not vice versa. A particular example of this could be the use of a single working memory for a number of different subsets of domain knowledge, where the working memory would be represented in the top node, and the subsets of domain knowledge repre- sented in subpartitions. The results o f reasoning done within one subpartition can in this way be communicated to the other partitions via the working memory. Again, this feature can also be used in the modelling of a black- board system in Socrates, since the blackboard needs to be visible from all knowledge sources, but not vice versa. Since partitions can be created dynamically at runtime, another application for the partition hierarchy in the knowledge base is hypothetical reasoning, some- times known as 'what-if' reasoning. Each time a new hypothesis is generated, a new subpartition can be created containing this hypothesis, and inheriting all existing propositions from higher partitions. The inheritance mechanism puts restraints on the logical languages that can be used within subpartitions. Because subpartitions inherit propositions from super- partitions, all the partitions in a partition hierarchy must be associated with the same logical representation language. (Strictly speaking, it is only necessary that the language of a subpartition is an extension of the language of its superpartition, but Socrates does not support this type of language inheritance.) Thus, the knowledge base can be seen as a set of trees of partitions. Within each tree, all partitions must have the same language, but each separate tree can be associated with a different language. A final facility supported by the knowledge base is Voi 1 N o 3 June 1988 135 the a n n o t a t i o n o f p r o p o s i t i o n s . Each p r o p o s i t i o n can be a n n o t a t e d with a r b i t r a r y i n f o r m a t i o n using a slot- value m e c h a n i s m . This allows us to associate extra- logical i n f o r m a t i o n with propositions. This i n f o r m a t i o n can be used for a wide range o f purposes, o f which a few e x a m p l e s are: n a t u r a l language descriptions to be used in explanations, c o n t r o l i n f o r m a t i o n to be used by the meta-level interpreter, c e r t a i n t y values, etc. This slot-value m e c h a n i s m could be used to model a truth- m a i n t e n a n c e system in Socrates, by storing each derived p r o p o s i t i o n in the k n o w l e d g e base t o g e t h e r with a n n o t a - tions that c o n t a i n the premises t h a t were used in its derivation. Socrates uses a discrimination net technique for retrieval o f propositions. T h e o p t i m a l criteria that the net should use for discrimination d e p e n d on the parti- cular application, a n d Socrates therefore allows the knowledge engineer to adjust these discrimination criteria to suit the p a r t i c u l a r ways in which the k n o w - ledge base retrieval m e c h a n i s m will be used. F o r example, if the m a i n control regime for a p a r t i c u l a r application is s o m e f o r m o f b a c k w a r d chaining, then p r o p o s i t i o n s o f the f o r m "left-hand-side ~ r i g h t - h a n d - side' will be retrieved f r o m the knowledge base on the basis o f the p a t t e r n s in the ' r i g h t - h a n d - s i d e ' a r g u m e n t . This implies t h a t the discrimination net should first dis- c r i m i n a t e implications on the basis o f their consequent, r a t h e r than their antecedent. As a second example, we note that m a n y predicates use a certain n u m b e r o f their a r g u m e n t s as ' i n p u t s ' , while others are used as "output" a r g u m e n t s . A predicate such as ' s u f f e r s - f r o m (patient, disease)' will typically be used to associate a given patient with a disease, r a t h e r t h a n to try a n d find all patients suffering f r o m a given disease. This p a r t i c u l a r use o f a r g u m e n t s indicates t h a t the discrimination net should use the first a r g u m e n t as the m a i n discrimination criterion, r a t h e r t h a n the second a r g u m e n t . Because these p r o p e r t i e s are specific to a p a r t i c u l a r application, they can only be adjusted by the k n o w l e d g e engineer w h o configures the system, r a t h e r t h a n being hardwired into the retrieval m e c h a n i s m o f the knowledge base. PROOF THEORY DECLARATION T h e declaration o f a logical language t o g e t h e r with a storage and retrieval m e c h a n i s m allows us to represent knowledge, but in o r d e r to m a n i p u l a t e this k n o w l e d g e to derive new conclusions we need rules that tell us what the legal d e r i v a t i o n s will be. Since we have chosen logic as the r e p r e s e n t a t i o n language for the system, we are c o m m i t t e d to logical d e d u c t i o n as the inference process. W e therefore need to define a p r o o f theory, i.e. a set o f inference rules* t h a t tell us h o w logical p r o p o s i t i o n s can be m a n i p u l a t e d in o r d e r to p e r f o r m a p r o o f . In Socrates we follow Biedsoe 2s in using the natural d e d u c t i o n style o f p e r f o r m i n g p r o o f s r a t h e r than, for instance, resolution. A l t h o u g h n a t u r a l d e d u c t i o n systems use a relatively large n u m b e r o f inference rules (as o p p o s e d to the single inference rule o f resolution based systems), and thereby create a p o t e n t i a l c o n t r o l *We use the term "inference rule' in the logician's sense: an inference rule is a rule that describes how true formulas can be inferred from other true formulas, and is of the form . f t . • • f , ~- g , where g is inferred from J ~ . . . f , . The term 'inference rule' is often incorrectly used to denote formulas of the form .f--, g (i.e. logical implications). p r o b l e m , a n u m b e r o f reasons can bc given in f a v o u r o f n a t u r a l deduction. T h e inference rules o f a n a t u r a l d e d u c t i o n system are m o r e intuitively meaningful than, for instance, the resolution rule. F u r t h e r m o r e , no n o r m a l f o r m s are required for the f o r m u l a s used in a proof. As a result, the p r o o f s p e r f o r m e d by a n a t u r a l deduction system are easier to follow for a h u m a n reader, thereby i m p r o v i n g the possibilities for e x p l a n a t i o n facilities. T h e naturalness o f the p r o o f d e v e l o p m e n t also m a k e s it easier to identify heuristics to c o n t r o l the p r o b l e m solving pro- cess, in the m a n n e r discussed below. W h e n expressing inference rules, the k n o w l e d g e engineer can m a k e use o f extra-logical variables that range o v e r well f o r m e d f o r m u l a s f r o m the object-level representation language. F o r instance, the rules P , P ~ Q ~ Q P ~ - P V Q represents the rules f o r M o d u s Ponens a n d Disjunction I n t r o d u c t i o n . It is i m p o r t a n t to stress that these inference rules can be used in b o t h a f o r w a r d a n d a b a c k w a r d direction. F o r instance, M o d u s Ponens can be used to d e t e r m i n e t h a t P a n d P -~ Q have to be p r o v e d in o r d e r to p r o v e Q ( b a c k w a r d use), o r the rule c a n be used to infer that Q is true when we k n o w t h a t b o t h P and P --* Q are true. F u r t h e r m o r e , because o f the associativity and c o m m u t a t i v i t y o f s o m e o f the logical connectives, a single inference rule c a n often be applied in m o r e t h a n one way. F o r instance, if disjunction (V) has been declared as a ' s e t - o p e r a t o r ' , Disjunction I n t r o - d u c t i o n can be applied b a c k w a r d to (/'V g) in t w o differ- ent ways, binding P to e i t h e r . f or g, thereby generating either f o r g as a sub-goal for p r o v i n g 0"V g). H o w e v e r , which o f these possible a p p l i c a t i o n s o f an inference rule should be used is a control decision, a n d is therefore a meta-level issue, which is not decided as p a r t o f the p r o o f theory. N o t all the inference rules t h a t the system uses are declared as p a r t o f the p r o o f strategy. First o f all, there is a set o f inference rules t h a t tell the system h o w to deal with t y p e d quantification. These rules: V x:t~ P[x] ~ P[c:t2] for an a r b i t r a r y c o n s t a n t c, a n d all sorts t~ and t2 with t~ _~ t2 ~ ~' P[c:t~] ~ 3 X:tz P[x] for an a r b i t r a r y c o n s t a n t c, a n d all sorts t~ and t2 with t 2 ~ t~ D ~)* 3 x:tt V y:t2 P[x,y] I'-- V y:t2 q x:t~ P[x,y] for all sorts t~ a n d t2 are taken to be o f universal validity (that is: across differ- ent a p p l i c a t i o n areas o f the system), a n d are therefore hardwired into the retrieval m e c h a n i s m . A second set o f rules, t h a t is p a r t o f the retrieval m e c h a n i s m in the knowledge base r a t h e r t h a n the p r o o f theory, are the results that deal with the c o m m u t a t i v i t y a n d associativity o f certain logical connectives. F o r a n y o p e r a t o r ~ that has been declared as " b i n a r y - c o m m u t a t i v e ' , the inference rule P d p Q ~ Q ~ P is hardwired into the knowledge base retrieval mechanism, as are, for every ' s e t - o p e r a t o r ' , the additional rules P F - Pdp P (P dp (Q dp R)) I-- ((P ~ Q) dp R). *it is exactly because of this rule that in the section on logical represen- tation declaration we required all sorts except ~ to be non-empty. 136 K n o w l e d g e - B a s e d Systems By taking all these rules out o f the explicit declaration o f the p r o o f strategy and transferring them to the retrieval mechanism o f the knowledge base, we have given a limited deductive capability to the knowledge base. The retrieval mechanism comprises two sequential stages, a syntactic 'pattern matcher' and a 'unifier'. Syntactic pattern matching is effected using the discrimi- nation net technique mentioned above. Given a formula as a query to the knowledge base, this process will retrieve all formulas with the same pattern o f operators and predicates, subject to the commutativity and associa- tivity rules as declared for the particular language. This means that unification will be attempted only on patterns that have a strong possibility o f succeeding. The patterns that can be specified as input to the syntactic pattern maching phase are allowed to contain 'recta-logical (propositional) variables' that can match with formulas o f the logical representation language rather than with terms. These meta-logical variables will be bound to the corresponding components o f the matching expression, using pattern matching under the inference rules governing commutativity and associa- tivity. For example, the pattern (& f ?P) will match with a formula like (& g f ) , binding ?P with g after applying commutativity. To facilitate the retrieval o f expressions containing set-operators, a special version o f these meta-logical variables is available, the so-called 'segment-variables'. These segment variables do not match with formulas, but with lists o f logical formulas. For example, a formula like (& f g h) will match with a pattern like (& g ?P'segment), binding ?P with the list ( f h). Because o f the meta-logical variables, the patterns sent to the knowledge base for retrieval are actually schemata, representing whole families o f queries rather than just a single query. In the second phase o f the retrieval process the unifier will construct bindings o f the logical variables occurring in the query. This is necessary since in the context o f expert systems we are interested in performing construc- tive proofs, and we therefore need the values for the existentially quantified variables in the query for which the query succeeds. In other words, for a query such as 3 x:ttp(x), we want not only a yes/no response, but also the values o f x which can be deduced from the contents o f the knowledge base. Notice that these bind- ings might only consist o f restrictions on the sort o f x, rather than o f bindings o f x to terms. The sorted unification algorithm might tell us that the query succeeds for all values o f x o f a certain sort t2, with t2 c t,. In this way, taxonomic reasoning is performed at retrieval time. A final point to be made about the declaration o f the p r o o f theory concerns the soundness and complete- ness o f the set o f inference rules. In order to guarantee soundness o f the p r o o f theory, the knowledge engineer should not be allowed to declare arbitrary inference rules, but only to select inference rules from a predefined (and sound) set*. This selection process will o f course affect the completeness o f the system. However, the loss o f completeness in the context o f expert systems is not serious, since one does not want to infer a / / f a c t s that follow from the available knowledge, but only those facts that one is interested in. *Such a selection procedure has not been provided in the current implementation o f Socrates. P R O O F S T R A T E G Y D E C L A R A T I O N At this point, the knowledge engineer has declared both a logical language and a corresponding p r o o f theory. From a purely logical point o f view, no further declara- tions are necessary. The combination o f language and p r o o f theory determines all the possible inferences that the system can make. However, in order to create a practical computer system, one more step has to be taken. Proving statements in any non-trivial logical language is a search intensive problem. The logical language and p r o o f theory together define a search space for the p r o o f process. What remains to be done is the specification o f the strategy that the system should use to traverse this space while searching for a proof. For this task, Socrates provides a declarative language for representing such a control strategy, described below. Because such a declarative language has certain dis- advantages associated with it, a more procedural language has also been investigated (see below). Declarative representation of control knowledge Socrates allows the knowledge engineer to explicitly specify a control strategy. This control strategy provides the system with a description o f its desired behaviour, and is interpreted at run time by the meta-level inter- preter. As a result, the meta-level interpreter executes this control strategy, and thereby guides the search through the space o f all possible proofs. The language that is used to express the control strategy is a many sorted version o f Horn Clause Logic. This language, although also a logical representation language, should be distinguished from the logical languages used to represent the domain knowledge. Unlike the object-level languages, the language used at the meta-level has a fixed set o f logical connectives, namely exactly those connectives needed in Horn Clause Logic: conjunction, implication and negation, plus disjunction. All these connectives are declared as non-commutative, non- associative. This is done because the procedural interpre- tation (i.e. the way in which the meta-level interpreter executes expressions o f the language) is also fixed. The procedural interpretation o f the language is the standard interpretation for Horn Clauses, the standard depth-first p r o o f procedure as found in Prolog systems. The reason why Socrates does not allow the knowledge engineer to change the control regime o f the meta-level interpreter (which would amount to providing a meta-meta-level interpreter~f) follows from the analysis o f models o f rationality, sketched above. As indicated, typical expert system tasks such as diagnosis, planning, monitoring, etc. are related to particular control regimes. The meta- level controls the behaviour o f the object-level interpreter according to the expert system task. The variation in control is achieved by changing the meta- level knowledge base. There is no need to change the interpreter, which always has the same task, namely con- trolling the behaviour o f the object-level interpreter by using the data in the meta-level knowledge base. The parts o f the meta-level language that are still subject to declarations made by the knowledge engineer tThe notion of a meta-meta-level interpreter should not be confused with the scheduler; the relation between meta-level interpreter and scheduler is very different from the relation between object-level and meta-level interpreter. Voi I N o 3 June 1988 137 are therefore the set o f constants, predicates and function symbols, the sort hierarchy, and the set o f "evaluable predicates'. Figure 2 shows an example o f a description o f a local-best-first non-exhaustive backward chaining control strategy. F o r this control strategy a sort hierarchy was defined containing the sorts formula, list- of-formulas, substitution and list-of-substitutions. T h e sort formula was further subdivided into c o m p o u n d - , evaluable- and non-evaluable-formula. A further specialization o f list-of-formulas was non-empty-list-of- formulas. In the example shown in Figure 2, clause (1) states that in order to prove a n o n - c o m p o u n d expression F on the basis o f the contents o f knowledge base partition P giving a substitution S as a result, the system should either try to see if the formula is a know n fact in the knowledge base, try to infer the formula on its own, or it should ask the end-user. Trying to infer the formula means generating all possible inferences, select- ing some o f these possible inferences, and continuing with clause (2). T h a t clause chooses the best o f all selected possible steps, and tries to continue the p r o o f with this selection. I f this succeeds, the p r o o f terminates (i.e. non-cxhaustive), if this fails, the p r o o f continues with the next best step. Clause (3) states the criterion used in the best-first search, while clause (4) describes what needs to be done in order to prove a c o m p o u n d expression: prove both left- and right-hand sides o f the c o m p o u n d expression, and c o m b i n e the results. Clause (5) states that all evaluable predicates e n c o u n t e r e d in a p r o o f should be evaluated without any further control scheduling. This example shows how the different aspects o f this strategy can be changed if needed for a particular appli- cation. F o r example, the order o f the disjuncts in clause (1) might be changed to ask the end-user for solutions before the system tries a p r o o f itself, or the ask-user (I) (v F:non-evaluable-formula, P:partition, S:substitution, Next:non-empty-list-of-formulas. SomeNext:non-empty-list-of-formulas) [knowledge-base-lookup(F, P, S) V ( object-level-interpreter(F, P, backward. Next) & ~lect-inferences(Next, SomeNext) & infer(SomeNext, P, S)) V ask-uscr(F, P, S)) -oproof(F. P, S)] (2) (V inferences:non-empty-list-of-formulas, P:partition, S:substitution, Best:formula, Rest:list-of-formulas) [best(Inferences. Best,Rest) & (proof(Best, P. S) V infer(Rest, P, S)) -,infer(Inferences, P. S)] (3) (V List-non-empcy-list-of-formulas, Best:formula, Rest:list-of-formulas) [higher-certainty-value(List, Best,Rest) --.best(List, Best,Rest)l (4) (V F:compound-formula. P:partition, S:substitution, Lhs:formula, Rhs:formula, LhsSubst:substitution, RhsSubst:substitution) [split-compound-expression(F, Lhs, Rhs) & proof(Lhs;, P, LhsSubst) & proof(Rhs, P, RhsSubst) &-combine(LhsSubst. RhsSubst, S) --* proof(F, P, S)] (5) V F:evaluable-formula, P:partition, S:substitution. [evaluate(F. P, S) -, proof(F, P, S)] Figure 2. Declarative speciJ~cation of control in Socrates disjunct might be deleted altogether. T h e criterion used for the best-first scheduling could be changed, or a new decision for scheduling the o rd er in which conjuncts are proved in clause (4) could be introduced. M o r e t h o r o u g h changes to the strategy could also be made, but they would a m o u n t to writing a completely new p r o o f strategy rather than changing the one shown in this example. O f the evaluable predicates in Figure 2 (such as ask- user, knowledge-base-lookup, combine) the predicate object-level-interpreter is the most i m p o r t a n t one. This predicate encapsulates the interface between the meta- level interpreter executing the co n t ro l strategy, and the object-level interpreter handling the logical representa- tion language and the c o r r e s p o n d i n g p r o o f theory. The input o f this predicate is an object-level formula F, the name o f a knowledge base partition P and a direction in which to apply inference rules (either forward or back- ward), and returns as o u t p u t the result o f applying all inference rules specified as part o f the p r o o f theory for partition P to the input fo rm u l a F in the indicated direc- tion. In terms o f the p r o o f search space, this a m o u n t s to generating all nodes that are accessible from the current n o d e as represented by F. Thus. the predicate object-level-interpreter allows the meta-level interpreter to access an explicit representation o f the object-level search space, and to choose which branches o f the object-level p r o o f tree will be ex p an d ed on the basis o f the control regime provided by the knowledge engineer. Unlike m a n y logic-based meta-level architectures pro- posed in the literature, (such as Silver t°, or the Prolog system described inZ°), Socrates completely separates the languages used at the object-level from the language used at the meta-level. Even when the object-level repre- sentation language h ap p en ed to be defined as sorted H o r n Clause Logic, the two languages would still be syntactically separate. Th e meta-level and object-level languages are connected t h ro u g h a 'n am i n g relation'. Th e meta-level language contains names for all object- level expressions. In Socrates, the n am e o f an object-level sentence c o r r e s p o n d s to a co n st an t in the meta-level language. O t h e r meta-level constants are used to denote bindings for object-level variables. If this is required, meta-level expressions could range o v er any o f the extra- logical properties o f object-level expressions, such as truth values, certainty factors, justifications, etc. In this way, for instance, Socrates could be configured to deal with certainty values by specifying as part o f the control strategy how certainty values should be used in a proof. This c o r r e s p o n d s to the a p p r o a c h suggested by Shapiro 2;, with the i m p o r t a n t difference that Socrates makes a correct distinction between meta-level and object-level languages, whereas Shapiro confuses the two and uses Prolog for both. A n u m b e r o f reasons can be given why it is i m p o r t a n t for the meta-level language to be separated from the object-level languages. First, there is an epistemological reason: as argued in 2~, different d o m a i n s require different representation languages, and the object-level and the meta-level o f Socrates deal with widely different d o m a i n s (the object-level deals with the application d o m a i n o f the system, while the meta-level deals with the issue o f controlling the object-level). A second argu- ment concerns the m o d u l a r i t y o f the system: it should 138 Knowledge-Based Systems be possible to vary control knowledge and domain knowledge independently. The third argument is one o f explanation: in order to enable the system to include control knowledge explicitly in its explanations, it is important for both the human reader and the automated explanation generator that control knowledge can be syntactically distinguished from domain knowledge. Procedural representation of control knowledge The approach to the specification o f a p r o o f strategy described above is based on the use of a declarative meta-level language. Although the declarative style o f control o f reasoning has its attractions, there are also disadvantages. Two problems in particular are caused by the use o f a declarative language, and in an attempt to overcome these problems Socrates provides an alter- native, more procedural language for specifying control regimes. First, the extra layer o f interpretation that is incurred by the explicit meta-level interpreter is expen- sive, because o f the declarative nature o f the meta-ievel language. A procedural meta-level language would be much closer to the underlying implementation language and machine architecture, and therefore cheaper to execute. Second, much o f the knowledge expressed in the meta-level language is procedural, rather than declarative. For example, one often wishes to apply knowledge o f the form 'try method-I before method-2', or 'in order to achieve goal-l, achieve sub-goal-I to subgoal-n'. In the declarative meta-level language this type o f procedural knowledge has to be expressed by either relying on the hardwired control regime for the meta-levei interpreter, or by using semantic attachment. Neither o f these ways o f expressing procedural knowledge is very desirable, since they encode knowledge implicitly rather than represent it explicitly. A more pro- cedural language provides a more natural medium for expressing the procedural control knowledge. Our approach to procedural control is therefore to provide a 'meta-level programming language' rather in the vein o f M L 3° in its relationship to LCF. That is, we provide high level primitives that make the writing o f control regimes easier. It is important to note that a procedural control language is only an alternative way o f implementing the separation o f control knowledge from object-level knowledge. The procedural approach still clearly separates control knowledge from object- level knowledge. The difference is that rather than put- ting the control knowledge into a declarative knowledge base with its own interpreter, we propose implementing a special purpose meta-level interpreter that incorporates the control knowledge. The three stage process o f build- ing systems is retained. One particular point to note is that we retain the explicit declaration o f inference rules and provide primitives to apply inference rules. The procedural meta-levei language consists o f the implementation language o f the system (Common Lisp), extended with primitives implementing standard artifi- cial intelligence techniques that have been found useful in writing interpreters. Central to the system is the use o f lazy evaluation. The procedural meta-level language provides facilities for the manipulation o f lazily evaluated lists, which form the basis for backtracking and coroutining in the control regimes. The second important component is agenda- (defun proof (GoalList Partition Subst &aux NewGoals NewSubst) (if GoalList (foreach (NewGoals. New Subst) in (or (any-of (order-inferences (evaluate (first GoalList) :partition Partition :subst Subst)) (order-inferences (lookup (first GoalList) :partition Partition :subst Subst)) (select-inferences (generate-backward-inferences (first GoalList) :partition Partition :subst Subst))) (ask-user (first GoalList) :partition Partition :subst Subst)) generate-each (proof (append NewGoals (cdr GoalList)) Partition NewSubst)) (list Subst))) Figure 3. Procedural specification o f control in Socrates based reasoning. This technique allows the knowledge engineer to experiment with several different control strategies, often only changing the way the agenda is handled without changing the rest o f the control regime code. The third component is a pattern matcher which provides the basis o f pattern directed invocation of p r o o f methods. It is important to realize that in this procedural approach it is still the case that the only inference rules are those declared explicitly during the declaration o f the p r o o f theory (as described above). Language primi- tives are provided to apply the declared inference rules. Figure 3 shows an example o f a control regime formu- lated in the procedural meta-level language. This code is the procedural equivalent o f the declarative prover given in Figure 2. The main function is called 'proof' and performs the same function as the predicate o f that name. Being stream-based, p r o o f returns a stream o f substitutions that prove the goals in the 'GoalList' argu- ment. Thus, if the GoalList is empty there is one such proof, given by the Subst argument. If the GoalList is not empty then the inference rules are applied to the first goal in GoalList. The ' a n y - o f macro is a way o f lazily combining streams. Thus, in this example, we generate all the possible inferences using 'evaluate' (and put them in a preferred order), then all the possible inferences using 'lookup' (again in preferred order), finally followed by a selection o f the possible inferences generated using all the inference rules. ' I f and only if' no possible inferences are generated by this procedure, then 'ask-user' is applied to obtain possible inferences. Each inference rule application generates three things: a set of new goals to be proved in order to prove the goal (bound to the variable 'NewGoals'); a new substi- tution, bound to the variable 'NewSubst'; and a justifi- cation, which merely describes which inference rule has been applied and is effectively ignored by this prover. The 'foreach' macro itself generates a stream o f answers. Thus, if at some later stage in the p r o o f there is a need to backtrack, the next inferences will be generated only then. Note that, unlike the declarative prover, which generates only the first proof, the procedure ' p r o o f returns a stream o f proofs, and thus generates the set o f all proofs (lazily). It was noted at the beginning o f this section that much Vol 1 No 3 June 1988 139 control knowledge seems very procedural in nature (such as the execution o f a sequence o f goals). However, some- times control knowledge is declarative in nature (e.g. a set o f criteria used in the ordering o f conjuncts). The architecture o f Socrates is such that even with procedural control it is still possible to invoke a declarative meta- level interpreter that is implemented using the techniques described above. Although the above features provide a basis for a procedural language for formulating control regimes, certain problems remain. First, the current language may not be powerful enough, and further additions may be needed. Second, although in one sense the current proce- dural meta-level language might not be powerful enough, in a n o t h e r sense it might be too powerful. As described, the procedural meta-level language consists o f extensions to C o m m o n Lisp, thereby making all the general purpose expressive power o f Lisp available to the knowledge engineer when writing control regimes. It might well be the case that this provides too powerful a language, since it does not restrict the knowledge engineer in any way. The scheduler A third level in the architecture o f Socrates (see Figure 1) is the 'scheduler'. This third level is not actually imple- mented in the current Socrates architecture, but it can be added to the current system with little effort. The main notion that is treated at this level is that o f a "subtask'. As shown in Reichgelt and van Harmelen 29, m a n y expert systems perform not just one simple task, but a composite one that can be thought o f as consisting of a number o f elementary tasks ( M Y C I N , RI and VM are a m o n g the systems discussed in that paper). It is unlikely that one appropriate control regime can be found that would be suitable for these composite tasks. Rather, the composite task should be split up into its constituent subtasks, and a proper control regime can then be chosen for each o f the subtasks. The subtasks that would result from this decomposition process are the kind o f prototypical tasks proposed in Reichgelt and van Harmelen 29, Chandrasekaran 6, and Breuker and Wielinga 5, like classification, monitoring, simulation, design, etc. The scheduling level o f the Socrates architecture is meant to deal with this sub- division o f the major task into prototypical subtasks. Each o f these prototypical subtasks can then be solved using the appropriate meta-level control strategy. (By using the knowledge base partition mechanism, it is possible to equip a Socrates configuration with more than one control strategy.) F o r engineering purposes it would be easiest to equip the scheduling level with a language similar to (but again syntactically separate from) the language used to describe the control strategy at the meta-level. However, early experience indicates that the type o f knowledge to be expressed at the schedul- ing level is o f a very procedural nature (even more so than the knowledge expressed at the meta-level), and therefore a language with more conventional procedural primitives, such as sequences, conditionals, loops and subroutines, might be more appropriate. PRACTICAL P R O G R E S S A N D A C H I E V E M E N T S A version o f the Socrates architecture as described above has been implemented in approximately 15K lines o f C o m m o n Lisp code. (Notice the distinction between "implementation language" and "representation language'of a system: although the knowledge represen- tation and inference process o f Socrates are both logic based, the system is n o t implemented in Prolog or any other logic programming language.) The system currently runs in a number o f C o m m o n Lisp implemen- tations on U N I X based systems. In one o f these C o m m o n Lisp systems, the Poplog system, a graphics- based knowledge engineer interface, has been con- structed, allowing interaction with the system via menus, browsers, graphers, etc. A substantial set o f different control strategies has been written as meta-level programs, including backward and forward chaining, exhaustive and non-exhaustive search, user guided or automatic conflict resolution, best-first, depth-first, breadth-first search, branch and bound type algorithms, generate and test procedures, elimination and confirmation strategies, etc. A number o f demonstration systems have been built using Socrates, including an expert system in the domain o f personal investment advice and a route planning system. More significantly. Socrates has been used to reimplement an existing expert system under the name o f DOCS, developed by G E C Research in collaboration with Westminster Hospital, London. This system con- sists o f 130 rules divided over two knowledge base partitions. The partition hierarchy is organized so that these two partitions can use data from a c o m m o n work- ing memory partition. A sort hierarchy o f over 80 sorts was used to model the taxonomic hierarchy o f the medical domain. A generate and test control strategy was specified tbr this system, consisting o f some 20 clauses in the meta-level knowledge base. In the area o f theorem proving Socrates has been used to solve the problem described by Walther 2', known as 'Schubert's steamroller'. This problem was originally formulated because o f the huge search space that it generates. Using the sort hierarchy to model the taxonomic part o f the problem, a breadth-first search strategy, implemented using our procedural control tech- niques, resulted in the first natural deduction style p r o o f for this problem. A number o f other procedural control strategies were implemented to solve the problem, and a comparison o f these different strategies showed the importance o f the exploitation o f meta-knowledge to guide the search for a proof. This application o f Socrates is described in detail by Davies 23. Current areas o f activity are: • The use o f meta-level interpretation for dealing with extra-logical issues, such as uncertainty, truth maintenance, explanation, etc. (how the slot-value a n n o t a t i o n mechanism o f Socrates' knowledge base opens up these possibilities is described above). • The implementation o f modal logics through the use o f reification, as described by Reichgelt 3 ~. • The classification o f domains and subtasks, as stated by Reichgelt and van Harmelen 2s'29, in order to provide the knowledge engineer with guidelines that indicate how to choose the appropriate representation language given a particular application domain, and how to choose the appropriate control regime given a particular prototypical task. • The development o f a library o f control regimes that 140 Knowledge-Based Systems can be executed by the system. Rather than having to write a new control strategy from scratch every time, the knowledge engineer can use a library o f preprogrammed control strategies. The knowledge engineer can then either use one o f the strategies directly from the library, or use one o f the library elements as the basis for his own control strategy by making small changes to the preprogrammed strategy. O P E N P R O B L E M S O f the three stages o f the configuration process, the third one (declaring a p r o o f strategy) is by far the most problematic. An important open question here is the choice o f a good language for specifying such a control strategy. As described above, the system primarily uses a declarative logical language to do this, but a procedural language has also been investigated. Apart from the type o f language used at the meta-level, a related problem is the required vocabulary o f such a language. At the moment, the vocabulary o f the system is specified by the knowledge engineer, and although this is to a certain extent inevitable, since part o f the vocabulary will be application-specific, one would hope that at least a central core vocabulary can be distinguished that can be preprogrammed into the system. The example o f a control regime discussed above suggests predicates to do with manipulating substitutions and formulas, and with generating the object-level search space, but a more extensive and more exactly defined vocabulary is needed in order to alleviate the task o f the knowledge engineer. A second problem associated with the explicit meta- level interpreter is that o f meta-level overhead. Although the flexibility in defining the appropriate control strategy at the meta-level can considerably reduce the object-level search space, the price we have to pay for this is the fact that the object-level inference process is completely simulated by the meta-level interpreter. This is obviously much more expensive than an object-level interpreter that has the appropriate control strategy hardwired into it. This problem could be solved by taking the explicit formulation o f a control regime, and compiling it into an interpreter that has the particular control regime hardwired into it. This compilation process (whose first stages could be similar to that described by Altman and Buchanan 3z) has been simulated in Socrates by hand coding a number o f hardwired control strategies. Experi- ence with these hardwired strategies in both the DOCS system and in solving Schubert's steamroller indicates that the meta-level overhead can indeed be reduced to an acceptably small amount. C O N C L U S I O N The work described in this paper attempts to create an environment for building expert systems based on the following principles: • An epistemological analysis o f the domain and task o f a particular application guides the choice o f the appropriate knowledge representation language and the appropriate control regime. • Logic is used as the main underlying formalism. • Control knowledge is represented explicitly and is separated from the domain knowledge. When configuring the Socrates environment into a particular expert system, a knowledge engineer can vary the architecture along three dimensions: • The representation language: a knowledge engineer can define his own logical representation language, including first order logics (possibly many-sorted), modal logics, temporal logics, etc. • The inference rules for the logical language: the set o f rules that determine the possible inferences made in the logical language can be changed by the knowledge engineer. • The control regime under which the inference rules will be used to perform proofs in the logical represen- tation language. An implementation o f the Socrates abstract architecture and a number o f applications o f the system have proved the feasibility o f this approach. Due to limitations o f space, some o f the arguments and descriptions in this paper are rather terse. A long version o f this paper can be found in Corlett, Davies, Khan, Reichgelt and van HarmelenL A C K N O W L E D G E M E N T S As the grant holder, Peter Jackson has made many con- tributions to the work described above. Ray McDowell and Dave Brunswick have contributed to the work done at GEC Research. The research was carried out as part of Aivey Project IKBS/031 in which G E C Research, the University o f Edinburgh and G E C Avionics were partners. The university work was supported by SERC grant GR/D/17151. R E F E R E N C E S 1 AIvey, P 'Problems o f designing a medical expert system' 3rd Tech. Conf. British Comput. Soc. Specialist Group on Expert Syst. (December 1983) pp 20-42 2 Bobrow, D and Stef'~, M The LOOPS Manual Rank Xerox, U K (1983) 3 The knowledge engineering environment Intellicorps, California, USA (1984) 4 Williams, C ART, the advanced reasoning tool, conceptual overview Inference Corporation, Los Angeles, California, USA (1983) 5 Breuker, J A and Wiefinga, B J 'Models o f Expertise' Proc. 7th Europ. Conf. on Artif. Intel. (July 1986) pp 306-318 6 Chandrasekaran, B 'Towards a functional architec- ture for intelligence based on generic information processing tasks' 7th Int. Joint Conf. on Artif. lntel. (August 1987) pp 1183-1192 7 Corlett, R, Davies, N, Khan, R, Reichgelt, H and van Harmelen, F 'Socrates: a flexible toolkit for building logic based expert systems' in Jackson, P, Reichgelt, H and van Harmelen, F (eds) Logic-based knowledge representation MIT Press, USA (1988) 8 Davis, R 'Meta rules: reasoning about control' Artif. lntel. Vol 15 No 2 (1980) pp 179-222 9 Bundy, A and Welham, B 'Using meta-level inference for selective application o f multiple rewrite rules in algebraic manipulation' Artif. Intel. Vol 16 N o 2 (1981) pp 189-212 Vol 1 No 3 June 1988 141 10 Clancey, W "The advantages of abstract control knowledge in expert system design' Proc. 3rd Annual Meeting o f th ~ American Assoc..for A rt([~ Intel. (1983) pp 74-78 11 Aiello, L and Levi, G 'The uses o f metaknowledge in AI systems' Proc. European Conf. on Artif. Intel. (September 1984) pp 707-717 12 Clancey, W 'Representing control knowledge as abstract tasks and metarules' in Cooml~, M and Bolc, L (eds) Springer-Verlag, F R G (1985). Also: Stanford Knowledge Systems Laboratory, Working Paper No KSL-85-16 (April 1985) 13 Claneey, W 'The epistemology of a rule-based expert system: a framework for explanation' Artif. lntel. Vol 20 (1983) pp 215-251. Also: Stanford Heuristic Programming Project, Memo HPP-81-17, STAN-CS- 81-896 (November 1981 ) 14 Bundy, A, Byrd, L, Luger, G, Mellish, C, Milne, R and Palmer, M 'Solving mechanics problems using meta-level inference" Proe. Int. Joint Conf. on Artif. lntel. (August 1979). Also in Michie, D (ed.) Expert S.vstems in the Micro Electronic Age Edinburgh University Press, UK (1979) pp 50 64 15 Davis, R 'TEIRESIAS: applications of meta-level knowledge' in Davis, R and Lenat, D B (eds) Knowledge-Based Systems in Artificial Intelligence McGraw-Hill, New York, USA (1982) pp 227~,90 16 Pereira, L M "Logic control with logic' Proc. 1st Int. Logic Programming Conf. (1982) pp 9-18. Also in: Campbell, J A (ed) Implementations ~?fProlog Ellis Horwood, UK (1984) 17 Genesereth, M and Smith, D 'An overview o f meta- level architecture' Proc. 3rd Annual Meeting o f the American Assoc. for Art(f. Intel. (1983) pp 119-124 18 Sterling, L 'Implementing problem solving strategies using the meta-level" DAI Research Paper No 209, Department o f Artificial Intelligence, University of Edinburgh, UK (1984) 19 Silver, B Meta-level InJerence Studies in Computer Science and Artificial Intelligence, North Holland, Amsterdam, The Netherlands (1986) 20 Welham, B 'Peclaratively programmable interpreters and meta-level inferences' Hewlett-Packard Labora- tories Bristol Research Centre Technical Memo No HPL-BRC-TM-86-027 (September 1986). Also in: Maes, P and Nardi, D (eds) Meta-h, vel architectures an'l r~/h, ction North Holland. Amsterdam. The Netherlands (1987) 21 Waltber, C "A mechanical solution of Schubert's steamroller by many-sorted resolution" Proc. 4th Annual Meeting of the American Assoc. Art(f. lntel. (1984) pp 330- 334 22 Cohn, A G 'OL the solution of Schubert's steamroller in many sorted logic" Pro,'. 9th Int. Join t. Con/i on Art(/: lntel. (August 1985) pp 345-352 23 Davies, N "Schubert's steamroller in a natural deduction theorem prover" Proc. 7th Tech. Conf. o f the British Comput. Soc. Specialist Group on Expert Syst. (December 1987) 24 Weyhraueh, R 'Prolegomena to a theory of mechanised formal reasoning' Art(/: hztel. Vol 13 No 1 (1980)pp 133 170 25 Bledsoe, W 'Non-resolution theorem proving" Artif. Intel. Vol 9 No I (1977) pp I--35 26 Gallaire, M and Lassetre, C 'Meta-level control for logic programs" in Clark, K and Tarnlund, S (eds) Logic Programming Academic Press. UK (1982) pp 173 188 27 Shapiro, E "Logic programs with uncertainties: a tool for implementing rule-based systems" Proc. 8th Int. Joint Conf. on Art(f. lntell. (August 1983) pp 529-532 28 Reichgelt, H and van Harmelen, F "Relevant criteria for choosing an inference engine in expert systems" Proc. 5th Tech. Conf. o f the British Comput. Soc. Specialist Group on Expert Syst. (December 1985) pp 21--30 29 Reichgelt, H and van Harmelen, F "Criteria for choos- ing representation languages and control regimes for expert systems" The Knowledge Eng. Rev. Vol I No 4 (December 1986) pp 2-- 17 30 Gordon, M, Milner, R and Wadsworth, C Edinburgh LCF." a mechanized logic o f computation Springer- Verlag Lecture Notes in Computer Science, Vol 78 Springer-Verlag, F R G (1979) 31 Reichgelt, H 'Semantics for a reified temporal logic" Proc. 1987 A I S B Conf. (April 1987) pp 49 62 32 Altman, R B and Bwehanan, B G 'Partial compilation of strategic knowledge' Proc. 6th Annual Meeting o[ the American Assoc. /or ,4rt(/~ lntel. (July 1987) pp 399- 404 142 Knowledge-Based Systems