A Formalisation of Knowledge-Level Models for

A Formalisation of Knowledge-Level Models for Knowledge Acquisition∗ Hans Akkermans†

Frank van Harmelen‡

Guus Schreiber‡

Bob Wielinga‡

†

Software Engineering & Research Department Netherlands Energy Research Foundation ECN P.O. Box 1, NL-1755 ZG Petten (NH), The Netherlands e-mail: [email protected] ‡

Department of Social Science Informatics University of Amsterdam Herengracht 196, NL-1016 BS Amsterdam, The Netherlands e-mail: [email protected] This paper will appear in the International Journal of Intelligent Systems

Abstract This paper defines second-generation knowledge acquisition as a modelling activity that is knowledge-level oriented. Knowledge-level models of expert reasoning represent an important output of the knowledge-acquisition process, since they describe, in a conceptual and implementation-independent fashion, the different roles and types of knowledge required for a problem-solving task. We argue that a formalisation of such models enhances knowledge acquisition, and in particular the conceptualisation phase, by rendering currently informal concepts and intuitions more precise, thus also contributing to a more solid basis for KBS design, validation and maintenance. A framework is constructed for the formal specification of knowledge-level models. The proposed formalism, called ml2 , has been inspired upon the kads methodology for KBS development, and aims at expressing different roles and types of knowledge components through employing an order-sorted logic, a modular structuring of theories and a meta-level organisation of knowledge, comprising ‘enlarged’ reflection rules and a ‘meaningful’ naming relation. An application of the formal specification method to heuristic classification is given. Issues relating to the epistemological adequacy and the computational tractability of formalised knowledge-level models are discussed. ∗ The research reported here was carried out in the course of the REFLECT and KADS-II projects, partially funded by the ESPRIT Programme of the Commission of the European Communities as project numbers P3178 and P5248. The partners in the REFLECT project are the University of Amsterdam (NL), the Netherlands Energy Research Foundation ECN (NL), the National German Research Centre for Computer Science GMD (D) and BSR Consulting (D). The partners in the KADS-II project are Cap Gemini Innovation (F), Cap Gemini Logic (S), the Netherlands Energy Research Foundation ECN (NL), Entel (ESP), IBM France (F), Lloyd’s Register of Shipping (UK), the Swedish Institute of Computer Science (S), Siemens AG (D), Touche Ross Management Consultants (UK), University of Amsterdam (NL) and the Free University of Brussels (B).

1

Introduction

Knowledge acquisition is increasingly considered to be a model-based activity . This is in contradistinction to the traditional ‘extract–transfer–and–simulate’ view, in which knowledge acquisition is seen as extracting knowledge from a human expert, transferring or translating this into a knowledge representation, and mimicking or simulating the human problem solving in a knowledge-based system (KBS). In the model-based approach to knowledge acquisition [1; 2], engineer-type models are constructed that relate to various (restricted) aspects of interest of problem-solving knowledge and that are able to perform certain problem-solving functions. Recent research in second-generation knowledge-based systems [3; 4; 5; 6; 7] elaborates the viewpoint originated by Clancey [8] that this modelling of problem solving should be carried out at a conceptual level that abstracts from implementation detail: Newell’s ‘knowledge level’ [9]. Thus, second-generation knowledge acquisition (as we may call it) has two basic characteristics: it is (i) model-based and (ii) knowledge-level oriented. In this broad context, the present work investigates the need for and methods for the formal description of knowledge-level models, in order to support the conceptualisation stage of knowledge acquisition. It does so particularly in the framework of the kads methodology for structured KBS development [1; 7].

1.1

Second-generation knowledge acquisition

Knowledge acquisition still has many features of an art rather than a science. If it is to become a mature branch of engineering science, it follows from the above that knowledge acquisition should have as its foundation a practical knowledge-level theory of problem solving that is shared by the discipline. The cited work on second-generation expert systems might be viewed as an attempt to carry out such a research programme concerning the foundations of knowledge acquisition and engineering. Within this programme, we may distinguish a number of important research topics: 1. A knowledge-level typology of problem solving: A first issue is to establish a typology of the roles and the kinds of knowledge that are used in problem solving. Much of the cited work is concerned with this problem and has provided us with knowledge types like generic tasks, role-limiting and problem-solving methods, task and inference structures, role annotations, canonical inference steps, the generic elements in the kads four-layer framework, et cetera. Evidently, the terminology involved is quite different and even confusing. Nevertheless, as pointed out in [7], a common view appears to be emerging based on the idea that different types of knowledge constitute the knowledge level, these playing different roles in the reasoning process and possessing inherently different structuring principles. The fundamental concepts of a systematic, second-generation knowledge acquisition would be yielded by a consolidated typology or taxonomy of the knowledge level. 2. Generic knowledge components: Is it possible, on the basis of this typology, to identify stable and recurring components of problem solving that are generic across classes of tasks or domains? Such generic components can be utilised by the knowledge engineer as standardised building blocks for knowledge modelling. For example, 2

heuristic classification [10], cover-and-differentiate [11], propose-and-revise [12] and, generally, work on various other instances of generic tasks, role-limiting methods or kads interpretation models [13] may be mentioned here. 3. Formal specification methods: Can we devise methods for the formal specification of these generic knowledge components, such that their structure and use can be unambiguously expressed at the knowledge level? The knowledge components as mentioned above are described using broad conceptual terminology and/or in implementational terms. Formal descriptions could help to make conceptualisations more precise. Such an ongoing formalisation is a typical element of the historical development of any engineering science. In knowledge acquisition this issue has not received much attention until now — presumably because the purely conceptual aspects have not yet become stabilised — but initial proposals were put forward in [14; 7; 15; 5; 16], and are further worked out in this paper. 4. Computational properties of knowledge-level components: Any knowledge-level approach to knowledge acquisition has an inherently dual nature. On the one hand, it focusses on the knowledge level. This brings with it model descriptions that have a conceptual, epistemological flavour. In a way, it may be regarded as ‘the engineer’s kind of applied epistemology’. On the other hand, it cannot neglect the program or symbol level [9], the ultimate goal being to end up with a working computational system. This duality poses a non-trivial problem, since epistemological adequacy and computational adequacy of knowledge models do not necessarily coincide. The research issue then is to clarify in what ways (epistemological) role limitations [6] of knowledge relate to (computational) access limitations. 5. Operationalisation in informed and knowledgeable knowledge-acquisition tools: How can generic knowledge components be operationalised as parts of a knowledgeengineering workbench, to be instantiated or configured for specific applications? This is a generalisation of the idea underlying the recent work of [17] carried out in a medical domain. Along such lines, second-generation knowledge-acquisition tools could be developed that are informed and knowledgeable about a knowledge-level theory of problem solving. This paper will focus on the formalisation issue, but it will make remarks on some of the other issues as well.

1.2

Formalisation of knowledge models

The traditional view on KBS development is to consider it as a conceptualisationformalisation-implementation cycle [18]. Here, formalisation is seen as the mapping of the concepts and structures of the domain onto a knowledge representation, such as frames or rules, and a corresponding programming environment. The knowledge-level approach has especially advanced the conceptualisation stage, by developing a domain-independent and implementation-independent vocabulary of knowledge types, and by providing generic knowledge models for a variety of tasks. This paper studies the question what kind of formal framework is suitable for supporting the knowledge-level approach.

3

Thus, the present work takes a view on formalisation that differs from the traditional KBS approach: our primary concern is not to construct (yet another) knowledge representation, but to investigate formal methods to be used in the conceptualisation stage. This does not mean that representational or computational issues are of completely no concern here. The fact that formal systems have known logico-mathematical properties may be exploited in several stages of KBS development. For example, it can be demonstrated that a specification in a many-sorted or order-sorted logic —one of the proposed elements of our formal framework— is a promising technique for computationally solving certain classes of problems (cf. Schubert’s steamroller) [19; 20]. However, our first consideration to propose an order-sorted logic is the fact that the use of sorts is a natural way to formally express certain knowledge types and roles at the knowledge level. This paper also differs in certain aspects from current knowledge-level approaches, which tend to lead to very informal conceptualisations. The terminology used in describing generic knowledge components like ‘heuristic classification’, ‘cover-and-differentiate’ or canonical inference steps such as ‘abstraction’ is fuzzy and often ambiguous. What is meant precisely becomes clear only by looking at the computational implementation of such notions. This is not what one would like to have within a knowledge-level approach, and a recourse to formal methods is a natural move in order to make progress in conceptual knowledge-level analysis. There is in our opinion no essential difference here with the role that is played by formalism in other sciences, such as the role of applied mathematics within physics and engineering. With this argument in favour of formalisation we do not imply that there is no role for informal conceptualisations. On the contrary, these are indispensable. We do believe however that formal methods will contribute if we want to obtain a real conceptual understanding of what is actually meant by intuitive statements of the kind “these data are abstracted to such-and-such features” or “cover-and-differentiate is a form of heuristic classification”. In our approach, formalisation serves very pragmatic goals and, accordingly, this paper is to be viewed as reporting work from ‘neat scruffies’. The formal framework discussed in this paper appears, on the basis of first experiences, to be helpful in structuring and in more precisely formulating knowledge-level models. It has been inspired by the kads methodology [1; 2]. However, we regard the kads methodology as only one of the specific approaches contributing to a theory of generic knowledge types and components, as is the work on generic tasks [4], role-limiting methods [6], canonical inference steps like in heuristic classification [10] and components of expertise [3]. Since our formal framework employs rather general constructs, it is not restricted to a single knowledge-level approach. On the other hand, in its present state it is probably even too flexible and global. Consequently, the present formalisation seems to constitute a useful attempt or exercise, but it has certainly not yet found a consolidated form. The organisation of this paper is as follows. First, a short recapitulation of the kads methodology for KBS development is given (Sec. 2). In Sec. 3 we construct ml2 , our formalisation framework for knowledge models. An example application concerning heuristic classification is presented in Sec. 4. In Sec. 5 we discuss the proposed formalism in its relation to some of the other research issues pointed out previously concerning secondgeneration knowledge acquisition. A summary is given in Sec. 6.

4

2

Recapitulation of the KADS Methodology

In this section we shortly recapitulate the kads methodology for KBS development [1; 2; 13], because it has served as an important source of inspiration for our formalisation framework. This section has been included in order to make this paper self-contained. There is no claim of novelty here and readers familiar with kads may want to skip this section.

2.1

The KBS development process

kads takes the view (and so does this paper) that the development of knowledge-based systems is a modelling activity. A KBS is not a container filled with knowledge extracted from an expert, but an operational model that exhibits some desired behaviour observed or specified in terms of real-world phenomena. The use of models is a means of coping with the complexity of the development process. A model reflects, through abstraction of detail, selected characteristics of the empirical system in the real world that it stands for [21]. In kads, modelling at the knowledge level is an essential intermediate step in the development process [22]. The knowledge-level model defines the types of knowledge that are to be elicited from the expert and that will have to be represented in the system. In addition, modelling at the knowledge level indicates a route towards the use of generic models for certain classes of tasks, since it is independent of the actual details of the system. These generic task models can be used for top-down knowledge acquisition and for system development.

Figure 1: The KBS development process: a bird’s eye view

5

Fig. 1 (taken from [7]) symbolises this view on the knowledge-engineering process. An observer (knowledge engineer) constructs a conceptual model by abstracting from the problem-solving behaviour of experts. This abstraction process is aided by the use of some interpretational framework, such as generic models of classes of tasks or of domains. The conceptual model is a knowledge-level model of expertise. It is real-world oriented in the sense that it is phrased in real-world terminology, and can thus be used as a communication vehicle between knowledge engineer and expert. The conceptual model does not take detailed constraints with regard to the artefact into account. The formal framework discussed in the present paper intends to support this conceptual modelling. The design model is a model of the artefact. It describes how the conceptual model is realised with particular AI techniques and methods. Thus, knowledge representation issues are located at this stage of KBS development. The idea is that the design model can be transformed into a detailed system design and subsequently into actual system code without further major decisions having to be made. According to the kads experience, building a conceptual model without having to worry about system requirements makes life easier for the knowledge engineer. The distinction between the two models is also useful, if one opts for another problem-solving method in the artefact than the one used by the domain expert. For example, if the domain expert uses heuristics to find a particular solution, one may choose to use a exhaustive generate and test method in the KBS, because its computational resources are larger. An explicit representation of both models can in that case be used to explain the differences in behaviour between the system and the expert to a user.

2.2

A four-layer conceptual model

In kads a conceptual framework for the modelling of expertise has been developed, based upon a categorisation of knowledge in accord with the role that it plays in a reasoning process. In this framework four categories of knowledge are distinguished. The first category of knowledge concerns static domain knowledge. This consists of the domain concepts and their attributes, domain facts, structures representing complex relations etc. The static knowledge can be viewed as the layer of knowledge representing a declarative theory of the domain. The static domain knowledge is considered to be largely task neutral, i.e., represented in a form that is independent of its use. There is ample evidence [23] that experts are able to use their domain knowledge in a variety of ways: for problem solving, explanation, teaching, etc. Separating the theory concerning static domain knowledge from its use in a problem-solving process, is a first step towards flexible use and reusability of domain knowledge. A second type of knowledge concerns canonical inference steps. An inference is considered to be an elementary step in the reasoning process deriving new information from existing information. An important characteristic of an inference is the type of information that is used in making the inference and the type of information that it produces. In addition, the inference is characterised by the type of domain concepts and relations it uses. For example, an elementary classification inference takes as input a bundle of features of an object and produces as output a class to which the object can belong, using definitions of the set of classes that the system knows about. The type of the information used or produced by a canonical inference is indicated by what is called in kads a metaclass (e.g., 6

datum, feature, hypothesis, solution). In the terminology of the kads four-layer model inferences are called knowledge sources. With respect to a taxonomy of canonical inferences there is no consensus in the literature. The most well-known collection of canonical inference steps is found in Clancey’s model of heuristic classification [10]. In this model the inferences are: abstraction, association and refinement. Within kads a somewhat larger set of canonical inferences is assumed. Example additions are transformation, selection and computation. A full description of this set can be found in [13]. The third category contains knowledge about how elementary inferences can be combined to reach a certain goal. The prime knowledge type in this category is the task. A task can be defined statically (a control structure with the usual control primitives) or dynamically (as a planner function which interprets descriptions of the second category). Tasks satisfy a particular goal. The relations between tasks and goals are in principle many-to-many. Task knowledge is usually characterised by a vocabulary of control terms, for instance indicating that a finding has been processed or a hypothesis has been verified. The fourth category of knowledge is the strategic knowledge. Strategic knowledge determines what goals are relevant to solve a particular problem. How each goal is achieved is determined by the task knowledge. Strategic knowledge will also have to deal with situations where the afore-mentioned knowledge categories fail to produce a partial solution. For example, the problem-solving process may reach an impasse because information is not available or because contradictory information is produced. In such cases the strategic reasoning should suggest new lines of approach or attempt to introduce new information e.g., through assumptions.

Figure 2: The kads four-layer model These categories can be seen as knowledge layers in the sense that each successive layer interprets the description at the lower layer. In Fig. 2 the four categories and their interrelations are summarised. The four-layer framework for knowledge modelling has been successfully used as a basis for structured acquisition and description of knowledge 7

at an intermediate level between the verbal data obtained from experts and the knowledge representation in an implemented system [24]. From a knowledge-level viewpoint, the present four-layer model captures knowledge types that are quite similar to those encountered in other models in the literature. As alluded to before, an important problem common to all approaches is that they are formulated in a rather informal and therefore ambiguous manner. Accordingly, in the following section we will construct a formal framework for a more precise specification of knowledge models.

3

Formalising Knowledge Models

In this section we will first present some general considerations leading to a framework for a formalisation of knowledge models that we call ml2 . Secondly, we will discuss the major ingredients of ml2 , namely order-sorted logic, modular theories, ‘meaningful’ naming relations and ‘enlarged’ reflection rules. The framework presented below assumes a KADSlike approach to knowledge modelling, but we suspect that ml2 is in fact more general than simply a formalisation of KADS models. A number of features of ml2 (such as modular theories and a meta-level organisation) will most likely be useful for describing other knowledge-level models as well.

3.1

Ingredients of the formal framework

Although we will use logic as the basis for ml2 because of its long history and established position as a tool for formal analysis, we will not state the case for the use of logic in AI here, since it has been made adequately before [25; 26; 27]. We only remind the reader of advantages such as a formal semantics, the possibility for stating incomplete information (disjunction, existential quantification), and well-understood properties such as completeness, soundness and (semi)-decidability. Moore [27] distinguishes three levels at which logic can be used in AI, namely as an analytic tool, as a representational mechanism, and as a computational mechanism. We are using logic only at the first two of these levels, and make no claim about logic as a computational mechanism (unlike for instance [28]). 3.1.1

Order-sorted logic

First of all, we propose to use not a simple first-order language, but instead to use an ordersorted language (for an overview see, e.g., [20]). This is a language in which all variables and constants have sorts (types) associated with them, with these types organised in a subsort hierarchy. Functions and predicates are also typed (according to the types of their arguments, and, for functions only, their results). The inference rules of the logic take into account that two terms can only match if there are appropriate subsort relationships between their sorts. Previous work in AI [29; 30] has shown these languages to have a number of advantages. These include the reduction of the number of axioms, the reduction of the length of logical formulae, a reduced search space during deduction, and increased human readability. Furthermore, sorts provide a natural formal construct for knowledge roles that are distinguished at the knowledge level.

8

Such an order-sorted first-order language is a conservative extension of a normal firstorder language, in the sense that everything that can be expressed and deduced in an order-sorted language can also be expressed and deduced in an unsorted language, and vice versa [19]. Many authors in AI have argued in favour of richer logics than just a first-order predicate logic, as witnessed by the plethora of such languages in recent years (epistemic, temporal, uncertain, multi-valued, non-monotonic, etc). Although we do not explore these avenues in this paper, such approaches are wholly compatible with the formalism we propose here, and may well prove useful in the kads framework. Our current formalisation can be seen as entirely parametrised over the choice of the logical language, very much in the spirit of Socrates [31]. 3.1.2

Modular systems

Furthermore, we want a mechanism that allows us to express our theories in a modular way. Instead of having to state all our axioms in a single large theory, we split our set of axioms into a number of sub-theories, which can then be combined using a small set of meta-theoretic operators. In ml2 , we currently use set-theoretic union as the only way of combining theories into larger ones, but more sophisticated operators have been proposed in the literature: [32] in the context of an algebraic specification formalism and [33] for logical theories. Again, the subtheory extension we use here is a conservative one, in the sense that it does not alter the expressive or inferential power of the system over and above a single first-order theory. For an extensive formal investigation into the properties of module systems, see [34]. 3.1.3

Meta-level theories

Next, given the multi-level nature of the kads methodology as described in section 2 (a feature we also encounter in other knowledge-level theories), it seems desirable to try and represent this layered structure in ml2 . This should give us not only a multi-theory system within one level (as suggested in the previous paragraph), but a system with theories at different levels. Such theories on different levels will have to be ‘connected’ to each other (unlike the theories within a single level), in the following ways: 1. Expressions in a higher level theory will have to be able to refer to expressions in a lower level theory (or equivalently, expressions in a lower level theory will need names in a higher level theory). 2. Inference in a theory at one level will need to be able to ‘affect’ inference in a theory at another level. These two requirements will bring ml2 into the realm of meta-level or reflective theories. Rather than giving an extensive overview of the work that has previously been done on such formalisms, we list a number of important references: [35] for some of the early work in logic on reflective systems, [36] and [37] for some early reflective systems in AI, [38] for a good introduction to the terminology and the literature, and [39] for a collection of some recent work in this area. Using the established terminology, we call theories which are at a lower level ‘object-level theories’, whereas the theories that refer to these object-level theories are called ‘meta-level theories’. 9

In such a multi-level framework, a choice has to be made made regarding the relation between the languages used in the theories at the different levels. The theories at a single level can be combined using set-theoretic union, and will therefore share the same language, but no such requirement exists between theories on different levels. In particular, if we take M and O to be the languages for theories M and O which are of different levels, than two different options often chosen in the literature are O ⊆ M1 and M ∩ O = ∅2 . Taking O ⊆ M leads to problems of inconsistencies and paradoxes based on self-reference (see for instance [40]), which can be avoided by taking M ∩ O = ∅. However, in this option certain sentences of a reflective nature are no longer expressible. In particular, in theory M , we can state properties of sentences in language O, but we cannot state properties of sentences in language M. For this, we would need to introduce another meta-level theory, say M 0 , with language M0 such that M0 ∩ M = ∅, but then, again, we would not be able to state properties about sentences in M0 , etc. See [40], [41], [42] and [43] for discussions of the merits of these two approaches. Following [40] and [43] we choose for a system with separate languages for theories at different levels, in order to avoid the self-referential paradoxes. The price we pay for this (making certain self-referential statements inexpressible) is not very high, since such statements do not naturally occur in kads models (and, as far as we know, also not in other current knowledge-level theories of knowledge-based systems) which are after all the subject of our formalisation. This separation of languages related to different levels still leaves open the formal possibility to have a circularity in the meta-relation, that is, the possibility that a meta-theory has as its object its own meta-theory. Since kads (and other knowledge-level theories) are intuitively interpreted as a linear chain of meta-levels, we will in the following exclude this possibility of having circularities. 3.1.4

Meaningful names

To fulfil the first requirement pointed out above for a meta-level framework, we need what is called in logic a ‘naming relation’: expressions in a meta-level theory refer to (are the names of) expressions in an object-level theory. For technical reasons it is required that these names are ground terms (not containing variables), but otherwise we are free to choose the naming relation. Logicians (e.g. [44]) distinguish two types of names, the so-called quotation-mark names, and the structural-descriptive names. Quotationmark names turn an expression of an object-level theory into an atomic constant in the meta-level theory. For an expression P , such constant is often written dP e. Structuraldescriptive names turn expressions into more complex terms in the meta-level theory, where these terms reflect the structure of the object-level expression. An example would be the name all(var1,all(var2,impl(2pred(p,var1,var2),2pred(p,var2,var1))))

in M for the following sentence in O which asserts the symmetry of predicate p: ∀x∀y[p(x, y) → p(y, x)]. (Notice that the variables x and y in O are named by constants var1 and var2 to obtain a ground term in M, and that all predicates, logical constants and quantifiers in O are named by function symbols in M). 1 2

A construction known in the literature as the amalgamation of object- and meta-level theories. The obvious way of obtaining M ∩ O = ∅ is to create M and O from disjoint alphabets.

10

Instead of using these quotation-mark and structural-descriptive names we propose a new kind of naming relation, giving what we will call meaningful names. Such meaningful names will be determined not only by the syntax of an expression at the lower level, but also by the ‘knowledge’ role that an expression plays in this theory. As other knowledgelevel theories, the kads methodology makes epistemological distinctions between elements of the object-level (domain) theory, and such distinctions must be formally representable in our framework. Thus, the idea of meaningful naming is a natural consequence of the idea of conceptual modelling at the knowledge level. A typical example (which will also occur in the example formalisation presented in the next section), is that certain implication sentences in the object-level theory, although having the same syntactic structure, actually play very different roles in the inference process. Therefore, we propose to employ the naming relation to make this distinction explicit in the meta-level theory. This implies that it will not suffice to have a naming relation that is uniform over the syntax of the entire object-level theory. Instead, this naming relation will have to be defined as an integral part of the knowledge model. For this purpose we use the lift-operators described below. On top of the sorts that we employ within a theory, this meaningful inter-theory naming operation is a second support for the knowledge-level notion of role limitations. 3.1.5

Reflection rules

Reflective systems provide us with a device to realise the second requirement. Rules that specify how inference in one theory affects the contents of another theory are called reflection principles. A very simple reflection rule or principle would be: ` ∆MP rovable(dOe, dP e) , ` ∆OP which states that if dP e is derivable from dOe in (meta-)theory M, then P is a theorem of (object-level) theory O, where dP e and dOe are the names in theory M of sentence P and theory O respectively. This reflection principle is in fact the one used in the system described in [42]. From a knowledge-level perspective, reflection principles are of interest, since they enable us to express how to use or to reason about a given piece of knowledge (i.e., a given theory). We point out, however, that the reflection rules that suit our purpose are so-called enlarged reflection rules [38] in the sense that they do not necessarily constitute a conservative or truthful extension of the theory. This is further discussed below and in Sec. 5. After this general discussion of the various properties of our formalisation — a logicbased formalism in a order-sorted first-order language, with modular and multi-level theories, connected by module operators, enlarged reflection principles and an epistemologically inspired meaningful naming relation — we will discuss the individual formal constructs in more detail in the following subsections.

3.2 3.2.1

Constructing modular theories Languages

Before discussing the actual syntax of ml2 , it is important to realise the different languages that play a role in our system. First of all, there is O, the syntax of order-sorted first11

order predicate calculus which is used to express object-level theories. A second language M is used to express meta-level theories. Although of the same type (also order-sorted first-order predicate), this language is entirely separate from O, for the reasons discussed above. Thirdly, there is the language F that we use to describe the languages O and M, and the connections between them (reflection principles and naming relation). This third language has a status different from both O and M: it does not specify the contents of a formalised knowledge model, but rather the abstract form of it. The situation can be depicted as in Fig. 3.

M∆1

M∆n

...

dO∆1e 6

dO∆ne F

lift

...

O∆1

6

lift

O∆n

Figure 3: Relation of languages in the specification framework Thus, whereas the languages O and M are to be defined by the user (or at least the non-logical part of it), the language F is fixed, and it is indeed by using the constructs from F that the user defines both O and M. 3.2.2

Theory constructors

The most basic construction in ml2 is the formation of a theory, using the theory constructor. Formally, a theory T consists of a signature Σ (defining a language), plus a set of axioms A (constituting a knowledge base) which are expressed in this language: theory = < Σ, A > . Such a theory is specified as follows

3,4 :

theory theory name import theory name ? signature sorts sort tree constants (constant ? :sort) ? 3 We do not give a formal definition of the syntax of our formalisation, but instead give an intuitive idea of this by discussing its notation. For this purpose, we will use bold font for terms from the language F . Words written in italic are placeholders, to be replaced by terms supplied by the user (that is, terms in either O or M). The ? operator indicates zero or more repetitions of the preceding term. 4 Our theory constructor is very much inspired by algebraic specification languages (see for instance [34]).

12

functions (function:sort ? → sort) ? predicates (predicate:sort ?) ? variables (variable? :sort) ? end signature axioms lists of axioms end axioms end theory This defines a theory with a theory name, containing a list of axioms, which are expressed in terms of predicates, functions, constants, and variables, each of which has to obey a type specification. The type of a constant and a variable is specified by a single sort, the type of an n-ary predicate is specified by an n-tuple of sorts, and the type of an n-ary function is specified by an n + 1-tuple of sorts. The sort tree is textually expressed as a nested list of sorts, where the structure of the list specifies the subsort relationships. (This notation implies that sorts are only allowed to have one supersort, in other words: the sort hierarchy is a tree). The collection of sorts, variables, constants, functions and predicates of a theory is called the signature of that theory. Apart from the elements of the signature, the axioms can also use the logical constants of firstorder predicate calculus with equality (equality =, conjunction ∧, disjunction ∨, negation ¬, implication → and equivalence ↔). We also allow the usual set-theoretic operations as part of the language to be used in the axioms. This means that for any predicate p, we can use the following construction to denote the extension of p: {(x∆1, . . . , x∆n)|p(x∆1, . . . , x∆n)}. On such sets we allow the usual set-theoretic predicates (membership ∈ and containment ⊂) and functions (intersection ∩ and union ∪). In order to avoid repetitious typed quantifiers in the expressions, all variables occurring in the axioms are implicitly universally quantified over the specified type. Existential variables or universal variables with a scope smaller than the entire sentence need to be quantified explicitly. Apart from the signature of a theory, axioms can also use predicates, functions and constants that are defined in the signature of any imported theory. An import operation results in the union of the signatures and axioms of the importing and the imported theory. Formally: < Σ∆1, A∆1 > import < Σ∆2, A∆2 > = < (Σ∆1 ∪ Σ∆2), (A∆1 ∪ A∆2) > . Standard mechanisms are available from algebraic specification languages to resolve possible name clashes resulting from such import operations, by using a renaming operation. A useful extension of the module operations would be an export operator, which allows only part of the signature of a theory to become available as the result of an import. A further extension would be in the form of the parametrisation of theory declarations, which allows theories to be parametrised over as yet unknown signatures. Such extensions have been well investigated elsewhere (e.g., [34]), and for the sake of simplicity we will not present any of these extensions here.

13

3.3 3.3.1

Constructing naming relations Lifting to a meta-level

The second basic construction in ml2 is the lift-operator, which is used to define a naming relation between theories. The relation lift has to be a mapping from terms of one theory to ground terms in another theory, but how this mapping is to be done, must be defined according to the particular conceptual kads model that is being formalised. Thus, we expect a lift-operator to specify an input language (part of the object-level language), an output language (part of the meta-level language), and a mapping from input terms to output terms. More precisely: lift: L∆O → L∆Mgt , stating that lift is a mapping with domain L∆O, the language of the object-level theory, and with range L∆Mgt , the fragment of the meta-theory language consisting of the ground terms. We specify such a lift-operator as follows: lift-operator operation name from object-level theory name ? to meta-level theory name ? signature sorts sort tree constants (constant ? :sort) ? functions (function:sort ? → sort) ? end signature metavariables (var ? :metatype) ? mapping (lift(obj-theory,term 1) 7→ term 2) ? end mapping end lift-operator We see that a lift-operator defines a variable-free signature5 (the one corresponding to the mentioned meta-language of ground terms), plus a set of rewrite rules that define the behaviour of the lift mapping. This signature can then be used by other (meta-level) theories (specified in the to clause), allowing them to refer to terms from the object-level theory. This is done through a use operator clause in a meta-level theory. When a liftoperator is used in a meta-level theory, we construct the union of the signature of the theory and the (meta-)signature produced by the lift-operator. Thus, an important difference between an imported theory and a used lift-operator is that an import results in the union of both axioms and signature, whereas a use results only in the union of the signatures. Formally: lift

< Σ∆1, A > use (L∆O → L∆Mgt ) = < (Σ∆1 ∪ Σ∆L∆Mgt ), A >, where Σ∆L∆Mgt is the signature underlying the language L∆Mgt . 5

Notice that the metavariables are not part of the signature.

14

The fact that the meta-level theories named in the to clause of a lift-operator will themselves contain a use clause mentioning the name of the same lift-operator constitutes a slight redundancy in ml2 , but makes it easier for the human reader to keep track of dependencies between theories and lift-operators. 3.3.2

Mapping rules between levels

The mapping of a lift-operator defines the behaviour of lift on the languages of theories mentioned in the from clause. The rules are of the form lift(theory, term∆1) 7→ term∆2, where theory is one of the theories mentioned in the from list, term∆1 is a term in the language defined by the signature of theory plus the specified metavariables, and term∆2 is a term in the language defined by the lift-operator’s signature plus the metavariables occurring in term∆1. The metavariables are introduced to allow the expression of mapping rules via schemas. They must be of a metatype (one of: variable, constant, function, term, predicate or sentence, organised in the obvious type hierarchy, and the second-order types function symbol, predicate symbol or logical symbol), and range over the corresponding expressions in the language of the object-level theory. Thus, lift rules can be expressed either by specifying the behaviour of lift on a particular term of the object-level language (when term∆1 is a ground term of the object-level theory), or by specifying its behaviour on a class of terms of the object-language (when term∆1 contains metavariables) by means of schemas. If theory is unspecified, the rule is a shorthand for the set of rules with all possible values for theory (i.e., all theories mentioned in the from list). This default means that we never have to mention the first argument of lift if the from clause contains only one element. 3.3.3

A simple example

A simple example of an object-level theory and a corresponding lift-operator is: theory naturals signature sorts nat constants 0:nat functions s:nat → nat plus:nat × nat → nat predicates even:nat × nat variables x, y:nat end signature axioms plus(0, y) = y plus(s(x), y) = s(plus(x, y)) end axioms end theory lift-operator super-natural from naturals 15

to cost-of-naturals signature sorts (exp (term eqn)) constants6 zero, “plus”, “x”, “y”:term functions baseeqn:term × term → eqn stepeqn:term × term → eqn f n:term × term × term → term succ:term → term end signature metavariables N ∆1, N ∆2:term V ∆1, V ∆2:variable F :f unctionsymbol mapping7 lift(0) 7→ zero lift(s(N ∆1)) 7→ succ(lift(N ∆1)) lift(V ∆1) 7→ “V ” lift(plus(N ∆1, N ∆2)) 7→ f n(“plus”, lift(N ∆1), lift(N ∆2)) lift(F (0, V ∆1) = N ∆1) 7→ baseeqn(lift(F (0, V ∆1)), lift(N ∆1)) lift(F (s(V ∆1), V ∆2) = N ∆2) 7→ stepeqn(lift(F (s(V ∆1), V ∆2)), lift(N ∆2)) end mapping end lift-operator The theory naturals defines the standard structure for natural numbers, with addition. The lift-operator classifies the defining axioms from the theory naturals into two categories, namely step equations and base equations. Every equation from the naturals theory that has zero as the first argument on its left hand side is a base equation, otherwise it is a step equation8 . Notice that some parts of the lift mapping have been defined by explicitly relating terms in the input language (the language from the theory naturals) to ground terms in the output language, whereas other parts of lift have been defined by universally quantified rules. Even this very simple lift-operator can be used by a meta-level theory to state properties of the naturals object-level theory: theory cost-of-naturals use super-naturals signature sorts effort constants cheap, expensive:effort functions cost:eqn → effort 6

A useful notational convention we often employ is to not declare constants in lift-operators. This leaves their type unspecified, but by convention their type is taken to be the smallest type that is consistent with all positions in which they occur in the mapping. If this convention does not result in the intended type of a constant, the constant must be declared explicitly. 7 In this example we have not employed the shorthand mentioned in the previous paragraph that allows us to leave out the theory argument to the lift mapping if the from clause contains only one theory. 8 These theories only serve as an example. We do not claim these are particularly useful, interesting or even sensible theories.

16

variables lhs, rhs:term end signature axioms cost(baseeqn(lhs, rhs)) = cheap cost(stepeqn(lhs, rhs)) = expensive end axioms end theory 3.3.4

Properties of the lift mapping

So far we have not said anything about the general properties that we would expect a naming relation to have. Unlike the traditional naming relations employed by logicians (as described in section 3.1), we do not necessarily require our lift mapping to be a function (which would mean at most one value in its range for each element of its domain). As a result, the property ((lift(t, x) 7→ y∆1) ∧ (lift(t, x) 7→ y∆2)) → y∆1 = y∆2 need not hold; lift is allowed to be one-to-many. lift is a naming relation and is deliberately written lift(theory, exp) 7→ name, instead of lift(theory, exp) = name. This allows us to give multiple names to an object-level expression, which may be useful if the same object-level expression plays multiple roles in a conceptual model. For instance, the consequent Q of an object-level implication P → Q may be viewed as an abstraction of the antecedent P or, alternatively, P may be seen as a specialisation of Q. Therefore, P → Q might at the meta-level play the role of both an abstraction rule and a specialisation rule. We note that giving multiple names forms a conservative extension: instead of giving multiple names (such as dabs(P, Q)e and dspec(P, Q)e) to the object-level sentence P → Q and formulating different meta-level axioms about the different names, one could simply use a single name dP → Qe and make the meta-level axioms conditional: abs(dP → Qe) → . . . and spec(dP e, dQe) → . . .. Thus, just as the sorted language we use does not extend the logical power of its unsorted fragment, allowing lift to be non-functional does not extend the power of the system. Furthermore, there is obviously no need for lift to assign a name to every term in its domain (in other words, lift need not be total, which means we do not have ∀x∃y[lift(t, x) 7→ y]). This is even a desirable property, because it gives a handle to restrict the size of the meta-theory as well as the needed access to the object-level theory. Again, this is unlike the traditional naming relations in the literature. Next, not every expression in the meta-level language has to be a name for an object-level expression, thus lift need not be surjective (we do not have ∀y∃x[lift(t, x) 7→ y]). Since we will rely on the inverse operation of lift (written lift −1 ) to be a function, however, we do require lift to be injective (that is, no element in the range of lift is the name for more than one element in the domain of lift: ((lift(t, x∆1) 7→ y) ∧ (lift(t, x∆2) 7→ y)) → x∆1 = x∆2). All in all, we require lift to be an injective relation, but it may or may not be functional, surjective or total. When importing a lift-operator, a meta-level theory imports the corresponding signature, and it can thereby refer to terms of the lifted object-level theories which are declared in the from clause of the lift-operator. As well as referring to the terms in an object-level theory, a meta-level theory often needs to refer to the name of that object-level theory itself. To make this possible a single constant is implicitly declared in the imported signature of the lift-operator, namely a constant equal to the name of the object-level theory (the value of the from clause), which will be of type theory. This constant will

17

for instance be needed for the realisation of the reflective predicates discussed in the next section.

3.4

Reflective predicates and reflection rules

In ml2 so far we can construct multiple theories within a single level (the theory construction), and theories at different levels with a naming relation between them (the lift-operator construction). However, we have not yet established a mechanism by which inference in one theory can affect the other theory. For this purpose, we define a small number of reflective predicates, whose behaviour will be defined by reflection rules. We notice that reflection rules are almost like ordinary inference rules, except that they have their premise and conclusion situated in different theories. These rules are similar to the ‘bridging rules’ described in [45]. 3.4.1

The ask predicate

The first and most elementary reflective predicate allows us to inquire about another theory. This predicate, ask ∆ `, is defined by the following reflection rule: ` ∆OP ` ∆Mask ∆ ` (dOe, dP e)

(1)

Rule (1) states that if P is derivable in the object-level theory O, then ask ∆ ` (dOe, dP e) is derivable in the meta-level theory M, where dP e and dOe are the names of sentence P and object-level theory O as usual. Notice that we do not only use names of object-level sentences, but we also need the name of the object-level theory. As usual, such an inference rule can be read in either a forward or a backward direction: if we infer P in O, we can infer ask ∆ ` (dOe, dP e) in M (forward), or: if we want to infer ask ∆ ` (dOe, dP e) in M we need to infer P in O. Rather than asking if a given object-level formula is provable in an object-level theory, a second reflective predicate allows us to ask if it is indeed an axiom of the theory. This distinction is never made in the logical literature, and indeed there is no need to do so on purely logical grounds, but on both epistemological and computational grounds there are good reasons to distinguish between an axiom of a theory and a derived conclusion of a theory. This is expressed by the predicate ask ∆ ∈, defined by the following reflection rule: P ∈O ` ∆Mask ∆ ∈ (dOe, dP e)

(2)

where P ∈ O is true iff P is an axiom of O. Since this rule contains the ∈ predicate on sets of axioms (theories), we have to decide which notion of equality among logical sentences we use as part of the membership test. One possibility would be to restrict equality between sentences to alphabetic variancy: P = Q iff P and Q are syntactically equal modulo the renaming of variables. A much more liberal possibility would be to take logical equivalence (↔) as the definition of equality. This would of course greatly enhance the logical power of the ask ∆ ∈ predicate, but would make its computational interpretation nearly as problematic as that of ask ∆ `.

18

Versions of equality that lie in between these two options are also possible (for instance equality under alphabetic variancy plus associativity, commutativity and idempotency of the logical connectives). Further experience with applications of the proposed framework will be needed to decide this issue. For the application of the framework in the next section, the interpretation of equality as alphabetic variancy suffices. For both of the predicates ask ∆`, ∈ we allow a shorthand notation where the first argument (the name of the object-level theory) is left out. This shorthand is to be read as if the theory name was an existentially quantified variable (thus: ` ∆Mask ∆ ∈ (dP e) means that P is true in some theory). As exemplified in our example specification, this shorthand is useful if the name of object-level theory can be uniquely determined on the basis of the name of the expression P (i.e., when only a single object-level theory O contains expressions that are named by expressions that match the single argument of ask ). 3.4.2

The tell predicate

Both of the above ask ∆`, ∈ predicates are ‘upward’ reflection rules, since properties of the object-level theory O influence the provability in the meta-level theory M. We can also consider ‘downward’ reflection rules, where provability in the meta-level theory M influences provability in the object-level theory O. More precisely, in a downward reflection rule, a property of the object-level theory is inferred from the assertion of that property in the meta-theory. We define a downward reflective predicate tell ∆ ∈ as follows: ` ∆Mtell ∆ ∈ (dOe, dP e, dO0 e) Q ∈ O0 iff Q ∈ O or Q = P

(3)

This rule states that O0 is a theory with the same axioms as O plus axiom P . The rule uses equality between logical sentences in O in its consequent, a suitable definition of equality must be chosen, as discussed above. We write the tell ∆ ∈ predicate as a three-place predicate and not as tell ∆ ∈ (dOe, dP e), because this would destroy the declarative semantics of the reflective predicate: in contrast to the two-place version, the three-place predicate preserves the property that the theory name suffices to determine (the set of axioms of) a theory. A given theory name is thus uniquely related to a theory or axiom set, but note that the converse is not true: a theory or knowledge base may have more than one name. 3.4.3

The del predicate

A third type of reflective predicate (again downward) allows us the reduce the contents of another theory: ` ∆Mdel ∆ ∈ (dOe, dP e, dO0 e) (4) Q ∈ O0 iff Q ∈ O and Q 6= P which may be compared to rule (3) above. Rule (3) creates a new theory by ‘adding’ an axiom to the old theory, whereas rule (4) ‘removes’ an axiom from the old theory. As with rules (2) and (3), an appropriate choice for the equality between sentences must be made for this rule. 19

All the above reflective predicates and their corresponding inference rules (1)–(4) are a predefined part of our formal framework in the same way as the logical connectives such as conjunction, disjunction. Just as these logical connectives, they are implicitly part of the language of any theory. Future experience with our formalisation must decide whether this set of reflective predicates is indeed adequate for our purposes. On the basis of these reflection rules, the following intuitively expected consequences are now indeed derivable as tautologies of any meta-level theory: tell ∆ ∈ (dOe, dP e, dO0 e) → ask ∆ ∈ (dO0 e, dP e) ask ∆ ∈ (dOe, dP e) → ask ∆ ` (dOe, dP e) del ∆ ∈ (dOe, dP e, dO0 e) → ¬ask ∆ ∈ (dO0 e, dP e)

The conclusion of the last implication should be compared to ask ∆ ∈ (dO0 e, d¬P e), which illustrates the difference between ‘not inferring P ’ and ‘inferring not P ’. 3.4.4

Meta-modelling of object-level reasoning

With the above collection of reflective predicates, we can add as axioms meta-level sentences in order to model different types of object-level reasoning. A few examples of such meta-level sentences are: • ¬ask ∆ ` (dOe, dP e) → tell ∆ ∈ (dOe, d¬P e, dO0 e) corresponds to a closed-world assumption: if P is not provable, then assume ¬P . • ¬ask ∆ ∈ (dOe, d¬P e) → tell ∆ ∈ (dOe, dP e, dO0 e) corresponds to (a form of) default reasoning: if the negation of P is not provable, then assume P in an enlarged theory. This allows us to keep track of which further inferences are based on the assumption of P , namely all inferences made in O0 , or in theories constructed from O0 . • ask ∆ ` (dOe, dP e) → tell ∆ ∈ (dOe, dP e, dO0 e) is logically a no-op, but corresponds computationally to caching. • tell ∆ ∈ (dOe, d¬P e, dO0 e) ∧ ask ∆ ` (dO0 e, dfalsume) → ask ∆ ` (dOe, dP e) is a formalisation of reductio ad absurdum, the inference rule that is denied by intuitionism. Other standard inference rules of predicate logic can be formalised in a similar fashion. • contains−only−equivalences(dP e)∧ (sentential−symbol(S) ∧ occurs(S, dP e, N ) → even(N )) → ask ∆ ` (dOe, dP e) says that for every theory O, if P is an expression containing only equivalences in which every sentential symbol occurs an even number of times, then P is a theorem of O (we assume that a theory has already been specified regarding the new predicates occurring here). The above statement is what is sometimes called a ‘subsidiary deduction rule’: a shortcut resulting from stating the outcome of a longer proof. 20

This example (taken from FOL [36]) shows how deduction at the meta-level can be employed to replace deduction in the object-theory itself. Since the former may be more efficient, this can be a computational consideration in favour of a meta-level system. 3.4.5

The interaction of naming and reflection

It should be clear that the naming relation as defined by the lift mapping plays a central role in the application of the reflection rules (1)–(4). If for instance we want to apply rule (1) forwards for a given name dP e and object-theory O in some meta-theory M, then we must first compute the value lift −1 (dP e) (the sentence for which dP e is a name9 ), and then try to prove this sentence in O. An example of a backward application of an inference rule can also be given with rule (1). If we want to establish the derivability of some sentence P in object-theory O, we can ‘reflect up’ by computing lift(O, P ) 7→ dP e, and then try to prove in M that ask ∆ ` (dOe, dP e) for some name dP e of P in M. Because the naming relation does not have to be functional (as stated in the previous subsection), the above rules (1)–(4) must be read as true for all dP e such that lift(O, P ) 7→ dP e. This means that if some object-level sentence P has more than one meta-level name, say dP e∆1 and dP e∆2, then theoremhood of P in rule (1) results in the truth of both ask ∆ ` (dOe, dP e∆1) and ask ∆ ` (dOe, dP e∆2), and similarly for axiomhood in rule (2). In a similar vein, deriving tell ∆ ∈ (dOe, dP e∆1, dO0 e) or tell ∆ ∈ (dOe, dP e∆2, dO0 e) in M results in P being ‘added’ as an axiom to O0 . Rule (4) behaves similar to rule (3). The reflective predicates together with the naming relation can establish theoremhood or axiomhood in one theory by deduction in another theory. A more realistic and substantial example than those above is presented in the next section.

4

Example Formal Specification of Inferences in Heuristic Classification

In this section we specify parts of the heuristic classification model to illustrate the application of ml2 . Heuristic classification [10] was one of the first knowledge models. It can be viewed as a knowledge-level abstraction of the problem-solving process of the MYCIN system. The NEOMYCIN program is an operationalisation of heuristic classification. The (informal) description of NEOMYCIN in [46] provided the main source of information for this specification. The types of inferences in heuristic classification are usuallly captured in the horse shoe figure (Fig. 4). Inference steps can be divided in three groups: 1. abstractions and specifications of data; 2. associations between data and solutions; 3. refinements and generalisations of solutions. The scope of our example formalisation is limited to the first type of inference steps: abstractions and specifications of data (the left leg of the horse shoe). In the following If it exists, this sentence is unique, because lift −1 is a function (lift is injective). If it does not exist (lift is not total, since lift is not surjective), the inference rule is not applicable. 9

−1

21

Figure 4: Inference steps in heuristic classification sections theories and lift operators are specified to describe the various knowledge types involved in these inferences steps at the domain level, the inference level and the task level, respectively.

4.1

Domain Level

The domain level represents the knowledge and data that depend upon a particular domain. The domain level can be compared to the domain knowledge required by the HERACLES system (a shellification of NEOMYCIN). We assume here a medical diagnostic domain, similar to the domain of NEOMYCIN, although the actual knowledge specification is derived from a description of the domain of acute heart diseases. As the scope of our example is restricted to specifications and abstractions of data used in diagnosis (i.e, the left leg of the horse shoe), the domain-layer description addresses the specification of patient data. The domain-layer specification10 consists of three parts: 1. the types of patient data; 2. the relations between patient data; 3. the facts about a particular patient. 4.1.1

Patient data

Patient data originate from a number of sources. Here we describe three groups of data: anamnestic-data, physical signs and laboratory data. The import operator is used to describe this relation. theory patient-data import anamnestic-data, physical-signs, lab-data

end theory 10

The examples that are given are only meant to serve as an illustration of the use of ML2 . We make no claim with regard to a correct or complete description of this particular domain.

22

The signature of the theory anamnestic-data specifies typical data a physician could gather during an interview of the patient. We use both functions and predicates to describe the data11 . theory anamnestic-data signature sorts age, age-category, sex-category, location, condition constants age-category: infant, child, adult, .. sex-category: male, female location: mid-sternal, .. condition: rest, exercise functions age-in-years : → nat life-phase: → age-category sex: → sex-category chest-pain-location: → location chest-pain-trigger: → condition predicates pregnant, immunosuppressed, alcoholic, chest-pain end-signature

12

end theory The theory physical-signs specifies data resulting from a physical examination in a similar spirit as the one above: theory physical-signs signature functions body-temperature: → nat diastolic-blood-pressure → nat systolic-blood-pressure → nat predicates fever, hypertension end-signature

end theory The theory lab-data specifies the various data that can be gathered with a particular test. theory lab-data signature sorts test-type constants test-type: blood-enzymes, blood-count functions SGOT, LDH, CPK, ...: → real red-cell-count, white-cell-count, ... : → nat predicates 11 12

In the theory specifications we assume that basic sorts like nat (the natural numbers) are pre-defined. These predicates are of zero arity, which is the reason why no sort appears in their declaration.

23

test: test-type end-signature

end theory

4.1.2

Relations between patient data

The theories about patient data specify a language of patient data types through their signature. No axioms were present in these theories. The theories below use this language (through an import operation) in order to specify relations between data propositions. In the theory definitions relations between quantitative and qualitative values are established. For instance, fever (a qualitative value) is defined via a proposition concerning the body temperature (a quantitative value). theory definitions import patient-data axioms body-temperature ≥ 38.0 → fever age-in-years > 18 → age-category = adult ; diastolic-blood-pressure > 95 → hypertension ; ... end-axioms

end theory The theory world-facts contains common-sense knowledge, for example that males cannot become pregnant. theory world-facts import patient-data axioms sex = male → ¬ pregnant; ... end-axioms

end theory The theory generalisations specifies a generalisation/specialisation hierarchy between data propositions. theory generalisations import patient-data axioms cytostatic-therapy → immunosuppressed ; immuno-suppressed ∨ alcoholic → compromised-host ; ... end-axioms

end theory

24

4.1.3

Facts about patients

Apart from the knowledge about patient data concepts and relations, the domain layer also stores facts about a particular patient. theory patient-facts import patient-data axioms % some example facts % age-in-years = 45 ; sex = male ; diastolic-blood-pressure = 100 ; systolic-blood-pressure = 150 ; chest-pain ; chest-pain-location = mid-sternal; chest-pain-trigger = exercise ; ... end-axioms

end theory

4.2

Inference Level

Now that we have specified the domain level, we can define lift operations that map the domain knowledge and facts onto inference-level terms. These terms are used in inferencelevel theories that yield the elementary problem-solving steps. The lift-operator finding-schema maps the domain-level expressions in the following way onto meta-level terms: • atomic sentences 7→ findings of two sorts: hard-findings and soft-findings; • axioms 7→ functions with findings as arguments. The organisation of the domain level into sub-theories is used to give different names to axioms in different theories. For example, the axiom body − temperature > 38 .0 → fever in the theory definitions is mapped (assuming quoted names) onto definition(“body − temperature > 38.0”, “f ever”) in the meta-theory. lift-operator finding-schema from definitions, generalisations, world-facts to abstract, specify signature sorts (finding (soft-finding hard-finding)) constants soft-finding: ds∆ie hard-finding: dh∆ie functions

25

definition: finding* × finding → ... world-fact: finding* × finding → ... generalisation: finding × finding → ... predicates source-of: finding × finding characterised-by: finding × finding end-signature meta-variables P∆i: predicate; PS: predicate-symbol mapping lift(PS∆i(age-category, )) 7→ ds∆ie ; ... lift(PS∆i(systolic-blood-presure, ) 7→ dh∆ie ; ... lift(definitions, P∆1W→ P∆2) 7→ definition(dP∆1e, dP∆2e) ; lift(generalisations, ∆i P∆i → P∆j) 7→ generalisation(dP∆ie, dP∆je) ; W lift(world-facts, ∆i P∆i → P∆j) 7→ world-fact(dP∆je, dP∆ie) ; end-mapping meta-axioms % The generalisation relation is transitive % ask∆ `(generalisation(F∆1, F∆2)) ∧ ask∆ `(generalisation(F∆2, F∆3)) → ask∆ `(generalisation(F∆1, F∆3)) ; source-of(dblood-teste, dred-cell-count = e) ; source-of(dblood-teste, dwhite-cell-count = e) ; ... characterised-by(dchest-paine, dchest-pain-location = e) ; characterised-by(dchest-paine, dchest-pain-trigger = e) ; end-meta-axioms

end lift-operator The introduction of meta-axioms in the above specification deserves some further attention: • The meta-axioms are a definitional extension of ml2 . It is equivalent to an additional meta-level theory that uses a lift-operator. The meta-axioms construction provides a convenient way of writing down inherent properties of the object-level terms. The axioms specifying the transitivity of the generalisation relation are a good example of the use of this feature. • The meta-axioms in finding-schema contain some domain-specific axioms (‘sourceof’ and ‘feature’). This is due to the fact that this type of domain knowledge is of a second-order nature (properties of functions and predicates) and thus cannot be conveniently expressed at the domain level. Introducing domain-specific aspects at the inference level is however against the kads philosophy. We are currently exploring alternative approaches to this problem, for example by specifying a lift within the domain layer. Knowledge-source theories The domain-level terms generated by this lift operator finding-schema are used by two theories representing the two elementary inference steps: abstract and specify. In the KADS terminology these theories are called knowledge sources. In the signature of the theory abstract two predicates are defined (focus and abstracted). These predicates specify the role that the finding plays in the inference step and, hence, 26

are the formal equivalent of the kads metaclasses. The axioms of the theory specify a dependency between the metaclasses given particular domain relations. For example, the first axiom could be phrased in natural language in the following way: “If there is a focus finding and if it can be inferred that this finding is the defining part of a definition relation at the domain level, then conclude that the second argument of the relation is an abstraction of the focus.” theory abstract use finding-schema signature predicates focus, abstracted: finding end-signature axioms focus(F) ∧ ask∆ `(definition(NewF, F)) → abstracted(NewF) ; focus(F) ∧ ask∆ `(generalisation(F, NewF)) → abstracted(NewF) ; focus(F) ∧ characterised-by(NewF, F) → abstracted(NewF) ; end-axioms

end theory The theory specify can be seen as the ‘inverse’ of abstract. This type of inference is used if, for example, the physician learns that the patient has a fever. In that case the physician will also want to know what the exact temperature of the patient is. The main difference between abstraction and specification is that specification often requires the assessment of a particular value (e.g., the value of the body temperature). The presence of the find-out predicate in the axioms of specify marks this difference. The full specification of find-out has been omitted in this example. theory specify use finding-schema, finding-facts signature predicates focus, specified: finding × finding end-signature axioms focus(F) ∧ source-of(F, NewF) ∧ find-out(NewF) → specified(NewF) ; focus(F) ∧ ask∆ `(generalisation(NewF, F)) ∧ find-out(NewF) → specified(NewF) ; focus(F) ∧ ask∆ `(definition(NewF, F)) ∧ find-out(NewF) → specified(NewF) ; focus(F) ∧ ask∆ `(characterised-by(F, NewF)) ∧ find-out(NewF) → specified(NewF) ; true(F) → find-out(F) ; false(F) → ¬ find-out(F) ; unknown(F) ∧ .... → findout(F) ; ... end-axioms

end theory

27

The axioms concerning find-out in the above theory make use of predicates like true, false and unknown. These typical meta-level notions are defined in the lift operator findingfacts with the use of the reflective predicate ask∆ ∈ in the following way: • dP e is true iff P is an axiom of the domain-level theory; • dP e is false iff ¬P is an axiom of the domain-level theory; • dP e is unknown otherwise. Again, the meta-axioms provide a convenient way of defining the appropriate metalevel terminology. lift-operator finding-facts from patient-facts to find-out signature sorts: finding constants: dfe predicates: true, false, unknown: finding end-signature meta-variables: P: predicate mapping lift(P) 7→ dfe ; end-mapping meta-axioms true(dPe) ↔ ask∆ ∈(lift(P)) false(dPe) ↔ ask∆ ∈(not(lift(P))) ; unknown(dPe) ↔ ¬ true(lift(P)) ∧ ¬ false(P)) ; end-meta-axioms

end lift-operator

4.3

Task Level

The relation between task and inference level is of a different nature than the one between inference and domain level. The mapping from domain to inference level generates meaningful names (see Sec. 3) for the domain knowledge such that the elementary inference steps can be defined in domain-independent terms. Accordingly, this transition comprises a real conceptual abstraction. In contrast, the mapping from inference to task level is a trivial mapping of predicates onto identical function terms. This mapping allows us to manipulate the knowledge-source theories with reflective predicates such as ask∆ ` and tell∆ ∈ to carry out primitive problem-solving tasks. lift-operator knowledge-sources from specify, abstract to knowledge-sources signature sorts finding constants finding: dfe

28

functions focus: finding → ... specified: finding → ... abstracted: finding → ... end-signature meta-variables F∆i: term; mapping lift(F:finding) 7→ dfe ; lift(specify & abstract, focus(F)) 7→ focus(lift(F)) ; lift(specify, specified(F)) 7→ specified(lift(F)) ; lift(abstract, abstracted(F)) 7→ abstracted(lift(F)) ; end-mapping

end lift-operator The theory clarify-and-abstract defines two complex and two primitive tasks concerned with abstraction and specification of data. The complex tasks clarify-findings and abstractfindings) iterate over all new findings and call a primitive task for each finding. Remember that variables are assumed to be universally quantified, unless indicated otherwise. The primitive tasks have the following typical structure: (i) a tell∆ ∈ of the input meta class, and (ii) a ask∆ ` of the output meta class. Typical for the task-level theories is that the axioms contain ask∆ ∈ and tell∆ ∈ predicates that refer to a task-base theory. This task database is assumed to contain all kinds of book-keeping information, e.g., whether a new finding was found, which hypotheses are in the differential, et cetera. The task database is defined at the object-level of the task level, i.e. the inference level. It is useful to view the knowledge-source theories and the task database as separate “compartments” of the same level. The specification of the task-base theory and its lift operator is omitted in this example. theory clarify-and-abstract use knowledge-sources, task-bookkeeping signature predicates clarify-findings, abstract-findings: clarify-finding, abstract-finding: finding end-signature axioms clarify-findings ← ask∆ ∈(task-base, new-finding(Focus), task-base) ∧ clarify-finding(Focus); clarify-finding(Focus) ← tell∆ ∈(specify, focus(Focus), specify) ∧ ask∆ `(specify, specified(NewFinding)) ∧ tell∆ ∈(task-base, new-finding(NewFinding), task-base) ; abstract-finding(Focus) ← ask∆ ∈(task-base, new-finding(Focus)) ∧ abstract-finding(Focus) ; abstract-finding(Focus) ← tell∆ ∈(abstract, focus(Focus), abstract) ∧

29

ask∆ `(abstract, abstracted(NewFinding)) ∧ tell∆ ∈(task-base, new-finding(NewFinding), task-base) ; end-axioms

end theory Two technical comments need to be made on the task specifications above: 1. The fact that the axioms specifying tasks are all Horn clauses is not completely coincidental. The type of knowledge at the task level is of a highly procedural nature and we are looking into the question whether the task level needs a different specialised (logical) language (cf. the discussion in Sec. 5). 2. The tell∆ ∈ predicate is defined in Sec. 3 as having two distinct theories (e.g. O and O0 ) as the first and third argument. We use here the same theory name in both places with the intended interpretation that the third argument is a new theory that is renamed to the old theory-name. This prevents the introduction of module variables and hence a reduction of the clarity of the theory.

5

Discussion: the Tension between Epistemological, Formal and Computational Aspects

After our exposition in the previous sections concentrating on the formalism, we will now return to a point of view that is closer to the practicing knowledge engineer. As already pointed out in the introductory section 1, the knowledge engineer has to practically achieve a ‘cohabitation’ of distinct perspectives. First, a conceptualisation of the various knowledge components in relation to the KBS task and domain is necessary. The outcome will be a knowledge-level conceptual model of the problem solving with a strong epistemological flavour. Second, a more formal account is needed of the (often informal) concepts occurring in this model, so as to sharpen these notions and as an intermediary to enable high-level prototyping and a more precise basis for KBS design. Our formalism is directed at this activity. It is here that logic plays an important role as a tool for knowledge-level analysis. Third, the obtained conceptual and formal results have to be rendered into a — program or symbol level — form suitable for a working computational system. These perspectives are quite different and possibly even conflicting, and their combination poses non-trivial problems, because epistemological adequacy, computational tractability and formal analysability need not coincide.

5.1

Role and access limitations of knowledge

Below we will put forward some tentative observations on this issue of epistemological and computational adequacy and how this connects to ml2 . In our opinion, a fundamental concept to understand the relationship between epistemological adequacy and computational tractability is that of role and access limitations of knowledge [7]. Structure is imposed upon knowledge-level models of problem solving by distinguishing different types and roles within the body of knowledge that is involved. This leads to the differentiation of a model into distinct knowledge components that will only play specialised and limited roles in the totality of the problem-solving process. Thus, we have role limitations (a term 30

taken from McDermott [6]) as the basic structuring notion at the knowledge level. The corresponding notion at the computational level is that of access limitations. If knowledge components can only be selectively used due to specified role-limiting effects, this will give rise to restricted dynamic access to the computational representation of those components in a knowledge-based system. Like actors in a play, they will only be actively called upon, and this in a very specific way, when they have an immediate part in the process. Hence, we suggest that epistemological role limitations are connected to computational access limitations. Vice versa, a common method to enhance computational tractability is to introduce knowledge differentiations that at the knowledge level are characterised as adding new role specialisations and limitations. As a matter of fact, the latter technique is quite clearly exemplified in the work on generic tasks and problem-solving methods, while the former approach is more in the spirit of the kads methodology. Accordingly, the above ideas seem to capture a fundamental working hypothesis underlying any knowledge-level approach, namely, that the knowledge level is the ‘right’ level of abstraction for knowledge acquisition, because epistemological role limitations of knowledge are reflected in computational access limitations in knowledge-based systems.

5.2

Specifying knowledge roles in the formalism

Adopting this as a plausible working hypothesis, we will now consider its relation to ml2 . We reiterate, then, that our formalism is based upon very simple intuitions that stem from the above-discussed epistemologically inclined, conceptual structuring of knowledge models. Generic knowledge types and roles can be indicated in the formalism by: • The use of sorts. Epistemologically, sorts are natural constructs to be employed as knowledge role indicators. At the same time, order-sorted logic is formally wellunderstood and has been shown to have some computational advantages [19; 20]. • Modular decomposition. From a conceptual viewpoint, this mechanism is suited to structure complicated theories in terms of knowledge components, interpreted here as coherent minitheories. The formal, algebraic properties of the used module constructors have been well investigated [34]. From the software point of view, the importance of modularisation hardly needs further discussion. • Meta-level constructs. The introduction of these mechanisms has first of all been driven by knowledge-level considerations, such as the common distinction between domain and control (strategy) knowledge and, specifically, the kads layered framework. The way the naming relation is specified in the present formalisation is suited as a knowledge role indicator of object-level expressions for use at the meta-level: hence the notion of meaningful naming. A similar remark applies to the introduction of reflection principles which partly are of a non-standard nature: enlarged reflection rules, to use the terminology of [38]. However, whereas the formal implications of the naming relation are quite clear (in particular because we avoid self-referential problems by ruling out the amalgamation of levels), studies of formal and computational aspects of reflection principles and meta-level inference point to open problems [35; 36; 38], [31; 47]. For example, role limitations imposed by meta-knowledge are computationally counteracted by introduced meta-level overheads. 31

Accordingly, ml2 seems to us expressive and fairly natural in expressing different knowledge roles and types of components at the knowledge level. Given the rather general formal constructs that have been employed, in its present form ml2 is most likely too general and flexible, as it is not yet sufficiently specialised to a shared generic knowledge-level theory of problem solving. Such a theory, however, does not yet exist and is only slowly emerging now. To a quite considerable extent, ml2 also provides a formal semantics for conceptual knowledge-level models. A knowledge module specification can be interpreted as an ordersorted first-order theory (closed under derivability). Module operations occurring in such specifications can be essentially understood in terms of union and restriction of theories. Since levels are strictly separated, the same applies to meta-level specifications as metatheories (whereby object-level theories can be considered as partial models of the metatheory). ml2 also contributes to a more operational semantics of knowledge-level modelling and specifically of the kads approach. It is close to extensions of logic programming as exercised in Socrates [31], FOL [36], GETFOL [45] and REFLOG [48]. Several concepts, such as modules, also fit quite nicely into the object-oriented paradigm [49]. Ideally, one would opt for an integration of object-oriented and logic-programming ideas (cf. [50]).

5.3

Trade-offs between epistemological and computational aspects

The really hard part of ml2 , going undoubtedly beyond conservative extensions of firstorder theories, comes in due to our use of reflection principles. This has advantages and disadvantages. On the one hand, their introduction is favoured by knowledge-level motivations, in the sense that they enable a rather natural expression of the relationships between theories. On the other hand, their formal and computational properties are only known to a limited extent. This is particularly so because not only reflection principles are of interest that represent a conservative or ‘truthful’ extension of a theory (as was the case in [35]), but also so-called enlarged reflection principles [38]. As may be inferred from the reflection rules proposed in Sec. 3, they comprise the possibility to, for example, introduce non-monotonic, defeasible reasoning. In addition, much work is still to be done on the computational tractability of meta-level inferencing [47]. Consequently, there is something of a trade-off here. From the epistemological perspective we prefer a multi-level, multi-language framework13 for conceptual modelling. This gives rise to formal problems related to non-standard logics as well as to open computational issues. It is perhaps possible to restrict the formalisation to (conservative extensions of) a standard first-order logic (as suggested in [15]), but then we must drop to varying degrees the notions of the layering of conceptual models and of meta-level knowledge. This seems to us a big sacrifice in terms of epistemological naturalness and expressiveness. A further point is that ml2 employs the same language at the different levels, regardless of their content. One may wonder, however, whether it wouldn’t be more natural to have procedural constructs in the formal language to model task structures and their execution. Here, procedural constructs (like sequence, iteration, non-deterministic choice and test) as formalised in so-called dynamic logic [51] might be of interest. Also, one can quite well imagine that the most suitable language to model domain knowledge will vary with the domain. At this stage it is difficult to make more definitive statements. How the 13

This provides of course an explanation of the name ML2 for our formal framework.

32

trade-off between conceptual, formal and computational considerations is best made will be a matter of future experience.

6

Conclusion

In this paper we have argued that formalisation of conceptual models of problem solving is important to advanced knowledge acquisition. Second-generation knowledge acquisition has been viewed here as a modelling activity that focusses at the knowledge level. Formalised knowledge-level models as discussed here first of all intend to support the conceptualisation stage of KBS development. This view on formalisation differs from the traditional approach where formalisation is usually seen as linked to knowledge representation rather than conceptualisation issues. A formal account of knowledge-level models increases conceptual precision, and lays foundations for second-generation knowledge acquisition and engineering tools. We have proposed ml2 , a formalism for the specification of knowledge models. This formal-specification framework has been inspired by current knowledge-level approaches and in particular by the kads methodology for KBS development. These approaches suggest a multi-language and multi-level (hence the name ml2 ) framework for conceptual modelling, whereby the basic structuring principle is yielded by distinguishing different roles and types of knowledge components. ml2 incorporates these intuitions in the following manner: • An order-sorted first-order logic is employed, whereby sorts act as knowledge role indicators. • Each level is thought to consist of ‘knowledge modules’. A module is a coherent piece of knowledge (a minitheory in the mentioned logic) used as a component in a larger theory. More complex theories within a level can be built in a structured way by employing constructional operators. For example, the ‘import’ operator generates the union of two theories. • The connections between levels are realised by so-called ‘lift operations’, which are in fact a special, epistemologically inspired, form of the naming relations between a theory and its meta-theory. This ‘meaningful naming’ is also used to specify knowledge roles. • Furthermore, inference relationships between theories (situated at different levels) are specified by ‘enlarged reflection rules’. The proposed intertheory inference rules are important as they support the expression of different types of reasoning on and different uses of a given body of knowledge. This formalism has shown, on the basis of first experiences, to be an aid in structuring and in more precisely formulating knowledge models. An example application concerning heuristic classification has been given in this paper. Although ml2 seems helpful and flexible, in its present state it is too general and will need future specialisation with regard to a —currently emerging— generic knowledge-level theory of problem solving.

33

Finally, we have pointed out that a typical element of knowledge-level approaches to knowledge acquisition lies in their defining different roles and types of knowledge. This is attributed great significance for building a well-behaved computational system. Thus, as a fundamental working hypothesis underlying the knowledge-level approach, we have postulated that (epistemological) role limitations of knowledge are reflected in (computational) access limitations in knowledge-based sytems. From this perspective we have discussed the present formalisation in connection to the issue of the epistemological and computational adequacy of knowledge models.

References [1] B.J. Wielinga and J.A. Breuker. Models of expertise. In Proceedings ECAI-86, pages 306–318. ECCAI, 1986. [2] S.A. Hayward, B.J. Wielinga, and J.A. Breuker. Structured analysis of knowledge. International Journal of Man-Machine Studies, 26:487–498, 1987. [3] L. Steels. Components of expertise. AI Memo 88-16, AI Lab, Free University of Brussels, 1988. Published in AI Magazine, Summer 1990, pages 28–49. [4] T. Bylander and B. Chandrasekaran. Generic tasks in knowledge-based reasoning: The ‘right’ level of abstraction for knowledge acquisition. In J.H. Boose and B.R. Gaines, editors, Knowledge-Based Systems, Volume 1: Knowledge Acquisition for Knowledge-Based Systems, pages 65–77. Academic Press, London, 1988. [5] J.H. Alexander, M.J. Freiling, S.J. Shulman, S. Rehfuss, and S.L. Messick. Ontological analysis: an ongoing experiment. In J.H. Boose and B.R. Gaines, editors, Knowledge-Based Systems, Volume 2: Knowledge Acquisition Tools for Expert Systems, pages 25–37. Academic Press, London, 1988. [6] J. McDermott. Preliminary steps toward a taxonomy of problem-solving methods. In S. Marcus, editor, Automating Knowledge Acquisition for Expert Systems, pages 225–255. Kluwer Academic Publishers, Boston, MA, 1989. [7] B.J. Wielinga, J.M. Akkermans, A.Th. Schreiber, and J.R. Balder. A knowledge acquisition perspective on knowledge-level models. In J.H. Boose and B.R. Gaines, editors, Proceedings 4th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, pages 36.1–36.22, Calgary, 1989. SRDG Publications, University of Calgary. [8] W.J. Clancey. The epistemology of a rule-based system — a framework for explanation. Artificial Intelligence, 20:215–251, 1983. [9] A. Newell. The knowledge level. Artificial Intelligence, 18:87–127, 1982. [10] W.J. Clancey. Heuristic classification. Artificial Intelligence, 27:289–350, 1985. [11] L. Eshelman. MOLE: A knowledge-acquisition tool for cover-and-differentiate systems. In S. Marcus, editor, Automating Knowledge Acquisition for Expert Systems, pages 37–80. Kluwer Academic Publishers, Boston, MA, 1989. 34

[12] S. Marcus and J. McDermott. SALT: A knowledge acquisition language for proposeand-revise systems. Artificial Intelligence, 39(1):1–37, 1989. [13] J. Breuker, B. Wielinga, M. van Someren, R. de Hoog, G. Schreiber, P. de Greef, B. Bredeweg, J. Wielemaker, J.-P. Billault, M. Davoodi, and S. Hayward. Modeldriven knowledge acquisition: Interpretation models. ESPRIT-I Project P1098, Deliverable D1 (task A1), University of Amsterdam, 1987. [14] H. Akkermans, B. Wielinga, G. Schreiber, and J. Balder. Towards a formal specification of knowledge models. Technical Report ECN-89-006, ECN, Petten, The Netherlands, 1989. [15] T. Wetter. First-order logic foundation of the KADS conceptual model. In B.J. Wielinga, J.H. Boose, B.R. Gaines, A.Th. Schreiber, and M. van Someren, editors, Current Trends in Knowledge Acquisition, pages 356–375. IOS Press, Amsterdam, 1990. [16] W. Kowalczyk and J. Treur. On the use of a formalized generic task model in knowledge acquisition. In B.J. Wielinga, J.H. Boose, B.R. Gaines, A.Th. Schreiber, and M. van Someren, editors, Current Trends in Knowledge Acquisition, pages 198–221. IOS Press, Amsterdam, 1990. [17] M.A. Musen. Automated Generation of Model-Based Knowledge-Acquisition Tools. Pitman, London, 1989. Research Notes in Artificial Intelligence. [18] F. Hayes-Roth, D.A. Waterman, and D.B. Lenat. Building Expert Systems. AddisonWesley, New York, 1983. [19] C. Walther. A Many-Sorted Calculus Based on Resolution and Paramodulation. Pitman, London, 1987. Research Notes in Artificial Intelligence. [20] M. Schmidt-Schauß. Computational Aspects of an Order-Sorted Logic with Term Declarations. Springer-Verlag, Berlin, 1989. Lecture Notes in Artificial Intelligence No. 395. [21] T. DeMarco. Controlling Software Projects. Yourdon Press, New York, 1982. [22] A.Th. Schreiber, J.A. Breuker, B. Bredeweg, and B.J. Wielinga. Modelling in KBS development. In J.H. Boose, B.R. Gaines, and M. Linster, editors, Proceedings 2nd European Knowledge Acquisition Workshop EKAW-88, Bonn, pages 7.1–7.15, St. Augustin, 1988. GMD. GMD-Studien 143. [23] B.J. Wielinga and B. Bredeweg. Knowledge and expertise in expert systems. In G.C. van der Veer and G. Mulder, editors, Human-Computer Interaction: Psychonomics Aspects, pages 290–297, Berlin, 1988. Springer-Verlag. [24] P. de Greef and J. Breuker. A case study in structured knowledge acquisition. In Proceedings of the 9th IJCAI, pages 390–392, Los Angeles, CA, 1985. [25] P. Hayes. In defence of logic. In Proceedings of IJCAI-77, pages 559–556. International Joint Conference on Artificial Intelligence, 1977. 35

[26] R. Moore. The role of logic in knowledge representation and common-sense reasoning. In National Conference on Artificial Intelligence, pages 428–433, Pittsburgh, PA, August 1982. American Association for Artificial Intelligence. [27] R. Moore. The role of logic in Artificial Intelligence. Note 335, SRI International, Menlo Park, CA, 1984. [28] B. Kowalski. Logic for Problem Solving. North-Holland, Amsterdam, 1979. [29] C. Walther. A mechanical solution of Schubert’s steamroller by many-sorted resolution. In Proceedings of the fourth National Conference on Artificial Intelligence, pages 330–334, Austin, Texas, 1984. American Association for Artificial Intelligence. [30] A.G. Cohn. On the solution of Schubert’s steamroller in many sorted logic. In Proceedings of the Ninth IJCAI, pages 345–352, Los Angeles, August 1985. International Joint Conference on Artificial Intelligence. [31] P. Jackson, H. Reichgelt, and F. van Harmelen. Logic-Based Knowledge Representation. The MIT Press, Cambridge, MA, 1989. [32] D. Sanella and R. Burstall. Structured theories in LCF. In Proceedings of the 8th Colloquium on Trees in Algebra and Computing, Berlin, 1983. Springer-Verlag. Lecture Notes in Computer Science No. 159. [33] A. Brogi, P. Mancarella, D. Pedreschi, and F. Turini. Hierarchies through basic meta-level operators. In M. Bruynooghe, editor, Proceedings of the Second Workshop on Meta-programming in Logic (META’90), pages 381–396, Leuven, Belgium, April 1990. [34] J.A. Bergstra, J. Heering, and P. Klint. Module algebra. Journal of the ACM, 37(2):335–372, 1990. [35] S. Feferman. Transfinite Recursive Progressions of Axiomatic Theories. Journal of Symbolic Logic, 27(3):259–316, September 1962. [36] R. Weyhrauch. Prolegomena to a theory of mechanized formal reasoning. Artificial Intelligence, 13:133–170, 1980. [37] B. Smith. Reflection and semantics in Lisp. In Proc. 11th ACM Symposium on Principles of Programming Languages, pages 23–35, Salt Lake City, Utah, 1984. also: Xerox PARC Intelligent Systems Laboratory Technical Report ISL-5. [38] F. Giunchiglia and A. tomated reasoning. In in Logic Programming Cambridge, MA, 1989.

Smaill. Reflection in constructive and non-constructive auH. Abramson and M.H. Rogers, editors, Meta-Programming (Proceedings META-88 Workshop, Bristol), pages 123–140, MIT Press.

[39] P. Maes and D. Nardi, editors. Meta-Level Architectures and Reflection, Amsterdam, 1988. North-Holland.

36

[40] D. Perlis. Languages with self-reference I: Foundations. 25:301–322, 1985.

Artificial Intelligence,

[41] K. Konolige. A Deduction Model of Belief. Research Notes in AI. Pitman, London, 1985. [42] K.A. Bowen and R.A. Kowalski. Amalgamating language and metalanguage in logic programming. In K.L. Clark and S.-A. T¨arnlund, editors, Logic Programming, pages 153–172. Academic Press, London, 1982. [43] F. van Harmelen. A classification of meta-level architectures. In P. Jackson, H. Reichgelt, and F. van Harmelen, editors, Logic-Based Knowledge Representation, chapter 2, pages 13–36. MIT Press, 1989. Also in: Meta-Programming in Logic Programming (META’88), Abramson, H. and Rogers, M.H. (Eds.), MIT Press, Cambridge, MA, 1989, pp. 103-122. [44] A. Tarski. Der Wahrheitsbegriff in den formalisierten Sprachen. Studia Philosophica, 1:261–405, 1936. English translation in Logic, Semantics, Metamathematics, A. Tarski, Oxford University Press, 1956. [45] F. Giunchiglia and L. Serafini. Multilanguage first-order theories of propositional attitudes. Technical Report 9001-02, IRST, Trento, Italy, January 1990. [46] W.J. Clancey. Acquiring, representing and evaluating a competence model of diagnostic strategy. In Chi, Glaser, and Far, editors, Contributions to the Nature of Expertise, 1985. [47] F. van Harmelen. On the Efficiency of Meta-level Inference. PhD thesis, University of Edinburgh, 1989. To appear in Research Notes in Artificial Intelligence, Pitman, London. [48] N. Lavraˇc and H. Vassilev. Meta-level architecture of a second-generation knowledge acquisition system. In K. Morik, editor, Proceedings EWSL-89, pages 99–109, London, 1989. Pitman. [49] J.R. Balder and J.M. Akkermans. StrucTool: Supporting formal specifications of knowledge-level models. In B.J. Wielinga, J.H. Boose, B.R. Gaines, A.Th. Schreiber, and M. van Someren, editors, Current Trends in Knowledge Acquisition, pages 60–77. IOS Press, Amsterdam, 1990. [50] J.A. Goguen and J. Meseguer. Unifying functional, object-oriented and relational programming with logical semantics. In B. Shriver and P. Wegner, editors, Research Directions in Object-Oriented Programming, pages 417–477, Cambridge, MA, 1987. MIT Press. [51] D. Harel. Dynamic logic. In D. Gabbay and F. Guenthner, editors, Handbook of Philosophical Logic, Vol. II: Extensions of Classical Logic, pages 497–604. Reidel Publishing Company, Dordrecht, The Netherlands, 1984.

37