The Role of Ontologies in Knowledge Engineering

The Role of Ontologies in Knowledge Engineering

Cover design: Natascha Theunissen

THE ROLE OF ONTOLOGIES IN KNOWLEDGE ENGINEERING

ACADEMISCH PROEFSCHRIFT

ter verkrijging van de graad van doctor aan de Universiteit van Amsterdam op gezag van de Rector Magnificus prof.dr P.W.M. de Meijer ten overstaan van een door het college van dekanen ingestelde commissie in het openbaar te verdedigen in de aula van de universiteit op 17 mei 1995 te 14.00 uur

door

GERARDUS ADRIANUS CORNELIS MARIA VAN HEIJST geboren te Oudenbosch

Promotor: Copromotor:

prof.dr B.J. Wielinga dr A.Th. Schreiber

Faculteit Psychologie Universiteit van Amsterdam

Promotiecommissie: prof.dr J.A. Breuker dr R. de Hoog prof.dr N.J.I. Mars prof.dr N.R. Shadbolt prof.dr P.F. de Vries Robbé

Universiteit van Amsterdam Universiteit van Amsterdam Universiteit Twente University of Nottingham Katholieke Universiteit Nijmegen

CIP-GEGEVENS KONINKLIJKE BIBLIOTHEEK, DEN HAAG Heijst, Gerardus Adrianus Cornelis Maria van The role of ontologies in knowledge engineering / Gerardus Adrianus Cornelis Maria van Heijst. — Amsterdam: Universiteit van Amsterdam, Faculteit der Psychologie Thesis Universiteit van Amsterdam — With ref. ISBN 90-5470-032-7 Subject headings: knowledge engineering / ontologies / knowledge acquisition.

To my parents

Contents 1

2

3

4

Introduction 1.1 Knowledge Engineering in Perspective 1.2 The Problem : : : : : : : : : : : : : : 1.3 Ontology : : : : : : : : : : : : : : : : 1.4 Research Questions : : : : : : : : : : 1.5 Reader’s Guide : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

Methodological Background: The GAMES Approach 2.1 Introduction : : : : : : : : : : : : : : : : : : : : 2.2 KBS Technology in Medical Organizations : : : : 2.3 General Approach : : : : : : : : : : : : : : : : : 2.4 World View : : : : : : : : : : : : : : : : : : : : 2.5 Theory : : : : : : : : : : : : : : : : : : : : : : : 2.6 Methods : : : : : : : : : : : : : : : : : : : : : : 2.7 Tools : : : : : : : : : : : : : : : : : : : : : : : : 2.8 Use : : : : : : : : : : : : : : : : : : : : : : : : : 2.9 Discussion : : : : : : : : : : : : : : : : : : : : : Model-Based Knowledge Acquisition Tools 3.1 Introduction : : : : : : : : : : : : : : 3.2 A Framework for Comparing Tools : : 3.3 Evolution of the Paradigm : : : : : : : 3.4 Types of Tool Support : : : : : : : : : 3.5 Knowledge Acquisition Tools : : : : : 3.6 Conclusions : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

Generalized Directive Models 4.1 Introduction : : : : : : : : : : : : : : : : : : : : : 4.2 Problems with Model-Based Knowledge Acquisition 4.3 Generalized Directive Models : : : : : : : : : : : : 4.4 The GDM Grammar : : : : : : : : : : : : : : : : : 4.5 GDM’s in KEW : : : : : : : : : : : : : : : : : : : 4.6 A Fragment of a GDM Scenario : : : : : : : : : : : 4.7 A GDM Grammar for Design : : : : : : : : : : : : 4.8 GDM’s Revisited : : : : : : : : : : : : : : : : : : : 4.9 Discussion : : : : : : : : : : : : : : : : : : : : : : i

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

1 1 3 4 5 5 7 7 8 9 10 12 22 26 30 35 41 41 42 44 46 48 54 57 57 58 59 60 62 63 65 66 68

ii 5

6

7

8

9

The Role of Ontologies in Knowledge Engineering Principles for Ontology Library Construction 5.1 Introduction : : : : : : : : : : : : : : : : 5.2 Ontologies : : : : : : : : : : : : : : : : : 5.3 Organization of the Library : : : : : : : : 5.4 Building the Library : : : : : : : : : : : : 5.5 Using the Library : : : : : : : : : : : : : 5.6 Discussion : : : : : : : : : : : : : : : : : CUE: Ontology-Based Knowledge Acquisition 6.1 Introduction : : : : : : : : : : : : : : : : 6.2 Steps in Epistemological Modeling : : : : 6.3 Skeletal Model Construction in CUE : : : : 6.4 Model Instantiation in CUE : : : : : : : : 6.5 Discussion : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

Knowledge-Based Integration of Representation Formalisms 7.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : 7.2 The Need for Multiple Representations : : : : : : : : : : 7.3 Hybrid Knowledge Representation : : : : : : : : : : : : : 7.4 Knowledge-Based Integration : : : : : : : : : : : : : : : 7.5 Applying Knowledge-Based Integration : : : : : : : : : : 7.6 Discussion : : : : : : : : : : : : : : : : : : : : : : : : : Treating Acute Radiation Syndrome: a Case Study 8.1 Introduction : : : : : : : : : : : : : : : : : : 8.2 Synopsis of the ARS Domain : : : : : : : : : 8.3 Modeling the Task : : : : : : : : : : : : : : : 8.4 Building the Application Ontology : : : : : : : 8.5 Extending the Library : : : : : : : : : : : : : 8.6 Mapping Task Model and Ontology : : : : : : 8.7 Acquiring Domain Knowledge : : : : : : : : : 8.8 Building the Computational Model : : : : : : 8.9 QUAARS in Action : : : : : : : : : : : : : : 8.10 Conclusions : : : : : : : : : : : : : : : : : : Conclusions and Discussion 9.1 Review of the Individual Chapters : : : : 9.2 Synthesis : : : : : : : : : : : : : : : : : 9.3 A Perspective on Knowledge Engineering

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

A GDM Grammar for Design B A Part of MOLE’s Elicitation Strategy B.1 MOLE’s Ontology : : : : : : : : : : : : : : : : : B.2 MOLE’s Knowledge Elicitation Strategy : : : : : : B.3 Description of CUE’s Elicitation Strategy Language

71 71 73 74 84 88 90 93 93 94 95 100 113 117 117 118 119 120 123 126 129 129 129 130 131 139 141 142 144 154 156 159 159 160 164 167

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

175 175 177 178

iii C The ARS Application Ontology

179

Bibliography

191

Name Index

204

iv


Preface In the five years that I have worked at the department of social science informatics (SWI)1 I have witnessed several times that writing a PhD thesis is a tough exercise. Now I have experienced this myself, especially during the last months before sending the manuscript to the committee. I am grateful to the many friends, colleagues and friend-and-colleagues that have supported me. Scientific research, especially at SWI, is a matter of teamwork and this also holds for the “Gertjan’s thesis” project. The most prominent team-member in this project was Guus Schreiber, my daily supervisor during the last three years. Guus has put so much time and effort in this thesis that it is almost as much his product as it is mine. My promotor Bob Wielinga has given direction to the research throughout the years, and especially in the last intensive months he has suggested many improvements and has pointed out many links with other research activities. Manfred Aben has been my room-mate and friend for the last five years. Manfred, thanks for the fun and for the millions of interesting discussions about topics ranging from the repertoire of André van Duin to the role of formal methods in beer drinking. I learned a lot from you, though I am not entirely sure what exactly.2 Good luck at Unilever Research. Lynda Hardman provided many valuable comments and suggested many improvements on both the English and on the contents of the thesis. Thanks, I hope I can do the same for you when you finish your thesis. Within our group I have closely collaborated with Ameen Abu-Hanna, Wilfried Post and Peter Terpstra, who are also co-authors of some of the papers on which this thesis is based. I enjoyed working with you and I hope that there will be possibilities to continue our cooperation in the future. Anjo Anjewierden taught me right from wrong in programming and, in particular during the ACKnowledge project, showed me how to survive in EC funded projects. I am grateful to Jan Wielemaker for developing XPCE. Without XPCE programming graphical interactive tools like the CUE environment would simply be too difficult for amateur programmers like myself. I am grateful to Frank van Harmelen for the many discussions about almost everything within and outside the field of AI. I learned a lot from these discussions, both about the subject matter and about rhetorics. During the last five years I have collaborated with many international researchers from whom I learned many things. In particular, I want to thank Nigel Shadbolt, Dean Allemang, Giordano Lanzola, Mario Stefanelli and Sabina Falasconi who were co-authors of some of the papers and articles on which this thesis is based. Hauke Kindler provided valuable input for chapter 8 about acute radiation syndrome. Further, I want to acknowledge all the citizens of the European Union. This thesis would never have existed if you were not so eager to pay your taxes. Thanks, I hope you think the money was 1 2

The name of the department wasn’t my idea! I hope this makes up for the coffee!

v

vi


well spent. Last, but certainly not least, Natascha, bedankt vuur alles. Dieng leefde en steun goove mich de kracht um durch te goa op momente dat ich ut zelf nit mie zoog zitte. Joamer dat alles noe zoe gegaange is. Ich hoop datste gelukkig weats.

Chapter 1

Introduction The topic of this thesis is how prior knowledge of particular domains or particular tasks can be used in knowledge engineering. Of the various forms in which this prior knowledge may exist, this thesis addresses two: abstract descriptions of reasoning methods and abstract descriptions of domain knowledge, where the emphasis is on the latter. The following section motivates why the study of abstract descriptions of domain knowledge — ontologies — has become an important issue in knowledge engineering by posing the question within a wider context.

1.1 Knowledge Engineering in Perspective Historically, the study of knowledge has been the realm of philosophers. In this century, however, intellectual disciplines such as logic, linguistics and psychology have made knowledge object of their study too, each from their own perspective. With the emergence of computers, yet another approach to the study of knowledge and reasoning emerged: artificial intelligence (AI), which strives to develop computer programs that exhibit intelligent behavior. In the early days of artificial intelligence, the programs that were developed were knowledgepoor; the general assumption was that intelligence was in the algorithm, and not in the data structures. For example, a famous early AI program was GPS, the general problem solver (Newell & Simon, 1963). This system was considered intelligent because it was able to solve all kinds of problems, provided that the knowledge needed to solve those problems was given by the user. However, this view on intelligent behavior led to problems. It became clear that there are many algorithms that can make a system act “intelligently”, provided that the knowledge is represented in the right way. Therefore, in the seventies the attention in AI research shifted towards investigating the properties of different knowledge representation formalisms. To date, this subject has remained an active research area. At the same time, practically oriented artificial-intelligence researchers began to investigate the possibility of applying the “intelligent” algorithms that they had developed for solving toy problems, to more challenging tasks, such as medical diagnosis. It was soon realized that the general purpose (“weak”) reasoning methods were computationally inadequate. To achieve adequate problem solving in complex domains, it was necessary to incorporate large amounts of domain- and task-specific knowledge in the systems. Because of their ability to solve problems that required some kind of expertise, these systems were called “expert systems”. In the seventies, a number of successful expert systems were developed in diverse fields such 1

2


as organic chemistry (DENDRAL; Buchanan & Feigenbaum, 1978), medical diagnosis (MYCIN; Shortliffe, 1979) and computer-hardware configuration (R1; McDermott, 1982). The success of these systems suggested that they were also interesting from a commercial point of view. There were high expectations that a huge market was waiting for expert systems technology. This more product-oriented offspring of artificial intelligence is called knowledge engineering. However, the initial enthusiasm about the application of this new technology was soon tempered when a number of problems became apparent. A first difficulty concerned the immature development stage of the technology itself. The large amount of knowledge necessary for expert behavior was in these first-generation expert systems typically represented as an unordered collection of production rules. The lack of structure in the organization of the knowledge base hindered the development and maintenance of these systems. Another, more fundamental problem was that it appeared to be very difficult to acquire the expert knowledge in the first place. In order to avoid knowledge engineers having to become experts themselves, expert systems have to be developed in close cooperation with domain experts. However, the communication between domain experts and knowledge engineers appeared to be problematic. Feigenbaum (1984) termed this hindrance the knowledge acquisition bottleneck. The disappointing experiences with the commercialization of expert systems technology made it clear that the above-mentioned problems had to be solved before the technology could fully be exploited. Therefore, in the last decade many researchers have addressed these problems, which has resulted in a better understanding of their nature. In an overview of the field, Musen (1993) mentions four causes of the knowledge-acquisition problem. Firstly, the knowledge of experts is often tacit: it is only available in a procedural form and not in a declarative, verbalizable form. Secondly, there is the problem of miscommunication. Typically, knowledge engineers do not comprehend the vocabulary used by domain experts. Similarly, domain experts do not know enough about programming to understand which kinds of knowledge might be relevant for a computer program. A third problem identified by Musen is the use of knowledge representations. The formalisms used to represent knowledge in an expert system necessarily have a limited expressive power in order to maintain computational tractability. As a result, there is often a tension between the form in which knowledge is brought to bear by the expert and the form in which it must be represented in the knowledge base. Musen’s fourth problem is the problem of creating models. Knowledge bases are models of the expertise required to solve problems. Therefore, knowledge acquisition is a modeling activity. As with all creative activities, this is difficult. The maintenance problems, which were a consequence of the lack of organization in knowledge bases, have also been addressed. It is now widely recognized that there are different types of knowledge which should be represented separately and in different ways in order to achieve maintainability. A number of knowledge typologies have been proposed for this reason. For example, the KADS framework distinguishes between domain knowledge, inference knowledge, task knowledge and strategic knowledge (Wielinga & Breuker, 1986). Further, comprehensive knowledge-engineering methodologies have emerged which provide support for organizing the development process of expert systems, or knowledge-based systems (KBS), which is a more common term nowadays. A characteristic that is shared by most of these approaches is that they promote the reuse of knowledge pieces by providing libraries with off-theshelf knowledge components. The idea is that with such a library, knowledge engineering will eventually become a configuration activity. So far, the emphasis has mainly been on components for configuring problem-solving methods — abstract descriptions of the steps that must be taken

Chapter 1: Introduction

3

to perform particular tasks. Another type of knowledge which has been suggested as a candidate for reuse are ontologies — intensional descriptions of the domain knowledge in some field. Many feel that access to libraries of reusable ontology-components would facilitate the knowledge engineering process, and an increasing number of research groups are taking up the challenge to develop candidate components for ontologies. However, the field is still in its infancy and many problems are unsolved or even unaddressed. To mention a few: how can ontologies be built, compared, integrated, validated, visualized or used? Further, a question that needs to be addressed is whether a methodology that is based on the use of generic components for problem-solving methods can also promote the use of generic components for ontologies. In other words: can the components be specified in such a way that the ontologies can be used with different problem-solving methods while the problem-solving methods can be used with different ontologies? This question touches upon a long-standing debate in AI about whether domain knowledge can be represented independently of how it is used in reasoning. Clancey’s early work on NEOMYCIN suggested that both domain knowledge and problem-solving knowledge — or control knowledge as it was called in those days — can be reused, provided that the problem-solving knowledge and domain knowledge are represented separately in the knowledge base (Clancey & Letsinger, 1984). This belief that separation of control knowledge and domain knowledge would enhance the reusability of both was also one of the assumptions that led to the conception of the KADS four-layer model (Wielinga & Breuker, 1986). However, in 1988 Bylander and Chandrasekaran argued against this belief by presenting the interaction problem: Representing knowledge for the purpose of solving some problem is strongly affected by the nature of the problem and the inference strategy to be applied to the problem (Bylander & Chandrasekaran, 1988). In our terminology, the interaction problem states that the ontology of the knowledge in a KBS is strongly affected by the task of the KBS and the method it uses to perform that task. Bylander and Chandrasekaran identified two reasons for the interaction problem. Firstly, the task at hand determines to a large extent which kinds of knowledge should be encoded: it is not feasible to model everything that the expert knows. Secondly, the knowledge must be encoded in such a way that the inference strategy used can reach appropriate conclusions efficiently. To summarize, although there is a general feeling that explicit ontologies which are built from reusable building blocks are useful in knowledge engineering, there are many open issues. It is also unclear whether such reusable ontological components can be used in methodologies which are primarily oriented towards the use of reusable problem-solving method components. It is this state of affairs that has motivated the research reported in this thesis.

1.2 The Problem There are many issues related to the notion of ontology in the context of KBS development. In this thesis, we will focus on the utility of ontologies in the KBS development process. The central research question of this thesis can then be formulated as: How can explicit ontologies be obtained and used to make the knowledge-engineering process more manageable?

4


For practical reasons, this general problem is divided into three more concrete research questions: (i) how can the knowledge-engineering process be organized in such a way that explicit ontologies are useful, (ii) how can explicit ontologies be constructed and (iii) can domain ontologies be reused with different problem solving methods? Sec. 1.4 will elaborate on each of these questions. The following section discusses the term “ontology”, as used in this thesis.

1.3 Ontology In philosophy, the term “ontology” refers to “a particular theory about the nature of being or the kinds of existence.”. This broad definition can be interpreted in a number of ways, depending on the metaphysical stance that one takes with respect to what “existence” is. A number of researchers in knowledge engineering have therefore suggested more specific, AI-oriented definitions of ontology. In general, AI definitions avoid referring to reality, but rather use terms as representation and conceptualization. An often-cited definition is that of Gruber: An ontology is an explicit specification of a conceptualization. The term is borrowed from philosophy, where an ontology is a systematic account of Existence. For AI systems, what “exists” is that which can be represented (Gruber, 1994). Although not explicitly stated, this definition suggests that an ontology is a meta-level description of a knowledge representation. Thus, the ontology is not part of the representation itself. As we shall see in detail in chapter 7, this is an aspect of ontologies that will turn out to be important for their application in knowledge engineering. Another aspect of ontology that is important for the work in this thesis can be found in a definition formulated by Wielinga and Schreiber: An (AI-) ontology is a theory of what entities can exist in the mind of a knowledgeable agent (Wielinga & Schreiber, 1993). This definition emphasizes that we want to apply the notion of ontology to all knowledgeable agents, including humans. Since different knowledgeable agents will often have different symbollevel representations, it is convenient to formulate ontologies at the knowledge level (Newell, 1982). This aspect is important in this thesis because in chapter 6 it will be argued that ontologies can be used as mediators between knowledge as it is understood by a domain expert and knowledge as it is represented in a computer system. A third knowledge-engineering oriented definition of ontologies is given by Alberts (1993): An ontology for a body of knowledge concerning a particular task or domain, describes a taxonomy of concepts for that task or domain that define the semantic interpretation of the knowledge (Alberts, 1993). In AI, the term ontology is often used as a synonym for the terminology in some domain. This definition emphasizes that it is not the terminology itself that constitutes the ontology but the semantic interpretation of the terms. Another important aspect of this definition is that ontologies can be specific for tasks or for domains. That is, both the domain and the task at hand may affect the ontology. As will be explained in chapter 5, this aspect of ontologies can be used to organize a library of reusable ontologies. The three definitions above are not contradictory, and capture a large proportion of the aspects of ontology that are relevant for the work reported in this thesis. Combining the above definitions results in the following definition:

Chapter 1: Introduction

5

An ontology is an explicit knowledge-level specification of a conceptualization, i.e. the set of distinctions that are meaningful to an agent. The conceptualization — and therefore the ontology — may be affected by the particular domain and the particular task it is intended for.

1.4 Research Questions In Sec. 1.2 the general problem was reformulated into three more specific questions. This section motivates how these questions are related to the general problem. 1. How can the knowledge engineering process be organized to maximize the leverage of explicit ontologies? To use ontologies in knowledge engineering, they must be embedded in a methodology. Therefore, a part of this thesis is devoted to the analysis of the activities that constitute the knowledge engineering process and the kinds of support that these activities require. The results of this analysis are then used to identify parts of the knowledge engineering process where explicit ontologies are useful. Then, an approach to knowledge engineering is presented where the activities are organized in such a way that the availability of an ontology is fully exploited. 2. How can explicit ontologies be constructed? Assuming that the knowledge engineering process is organized in such a way that explicit ontologies are useful, the next question that must be addressed is how they are obtained. Basically, there are three ways: ontologies can be constructed from scratch, they can be selected from a library of off-the-shelf ontologies, or they can be configured from off-the-shelf components. Each of these ways of obtaining ontologies is addressed in this thesis. 3. Can domain ontologies be reused with different problem solving methods? This question concerns the interaction problem. The basic idea that underlies the current efforts to construct libraries of reusable ontologies, is that such ontologies can be selected from the library and then used for various purposes. However, the interaction problem states that this is impossible. In particular, it impedes the reuse of ontologies with different problem-solving methods. This is a severe problem, since existing knowledge engineering methodologies depend heavily on libraries of reusable problem-solving methods. Therefore, a part of this thesis is dedicated to investigate to what extent the task/method perspective precludes the use of reusable ontologies.

1.5 Reader’s Guide This thesis is the result of integrating a number of journal articles, articles in conference proceedings and papers presented at workshops. Therefore, the questions that were outlined in the previous section are not treated and answered sequentially. However, in chapter 9 the results of the individual chapters in this thesis will be merged into answers to the three research questions. To help with the reading of this thesis, every chapter is preceded with a brief introductory section which explains how the work presented in that chapter fits in the overall structure of the thesis. Where appropriate, the introductory section will also mention the original sources on which

6


the chapter is based. This section summarizes the topics addressed in the different chapters and presents the rationale for putting the chapters in the particular order that they are in. Chapter 2 describes the GAMES approach to knowledge engineering, which forms the methodological background of most of the research reported in this thesis. The GAMES methodology uses explicit ontologies to facilitate the knowledge-acquisition process. Some of the issues that are relevant for answering the research questions raised above are worked out in further detail in later chapters. Chapter 3 One important role for ontologies that is addressed in this thesis concerns the ways in which they can be used in knowledge acquisition. In the context of an overview of the history of automated knowledge acquisition, chapter 3 presents an analysis of the ways in which the basic activities in knowledge acquisition can be and have been supported by tools, hereby illustrating that strong tool support is often based on rigid ontological commitments. However, because of these ontological commitments, such tools usually have a narrow scope. Explicit and inspectable ontologies can provide a way out of this dilemma. Chapter 4 presents the theory of generalized directive models (GDM’s), which is a particular theory about how problem-solving methods can be configured from a library of components. The GDM approach, which is strongly tied to the KADS methodology, was developed in the ACKnowledge project. In the line of this thesis, this chapter shows how the work on a methodology with a task/method perspective forced us to concentrate on the systematic description of the nature of domain knowledge, that is, the ontology. Chapter 5 To reuse ontologies they must be indexed and stored in a library. Chapter 5 presents principles for organizing an ontology library in such a way that it can be used in a methodology which also makes use of reusable problem-solving methods. Chapter 6 describes a knowledge engineering workbench which exploits explicit ontologies to support knowledge elicitation, one of the main knowledge-engineering activities distinguished in chapter 3. The chapter shows that by making explicit how particular types of tool support depend on ontological commitments, a knowledge acquisition tool may provide strong support while remaining generally applicable. Chapter 7 explains how explicit ontologies can be used in the computational design of a knowledge-based system, which is another of the knowledge-engineering activities distinguished in chapter 3. Chapter 8 illustrates many of the ideas in the preceding chapters in the context of the development of a knowledge-based system for the management of acute radiation syndrome. Chapter 9 returns to the problem formulated in Sec. 1.2. The results of chapters 2 to 8 are used to formulate answers to the three research questions stated above.

Chapter 2

Methodological Background: The GAMES Approach This chapter introduces the GAMES methodology, which forms the background of most of the work presented in this thesis. The chapter attempts to provide a general overview of the issues involved in medical KBS development. Many issues that are touched upon are worked out in further detail in other chapters. Because the chapter is intended as a general overview of the approach, some aspects of GAMES which are described in this chapter reflect the work of others. This chapter is a slightly revised version of an article published in the Knowledge Acquisition Journal. It is co-authored by Giordano Lanzola, Guus Schreiber and Mario Stefanelli. The reference is: G. van Heijst, G. Lanzola, A. Th. Schreiber and M. Stefanelli (1994a). Foundations for a methodology for medical KBS development. Knowledge Acquisition, 6:395–434.

2.1 Introduction In the last decade expert systems have been built in numerous medical domains. Although some of these systems were able to solve non-trivial problems, thus illustrating the potential of Artificial Intelligence (AI) techniques in medicine, these systems have also been criticized. Frequently mentioned problems of knowledge-based system (KBS) technology include maintenance problems, limited explanatory power, problems with integrating KBSs in the workplace, and high development costs. Many researchers in the field have recognized these limitations, which are typical for new technology, and for most of the problems mentioned above solutions have been proposed. For example, the maintenance problems of first-generation expert systems were mainly due to the fact that different types of knowledge were mixed up in the knowledge base (Clancey, 1983). It is now a generally accepted principle that epistemologically different types of knowledge should be represented separately. Swartout (1983) tackled both the maintenance and the explanation problem by emphasizing that the underlying rationale of knowledge chunks should be recorded together with the rules. Wick and Thompson (1992) observe that explanation and problem solving are distinct tasks that require different information and different strategies. High costs of development are a feature that KBS share with other complex artifacts, and there is a standard engineering solution: the construction of libraries of reusable components. A large share of current research in KBS development can be qualified as an effort to discover reusable tasks and problem-solving 7

8


methods (Chandrasekaran & Johnson, 1993; McDermott, 1988; Musen, 1989a; Steels, 1990; Wielinga et al., 1992) and reusable domain ontologies (Gruber, 1992). Thus, KBS technology is rapidly overcoming the growing pains associated with first-generation expert systems. However, what is still missing to date is a general framework that organizes all partial solutions for the problems mentioned above into a road map for the construction of “secondgeneration expert systems”. This chapter presents results of work on a methodology for medical KBS construction. This work was performed in the context of the GAMES-II project, a European research project within the EC programme “Advanced Informatics in Medicine”. The aim of the project is to integrate the insights that have emerged during 10 years of KBS research into a comprehensive framework that covers central aspects of medical KBS construction. This chapter is organized in the following way. Sec. 2.2 presents an analysis of the specific requirements that distinguish medical applications from other applications, thus illustrating the need for a methodology that is specific for medical KBS. Sec. 2.3 describes the necessary components of a methodology. Secs. 2.4 to 2.8 describe how these components are realized in the GAMES approach and in Sec. 2.9 the present approach is compared with other proposals.

2.2 KBS Technology in Medical Organizations Although the previous section argued that there is a need for a general methodology for KBS development, the GAMES methodology is only intended for medical applications. In this section we present two arguments to justify this scoping decision. Firstly, the presented approach depends heavily on the existence of libraries of reusable components. As it would require an enormous amount of work to develop libraries for arbitrary domains, we have decided to concentrate on medical domains only, thereby increasing the likelihood that a component developed for reuse will actually be reused. More specifically, the approach is only to support KBS in the area of clinical curative medicine. Secondly, medical environments and medical knowledge have specific features that put additional demands on knowledge based systems. In particular, the high risks associated with wrong advice, the quick emergence of new insights and the diverse nature of the domain knowledge discriminate medical domains from many others: Reliability and interpretability of advice In medical environments the risks associated with decisions are very high. Often, decisions that must be taken affect the survival chances of patients. This puts a strong emphasis on the reliability of devices that are used as decision aids. However, because of the incompleteness of medical knowledge, it is often impossible to guarantee the reliability of medical KBS. In those circumstances it is up to the medical professional to decide whether the advice of the system should be followed. In other words, the health care professional must be able to use the KBS in such a way that the final decision still rests with the professional. This requires that the system must be able to explain its line of reasoning in terms that can be interpreted by the expert. Dynamic nature of medical knowledge Medical knowledge has a dynamic nature. For many people, health is one of the most important values in life, and a large amount of money is invested in health care and health related research. As a result of the research activities new insights emerge.

Chapter 2: Methodological Background: The GAMES Approach

9

Medical professionals must continuously keep their knowledge up to date. A KBS that advises the professional faces the same problem; whenever new insights emerge the knowledge base must be updated to reflect these new insights. Thus, the dynamic nature of medical knowledge requires that knowledge bases can be developed in an incremental way. Therefore, the maintenance of the knowledge base should preferably be done by the medical experts themselves. Diversity of medical knowledge For some medical problems there are well-tested detailed pathophysiological models available, while for other problems the medical expert has to fall back on intuitive rules of thumb which have proven useful in the past but have limited theoretical justification. This diversity can also be found in medical expert systems. For example, in an analysis of a number of medical expert systems de Vries Robbé and de Vries (1985) identified twelve different types of relations and dependencies often used in medical KBS. Another dimension on which medical knowledge differs is the abstraction level (Blois, 1984). The objects used in medical explanation reside at different levels: molecules, cells, tissues, organs and even psychological states can play a role in medical reasoning. They present different views on the phenomena of interest. When medical professionals solve problems they are able to integrate these different types of knowledge into a coherent line of reasoning. Expert systems that solve similar problems, with the same knowledge available, must also be able to do this.

2.3 General Approach Our purpose is to provide a general framework for the construction of medical KBS, or in other words, a methodology. In the most general sense, a methodology is a body of methods, rules, and postulates employed by a discipline. A more concrete definition can be found in Wielinga et al. (1989). They consider a methodology as a layered framework where each layer can be viewed as a building block that supports the layers on top of it. The result is referred to as the methodological pyramid (Fig. 2.1).

use

feedback

tools methods theory world view Figure 2.1: The Methodological Pyramid.

We briefly discuss each of the five components of the pyramid. To illustrate the meaning of the components, their role is explained in terms of an analogy with Newtonian mechanics, which can be viewed as a methodology for predicting changes in the physical world.

10


World view The “world view” layer of the pyramid refers to the principles and assumptions that underlie the methodology, thereby setting the boundaries for the ultimate scope. Sometimes these principles are so obvious that they seem trivial. However, there are many examples of principles that are trivial for one particular community but not for another. Making the world view explicit facilitates communication and it also facilitates comparison of a methodology with alternatives. In addition, it makes it easier for a potential user to establish if the methodology is appropriate for his/her goals. An example of a principle in the world view that underlies Newtonian mechanics is the assumption that the universe is homogeneous (i.e. the same laws apply everywhere in the universe). Theory The “theory” layer of the pyramid stands for a “declarative” description of the knowledge that is available in the domain of the methodology. Theories are usually formulated as a set of theorems: sentences that reflect the fundamental insights that the theory offers. The laws of Newton, such as “every action has an equal and opposite reaction”, are part of the theory level in the mechanics domain. Methods The “methods” layer represents the operations that can be performed with the expressions in the theory. In other words, theories describe the “what”; methods describe the “how”. For example, mathematical equations such as xt = x0 + v:t are used as methods in Newtonian mechanics. Tools Tools are the devices that support the methods. With tools we mean devices in the most general sense of the word. Thermometers, pen and paper, text editors, hammers and stethoscopes can all be considered tools. Any computer program that is able to solve differential equations would be an appropriate tool for Newtonian mechanics. Use The highest layer in the pyramid is labeled “use”. Use of the methodology will reveal shortcomings in the tools, the methods, the theory (Popperian falsification) and the world view (Kuhnian revolutions). In the following sections the methodological pyramid will be used as an organizing principle to present the GAMES approach to medical KBS construction. Starting with a description of the world view underlying the methodology, every following section will describe a higher level of the pyramid. This approach should not suggest, however, that we are trying to develop a new methodology from the bottom. In contrast, the work presented here builds on the work of many others. In particular, many ideas that the approach is based on were derived from the KADS methodology (Schreiber et al., 1993) and the PROTE´ GE´ framework (Musen, 1992). Where appropriate, these relationships will be highlighted.

2.4 World View The world view of a methodology represents the principles and assumptions upon which the methodology is based. In this section we elaborate the world view that underlies the approach that we advocate. The GAMES approach is based on three main principles: (i) knowledge-level modeling, (ii) emphasis on reusability of both task and domain knowledge, and (iii) integration of multiple reasoning techniques.


11

Knowledge-level modeling A decade after the publication of Newell’s (1982) influential article “The Knowledge Level”, the merits of an analysis of knowledge on a more abstract level than that of implementable representation languages have been recognized by a majority of researchers in the field. The key point underlying Newell’s argument was that AI research was too much focused on detailed representational issues. What was missing was a description of the rationality behind the use of AI techniques. He pleaded for a shift of emphasis in AI research from the “how” questions to the “why” questions. The knowledge level was his proposal for realizing a description of an AI system in terms of its rational behavior: why does the system (the “agent”) perform this “action”, independent of its symbolic representation in rules, frames or logic (the “symbol level”). Although there is certainly no general agreement about the exact nature of the knowledge level, there is little disagreement about its usefulness in knowledge acquisition. Knowledge-level models have been proven useful as a communication vehicle between domain expert and the knowledge engineer. The terminology used in the knowledge model is easier to understand for non-programmers because the statements are not blurred by implementational considerations, that are hard to understand without detailed knowledge about the particular interpreters. Reusability Another insight from artificial intelligence is that intelligent behavior requires an enormous amount of “world knowledge”. Even solving relatively simple problems involves a large amount of background knowledge. Lenat and Feigenbaum (1991) formulate this insight as the knowledge principle: If a program is to perform a complex task well, it must know a great deal about the world in which it operates. In the absence of knowledge, all that you have left is search and reasoning, and that is not enough. Knowledge based systems require large bodies of knowledge. The acquisition of such bodies is a cumbersome and time consuming enterprise. For this reason there would be a high pay off if knowledge could be reused for multiple applications. In the knowledge acquisition community there seems to be a growing understanding that there are at least two types of reusable knowledge: problem-solving methods and domain ontologies. GAMES adheres to this view as well. Integration It has become clear that there is no such thing as the universal representation language. The problems that experts solve are typically intractable and require specialized inference procedures. The problems with general problem-solving architectures have lead to the proposal of so called “hybrid representation languages”. These are large systems with multiple interpreters and algorithms for switching from one interpreter to the other. The different interpreters are usually closely integrated in such systems, and they have a fixed way of communication. The problem with such a “symbol level” integration of problem-solving methods is that it is too rigid. For instance, KRYPTON (Brachman et al., 1985) makes a distinction between definitional knowledge, which is represented in a semantic network language, and assertional knowledge, which is represented in first-order predicate logic. The rationale is that definitions are usually organized in subsumption hierarchies and this allows more efficient retrieval. Although a system like KRYPTON does indeed reason more efficiently, because it has specialized inference machinery for particular queries, it does not solve the problem in general. Experts are able to solve problems because they use inference strategies that happen to fit well with the problems encountered. In domains where

12


the bulk of the knowledge consists of definitional knowledge KRYPTON will do a good job, but in other domains it will not perform better than a traditional first-order theorem prover. The aim of GAMES is to provide an architecture that supports the integration of a variety of reasoning methods in various ways, depending on a particular domain. Features of the domain should determine which reasoning techniques are employed and in what way they are integrated. We will call this knowledge-based integration as the integration depends on the structure and the contents of the domain knowledge, and not on the formalism used.

2.5 Theory In the context of KBS construction “theory” refers to what the methodology considers to be the end product of a development project. As implied by the term “knowledge-based system” a methodology for constructing such systems should say something about both knowledge and (computer) systems. In GAMES these issues are addressed through the use of two models: the epistemological model, which is a knowledge-level description of the knowledge that is required to perform the expert task, and secondly, the computational model which is a symbol-level specification of the representations and algorithms required to have a computer perform that task. In the remainder of this section we will describe these two models and their interrelation in detail.

2.5.1

Epistemological Model

A GAMES epistemological model consists of three components: (i) ontology and application knowledge, (ii) inference model and (iii) task model. The ontology is a relatively use-independent representation of the conceptualization of the domain. It describes the concepts and the relations between the instances of those concepts in a particular domain. The inference model describes the possible manipulations of that knowledge in order to derive new facts. The task component guides the selection of inferences in the inference model. The components of the epistemological model roughly correspond to three layers of the KADS four-layer model (Wielinga et al., 1992), although they differ in their actual contents. The components of the epistemological model can also be mapped on the characteristics of Newell’s knowledge-level agents: the knowledge of the agents is represented in the ontology; the repertoire of actions corresponds to the inference model; and the goals of the agents are reflected by the tasks. Inference model Wielinga et al. (1992) define an inference model (or inference structure, in their terminology) as a model of the problem-solving competence of an intelligent agent. Thus, an inference model describes all the possible actions at the agent’s disposal during problem solving. Although it is in principle possible to formulate the inference model by enumerating all the possible inference actions, it is more convenient to specify inferences on a more abstract level. Therefore we formulate the inference model in terms of inference types, sets of inferences that are similar according to some criterion. Different candidates have been proposed for such a criterion in the literature. For example, the developers of the KADS methodology have based their typology on the operations that can be performed on an abstract ontology (Wielinga et al., 1992; Aben, 1993). The typology of inferences used in GAMES is based on the work of the philosopher Peirce, who discerns three main inference categories that he considers the fundamental and prelogical


13

characters of reasoning: deduction, abduction and induction.1 This classification is based on the compellingness of the argument and on the distinction between universals, general statements about classes of individuals, and particulars, statements about specific individuals. Deduction refers to the class of inferences that combine particulars and universals to derive new particulars. Deduction is truth preserving: when the statements that the inference is based on are true the derived statement must be true as well. Abduction Abductive inferences are also based on the combination of particulars and universals to derive other particulars. However, in contrast with deduction, abduction is not truth preserving. When the premises are true it does not necessarily follow that the conclusion is true as well. It is also said that abduction is logically unsound. Induction refers to the inferences that combine particulars. Peirce distinguishes three different types of induction. Two of these involve synthesizing particulars into universals. However, here we are mainly concerned with Peirce’s third type of induction, which involves the comparison of particulars to confirm or falsify another particular (e.g. a hypothesis). Besides the inference type, a second element type in inference models is the knowledge role. A knowledge role is a functional name for a part of the domain knowledge, describing the role that this part plays in problem solving. Typical examples of roles are “hypothesis” and “observation”. Roles allow the inference model to refer to the domain knowledge in a domain-independent way, which is important for reusability. An important hypothesis of the GAMES approach is that clinical tasks can be modeled as (possibly multiple) instantiations of one particular inference model: the select and test model, or STModel (Ramoni et al., 1992), shown in Fig. 2.2. The arcs in the figure represent the inference types and the ellipses the knowledge roles. The inferences will be described in the order indicated by the arrows, starting from abstraction. The abstraction inference represents the reformulation of the problem in expert terminology. Abstraction involves both ignoring irrelevant details and adding higher level structure to the initial problem description. We have added abstraction to the inferences of Peirce because of its importance for expert performance.2 The abstraction inference is intended to model the preprocessing-of-data step that experts typically do before they start to consider potential solutions for the problem that they are facing. In principle, this preprocessing-of-data step could be modeled as a complete hypothetico-deductive reasoning process itself, possibly using another STModel. However, in many occasions the abstractions are really simple (e.g. temp > 38 ==> fever = present) and it would be overkill to use an entire STModel for modeling such a simple situation. The abstraction inference is intended for those situations. Of course, in cases where the abstractions are complicated it would be more appropriate to model the abstraction process as a separate subtask. The knowledge pieces derived by abstraction are called problem features in the STModel. Starting from these problem features, abductive inference is used to generate a set of potential solutions: the hypotheses. Abduction can be considered as the backward traversal of deductive 1

Of course, Peirce distinguishes many more categories, as he considers the classification of arguments as the main subject of logic, but each of the other categories can be considered as a specialization of deduction, abduction or induction. 2 Peirce does acknowledge the importance of abstractions. However the concept is only treated in the context of the information content of terms, not as a distinct inference type (see Peirce, 1932; p. 255).

14


ranking

hypotheses

abduction

problem features

induction

deduction

abstraction expected/ observed data

request new data

Figure 2.2: Generic inference model (STModel) used in GAMES. The arcs in the figure represent inference types, the

ellipses represent knowledge roles.

chains of inference. Bylander et al. (1991) have shown that abduction is in general intractable. Therefore, abductive inference is often guided by minimality criteria to reduce the search space. The pros and cons of different minimality criteria is the subject of much current research in artificial intelligence (Peng & Reggia, 1986; Console & Dupré, 1992). An example of an abductive inference in diagnosis would be to generate a set of diseases, or groups of diseases, that might have caused the presence of fever. Before the generated hypotheses are discriminated, they can be ranked according to some criteria. The purpose of this ranking step depends on the particular situation. An obvious criterion would be to test likely hypotheses first, but other criteria such as risk for the patient and cost of testing might be involved as well. It is also possible to apply multiple criteria at the same time. Ranking is used to determine only the order of testing of the hypotheses: it does not provide a way of deciding which hypotheses can be considered as solutions. After the hypotheses have been abducted and ranked, deductive inference is used to explore their consequences. For each hypothesis expected consequences are derived. These expected consequences represent features of the situation that would result if that hypothesis would be the solution for the problem. For example, in diagnosis the expected consequences would be features that can be observed in the patient (e.g. the presence of localized rash for extensive chronic graft-versus-host disease). The deductive inference is also called prediction. Once predictions have been derived from hypotheses, they need to be compared with the actual situation. The request new data inference in the STModel represents the process of obtaining information about the actual situation. Strictly speaking, this is not a real inference because it is not a purely syntactic operation such as the other inferences. Induction involves comparison of singular statements. In the STModel the compared state-


15

ments are the deduced predictions and the obtained knowledge about the patient’s actual condition. Since hypotheses are ranked at the beginning of the testing phase, some hypotheses will be tested before others according to the adopted ranking criteria. During this phase, induction corroborates those hypotheses whose expected consequences turn out to be in agreement with the state of affairs in the patient and refutes those which failed this test. Induction closes the cycle of the inference model of medical reasoning. As mentioned above, one of the hypotheses of GAMES is that the STModel is sufficiently general to model clinical reasoning. We will now present some arguments to substantiate this. The first argument is based on the level of abstraction of the STModel. Many authors have argued that, at a very abstract level, problem solving can be considered as a process of generating possible solutions that are then verified (Simon, 1985; Patil, 1988) and there is ample evidence that medical experts follow this scheme as well (Elstein et al., 1978; Chi et al., 1988; VanLehn, 1989). From the description above it will be clear that the STModel is a rather straightforward implementation of the reasoning steps involved in the generation and subsequent verification of possible solutions. The generality of the STModel is also illustrated by Ramoni and Stefanelli (1992) who show that many well known problem-solving methods [e.g. Heuristic Classification (Clancey, 1983), Propose-and-Revise (Marcus & McDermott, 1989), Cover-and-Differentiate (Eshelman, 1988)] can be considered as special cases of the STModel. The second reason for us to hypothesize that the STModel is sufficient to model clinical reasoning is based on the analysis of tasks that will be presented below. We have found that many clinical tasks can be decomposed into sequences of diagnosis, therapy planning and patient monitoring. For each of these generic tasks it will be shown that they can be described in terms of the STModel. Ontology As in the PROTE´ GE´ -II framework (Gennari et al., 1994), GAMES makes a distinction between application knowledge and application ontology. Whereas the application knowledge refers to the expressions that are true in a particular domain, the ontology is a meta description of what can be contained in the domain knowledge. In other words, the application ontology specifies under which conditions an expression may be part of the application knowledge. For example, the statement that there are causal relations between states and that the causal relation is anti-symmetric (if A causes B, B cannot cause A) would be part of the ontology. However, the statement that ischemia causes necrosis would be part of the application knowledge. The rationale for this distinction is that a meta description of the types of knowledge will probably be reusable across a number of domains, while the application knowledge will by definition be domain specific. Furthermore, as we shall see in greater detail later, an explicit representation of the ontology is very convenient for knowledge acquisition and for construction of the computational model. Defining the domain ontology for a particular purpose (e.g. the construction of a KBS) involves the decision about which kinds of domain knowledge need to be represented to solve problems in that domain. Many authors have observed that two kinds of ontologies have been predominant in modeling medical problem solving: causal ontologies and taxonomic ontologies (e.g. Miller et al., 1982; Simon, 1985). However, this is a coarse-grained classification: both kinds have been modeled in different and incompatible ways. The term “causal ontology” for example, has been used for a number of different views on the relation between causes and effects. For instance, in KBS as CASNET (Weiss et al., 1984), CADUCEUS (Pople, 1985), and ABEL (Patil et al., 1981) causal ontologies are modeled as networks where the nodes represent states and the links represent causal

16


relations between those states. In other systems, causality is modeled by means of models of the structure and behavior of systems (de Kleer & Brown, 1984; Forbus, 1984; Kuipers, 1986). In this approach, the causal relation links variables rather than states. These variables represent attributes of the system to be modeled, and a causal relation represents the fact that a change of a variable produces a change in another variable. The term “taxonomic ontology” has also been used in many different ways. The main characteristic of these ontologies is that their prime relation is some form of the subsumption relation (e.g. is-a, subclass-of, etc.). Since an ontology determines what can be represented, it also determines what can not be represented. GAMES, being a general approach for medical KBS construction, should therefore provide an ontology that is sufficiently expressive to capture all subtleties involved in medical reasoning. However, the example of causality above already illustrates that there is no such thing as the causal ontology. There are many ways of defining causality, each with its own virtues and restrictions. The decision about which conceptualization is best depends on features of the domain of the application. For example, in many medical domains structural models of the organism are simply not available. Thus, the coexistence of different views on the structure of medical knowledge makes it difficult to provide a generic ontology for medical reasoning. In addition, an ontology that covers all aspects of medical reasoning needs more than the definitions of causality and subsumption. Medical reasoning involves a huge amount of knowledge which is not typically medical. The simple observation that the fever of a patient has been increasing for 3 days involves knowledge of temporal relations, knowledge of dimensions and knowledge of scales. Knowledge of time in turn requires knowledge of time intervals (years, weeks, days, : : : ), and their relations (before, after, : : : ). All of these concepts can be (and have been) defined in different and incompatible ways. In summary, there are two reasons why it is not possible to provide a generic ontology for medical reasoning: (i) the ontology would need to cover different and incompatible conceptualizations and (ii) such an ontology would be so large that it becomes difficult to handle. Because of the problems mentioned above, we do not attempt to define a general ontology. Instead, GAMES provides a library of theories, that can be configured into an application ontology, an ontology that is well suited for a particular application. Such theories are internally consistent sets of interrelated definitions and constraints that together constitute a “knowledge module”. While some knowledge modules will be at a very abstract level (e.g. defining “objects with slots”) others will be very specific (e.g. an ontology about contagious diseases). Theories on lower abstraction levels will depend on theories on higher levels. Such dependencies are represented by means of inclusion relations between the theories. For example, Newton’s theory of mechanics is based on a particular view on time: time is defined as a continuous entity that does not depend on any external influences. In our library this would be reflected by having “Newtonian mechanics” include “absolute time”. An alternative theory of mechanics (e.g. relativity) could be based on another definition of time. So “relativity” would include “space-time” instead. Such inclusion relations can be considered as constraints on the configuration of application ontologies. Application ontologies can be quite domain specific, for example including definitions of concepts as “infection”, “bacterion”, “blood vessel” etc. The GAMES ontological library is described in chapter 5. The use of a library circumvents the compatibility problem. However, the size problem remains, but now for the library. The objective of the GAMES project is to provide an initial ontology library with definitions of concepts often found in medical KBS. Further, the project is developing indexing schemes for organizing the library, and methods and tools for extending the


17

library. In this way, the development of the library becomes a joint effort of all the users of the methodology. A library of ontologies needs to be formulated in a language. GAMES has adopted Ontolingua (Gruber, 1992) for this purpose. Ontolingua, a frame based extension of KIF (Genesereth & Fikes, 1992), is developed as part of the knowledge sharing effort described by Neches et al. (1991). The language is based on predicate calculus, but supports the explicit representation of additional knowledge differentiations such as the distinction between definitional and assertional knowledge and it provides theory inclusion as a modularity construct. Further, the language comes with the Frame Ontology, which contains standard definitions for primitives often used in knowledge representation systems. Ontolingua is a modeling language and not a reasoning language: there is no Ontolingua interpreter. However, the developers of the language do provide a translation architecture: a computer program that facilitates the translation of Ontolingua theories into executable representation languages. This translation architecture turns out to be very useful for the construction of the computational model (see Sec. 2.6.2). Task model Tasks are related to the goals of Newell’s knowledge-level agent. Whereas the inference model embodies the potential inferences that can be made, the task describes which inferences should actually be made in order to achieve a goal. Following Chandrasekaran (1987), GAMES assumes that complex reasoning tasks can be decomposed into a number of basic or generic tasks. These basic tasks can be described in terms of the goals that they achieve and the labels that they use for the roles in their inference model. As mentioned in Sec. 2.2, the GAMES project concentrates on systems in the field of clinical curative medicine. Many tasks in this field, or at least the tasks that we have investigated, can be decomposed into sequences of three basic tasks: diagnosis, therapy planning and patient monitoring. These tasks achieve different goals, and can have different control regimes. However, they are all based on the same inference model, the STModel. The roles in the STModel are differentiated for the three generic tasks. For example, the problem features role in Fig. 2.2 is named “patient findings” in diagnosis and “therapeutic problems” in therapy planning. Given the fact that we limit ourselves to medical problem solving it is also possible to say something about the mapping between the roles in the inference model and the application ontology. Each of the three generic tasks will now be described in terms of the above-mentioned attributes. Diagnosis can be considered as the task of selecting an explanation for the patient’s condition. This task can be associated with different goals. The most obvious goal is that of reaching an evidential hypothesis. In this case, there are a number of observed findings in the patient and the goal is to find the hypothesis that best explains these findings. However, other diagnostic goals are also found in medical practice. For example, that of determining the grade of an (already known) disease in a patient. One of the current activities in GAMES is the creation of a collection of such prototypical goals because these can be associated with particular control regimes. We will return to this issue in Sec. 2.5.2. Therapy planning concerns the selection of a set of actions leading to a desired future state (i.e. improved condition of a patient). Just as with diagnosis, therapy planning can be associated with a number of goals. For instance, a typical goal for therapy planning is the selection of the best therapy for a particular patient, given a number of possible treatments. Other goals frequently found in therapy planning are the establishment of the utility of a particular treatment for a particular patient and the selection of prophylactic treatment. In therapy planning, the hypotheses are usually therapies or treatments. The mapping of the problem features and the data on domain

18


classes is more complicated. Typically, the data consist of a disorder, which might be the output of a diagnostic process, and other possibly relevant aspects of the patient and the situation. These data are then abstracted into so-called therapeutic problems, critical aspects of the patients condition which can be interpreted immediately as a list of crucial targets of the therapy. Sometimes, therapy planning also requires a description of the desired future state of the patient. If this is the case, such a description should also be part of the data. Monitoring refers to the process of observing and controlling the course of a patient’s condition. To this aim, an intelligent agent should be able to predict the course of a patient’s condition under the combined action of diagnosed disorders and selected therapies. If the selected therapy works and the patient is responding appropriately according to the used patient model, the therapy is continued or the patient is released from treatment (the testing phase). If the therapy does not work or if unusual findings arise, further assessment is necessary (the selection phase). As a result of monitoring, previous diagnoses and therapy plans are confirmed or falsified. In the former case, monitoring involves continuous cycling between deduction and induction, while in the latter case diagnosis and/or therapy planning may be invoked again. In GAMES, the task model is a configuration of instances of the three medical generic tasks. In the epistemological model, each of the generic-task instances is associated with a typical goal. Contrary to KADS, however, the task model does not contain a detailed specification of the control regime. This is specified in the computational model.

2.5.2

Computational Model

The epistemological model is a knowledge-level description of the knowledge and the methods needed to perform a task, or achieve a goal. The computational model is a symbol-level specification of representations and algorithms to perform that task. The architecture of the GAMES computational model must fulfill two requirements: (i) it must easily be mapped onto the epistemological model, and (ii) it must allow the use of multiple knowledge representations and reasoning techniques. Fulfillment of the first requirement facilitates implementation and debugging of the system and it allows the construction of an explanation facility that generates expert-understandable explanations. As argued in Sec. 2.4, the second requirement is important for circumventing the tractability problems usually associated with “weak” methods. Currently, the architecture of GAMES computational models is loosely based on the notion of a control blackboard architecture, which is one well-known architecture that fulfills the abovementioned requirements. However, other architectures that fulfill the requirements can be used as well. Control blackboard architecture Blackboard systems consist of a blackboard and a number of knowledge sources (Nii, 1986). The blackboard is a central information repository that represents the state of the problem-solving process. The knowledge sources are mechanisms that can inspect and, if their triggering conditions are satisfied, can modify the blackboard, thus driving problem solving. Knowledge sources are problem-solving modules that are specialized for particular types of problems whose internal representations and strategies are hidden for the other components of the architecture. Thus, knowledge sources may be considered as black boxes. The blackboard may be divided into different spaces, and knowledge sources may only be allowed to inspect or modify a limited number of spaces.


19

When multiple knowledge sources are triggered at the same time, a control problem arises. This problem was solved by the introduction of control blackboard architectures (Hayes-Roth, 1985). These systems are blackboard systems augmented with a module specialized in conflict resolution. In the original proposal this module was implemented as a blackboard with knowledge sources as well. In the architecture adopted in GAMES the control module is implemented through a set of meta rules. The epistemological model can be implemented on a control blackboard architecture in the following way. The inferences in the inference model are realized as knowledge sources in the computational model. This involves the assignment of particular knowledge sources to particular inference steps in the STModel. The knowledge roles in the STModel are represented as different spaces on the blackboard. Thus, there would be a space for problem features, a space for hypotheses etc. This allows us to implement the role limitations in the epistemological model by means of read and write permissions for spaces on the blackboard. For example, the inspection and modification permissions of the knowledge sources assigned to abduction would be restricted to the problem-feature space and the hypotheses space. The relation between the ontology and the blackboard architecture is less evident. The knowledge sources need access to the domain knowledge. However, it was already mentioned that knowledge sources may use private representations that are well suited for the particular reasoning technique that they use. Thus, mapping the ontology on the computational model involves translation into multiple representations. This will not always be possible, because of limitations in expressiveness of some representation formalisms. This issue will be addressed in detail in Sec. 2.6. As mentioned above, control of inferencing is handled by a set of meta rules. The meta rules inspect the current state of problem solving (the blackboard) and decide which knowledge source should be invoked next. Meta rules can thus be used to implement problem-solving strategies that are well suited for particular tasks. Below we will describe the meta-rule language provided by GAMES. Problem solvers Knowledge sources are usually implemented as sets of production rules. However, the black-box nature of the knowledge sources also allows the incorporation of other reasoning techniques and representations. In the remainder of this chapter a combination of a representation and a reasoning technique will be called a problem solver. There are two reasons for allowing multiple representations and reasoning techniques in the computational model. The most important of these is that the GAMES approach requires that the knowledge is represented in a way that resembles the way it is modeled in the epistemological model. Since medical reasoning involves different types of knowledge this implies that different representation languages should be used. Secondly, the inference steps in the STModel have different computational requirements. For example, it has been proved that abduction in general is NP-hard, and thus requires heuristic techniques that use preferences or probabilities. Since other inference steps will have other computational requirements, the GAMES approach should allow for the use of multiple reasoning techniques. From the discussion above it may seem that we can provide the GAMES user with a particular configuration of problem solvers with for each inference in the STModel an adequate problem solver. However, the adequacy of a problem solver also depends on the domain knowledge. For example, in the case of abduction in medical diagnosis it makes a significant difference if there are twenty or twenty thousand diseases in a particular domain. For this reason, the configuration

20


of the problem solvers into a blackboard system can only be done after knowledge acquisition. A large amount of research in artificial intelligence involves the development and evaluation of reasoning techniques. In principle, the GAMES approach allows the use of all of these techniques. However, for practical purposes we limit ourselves to a set of selected techniques that we believe represent typical examples of reasoning often found in medical settings. A first example of such a technique is reasoning in causal-probabilistic networks. Problem solvers based on this technique employ knowledge about probabilities that particular states in particular contexts cause other states of the patient. In medicine causal-probabilistic networks are often used for decision models. This technique has the ontological requirement that knowledge can be represented in terms of probabilistic causal relations. Another example is qualitative simulation of physical processes. This type of reasoning is based on a physiological description of an organ in terms of compartments and flows between the compartments. Medical professionals use these models, for instance, for the prediction of the effects of drugs. This techniques requires that knowledge can be represented in terms of compartments and flows. A third reasoning technique used is associational reasoning based on frames and production rules. This technique may seem more general than the other two, in the sense that it is not based on ontological assumptions as to the existence of a causality relation or a compartment class. However, there are many types of knowledge that are difficult to represent in production rules (e.g. uncertainty). Therefore, the applicability of such techniques also depends on the application ontology.

Communication on the blackboard The fact that the problem solvers use different knowledge representations poses a potential problem: how can they cooperate to solve a problem if they don’t understand each other. Since the blackboard is the only medium for information exchange the question can be reformulated as “what expressions are allowed on the blackboard and how are they interpreted by the problem solvers”, or in other words, what is the language for blackboard communication. A first requirement for such a language is translatability. The problem solvers should be able to translate the expressions into their private representations in order to do their job, and they should also be able to translate their solutions into that language before putting them on the proper blackboard space. Thus, the communication language must at least be as expressive as any of the representation languages of the selected problem solvers. The second requirement for the communication language has to do with the role of the blackboard during problem solving. At the beginning of the problem-solving process, the blackboard contains a description of the problem. When problem solving proceeds the problem solvers modify the blackboard, changing the problem description into a description of the solution. The state of the blackboard after problem solving (the situation specific model; Clancey, 1992) is also considered as an explanation of the derived solution. To be an explanation something should be understandable, so the second requirement of the communication language is understandability. Taken these requirements into consideration, an obvious candidate for communication language is the language for representing domain knowledge in the epistemological model. This language is intended to be both expressive and understandable. The translation process will be described in detail in Sec. 2.6.2.


21

Implementing tasks: the meta rules As described in Sec. 2.5.1, the epistemological model for a particular application contains a decomposition of that task into a collection of generic-task instantiations, where each of these is associated with a particular goal. It was also mentioned that such a prototypical goal can be associated with a particular control regime. We will now explore this issue in further detail. The control regime determines in which order actions must be undertaken to solve a problem. In GAMES this regime is implemented using a tailored meta-rule language. The condition part of these meta rules consists of a number of queries on the blackboard. When these conditions are satisfied the action part of the meta rule is triggered. The action involves the invocation of a subtask or an inference step of the STModel. The meta rules can be classified into two groups. Meta rules of the first kind have as action part the invocation of a subtask. In turn, such a subtask is implemented by meta rules as well, thereby giving rise to a task-subtask decomposition. These meta rules are similar to Steels’ decomposition methods (Steels, 1990). Note that this implementation allows for dynamic method selection. Meta rules of the second kind directly invoke the inferences steps of the STModel in their action part. These correspond to Steels’ action methods. Fig. 2.3 shows a typical generic-task instantiation, where different problem solvers implement the different steps in the STModel. blackboard

problem solvers

task agenda

solution model qualitative simulation hypotheses problem features

causal probabilistic network

data production rules + frames

Figure 2.3: A computational model where abstraction is done by a production rule interpreter, abduction by a causal-

probabilistic network and deduction by a qualitative simulator. The problem solvers are allowed to inspect and modify only the spaces that are their inputs and outputs. For example, the production rule interpreter is allowed to read only in the data space of the blackboard and it is allowed to write only in the problem features space.

The sequencing of the inference steps within an STModel depends on two factors: the initial task that was invoked and the emerging situation on the blackboard. For every prototypical goal that can be associated with a generic-task instantiation there is a set of meta rules that implement the task to achieve that goal. These rules can set up their own subtasks, thereby generating a sequence of inferences that is well suited to achieving the original goal. Thus far we have concentrated on the control regime within generic-task instantiations. However, real applications often perform tasks that consist of combinations of these instantiations. We

22


will use the term “global control regime” to refer to the rules that control the sequencing of the generic tasks. The global control regime is implemented using a special kind of meta rule. These special rules have in their conditions queries on the blackboard of one generic-task instantiation, and their actions invoke tasks in another generic-task instantiation.

2.6 Methods In the previous section we described the epistemological model and the computational model that are the result of a GAMES KBS construction project. In this section we concentrate on the dynamic aspects of KBS development: what actions must be taken to construct the two models. There are two principal participants in the KBS construction process: the knowledge engineer and the domain expert. One aspect that needs to be addressed here is the allocation of duties between these two. A major principle underlying the GAMES methods is that the amount of work done by the domain expert should be kept to a minimum. A first observation that can be made is that the epistemological model needs to be constructed before the computational model. Although this seems obvious, there are other options as well. For example, Rademakers and Pfeifer (1992) have proposed an “evolutionary” approach where the two models are constructed in an iterative way. Their approach can be considered as the knowledge modeling equivalent of rapid prototyping. Although GAMES also allows for iterative construction of the two models, it is different in the sense that knowledge engineers will proceed to the construction of the computational model only when they have the feeling that the epistemological model is relatively complete.

2.6.1

Construction of the Epistemological Model

Construction of the epistemological model involves four activities: 1. 2. 3. 4.

construct a task model for the application select and configure appropriate ontologies, and if necessary refine these map the application ontology onto the knowledge roles in the STModel instantiate the application ontology.

Fig. 2.4 shows the relation between these activities, the GAMES supplied libraries and the components of the epistemological model. It also shows who is the main person responsible for each activity. The remainder of this section describes the four activities in further detail. Constructing a task model for the application The first activity in KBS construction is task analysis. The purpose of the task analysis is to decompose the real-life task into a number of generic medical tasks (diagnosis, therapy planning and patient monitoring). As described in Sec. 2.5.1 these generic tasks are all instantiations of the STModel, where the knowledge roles (the ellipses in Fig. 2.2) have task specific labels. A real-life task often found is the combination of diagnosis and therapy planning. For example, the task of managing graft-versus-host disease (GVHD) after bone marrow transplantation involves both a diagnostic task and therapy planning activities. The task model for such a task consists of two STModels. In this stage of the knowledge acquisition process the different STModels are independent entities. Their integration is realized later in the knowledge acquisition process through the mapping of the knowledge roles onto the ontology and through the specification of the global control regime.


Generic Epistemological Model components

23

Epistemological Model of the application

ST Model library Knowledge roles Medical generic tasks: diagnosis, therapy planning monitoring

construct task model for application

knowledge engineer or informed expert

hypothesis datum problem feature

map knowledge roles onto application ontology

Ontology library Multiple theories containing type definitions for e.g.: finding, disease time, scale, etc.

Application ontology disease disease-subtype-of finding observable

select ontologies and configure

GAMES-II Theory

domain expert

instantiate application ontology

Application knowledge GVHD

Medical Lexicon

Database of standardised medical vocabulary

provide standard terms

acute GVHD

grade I grade II

chronic GVHD

grade III grade IV

Figure 2.4: Activities in the construction of the epistemological model.

Selecting and configuring an application ontology When the task of the target system is recognized as a prototypical task or a sequence of prototypical tasks, KBS construction proceeds with the construction of a domain ontology. As described in Sec. 2.5.1, the ontology is a description of the structure of the domain knowledge. In general, ontology construction is a difficult process that requires the expertise of a knowledge engineer or an informed domain expert. The GAMES library of ontological theories is used in this process. The knowledge engineer can select these and, if necessary, tune them to meet the demands of the application. In Sec. 2.5.1 we explained that there are dependencies between the theories that guide the selection and configuration process. Fig. 2.5 shows a partial example ontology, derived from the way in which domain knowledge is described in INTERNIST (Miller et al., 1982). Mapping application ontology onto STModel roles The application ontology defines the relevant classes, relations and functions in the domain. When performing a generic task, instances of particular domain classes typically fulfill particular roles in problem solving. For example, in medical diagnosis, instances of class disease will have the role of hypotheses. This mapping is

24

The Role of Ontologies in Knowledge Engineering finding

manifestation of

disease

relation

relation

class

importance

evoking strength

frequency

function

function

function

Figure 2.5: Example domain knowledge types, derived from the ontology underlying INTERNIST (Miller et al., 1982).

The terms class, relation and function refer to the Ontolingua primitives that were used to model these concepts. Note that findings are modeled as relations whereas diseases are modeled as classes. The reason for this is that findings are complex objects, consisting of an observable, an operator and a value.

specific for tasks and domains as is illustrated by the fact that in therapy planning diseases will often play the role of data. We mentioned above that the different STModels are independent at the task level. One of the ways to accomplish their integration is through the mapping of these models onto the application ontology. For example, the mapping of both diagnostic hypotheses and therapeutic data onto the ontological class disease indicates that hypotheses derived via diagnosis may be considered as data for therapy planning. The ontology-mapping activity is usually straightforward in medical tasks. However, since the activity requires detailed knowledge of the structure of the epistemological model it must be carried out by the knowledge engineer. Instantiating the application ontology While the application ontology defines which classes, relations and functions can be found in the domain, the application knowledge is expressed by the actual instances of these classes and relations. Besides the reusability aspect, one of the main arguments for distinguishing between the ontology and the application knowledge is that the application knowledge must by definition be presented by the medical expert. These considerations are similar to the those that led to the development of PROTE´ GE´ (Musen, 1989b). When the application ontology has been defined, instantiating it is straightforward. In Fig. 2.4 the instantiation of the application ontology is supported through a medical lexicon. Such a lexicon would ensure the presence of correct and potentially sharable terms in the knowledge base of the application. One of the longer term research goals of GAMES is to make such facilities available to the user. knowledge roles

ontology

application knowledge

expected datum

problem feature

disease

observable

SGOT liver size

hypothesis

rash

veno occlusive GVHD disease

abductive knowledge

deductive knowledge

manifestation of

liver size = enlarged rash = present manifestation of manifestation of veno occlusive disease GVHD

Figure 2.6: Example knowledge elements illustrating the three-level organization of medical domain knowledge.

Fig. 2.6 shows a fraction of an epistemological model for diagnosis in the GVHD domain.


25

The terms on the highest level represent knowledge roles in the STModel for diagnosis. The terms in the middle level are classes and relations in the application ontology and the lowest level represents the application knowledge.

2.6.2

Construction of the Computational Model

An important hypothesis underlying the GAMES approach is that the availability of a completed epistemological model enables the knowledge engineer to develop the computational model without further assistance of the domain expert. This hypothesis is based on the observation that there are two kinds of considerations that affect the nature of the application: considerations that are related to the task and the domain of the application, and considerations as to whether which computational techniques are appropriate. The domain expert only has knowledge for the first type of considerations, and this knowledge is reified in the epistemological model. The second type of considerations involves knowledge about representations and algorithms and should therefore be made by a programming expert. The above hypothesis assumes that it is possible to develop a complete epistemological model without computational considerations and without feedback of a running prototype of the application. In practice, this assumption will sometimes be violated. However, even in situations where it is not possible to develop a full-fledged epistemological model without computational considerations, the GAMES approach attempts to keep the need for a domain expert for the construction of the computational model to a minimum. We discern three activities in the construction of the computational model: (i) selection/construction of the meta rules, (ii) selection of problem solvers and (iii) translation of the domain knowledge into the representations of the selected problem solvers. Selecting or constructing an appropriate set of meta rules The task level of the epistemological model consists of a set of generic medical tasks. These tasks have two components: an instantiated STModel and a goal statement. GAMES provides sets of meta rules that implement typical control procedures for these goals. Thus, on the level of generic tasks the control knowledge is provided by the GAMES approach. As already mentioned in Sec. 2.5.2, the global control regime needs to be specified as well. Since this regime depends heavily on the actual task of the KBS under construction, it needs to be defined by the knowledge engineer. Besides the ontology mapping, the global meta rules are the second way in which the different STModels that together realize the real-life task are integrated. Selecting problem solvers The next activity in the construction of the computational model involves the selection of problem solvers that are both epistemologically and computationally adequate. By epistemologically adequate we mean that the ontology of the epistemological model is compatible with the ontological assumptions underlying the problem solver. Computational adequacy refers to the computation time and memory resources that it will take to solve typical problems in the domain. Thus, for GAMES to support the selection of problem solvers we need a description of the ontological assumptions and the computational characteristics of a number of problem solvers. As mentioned in Sec. 2.5.2 GAMES restricts itself for practical reasons to a small number of problem solvers. However, in the long run the project hopes to profit from the many efforts by AI researchers to determine the computational and representational properties of various reasoning techniques.

26


Translating the knowledge into appropriate formalisms After the inferences are assigned to problem solvers the next activity is to translate the domain knowledge into the representation formalisms of the problem solvers. Such a translation only needs to be partial because the problem solvers are responsible only for a particular inference step of the STModel: a problem solver used only for abstraction does not need knowledge used only in deduction. Further, such a translation will be ontology specific: the exact nature of the translation depends on the contents of the application ontology. For example, in a situation where diagnostic abduction is done by a bayesian network interpreter with a representation that consists of nodes with admissible values and probability distributions, instances of the ontological class disease could be translated into probabilistic nodes with the admissible values present and absent. Because this translation is application specific, it needs to be specified as part of the knowledge engineering process. To facilitate this activity for the knowledge engineer, the translation operation is divided into two steps: an knowledge intensive mapping of the application ontology onto a representational meta model of the problem solver, and an automatic translation of the representational meta model into the private representation of the problem solver. A representational meta model is a declarative description of the kinds of expressions that can be interpreted by a particular problem solver. The division in two steps facilitates translation because only the mapping step is application specific. The further translation into the private representation may be complicated, but needs to be specified only once for each problem solver. Specific details of this approach to integration of problem solvers can be found in chapter 7.

2.7 Tools It has long been recognized that knowledge engineering, even when guided by a methodology, is a cumbersome and error prone enterprise. Therefore the potential gains of tool support are large. However, tools are only useful inasmuch as they support an underlying methodology. For this reason, the development of KE methodologies and KA tools go hand in hand. Within GAMES, a number of tools have been developed for supporting most of the knowledge engineering activities presented in the previous section. In this section some of these tools are described. It will also be indicated how, and under which conditions, other tools that have been described in the literature can be integrated into the framework.

2.7.1

Selecting and Configuring Ontologies

One of the essential and most difficult activities in the GAMES approach is the construction of an application ontology. Therefore, one of the tools being developed within GAMES is a domain ontology editor (QUOTE). This tool acts as a graphical front-end for Ontolingua and allows (i) the construction of ontological theories, (ii) selection of theories form the ontology library and (iii) fine-tuning of theories for a particular application. The functionality of QUOTE includes completeness checking, browsing facilities, graphical presentation of class-subclass hierarchies, visualization of type restrictions on functions and relations, and direct access to the underlying Ontolingua representation. Fig. 2.7 shows a screen dump of QUOTE’s theory editor, when editing a ontology similar to that in INTERNIST (Fig. 2.5). It should be stressed that, although the support of such an editor should not be underestimated, the burden of ontology construction remains largely on the shoulders of the knowledge engineer. The tool is able to detect obvious deficiencies such as syntax errors, and references to undefined


27

Figure 2.7: QUOTE’s theory editor.

objects, but it is the knowledge engineer who, in consultation with the expert, must decide whether the application ontology captures all the relevant distinctions in the domain that are required to perform the task.

2.7.2

Entering Domain Knowledge

Once constructed, the application ontology functions as a template that can be filled in by the domain expert. A second tool developed in GAMES, the domain knowledge editor (QUAKE), takes as input an ontology as specified by QUOTE and exploits this ontology to prompt the expert in domain-specific terminology. Furthermore, the explicit representation of the ontology allows QUAKE to check whether the asserted domain facts violate the restrictions specified in the ontology. For example, when the ontology contains a definition of the manifestation-of relation which states that such a relation can only exist between findings (rash = present) and diseases (acute gvhd), QUAKE will signal a warning when the expert tries to enter that the presence of rash is a manifestation of heart-transplantation.3 QUAKE offers two modes of interaction with the expert: passive and active. In passive mode, the tool support is mainly based on browsing facilities that help the domain expert determine which parts of the domain ontology are not yet fully instantiated. In this mode the initiative is completely 3

Provided that it is known to the system that heart-transplantation is a therapy, and that therapies and diseases are mutually exclusive classes.

28


with the user. In active mode, the initiative lies with the system instead of the expert. The tool interacts with the user by means of a structured dialogue, prompting the user with questions such as “are there any other manifestations of the disease acute-hepatitis?”. This approach is similar to the way MOLE (Eshelman, 1988) and SALT (Marcus & McDermott, 1989) interact with the expert. Fig. 2.8 shows a screen dump of QUAKE. It should be mentioned that neither QUOTE nor QUAKE are specific to the medical field. However, as indicates in Sec. 2.2, their support is dependent on the availability of a library of ontological theories, and the GAMES supplied libraries are specific to medicine.

Figure 2.8: QUAKE when the tool prompts the user for manifestations of GVHD.

Although the application ontology allows QUAKE to have a strongly focused interaction in domain-specific terminology, the nature of the interaction is still quite general. QUAKE’s elicitation strategies are based on the fact that GAMES ontologies are formulated in terms of classes, relations and functions, without further assumptions about their nature. This has the advantage that the tool can be used as an elicitation tool for every ontology defined with QUOTE. However, stronger ontological assumptions often allow the use of more intuitive elicitation techniques. We will illustrate this using concept hierarchies. A concept hierarchy consists of a set of concepts that are related through is-a relations. Because such concept hierarchies are important knowledge structures that can be found in many domains, special knowledge acquisition tools have been devised to elicit such hierarchies. An example of such a tool is the laddering tool ALTO, which is described in (Major & Reichgelt, 1990). ALTO has built-in knowledge about the structure of concept hierarchies and the optimal interviewing strategies to elicit them. However, when the domain knowledge does not have the supported structure, the tool can not be used. A second, related weakness of QUAKE is that its independence of a specific ontology makes it difficult to furnish the tool with algorithms to give feedback to the user about dynamic properties of the entered knowledge. We find here the same trade-off that we saw earlier with respect to problem solvers: stronger ontological assumptions allow better performance at the cost of losing generality. From the discussion above it may be concluded that it is possible to have more focused elicitation when there is a commitment to a particular ontology. In Sec. 2.5.1 it was explained


29

that the goal of GAMES to provide a general methodology makes it impossible to provide a fixed ontology, and therefore to provide a tool box based on such an ontology. However, the application ontology, which is constructed before the domain knowledge is elicited, may be regarded as an explicit model of the ontological commitments in the application domain. Therefore, the application ontology can be used to decide whether a particular special purpose tool is appropriate for (parts of) the knowledge in a domain. For example, in domains where the is-a relation is a major constituent of the application ontology, a tool like ALTO can be used to elicit the corresponding parts of the domain knowledge. In order to fit into the GAMES framework, specialized KA-tools must fulfill a number of specific requirements. Firstly, the tool needs to have an explicit model of the ontological assumptions that it is based on. If such a model is not available it is not possible to decide whether the knowledge that is elicited with the tool fits within the framework of the application ontology. Secondly, the tool must produce output in the language of the epistemological model. Many specialized KA tools that are described in the literature produce executable systems as output, and thereby bypass the distinction between the epistemological model and the computational model that is central in the GAMES approach. This is unacceptable for a number of reasons. Firstly, as we noted in Sec. 2.5.2, the computational adequacy of a particular reasoning technique can be determined only after knowledge acquisition. If the selection of a particular knowledge acquisition tool determines which computational technique will be employed in the target system, we could well end up with systems that are inadequate from a computational point of view. A second, even more important reason as to why the output of the knowledge acquisition tools should be on the epistemological level has to do with the compositional nature of the application ontology. Typically, specialized KA-tools will be used to instantiate only parts of the application ontology. For example, a laddering tool such as ALTO might be used to elicit disease hierarchies while another tool, specialized for the elicitation of causal connections, might be used to elicit the observable manifestations of these diseases. The GAMES approach requires that all the knowledge is collected in a single epistemological model before the computational model in constructed. If this were not the case it would be impossible for the problem solvers in the computational model to communicate. Within the GAMES project several special purpose KA-tools are being developed that fulfill the requirements described above. GAMEES (Bellazzi et al., 1991) is an interactive graphical environment for the construction of causal-probabilistic networks. The underlying ontology is that of influence diagrams: nodes of different types connected through influences relations. There are four types of nodes: (i) decision nodes, (ii) chance nodes, (iii) context nodes and (iv) utility nodes, and each of these node types can be associated with different probability distributions. GAMEES supports a number of sampling algorithms to allow the user to make a dynamic analysis of the consequences of the entered knowledge. However, as was mentioned above, these algorithms are used only to support the knowledge elicitation process. It might well be that the same simulation algorithm that is used during knowledge acquisition is also used in the final KBS, but that decision is taken later, when the computational model is constructed. QCMF (Ironi et al., 1993) is a tool that supports the construction of qualitative models of pathophysiological systems. The underlying ontology is based on the notion of compartments:

30


subsystems that function as stores for substances. The dynamics of the system are modeled through flows, that represent transfers between compartments. The construction of a qualitative model encompasses two distinct activities: specification of the structure and specification of the behavior of the system. QCMF provides a graphical interface that supports the structural-modeling activity. Behavioral modeling involves specification of the variables, their functional relations and the differential equations that govern their behavior. The relevant variables are automatically identified in QCMF by analyzing the structural model. In summary, GAMES provides two kinds of tools for ontology instantiation. QUAKE is intended as a generally applicable tool for instantiating application ontologies constructed with QUOTE. Because the general character of such a tool makes it difficult to use (i) ontology-specific visualization techniques and (ii) dynamic knowledge-analysis techniques, GAMES also allows the use of more ontology-specific KA tools. These tools need to satisfy two conditions: (i) they must have an explicit model of their ontological commitments and (ii) the must produce knowledge-level output. Two example tools that satisfy these requirements are GAMEES and QCMF.

2.7.3

Constructing the Computational Model

The tools described above are intended to support knowledge-level modeling. The output of such tools is a description of the knowledge required to perform a task, but not a knowledge-based system. In Sec. 2.6 we described how the epistemological model can be transformed into a computational model, using ontology-specific translators. However, translation of the ontology is not sufficient to have an executable KBS. The configuration of the problem solvers into an executable system is supported by another tool being developed in GAMES. This tool, M-KAT, is a shell for the blackboard architecture described in Sec. 2.5.2. M-KAT provides the infrastructure to have the problem solvers cooperate: a blackboard that consists of spaces that correspond to the knowledge roles in the STModel, a facility to plug in problem solvers, and a meta-rule interpreter to drive the reasoning process. The tool also contains a syntax-driven editor for the definition of meta rules.

2.8 Use Until now the GAMES approach has been presented as a general framework for medical KBS construction. The tacit assumption has been that the availability of such a framework facilitates the development of these systems. This claim, however, should be supported by empirical evidence. Therefore, within GAMES, KBS’s are being constructed in the following domains:

diagnosis and treatment planning in the domain of acute radiation syndrome management of adverse reactions and drug interactions in the emergency room treatment of shock in intensive care management of neonatal icterus selection of patients for liver transplantation managing complications with bone marrow transplantation diagnosis and management of asthma drug therapy in diabetes diagnosis of nosocomial infections


31

chemotherapy in the palliative treatment of advanced cancer.

These systems are still under development and it is too early to draw final conclusions about the usability of the methodology. Although we cannot as yet provide an empirical validation we nevertheless want to give the reader an impression of how the methodology is used. In the following section some aspects of the GAMES approach are illustrated using fragments from a scenario for the construction of a system in the domain of therapy planning for Acute Myeloid Leukemia (AML) (Quaglini et al., 1994).

2.8.1

A Scenario

The domain AML represents a heterogeneous group of diseases, classified into seven groups (M1 to M7). There are two therapies available for AML: bone marrow transplantation (BMT) and chemotherapy. BMT can have long term negative side effects as a consequence of the chemoradiotherapy used as BMT conditioning regimen, and the high risk of graft-versus-host disease (GVHD). However, a mild form of GVHD might be beneficial for the patient since it affects the leukemia cells. This mild form of GVHD is referred to as graft-versus-leukemia. Usually BMT is accompanied by GVHD prophylaxis in the form of two drugs, Cyclosporine and Metothrexate, to mediate the severity of the GVHD reaction. Thus, the severity of GVHD is a determining factor for the success of BMT. Because of the risks associated with BMT, it will only be carried out when there is a high risk of relapse of the disease. Constructing a task model The treatment of AML involves multiple decisions at different time points. The first decision that needs to be taken is whether to select BMT or chemotherapy. We will elaborate the model only in the case where BMT is selected as the appropriate therapy. Once BMT is selected as a therapy, the proper dosages of Cyclosporine and Metothrexate need to be determined for GVHD prophylaxis. After the BMT the patient needs to be diagnosed to determine the occurrence and the severity of the GVHD reaction. There are two kinds of GVHD: acute GVHD and chronic GVHD. Depending on the outcomes of the GVHD diagnosis there may be an additional treatment for GVHD. The different steps in the process are depicted in Fig. 2.9. Constructing the application ontology As described in section Sec. 2.7.1 the construction of the application ontology is supported by QUOTE. We will refer to the application ontology for the AML domain as AML-ontology. The task model depicted in Fig. 2.9 shows that the task involves both diagnostic and therapy-planning activities. These activities require knowledge about two basic types of relations: the relations between findings and diseases, and the relations between diseases and therapies. The GAMES library provides generic theories about these relations, the theories finding-disease and disease-therapy. Therefore these two theories are included in the AML-ontology. The included theories in turn include other theories, giving rise to the application ontology depicted in Fig. 2.10. To explain the structure of the AML-ontology we will broadly describe the contents of some of its constituent theories. The theory finding-disease contains the definitions that concern the relation between findings and diseases. Therefore, finding-disease needs to know what these are and thus includes the theories finding and disease. The contents of finding-disease are based on the ontology of INTERNIST as depicted in Fig. 2.5. The theory finding defines findings as expressions that consist of observables, operators and values. Such expressions are basically

32


Figure 2.9: A part of the task model of the AML application, shown in QUITE, the task model editor of the GAMES tool box. The circles represent diagnosis STModels and the diamonds represent therapy planning STModels. When they are double-clicked, the corresponding STModel is opened for editing. In the figure, one diagnosis STModel and one therapy planning STModel are opened for editing.

measurements on a particular scale. Therefore finding includes scale-ontology, where concepts such as metric scale, ordinal scale, nominal scale, value-range and scale-transformation are defined. The theory disease-therapy defines that diseases may have therapies as treatments. The applicability of therapy may depend on additional findings and therefore findings is included as well in disease-therapy. The AML ontology so far is completely constructed from generic theories from the library. However, in other cases it may be necessary to fine-tune the ontology for the particular domain.

Role mapping The role mappings are relatively straightforward. We will describe only the mapping for the second instantiation of the STModel in Fig. 2.9, planning a therapy for AML. The hypotheses role is always mapped onto the domain classes that can be the outcomes of the problem-solving activity. Thus, in this case hypotheses are mapped onto therapies, as defined in the therapy theory of the application ontology. The problem-features role is mapped onto the concepts disease and finding, since both the diagnosed disease and additional findings about the patient must be taken into account to decide on the best therapy. Also the data role is mapped onto finding.


33

Figure 2.10: The structure of the application ontology in the AML domain as visualized by QUOTE. The nodes in the

graph are the names of theories, while the arrows represent inclusion relations between the theories. When a theory includes another theory all the definitions in the included are accessible by the includer.

Instantiating the application ontology Once the ontology and the role mappings have been defined, the actual domain knowledge must be acquired. As described in Sec. 2.7.2, this process is guided by the application ontology. We illustrate this for the first step in the task model, where the domain expert uses QUAKE to enter knowledge about the different types of AML (M1 to M7). When the domain expert enters these diseases into QUAKE, the tool automatically prompts for the associated findings. For example, a manifestation of M1 is that the blasts morphology is undifferentiated. Once this finding is entered, the expert is asked to specify its evoking strength. Since the undifferentiatedness of the blasts morphology is a discriminating manifestation, the expert enters that the finding is pathognomonic, when prompted for the evoking strength.4 Selecting meta rules As described in section Sec. 2.5.1 the generic tasks in a task model can be associated with prototypical goals. These goals have associated sets of meta rules that implement appropriate control regimes. Table 2.1 shows the goals associated with the tasks in the task-model of Fig. 2.9. We will focus on the first generic task: the diagnosis of AML. This task is associated with the goal of reaching a sufficient hypothesis, which is defined as “finding the hypothesis from a set of pre-enumerated candidates that best explains the present findings”. This has a number of implications for the control regime. For example, the fact that there is a finite set of hypotheses, M1 to M7, allows the use of deductive techniques for the abductive inference in the STModel. Furthermore, the single fault assumption (only one of M1 to M7 may hold) that is implicit in this 4

The possible values of the evoking strength are also defined in the theory finding-disease. QUAKE informs the user about these.

34


Generic task instance

Prototypical goal

1. 2. 3. 4. 5.

formulate a sufficient hypothesis plan the best therapy determine treatment dosage grading the disease plan the best therapy

Diagnose-AML Plan-AML-therapy Plan-GVHD-prophylaxis Diagnose-GVHD Plan-GVHD-therapy

Table 2.1: Typical goals associated with the tasks in the task model for Acute Myeloid Leukemia treatment.

goal allows the task to terminate when a hypothesis is found that explains all the present findings. Apart from the local control regimes we also need to construct the meta rules that implement the global control regime. Below we show a stylized version of the meta rule that implements the transition of Diagnose-AML to Plan-AML-Therapy (the first two steps in Fig. 2.9). IF ?hypothesis is in hypotheses space AND ?hypothesis is a subclass of AML AND confirmation-status of ?hypothesis is definite THEN invoke task Plan-AML-therapy

The rule states that as soon as there is a hypothesis that has confirmation status “definite”, the system should proceed with therapy planning. Thus, this rule also reflects the single fault assumption mentioned above. Selecting problem solvers This activity will be illustrated using the generic task Plan-AMLTherapy. According to the epistemological model there are two possible outcomes: BMT and chemotherapy. The crucial factor for deciding which of the two is appropriate is the risk of relapse. When the risk of relapse is high the proper treatment is BMT, while for low risk of relapse chemotherapy is preferable. In the case of a medium risk of relapse there is no clear indication which treatment is preferable, thus both hypotheses will be generated. As shown below, this knowledge can be represented easily with production rules and therefore a rule-interpreter is selected to implement the abductive step in Plan-AML-Therapy. IF risk of relapse = high THEN put BMT on hypotheses space

In the case of a medium risk of relapse both competing therapies, BMT and chemotherapy, are added to the hypothesis space. Hence, in this case further analysis is required. The decision between chemotherapy and BMT involves complex trade-offs among uncertain consequences. For example, BMT may lead to GVHD. The likelihood and the severity of the GVHD reaction depend on the prophylaxis. In addition, there is a certain probability that BMT fails to engraft. Finally, both therapies may have early and late morbidities. Thus, the deductive step in Plan-AML-Therapy involves reasoning with uncertainty. As described in Sec. 2.5.2, GAMES provides a specialized problem solver for the evaluation of causal-probabilistic networks and influence diagrams. This problem solver is well suited for the type of reasoning required here. The applicability of the reasoner also depends on the availability


35

of the probabilities of course. In the AML domain these probabilities are available from the literature. Translating the knowledge Once a problem solver is selected, the appropriate parts of epistemological model must be translated into the private representation of that problem solver. As described in Sec. 2.6.2, this translation consists of a two step process. First, the expressions are mapped onto a representational meta model of the selected problem solver. This mapping is specified manually by the knowledge engineer. For example, for the probabilistic network interpreter that was selected in the previous paragraph, the knowledge-level expression: probability(causes(bmt, chronic-gvhd), 0.22)

would be mapped onto an expression such as: p(chronic-gvhd / bmt) = 0.22

Using a problem-solver specific translation, this expression is then further translated into the private representations of the problem solver.

2.9 Discussion In this chapter we have presented the GAMES approach for the construction of medical knowledgebased systems. We have presented the assumptions upon which that the approach is based, the view of what constitutes a good knowledge-based system, the methods to construct such a system, and the tools that support these methods. In the previous section we briefly described a number of experiments that are currently being performed to validate the methodology. In this section the GAMES approach is compared with some other approaches described in the literature. Finally, we will return to some of the issues raised in the introduction.

2.9.1

Relation to Other Work

Knowledge sharing effort The work being done as part of the knowledge sharing effort (KSE) has a large impact on GAMES. Neches et al. (1991) emphasize, as we do, the importance of reusing domain knowledge. The goal of the KSE project is to develop technology that enables future KBS to share and reuse knowledge bases. In order to achieve this goal two requirements have to be met: (i) the knowledge bases must be designed in such a way that they allow reuse and (ii) the KBS must have an architecture that is able to exploit the reusable knowledge bases. The first of these requirements is realized through Ontolingua, a language for defining reusable ontologies independent of the underlying knowledge representation language. As outlined in Sec. 2.5.1, GAMES has adopted Ontolingua as the epistemological modeling language for the ontology part. Neches et al. (1991) describe a range of architectures that could be used to realize the second requirement. The blackboard architecture that is used in the GAMES computational model is one of these. Thus, it is to be expected that systems constructed using GAMES will fit quite well with the outcomes of the KSE project. There are also some differences that arise from the different goals of the two projects. Whereas the KSE project is mainly interested in the design principles for future knowledge bases and systems that exploit these knowledge bases, GAMES also tackles the problem known as the “knowledge

36


acquisition bottleneck”: how to model the knowledge of an expert in a formal representation that can be interpreted by computers. In Sec. 2.7 we described how the availability of an explicit representation of the ontology makes it possible to select KA-tools that elicit knowledge in a form understandable for domain experts. One of the challenging research questions in GAMES is whether ontologies that are used to share knowledge bases can also be used to facilitate communication between computers (in the form of KA-tools) and domain experts.

´ E ´ (Musen, 1989b) is a system that aids the construction of KBS applying the “episodic PROTEG skeletal-plan refinement” problem-solving method. It embodies a view of knowledge acquisition that is similar to GAMES. In PROTE´ GE´ two phases are discerned in the KA-process. In the “model building phase” the knowledge engineer associates roles in the problem-solving method with domain specific classes. Based on this association PROTE´ GE´ generates a knowledge acquisition tool that, in the “model extension phase”, interacts with the domain expert in domain specific terminology to build the actual knowledge base. The two phases in PROTE´ GE´ are similar to the role-mapping and the ontology-instantiation activities as shown in Fig. 2.4. As in GAMES, the major motivation for separating the two stages has to do with the allocation of duties. While model building is considered to be a difficult process that requires the expertise of both knowledge engineer and domain expert, model extension is regarded as a much more constrained task that the domain expert can carry out without further assistance. The differences between the PROTE´ GE´ and GAMES approaches are mainly due to differences in scope. While GAMES attempts to be a general methodology for the construction of medical KBS, the PROTE´ GE´ approach is limited to the construction of systems that perform skeletal plan refinement. This commitment to a particular problem-solving method has as a consequence that in PROTE´ GE´ the ontology can only be defined in terms of the knowledge roles in skeletal plan refinement. Thus, the PROTE´ GE´ user can specify what the planning-entities are in the domain, what the components of these entities are, what their attributes are and what the properties of these attributes are. For example, in HTN, an application constructed with PROTE´ GE´ , the planning entities are protocols that have as components tests, tablets and wait-periods. However, many other aspects of protocols that are not relevant for skeletal plan refinement, but that might be relevant for other tasks, cannot be represented. This aspect of ´ GE´ hinders the reuse of the domain ontologies for other tasks than the one embodied in PROTE ´ GE´ . PROTE ´ GE´ -II PROTE

(Puerta et al., 1992), the successor of PROTE´ GE´ , is less method dependent. In this system, knowledge engineers are allowed to define new problem-solving methods, in addition to skeletal plan refinement. Although this system was initially presented as a generalization of PROTE´ GE´ , it is currently being extended to a general framework that contains a multitude of tools, among which an ontology editor, MAÎTRE (Gennari, 1993), and a KA tool generator, DASH (Eriksson et al., 1994), which are comparable to QUOTE and QUAKE. Although there are many differences in the details, it seems fair to conclude that, with respect to the construction of the epistemological model, GAMES and the PROTE´ GE´ -II framework are moving into the same direction. Unlike GAMES, PROTE´ GE´ -II does not explicitly distinguish a computational model. As argued in Sec. 2.5.2, the GAMES knowledge engineer has to make a number of informed decisions about which knowledge representations and which reasoning techniques must be employed for which steps in the reasoning process. In both PROTE´ GE´ and PROTE´ GE´ -II the knowledge level model is directly compiled into CLIPS code.


37

KADS and CommonKADS A third major influence on the development of GAMES is the KADS methodology (Schreiber et al., 1993). As GAMES, KADS attempts to provide a coherent framework that covers all aspects of KBS development and maintenance. However, unlike GAMES, KADS is not committed to a particular application area. Therefore, it is to expected that GAMES can be expressed in KADS terminology, adding detail specific for medical KBS development. KADS divides the development process into a series of modeling activities. Each of the resulting models covers a different aspect of the system under construction. The most wellknown of these models is the model of expertise, which is a knowledge level representation of the knowledge required to perform a task. The model of expertise is in many respects similar to the epistemological model in GAMES. It distinguishes four types of knowledge that are organized as layers: (i) strategic knowledge, (ii) task knowledge, (iii) inference knowledge and (iv) domain knowledge. The task layer and the strategic layer together represent the control knowledge. The former consists of predefined control regimes for prototypical tasks, and the latter dynamically controls the invocation of these tasks. These two layers can be mapped onto the meta rules for the prototypical tasks and the meta rules that implement the global control regime respectively. The KADS inference layer is the epistemological equivalent of the GAMES inference model, although it is based on another classification of inferences (see Sec. 2.5.1). The CommonKADS framework (Wielinga et al., 1993), the successor of KADS, makes a distinction between domain models and meta-domain models, called domain schemata which are of a similar nature as ontologies. The GAMES computational model has the CommonKADS design model as its counterpart. However, unlike GAMES, CommonKADS does not commit itself to a particular computational architecture, thereby providing more generality at the cost of less support. Other related work Besides the ones mentioned above, many other approaches have influenced the work on GAMES. For example, one of the motivations for the SPARK/BURN/FIREFIGHTER framework (Klinker et al., 1991; Yost et al., 1994) was to make method-specific knowledge acquisitions tools such as MOLE more widely applicable without losing the strong KA support that these tools offer. In this approach, and also in the DIDS approach (Runkel & Birmingham, 1993), this is realized by separating the KA process into two steps: mechanism configuration and knowledge elicitation. These approaches are similar to GAMES in the sense that they attempt to reconcile the strong guidance of abstract application models for knowledge acquisition with wide applicability of domain and task neutral KA systems. The difference between these approaches and GAMES lies mainly in the nature of the abstract models: in GAMES, these are abstract models of the domain knowledge (the application ontology), in SBF and DIDS these are abstract models of the method. In this respect, the GAMES approach is similar to the Componential Framework (Steels, 1993), which also distinguishes ontologies and domain models.

2.9.2

Conclusions

In Sec. 2.1 and Sec. 2.2 we formulated a number of requirements for second generation medical expert systems. In particular, we mentioned (i) the need for a cost-effective development methodology, (ii) the need for reliable and understandable output, (iii) the requirement that medical KBS can be maintained by domain experts and (iv) the requirement that KBS can handle different types of knowledge in an appropriate way. In the course of this chapter it has been argued how systems developed according to the GAMES approach fulfill these requirements. We summarize some of

38


these arguments and conclude with an elaboration of some of the key issues of the approach. Cost-effective KBS development One of the requirement was that KBS need to be developed in a more cost-effective way. This requirement can be met through the use of reusable components. Therefore, GAMES provides support for the reuse of task-models, domain ontologies and problem solvers. Interpretability of KBS output As described in Sec. 2.5.2, the output of a GAMES KBS consists of the contents of the blackboard(s) after the system has found a solution. Since the expressions on the blackboard are formulated in a knowledge-level language it is expected that medical professionals will be able to interpret the solution. Also, the availability of knowledge-level traces will facilitate the task of a reconstructive explanation facility of the kind described by Wick and Thompson (1992). KBS maintenance by domain expert Because of the dynamic nature of medical knowledge, maintenance of medical KBS should preferably be done by medical experts. In GAMES this is facilitated by separating the activities of application ontology construction and ontology instantiation. After the application ontology has been constructed, the instantiation and maintenance can be done by the domain expert in familiar terminology. Only in the cases of major revisions of medical insights, when the application ontology must be updated, a knowledge engineer is required. Representation of and reasoning with different types of knowledge The GAMES computational architecture allows different reasoning techniques and representation formalisms. Selection of a particular formalism is based on the principle that problem solvers must be epistemologically adequate for the given (sub-)problem. A central topic in the approach is the application ontology. It is used both for organizing the elicitation of domain knowledge and for choosing appropriate reasoning techniques. Once the application ontology is available the GAMES approach is able to provide support for KBS development in the same way as PROTE´ GE´ , MOLE and SALT. However, constructing the application ontology is a complicated activity. We are currently developing a library of “generic” ontologies that are related by means of inclusion and exclusion relations. However, how to carve up the medical world into modules in a way that maximizes their reusability remains an open issue, as is the question whether the inclusion and exclusion relations are sufficient as organizing principles. Other cornerstones of GAMES are the principles that there should be a structural correspondence between the epistemological model and the computational model and that existing problem solvers should be used when possible. These principles are realized by means of a computational architecture that allows the use of multiple problem solvers, which are selected in such a way that they can appropriately represent the knowledge that is needed to perform the part of the reasoning process to which they are assigned. An aspect of KBS development that has not yet received sufficient attention in GAMES is the integration of these systems in the medical environment. For KBS to gain acceptance, the systems must fit in the organizational structure of the clinical environment (Klinker et al., 1993) and they must be integrated with software that is already being used in that environment, such as patient databases (van Bemmel, 1993). With respect to the first requirement, we plan to use results from the CommonKADS framework, in the context of which a theory and tools for organization


39

modeling have been developed. The second requirement, integration with existing software, is facilitated by the availability of an explicit application ontology. In principle, the integration of a KBS with a patient database can be realized in a similar fashion as the integration of problem solvers in the computational model. However, the feasibility of this approach remains a research issue. Finally, validation remains a major research issue for the approach. As already indicated in Sec. 2.8, a number of experiments are carried out to test the validity of the claims and assumptions. One of these experiments is described in detail in chapter 8 of this thesis. However, a thorough evaluation not only requires that we show that the methodology can be used to build KBS, it also requires the assessment of alternative design decisions within the methodology and comparison with other approaches. Viewed this way, proper evaluation requires an enormous amount of effort. Fortunately, as the GAMES approach shares many aspects with other methodologies, the validation experiments that have been performed in the context of these methodologies also provide feedback about the validity of GAMES. Therefore, the project concentrates on aspects that are particular for the GAMES approach. Some of the work presented in this thesis also validates aspects of the GAMES approach. In particular, the ideas of exploiting a library of medical ontologies to facilitate the knowledge engineering process (chapter 5 and 6) and the ontology-based integration of problem solvers (chapter 7) are addressed.

40


Chapter 3

Model-Based Knowledge Acquisition Tools One important role for ontologies that is addressed in this thesis concerns the ways in which they can be used in knowledge acquisition. The chapter identifies a number of ways in which knowledge acquisition can be supported by tools, and describes how a number of well known knowledge acquisition tools have provided these types of support. The chapter is an extended version of the first part of a paper presented at the European Knowledge Acquisition Workshop 1994, which was co-authored by Guus Schreiber. The reference is: G. van Heijst and A. Th. Schreiber (1994). CUE: Ontology-based knowledge Acquisition. In Steels, L., Van de Velde, W., & Schreiber, A. T., editors, Proceedings European Knowledge Acquisition Workshop EKAW’94, Heidelberg/Berlin. Springer Verlag.

3.1 Introduction One of the recurring themes in the recent knowledge acquisition literature is that knowledge acquisition is a modeling activity, as opposed to the older view of knowledge acquisition as mining. There are at least two different interpretations of this modeling process. In the first interpretation, which we will call “KA as modeling”, modeling is viewed as a bottom-up constructive process where a structure is imposed on already elicited knowledge (e.g. Ford et al., 1993). In the second interpretation, called “model-based KA”, modeling is viewed as a top-down process where an abstract model is selected or constructed which is then instantiated with application-specific knowledge (e.g. Breuker & Wielinga, 1989). Fig. 3.1 shows the alternative interpretations of the modeling view. One could argue that all forms of knowledge acquisition use some abstract model of the domain knowledge, although this model might be weak. Therefore, it is better to view the two interpretations in Fig. 3.1 as the extremes of a continuum which ranges from weak model support to strong model support. To gain a better understanding in the possible types of models and the way in which they can be used in the knowledge acquisition process, this chapter makes a comparison between a number of well-known knowledge acquisition tools. To identify dimensions on which the tools can be compared, Sec. 3.2 presents a general framework for describing the knowledge acquisition process according to the model-based-KA paradigm. Sec. 3.3 describes how this paradigm evolved. Sec. 3.4 then describes how each of the subtasks in the paradigm can be supported by tools and in Sec. 3.5 a number of well known tools are described and compared. Because we are 41

42


KA as Modeling

Model-Based KA 1

1

Select / Construct skeletal model

Elicit knowledge

2

2

Impose structure on the elicited knowledge

Instantiate skeletal model

Figure 3.1: The two alternative interpretations of the modeling process in knowledge acquisition.

mainly interested in the role of the abstract models, the comparison is biased towards tools that are closer to the model-based-KA edge of the continuum.

3.2 A Framework for Comparing Tools In order to compare existing model-based KA tools, we need a general framework in which they can be described. This section proposes such a framework which distinguishes four main activities in model-based knowledge acquisition: (i) skeletal model construction, (ii) model instantiation, (iii) model compilation and (iv) model refinement. The framework is based on an analysis of the types of support provided by existing knowledge acquisition tools. The first of these subtasks, skeletal model construction, involves the creation or selection of an abstract specification of the knowledge that is required to perform a particular task in some domain. Such skeletal models may come in different flavors, and they vary in the amount of detail that they specify. For example, generic tasks (Chandrasekaran, 1987) specify both the method that is used to perform a task and the way that domain knowledge must be represented. In contrast, KADS interpretation models (Wielinga et al., 1992) specify the method (using control knowledge and inference structures), but they do not specify how the domain knowledge must be represented. In the PROTE´ GE´ approach (Musen, 1989a), both the method and the domain-specific classes are specified in the skeletal model. Here, only the instances of the classes and their relations are unspecified. Model instantiation, the second activity in knowledge acquisition, involves “filling” a skeletal model with domain knowledge to generate a complete knowledge base. Many well-known knowl-

Chapter 3: Model-Based Knowledge Acquisition Tools

43

edge elicitation tools concentrate on this activity in the knowledge acquisition process (Boose, 1985; Shaw & Gaines, 1987; Marcus, 1988; Musen et al., 1988). For example, SALT concentrates on the elicitation of knowledge that is required for the Propose-and-Revise skeletal model. In the model instantiation activity the elicited knowledge is often, but not always, represented in a non-executable language. In the model compilation activity, the instantiated skeletal model is transformed into an executable knowledge base. This subtask is only required when the instantiated model is formulated in a non-executable language. The fourth activity in model-based knowledge acquisition is refinement of the executable model. In this activity, the dynamic characteristics of the KBS are validated using a number of selected test cases. When the KBS does not solve the test cases correctly, or produces invalid explanations, this provides feedback about erroneous or missing knowledge in the executable model. In cases where the executable model and the instantiated model are different, this activity requires “uncompilation”: the parts of the instantiated model that correspond to the erroneous parts of the executable model must be identified. 3 compile instantiated model

2 instantiate skeletal model

1 construct skeletal model

skeletal model

instantiated skeletal model

executable model

4 refine instantiated model Figure 3.2: The four basic activities in model-based knowledge acquisition

Fig. 3.2 shows the four basic activities in model-based knowledge acquisition. It should be emphasized that this task breakdown does not imply that the four activities are necessarily performed sequentially. As argued by Shadbolt and Wielinga (1990), the KA process is typically a cyclic process. The dotted arrow in Fig. 3.2 represents a fifth activity in the paradigm: the use of the instantiated model to provide feedback about the validity of the skeletal model. Negative feedback can be used for identifying parts of the skeletal model that need to be adapted while positive feedback could for example be used for deciding to put a model — or parts of a model — in a library. Although, this activity is obviously important, there are at present no tools that support this activity.1 Therefore, it was decided to keep this activity out of the framework. The four activities require different kinds of expertise and different types of support tools. Whereas the model construction activity is inherently difficult and requires the expertise of a knowledge engineer, the knowledge instantiation activity can often be performed by domain experts, after some initial explanation of representation and tool usage. The compilation activity requires the expertise of a computer programmer, but in many existing KA tools this activity is fully automated. The knowledge refinement activity can be performed by domain experts, provided that they understand the control regime of the inference engine (Davis, 1979). 1

It could be argued that the KEW system is an exception. However, in chapter 4 it will be explained that this is not really the case.

44


3.3 Evolution of the Paradigm This section gives a historical overview of the developments in automated knowledge acquisition, illustrated with references to some well known tools that have been described in the literature. The overview is mainly intended to sketch trends in the history of knowledge acquisition tools. To emphasize these trends, the presentation is not completely chronological.

3.3.1

Ancient Times: Rule Editors

Knowledge acquisition tools of the first generation were derived from existing expert systems. For example, KAS (Duda et al., 1979), EMYCIN (van Melle, 1979) and EXPERT (Weiss & Kulikowski, 1979) were derived from PROSPECTOR, MYCIN and CASNET respectively. Tools of this era assumed that the domain expert or the knowledge engineer was able to build an initial knowledge base without extensive (tool) assistance. Only after this initial knowledge base was available could the tools support the KA process by providing feedback about the origin of erroneous solutions. The power of these tools was solely based on the explanation facilities of their inference engines, which facilitated the job of locating missing or incorrect parts of the knowledge base. Thus, of the activities described in Sec. 3.2, only model refinement was extensively supported by these tools. They barely supported model construction, while the support for model instantiation was limited to symbol-level facilities such as rule editors.2 Tools of this generation could not provide much support for model instantiation because of their weak skeletal models. For example, EMYCIN’s skeletal model only specified that the reasoning method is backward chaining and that the domain knowledge is organized in a context tree, a simple hierarchy of domain entities. Because in these early systems the instantiated model was formulated in terms of directly executable representation formalisms no compilation activity was required. A notable exception with respect to the lack of support for model instantiation was TEREISIAS (Davis, 1979). Like other tools of its generation, TEREISIAS did not have an explicit model of the types of knowledge that had to be elicited, but during the knowledge elicitation process TEREISIAS used already elicited knowledge to formulate expectations about what other knowledge might be needed. These expectations, which were represented as rule models, served a similar purpose as explicit skeletal models. However, because the rule models were not available at the beginning of the model instantiation phase, they could only provide support after a significant amount of knowledge had already been elicited. Another exception is ROGET (Bennett, 1985). This system was especially designed to support the early phases of knowledge engineering. The system helps the domain expert to design the conceptual structure of a target consultation system, by interacting with the expert. ROGET is able to provide guidance because it has access to a library of conceptual structures of existing knowledge-based systems. These conceptual structures can be considered as kinds of skeletal models. ROGET was able to translate the constructed conceptual models into EMYCIN context trees. ROGET is very different from the other first-generation tools and could best be viewed as an early predecessor of the model construction tools of third-generation workbenches. 2

Some tools of this generation used simple template-based natural language front-ends to hide the most deterrent details of the underlying representation formalisms.


3.3.2

45

Medieval Times: Task- and Method-Specific Architectures

Whereas the first generation of tools merely supported model refinement, the second generation of knowledge acquisition tools also supported the model instantiation activity. This higher level of support for model instantiation was a result of the fact that these tools acquired knowledge in a form that was more intuitive to the domain experts than the production rules in the earlier tools. Put differently, tools of this generation were capable of knowledge-level communication with domain experts. The type of support provided by second-generation tools can be classified into three categories. A first reason why tools of this generation could better support model instantiation than their ancestors was because of their more restrictive skeletal models. For example, tools as MOLE (Eshelman, 1988) and SALT (Marcus & McDermott, 1989) used knowledge of problemsolving methods such as Cover-and-Differentiate and Propose-and-Revise to engage in a structured dialogue with the domain expert. Because these tools knew what kind of knowledge was required for these methods, they could strongly focus the knowledge elicitation dialogue. Another system in this category was OPAL (Musen et al., 1988). OPAL did not only make assumptions about the method that the KBS was going to perform, but also about the domain that the system would reason about: oncology. Because of this, OPAL was able to communicate with domain experts in domain-specific terminology. A second way in which tools of this era bridged the gaps between the ways in which humans process knowledge and the ways knowledge is represented in AI formalisms was the use of graphical user-interfaces. For instance, the graphical user-interface of OPAL allowed the oncologists to enter knowledge in forms that resembled the paper forms that they were used to working with. The tool then automatically translated these forms into an internal representation which was subsequently compiled into production rules. A third group of tools of this generation based their support on interviewing techniques which originated from psychology. Typical examples of this category are tools such as ETS (Boose, 1985) and its successor AQUINAS (Boose & Bradshaw, 1988), which embody the repertory grid technique and ALTO (Major & Reichgelt, 1990), which is based on the laddering technique. With respect to the activities described in Sec. 3.2, tools of this generation provided stronger support for the model instantiation activity than their predecessors because they used stronger skeletal models. However, these skeletal models were hardwired in the tools: it was not possible to edit skeletal models or construct new ones. Thus, the model construction activity was not supported. Some of these tools acquired the knowledge in a format that was not directly executable. For these tools, an explicit compilation activity was required. This compilation was usually automatic and could not be controlled by the knowledge engineer. Although some of the tools of this generation had a refinement facility similar to those of the earlier tools, the emphasis was on getting the knowledge model right the first time.

3.3.3

Modern Times: Integrated KA Workbenches

Only recently tools have been built that support skeletal model construction. In contrast with the systems of the first and the second generation, which are often presented as stand-alone programs, these tools are usually embedded in larger knowledge engineering environments, called KA workbenches. One of the first systems that supported model construction was PROTE´ GE´ (Musen, 1989a). This tool uses an abstract model of a problem-solving method, and allows the knowledge

46


engineer to associate the knowledge roles of the method with domain-specific labels. Based on these associations, PROTE´ GE´ can be used to generate model instantiation tools such as OPAL, which interact with experts in domain-specific terminology. A limitation of PROTE´ GE´ is that it is based on one problem-solving method: episodic skeletal-plan refinement. Other systems of this generation allow the construction of arbitrary skeletal models from sets of primitive components. Most of the existing KA workbenches concentrate on the earlier activities of the modelbased knowledge acquisition paradigm. Typically, skeletal-model construction is supported by libraries of model components which can be selected and adapted for an application by means of specialized editors. The model instantiation activity is supported by tools that exploit the explicitly represented skeletal model to focus the elicitation activity. In most workbenches, the instantiated skeletal model is formulated in a non-executable language, so compilation is required. This compilation may or may not be automatically. In most of the workbenches there is little emphasis on the knowledge refinement activity.

3.4 Types of Tool Support In Sec. 3.2 a framework was presented for comparing model-based knowledge acquisition tools which distinguishes four activities. This section identifies for each of these activities ways in which they can be supported or automated by knowledge acquisition tools. Sec. 3.5 will use the results of this analysis to make a classification of a number of well-known knowledge acquisition tools.

3.4.1

Supporting Skeletal-Model Construction

As mentioned, different types of skeletal models have been proposed in the literature. Here we will adopt the GAMES view — which is also the view in CommonKADS and PROTE´ GE´ -II — that skeletal models consist of a task model and an application ontology. Together, these specify what kind of application knowledge is required to solve problems in the application domain. The most obvious form of support for the construction of skeletal models is by means of (graphical) editing facilities. Dependent on the expressiveness of the formalism in which the models are expressed, such editors can perform several types of consistency checking and completeness checking. A second type of support is by providing libraries of primitive components and typical configurations of those. Usually, these two types of support are combined: libraries provide generic configurations that can be fine-tuned for particular applications using specialized editors. The third, most ambitious type of support for skeletal model construction is process support. This type of support requires a prescriptive theory of how skeletal models should be constructed from primitive components. For task models, such a theory is currently under development (e.g. Aben, 1995). However, for application ontologies such a theory is not yet available. Chapter 5 will describe principles that can be viewed as a first sketch of such a theory.

3.4.2

Supporting Model Instantiation

In general, stronger skeletal models allow better support for model instantiation because it can more easily be determined which knowledge is valid and required for problem solving. There are five ways in which model instantiation can be supported: (i) checking if the entered knowledge is consistent with the skeletal model,(ii) checking whether the entered knowledge is all the knowledge


47

that is required according to the skeletal model, (iii) using domain specific terminology, (iv) using intuitive visualization techniques, and (v) use of a structured dialogue. The simplest form of support, consistency checking (e.g. syntax checking, type checking), can also be found in conventional programming tools such as syntax-driven editors. However, the other types of support are dependent on the stronger skeletal models used in knowledge engineering. For example, there are two types of completeness checking: checking whether for all the knowledge types knowledge has been elicited and checking whether all the knowledge of a particular type has been elicited. To provide this support, the skeletal model should define which knowledge types there are in the domain and what the constraints are on the quantity of the knowledge pieces for each of these knowledge types. The use of domain-specific terminology requires that this terminology is defined. Also, specialized visualization techniques are based on strong assumptions about what is to be visualized. For example, when it is assumed that the knowledge in the domain consists of objects and values of these objects on a number of dimensions, it can be decided to use grids for visualizing the knowledge. Dialogue structuring requires — amongst other things — the ability to find out what knowledge still needs to be elicited and is therefore is dependent on the capacity to perform completeness checking, which in turn requires a strong skeletal model.

3.4.3

Supporting Model Compilation

The model compilation activity is only required when the knowledge is elicited using a nonexecutable language. The advantage of such knowledge-level languages is that they facilitate model-instantiation because they are easier to understand for non-programmers. Therefore, it is to be expected that for tools that give better support for model instantiation the compilation activity is more complex. In some tools, the compilation activity is completely automated. Once the skeletal model is instantiated, the tool is able to generate an executable knowledge base without further assistance. This type of support for compilation may seem the most powerful type, but there is a serious drawback. Compilation becomes more difficult when the source language is more expressive. With current compilation technology, automatically compilation would in many cases yield computationally inefficient executable models. Alternatively, tools may engage in an interactive compilation dialogue. Here the tool attempts to compile the instantiated model automatically, but whenever the compiler does not have sufficient information to select an appropriate representation, it may ask for additional information to resolve the ambiguities. In a third group of tools compilation is considered as an activity to be performed by the knowledge engineer. Here, the emphasis is on supporting the knowledge engineer instead of on replacing the knowledge engineer. Manual compilation can be supported by providing libraries of reusable compilation procedures from which the knowledge engineer can select the most appropriate one.

3.4.4

Supporting Model Refinement

Model refinement, which takes place in the context of a running system, may be supported in four ways. Firstly, the tool may provide a tracing facility that shows the reasoning steps that lead to the solution that the system arrived at. This type of support is also provided by tools that support software engineering. Secondly, tools may be able to inspect such traces to answer why and how

48


questions. For such a facility, the tool must have a persistent representation of the trace. The explanations of first-generation tools were for example based on such persistent traces. A third type of support is the ability to answer why not and what if questions. Such a facility requires that the tool is capable of hypothetical reasoning. Finally, tools may be able to locate the missing or incorrect knowledge pieces in the knowledge base that are responsible for the erroneous solution. That is, they are capable of blame assignment.

3.5 Knowledge Acquisition Tools In this section, a number of existing knowledge acquisition tools are analyzed with respect to the types of support that were identified in the previous section. The tools that are described were selected because they are prototypical representatives of different classes of tools. The results of the analysis are shown in Fig. 3.3, Fig. 3.4 and Fig. 3.5. For some tools, describing the functionality in terms of the four subtasks of the model-based KA paradigm required some reinterpretation. However, in order to be able to compare different tools it is necessary to have a common framework, and we believe that the framework presented in Sec. 3.2 is sufficiently general to do justice to the particularities of the different tools. The tools are described in a roughly chronological order. Emycin EMYCIN (van Melle, 1979), a shell based on the domain-independent core of MYCIN, is intended as a tool for the development of consultation programs. As already mentioned in Sec. 3.3, EMYCIN has a fixed skeletal model based on the backward-chaining method and the context tree. Because this skeletal model is under-constrained, the tool can provide only limited support for model instantiation. The knowledge is entered into the system using the “Abbreviated Rule Language” a user-friendly interface on top of the production rules that EMYCIN uses for representing knowledge. A rule that is entered is checked for syntactic validity, and to a limited extent for “semantic” validity: EMYCIN checks whether an entered rule does not directly contradict another rule, and whether the entered rule is subsumed by another rule. Because the entered knowledge is directly mapped onto production rules there is no need for compilation. To support model refinement, EMYCIN has tracing facilities and it is able to answer why and how questions. Kas KAS (Duda et al., 1979), which is derived from PROSPECTOR, is very similar to EMYCIN but has richer facilities for supporting model instantiation. For example, the tool protects against errors such as disconnecting parts of the semantic network that KAS uses for knowledge representation. Further, the tool keeps a record of unfinished elicitation jobs, thereby performing a kind of completeness checking. Expert Compared to the previous tools, EXPERT (Weiss & Kulikowski, 1979) makes stronger assumptions about the kinds of knowledge that must be elicited: findings and hypotheses. It distinguishes three kinds of rules: finding-to-finding rules, hypothesis-to-hypothesis rules and findingto-hypothesis rules. However, although EXPERT has a stronger skeletal model than EMYCIN and KAS, the tool does not use this model for supporting model instantiation. In EXPERT, the rules need to be entered using text editors. After syntax checking, these rules are then automatically compiled into an efficient internal representation. For refinement, EXPERT provides similar facilities as EMYCIN and KAS.


49

Mole MOLE (Eshelman, 1988) is a knowledge acquisition tool for systems that use the Coverand-Differentiate problem-solving method. The (built-in) skeletal model of MOLE is derived from the knowledge requirements for this method. MOLE uses its skeletal model to engage in a focused dialogue with the domain expert. During the model instantiation phase, MOLE uses static analysis techniques to decide on the consistency and completeness of the entered knowledge. Internally, the entered knowledge is represented in the form of production rules, so compilation is not needed. MOLE has advanced facilities for supporting the model-refinement activity. If MOLE makes an incorrect diagnosis in the model refinement phase, the tool tries to locate the source of the error and recommends possible remedies. Thus, in addition to tracing and explanation, this tool is also capable of blame assignment. Salt SALT (Marcus & McDermott, 1989) can be used to develop expert systems that use the Propose-and-Revise problem-solving strategy. The tool has built-in expectations about the knowledge requirements of this method to structure the knowledge acquisition dialogue. For Proposeand-Revise, there are three types of knowledge: propose knowledge, constraint knowledge and knowledge for fixing constraint violations. SALT is capable of consistency checking and completeness checking. Initially, the entered knowledge is represented in a dependency network which is then automatically compiled into production rules. To support knowledge refinement, SALT is able to answer how, why, what-if and why-not questions. Opal As already indicated in Sec. 3.3, the skeletal model of OPAL (Musen et al., 1988) is based on the method that the knowledge-based system will use (episodic skeletal-plan refinement) and on the domain about which it will reason (oncology). Because of this strong model, the tool is able to perform extensive consistency and completeness checks, to communicate with experts in domain-specific terminology, and to use specialized visualization techniques. OPAL compiles the entered knowledge automatically into production rules. The tool has no knowledge refinement facilities. Aquinas AQUINAS (Boose & Bradshaw, 1988) is a system for building classification expert systems. Like its predecessor, ETS (Boose, 1985), the tool is centered around the repertory grid technique, which is a psychological technique for eliciting concepts and “personal constructs”. These personal constructs are dimensions on which the concepts may have values. The elicited concepts and distinctions together form a skeletal model that is used to direct the further KA process, which consists of assigning values to the concepts on the dimensions. In the knowledge instantiation phase, the concepts are organized in hierarchies and assigned values on the dimensions. This process is supported by graphical visualization and by dialogue structuring. The tool is able to perform simple completeness checks. The elicited knowledge can be compiled automatically into various expert system shells (e.g. KEE, EMYCIN, OPS5 etc.). The facilities for supporting knowledge refinement are those of the shells into which the knowledge is compiled. Alto ALTO (Major & Reichgelt, 1990) is a tool that implements the laddered-grid knowledgeelicitation technique, intended for hierarchy elicitation. The tool expects that knowledge can be modeled in terms of tree structures. Based on this assumption, the tool visualizes the elicited knowledge in terms of directed graphs, thereby providing the user with an intuitive overview of the elicited knowledge. During model instantiation, the tool performs consistency checking

50


and some forms of completeness checking. For example, it insists that sibling concepts have at least one discriminating attribute. The elicited knowledge is semi-automatically translated into CommonSLOOP, an object-oriented representation system. During compilation, ALTO asks for additional knowledge for resolving ambiguities. ALTO has no facilities for supporting knowledge refinement. Protégé PROTE´ GE´ (Musen, 1989b), which was described briefly in Sec. 3.3, was probably the first tool that recognized skeletal model construction as a distinct activity. The tool has a fixed task model, but allows the knowledge engineer to specify the ontology. This specification is then used to generate tools similar to OPAL, but for different application domains.

Spark-Burn-Firefighter Another tool that supports model construction is SPARK, which belongs to the SPARK-BURN-FIREFIGHTER (SBF) environment (Klinker et al., 1991). SPARK allows the user to indicate which of the tasks in a particular industrial environment could be performed by a KBS. To do this, the tool employs a general model of the tasks that are performed in some domain. Based on this task analysis and a theory of what methods are used in particular organizational environments, SPARK generates a specification of the method of the KBS, in the form of a configuration of mechanisms. This mechanism configuration is then used by BURN, the model instantiation tool of the SBF workbench, to elicit the domain knowledge that is required by the method. For each mechanism in the library, BURN has a specific knowledge acquisition module. It is not entirely clear from the literature which kinds of support are provided by BURN. As explained in (Yost et al., 1994), the knowledge refinement tool FIREFIGHTER was never implemented.

Keats The KEATS system (Motta et al., 1990) consists of a number of tools that support the various activities in model-based KA. The skeletal models in KEATS are coding sheets, templates that define the structure of the skeletal model. In Motta et al. (1990) both task-oriented coding schemes and domain-oriented coding schemes are mentioned. However, it is not clear from the literature whether the system supports the development of such coding schemes. The coding schemes can be filled-in to arrive at an instantiated skeletal model. The instantiated model is then used to develop an executable knowledge base. For the executable model, KEATS uses a hybrid representation language for which it provides a forward- and backward-chaining rule interpreter, a non-monotonic truth maintenance system, a frame-based representation language and a constraint-based language. KEATS has a number of facilities for supporting model refinement. For example, the tool has graphical visualization tools for inspecting persistent traces of problemsolving sessions at different levels of abstraction.

Shelley SHELLEY (Anjewierden et al., 1992b) is a workbench that provides tool support for the KADS methodology. The system supports model construction by providing an inference structure editor that has access to a library of interpretation models. Model instantiation is supported by a number of facilities (e.g. a concept editor, a card sort tool, a protocol editor etc.). SHELLEY concentrates on the earlier activities of the knowledge acquisition process, and it does not produce executable knowledge bases. Therefore, model compilation and model refinement are not supported.


51

Kadstool KADSTOOL (Albert & Jacques, 1993) is a commercial system based on the same ideas that underly SHELLEY, but it is based on a more recent version of the KADS methodology. Besides an inference structure editor, KADSTOOL provides facilities for defining domain ontologies. The system has an editor that supports domain modeling. Some actions that this editor supports can be considered as ontology construction. For example, it is possible to define that domain relations are transitive. This knowledge can then be used to decide how domain knowledge must be visualized. However, in KADSTOOL ontology construction and model instantiation are not clearly separated. Similar to SHELLEY, KADSTOOL is intended as a tool for knowledge analysis; it does not support model compilation or model refinement. Kew KEW (Shadbolt & Wielinga, 1990; Anjewierden et al., 1992a), another third-generation KA environment, is a large system that embodies a variety of knowledge elicitation and knowledge refinement tools. As in its predecessor SHELLEY, the skeletal models that are used in KEW are KADS-based. However, in contrast with the original KADS approach, KEW does not merely provide a library of such skeletal models, but it uses the theory of “generalized directive models” (GDM’s) for providing active support for the model construction activity. The GDM theory is described in chapter 4. As in SBF and SHELLEY, the skeletal models in KEW are task models — there is no explicit notion of ontology. KEW has a number of knowledge instantiation tools, which represent the elicited knowledge in private representation languages. These private representations can be translated into a frame language and into first-order predicate logic. For both languages KEW has interpreters and knowledge refinement facilities. Krest The KREST workbench (Steels, 1993) is yet another example of a third-generation KA environment. In this system, which is based on the componential framework (Steels, 1990), skeletal-model construction consists of two parts: (i) the construction of a task structure, which is a task decomposition tree, and (ii) the construction of a model dependency diagram, which is a specification of the domain models (or ontology) that are needed to perform a particular task. For both constituents KREST provides editors. KREST is intended to be used in combination with an application kit which is a library of reusable components. In parallel with the task structure for the application, a task structure for knowledge acquisition is constructed. Thus, for every problemsolving method, an application kit must also have an associated knowledge acquisition method or tool. It is not clear from the literature in which ways model instantiation is supported. The elicited knowledge is compiled into CLOS code. KREST does not support knowledge refinement. Dids In the DIDS system (Runkel & Birmingham, 1994), the emphasis is on separating task knowledge and search control knowledge. The skeletal model is formed by a description of a problem space, a set of operators (the task model) and a set of knowledge structures (the ontology). Based on this skeletal model, a number of mechanisms for knowledge acquisition are selected, and a knowledge acquisition method is specified . The mechanisms for knowledge acquisition use specialized visualizations and may have private validation procedures. In the model-compilation phase, the knowledge engineer associates problem-solving mechanisms with the operators. The mechanisms can be associated with code for compiling to different problem solvers. Because the compilation procedures make assumptions only about the mechanisms, and not about the instantiated knowledge, they can be stored for reuse once they are developed.

52


Protégé-II Current work on PROTE´ GE´ -II (Puerta et al., 1992) attempts to overcome the limitations of PROTE´ GE´ . PROTE´ GE´ -II is a large environment that embeds a number of tools, amongst which a mechanism configuration facility and an ontology editor. Mechanisms are primitive building blocks for problem-solving methods. In the PROTE´ GE´ -II framework, the configuration of mechanisms and the application ontology together form the skeletal model. Another tool of the workbench, DASH, uses the ontology to generate a model instantiation tool, which is capable of consistency checking and communication in domain-specific terminology. The user of DASH (usually a knowledge engineer) is responsible for defining an intuitive user-interface and, to some extent, a sensible dialogue structure. Similar to PROTE´ GE´ , PROTE´ GE´ -II compiles the generated knowledge directly into CLIPS production rules. The system does not support knowledge refinement.

Tool Emycin Kas Expert Mole Salt Opal Aquinas Alto Protégé SBF Keats Shelley Kadstool Kew Krest Dids Protégé-II

Skeletal Model Construction Task Model Ontology Editor Library Process Editor Library Process – – – – – – – – – + ? + + + + ? +

– – – – – – – – – + + + + + + + +

– – – – – – – – – + – – – + – – –

o – – – – – o o + – ? – + – + ? +

– – – – – – – – – – + – – – + + +

– – – – – – – – – – – – – – – – –

Figure 3.3: A summary of the means by which the tools described in this chapter support the model construction activity.

Editor support means that the tool has editing facilities for specifying the skeletal model, library support means that the tool provides access to a library of reusable skeletal models or components of skeletal models, and process support means that the tool actively supports the modeling process. In the table, + means that the type of support is provided, o means that the type of support is only provided to a limited extent, – means that the type of support is not provided. The value n.a. means not applicable. A ? means that it could not be determined from the literature whether the type of support is provided.

The results of the analysis of the different tools are summarized in Fig. 3.3, Fig. 3.4 and Fig. 3.5. It should be emphasized that tools which have many pluses in the tables are not necessarily the ideal tools for knowledge acquisition. Some tools support all activities to some extent, while other tools provide extensive support for one activity only. For example, although AQUINAS does provide editor support for ontology specification according to Fig. 3.3, the types of things that can be specified are restricted to concepts and dimensions. Further, there is always some form of subjectivity in analyses as the one presented here. This subjectivity is manifest in the tools that were selected, the dimensions that were used for the comparison and the way in which the consulted literature was interpreted. However, in spite of these difficulties we still think that the tables are a useful starting point for comparing tools and investigating which facilities an ideal


Tool

consistency checking

Emycin Kas Expert Mole Salt Opal Aquinas Alto Protégé SBF Keats Shelley Kadstool Kew Krest Dids Protégé-II

Model Instantiation completeness domain intuitive checking terminology visualization

o o o + + + + + + + + + + + + + +

– o – + + + + + + – ? – + + ? + ?

– – – – – + + – + – + – – – ? – +

– – – – – + + + + + + + + + ? + +

dialogue structuring – – – + + – o – – + – – – – ? + –

Figure 3.4: A summary of the means by which the tools support model instantiation.

tool Emycin Kas Expert Mole Salt Opal Aquinas Alto Protégé SBF Keats Shelley Kadstool Kew Krest Dids Protégé-II

Model Compilation automatic semilibrary automatic support n.a. n.a. + n.a. + + + – + + ? – – o + – +

n.a. n.a. – n.a. – – – + – – ? – – – – – –

n.a. n.a. – n.a. – – – – – – ? – – – – + –

tracing + + + + + + n.a. + ? + + – – + + + +

Model Refinement how / what if / blamewhy why not assignment + + + + + ? n.a. – ? – + – – + – – –

– – – ? + ? n.a. – ? – – – – – – – –

– – – + – – n.a. – – – – – – – – – –

Figure 3.5: A summary of the means by which the described tools support model compilation and refinement.

53

54


knowledge acquisition tool should provide.

3.6 Conclusions This chapter has presented a framework for comparing model-based knowledge acquisition tools. The framework distinguishes four activities in the model-based KA paradigm: the construction of a skeletal model, the instantiation of that model, the compilation of the instantiated model into an executable model and the dynamic evaluation of the executable model to provide feedback about the validity of the instantiated model. Also a fifth activity was mentioned: the use of the instantiated model to provide feedback about the validity of the skeletal model, but since there are at present no KA tools that support this activity it was left out of the framework. For each of the four activities, the chapter distinguished ways in which they could be supported by tools. Then, a number of well-known KA tools were compared with respect to these types of support. An important reason for developing the framework was to gain insight in the range of skeletal models that have been used in KA tools and the effects of the use of these models on the other knowledge acquisition activities. Although it was claimed that all knowledge acquisition tools are model based to some extent, the model-based-KA perspective has introduced some bias in the selection of dimensions for comparison. For example, a number of researchers in the KAas-modeling paradigm have emphasized the importance of using multiple experts (e.g. Shaw & Gaines, 1989). Tools developed from this perspective often have advanced features for integrating the opinions of different experts, but this feature was not chosen as a dimension for comparison. Based on the analysis, the following conclusions can be drawn. Firstly, different types of skeletal models have been used in model-based knowledge acquisition, which contain different types and different amounts of information. The skeletal models can be classified according to a number of dimensions. These are

tools which use widely applicable but weak skeletal models (e.g. EMYCIN) and tools which use very a specific skeletal model which have a limited scope (e.g. MOLE); tools which use skeletal models of a knowledge representation formalism (e.g. EXPERT) and tools which use knowledge-level skeletal models (e.g. SHELLEY); tools which use fixed, implicit skeletal models (e.g. OPAL) and tools which allow userdefined, explicit skeletal models (e.g PROTE´ GE´ -II ); tools where the skeletal model is a model of the reasoning process (e.g. KEW) and tools where the skeletal model is elicitation oriented (e.g. AQUINAS); and tools where the skeletal model describes the types of domain knowledge (e.g. ALTO) and tools where the model describes the knowledge requirements of the problem-solving method (e.g SALT).

In model-based knowledge acquisition, the information in the skeletal model is used to support model instantiation, model compilation and model refinement. Therefore, it is important to know how the different types of information that skeletal models may contain are related to the types of support that can be provided for the other activities. In chapter 6 of this thesis, this question is addressed for the model instantiation activity. Chapter 6 describes the CUE workbench which uses information specified in one part of the skeletal model — the application ontology — to support model instantiation by consistency checking, by completeness checking, by using domain-specific terminology, by using specialized visualization and by dialogue structuring.


55

Chapter 7 addresses the question of how skeletal models can be used in the model compilation activity. The chapter presents an approach where user-defined, knowledge-level skeletal models are mapped onto skeletal models of the representation formalisms used by problem solvers. These mappings may be considered as extensions to the knowledge-level skeletal model for compilation purposes. A second conclusion that can be drawn from the analysis presented in this chapter is that few tools support the process of skeletal-model construction. KEW and SBF are the only tools that support task model construction and there are at present no systems that provide process support for ontology construction. These issues are addressed in this thesis in chapter 4 and 5. Chapter 4 describes the GDM theory and its implementation in KEW. The GDM theory is a theory about how the process of constructing task models can be organized. Chapter 5 presents a library of ontology components and some principles for using this library. These principles could be viewed as the first sketch of a method for ontology construction.

56


Chapter 4

Generalized Directive Models In chapter 3 it was mentioned that KEW used the theory of generalized directive models to support the model construction process. In this chapter, this theory is presented in the original form in which it was developed as part of the ACKnowledge project. Then the theory is reinterpreted in the context of more recent developments in knowledge-engineering theory such as the use of application ontologies. In the line of this thesis, this chapter is mainly important because it shows how the work on a methodology with a task/method-oriented perspective forced us to direct our attention to ontologies. The chapter is based on a number of papers which are co-authored by Peter Terpstra, Nigel Shadbolt and Bob Wielinga. The references are: van Heijst, G., Terpstra, P., Wielinga, B., & Shadbolt, N. (1992a). Using generalised directive models in knowledge acquisition. In Wetter, T., Althoff, K., Boose, J., Gaines, B., Linster, M., & Schmalhofer, F., editors, Current Developments in Knowledge Acquisition: EKAW-92, Berlin, Germany. Springer-Verlag. van Heijst, G., Terpstra, P., Wielinga, B., & Shadbolt, N. (1992b). Generalised directive models. In Proceedings of KAW-92, Banff. Terpstra, P., van Heijst, G., Wielinga, B., & Shadbolt, N. (1993). Knowledge acquisition support through generalised directive models. In David, J., Krivine, J., & Simmons, R., editors, Second Generation Expert Systems, pages 428–455. Berlin Heidelberg, Germany, Springer-Verlag.

4.1 Introduction As argued in the previous chapter, there are three possible ways to support the construction of task models and application ontologies: (i) providing specialized editing facilities, (ii) providing libraries of reusable components, and (iii) providing a theory of how such components can be assembled. This chapter presents an overview of such a construction theory for task models, based on the notion of generalized directive models (GDMs). Because the work presented in this chapter was performed in the context of the ACKnowledge project, the terminology used differs slightly from the terminology used in the other chapters. Where necessary, the ACKnowledge terminology will be explained. The purpose of ACKnowledge was to build KEW, a large knowledge engineering workbench that actively supports the knowledge-acquisition process by suggesting which knowledge should be acquired in the next step of the acquisition process and which acquisition tool should be used (Jullien et al., 1992; Shadbolt & Wielinga, 1990; Anjewierden et al., 1992a). 57

58


4.2 Problems with Model-Based Knowledge Acquisition The model-driven approach to knowledge acquisition implicitly advocates a staged model of the acquisition process: first the skeletal model is acquired — for example by selecting one from a predefined set — and then the model is instantiated with appropriate domain knowledge. During model instantiation, skeletal models are used as high level templates that put constraints on the domain knowledge that is required. The models direct knowledge acquisition because they make explicit what kind of knowledge is used in the problem-solving process and they provide a schema for structuring the knowledge base. In model-based knowledge acquisition, it is often assumed that the correct skeletal model can be selected using global features of the task that the system has to perform. For example, in the KADS framework (Wielinga et al., 1992) the models are selected using a decision tree. The nodes of this tree are associated with questions about general characteristics of the task such as the solution type. It is assumed that these questions can be answered without detailed knowledge about the domain. In this chapter it is argued that this assumption is not alway correct; sometimes the suitability of a skeletal model depends on detailed characteristics of the domain knowledge, which can only be revealed through acquisition of actual domain knowledge. In situations like these a dilemma arises: some domain knowledge needs to be elicited before the skeletal model can be established, but at the same time directed elicitation of domain knowledge requires the availability of a skeletal model. The fact that an appropriate model can only be selected after inspection of domain knowledge invalidates the earlier mentioned “separate stages assumption”. A second problem with model-based knowledge acquisition is related to the use of a library of predefined models, such as in KADS or the Generic Task approach. Because such a library contains only a limited set of generic problem-solving models, there is not always a prototypical model available for a real world problem. In such cases, prototypical models need to be adapted or, alternatively, constructed from scratch. For example, in (Schreiber, 1992) five forms of modifications are described for skeletal models: refinement, addition, simplification, deletion and renaming. These forms of adaptation are all on the level of primitive components of the skeletal models. Adaptation and construction of models could also be supported by the explicit representation of partial models which can be replaced by other explicitly represented partial models to yield other skeletal models. However, flat library representations as the ones mentioned above do not have the expressive power that is required for doing this. This chapter proposes a way to handle the complications mentioned above without losing the advantages of model-driven knowledge acquisition. One particular kind of skeletal model will be focused on: KADS interpretation models (Breuker et al., 1987). Interpretation models are a good starting point for a more flexible use of skeletal models because the KADS approach provides a semi-formal conceptual modeling language for describing arbitrary models. Interpretation models describe the inference structure and the task structure of a certain problem. In this analysis only the inference structure has been taken into account. KADS inference structures consist of knowledge sources, representing “primitive” inference steps, and meta classes, which index domain knowledge in terms of the role that it plays in the problem-solving process.1 There is a fixed set of knowledge sources with a predefined semantics. This chapter is organized in the following way. The next section introduces the notion of 1

Knowledge source and meta class are part of the original KADS vocabulary. They are now called (primitive) inference and knowledge role respectively. The latter terms are also used in GAMES.

Chapter 4: Generalized Directive Models

59

generalized directive models, and describes how they can be used to avoid the problems mentioned above. Next, the technical details of the approach are described. As an illustration, Sec. 4.6 gives an example of the way GDMs are used in a real life knowledge-acquisition scenario. Finally, the relation between work on GDMs and the other work in this thesis will be discussed.

4.3 Generalized Directive Models The problems of model selection, the library components and their representation that were pointed out above can be solved through the introduction of generalized directive models.2 GDMs are interpretation models which leave parts of the problem-solving process underspecified. This is modeled through the introduction of a third building block for models: the generalized knowledge source. A generalized knowledge source describes a non-primitive problem-solving step that represents the fact that it is not known how the corresponding part of the problem-solving process should be modeled. Another way of saying this is that a generalized knowledge source represents a set of possible model components with similar input/output relations. These model components can be primitive knowledge sources, but they can also be partial models that consist of multiple generalized and primitive knowledge sources and intermediate meta classes. However, these model components have in common that they describe the same relation between the input and the output of the generalized knowledge source, albeit at different levels of detail. The key idea is that these GDMs contain sufficient information to guide the elicitation of at least some domain knowledge. At the same time, the elicited domain knowledge will reveal new information about the domain, and this new information can be used for further refinement of the underspecified parts of the GDM. GDMs are based on three related principles:

Knowledge acquisition is a cyclic process Knowledge engineering is an iterative process of elicitation of domain knowledge, integration of the elicited knowledge with previously acquired knowledge and evaluation of the acquired knowledge to assess the current state of the acquisition process. Model construction is an integral part of this cycle. Compositionality A generalized knowledge source describes a relation between inputs and outputs. The principle of compositionality states that every refinement of that generalized knowledge source must ensure that this relation between the inputs and the outputs is maintained. This principle ensures that the decision to refine a generalized knowledge source in a particular way does not affect other parts of the directive model. A delayed commitment strategy Knowledge engineers should only commit themselves to a particular model if there is sufficient evidence that it is the “right” model. This reflects the idea that backtracking on skeletal model construction is difficult and should be avoided when possible.

Generalized directive models enable interleaving of the two stages of the knowledgeacquisition process. Although it is still required that there is an initial skeletal model to bootstrap knowledge elicitation, this initial GDM may be extremely general, leaving all parts that depend on properties of the domain knowledge unspecified. This model can then be used to instigate acquisition of domain knowledge. 2

The term “directive” is used to emphasize that the models are used to direct knowledge acquisition.

60


There are two ways in which the GDM can direct the knowledge-acquisition process. Firstly, the primitive knowledge sources in the GDM require specific kinds of domain knowledge. Therefore, the semantics of knowledge sources can be used to determine the types of domain knowledge that are needed to instantiate these knowledge sources. For example, if the model contains a primitive knowledge source “taxonomic abstraction”, a domain taxonomy will be required. Also the generalized knowledge sources may guide the knowledge-acquisition process, but in a different way. Generalized knowledge sources have a limited set of possible refinements, the applicability of which depends on features of the domain knowledge. In order to select the appropriate extension, it must be investigated which types of domain knowledge are available in the domain. Thus, generalized knowledge sources can direct knowledge acquisition by focusing on eliciting domain knowledge that reveals features that could be used to select appropriate refinements. In summary, in the GDM view the knowledge-acquisition process is organized in the following way. The process starts by selecting an initial GDM, which may consist of primitive and generalized knowledge sources. Then, a cyclic process of knowledge elicitation and GDM refinement starts, where the primitive and generalized knowledge sources suggest what types of knowledge should be elicited. In the next cycle of the acquisition process, the newly elicited knowledge can be used to refine the GDM by filtering the possible extensions of the generalized knowledge sources. If only one possible extension is left, it takes the place of the generalized knowledge source in the GDM.

4.4 The GDM Grammar In KEW, the library of GDMs is represented as a context-sensitive generative grammar. By analogy with natural language, it could be said that the final models are sentences, the generalized knowledge sources are intermediate constituents, and the knowledge sources and meta classes are words. The model-construction steps in each acquisition cycle correspond to the application of rewrite rules. Each of the rewrite rules has associated conditions that have to be true before the rule may be applied. These conditions are the link between the skeletal model and the features of the domain knowledge.

?input1, NT-Abstract, ?output --> (?input1, Domain-Taxonomy), T-Taxonomic-Abstraction, ?output. Conditions: there is a domain taxonomy that relates objects in the meta class unified with variable ?input1 through taxonomic (is-a) relations with objects unified with variable ?output.

Figure 4.1: An example of a GDM rewrite rule. The prefixes NT- and T- stand for “Non-Terminal” and “Terminal”

respectively.

Let us use abstraction as an example. In a particular GDM grammar, the generalized knowledge source NT-Abstract can be rewritten in several ways. One of the candidates is the primitive


61

knowledge source T-Taxonomic-Abstraction. The corresponding rewrite rule is given in Fig. 4.1. The symbols ?input1 and ?output are variables that can be unified with meta classes. The variable scopes are limited to rewrite rule and its associated conditions. The given rule reflects the following idea: If there is a generalized knowledge source NT-Abstract in the GDM with input ?input1 and output ?output, then this generalized knowledge source may be replaced by the knowledge source T-Taxonomic-Abstraction with input meta classes ?input1 and Domain-Taxonomy and with output ?output. The meta classes ?input1 and ?output already exist in the model before the rule is applied. The meta class Domain-taxonomy is introduced in the model when the rewrite rule is applied. The rule may only be applied if the associated conditions are satisfied. In this particular example there is only one condition: the existence of a domain taxonomy that contains taxonomic links between the inputs and the outputs. In Fig. 4.1 and in the scenario presented in Sec. 4.6 the conditions are described in natural language. In KEW, where the system checks whether the conditions are satisfied, a simple condition-description language is used. The use of input and output variables in the left hand sides (LHS) of rewrite rules is not conventional in grammars. There are two reasons for the introduction of these variables. Firstly, the right hand side (RHS) of a rewrite rule does not necessarily have a strict linear internal structure. A meta class associated with the non terminal in the LHS of the rule can be associated with more than one knowledge source and non terminal in the RHS of the rule. To express such facts in the rewrite rules, we need labels for these meta classes. The variables are a way of labeling the meta classes. The second reason for the introduction of input and output variables is that they enable referring to the input and output meta classes in the conditions. The grammar is also extended with special model variables. These variables can be used for model-wide communication about the existence of particular types of knowledge in the domain. They function as stores for information that might be needed at different places in the model. Metaphorically, these variables are the GDM equivalent to anaphora in natural language. For example, if the same rule is applied twice in the construction history of a GDM, and in the RHS of this rule there is a reference to a causal model of the domain, it would be more appropriate to refer to the same meta class in the GDM than to a different but similar meta class.3 This can be done by storing the causal model in a special variable ?causal-model, that can be read by other rewrite rules. The use of these variables with a grammar wide scope is a concession: formal elegance is sacrificed for expressive power. For this reason, the use of these variables has been restricted to features of the domain that are independent of the problem-solving process, like the existence of a structural model of the object that is reasoned about, or the universe of observables. We have not been very specific about the nature of the conditions on the rewrite rules. The conditions are the interface between the grammar formalism and the empirical knowledge about problem-solving processes. The conditions used in the library are established empirically, by analyzing existing knowledge-acquisition scenario’s. Because we were mainly interested in the conceptual modeling phase of knowledge acquisition the conditions mainly have to do with knowledge availability and with the nature of the inputs and outputs of the task. However, it is expected that also design oriented conditions can be incorporated, reflecting the computational constraints of the target system. 3

This may be arguable in the context of knowledge modeling, but it is certainly true for knowledge acquisition: you don’t want to acquire the same knowledge twice!

62


4.5 GDM’s in KEW The GDM formalism is used in KEW to drive an “advice and guidance” module. The task of this module is to suggest appropriate knowledge acquisition activities, based on an analysis of the state of the KA process, and also taking the context into account. Fig. 4.2 shows a high-level description of the architecture of this module. GDM hierarchy

GDM grammar

analyse CKB

CKB features

execute CKB

refine GDM

select initial GDM

current GDM

generate task schedule

core knowledge base

partition 1

partition 2

partition 3

...

current task schedule

transform knowledge

select KA activity

knowledge in tool-specific representation

current KA activity

elicit domain knowledge

tool knowledge base

select KA tool

partition n

knowledge acquisition tool

knowledge acquisition context Figure 4.2: The architecture of KEW’s advice and guidance module.

The first step in the KA process in KEW is the selection of an initial GDM. To do this, KEW invokes an interview facility that poses some general questions about the nature of the task and the nature of the domain. As soon as the system has acquired enough information to select an initial GDM, the user is informed about this. At this point, the user can decide to start a knowledge elicitation session, or alternatively, continue the interview to select a more specific initial GDM. Next, KEW uses the GDM to generate a task schedule. This is a sequence of possible knowledge elicitation activities, with for each of the components of the GDM a corresponding activity. The ordering of the activities that KEW suggests is based on two heuristics: (i) focus elicitation around primitive knowledge sources and (ii) start with eliciting knowledge that is related to already acquired knowledge. Both heuristics are based on the same underlying principle: start with the


63

elicitation activities that are most strongly constrained. After this, the knowledge engineer selects one of the activities in the task schedule to work on. KEW then attempts to determine constraints associated with the activity, by inspecting the part of the GDM that the activity is associated with. The system then uses these constraints, and also its knowledge about the KA tools and its knowledge of the current context, to suggest an appropriate knowledge acquisition tool for the activity. When the user has decided which tool (s)he wants to use, KEW passes control to the selected KA tool. When the session with the selected tool has finished, the results of the KA session are transformed in one of KEW’s knowledge representation languages and stored in the core knowledge base (CKB). The CKB is a large knowledge repository with an internal partition structure, which is also partially based on the contents of the current GDM. For every component of the GDM there is a separate partition. Therefore, the advice and guidance module knows where to put the newly elicited knowledge. When the new knowledge is merged into the CKB, KEW analyzes the CKB partitions with respect to a number of properties that they may have: the CKB features. These features are meta characterizations of the knowledge in the partitions; they describe for example the size of a partition, the completeness of a partition or the types of knowledge in a partition. Finally, the CKB features are used to refine the current GDM. For each of the generalized knowledge sources in the GDM, KEW attempts to rule out rewrite rules, by comparing their conditions with the features of the CKB. When only one rule is left for a particular generalized knowledge source, the rule is applied to generate a more specific GDM, which can then be used in the next cycle in the knowledge acquisition process.

4.6 A Fragment of a GDM Scenario findings

T-Match

hypotheses

T-Abstract

NT-Predict

observations

norms

NT-Test

solutions

Figure 4.3: The current GDM in the scenario. The ellipses represent knowledge sources (primitive inferences), the boxes

represent meta classes (knowledge roles) and the double ellipses represent generalized knowledge sources (non-primitive inferences).

This section illustrates how a GDM grammar directs the knowledge-acquisition process. The example is taken from a knowledge-acquisition scenario to build a system for diagnosis of

64


?input1,NT-Predict,?output => (?input1,?causal-model,Specification-Rules) T-specify, ?output. conditions:

there is a causal model in the domain that can be used to derive observable effects of deficiencies in the system that is reasoned about.

?input1,NT-Predict,?output => (?input1,Hypothesis-Norms), T-Select, ?output. conditions:

(3)

Not every hypothesis in ?input1 has an associated norm, but every hypothesis in ?input1 can be refined to another hypothesis with an associated norm that must be true if the refined hypothesis is true.

?input1,NT-Predict,?output => (?input1,Generalization-Rules), T-Generalize, Generalized-Hypotheses, NT-Predict, ?output. conditions:

(2)

Every hypothesis in ?input1 has an associated norm that must be true if the hypothesis is true.

?input1,NT-Predict,?output => (?input1,Refinement-Rules), T-refine, Refined-Hypotheses, NT-Predict, ?output. conditions:

(1)

Not every hypothesis in ?input1 has an associated norm, but every hypothesis in ?input1 can be generalized to another hypothesis with an associated norm that must be true if the generalized hypothesis is true.

Figure 4.4: Rewrite rules for non terminal symbol NT-Predict.

(4)


65

respiratory diseases. In Terpstra et al. (1993) the scenario is described in full detail. At a certain moment in the scenario, the current GDM is the model that is shown in Fig. 4.3. The boxes in this figure represent meta classes, the ellipses represent primitive knowledge sources, and the double ellipses represent generalized knowledge sources. In the acquisition process so far, the knowledge engineer has concentrated on the left side of the model, which is the part where hypotheses are generated. This part of the model is completely refined, so it contains only primitive knowledge sources. Also most of the domain knowledge that is required to execute this part of the problem-solving process is already elicited. In particular, most hypotheses (respiratory diseases in the domain) are identified. The hypothesis generation part of the model is similar to the hypothesis generation part in the classical model for heuristic classification (Clancey, 1985). However, the part of the model where the hypotheses are tested is still underspecified. It is known that hypotheses are tested by predicting an observable manifestation (a norm) that is expected when the hypothesis is true, but how this prediction is done is still unclear. For this reason the knowledge engineer decides to concentrate on the prediction step in the model. The GDM grammar contains four rules to rewrite the non-terminal symbol NT-Predict. These rules are shown in Fig. 4.4. The main goal of the knowledge engineer at this stage in the acquisition process is to determine which of the four rules should be applied. As can be seen in the conditions, this decision depends on detailed characteristics of the application domain. The first rule is only applicable if there is a causal model of the respiratory system that can be used to derive the observable manifestations of a certain respiratory disease. Because of this the knowledge engineer starts looking for such a causal model. However, in the think-aloud protocols evidence is found that many diseases have unique identifiers, and that no causal model is used to predict the norms for hypotheses. This rules out the first rule in Fig. 4.4. Since many diseases have unique identifiers the knowledge engineer suspects that the second rule is the correct rule. For this reason he tries to elicit the associated norms for the possible hypotheses. While doing this, the knowledge engineer discovers that not every possible hypothesis has an obvious norm associated with it that can be used to decide if the hypothesis is true. This proves that rule 2 is not the correct rule either. However, additional KA reveals that every hypothesis can be refined to a more specific hypothesis that has an associated norm. At this stage the knowledge engineer knows that the third rule for NT-Predict is applicable, because the condition for that rule is satisfied. Just applying rule 3 is not sufficient. The recursive nature of the rule means that after its application the directive model still contains the non terminal NT-Predict. However, now the refined hypotheses are the input for NT-Predict and we know that all the refined hypotheses have associated norms so rule 2 can be applied directly after rule 3. The fragment demonstrates that sometimes a detailed analysis of domain knowledge is required to reveal the correct form of the skeletal model: the question whether every generated hypothesis has an associated norm can hardly be considered a global characteristic of the task. The fragment is also a good illustration of the delayed commitment strategy. The third grammar rule for NT-Predict is only applied when the knowledge engineer has found sufficient evidence that the rule indeed captures the inferences made by the domain expert.

4.7 A GDM Grammar for Design The diagnosis grammar used in the scenario in the previous section consists of 14 rewrite rules. These rules are intuitively sensible and they seem to produce appropriate models. For example, the

66


grammar is able to generate the “classical” models for Heuristic Classification (Clancey, 1985), Cover-and-Differentiate (Eshelman, 1988) and Systematic Diagnosis (Wielinga et al., 1992), together with a wide range of less well known models that intuitively make sense. In order to test whether the GDM-grammar formalism is powerful enough for capturing knowledge-engineering knowledge developed outside the context of ACKnowledge, Allemang and van Heijst (1993) performed an experiment to formulate the analysis of design problemsolving by Chandrasekaran (1990) as a GDM grammar. The grammar that was the result of this experiment is presented in Appendix A. To test the grammar’s validity, it was used to model the behavior of a number of knowledge engineers when designing a KBS. In a prior experiment, Allemang and Rothenfluh had investigated how a number of knowledge engineers applied the generic task approach to design a KBS for the office assignment task (Allemang & Rothenfluh, 1992).4 One result of this experiment was that there was a large variety in the ways that the Generic Task approach was applied. However, when modeled using the GDM grammar and KEW, the different design decisions of the knowledge engineers appeared to correspond to the application of different rewrite rules, due to ambiguities in Chandrasekaran’s formulation of the conditions under which particular decomposition methods should be applied. The formulation of the task analysis as a GDM grammar helped to resolve some of these ambiguities.

4.8 GDM’s Revisited The ACKnowledge project ended at the end of 1991. Since then, GDMs have been used by a number of researchers. In particular, research performed in the context of the VITAL project (e.g. Shadbolt et al., 1993; O’Hara, 1993; Motta et al., 1994) has used and extended the approach. A number of GDM grammars have been developed and described in the literature. In the previous section, the grammar for design developed by Allemang and van Heijst was already mentioned. Further, Benjamins (1993) used GDMs and KEW to illustrate that his analysis of diagnostic problem solving could be used for knowledge acquisition purposes. As part of the CommonKADS project, the successor of KADS, a library of knowledge modeling components has been developed (Breuker & Van de Velde, 1994). Parts of this library, in particular the expansion methods (Valente et al., 1993), are organized according to principles similar to those that underly the GDM approach. The wide acceptance of the GDM idea suggests that it solves some of the problems related to the earlier approaches to library organization and use. However, one of the principles underlying the GDM theory, namely the observation that model construction and model instantiation need to be interleaved, is in conflict with the approach described in chapter 2, where it was argued that model instantiation is only allowed when the skeletal model has been constructed. This section will argue that the reason for this apparent conflict lies in a different view of what should be in a skeletal model.

4.8.1

What is in a GDM condition?

The conditions form the interface between the directive model and the features of the domain knowledge. A closer look at the conditions reveals that they do not directly refer at all to what 4

Note that the modeled task is KBS design, and not office assignment.


67

is called domain knowledge in GAMES terminology. For example, the following condition was used in the first rule of Fig. 4.4: There is a causal model in the domain that can be used to derive observable effects of deficiencies in the system that is reasoned about. The condition states that there are causal relations in the domain, and that some of the states in the causal network are associated with observable effects. In GAMES terminology, such a fact would be considered as part of the application ontology, and not as part of the domain knowledge. The same observation holds for the following condition: Every hypothesis in ?input1 has an associated norm that must be true if the hypothesis is true. This condition states that there are direct links between hypotheses and norms. In a GAMES application, such a question could be answered by looking at the ontology. For example, in the case where hypotheses are mapped onto diseases and norms onto findings, the question could be answered by looking if there is something like the manifestation-of relation in the application ontology. Thus, it seems that the conditions on the GDM rules reflect constraints on the application ontology, and not on the actual domain knowledge. A similar phenomenon can be found in the GDM grammars developed by others. For example, to model a diagnostic reasoner, Benjamins (1993) used the conditions shown in Table 4.1. prime diagnostic method - Can all hypothesis be generated? (1) - Can additional observations be obtained? (2) ask-user symptom-detection method - Is the user able to recognize symptoms? (3) empirical hypothesis-generation method - Are there empirical associations between observations and hypotheses? (4) - Is probability information about faults available? (useful condition) (5) discrimination method - Is the non-intermittency assumption satisfied? (6) select-random method - Are the hypotheses in the hypothesis set unrelated to each other? (7) compiled-test method - Are there associated (pre-stored) tests for testing hypotheses? (8) interpret-data in isolation method - Are the hypotheses in the hypothesis set unrelated to each other? (9)

Table 4.1: The methods and conditions used in (Benjamins, 1993) to construct a diagnostic reasoning model

68


Of the conditions in Table 4.1, only conditions 2 and 3 are not directly related to the ontology and the role mappings. However, these conditions refer to the context in which the system will be employed, so it is may be concluded that none of the conditions refer to what would be called domain knowledge in GAMES terminology. It is fair to conclude that in the GAMES view, the conditions would be related to the application ontology, and not to the application knowledge. In the original work on GDMs this fact was obscured because there was no explicit distinction between domain knowledge and ontology. As a result, the only way for KEW to establish the validity of particular ontological commitments was to acquire domain knowledge and then analyze it with respect to certain features which we would now call ontological features. In retrospect, the GDM principle that knowledge engineering is a cyclic process where model construction and model instantiation are highly interleaved, should be reformulated as the principle that construction of the task model and the application ontology should be highly interleaved. In turn, development of the application ontology could require the elicitation of some domain knowledge, but this would only be for uncovering the ontological structure of the domain, and not per se for model instantiation. This distinction is important, because the two types of elicitation have different goals and therefore different requirements. For example, whereas completeness is an important issue in model instantiation, it is often not very important for ontological modeling.

4.9 Discussion This chapter began with a presentation of the GDM theory as it was conceived at the end of the ACKnowledge project, in 1991. Subsequently, a conflict was signaled between this theory and one of the principles that underly the GAMES approach. Whereas the main message of the work on GDMs was that skeletal-model construction and domain-knowledge elicitation can not be separated, this is one of the cornerstones of the GAMES approach. However, a closer inspection of the conditions on the GDM rules revealed that the conflict was due to different conceptions of what should be in a skeletal model. In the GDM interpretation, only the model of the reasoning process should be part of the skeletal model and the ontology is considered as part of the domain knowledge. In contrast, in GAMES the skeletal model includes the application ontology. More generally speaking, a weakness of the GDM approach is that it has a purely task/methodoriented perspective on knowledge modeling. This view was inherited from the original KADS approach, which suffered from the same problem. Although the main reason for the conception of the four-layer model was that a separation of different types of knowledge would facilitate the reuse of each, in practice this was only worked out for the inference layer and the task layer. Another weakness that GDMs inherited from KADS is that there is no proper vocabulary for expressing ontological commitments and requirements that inference structures put on the domain knowledge that they are connected to. In KADS the connection between the inference structure and the domain knowledge is realized through domain views (Schreiber, 1992). Domain views specify how parts of the domain knowledge can be used by primitive inferences. The domain views, which are defined by the knowledge engineer, are pointers from the inference to the domain relations that they use. However, there is no explicit representation of the constraints that a domain relation should satisfy in order to be used in the domain view of an inference. In GDMs, the lack of a vocabulary for expressing the ontological requirements of inferences — and of their aggregates — is visible in the ad hoc character of the conditions on the rewrite


69

rules. In KEW, where the system reasons about the conditions, the conditions are expressed in terms of simple attribute value pairs. There are no restrictions with respect to the attributes that are allowed. The key problem in model-based knowledge acquisition is the interaction between task models and the nature of domain knowledge. In the remainder of this thesis, we will focus on the use of ontologies as meta models that abstract from domain knowledge. The connections between the domain knowledge and the task models can then be realized by means of mappings between the task model and the meta model. These meta models must be sufficiently abstract to allow straightforward mappings, and contain sufficient ontological commitment to decide on the suitability of a particular method.

70


Chapter 5

Principles for Ontology Library Construction This chapter presents principles for organizing a library of reusable ontology components in the medical field. The focus is on the internal structure of such a library, how it can be built and how it can be used. The proposed principles are illustrated with a library of medical ontologies developed by Sabina Falasconi at the University of Pavia and presented at the ECAI-94 workshop on implemented ontologies. For the library examples in the other chapters a library developed in Amsterdam was used. This chapter will be published in the journal AI in Medicine. The article is co-authored by Sabina Falasconi, Ameen Abu-Hanna, Guus Schreiber and Mario Stefanelli. The reference is: van Heijst, G., Falasconi, S., Abu-Hanna, A., Schreiber, A.Th., & Stefanelli, M. (1995). A case study in ontology library construction. AI in Medicine. (in press).

5.1 Introduction Many authors in the field of knowledge acquisition for knowledge-based systems (KBS) have emphasized the importance of reusable components to reduce the effort required for KBS development (e.g. Musen, 1992). Two types of components have been identified as potentially sharable and reusable: (i) problem-solving methods, abstract descriptions of the steps that must be taken to perform a particular task, and (ii) domain ontologies, abstract descriptions of the structure of domain knowledge in a particular field. Most present approaches share the view that reuse of these components is facilitated by the use of KBS architectures that keep the problem-solving methods and the domain ontologies separated. Fig. 5.1 shows the architecture of a KBS that is organized according to these principles. Until recently, most researchers in the field have concentrated on the domain-independent specification of problem-solving methods (Marcus, 1988; Tu et al., 1989; Wielinga et al., 1992; Breuker & Van de Velde, 1994). The availability of abstract models of the methods to perform a real world task has proven to be very useful for knowledge acquisition. Since the model of a method determines which knowledge is required to perform a particular task, it can be used to direct the knowledge acquisition process. This is often called the model-driven approach to knowledge acquisition. For example, MOLE (Eshelman, 1988), a knowledge acquisition tool for systems that use the Cover-and-Differentiate problem-solving method, uses its knowledge of the domain-knowledge requirements for this method to focus the knowledge elicitation dialogue. The early successes of the model-driven approach to knowledge acquisition have inspired researchers 71

72

The Role of Ontologies in Knowledge Engineering Problem solving method

ontology

domain knowlege

Observation

Finding

rash = present

generate

Hypothesis

Manifestation-of

differentiate

Solution

Disease

graft-versus-host disease

Figure 5.1: The relation between problem-solving methods, ontologies and domain knowledge, illustrated for the

generate-and-differentiate problem-solving method and a simple conceptualization of a medical domain. The ellipses in the problem-solving method represent knowledge roles, domain independent labels that specify the role of domain expressions in the reasoning process. The arrows between the roles and the domain classes, depicted as rounded boxes, represent role limitations: only instances of the class disease may play the role of hypothesis in the reasoning process.

to investigate other problem-solving methods (Valente & Löckenhoff, 1994), the configuration of problem-solving methods from smaller building blocks (Klinker et al., 1991; Puerta et al., 1992), and the formalization of such building blocks (Aben, 1993). Only recently, researchers in knowledge engineering have started to pay attention to reusable domain ontologies. Whereas KBS developers nowadays have a good chance to find appropriate — or at least usable — problem-solving methods for their applications in the literature, it is unlikely that they will find reusable domain ontologies. The reluctance to take up the challenge of creating libraries of reusable domain ontologies is, in our view, due to two reasons: the hugeness problem and the interaction problem. The hugeness problem concerns the overwhelming amount of knowledge in the world. This makes the construction of a library of reusable domain ontologies a daunting exercise. The interaction problem, first formulated by Bylander and Chandrasekaran (1988), states that domain knowledge cannot be represented independently of assumptions of how it will be used in reasoning. Although these problems provide severe impediments for the development of libraries of reusable domain ontologies, the potential gains are high: collecting domain knowledge is by far the most cumbersome and time consuming step in the knowledge-engineering process. In this chapter, a number of hypotheses about the nature of medical domain knowledge are put forward, from which principles are derived for organizing a library in such a way that the hugeness problem and the interaction problem remain manageable. In short, these principles are that (i) there is a relatively small set of basic concepts that are reusable across many medical domains and tasks, (ii) medical subdomains have domain-specific concepts that are often specializations of the basic medical concepts, and (iii) many problem-solving methods require additional concepts that are specific for that method. The proposed principles are illustrated with examples from a case study in constructing a library of reusable medical ontologies that was performed in the context of the GAMES-II project. The chapter is organized as follows. In Sec. 5.2, a classification of different types of ontologies is discussed. Sec. 5.3 describes the organizational principles that the library is based on, thereby showing how the hugeness problem and the interaction problem can be addressed. Sec. 5.4 shows how these principles are used to build an initial library and Sec. 5.5 explains how the library can be used for KBS development. Sec. 5.6 presents some conclusions and points at future research issues.

Chapter 5: Principles for Ontology Library Construction

73

5.2 Ontologies The term “ontology” is often used in recent AI literature, and not always in the same way. To avoid confusion, we present our interpretation of the term here, together with a typology of different kinds of ontologies that can be distinguished. According to Gruber (1993) an ontology is a “specification of a conceptualization”. It defines the vocabulary of a domain and it specifies constraints on the use of terms in the vocabulary. Ontologies can be classified according to two dimensions: the amount and type of structure of the conceptualization and the subject of the conceptualization. With respect to the first dimension, three categories are distinguished:

Terminological ontologies such as lexicons, specify the terms that are used to represent knowledge in the domain of discourse. An examples of such an ontology in the medical field is the semantic network in UMLS (Unified Medical Language System; Lindberg et al., 1993). Information ontologies which specify the record structure of databases. Conceptual schemata of databases are an example of this class of ontologies. Level 1 of the PEN & PAD model (Rector et al., 1993), a framework for modeling medical records of patients, is a typical example of such an ontology in the medical field. At this level, the model provides a framework for recording the basic observations of patients, but it makes no distinction between symptoms, signs, treatments etc. Knowledge modeling ontologies specify conceptualizations of the knowledge. Compared to information ontologies knowledge modeling ontologies usually have a richer internal structure. Further, these ontologies are often tuned to a particular use of the knowledge that they describe. Within the context of KBS development, knowledge modeling ontologies are the ontologies that we are mostly interested in. The level 2 description of the PEN & PAD model is an example of a knowledge modeling ontology in the medical field. At this level, the level 1 observations are grouped to describe the decision-making process.

The other dimension on which ontologies can be differentiated is the subject of the conceptualization. Four categories can be distinguished on this dimension: (i) application ontologies, (ii) domain ontologies, (iii) generic ontologies and (iv) representation ontologies.

Application ontologies contain all the definitions that are needed to model the knowledge required for a particular application. Typically, application ontologies are a mix of concepts that are taken from domain ontologies and from generic ontologies (which are described below). Moreover, application ontologies may contain method- and task-specific extensions. Application ontologies are not reusable themselves. They may be obtained by selecting theories from the ontology library, which are then fine-tuned for the particular application. We use the term application ontology in a similar way as in PROTE´ GE´ -II (Tu et al., 1995). Domain ontologies express conceptualizations that are specific for particular domains. As indicated in Fig. 5.1, current knowledge engineering methodologies make an explicit distinction between domain ontologies and domain knowledge. Whereas the domain knowledge describes factual situations in a certain domain (e.g. chest pain is a manifestation of atherosclerosis), the domain ontology puts constraints on the structure and contents of domain knowledge (e.g. diseases have findings as manifestations).

74


Generic ontologies are similar to domain ontologies, but the concepts that they define are considered to be generic across many fields. Typically, generic ontologies define concepts like state, event, process, action, component etc. The concepts in domain ontologies are often defined as specializations of concepts in generic ontologies. Of course, the borderline between generic ontologies and domain ontologies is vague, because there is no exhaustive enumeration of fields and their conceptualizations. However, the distinction is intuitively meaningful and is useful for building libraries. Representation ontologies explicate the conceptualizations that underly knowledge representation formalisms (Davis et al., 1993). They are intended to be neutral with respect to world entities (Guarino & Boldrin, 1993). That is, they provide a representational framework without making claims about the world. Domain ontologies and generic ontologies are described using the primitives provided by representation ontologies. An example in this category is the Frame Ontology, which is used in Ontolingua (Gruber, 1993).

5.3 Organization of the Library This section presents structuring principles for organizing an ontology library and illustrates these principles using a medical ontology library that was developed as a case study in the context of the GAMES-II project. In terms of the categories distinguished in the previous section, the library consists of domain ontologies and generic ontologies of the knowledge modeling type. The domain ontologies in this library are described in (Falasconi, 1993). Many of the generic ontologies were taken from the Ontolingua library developed at Stanford University. The classification of ontologies presented in the previous section is too coarse-grained to be used as an indexing scheme for the library. Therefore, a number of principles were formulated that allow a more fine-grained categorization. In short, these principles are that (i) there are some general categories of medical knowledge that are fundamental to all kinds of medical reasoning, (ii) in many application domains there are additional ontological distinctions that are specific for that domain, and (iii) the use of specific reasoning methods may require additional methodspecific ontological distinctions. Based on these principles, the library is partitioned into two regions: a core library and a peripheral library. The core part contains definitions of the generic concepts and of general medical categories. The peripheral part contains definitions of the domainand method-specific extensions. The division is important because the two parts are indexed in different ways. Sec. 5.3.2 describes the core library and in Sec. 5.3.3 the peripheral parts are explained. Before turning to a more elaborate description of these parts, first some general issues in library construction are addressed.

5.3.1

Issues in Library Construction

Language Ontologies need to be specified in a language. A number of languages have been proposed as candidates (e.g. MODEL; Tu et al., 1995, CML; Schreiber et al., 1994), but it is not entirely clear to date which requirements a language for ontological modeling should satisfy. The library presented in this chapter is developed with Ontolingua (Gruber, 1993). An Ontolingua ontology consists of a number of definitions, collections of labeled sentences that constrain the use of a term. Four kinds of definitions are distinguished: classes, relations, functions and instances. Definitions can be grouped into theories, collections of definitions that are somehow related.


75

Theories can include other theories, which means that all the definitions in the included theory are also available in the including theory. Thus, the theory is the main modularity construct available, and is therefore the principal building block of the library that is described below. Modularity A key to successful library organization is modularity. A modular organization is one that organizes units in modules so that the cohesion within modules is maximal, while the interaction between modules is minimal. In the ontology library presented in this chapter, the units are definitions and the modules are theories. There are numerous possible cohesion criteria. Which of these are useful in this context depends on the intended use of the library. The main intended use of the library is to support the construction of application ontologies. Therefore, definitions that are likely to be used in the same application ontologies should be put together into one theory. There are two features that determine which definitions are needed for an application ontology: (i) the medical subdomain that the application should reason about and (ii) the method that the application uses to perform a (sub-)task. For example, applications in the domain of cardiac diseases use (at least partially) other knowledge than that used by applications in the domain of bacterial diseases; similarly, applications that diagnose cancer are likely to use different knowledge from applications that plan cancer therapy. Alternative definitions It is important to stress that the library is not intended as the ontology of medical knowledge; the definitions are not claimed to capture the essence of knowledge categories in some platonic sense. Instead, the definitions should be viewed as conceptualizations that have been proven useful for solving medical problems, either by human experts or by computers. A consequence of this pragmatic point of view is that it is sometimes necessary to allow for alternative, or even inconsistent, definitions of a concept in the library. For example, an often used concept in medical reasoning is “causality”. Since this concept is reusable across many applications, it is an obvious candidate for inclusion in the library. However, the history of philosophy shows that it is extremely difficult to come up with a satisfying definition of causality. When we look at medical reasoning, it seems that a number of alternative conceptualizations are being used. For example, in some cases both the cause and the effect roles of the causes relation are constrained to be physiological states, while in other cases they need to be events. The temporal aspects of the concept may also vary; in some cases the relation between cause and effect is immediate, while in others there may be a delay. Because these alternative conceptualizations are useful in medical reasoning, we have chosen to allow multiple definitions of the same concept, leaving the decision of which conceptualization is appropriate in a particular context to the library user. The need for a higher-order language The requirements of a modular organization and multiple concept definitions make it necessary to allow higher-order expressions in the ontology specification. The principle of modularity requires that the more generic aspects of a concept are defined in a core library theory, while the more domain- or method-specific aspects of those concepts are defined in a more peripheral theory. To take the previous example, assume that in a core theory causes is defined as a binary relation that takes states as arguments: causes(, ) For some method in some domain, the definition of the causal relation needs to be augmented with a notion of time delay. The typical first-order solution to do this would be to add a third parameter to causes:

76

The Role of Ontologies in Knowledge Engineering causes(, , )

It is clear that the introduction of an extra parameter violates the earlier mentioned minimal interaction principle, and thus the principle of modularity. The addition of the time delay parameter leads to the destruction of the internal structure of the generic definition of causes, with the result that all the definitions that rely on the definition of causes also need to be updated. To avoid this, the domain- and task-specific specializations must be specified by means of higher-order expressions, such as the following, where causes-tuple refers to a tuple in the extension of the causes relation: time-delay(, ) Unfortunately, allowing higher-orders introduces some well known difficulties. Firstly, higherorder languages are not decidable, thus it is impossible to have a system that can prove the internal consistency of the ontological theories. Secondly, the use of a higher-order language introduces the risk of self-referential sentences and the paradoxes that they give rise to. Since the language will be used for library construction, and not for reasoning, we allow the modularity argument to prevail.

5.3.2

Basic Categories of Medical Domain Knowledge

This section describes the core part of the library, which contains definitions that are considered reusable across many medical domains and medical tasks. Fig. 5.2 shows a part of the theory structure of this section of the library, in the form of a theory-inclusion graph. The nodes in the graph represent ontological theories, and the edges denote inclusion relations. Each arrow points from an including theory to an included theory. If a theory includes another theory, this means that all the definitions in the included theory are also available in the including theory. 5.3.2.1

Criteria for partitioning definitions

The decisions about the partitioning of definitions into theories are based on two considerations which we describe further below: (i) the definitions are to be centered around some “natural categories”, and (ii) the number of theory inclusions must be kept to a minimum. Center definitions around natural categories The main criterion for partitioning the definitions into theories is based on the observation that there are some, but not too many, basic categories of medical knowledge. These categories are natural in the sense of Rosch (1973), in that they reflect a social consensus that exists in the medical community. Examples of natural categories in the medical domain are concepts such as patient, disease, therapy etc. These concepts provide a coherent body of terminology that allows medical professionals from different specialties to communicate. These categories recur in almost all medical literature, and they often provide starting points for information analyses for software development. The natural categories are used as anchor points for modularizing the core library. For instance, the theory diseases is centered around the concept of disease, which is represented as an Ontolingua class. On the instances of this class several relations are defined. These definitions, such as disease-etiology and disease-location, are also located in the diseases theory, since they have no meaning independent of the meaning of disease. The current


77

Figure 5.2: Theory inclusion graph of the theories defining the basic categories of medical knowledge. Each node in the

graph represents a theory, with its own set of definitions.

organization of the domain theories, as shown in Fig. 5.2, is based on the knowledge categories that are distinguished in a number of existing expert systems (e.g. M-KAT; Lanzola & Stefanelli, 1992, and ABEL; Patil, 1981). Minimization of the number of inclusions An agent that commits to a particular theory necessarily also commits to the theories included by that theory. Therefore, organizing the theories in such a way that a theory includes few other theories, reduces the overhead of committing to that theory and allows a more flexible use of the library. Therefore, the second criterion used to partition the definitions into theories is that the number of inclusion links must be kept to a minimum. A theory must include, directly or indirectly, the minimal set of theories that it presumes. For example, the concept disease, which is defined in diseases, is a subclass of clinical-process, which is defined in fundamental-medical-concepts. Therefore, it is necessary that diseases includes fundamental-medical-concepts. As depicted in Fig. 5.2, two indirect inclusion paths connect clinical-environment, defining concepts related to the context in which medical activities take place, to diseases. The classes therapy and test are defined in separate theories, enabling external agents to commit to one of the theories without committing to the other. However, because both theories include diseases, all agents committing to one of the two theories must commit to the same definition of diseases.

78


For this reason it is important to avoid ontological overcommitment. In the core part of the library only general characteristics of the concepts should be defined, more specific characteristics should be defined as domain- or method-specific extensions in the peripheral areas of the library. 5.3.2.2

Contents of the core library

Table 5.1 contains brief descriptions of some of the theories in the core library which is shown in Fig. 5.2. As an example, Fig. 5.3 shows the Ontolingua definition of the class observable which is defined in the theory findings. The sentence labeled as :axiom-def expresses that observable is a subclass of human-body-state-variable, which is defined in the theory fundamental-medical-concepts. The:axiom-constraints sentence defines four possible subclasses of observable. The difference between the :axiom-def and :axiom-constraints sentences is that the former are considered to be definitional while the latter are assertional (for an explanation of the difference, see Gruber, 1992). The terms, subclass-of and subclass-partition are defined in the Frame ontology. The principle behind the core definitions is that these should be minimal. For example, stating that an observable is associated with a quantitative value set (the possible values of the observable are numbers) would be an ontological overcommitment, as this is not likely to hold for every application. Therefore, such a qualification should be defined as an extension. (define-class OBSERVABLE (?observable) "An observable is a state-variable whose values can - contextually indicate pathological or physiological states which can be observed. They can be classified according to the way they are obtained." :AXIOM-DEF (subclass-of observable human-body-state-variable) :AXIOM-CONSTRAINTS (subclass-partition observable (set-of sign symptom laboratory-observable special-investigation)))

Figure 5.3: The Ontolingua definition of the notion of “observable”. Ontolingua definitions consist of the name of the defined concept, a number of instance variables, and sets of labeled sentences. The sentence labeled as :axiom-def defines that observable is a subclass of human-body-state-variable, which is defined in fundamentalmedical-concepts. The :axiom-constraints sentence defines four possible subclasses of observable. For details of the Ontolingua language, see (Gruber, 1993).

5.3.3

Method- and Domain-Specific Extensions

The categories described in the previous section are considered basic, in the sense that they are more or less standard across medical tasks and medical domains, and form a generally agreed upon body of terminology in the medical field. We have already mentioned that this set of theories, while relatively small, still allows for alternative definitions. In the core part of the library, the definitions are very general, in the sense that they allow for further specialization according to application specific requirements. We will now describe the more application dependent parts of the library. Applications may vary on two attributes: (i) the domains that they reason about, and (ii) the tasks that they perform and the methods that they use.


Theory generic-concepts

fundamental-medical-concepts

anatomy physiology

findings drugs surgeries

clinical-state-abstractions

diseases

79

Characterization of contents Defines basic notions such as system, process, action from an “engineering” point of view. For example, a system is conceptualized as a collection of interconnected components characterized by states and processes. Contains definitions of basic notions useful for medical knowledge representation, such as human-body and medical-agent. The definitions in this theory specialize notions defined in genericconcepts. For example, human-body is a subclass of the class system, i.e. it is conceptualized as a class of complex entities describable through states and concerned with physiological or pathological (e.g. clinical) processes. Define ontological categories such as anatomical-part, physiological-process and organ that are generally used in medical contexts. The definitions are mostly based on the work of Patil (1981). Define and classify respectively observable findings, conceptualized as values on state variables that indicate the clinical state of a patient, drugs and surgical interventions. They are useful for mapping knowledge modeling ontologies onto “information ontologies” underlying the patient medical-record structure. Defines concepts for representing clinical states in compact ways, for instance, to synthesize a set of patient findings. This theory defines, for example, (i) qualitative-clinical-state-abstraction expressed using symbolic values such as “low” or “high”, and (ii) quantitative-clinical-state-abstraction expressed using numerical values (e.g. a measure such as the body surface computed from body weight and height). Defines a disease as a clinical process whose evolution can be described through finding or clinical abstraction-values over time, and tries to define taxonomies, used commonly in medical practice, based on diseases characteristics such as time evolution characteristics (e.g. “acute”, “chronic”), etiology and location.

Table 5.1: Characterization of some theories in the core library as shown in Fig. 5.2 and described in (Falasconi &

Stefanelli, 1994).

80


Reuse of domain-specific concepts across domains At first glance, the reuse of domain-specific concepts across domains seems a contradiction in terms. However, domain-specificity is not a dichotomy: some concepts are obviously more domain specific than are others. For example, the concept of “fungal skin infection” is more specific than that of “dermatological disease”, while both are more specific than “disease”. This observation can be used to organize the library in such a way that more reusable concepts are put in other theories than less reusable concepts. To do this, the notion of domain specificity must be operationalized. One candidate for this operationalization is the notion of abstraction level: definitions that specify less detail are often less domain specific than definitions that specify more detail. However, there are some problems with this operationalization. Firstly, the relation between more abstract and less abstract definitions is a many to many relation. A concept which is specified in detail can have multiple abstractions, depending on the point of view that one takes. This makes it difficult to specify the inclusion relations between theories which contain detailed definitions and theories which contain abstract definitions. In principle, a theory containing detailed definitions should include all the theories that contain abstract definitions of the same concept. However, this would violate the criterion that the number of inclusion relations should be kept to a minimum. A second problem with an organization according to the level of abstraction is that this dimension does not discriminate between concepts on the same level of abstraction. For example, concepts such as ischemia and glaucoma, which are on the same level of abstraction, are likely to be reusable under different circumstances. An organization along the dimension of abstraction level would not make this explicit. Issues such as the ones mentioned above make it clear that there are many unsolved problems with respect to the organization of a library in such a way that concepts that are likely to be reused under the same circumstances are stored in the same theory. Therefore we have adopted a pragmatic approach. Taking the division of medical practice as a starting point, every concept in the peripheral part of the library is associated with a domain-specificity value. The domain-specificity attribute indicates to what subdomain, or set of subdomains, a concept applies. To decide on the domain-specificity of concepts, a hierarchy of medical specialties is used. Each of the nodes in this hierarchy represents a medical subdomain that may be used as a value for the domain-specificity attribute of a concept. When a concept has a particular domain as its domain-specificity value, it is specific for that domain, but it is reusable across all its subdomains. The domain hierarchy reflects the existing organizational structure of medical practice. Example elements of the hierarchy are disciplines such as immunology, pathology, internal medicine and its specializations, etc. Of course, the organization of medical practice varies between countries. Therefore, the structure of peripheral parts the library is to a certain extent situated. This is another motivation for distinguishing between a “universal” core library and situated extensions of that core. Fig. 5.4 shows a part of the domain hierarchy. Reuse of method-specific concepts across methods and tasks According to the interaction problem, the way in which knowledge is represented is necessarily highly interwoven with the way that that knowledge will be used in reasoning. Therefore, it is difficult to reuse knowledge that is defined with a particular method in mind, for another method. Taken literally, the interaction problem precludes the reuse of concepts across methods. In this section it will be argued that the interaction problem does not hold to the same extent for every concept, and it will be shown that the degree of method-specificity of concepts can be used as an index to organize the ontology library.


81

medicine

internal medicine

medical pharmacology

cardiovascular medine

ophthalmology

heart diseases

...

...

psycho anesthesiology pharmacology

...

...

...

Figure 5.4: A part of the domain hierarchy for the medical field. The hierarchy reflects the organization of the medical

practice.

It has been argued elsewhere (Ramoni et al., 1992) that there are three fundamental tasks in medical reasoning: diagnosis, therapy planning and patient monitoring. Furthermore, it has been shown that at least two of these generic tasks can be modeled as instantiations of one inference model: the select and test model, or STModel. Fig. 5.5 shows the instantiation of this model for medical diagnosis. The model, which is based on the work of the philosopher Peirce, distinguishes four fundamental reasoning steps: data abstraction, abduction of hypotheses, deduction of predictions, and inductive verification of the predictions. The model also distinguishes two additional activities: deciding in which order the hypotheses will be tested (ranking) and requesting new data.

ranking

hypotheses

abduction

problem features

induction

deduction

abstraction expected/ observed data

request new data

Figure 5.5: The generic STModel, instantiated for medical diagnosis.

Each of the inference steps in the STModel can be realized trough a number of methods, and

82


each of these methods may have specific ontological requirements. For example, the abduction of hypotheses from patient findings can be done by interpreting direct associations between findings and diseases. This method thus has the ontological requirement that such associations exist. The following production rule is an illustration of this kind of abduction: IF chest-pain = present AND sustained-pain = yes THEN myocardial-infarct = probable

In some systems that perform abduction by direct associations, the associations are qualified with certainty factors, representing the likelihood that the disease is the cause of the findings. This is, for example, the case in MYCIN (Shortliffe, 1979). Using this method thus introduces another ontological requirement. Alternatively, the diseases that may cause a particular finding could be found by tracing pathways in causal networks — a method which requires the existence of causal connections in the domain. For specific methods, the causal links in such networks may need further qualification. For instance, CHECK (Console et al., 1993), a system for abductive diagnosis, makes a distinction between necessary causal connections and possible causal connections. Another example of this is provided by causal-probabilistic networks, where the causal relations are quantified through probability distributions. Based on the ontological commitments that they require, the methods employed in medical reasoning can be organized in a specialization hierarchy. Descending this hierarchy introduces additional ontological commitments. Fig. 5.6 shows a part of the method hierarchy for abducting diseases from findings in medical diagnosis. The concepts of disease and finding, which are used by all methods for medical abduction, are defined in the core library. The manifestation-of relation, which models direct associations between findings and diseases, is specific for methods that are specializations of “abduction by direct associations between findings and diseases” (method 2.1 in Fig. 5.6). Further specializations of these methods may require additional ontological commitments, such as the existence of certainty factors or evoking strengths for these direct associations. The level of the method hierarchy where an ontological requirement is introduced, is an indicator for the method-specificity of the corresponding concept. In the same way that the domain hierarchy is used to associate concepts with domain-specificity attributes, the method hierarchy is used to assign a method-specificity values to concepts. It should be emphasized that the organization of methods according to the ontological commitments that they introduce is only one possible way of organizing problem solving methods. For the purpose of the ontology library, this organization is suitable because the hierarchy will be used for retrieving the definitions that are required by the methods. However, we do not claim that we have solved the problem of indexing problem-solving methods.

5.3.4

Structure of the Library

Sec. 5.3.2 argued that there are basic categories of medical knowledge that are reusable across all medical domains and medical tasks. These categories form the core part of the library, and they are organized in theories according to the criteria mentioned earlier. Two attributes determine the degree of reusability of a concept: the domain-specificity and

Chapter 5: Principles for Ontology Library Construction medical diagnosis

task has inference

inferences

1 abstraction of findings from data

has inference

2 abduction of diseases from findings

implemented-by

2.1 abduction by direct associations between findings and diseases

inference methods

83

has inference

has inference

3 ranking hypothesized diseases

4 deduction of predictions from hypothesized diseases

...

implemented-by

2.2 abduction by tracing causal pathways between findings and diseases

has-specialization

2.2.1 abduction by traversing causal links with possible and necessary causal connections

has-specialization

2.2.2 abduction by bayesian probability propagation

Figure 5.6: Partial Hierarchy of methods used in medical diagnosis.

the method-specificity. For the definitions in the core part of the library, these attributes are not discriminating, as they are intended to be reusable across most medical domains and methods. However, this is not the case for the definitions in the extended part. By making the value of concepts on these attributes explicit, it is possible to determine to what extent and under which circumstances these concepts can be reused. Since concepts that have the same values on both attributes are likely to be applicable under the same circumstances, they should be stored in one theory. In this way the attributes provide a scheme for modularization. For every combination of a node from the domain hierarchy and a node from the method hierarchy, there can be a theory in the library. This theory contains the definitions that are specific for the method and the domain, but that are reusable across the specializations of the method and subdomains of the domain. For instance, the theory “abduction by tracing causal pathways between findings and diseases in the domain of cardiovascular medicine” would contain all the definitions that are specific for that method in that domain (e.g. artery-obliteration), but it would not specify that there are probability distributions that describe the nature of the causal connection between pathophysiological states, since these are specific for one particular specialization of the causal tracing method (see Fig. 5.6). The theory would also not contain a definition of pathophysiological state. Since this concept is reusable across a wider range of domains than cardiology, it is defined in the core library. Fig. 5.7 shows the organization of the peripheral part of the library by example. The dashed arrows in this figure represent the values on the domain-specificity and method-specificity indexes. The arrows in the two hierarchies represent specialization relations. Thus, cardiovascular medicine is a specialization of internal medicine and “abduction by traversing causal links with possible and necessary conditions” is a specialization of “abduction by tracing causal pathways between

84


findings and diseases”. Concepts with the same method specificity and the same domain specificity are stored in the same theory. Retrieving concepts from the library thus amounts to indicating the domain(s) and the method(s) that are relevant for the application and then collecting the theories that have the domain(s) and method(s) — or their parents in the hierarchy — as indexes. domain hierarchy

core library

method hierarchy

theory: physiology

medicine

physiological process

medical method

peripheral library theory: p-1

pathophysiological state internal medicine

ophthalmology cardiovasular medine

theory: p-2

artery obliteration

abduction by tracing causal pathways between findings and diseases

abduction by direct associations between findings and diseases

theory: p-3

coronary obliteration ...

abduction of diseases from findings

heart diseases

abduction by traversing causal abduction by links with possible bayesian probability and necessary propagation causal connections

Figure 5.7: The organization of the peripheral parts of the library. The dashed lines show how the theories in the

peripheral library are indexed on domain specificity and method specificity. The arrows in the two hierarchies represent specializations. Thus, cardiovascular medicine is a specialization of internal medicine and “abduction by traversing causal links with possible and necessary causal conditions” is a specialization of “abduction by tracing causal pathways between findings and diseases”. Concepts are stored in the theories with the same values on the domain- and methodspecificity attributes.

5.4 Building the Library The previous section described the principles of organizing the library of medical ontologies. Here, the issue of filling the library is addressed. Because this involves a large amount of work, only a prototype library is being developed in the GAMES-II project. Rather than aiming at completeness, the project focuses on formulating standardized procedures for adding new definitions to the library. The availability of standardized procedures will make it easier to augment the library and it will enable the development of tools for semi-automatic library maintenance. The currently used procedure consists of four steps: (i) take an existing medical AI application, (ii) describe the ontology and the inference methods of the system, (iii) score the definitions in the ontology on the domain-specificity and method-specificity attributes, and (iv) put the definitions in the appropriate library theories. The next sections will elaborate and illustrate each of these steps.

5.4.1

Start with an Existing Application

The definitions that are most likely to be usable for medical KBS development are the definitions that are already employed in existing systems. Therefore, the initial library is based on analyses of such systems. In this chapter CASNET (Weiss et al., 1984) will be used as an example. CASNET


85

allows the representation of causal associational networks that describe processes of diseases and has been used to build an application for diagnosing glaucoma. CASNET was chosen as an example for several reasons. Firstly, as a shell it provides a framework for developing applications in various medical domains. Therefore it is likely that its domain ontology is a good candidate for reuse across domains. Secondly, in addition to this general causal network ontology CASNET provides idiosyncratic ontological distinctions required by CASNET’s reasoning methods. This combination of properties makes CASNET an attractive illustration for developing method-specific extensions to the library. To illustrate the idea of domain-specific extensions, we have added the concept glaucoma, which was used in the glaucoma application developed with CASNET, to CASNET’s ontology.

5.4.2

Model the Application

It is often the case that existing medical KBS do not have explicit descriptions of the underlying domain ontologies. In these cases, it is up to the library builders to define such an ontology. This is done in three steps: (i) scoring the current application on the domain-specificity and method-specificity attributes, (ii) retrieving the concepts from the library that could be useful for modeling the ontology of the application and (iii) defining the additional concepts necessary for the application’s ontology. As described in Sec. 5.3, the possible values of the domain-specificity and method-specificity attributes are specified in the corresponding hierarchies. CASNET is a general shell for medical applications, but since we have added the concept glaucoma, the system is assigned the value “opthalmology” on the domain-specificity attribute. For the method specificity, we concentrate on the abduction step. CASNET uses a causal network for abduction, so “abduction by tracing causal pathways” is selected as the value for the method-specificity attribute. Actually, CASNET uses a specialization of this method, but as yet this specialization — which we will call the CASNET method — is not represented in the method hierarchy. When the application is scored on the method-specificity and the domain-specificity attributes, the concept definitions that are already available in the library can be retrieved. To complete the application ontology, the library builder has to define the additional classes, relations and functions required for the application. For the purpose of library construction, these newly defined concepts are the important ones. Because the method actually used by CASNET is not in the method hierarchy, the library builder also has to model the method of the system. CASNET’s application ontology Applications built with CASNET have an explicit representation of a network, the nodes of which represent pathophysiological states. The links in the network represent causal relations between the states. States are labeled with a confirmation status, which must be one of confirmed, denied, or uncertain. The evidence for the confirmation status of a state comes from patient observations. A specific state of the network is interpreted in terms of diseases in various states of progression. Fig. 5.8 presents parts of the reconstructed application ontology of CASNET in the form of an ontological semantic network (Abu-Hanna, 1994). There are three types of definitions in the application ontology: (i) definitions retrieved from the core library, (ii) definitions retrieved from the peripheral library and (iii) new definitions. The concepts retrieved from the peripheral library are specific for the causal tracing method, but generic across all the different specializations of causal tracing. None of the concepts that were retrieved from the opthalmology specific

86

The Role of Ontologies in Knowledge Engineering causation strength

n.

Wl

n.

inverse weight (n.)

strength (n.) c.l.

disease n.

causes (c.l.) classifies (p.l) n. glaucoma

n.

p.l.

path

begins (p.l.)

Wf

forward weight (n.)

Wi

n.

confidence measure

n.

weight (n.)

costs (n.)

confidence (n.)

p.l. pathophysiological state

cost

evidence-for (p.l.)

c.l. observation

terminates (p.l.) summarizes (p.l)

c.l. symptom

c.l.

history

labeled-as (n.) p.l. start pathophysiological state

p.l. end pathophysiological state

has frequency (n.)

n.

a-priory frequency

c.l. n.

status

c.l.

sign

c.l. lab-test

event

thresholded by (n.) n.

threshold

legend c.l.

object

concept retrieved from the core library

A

p.l.

object

concept retrieved from the peripheral library

A

n.

object

newly defined concept

A

relation (c.l.) relation (p.l.) relation (n.)

B relation between A and B

retrieved from core library

B relation between A and B retrieved from peripheral library

B newly defined relation between concept A and concept B.

B

A is a specialization of B.

A

Figure 5.8: The application ontology of CASNET represented as an ontological semantic network.

extensions were used for the application ontology. As mentioned above, the newly defined concept glaucoma was added to the application ontology as a subtype of disease. To decide on the method specificity of the newly defined concepts, the CASNET method must be modeled for analyzing the ontological requirements of the method. CASNET’s inference methods The analysis of CASNET’s inference methods is based on the STModel (see Fig. 5.5). We will describe the methods for abduction and for ranking. As mentioned, “CASNET abduction” is a specialization of “abduction by tracing causal pathways between findings and diseases”. The method consists of three primitive procedures. The first of these uses the evidence links between observations and states and their associated confidence measures to compute the confidence measure of the state. The second procedure then labels the states with confirmed, denied or undetermined by applying a threshold to the confidence measure of the states. Finally, the third procedure classifies paths of labeled states with no denied states as diseases. The problem-solving method that CASNET uses for the ranking inference (Fig. 5.9b) consists of two procedures: weighing the evidence for the hypothesized diseases and ranking the diseases according to the weights of the evidences. The weighing procedure consists of three steps, which use the strengths of the causal relations between the states. The total weight of a state is the maximum of the forward and the inverse weights. The forward weight of a state summarizes the


87

weight of the evidences coming from the causes of that state. The inverse weight summarizes the weight of the evidences coming from the effects of the state. When the status of a state is undetermined, the starting state’s a-priori frequency is used for the calculation of its forward weight. The procedure that ranks states (hypotheses) uses the ratio of the weight of the hypothesis and the costs of testing that hypothesis. Fig. 5.9 shows the methods that perform the abduction inference (Fig. 5.9a) and the ranking inference (Fig. 5.9b). The figure also shows some of the ontological commitments that are required by the method. inferences

Ranking

hypotheses

Abduction

ranking by weight to cost ratio

CASNET abduction

weigh state likelihood in path

rank according to weight to cost ratio

inference methods calculate state confidence

method oriented ontology

label states according to threshold

confidence measure

confidence

interpret labeled states

threshold

thresholded-by

(a)

weigh forward evidence

a-priory frequency

has frequency

W

weigh inverse evidence

f

forward weight

W

maximize evidence

W

l

inverse weight

cost

i

weight

costs

(b)

Figure 5.9: The inference methods used in CASNET for abduction of hypotheses (a) and ranking of hypotheses (b).

5.4.3

Scoring the Definitions

When the ontology of the application has been specified, the newly defined concepts must be indexed and stored in the library. In the case where the core library is largely complete, this is not difficult. The newly defined concepts are then all method or domain specific, and must be stored in the peripheral part of the library. In the case where the core library is also incomplete, the indexing is more difficult. In that case the library builder has to decide whether the definition represents a basic category of medical knowledge, or whether it is a method- or domain-specific extension. The procedure to follow in this situation is based on the principle that the concepts in the core library are intended to be reusable across many tasks and domains. If the library builder estimates that this is true for a concept under consideration, it is stored in the core library, otherwise it is considered as an extension. Of course, the subjective estimates of the library builder are not error-proof, but at present this is the only method available. One of the assumptions that underly this approach to library construction is that there are only a small number of truly basic categories of medical knowledge, so that it is likely that the current core library is already more or less complete. For CASNET, scoring the definitions on the method-specificity attribute amounts to deciding whether the concepts that are newly defined in Fig. 5.8 are all specific for the inference methods

88


of CASNET and not for their parents in the method hierarchy. Again this requires a subjective estimate of the library builder. After inspecting how the new concepts relate to CASNET’s methods (see Fig. 5.9) it is decided that the newly defined concepts are specific for the methods employed by CASNET, except for glaucoma. Because glaucoma does not add method-specific aspects to the definition of its super concept, the core library concept disease, it is assigned the value “medical method” on the method-specificity attribute. “Medical method” is the root of the method hierarchy. The concepts must also be scored on the domain-specificity attribute. In the general case, this requires medical expertise. For the current application, deciding on the domain specificity of concepts is straightforward because CASNET was developed as a general shell for medical applications. Therefore, all the concepts — except glaucoma — get the value “Medicine” on the domain-specificity attribute, which is the root of the domain hierarchy. glaucoma is assigned the value “glaucoma management”. In summary, glaucoma is indexed as “specific for the domain of glaucoma in all medical methods”. The other newly defined concepts that are used for abduction in CASNET (e.g. confidence-measure and threshold) are indexed as specific to “CASNET abduction in medicine”. Fig. 5.10 shows how the newly defined concepts are scored on the method-specificity attribute.

5.4.4

Storing the Definitions in the Library

When the definitions are scored, they must be stored in the proper parts of the library. For the new concepts with the domain-specificity value “Medicine” and the method-specificity value “CASNET abduction” or “CASNET ranking”, two new theories are created in the library: “CASNET abduction in medicine” and “CASNET ranking in medicine”. For glaucoma, the theory “glaucoma management in medical methods” is added to the library. Because “glaucoma” was not yet part of the domain hierarchy it is added as a specialization of opthalmology. Finally, the methods employed by CASNET must be added to the method hierarchy. For example, “CASNET abduction” is added as a specialization of “abduction by tracing causal pathways between findings and diseases”.

5.5 Using the Library This section explains how the library can be used for constructing a part of the application ontology of a KBS. Basically, this amounts to classifying the domain of the application in terms of the domain hierarchy and specifying the methods that the application will use in terms of the method hierarchy. When a domain or a method is not in the hierarchy, the most specific “super domain” or “super method” must be used. For example, if one is building an application in the field of cardiovascular medicine and the domain hierarchy does not have an entry for this domain, internal medicine should be used instead (see Fig. 5.4). When the application is scored on the indexes, the library can be used to collect the concepts that are likely to be useful for the application. The peripheral theories that are included in the application ontology must satisfy two criteria. Firstly, the theories must have a domainspecificity index that is equal to — or subsumes — the domain-specificity value of the application. Secondly, the theories must have a method-specificity index that is either equal to — or subsumes — the method-specificity values of the application. For example, for a system that uses the method “abduction by tracing causal pathways between findings and diseases” in the domain of


W

W

l casnet ranking

causation strength casnet abduction

inverse weight W

causes

forward weight

weight glaucoma

path

begins

casnet ranking

casnet abduction

costs

confidence

pathophysiological state

glaucoma

cost

confidence measure

i

casnet ranking

classifies

f

casnet ranking

strength

disease

89

evidence-for

observation

terminates summarizes

symptom

history

labeled-as start pathophysiological state

end pathophysiological state

has frequency

thresholded by

a-priory frequency

threshold

casnet ranking

casnet abduction

sign status

lab-test

event

casnet abduction

legend object

object stored in core library

object

object stored in existing part of peripheral library

object casnet abduction

object casnet ranking

object glaucoma

object stored in ‘‘casnet abduction in medicine’’ object stored in ‘‘casnet abduction in medicine’

relation

relation stored in core library

relation

relation stored in existing part of peripheral library

relation

relation stored in new part of peripheral library

B objects of type A may A

relation

have relation "relation" with objects of type B

B

A is a subclass of B

A

object stored in theory "glaucoma management in medical method"

Figure 5.10: The application ontology of CASNET. The labels associated with the new concepts show the method-

specificity values of these concepts.

cardiovascular medicine, the library would suggest including the theories P-1 an‘ P-2, but not P-3 from Fig. 5.7. For retrieving definitions from the core part of the library, the indexes cannot be used. However, concepts defined in the peripheral parts of the library are often defined as specializations of core ontology concepts. In this case, the peripheral theories and the core library theories are connected by means of inclusion relations. When theories include other theories, the included theories are also automatically retrieved. In cases where core ontology theories are needed which are not retrieved because of the inclusion relations, it is up to the library user to select these theories. For a particular application ontology and a particular reasoning step in the STModel, the reusability characteristics of the definitions can be illustrated in a reusability diagram. Fig. 5.11 shows such a diagram for abduction in an application that diagnoses heart diseases. The domainspecificity axis of the diagram is constructed by starting from the specific domain in the domain hierarchy, and then moving upwards through the domain hierarchy. Each of the parent nodes in the hierarchy is used as a value on the domain-specificity dimension. The method-specificity axis

90


is constructed in a similar way, using the method hierarchy. methodspecificity

domain + method specific extensions pathophysiological state

abduction by tracing causal pathways

abduction of diseases from findings

method independent definitions

disease-path

core library state

disease

event

observation

artery

arteryobliteration

coronaryobliteration

sign labtest

domain-specificity generic concepts

fundamental medical concepts

internal medicine

cardiovasular medicine

heart diseases

Figure 5.11: A diagram showing some definitions that are suggested for inclusion in the application ontology of a system

that diagnoses heart diseases. The positions in the diagram reflect the locations of the definitions in the library.

The region at the lower left part of the diagram contains the definitions that are retrieved from the core part of the library, which was described in Sec. 5.3.2. The definitions that are both method independent and generic are retrieved from the theory generic-concepts. For the other definitions in this region, the positions in the reusability diagram do not reflect from which theories they originate.

5.6 Discussion The starting point of the work presented here is the observation that, although the potential merits of libraries of reusable ontologies are widely recognized, there are few libraries available today. Ontology libraries could provide building blocks for an application ontology, which is a specification of all the ontological distinctions that are required to perform a particular task in a particular domain. Two reasons were identified to explain the unavailability of such a library: the hugeness problem and the interaction problem. This chapter presents an analysis of these problems in the context of medical knowledge, and suggests ways to make them manageable. In short, the interaction problem is addressed by the introduction of a method-specificity attribute for concepts, based on a classification of inference methods. To the hugeness problem there are two aspects: the large number of concepts makes building the library a daunting exercise, and it also complicates retrieving the appropriate concepts when they are needed. Building a full library is beyond the scope of this thesis. Instead, we have concentrated on the formulation of procedures for augmenting an initial library. The other aspect of the hugeness problem is addressed by the introduction of a domain-specificity attribute, similar to the method-specificity attribute. Based on this analysis and an analysis of the intended use of the library, three principles have been identified that can be used to impose a structure on an


91

ontology library: organizing concepts according to (i) natural categories, (ii) inference methods, and (iii) domain division in practice. The first of these principles advocates structuring ontologies of medical knowledge according to “topics” that often recur in medical practice. These general categories are located in the core part of the library. The importance of this organizational principle is that it provides anchors for the more specialized concepts in the other part of the library, thereby ensuring that concepts that are defined in different ways for different methods or subdomains, have at least some common ground. The second principle says that inference methods should be used as an index for the ontological distinctions that they introduce. This facilitates the construction of application ontologies because it is easy to find out which domain concepts are required for a particular inference method. The third principle suggests that domain concepts that are specific to a particular branch in medical practice should be indexed by that subdomain. This facilitates the construction of application ontologies because it can be used to suggest concepts that are specific for problem solving in that domain, and it also suggests what kinds of external knowledge will be available in the runtime environment of the KBS. A crucial underlying assumption of this work is that it is indeed possible to score medical applications within the framework presented. The justification of this assumption depends on how well the medical field fits in the mold provided by the above-mentioned principles. For the applications that we have studied so far, this assumption seems to be reasonable. The assumption is also likely to hold for applications built using the now prevailing “knowledge modeling” KBS development paradigm. These approaches provide meta-level descriptions of a knowledge base that can be used for indexing. In particular, applications built through explicit mappings between domain, method-specific and application ontologies, such as advocated by the CommonKADS methodology (Wielinga & Schreiber, 1993) will lend themselves to library construction and use. The PROTE´ GE´ -II approach (Tu et al., 1995), makes similar distinctions, and it is to be expected that libraries of the kind described in this chapter will also be usable within that framework. In the ´ GE´ -II framework, application ontologies are developed by augmenting a domain ontology PROTE with method-specific distinctions. Explicit mappings are then defined between the application ontology and a method ontology. The method ontologies, which are specific for the methods in ´ GE´ -II ’s method library, are reusable, as is the domain ontology. The use of the methodPROTE specificity index in the GAMES library could be viewed as a way of explicating when which method-specific distinctions should be added to the domain ontology. The work presented in this chapter is closely related to efforts to standardize medical terminology. An interesting future research issue would be to relate a library such as the one described in this chapter to the semantic network of the UMLS. A library would benefit from such a mapping because the automatic classification of terms would make it easier to locate concepts in the library. On the other hand, the GAMES library would impose a richer structure on the semantic network, which would make it easier to connect the knowledge in the UMLS to problem-solving methods.

92


Chapter 6

CUE: Ontology-Based Knowledge Acquisition This chapter presents CUE, a knowledge engineering workbench that is based on the use of explicit ontologies in knowledge acquisition. Three of the tools that are part of the workbench are described in detail. The first of these, QUITE is an editor that supports the development of task models. The second, QUOTE, is an editor for the definition of ontologies. QUAKE, the third tool exploits the ontologies defined with QUOTE to elicit domain knowledge in a focused way. In the context of QUAKE an analysis of possible knowledge-elicitation strategies is presented. Finally, the strengths and weaknesses of CUE are discussed and the system is compared with other knowledge acquisition environments. In the context of this thesis, this chapter describes how explicitly defined ontologies can be used to provide guidance in the knowledge acquisition process and which information must be available in the ontology to do this. The chapter is an extended version of the second part of a paper presented at the European Knowledge Acquisition Workshop 1994 (EKAW ’94), and is co-authored by Guus Schreiber. the reference is: G. van Heijst and A. Th. Schreiber (1994). CUE: Ontology based knowledge Acquisition. In Steels, L., Van der Velde, W., & Schreiber, A. Th., editors, Proceedings European Knowledge Acquisition Workshop EKAW’94, Heidelberg/Berlin. Springer Verlag.

6.1 Introduction The analysis in chapter 3 of the state of the art with respect to tools that support the model-based knowledge acquisition paradigm shows that there is an emerging theory of the various activities in this process and of the ways in which tools can support these activities. This chapter presents CUE as a KA environment that operationalizes this theory. Many of the ideas behind CUE are thus not new, but are just an explicit integration of principles that underly existing tools. CUE was developed as a testbed for extending this emerging KA process theory, in particular in the areas of (i) exploiting a library of ontologies such as the one described in chapter 5, and (ii) the exploration of the notion of knowledge-elicitation strategies. The library of ontologies acts as a repository of previous knowledge engineering experiences, and enables the knowledge engineer to reuse descriptions of the structure of domain knowledge that have proven useful in the past. Knowledge-elicitation strategies are principles for organizing the knowledge-elicitation dialogue, and present an alternative for existing techniques that either have predefined dialogue structures or leave navigation to the user. The immediate context in which CUE is developed is the GAMES approach. As argued in chapter 2, knowledge modeling in this approach consists of four activities: building a task model, 93

94


building an application ontology, mapping the task model onto the application ontology and instantiating the application ontology (see Fig. 2.4). Table 6.1 shows the CUE tools that support these activities. Modeling Activity

CUE Tool

Construct task model for application Construct application ontology Map task model onto application ontology Instantiate application ontology

QUITE QUOTE QUITE QUAKE

Table 6.1: The activities in constructing the epistemological model that are distinguished in the GAMES approach, and

the CUE tools that support these activities.

Sec. 6.2 presents a global overview of how the CUE tools are intended to be used in the KA process. Sec. 6.3 describes the two tools that support skeletal model construction in CUE: QUITE, a task modeling editor and QUOTE, an editor for ontologies in Ontolingua. Sec. 6.4 describes QUAKE, a tool that exploits the skeletal models developed with QUITE and QUOTE to elicit domain knowledge in a focused way. In the context of QUAKE an analysis of possible knowledge-elicitation strategies is presented. In Sec. 6.5, CUE is compared with KEW, PROTE´ GE´ -II and DIDS, and some strengths and weaknesses of the system are described. This chapter only describes CUE’s facilities for supporting model construction and model instantiation. Chapter 7 describes how CUE could support model compilation. The current version of CUE does not support model refinement, the fourth activity of the model based knowledge acquisition paradigm.

6.2 Steps in Epistemological Modeling To help understand why the different tools have their specific functionalities, this section presents an analysis of the different steps in the GAMES epistemological modeling process in the form of a generic scenario. In principle, each of the steps should be supported by a knowledge engineering workbench. The scenario is based on the activities mentioned in Table 6.1, but some activities are divided into multiple steps because different support facilities are needed. 1. Informally describe domain and task of the application. KBS development always starts with getting an initial picture of the kind of application that is required. This typically requires talking to managers and domain experts, reading some publications about the field etc. 2. Identify generic tasks Based on the informal domain and task description, the knowledge engineer then constructs an initial version of a task model. This model — a configuration of generic-task instances — is underspecified: it only models the high-level structure of the reasoning task that the application should perform. In GAMES the control structure is not considered as a part of the epistemological model and primitive inferences are formulated on a fairly abstract level. Because of the strong assumptions about the structure of generic tasks (the STModel), the task model still gives guidance about the types of domain knowledge that are needed.

Chapter 6: CUE: Ontology-Based Knowledge Acquisition

95

3. Specify which parts of the task must be automated. Usually, only some parts of the reasoning process will be performed by a KBS. This should be specified in the task model. 4. Construct the application ontology. For constructing the application ontology, GAMES provides the ontology library. As described in the previous chapter, the library is indexed by domain and by methods. by specifying the domain and the method, the library can be used for retrieve concept definitions that are likely to be useful in the application ontology. If there is no entry for the domain in the library, constructing the application ontology requires more creativity from the knowledge engineer.1 5. Specify the role-to-role mappings. When the application ontology has been built, the task model can be completed. This involves specifying which knowledge roles are shared between the generic-task instances, by means of role-to-role mappings. 6. Map task model onto ontology. The connection between the task model and the application ontology must be specified. This can be done by defining ontology mappings. These mappings specify that particular roles in the task model may only be fulfilled by instances particular ontological concepts. Once the mappings have been specified, the skeletal model is completed. 7. Create Elicitation Agenda Now the application ontology must be instantiated. The first step in this process is creating an elicitation agenda — a list of elicitation activities that should be performed. 8. Specify knowledge-elicitation strategy After having defined the elicitation agenda, a knowledge-elicitation strategy may be specified. This can best be viewed as an ordering on the elicitation activities in the agenda. 9. Elicit domain knowledge Finally, the tuples and instances of the relations, functions, and classes in the application ontology should be elicited and saved in a knowledge repository. In principle, all of the steps in the generic scenario should be supported by CUE tools. In the following sections, it will be explained to what extent this is realized in the current CUE implementation.

6.3 Skeletal Model Construction in CUE As mentioned in chapter 2, the skeletal models in GAMES consist of a task model and an application ontology. For both components, CUE contains a tool that supports their construction. QUITE, the task model editor, graphically supports the configuration of STModel instances into a task model for the application. QUOTE supports construction of application ontologies.

6.3.1

QUITE

In chapter 3 it was argued that there are three ways in which tools can support the construction of task models: (i) by providing specialized editors, (ii) by providing libraries of reusable components, and (iii) by providing support for the modeling process. 1

Chapter 8 will present a number of guidelines for acting in this situation.

96


In the context of GAMES, library support is quite easy. Because GAMES task models are configurations of the STModels for diagnosis, therapy planning and patient monitoring, the task modeling library contains only three models. QUITE users can select instances of these STModels and connect them by means of control links and role-to-role mappings. Control links are global indications of the order in which the instantiated STModels must be invoked to perform the application task. They are intended for supporting knowledge acquisition and do not contain sufficient information to drive problem solving. In the GAMES approach, the nitty gritty of task control are specified in the computational model. Role-to-role mappings indicate data-flow between STModel instances. For example, they could specify that diagnostic hypotheses are mapped onto therapeutic problems. QUITE users can specify control links and role-to-role mappings by setting the tool in the appropriate mode and drawing lines between the objects that need to be connected. If the specified links or mappings do not violate syntactical constraints, they are added to the task model. An example of a syntactical constraint is that roles should not be mapped onto roles within the same instance of a generic task. In many cases, the KBS that is being developed will only automate parts of the problem solving process, while other parts remain the responsibility of human agents. QUITE supports this by allowing the user to indicate which of the inferences in the task model will be performed by the application. The other tools in CUE will only attempt to acquire the knowledge required for these parts of the reasoning process. The task model is an informal, high-level overview of the medical reasoning process which fulfills two functions in the remainder of the knowledge acquisition process: (i) providing guidance for constructing the application ontology, and (ii) providing background knowledge for specifying the global control regime when the computational model is constructed. For the first of these purposes, QUITE allows users to specify ontology mappings between STModel components and components of the application ontology. The ontology mapping editors are described in Sec. 6.3.2. For the second purpose, QUITE has extensive documentation facilities: every STModel, knowledge role, inference and mapping in the task model can be documented individually. Fig. 6.1 summarizes the functionality provided by QUITE.

6.3.2

QUOTE

A second tool of the CUE environment is QUOTE. This tool is intended to support the development of application ontologies, either from scratch or by fine-tuning ontological theories selected from the ontology library described in chapter 5. Further, the tool can be used for the development of ontological theories for the library. Levels of support in QUOTE QUOTE supports the definition of ontologies at three levels. The first of these, the ontology level, has to do with the selection of theories from a library to build an application ontology. The graphical interface enables users to get a quick overview of the contents of an ontological theory, without an analysis of the internal details of the definitions. The second level of support is the theory level. QUOTE graphically shows the type constraints that are specified in the definitions of a theory. Whenever a parameter of a relation or a function is not typed, a warning is given.2 QUOTE also warns the user when definitions refer to classes, 2

In principle, nothing is wrong with untyped parameters. Neither Ontolingua nor QUOTE enforce such typing.


97

Summary of QUITE’s functionality

Supported activities from Sec. 6.2 – – – –

2. 3. 5. 6.

Build an initial task model. Specify which parts of the task must be automated. Specify the role mappings. Map task model onto ontology.

Intended users – Knowledge engineers, in cooperation with domain experts

Support Types – Editing facilities – Library support

Input from other tools – For the construction of the task model, QUITE requires no input from other tools. – For the mapping between the task model and the application ontology, QUITE requires an ontology defined in Ontolingua.

Output – A task model – A series of ontology mappings

Theoretical background – Task models can be constructed by configuring STModels for the three generic tasks in medicine: diagnosis, therapy planning and patient monitoring. Figure 6.1: A synopsis of QUITE’s functionality.

relations or functions that are not defined in the theory or its included theories; or when concepts are defined more than once. The third level of support that QUOTE provides is at the level of Ontolingua definitions. The definition editors facilitate the definition of classes, relations and functions by syntax checking, automatic indentation, and by providing direct access to relevant parts of the on-line documentation distributed with Ontolingua. Therefore, every definition that is created or modified in QUOTE is guaranteed to be consistent with the Ontolingua language definition. QUOTE works directly on Ontolingua theories. Theories that are created using QUOTE are saved as Ontolingua files, and thus can be used directly as input for the Ontolingua translators described in (Gruber, 1993). Furthermore, QUOTE can also be used to edit or visualize Ontolingua files that were not created with the tool. For these reasons the tool can also be used outside the CUE framework and independent of the GAMES methodology.

However, the ontologies defined in QUOTE are intended for driving the knowledge-elicitation process,and type constraints on parameters are important for the validation of elicited knowledge.

98


QUOTE’s functionality The functionality of QUOTE will be demonstrated by showing how the tool supports the development of a simple application ontology in the domain of managing graft-versus-host disease (GVHD). It should be emphasized that the application ontology used in this chapter is intended only for showing the functionality of the tools; the ontology for the “real” GVHD application which was developed in the GAMES project is more complicated (Lanzola et al., 1995). When QUOTE is started, the first window that appears is the theory-inclusion-graph viewer shown in Fig. 6.2. This facility can be used to select and load theories from the library. The loaded theories are automatically added to the application ontology. The theory-inclusion-graph viewer visualizes the theories that are part of the application ontology and their inclusion relations. As explained in chapter 5, a theory includes another theory when the definitions in the former depend on definitions in the latter. For example, the theory finding, which contains the definition of the concept finding, includes the theory observable, which defines the concept observable, because findings are defined as expressions about observables. All theories that are part of the inclusion graph in Fig. 6.2 are loaded from the GAMES supplied library of ontological theories.

Figure 6.2: A visualization of the theory structure of an application ontology in QUOTE. The arrows indicate direct inclusion relations. When the user presses the OK button, the theory finding-disease is added to the graph.

In Fig. 6.2, the user is defining a new theory, finding-disease, in which the concepts will be defined that specify how diseases are related to findings in the GVHD domain.3 Since the definitions of these concepts depend on the definitions of findings and of diseases, the theories that contain these definitions are included in the new theory. When the new theory is created, it is automatically added to the theory inclusion graph. The contents of theories can be specified or altered by means of theory editors. The user interface of a theory editor consists of two areas (see Fig. 6.3).4 The upper area contains a number of 3

In reality, finding-disease is also part of the ontology library. We assume here that it must be defined by the knowledge engineer to illustrate the functionality of QUOTE. 4 Actually, there are three areas since every CUE tool has a feedback area at the bottom of the tool. This area is used to provide the users with feedback about the actions that they initiate.


99

browsers which show the classes, relations and functions that are defined in the theory, and one which shows the theories that are imported by the theory. The lower area shows a graphical representation of the structure of the theory. The rounded boxes in the lower area of the tool represent already defined classes, and the rectangular boxes represent defined relations. The texts finding-importance, evoking-strength and frequency represent functions. QUOTE distinguishes between classes that are only intensionally defined and classes for which the instances are enumerated in the definition. We call the latter enumerated classes. The difference between these two types of classes is important because it affects the knowledge acquisition process: the definition of instances of enumerated classes is part of application ontology construction, whereas the definition of instances of intensionally defined classes is part of the model instantiation activity. Defining an enumerated class is a way to prevent CUE from attempting to elicit other instances of that class during the model instantiation activity. A typical use of enumerated classes is for defining value sets for attributes. For enumerated classes, QUOTE also shows the instances. For example, in Fig. 6.3 the instances of the enumerated classes importance-rate, strength-value and frequency-value are displayed. The arrows in the graph indicate type constraints. For instance, the relation manifestation-of shown in the figure is defined to have a disease and a finding as its arguments. The user can edit the definitions by opening a definition editor on a relation, class or function. Definition editors allow modification of the definitions at the Ontolingua level. For instance, in Fig. 6.4 the user has opened a definition editor for the function frequency. Definition editors are text buffers which provide emacs-like editing facilities. The CUE architecture ensures that the graphical representation and the underlying Ontolingua definitions are always consistent. This architecture is based on a user-interface management system which detects user actions and propagates these to the data structures, and which automatically detects changes in the data structures and propagates these to the visualizations. A detailed description of this architecture can be found in (Wielemaker & Anjewierden, 1989) and in (Anjewierden et al., 1992a). In chapter 3 three types of support were identified for ontology construction: specialized editing facilities, library support and process support. Only the first two of these support types are provided by QUOTE. The specialized editing support is based on three types of functionality: syntax checking, type checking and graphical visualization. Although these functionalities facilitate the definition of ontologies significantly, the support remains passive: the user defines the concept, and the tool warns that something might be wrong or missing. The creative aspect of ontology construction remains a task for the user. However, the library supplied by GAMES ensures that in many cases application ontology construction is reduced to library selection. Fig. 6.5 summarizes the functionality provided by QUOTE.

6.3.3

Connecting Task Model and Application Ontology

Once the the task model and the application ontology have been developed, they must be connected. This can be done using QUITE which has specialized mapping editors for supporting this activity. Every role and every inference in the task model can be associated with ontology mappings. For knowledge roles, these mappings specify which domain concepts may play these roles. For example, it may be specified that instances of the ontological class disease may play the role of diagnostic hypotheses. For, inferences, the mapping specify the types of domain knowledge that are used to perform the inference step. Thus, in the case of inferences, the mappings specify how

100


Figure 6.3: QUOTE’s theory editor visualizing the theory finding-disease. Note that the terms “disease” and “finding” in the imports browser refer to the theories included by finding-disease. In these theories the concepts finding and disease are defined.

the ontological requirements of the problem-solving methods associated with the inferences are satisfied. The screen dump of QUITE in Fig. 8.8 shows two mapping editors.

6.4 Model Instantiation in CUE Skeletal models specify which kinds of knowledge are needed for applications, and how the knowledge will be used during reasoning. The purpose of QUAKE, CUE’s model instantiation tool, is to interact with the domain expert to collect the domain knowledge and store it in a knowledge repository. In chapter 3 five types of support were identified for model instantiation: (i) consistency checking, (ii) completeness checking, (iii) use of domain specific terminology, (iv) use of intuitive visualization and (v) dialogue structuring. This section describes how each of these forms of support are provided by CUE. QUAKE can be used in two modes of interaction: passive, where the user determines the structure of the knowledge elicitation dialogue, and active, where the tool acts as an interviewer. Sec. 6.4.1 describes how QUAKE can be used in passive mode, thereby illustrating how the tool performs consistency checking and how it uses domain specific terminology. Sec. 6.4.2 describes the active mode, in which the tool also checks for completeness and structures the knowledge elicitation dialogue. Sec. 6.4.3 describes the use of specialized visualization techniques in QUAKE. Finally,


101

Figure 6.4: QUOTE’s theory editor when the user is editing the function frequency. The window labeled “frequency” in the lower area of the theory editor is an example of a definition editor.

Sec. 6.4.4 explains how QUAKE exploits the application ontology to support model instantiation.

6.4.1

QUAKE as a Passive Consistency Checker

QUAKE provides a narrow view on the underlying knowledge base. Only parts directly relevant to the current elicitation activity are shown. QUAKE’s basic user interface, shown in Fig. 6.6, consists of three areas. The upper left area is the object window. An object is either an instance of a class or a tuple of a relation. The object window is used for displaying information about the object that is the focus of the current elicitation activity. The right upper area contains a multi-functional browser. Depending on the nature of the elicitation activity, this browser can show different types of objects. The lower area of the tool is the interaction window. In this window the user is prompted to assert new knowledge in the knowledge repository. The use of QUAKE in passive mode will be illustrated with a fragment of a knowledge-elicitation scenario for a system that diagnoses GVHD. For this scenario, we use the application ontology described in Sec. 6.3.2. The scenario will also be used in Sec. 6.4.2 to describe some more advanced features of the tool.

A knowledge-elicitation scenario In the example scenario, the domain expert starts the knowledge elicitation session by entering diseases. Therefore, the user focuses the tool on the class disease, which turns the multi-functional browser into a browser for disease instances. The expert enters the names of some diseases that are relevant in the application area. The result is shown in Fig. 6.6.

102


Summary of QUOTE’s functionality

Supported activities from Sec. 6.2 – 4. Construct the application ontology by selection, editing and configuration.

Intended users – Knowledge engineers, in cooperation with domain experts

Support types – Editing facilities – Library support

Input from other tools –

QUOTE does not require input from other tools, but it can be used to visualize or edit Ontolingua theories developed outside the CUE environment. QUOTE can best be used together with a library of ontological theories, but this is not a requirement.

Output – An application ontology, consisting of a number of Ontolingua theories.

Theoretical background – The theory that underlies Quote is the Ontolingua theory: ontologies consist of definitions of classes, relations and functions that are organized in theories. A definition consists of a set of labeled sentences. Figure 6.5: A synopsis of QUOTE’s functionality.

Figure 6.6: QUAKE after the domain expert has entered some diseases. The entered diseases are visualized in the browser on the right side of the tool. The user is just entering a fifth disease: ACUTE-HEPATITIS.


103

Once five diseases have been entered, the user decides to concentrate on one of them: GVHD. The disease is selected and visualized in QUAKE’s object window. In the application ontology, no attributes are defined on instances of class disease. Therefore, the user decides to ask the tool for the relations that are defined on diseases. According to the application ontology, there are three kinds of relations defined on instances of the class disease: disease-subtype 5, manifestation-of and has-treatment. The relations are shown in the browser, which is now used as a relation browser. In Fig. 6.7, the relation disease-subtype is mentioned twice, because GVHD can play two roles in this relation. In the first relation specifier GVHD plays the role of the supertype, whereas in the second specifier GVHD would be the subtype.

Figure 6.7: QUAKE showing the relations defined on the class of GVHD.

The domain expert decides to work first on the manifestations of GVHD, so (s)he selects that relation in the browser. The tool responds by showing all the findings that are defined as manifestations of GVHD. However, in this case there are as yet no findings associated with GVHD. The domain expert decides to enter the presence of a rash as a manifestation of GVHD and selects the corresponding pulldown option, which results in the tool showing a template for the manifestation-of relation in the interaction window. Because the domain expert is working on GVHD, the disease parameter is already instantiated. As illustrated in Fig. 6.8, the user enters the finding “rash = present” in the text field. When the domain expert is finished QUAKE checks whether the entered expression is syntactically correct and consistent with the application ontology. If the new expression is correct and does not conflict with previously entered information, it is asserted in the QUAKE knowledge base. An example of a possible conflict would be that the domain expert had already asserted that rash is an instance of disease. Since it is defined in the application ontology that a finding has an observable as its first parameter and disease is not specified as a subclass of observable or vice versa, QUAKE would in that case refuse to accept the entered finding. In the scenario, the domain expert continues by asserting that another manifestation of GVHD is the presence of fever. After that (s)he decides to specify some further qualifications of the 5

Note that the disease-subtype relation is an object level relation that can hold between instances of the ontological class disease. This relation has nothing to do with the subclass relation which is used in Ontolingua.

104


Figure 6.8: QUAKE when the domain expert enters that the presence of rash is a manifestation of GVHD. When the user does not know in which form the finding should be entered the tool can be asked to show a template of the relation.

first mentioned manifestation. The corresponding tuple is selected in the browser and displayed in the upper left window. According to the application ontology, manifestation-of relations have two attributes: evoking-strength and frequency.6 The user first selects the evoking-strength attribute and as a result a template for the function appears in the interaction window (Fig. 6.9). Because in the application ontology evoking-strength is defined to have a strength-value as its value, which is an enumerated class, QUAKE is able to generate the list of possible values for the attribute. This list is used to support an auto-completion facility (which is also displayed in Fig. 6.9). This example clearly illustrates the importance of the distinction between intensionally defined and enumerated classes mentioned in Sec. 6.3.2: in the model instantiation phase it is not possible to define instances of enumerated classes. The scenario shows that QUAKE uses the application ontology to provide strong guidance for the model instantiation process. The tool prevents the user from entering expressions that conflict with the definitions in the ontology, and the tool interacts with the user in domain oriented terminology: it prompts for diseases and findings, and not for method-specific knowledge types, such as hypotheses and data, or for symbol-level constructs such as rules or constraints. Of course, the ability of the tool to communicate in domain-specific terminology depends on the domain specificity of the application ontology. If a knowledge engineer uses only generic vocabulary in the definitions, QUAKE is only able to communicate in generic terms. The knowledge engineer should take this into account when constructing the application ontology. QUAKE confronts the user with a limited amount of information at a time. For instance, Fig. 6.9 shows only the manifestations of GVHD, and the evoking-strength and the frequency for one of these manifestations. The rationale behind this approach is that this narrow, focused view on the underlying knowledge base guards the domain expert from not seeing the wood for the trees. Experiences with earlier KA workbenches showed that domain experts often get confused when large amounts of heterogeneous domain facts are displayed at one time. 6

QUAKE interprets

unary functions as attributes.


105

Figure 6.9: QUAKE when the domain expert enters the evoking strength of the presence of rash for GVHD. Because strength-value is an enumerated class, the tool is able to show the allowed values.

6.4.2

QUAKE as an Active Knowledge Collector

Experience with QUAKE as a passive application knowledge editor has revealed some shortcomings. Because of QUAKE’s narrow view on the knowledge base, users quickly forget which knowledge has already been asserted and which knowledge still must be entered. For example, in the scenario described in the previous section, the user first entered five diseases, then (s)he concentrated on one of these, GVHD, and asked the tool which relations were defined on this disease. Of the four relations, manifestation-of was selected, and two tuples of this relation were entered. In the course of this scenario many tasks were left unfinished. For instance, besides the five diseases shown in Fig. 6.6 other diseases need to be entered which also have findings as manifestations. Further, the disease hierarchies (the disease-subtype tuples) must be specified, etc. In passive mode, QUAKE leaves the navigation in the knowledge space defined by the skeletal model completely to the user. To overcome this difficulty, QUAKE is also equipped with a more active interaction style. In active mode, the tool not only waits for the user to take action, but it can also take the initiative. The active component of the tool consists of two parts: (i) an agenda mechanism, responsible for completeness checking and (ii) an interpreter for knowledge-elicitation strategies, responsible for dialogue structuring. Agenda mechanism The purpose of the agenda mechanism is to keep a record of which parts of the skeletal model are fully instantiated, partially instantiated, or empty. In some cases, QUAKE can decide whether a part of the skeletal model has been fully instantiated. For example, one of the assumptions made by QUAKE is that attributes must always have values. Therefore, the tool can decide that a particular attribute still needs to be specified without intruding upon the user. Furthermore, sometimes the application ontology explicitly defines that a specific number

106


of relation tuples or class instances must exist. For instance, it could be defined that instances of some type of disease may have at most one therapy. QUAKE’s agenda manager can use such information to decide whether parts of the skeletal model are fully instantiated or not. Most of the time, however, the decision as to whether a part of the skeletal model is fully instantiated must be taken by the domain expert. In the scenario, it was the domain expert who had to decide that all the relevant diseases were entered, that all the manifestations of all the diseases were specified etc. In contrast, in active mode it is up to QUAKE to keep the agenda up to date. Whenever a user decides to start working on another part of the knowledge base and the tool cannot determine by itself that the job that was worked on has been completed, QUOTE asks the user. For example, when the user in the scenario in Sec. 6.4.1 decided to start working on the manifestations of GVHD, the tool in active mode would first have asked whether the entered diseases are all the relevant diseases in the application domain. The response of the user would then be used to update the agenda. Fig. 6.10 shows QUAKE’s agenda after the five diseases and the two manifestations were entered.

Figure 6.10: QUAKE’s agenda mechanism

Knowledge elicitation strategies The agenda mechanism maintains a list of knowledgeelicitation activities that are completed, partially completed, or not yet initiated. However, the decision as to the order in which the different elicitation activities are performed is still left to the user. For example, in the scenario in Sec. 6.4.1 it was the user who decided to start working on the diseases, and it was the user who decided to select the manifestation-of relation from the relations defined on GVHD. After a while, the decision as to which knowledge-elicitation activity should be performed next becomes a complicated task in itself, because the number of activities rapidly increases as new knowledge is entered. For example, in the above scenario, four activities are added to the agenda for every disease which is entered in the knowledge base (elicitation of the manifestations, treatments, subtypes and supertypes of the entered disease). Many knowledge acquisition tools that are specialized in the model instantiation activity of the knowledge acquisition process, take a more active role. For example, MOLE (Eshelman, 1988) and SALT (Marcus & McDermott, 1989) instantiate their skeletal models using a dialogue where the system takes the initiative. In these systems, the tool decides which knowledge should be elicited when. We call the structuring principles for such a dialogue a knowledge-elicitation strategy. In other words, a knowledge-elicitation strategy is a specification of the order in which the domain instances and expressions are to be elicited.


107

In the above-mentioned second-generation KA tools, it was possible to hardwire the knowledge-elicitation strategies in the program because these tools were based on a fixed skeletal model. MOLE for example, begins a knowledge-elicitation session by asking the user to list some of the complaints that would indicate that there is a problem to be diagnosed. After these are entered, the tool asks for states or events that explain these complaints. In turn these states may also need to be explained. In this way MOLE builds, in a breadth-first manner, a network of causally related states and events. MOLE derives its power from the strong assumptions that it makes about the structure of the causal network that is required for the Cover-and-Differentiate problem-solving method. It is not possible to use built-in knowledge-elicitation strategies in systems like CUE, where the construction of the skeletal model is also considered part of the knowledge acquisition process. Because the suitability of a strategy depends heavily on the nature of the skeletal model, the strategy can be determined only after the skeletal model has been constructed. In the current version of CUE this problem is addressed by making the specification of the knowledge-elicitation strategy part of the construction of the skeletal model, as is also the case in DIDS (Runkel & Birmingham, 1994) and KREST (Steels, 1993). To formulate knowledge-elicitation strategies as part of the skeletal model, a simple Lispbased language has been defined which can be interpreted by QUAKE. This language allows the knowledge engineer to express ordering constraints in terms of the application ontology. A very simple example of a knowledge-elicitation strategy defined in this language is the following. (define-ka-strategy main () (elicit-all ?d (disease ?d)) (for-each ?d (disease ?d) (elicit-all $f (manifestation-of (finding $f) (disease ?d)))))

(1) (2)

The first expression tells QUAKE to start eliciting all the diseases in the domain. The second specifies that, once the diseases have been elicited, all the manifestations for each disease must be elicited. The constructs elicit-all and for-each are the main primitives of the language. elicit-all takes a specification and tells QUAKE to elicit expressions that are in accordance with that specification. In the body of the construct, operations can be specified that must be performed on each of the elicited expressions. for-each works similar, but instead of eliciting expressions according to the specification, it retrieves expressions that are already stored in QUAKE’s knowledge repository. The language is extended with constructs for sequencing, iteration and simple conditionals and allows recursion. The suitability of the language has been tested by using it for specifying the knowledge elicitation strategies of MOLE and SALT. Appendix B shows a part of the knowledge elicitation strategy of MOLE. The use of a language for this purpose allows specification of any knowledge-elicitation strategy which can be defined in ontological terms. It is left to the knowledge engineer to decide which of these strategies are sensible. This is an undesirable situation because it makes the job of the knowledge engineer more difficult. What is really needed is a KA tool that is able to determine an appropriate knowledge-elicitation strategy by itself. Such a tool would need to have knowledge of general guidelines for the formulation of knowledge-elicitation strategies. At present, such general principles are not available. In the remainder of this section, some candidate principles on which knowledge elicitation strategies can be based are discussed.

108


Principles for structuring the KA dialogue To investigate the question as to whether which dialogue structuring principles are sensible, we have compared the elicitation strategies employed by a number of existing tools. For one of these tools, MOLE, we have already described its elicitation strategy. SALT constructs its knowledge base in a similar way. The skeletal model of this tool requires three types of knowledge: procedures, constraints and fixes. The knowledge pieces are organized in a dependency network with three types of relations: contributes-to, constrains, and suggests-revision-of. To instantiate this skeletal model, the tool allows the user to start elicitation at any point in the network. SALT then cues the user for appropriate links and keeps track of how the elicited knowledge pieces are fitting together and it also warns for inconsistencies. ALTO (Major & Reichgelt, 1990) is a tool for the elicitation of concept hierarchies, based on the laddering technique. The underlying skeletal model distinguishes two types of knowledge: concepts, which are organized in is-a hierarchies, and attributes of those concepts. ALTO starts the elicitation process by asking for a seed item. From this seed item, the user may move up or down the hierarchy, or to the siblings of the seed item. After that, the attributes of the new concept are elicited and the process continues with the elicited concept as the new seed item. Analysis of the three knowledge-elicitation strategies described above reveals some striking similarities. All these tools seem to do some kind of “graph traversal”. This is one example of a potentially general principle for formulating knowledge-elicitation strategies: use elicited pieces of knowledge to prompt for related pieces of knowledge. This principle may be applied in a depth-first manner, a breadth-first manner, or a combination of both and it can make use of multiple relations (e.g. “contributes-to” and “constrains” in SALT). A second general principle is based on the observation that in many application domains, there are “basic” objects. The nature of these objects depends on the application task. For example, in diagnostic applications, the basic objects are the diagnoses, whereas in design applications, the basic objects are components. This observation is for example used in KEW’s advice and guidance module to organize the KA process. When the task of the application is of a diagnostic nature, KEW’s task scheduler suggests starting by eliciting the potential solutions. In cases when the number of solutions is infinite, or very large, KEW instead suggests starting by eliciting the solution components. Contrary to the first principle, the second principle is dependent on the task. The ability of QUAKE to implement such strategies depends on the mapping between the task model and the application ontology. For example, in the GVHD domain, QUAKE should know that the potential solutions for the diagnostic problem are diseases. In general, this heuristic could be formulated as follows. In every application, there are basic objects. What these basic objects are depends on the nature of the task and on the mapping between the task model and the application ontology. Knowledge acquisition should start by eliciting these basic objects. In summary: based on an analysis of the strategies used in existing knowledge acquisition tools, the following dialogue-structuring principles can be formulated.

Use already elicited knowledge to prompt for related pieces of knowledge (graph traversal). Center elicitation around “basic objects”. Which objects are basic depends on the task type and the mapping between the task model and the application ontology.

Principles such as these can be used as global constraints that elicitation strategies should satisfy. However, they are not sufficiently restrictive to derive a single best elicitation strategy from a task model and an application ontology. Further, the optimal strategy could also depend


109

on other, not ontology related considerations such as the level of expertise of experts and and the level of experience with tools (Burton et al., 1990).

6.4.3

Specialized Visualization in QUAKE

In the sections above it was illustrated how QUAKE checks for consistency and how it uses domain specific terminology (Sec. 6.4.1) and how it checks for completeness and structures the knowledge elicitation dialogue (Sec. 6.4.2). The final way in which tools can support model instantiation is by the use of specialized visualizations. ALTO, for instance, visualizes the elicited concept hierarchies in the form of directed graphs. The tool has this ability because it makes ontological assumptions about the structure of the knowledge that needs to be elicited. In ALTO these assumptions are hard-wired in the tool. In contrast, QUAKE cannot make such ontological assumptions because it must be able to instantiate arbitrary ontologies defined with QUOTE. In order to use specialized visualizations for particular parts of the knowledge base, QUAKE must be able to determine on the fly which visualizations are appropriate for which parts of the knowledge base. One way to realize this is to explicate the ontological assumptions upon which specialized visualizations are based. This makes it possible to decide whether a particular class or relation can be displayed using a specialized visualization, based on the definition of that class or relation in the application ontology. Currently, the only specialized visualization facility provided by QUAKE is a directed graph viewer. This viewer can be used for relations that are binary, transitive and anti-symmetric. Whenever QUOTE is able to determine that these properties hold for a certain relation, the tuples of this relation may be visualized using the directed graph viewer. Fig. 6.11 shows this facility when visualizing tuples of the disease-subtype relation.

Figure 6.11: QUAKE’s directed graph viewer, visualizing tuples of the disease-subtype relation.

The directed graph viewer can also be used as a simple laddering tool. To do this, the user must select an object in the hierarchy and select the “Ladder Up” or “Ladder Down” option (from the Laddering pulldown menu). The tool then searches for the corresponding job in the agenda and starts it up. Fig. 6.12 summarizes the functionality provided by QUAKE. In summary, the CUE tools support the steps distinguished in the generic scenario of Sec. 6.2 in the following ways.

110


Summary of QUAKE’s functionality

Supported activities from Sec. 6.2 – 7. Create elicitation agenda. – 8. Specify knowledge-elicitation strategy. – 9. Elicit domain knowledge.

Intended users – Domain experts

Support types – – – – –

Consistency checking Completeness checking Use of domain specific terminology Intuitive visualization Dialogue structuring defined by knowledge engineer

Input from other tools – QUAKE Requires an application ontology defined with QUOTE. – When there is also a mapping between the task model and the application ontology QUAKE can use this to generate an initial agenda. Otherwise, the user will have to aid the tool.

Output – A completed epistemological model, which can be handed over to a programmer to construct the computational model.

Theoretical background – The theoretical background of QUAKE is basically the theory of model-based knowledge acquisition that was set out in chapter 3: focused knowledge elicitation requires a restrictive skeletal model. In QUAKE, the skeletal model is made restrictive by incorporating the application ontology. Figure 6.12: A synopsis of QUAKE’s functionality.

1. Informally describe domain and task of the application. CUE does not support this step. 2. Identify generic tasks In CUE, this step is supported by QUITE. This tool allows the user to select generic-task instances and to configure these into a task model (by mouse clicking and dragging). 3. Specify which parts of the task must be automated. QUITE allows the user to indicate which parts of the task model are to be performed by the KBS. 4. Construct the application ontology. QUOTE supports ontology construction by selecting ontological theories from a library, configuring the theories into an application ontology and refining the definitions in the theories for the particular application. 5. Specify the role-to-role mappings. QUITE allows the user to specify the mappings between already defined roles (by dragging lines between the roles in the graphical representation of the task model).


111

6. Map task model onto ontology. The task model can be mapped onto the ontology in QUITE via the use of ontology mapping editors. 7. Create Elicitation Agenda Before the elicitation activity starts, QUAKE generates an initial agenda which is automatically kept up to date during the elicitation session. 8. Specify knowledge-elicitation strategy This step is only partially supported. QUAKE provides a simple tailored language for specifying knowledge-elicitation strategies, but it does not have specialized editors to support the language. 9. Elicit domain knowledge This step is supported by QUAKE. The tool interprets the knowledge-elicitation strategy and prompts the user to enter new knowledge until the knowledge base is — according to the application ontology — complete. QUAKE checks for consistency and is able to select appropriate visualizations for parts of the knowledge base.

6.4.4

How it Works

QUAKE’s ability to support model instantiation is almost entirely based on its capacity to inspect Ontolingua definitions. Consistency checking in QUAKE means checking whether the entered piece of knowledge is consistent with the corresponding Ontolingua definition. Also, completeness checking in QUAKE (determining if a KA activity has been completed) is done by examining Ontolingua definitions to see how many instances or tuples of a particular class or relation are allowed. Further, to decide how knowledge pieces should be visualized, the corresponding definitions are inspected. This section describes the components of an Ontolingua definition and how QUAKE is able to inspect these.

Ontolingua Definitions An Ontolingua definition consists of a number of labeled sets of sentences that specify how the defined class, relation or function may be used. For our purposes, the most important distinction between these sets of sentences is that some sets consist of axioms in which the defined term is used, while other sets of sentences consist of meta descriptions of the defined terms. In the former, which are called first-order sentences in Ontolingua, the truth functional properties of the logical connectives are used to constrain under which circumstances the defined term can be used for formulating valid expressions. The other sets of sentences consist of meta descriptions of the defined terms. These expressions are called second-order sentences in Ontolingua. A simple example of a sentence of the first type is: (=> (manifestation-of ?finding ?disease) (disease ?disease))

(1)

An example of a sentence of the second type is: (nth-domain manifestation-of 2 disease)

(2)

The two sentences both express the fact that the second argument of manifestation-of must be a disease. However, while the first sentence expresses this fact only implicitly, using material implication, the second states the fact explicitly.7 The vocabulary for writing these explicit meta axioms about ontological terms is defined in the Frame ontology, a special representational ontology that comes with Ontolingua. The Frame ontology is provided to facilitate the translation of Ontolingua ontologies into a number of 7

The terms implicit and explicit are used in the same way as in (Kirsh, 1990): something is explicitly represented when it can be derived from a knowledge base without the application of inference steps.

112


different representation formalisms, which was the main purpose for developing Ontolingua. The idea is that the terms defined in the Frame ontology capture cliches for which many (frame-based) problem solvers provide specialized inference procedures. The translators are able to inspect the meta axioms for deciding how a particular definition should be translated. In order to facilitate the job of the Ontolingua translators, the Ontolingua system first performs a canonicalization step. In this step, the system attempts to recognize first-order cliches and reformulate them in terms of the Frame-ontology axioms. The canonicalization pass guarantees that the translation output profits as much as possible from the special inference procedures of the target systems. Fig. 6.13 shows the Ontolingua translation architecture. A detailed description of this architecture can be found in (Gruber, 1993). user-defined Ontolingua Frame ontology

Loom

canonicalization translation canonical Ontolingua

translation

Epikit

translation other representation Figure 6.13: The Ontolingua translation architecture

QUOTE and Ontolingua The definition editors that are provided by QUOTE for specifying ontology definitions provide emacs-like editing facilities such as parenthesis checking, automatic indentation etc., but they are not syntax-driven. Users can use both types of sentences mentioned above in their definitions. Once they are satisfied with a definition, it is checked for syntax errors, and then handed over to the Ontolingua system. Ontolingua canonicalizes the definition entered by the user, and then passes it to a QUOTE-specific translator, which translates the definition into QUOTE’s internal data structures. Then, QUOTE invokes its pretty-printer to produce a nicely formatted textual representation of the canonicalized definition in the definition editor. Fig. 6.14 summarizes this process. A result of this design is that the internal representation — and the visualized representation — of QUOTE are always equivalent to canonical Ontolingua, making maximal use of the axioms in the Frame-ontology. This is important because the other tools in CUE can inspect only the meta-axioms. For example, when QUAKE needs to know the type of the second argument to manifestation-of it would understand sentence 2 above, but it would not understand sentence 1. However, the architecture ensures that sentence 1 is automatically reformulated as sentence 2. QUAKE and Ontolingua Just as the Ontolingua translators are able to inspect the meta axioms in Ontolingua definitions to decide how a particular term should be translated, QUAKE is able to inspect the meta axioms to retrieve information needed to support knowledge elicitation. For example, in Sec. 6.4.3 it was mentioned that for visualizing the tuples of a relation as a directed graph, QUAKE requires that the relation is binary, transitive and anti-symmetric. Since each of these terms is defined in the Frame ontology, QUAKE only needs to inspect the meta axioms of the


113

syntax-checking

buffer

user-defined Ontolingua

manifestation-of layout preview

(define-relation ------ (----) ---------------------------

canonicalization

Frame ontology

canonical Ontolingua

pretty-printing

Quote

translation Internal Quote representation

Ontolingua architecture

Figure 6.14: The interaction between QUOTE and the Ontolingua translation architecture.

ontology definition of the relation to decide whether these properties hold. In the same way, meta axioms about the cardinality of relations can be used to decide whether a particular knowledge acquisition job has been completed. For example, when it is defined that the maximum-slotcardinality of a particular class and a particular binary relation is three, QUAKE can decide that the corresponding KA job is finished after three tuples of that relation have been elicited. QUAKE makes a KA-oriented interpretation of the concepts defined in the Frame ontology, in the same way that the target representations that Ontolingua translates to make a reasoningoriented interpretation of these concepts. Of course, not every concept in the Frame ontology can be used for all types of model-instantiation support provided by QUAKE. Table 6.15, which is based on the description of the Frame ontology in (Gruber, 1993), summarizes the kinds of information that can be derived from the terms defined in the Frame ontology. The information can be used for three purposes: consistency checking, completeness checking and visualization. The other types of support for model instantiation, domain-specific terminology and dialogue structuring, are not directly based on the inspection of the meta axioms in the definitions. The use of domain specific terminology comes for free as a result of the use of an explicitly defined application ontology, the dialogue structuring facilities are partially based on QUAKE’s capacity for completeness checking.

6.5 Discussion This chapter presented three tools that are part of the CUE knowledge engineering workbench. CUE falls in the same category of knowledge acquisition environments as SBF, KEW, KREST, DIDS and PROTE´ GE´ -II , which were described in chapter 3. This section highlights some similarities and differences between CUE and these other systems. CUE differs from its predecessor KEW because the skeletal models that are used in CUE to drive the KA process (task model + application ontology) have more detailed information about the kinds of knowledge that need to be acquired. One of the lessons from KEW was that the KADS-like skeletal models — basically inference structures — did not sufficiently constrain the knowledge-elicitation process (see chapter 4). Secondly, CUE has a more rigid view on the knowledge engineering process than KEW. Whereas KEW can be used in a number of ways to develop a knowledge-based system — leaving most of the

114


type c c c r f f r r r r r f f f r r c c c c f f f r f r r r r r r r f r f r r f r f r r r r c r r c c c c c c c c c c c c c c c r

relation relation function class instance-of all-instances one-of subclass-of superclass-of subrelation-of direct-instance-of direct-subclass-of arity exact-domain exact-range total-on onto n-ary-relation unary-relation binary-relation single-valued inverse projection composition composition-of compose alias domain domain-of range range-of nth-domain has-value all-values value-type value-cardinality same-values inherited-slot-value all-inherited-slot-values slot-value-type slot-cardinality minimum-slot-cardinality maximum-slot-cardinality single-valued-slot same-slot-values class-partition subclass-partition exhaustive-subclass-partition asymmetric-relation antisymmetric-relation antireflexive-relation irreflexive-relation reflexive-relation symmetric-relation transitive-relation weak-transitive-relation one-to-one-relation many-to-one-relation one-to-many-relation many-to-many-relation equivalence-relation partial-order-relation total-order-relation documentation

arguments ?relation ?function ?class ?individual ?class ?class :-> ?set-of-instances @instances :-> ?class ?class ?class ?class ?class ?relation ?relation ?individual ?class ?class ?class ?relation :-> ?n ?relation :-> ?relation ?relation :-> ?class ?relation ?relation ?relation ?range-class ?relation ?relation ?relation ?binary-relation ?binary-rel :-> ?binary-rel ?relation ?column ?rel1 ?rel2 :-> ?binary-rel ?binary-rel ?list-of-rels @binary-rels ?binary-rel ?rel1 ?rel2 ?relation ?class ?class ?relation ?relation ?class ?class ?relation ?rel ?integer ?class ?inst ?binary-rel ?value ?inst ?binary-rel ?inst ?binary-rel ?class ?inst ?binary-rel :-> ?n ?inst ?rel1 ?rel2 ?class ?binary-rel ?value ?class ?binary-rel :-> ?values ?class ?binary-rel ?class ?class ?binary-rel :-> ?n ?class ?binary-rel ?n ?class ?binary-rel ?n ?class ?binary-rel ?class ?rel1 ?rel2 ?set-of-classes ?class ?class-partition ?class ?class-partition ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?binary-relation ?object ?string

cons. + + + + + + + + + + + + + o + + + + + + + + + + + + + + + + o -

comp. o o o o + + + + + -

vis. + + + + + + + + + o o o -

Figure 6.15: A summary of how QUAKE uses terms defined in the Frame ontology, to support consistency checking (cons.), completeness checking (comp.) and specialized visualization (vis.). + Means that QUAKE uses the relation for a type of support, and o means that the relation could be used but that the current implementation doesn’t. The types c, r and f in the first column stand for class, relation and function. :-> separates domain parameters from range parameters for functions. Parameters starting with a @ may be bound to multiple arguments.


115

navigation in knowledge acquisition space to the user — CUE is designed with a specific knowledgeengineering scenario in mind. The advice-and-guidance module described in chapter 4 was an attempt to reduce the complexity of the task that the KEW user has to deal with by suggesting what to do next in the KA process. However, even with advice and guidance, KEW remains difficult to use because the user has to deal with a large number of tools with different conceptualizations and representations and, as a result of this, with a large number of transformations between representations. In contrast with KEW, CUE assumes that the knowledge-engineering process proceeds in a very specific way, which was explicated in the generic scenario presented in Sec. 6.2. If the knowledge engineer decides to organize the process in another way, CUE will be less useful. Thus the usability of CUE depends on the usability of the generic scenario. The scenario was derived from two sources. Firstly, the analysis of existing knowledge acquisition tools in chapter 3 shows that all these tools can be described within the paradigm of model-based knowledge acquisition of which the generic scenario is a specific instantiation. The second inspiration for the scenario is the GAMES approach presented in chapter 2. In particular, the view that the application ontology is a distinct part of the skeletal model which can be exploited to provide strong guidance for the model instantiation step influenced the form of generic scenario. The work most closely related to the work presented here is that on the PROTE´ GE´ -II system. In particular, the work on DASH (Eriksson et al., 1994) is in a similar spirit. DASH is a tool that can be used to build knowledge elicitation tools from application ontologies specified in MODEL, the ´ GE´ -II ontology language. The relation between QUAKE and DASH is similar to that between PROTE an interpreter and a compiler. Whereas QUAKE interprets application ontologies to communicate in domain specific terminology, DASH uses these ontologies to generate other tools that communicate in domain specific terminology. DASH-generated tools act as user-friendly front-ends for the underlying knowledge base. They are similar to QUAKE in passive mode in that they do not aim for completeness. That is, they do not actively search for missing information. Therefore it is to be expected that users of DASH generated tools will face the same problems as those encountered with QUAKE when used in passive mode. The DIDS system (Runkel & Birmingham, 1994) has a facility for specifying knowledgeelicitation strategies. Runkel and Birmingham distinguish two elements that drive knowledge elicitation, namely (i) “mechanisms for knowledge acquisition” (MeKA), which define for each knowledge construct in the ontology an elicitation, a verification and a generalization procedure, and (ii) a “knowledge acquisition method” which defines the sequencing of MeKAs. The MeKA’s are knowledge acquisition tools that are specialized for particular types of knowledge. This is similar to the use of specialized visualizations in CUE. The knowledge-acquisition method is similar to knowledge-elicitation strategies in CUE, although they are typically more coarse grained. The main contribution of the work on CUE is that it provides a theoretical foundation for how the different types of support for knowledge elicitation can be achieved by separating ontology and application knowledge. If the ontology is available, it can be inspected to check the elicited knowledge for consistency and completeness, to communicate with the expert in domain specific terminology and to choose suitable visualizations. It was hypothesized that also a fifth type of support could be derived from the ontology: dialogue structuring. To experiment with different dialogue structuring principles CUE is equipped with a language for defining knowledge elicitation strategies.

116


As already indicated in the beginning of this chapter, the current version of CUE concentrates on the earlier activities in the model-based KA paradigm, model construction and model instantiation. The next chapter describes a prototype version of the CUE facilities for supporting model compilation.

Chapter 7

Knowledge-Based Integration of Representation Formalisms In the previous chapter, CUE’s facilities for model construction and model instantiation were described. This chapter presents a possible approach to model compilation, where distinct parts of the model can be compiled into different representation formalisms. These different formalisms are then integrated on the basis of the contents of the knowledge, as specified in the application ontology. It is argued that hybrid integration, which is based on the form of the knowledge, does not provide sufficient flexibility to achieve computational and epistemological adequacy. The implication of knowledge-based integration for knowledge engineering and problem solving are discussed. This chapter is a slightly revised version of a paper presented at European Conference on Artificial Intelligence (ECAI) 1994 which is co-authored by Wilfried Post and Guus Schreiber. The reference is: van Heijst, G., Post, W. & Schreiber, A. Th. (1994b). Knowledge-based integration of representation formalisms. In Cohn, A., editor, Proceedings of the 11th European Conference On Artificial Intelligence, pages 319–323, London. Wiley.

7.1 Introduction Model compilation, the third activity of the model-based knowledge acquisition paradigm,involves translating the instantiated skeletal model into an executable knowledge base. The compilation activity becomes more complicated when more expressiveness is allowed in the instantiated skeletal model. In GAMES, an approach to model compilation is investigated which can be used with instantiated models of arbitrary expressiveness. The approach is based on two principles. Firstly, an attempt is made to use existing problem solvers when possible.1 Secondly, it is assumed that in many cases it will not be possible to find a single problem solver that is appropriate for implementing the entire reasoning process. The basic idea is that different parts of the reasoning process can be implemented by different problem solvers. These problem solvers should be selected in such a way that they are adequate for the part of the reasoning process for which they are responsible. Problem solvers that cooperate to solve a problem must be able to communicate. This communication is complicated by the use of existing problem solvers which may use different representation formalisms. To achieve cooperative problem solving in this situation requires the specification of what the expressions in 1

We use the term “problem solver” for a combination of a reasoning technique and a representation formalism.

117

118


the formalism of one problem solver mean in the formalisms used by other problem solvers. That is, the representation formalisms of the problem solvers must be integrated. This chapter presents a possible approach for realizing such an integration. Sec. 7.2 explains why it is in general not possible to find a problem solver that is appropriate for implementing the entire reasoning process which is modeled in the epistemological model, thus illustrating the need for using multiple problem solvers and representation formalisms. Sec. 7.3 discusses some problems with hybrid integration, the way in which representation formalisms are usually integrated. Sec. 7.4 presents an alternative way of integrating problem solvers which is called knowledge-based integration. Sec. 7.5.1 describes a prototype architecture that supports knowledge-based integration, and in Sec. 7.5.2 and Sec. 7.5.3 the impact of knowledge-based integration on knowledge engineering and problem solving is discussed. In Sec. 7.6 the present proposal is compared with other recent proposals in the literature.

7.2 The Need for Multiple Representations It is widely acknowledged in the artificial intelligence community that there are different types of knowledge. For example, a number of researchers have identified dimensions according to which knowledge can be classified [e.g. deep knowledge vs. shallow knowledge (Steels, 1985), causal knowledge vs. heuristic knowledge (Console & Torasso, 1988; Simmons, 1992), knowledge of structure and behavior vs. functional knowledge (Abu-Hanna et al., 1991)]. For reasoning with these different types of knowledge, a large number of problem solvers have been developed which use different knowledge representation formalisms and have different inferential capacities. The reason for these differences is that problem solvers should be sufficiently expressive to represent all the relevant knowledge in a natural way and have the inferential power to derive all the interesting implications of the represented knowledge in an efficient way. As argued by Levesque and Brachman (1985) these two requirements are antagonistic. Therefore every problem solver must make a trade-off between expressiveness and inferential power. The problem solvers that have been developed can be characterized by the way they trade representational power for inferential power. The restrictions that have been put on the expressiveness to keep inferencing in these languages tractable can be categorized into three classes:

Firstly, there are representation languages that maintain tractability by putting syntactic restrictions on the expressions in the language. For example, many production rule interpreters can only handle facts in the form of triples. Another example is Prolog, which is based on first-order logic, but does not allow negation or disjunction in the conclusions.2 A second group of representation languages derive their inferential power from epistemological assumptions about the structure of knowledge. Frame-based representations are typical examples of this category; these systems assume that knowledge is typically organized as structured objects that are arranged in subsumption hierarchies, and they provide efficient reasoning schemes for such structures. The main difference between this category and the previous one is that here inferential power is achieved by adding specific forms of

2 We are only referring to Prolog as a representation formalism here. Of course, Prolog can be used as a programming language for implementing interpreters for other representation languages, which make the trade-of between representational power and inferential power in another way.

Chapter 7: Knowledge-Based Integration of Representation Formalisms

119

expressiveness, whereas in the previous category inferential power is achieved by reducing the expressiveness.

Unlike representation languages in the first two categories, representation schemes in the third category explicitly delimit the range of domains for which they can be used. Representation languages in this category maintain inferential power by making ontological assumptions about the domains and the task that they will be used for. A typical example of this approach is GDE (de Kleer & Williams, 1987), a system for model-based diagnosis, which requires that the devices that are to be diagnosed can be represented in terms of interconnected components.

Besides computational tractability, a second requirement for knowledge representation formalisms for KBSs is epistemological adequacy: a representation formalism must be able to reflect all the distinctions that are important for performing a particular task in a particular domain, while it should not force the knowledge engineer or the domain expert to make additional, irrelevant distinctions. The epistemological adequacy of a representation formalism depends on the type of knowledge that needs to be represented. For instance, it has often been noticed that the production rule formalism is well-suited for representing heuristic, associational knowledge, but is ill-suited for causal models (e.g. Simmons, 1993). Since solving real world problems often involves different types of knowledge, the requirements of epistemological and computational adequacy imply that a KBS that is to solve these problems must be able to use multiple representations and reasoning techniques. The use of multiple problem solvers poses a potential problem: how are the different problem solvers to be integrated? It was mentioned that the representation formalisms that the problem solvers use can have a different syntax, can be based on different epistemological assumptions, and can make different ontological commitments. To make such diverse problem solvers cooperate clarification is required as to how expressions in one formalism map onto expressions in another formalism. In existing systems that use multiple representations, integration is usually realized by predefined syntactical mappings. The next section presents some problems with this kind of integration.

7.3 Hybrid Knowledge Representation For different types of knowledge, the trade-off between expressive power and computational power should be made in a different way. This observation has initiated the development of a number of reasoning systems that use multiple representations and multiple inference engines [e.g. KEE (Fikes & Kehler, 1985), LOOM (MacGregor, 1991), KRYPTON (Brachman et al., 1985) and CYCL (Lenat & Guha, 1990)]. In these so-called hybrid architectures the different components are tightly connected: a problem solver can send queries to other problem solvers and use their result for its own reasoning. In hybrid architectures the problem solvers are typically specialized for particular types of (sub-)problems. In LOOM for example, one reasoning engine, which uses a semantic network representation, is responsible for terminological reasoning, while another problem solver, which uses a logical representation, is responsible for assertional reasoning. Another combination of problem solvers which is often found in hybrid architectures is the use of a first-order theorem prover for deductive reasoning and a frame-based problem solver for default reasoning.

120


In these hybrid systems the integration issue arises. When one of the problem solvers wants to invoke another problem solver it must know how to formulate the query for the other problem solver. In hybrid architectures this problem is solved by specifying mappings between the different representation formalisms. Of course, these mappings can only be partial: the differences in the expressive power between the formalisms is the main reason for having the hybrid architectures. The partial mappings specify the interface between the representation formalisms. For example, a partial mapping between a frame-based representation and a logical representation could specify that frames are mapped onto unary predicates and slots and slot-values onto binary predicates. Fig. 7.1 gives an example of such a mapping for the case of frames and predicate logic.

(defframe () ( ) ...)

() ( ,) ... Figure 7.1: A possible mapping between different representations in a hybrid system. In this mapping, the type of the

frame is mapped onto a unary predicate and the slots of the frames are mapped onto binary predicates.

As can be seen in Fig. 7.1, the integration is only based on the syntactical structure of the different formalisms: whenever something is represented as a frame slot in the frame language, it will be interpreted as a binary predicate in predicate logic. In hybrid systems, the integration is realized by mappings between syntactical structures. This is necessarily so, because in these systems the mappings are defined when the hybrid tool is built. At that moment, the syntactical structures are the only invariants available on which the mappings can be based. A disadvantage of integration as realized in hybrid systems is that the fixed mappings constrain the ways in which the representations can be used. When it is decided to represent a particular piece of knowledge in some way in one of the representation formalisms, this puts constraints on the ways in which knowledge can be represented in the other formalisms. Therefore, it is not always possible to exploit the full power of all the constituting formalisms. Further, sometimes the hybrid solution is not feasible because there is no obvious way in which the syntactical structures of one formalism should be mapped onto the syntactical structures of another formalism. For these reasons, hybrid representation is not the optimal solution for the present purpose: representing instantiated knowledge models of arbitrary expressiveness. The next section presents an alternative, more flexible approach for integrating multiple problem solvers.

7.4 Knowledge-Based Integration The problem with hybrid representations is that they integrate formalisms based on the syntactical form of the expressions in the constituting languages. Therefore, it is not always possible to represent a piece of knowledge in the form that is most appropriate for that piece of knowledge in each of the formalisms.


121

Instead of a syntactical mapping, it is also possible to integrate formalisms based on the content of the knowledge. This is what we call knowledge-based integration. Basically, the idea is the following. When a knowledge engineer starts a project, one of the first tasks is to construct a knowledge-level model of the domain knowledge that is required to perform the application task. This model must be formulated in a language that is formal but which may have an unlimited expressiveness, since it will not be used for reasoning. One component of this knowledge-level model is the application ontology, which makes the underlying structure of the domain knowledge explicit. When the knowledge model is completed, the knowledge engineer selects a number of problem solvers for implementing the system. Every problem solver has an associated representational meta-model. This is a model that specifies what can be represented in a particular formalism, but which abstracts from the syntactical details of the representation. The integration of the different representation formalisms of the problem solvers is then realized by specifying mappings between the application ontology and the representational meta-models. Fig. 7.2 shows the difference between knowledge-based integration and hybrid integration.

Knowledge Level

Symbol Level

application ontology

(disease ?x)

representational meta model 1

(state-variable ?x)



(and (state-variable ?x) (frame ?x) (sub ?x disease))


(frame ?x)

Hybrid Integration

Knowledge Based Integration

Figure 7.2: The difference between knowledge-based integration and hybrid integration is that the former is based on a

knowledge-level application-specific mapping, whereas the latter is based on a symbol-level syntactic mapping.

Application ontology The application ontology is a specification of the domain knowledge that is needed to perform a particular task in a particular domain. The following logical sentence is a typical example of an expression that would be part of an application ontology in a medical domain. It states that a finding is a tuple that consists of an observable, an operator and an element of the value set of the observable.

8

X ,Y ,Z finding(X ,Y ,Z ) ! [observable(X ) ^ operator(Y ) ^ Z

2 value set(

X

)]

Representational meta-models The representational meta models are abstract descriptions of the types of expressions that are allowed in a knowledge representation formalism. They are formulated in the same language as the application ontology. The representational meta-models of problem solvers can vary from coarse-grained descriptions of conditions and actions in the case

122


of production rule interpreters to fine-grained ontological models of what can be represented in systems like GDE. For example, the following expression, which states that a condition consists of a set of attribute expressions, could be part of the representational meta-model of a production rule interpreter, where the rules have condition parts and action parts.

8

,

X Y

[condition(X ) ^ Y 2 X ] ! attribute expression(Y )

Mappings The mappings between the application ontology and the representational metamodels specify how expressions from the language defined by the application ontology can be translated into the representation formalisms and vice versa. This serves two goals: (i) it specifies how the knowledge-level model can be implemented on a computational architecture in the design phase for the application and (ii) the mapping specifies the meaning of the expressions of the representation formalism in terms of the application ontology. As there is a mapping for each of the participating problem solvers, the application ontology specifies a language that is understood by all. Therefore, it can be used for communication between problem solvers. Mappings which are only used for the first goal are called static mappings. They are only used once, during the construction of the system. Mappings which are used for communication between problem solvers, are called dynamic. These mappings are used at run time, to translate output from one problem solver into input for another problem solver. As an example of the mapping between an application ontology and a representational metamodel, consider the following mapping rules: finding(X ,Y ,Z )

7! attribute expression(h

, ,

X Y Z

i)

[disease(X ) ^qualitative probability(X ,Y )] 7! attribute expression(hX ,=,Y i) Conceptually, these mappings are quite simple. For instance, the first rule expresses that findings, as defined in the application ontology, are represented as attribute expressions in the production rule formalism. However, even in this simple example there are some technical complications that the mapping mechanism should account for. Whereas finding is a ternary predicate in the application ontology, attribute expression is a unary meta-predicate in the representational meta-model. In the example, the mismatch is purely notational: in the representational meta-model attribute expression is defined to hold for three-placed tuples that have an operator as their second element. However, the knowledge engineer should be aware of conceptual incompatibilities, in which case the selected problem solver is not epistemologically adequate. The mapping mechanism must be able to perform the mappings in both directions. In the example, this is possible because the qualitative probability relation is defined to have a disease as its first argument. Therefore, the type of the first element of the attribute expression tuple can be used to decide on the corresponding application ontology expression: if it is an observable, the corresponding expression is a finding, if it is a disease, the corresponding expression is a qualitative probability. Although the mapping relations will usually be more complicated than the ones shown here, they should remain relatively simple. When it is not possible to define simple mappings, this could indicate that the expressiveness of the problem solver is not sufficient for expressing the distinctions made in the application ontology. For example, if the attribute expressions in the representational meta-model only allow the = operator while in the findings in the application ontology also the < and > operators are used, complicated mapping rules would be required. The


123

complexity of the mapping relation can therefore be viewed as an measure for the suitability of the problem solver: if the mappings are simpler, the problem solver is more appropriate. As argued in Sec. 7.2 it is often impossible to find a problem solver that is able to represent the full spectrum of knowledge types that is specified in the application ontology. In such cases, the task that the application must perform is broken up into subtasks, each of which is associated with a problem solver. Problem solvers must be selected so that the knowledge that is needed to perform the particular subtask can be adequately represented in the problem solvers’ representation. To summarize, the difference between hybrid integration and knowledge-based integration is that in the former the integration is realized directly, while in the latter the integration is realized through an intermediate knowledge-level model: the application ontology.

7.5 Applying Knowledge-Based Integration Using knowledge-based integration has important consequences for the practice of knowledge engineering and thus for the required functionality of AI toolkits. Since knowledge-based integration is based on the contents of the application ontology, the integration can only be realized after knowledge acquisition. Therefore, the decision on how to integrate the selected problem solvers must be taken by knowledge engineers when they develop an application. Knowledge engineering methodologies should recognize this activity as an integral part of the knowledge engineering process and provide methods and tools to support it. Sec. 7.5.1 describes a prototype of a toolkit that supports knowledge-based integration. In Sec. 7.5.2 it is illustrated how this system can be used to develop an application and Sec. 7.5.3 illustrates the impact of knowledge-based integration on the problem-solving process.

7.5.1

The CUE Environment

The previous chapter presented CUE’s knowledge acquisition tools: QUITE, QUOTE and QUAKE. The output of these tools is a non-executable knowledge-level description of the domain knowledge needed for an application. This section presents CUE’s facility for developing computational models. A first prototype of this module has been implemented. CUE is an open architecture that allows arbitrary problem solvers to be plugged-in. This requires two steps: (i) the representational meta-model of the problem solver must be constructed and (ii) it must be specified how this model is related to the internal representation of the problem solver. In CUE, the representational meta-models are also specified in Ontolingua.3 The links between the meta-models and the internal representations are realized by problem solver specific translators, written directly in Lisp. An example of the architecture of an application that is constructed with CUE is depicted in Fig. 7.3. Whereas the mappings between the application ontology and the representational meta-models must be specified for every application, the Lisp code for translation between the meta-models and the internal representations of the problem solvers needs to be specified only once. When this is done, the problem solvers and the associated representational meta-models and translation 3 Although Ontolingua is used for both the application ontology and the representational meta-models, we do not entirely agree with the Ontolingua philosophy. Sec. 7.6 discusses the exact relation between the present work and the work of Gruber.

124


application ontology

mappings


lisp code causal probabilistic network


lisp code production rule interpreter

Figure 7.3: Mappings and translations in knowledge-based integration

code can be put into a library for reuse. Thus, while the mapping relation must be specified by the knowledge engineer, the translation code will be written by the developers of CUE’s problem solver library.

7.5.2

An Example Using CUE

The use of CUE will be illustrated with some fragments from a scenario which is based on an exercise to reconstruct parts of the FREECALL system (Post et al., 1993) in CUE. The exercise was intended to test the idea of knowledge-based integration, and not to develop a realistic system. Therefore, some of the design decisions may seem odd from an engineering perspective. FREECALL is a KBS that supports ambulance dispatchers in their decision whether to send an ambulance after an emergency call. In the exercise, we concentrated on two subtasks of the system: (i) the generation of a set of initial hypotheses, and (ii) the assessment of the likelihood of these hypotheses. In the example only the use of dynamic mappings will be illustrated. The next chapter will present some examples of static mappings. The application ontology of FREECALL contains definitions of findings (as in Sec. 7.4), diseases, and the way they are related. Because of the large number of potential hypotheses — a computational consideration — it is decided to use production rules to generate the initial hypotheses set. The mapping between the application ontology and the representational meta-model of the production rule interpreter is described in Sec. 7.4. For the second subtask IDEAL is selected from the problem solver library. IDEAL (Srinivas & Breese, 1990) is a system for evaluating causal probabilistic networks and influence diagrams. The representational meta-model of IDEAL defines the class state variable and the relation influences:4

8

, influences(X ,Y ) ! [state variable(X ) ^ state variable(Y )]

X Y

The relation state expression is defined as follows:

8

, state expression(X ,Y ) $ [state variable(X ) ^ Y 2 value set(X )]

X Y

4

We use the logical notation instead of the Ontolingua notation which is used in CUE. The logical notation is more concise and probably more familiar.


125

Further, the representational meta-model specifies that every state expression Si has a number of associated conditions C1; : : : ; Cn. A condition Cj is a set of state expressions S1 ; : : : ; Sn with a state expression Sk 2 Cj for every state variable that influences the state variable of Si . For every condition Cj that is associated with Si there is a conditional probability P (Si jCj ) so that 0 P (Si jCj ) 1. For IDEAL, the mapping between the application ontology and the representational meta-model is more complicated than for the production rules. It is decided that observables are represented as state variables and findings as state expressions about these variables. Diseases are represented as state variables too, with two admissible values: present and absent. Alternatively, the diseases could be represented as admissible values on a state variable diagnosis, but this would make it impossible to hypothesize multiple diseases. Furthermore, it would make it impossible to use probabilities as described in the medical literature — an epistemological consideration. In the representational meta-model, state expressions are represented as binary relations between state variables and values. There is no explicit mentioning of an operator; it is assumed that only the equality operator is used. Therefore, IDEAL can only be used when the findings only use the equality operator. This is another example of an epistemological consideration. The following expression is an example of the (dynamic) mapping between findings and state expressions. It states that if a particular finding holds, this means that the probability of this finding is 1.0. finding(X ,Y ,Z )

7.5.3

7! P(state expression(

, )) = 1.0

X Z

Running a CUE Application

The impact of knowledge-based integration on the problem solving process can be illustrated with a session with the above described version of FREECALL. In the example, the caller is a man whose 28 year old son complains about lasting chest pain. The trace in Fig. 7.4 shows example mappings and translations at the stage where FREECALL generates the initial hypotheses. Note that whereas in step 2 in this figure the findings are rewritten as attribute expressions, in step 5 attribute expressions are rewritten as qualitative probability assessments. The second subtask in the FREECALL system is a quantitative assessment of the probabilities of the disease in the differential — the set of hypotheses generated with the production rule interpreter. Hence, an influence diagram is selected which contains nodes for all of the diseases in the differential and for the observables of the known findings (the initial data). The mapping rules specified in the previous section are used to set the probabilities of the state expressions that represent the known findings to 1.0 and then IDEAL is invoked. A trace of the mappings and translations that are required for this form of hypothesis discrimination is shown in Fig. 7.5. From the selected influence diagram, FREECALL derives that hyperventilation is by far the most likely diagnosis. Note that in step 7, the expressions in terms of IDEAL’s representational meta-model are translated directly into Lisp function calls. The reason for this is that IDEAL has no declarative knowledge representation. This is another reason why representational meta-models are necessary for knowledge-based integration. The traces in Fig. 7.4 and Fig. 7.5 illustrate how statements in the application ontology can be translated into specific representation formalisms for executing an inference method. The mappings and translations ensure that the results are meaningful in terms of the application ontology.

126


System’s action

comment

1 initial-data: finding(chest pain, =, present) initial-data: finding(sustained pain, =, yes) initial-data: finding(age, =, 28) 2 mapping attribute expression(h chest pain, =, present i) attribute expression(h sustained pain, =, yes i)

The patient data are entered as findings, as defined in the application ontology. The label initial-data indicates the role of the findings in the reasoning process.

3 lisp translation IF (and (= chest-pain present) (= sustained-pain yes) THEN (= angina-pectoris possible) 4 lisp translation attribute expression(hangina pectoris,=,possiblei) attribute expression(hhyperventilation,=,possiblei) attribute expression(hinfarction,=,probablei) 5 mapping hypothesis: disease(angina pectoris) qualitative probability(angina pectoris, possible) hypothesis: disease(hyperventilation) qualitative probability(hyperventilation, possible) hypothesis: disease(infarction) qualitative probability(infarction, probable)

Because the hypotheses generation subtask is assigned to the production rule interpreter, the findings are rewritten in terms of the representational meta-model of the production rule interpreter; and then further translated into the private representation of the production rule interpreter, so that it can be matched against rules such as the one shown here. The production rule system generates three hypotheses, together with a qualitative assessment of their likelihood. This output is translated back into the representational meta-model language. Finally, the output is rewritten in terms of the application ontology. The generated diseases are assigned the role of hypotheses (this is control information). This completes the hypotheses generation subtask in the FREECALL system.

Figure 7.4: Trace of mappings and translations for hypothesis generation using a production rule interpreter

7.6 Discussion Although the term “knowledge level”, was used occasionally, this chapter addresses a “symbol level” issue: how to integrate knowledge representation formalisms, or more specifically: what do expressions in one formalism mean in another formalism. This is just one aspect of the larger issue of having multiple problem solvers, or agents, cooperate to solve a problem. We have — intentionally — ignored control issues. This scoping decision was made because we believe that the problem of integrating representation formalisms can be resolved independently from the control problem. This has the advantage that such a solution can be used within a wide range of control architectures. For example, in the scenario in the previous section the decision to invoke IDEAL could be taken in a data-driven way, as in blackboard systems, or in a goal-driven way, as in task-oriented architectures. The main message of this chapter is that in cases where it is necessary to use multiple representation formalisms, the application ontology can be used to integrate these formalisms in such a way that the strengths of the different formalisms can be exploited maximally. As already mentioned, the work presented here is closely related to the work on Ontolingua (Gruber, 1993). CUE uses the Ontolingua language both for the application ontology and the representational meta-models. Besides a language for specifying ontologies, Ontolingua is also a computer program that translates the ontologies into the representation formalisms of a number of problem solvers. In Ontolingua, the translation of ontologies to representation formalisms does not require additional knowledge. The hypothesis that underlies the Ontolingua program is that it is possible to specify once and for all how expressions in the knowledge-level language are to be represented in the target representations. Therefore, the integration as realized through Ontolingua

Chapter 7: Knowledge-Based Integration of Representation Formalisms System’s action

127

comment

6 mapping P(state expression(chest pain, yes)) = 1.0 P(state expression(age, 25-29)) = 1.0

The findings and the hypothesized diseases are mapped onto state expressions in the influence diagram. The probabilities of the state expressions that represent findings are fixed to 1.0. 7 lisp translation Then, the probability assignments are translated into (setf (prob-of ’((#n(chest-pain) . Lisp function calls that set the values of structures in the #c(yes chest-pain)))) internal representation of IDEAL. 1) 8 lisp translation Next, the influence diagram is evaluated and the resultP(state expression(angina pectoris,present))=0.03 ing probabilities are translated back into the representaP(state expression(infarction,present))=0.04 tional meta-model terminology. P(state expression(hyperventilation,present))=0.27 9 mapping Finally, the expressions are translated back into the apquantitative probability(hyperventilation,0.27) plication ontology language and presented to the user of quantitative probability(angina pectoris,0.03) the system. quantitative probability(infarction, 0.04) Figure 7.5: Trace of mappings and translations in hypothesis discrimination using an IDEAL influence diagram

is essentially hybrid: when something is represented in a particular way in one representation it is predetermined how that knowledge will be represented in another representation. In contrast, in knowledge-based integration the translation is viewed as a knowledge intensive activity, which must be performed by the knowledge engineer. To facilitate this activity, the translation process is divided in a knowledge intensive part, the mapping operation, and an automatic part, the translation into the representations. We have not been very specific about the exact nature of the mapping relation. As in hybrid integration, the mappings may be partial: they connect the representational meta-models only with those parts of the application ontology that specify the knowledge needed to perform the particular subtask assigned to the problem solver. In general, we can formulate one hard constraint and one soft constraint on the mappings. The hard constraint is that the mappings must be bidirectional: it must be possible to go from the application ontology expression to the representational meta-model expression and it must be possible to go back from the representational meta-model expression to the application ontology expression. If this is not possible, the problem solvers lose the ability to communicate. The soft constraint is that the mappings are to remain simple. As was mentioned in Sec. 7.4, the complexity of the mapping relation is inversely related to the suitability of the selected problem solver. An important future research issue is how these constraints can be turned into practical guidelines for the formulation of mapping rules. Important work in this direction is currently being done by Gennari et al. (1994), who are developing an ontology of mapping relations. The pros and cons of different types of mapping systems are also a research topic in the area of formal KADS languages (Fensel & van Harmelen, 1994). In Sec. 7.4 it was mentioned that there are two types of mappings: static mappings, which are used during application development, and dynamic mappings, which are used during problem solving. In the examples in this chapter, all the mappings were dynamic mappings. The next chapter will give some examples of the use of static mappings during KBS development.

128


Chapter 8

Treating Acute Radiation Syndrome: a Case Study This chapter presents a pilot system that was developed to explore the feasibility of the approach presented in this thesis. The goal of the experiment was to use the approach and the CUE tools to develop a decision support system for treating acute radiation syndrome. The chapter concentrates on the construction of an application ontology and on the use of that ontology in the computational design phase of the KBS. The application ontology is shown in Appendix C. The domain knowledge for this application was collected and organized by Hauke Kindler and Dirk Densow, who also developed another prototype using M-KAT.

8.1 Introduction This chapter shows how the approach presented in this thesis is applied to develop a system that supports the treatment of acute radiation syndrome (ARS): a collection of injuries caused by exposure to high dosages of irradiation. ARS is a rare disorder; world wide there are about 900 known cases. The expertise for treating ARS is scarce and, because of the increased safety of nuclear power plants, it is decreasing. When such expertise is needed, however, in cases of nuclear accidents or nuclear attacks, it is likely to be needed immediately, and on a large scale. For this reason, researchers at the University of Ulm, which is one of the centers of expertise for managing acute radiation syndrome, have decided to develop a knowledge-based decisionsupport system, using the GAMES approach (Kindler et al., 1993). A prototype for such a system was implemented using M-KAT (Lanzola & Stefanelli, 1992). This chapter describes a reimplementation of the system, using the CUE tools. The medical knowledge used in the CUE implementation is the author’s interpretation of the knowledge collected by Hauke Kindler and Dirk Densow.

8.2 Synopsis of the ARS Domain A large dose of radiation causes depletion of cells, particularly in tissues where the cell population is normally renewed by continuous cell division and maturation. Organ systems that are affected by radiation include the haemopoietic system, the reproductive organs, the gastrointestinal tract, the skin, and the central nervous system. The stem cells of the bone marrow, which are responsible 129

130


for the production of blood cells, are particularly susceptible to the harmful effects of radiation. One type of blood cell, the leucocytes (white blood cells), play a fundamental role in the immune system. One task of the stem cells is to ensure that the number of leucocytes is kept at a certain level. There are two main types of leucocytes: granulocytes, which are produced in the bone marrow, and lymphocytes, which are produced in the lymphogenous organs, including the lymph glands and the thymus. The main aim of the treatment of ARS is to control the development of immunodeficiency. Immunodeficiency develops when the number of surviving stem cells after irradiation is too low to produce the necessary number of granulocytes, and, to a lesser extent, lymphocytes. In order to prevent the development of immunodeficiency, which can be lethal, a bone marrow transplantation (BMT) must be considered. However, BMT might have severe side effects, such as graft-versushost disease (GVHD). In addition, the injuries to other organ systems might be so severe that the patient would not survive anyway, in which case a bone marrow transplantation should be avoided. When a considerable number of stem cells survives the radiation exposure, growth factor therapy may be considered as an alternative. In this therapy, the patient is treated with growth inducers, proteins that stimulate the growth and reproduction of stem cells. A first target of ARS treatment is to establish the severeness of the radiation injury, expressed in terms of the estimated damage to four organ systems: the haemopoietic system (of which the stem cells of the bone marrow are a part), the skin, the gastrointestinal tract and the central nervous system. As a result of the exposure to radiation, these systems develop time-dependent patterns of signs and symptoms. These patterns must be interpreted to assess the severity of the lesions to each of the four systems. The lesions to each of the systems are expressed in terms of severity gradients — labels for qualitatively different severities. Based on these gradings appropriate therapeutic action can be undertaken.

8.3 Modeling the Task The aim of ARS management is symptomatic treatment — the radiation itself is irreversible. The medical expert must make a decision as to whether a particular action must be undertaken to control processes that occur in the patient. To make such a decision, the medical expert attempts to establish the severity of each of the four lesions that might be the result of the radiation. In the task model this situation is modeled by means of a diagnostic STModel, grading the severity of the syndrome, and a therapeutic STModel, selecting the appropriate action. The system receives its input from a standardized medical record which has been developed for the structured documentation of ARS cases (Baranov et al., 1994). This record contains the data that might be relevant for ARS treatment. Since all the relevant data are entered before the KBS is invoked, the system is not required to deduce expectancies and to request new data. Thus, only the abstraction step and the abduction step of the diagnostic cycle have to be performed by the system. For the same reason, the system only performs abstraction and abduction in the therapy planning subtask. Fig. 8.1 shows a first version of the task model, constructed with QUITE. The knowledge engineer has created a diagnosis generic-task instance (ARS-grading) and a therapy-planning generic-task instance (Select-ARS-treatment). These are connected by a control link which indicates that grading precedes treatment selection. For the moment, this is all that can be specified in the task model. The specification of the role-to-role mappings requires a better

Chapter 8: Treating Acute Radiation Syndrome: a Case Study

131

Figure 8.1: The task model for the ARS application.

understanding of the nature of the domain knowledge. At this stage of the modeling process, the task model only provides a rough description of the reasoning process. This model is sufficient to initiate construction of the application ontology.

8.4 Building the Application Ontology The GAMES approach provides a library of ontological theories that can be used to develop application ontologies. This library is indexed by medical subdomains and reasoning methods. Ontological modeling therefore starts by giving a rough indication of the medical subdomain and the possible reasoning methods. Treatment of acute radiation syndrome involves at least four medical subfields: haemotology, dermatology, neurology and gastro-enterology. Currently, the library contains no extensions that are specific to these subfields. Therefore, the domain-specificity indexes cannot be used directly to find the appropriate concepts.1 It is also not possible to decide at this moment which methodspecific extensions are needed. As argued in chapter 4, the suitability of methods often depends on the ontological structure of the knowledge in the application domain. For using the library in this situation, a number of guidelines have been developed. A first set of guidelines, presented in Fig. 8.2, can be used to decide on the order in which a knowledge engineer should search for concepts in the library. A second set of guidelines is intended for deciding on how to look for a particular concept in the library. These guidelines are presented in Fig. 8.3. A third set of guidelines, presented in Fig. 8.4, can be used for deciding on whether a 1

We use the term concept in the most general sense: classes, relations and functions are all concepts.

132


particular concept is suitable for the present purpose. Guidelines for deciding on for which concepts to look: Guideline A.1: Determine the concepts that play the primary roles in the reasoning process. The primary roles are the roles that always recur in the STModels for a particular generic task, independently of the particular methods that are used. For the diagnostic part of the task model these are diagnostic hypotheses, patient findings and data, and for the therapeutic part therapeutic hypotheses, therapeutic problems and data. Guideline A.2: Determine the ontological features of the concepts that are used to make the basic inferences in the reasoning process. These are abstraction, abduction, ranking, deduction, and induction. It usually better to search first for the concepts that play the primary roles (guideline A.1) because the terminology for these concepts is more standardized than the terminology for the concepts used for inferencing. Figure 8.2: Guidelines for deciding on the order in which the library should be searched for concepts.

The next sections will describe how these guidelines were used in the ontological modeling process for each of the two generic task instances. The results of this process are summarized in Fig. 8.7.

8.4.1

Ontology for ARS-Grading

The order in which the ontology for ARS-grading is constructed is based on guidelines A.1 and A.2. First we select or construct the concepts that play the knowledge roles, and then we deal with the concepts that are used for making the inferences. Diagnostic hypotheses As we have seen in the domain description in Sec. 8.2, the hypotheses role is mapped onto alternative gradings of the four syndromes that form ARS: the haemopoietic syndrome, the gastrointestinal syndrome, the skin syndrome and the central-nervous-system syndrome. We first concentrate on modeling syndromes, and then on their gradings. Following guideline B.1, the library is searched for a concept with the name “syndrome”. This concept is found in the theory syndrome, which is selected from the library. According to guideline B.2 it must now be checked as to whether it is suitable for the current purpose. The theory syndrome defines syndromes as collections of findings which co-occur but for which there is no known direct causal connection. Syndromes are modeled as a subclass of disorder. According to this definition, ARS is the only real syndrome in the domain; the component syndromes of ARS are processes about which the causal mechanisms are reasonably well understood. Thus, for the “syndromes” that constitute ARS the definition in inappropriate. Following guidelines B.3 and B.4, it is investigated whether the definition of syndrome can be specialized or modified to make it suitable. It is not possible to specialize the concept because a part of the definition of syndrome does not hold for the lesions. Specialization can only be used to add attributes to a definition, not to remove attributes. In principle, the concept could be modified to make it appropriate. However, it is decided not to do this because this would involve removing the only aspect of syndrome that distinguishes it from its superconcept disorder.


133

Guidelines for deciding on how to look for a concept: Guideline B.1: Ask the domain expert to suggest a name of the concept that is used for the particular role in the domain and search the library for a concept with a similar name. If the search succeeds, go to guideline B.2. Otherwise go to guideline B.5. The idea here is that if the appropriate concept is somewhere in the library, it can be found by terminology matching. This is more likely to succeed for concepts that are used for knowledge roles than for concepts that are used for inferences, because the terminology for the former is more standardized. Guideline B.2: Check if the definition found is suitable for the current purpose. If the concept is appropriate, include it in the application ontology. Otherwise, go to guideline B.3. When a concept with the right name is found, this does not guarantee that the concept definition is appropriate, so this needs to be checked. Guideline B.3: Find out if the concept can be specialized to a suitable subconcept. If this is possible, add the specialized concept to the application ontology. Otherwise, go to guideline B.4. When a library concept is inappropriate because it is too general, it can be made appropriate by adding specific details. This is done by introducing an application specific subconcept of the library concept. Guideline B.4: If the concept found is not suitable and it can also not be specialized to a suitable subconcept, find out if it can be modified to become suitable. If this is possible, copy the concept to an application-specific part of the application ontology, modify it and rename it to avoid name conflicts. Otherwise, go to guideline B.5. If the concept found by terminology matching is not appropriate, it can still be useful. During the discussion with the domain expert it becomes clear which aspects of the concepts are appropriate and which are inappropriate. This information can be used to define a more suitable version of the concept in the application ontology. Guideline B.5: If no suitable concept can be found or constructed using guidelines B.1 to B.4, try to find a very general concept in the core library and try to determine in discussion with the domain expert whether this concept can be specialized or modified to arrive at an appropriate concept. When a general concept is selected, it is almost always necessary to specialize it. Figure 8.3: Guidelines for deciding on how to search in the library for specific concepts.

134


Guidelines for deciding on the suitability of a particular concept In general, a concept is suitable if it makes the distinctions that are necessary for the present purpose, and no other distinctions. This can be operationalized by means of the following guidelines: Guideline C.1: Decide whether the concept is sufficiently general to cover the pieces of knowledge that will be modeled using the concept. If a concept is not sufficiently general, knowledge elicitation will become problematic because some pieces of knowledge that are used in the reasoning process cannot be modeled. Guideline C.2: Decide whether the concept is sufficiently specific to only cover the pieces of knowledge that will be modeled using the concept. If a concept is not sufficiently specific, it is not possible to define restrictive mappings between the application ontology and the task model: too many concepts will be allowed to play too many roles. Guideline C.3: Decide whether the name of the concept is a meaningful term in the application domain. If the name of the concept is not sufficiently domain specific, it cannot support knowledge acquisition in domain-specific terminology. Figure 8.4: Guidelines for deciding whether a particular concept is appropriate for the present purpose.

The problem is that for the lesions that constitute ARS the term “syndrome” is a misnomer. As prescribed by guideline B.5, it is therefore decided to introduce a new specialization of disorder which is called ars-organ-system-lesion. This concept is added to the theory ars-application, a theory added to the application ontology for storing application-specific definitions. Modeling different gradings of ars-organ-system-lesion can be done in two ways: (i) by defining that the possible gradings are subtypes of the lesion, or (ii) by modeling the gradings as expressions about the lesion. Examples of both types of modeling can be found in the core part of the library. An example of the first approach is in the theory disease. In this theory, the relation disease-subtype is defined, which can be used to model that particular diseases are specializations of other diseases (c.f. the examples in chapter 6). In the current application, this could be realized by defining a relation lesion-subtype between instances of ars-organ-system-lesion. This solution is shown in Fig. 8.5a. However, the different possible gradings of a lesion to one particular organ system are mutually exclusive: a patient can only have one grading for a particular lesion. Characteristics like this are important for knowledge elicitation and for computational design and should therefore be represented in the application ontology. Modeling the gradings this way would therefore require the addition of a number of very specific constraints to the lesion-subtype relation. Although this kind of customization is not unusual, it is often worthwhile in such situations to look for library definitions that better capture the relevant aspects of a concept. Another general medical concept in the library is finding.2 Findings are defined as 2

Note that the term finding is used for both a particular knowledge role in the STModel and for an ontological


135

expressions about patient parameters. Modeling ars-lesion-grading as a specialization of finding would solve the problem mentioned above, because for finding it is already defined that the different findings about one observable are mutually exclusive. There is one complication: to make ars-lesion-grading a specialization of finding, ars-organ-system-lesion must be made a specialization of patient-parameter. Because ars-organ-system-lesion was already modeled as a disorder, finding is not suitable because it is too specific (guideline C.1). Following Guideline B.5 the library is searched for a more general concept: finding is a specialization of expression, which is defined in the theory expression. ars-lesion-grading is therefore defined as an expression for which the first parameter must be an ars-organ-system-lesion. a)

ars-organ-system-lesion

1

ars-lesion-subtype


2

(ars-lesion-subtype haemopoietic-syndrome haemopoietic-syndrome-grade-3)

ars-lesion-grading

b)

expression

1


1

thing

2

operator

3

thing

(ars-ars-lesion-grading haemopoietic-syndrome = 3) Figure 8.5: Two alternative ways to model lesion gradings. The rectangular boxes represent relations and the rounded

boxes represent classes. The numbered arrows represent that the nth. parameter of the relation pointed at is constrained to be an instance of the class pointed from.

To summarize the modeling decisions above: the only real syndrome in the domain is ARS. This syndrome consists of four gradings of disorder which are modeled as ars-lesion-gradings. These gradings play the role of hypotheses in the diagnostic reasoning process. The lesion gradings have as first parameter an ars-organ-system-lesion, which is a specialization of disorder. Patient findings For patient findings, the concept finding is used as a first guess for a suitable ontological concept. However, this concept is not entirely appropriate because it is too generic (guideline C.2). In the ARS domain, the patient findings are a specific kind of findings with qualitative value sets. As explained in chapter 6 and 7, both knowledge acquisition and computational design are facilitated by being as specific as possible in the application ontology. Following guideline B.3 it is therefore decided to define a specialization of finding in the theory ars-application, named ars-lesion-indication. An ars-lesion-indication is a finding where the observable must be an ars-lesion-indicator. In turn, these lesion indicators are modeled as a subclass of patient-parameter in ars-application. Further, it is defined that the value of the ars-lesion-indication must be an ars-indicator-value. concept. These are different things, but the term “finding” is used for both in medicine. Although this is a continuous source of confusion, we have decided to respect this tradition. For clarity, this chapter will use the term “finding” when referring to the ontological concept and the term “patient finding” when referring to the inference role.

136


Diagnostic data The KBS receives its inputs in the form of a computerized record. This record contains many different kinds of data whose only shared characteristic is that they contain information about the patient. Using guideline B.1, the library is searched for a concept named “datum”. Such a concept is not present in the current library. Thus, using guideline B.5 we look for a general concept. Again, the concept finding is selected from the library. According to guideline C.2 finding is not suitable because it is too general: also instantiations of ars-lesion-indication are findings. Thus, the concept needs to be specialized. Therefore, the concept ars-datum is created and stored in ars-application. When specializing a concept, it must be decided which aspects are shared by the pieces of knowledge that must be covered by the specialization. One aspect that distinguishes raw data from findings in general is that data are directly observable. This can be modeled by specifying that the first parameter of ars-datum must be an observable, a subclass of patient-parameter defined in the theory observable. Another important aspect of data in this domain is their temporal attributes. Currently, the library contains only one simple theory of time which is selected. This theory defines the concepts time-point and time-interval, but it does not define temporal relations such as “before” and “after”. For determining the appropriate treatment for ARS the time points of data with respect to the time point of the radiation accident are important, but the application will not monitor the patients, so no complex reasoning about time is required. Finally, the knowledge engineer defines in ars-application that every datum is associated with a time stamp, which may be a time point or a time interval. ars-datum and the related concepts are shown in Fig. 8.6. observable

finding

ars-datum.time-stamp

1

time-descriptor

time-interval

ars-datum

time-point

time-interval.end time-interval.start

Figure 8.6: ars-datum is represented as a specialization of finding where the first argument must be an

observable. Every datum has an associated time-stamp which may be a time-interval or a time-point. The texts ars-datum.time-stamp, time-interval.start and time-interval.end represent functions. The dashed arrows represent the domains and ranges of the functions.

To illustrate how data are modeled, consider the part of the medical record which is shown in Table 8.1. This part of the record is used by doctors to describe erythema in the patient. location head and neck upper part of body arms lower part of body legs feet oropharyngeal

yes X

no

unknown

begin 16.06.1958

end 22.06.1958

Table 8.1: The structure of the record field for erythema.

maximum 18.06.1958

degree 2


137

In terms of the application ontology, the data in the fields of the record are modeled as tuples such as the following:3 (ars-datum head-and-neck-erythema = 2) (ars-datum.time-stamp (ars-datum head-and-neck-erythema = 2) (time-interval 16.06.1958 22.06.1958))

The name of the observable is constructed by concatenating the term “erythema” and the term that represents the location of the erythema. The degree-field of the erythema record is represented by the datum-value. Also the epistemic modality of the datum is expressed by means of the datum-value: if the value is a degree or “no” it is known, otherwise it is unknown. The “maximum” field of the erythema record, which stores the date at which the erythema is at the maximum, is ignored because it is not used in the clinical reasoning process. The begin and end fields are modeled by means of the ars-datum.time-stamp attribute. Diagnostic abduction After having modeled the concepts that play the primary roles in the diagnostic process, we now turn to the knowledge required to make the inferences (following guideline A.2). In ARS diagnosis, abduction of the hypotheses is a straightforward process — the possible values of the lesion indicators have been chosen in such a way that they can easily be related to the organ-system-lesion gradings. These associations can be modeled by means of direct relations between the lesion indications and the gradings of the organ-system lesions. The knowledge about the presence of direct associations can be used for exploring the library with the method-specificity index. Using this index, the knowledge engineer retrieves the manifestation-of relation from the library, which was also used in some examples in previous chapters. However, this relation is not entirely appropriate because it relates findings to diseases, whereas we are looking for a relation that relates findings to lesion gradings, which are modeled as expressions. Guideline B.3 — which suggests specializing the generic concept — is not applicable, because there is a type mismatch between the the second parameter of manifestation-of (the class disease), and the relation ars-lesion-grading. Following guideline B.4, manifestation-of is therefore copied to ars-application and modified to have an ars-lesion-indication as its first argument and a ars-lesion-grading as its second argument. The modified relation is called ars-manifestation-of. In the library version of manifestation-of, the tuples of the relation are qualified with evoking-strength and frequency attributes. These attributes can be used to characterize the correlation between the diseases and their manifest findings. To determine whether these attributes are useful for ars-manifestation-of, the expert is asked if, given a particular finding, some lesion-indications occur more often than others. This turns out not to be the case in the ARS domain — when a lesion has a particular grading all the indications are present and, if not all the indications are present, the evidence is insufficient to make the corresponding diagnosis. This information is recorded in the documentation string that QUOTE associates with the concept. Diagnostic abstraction Different kinds of abstraction are used in the ARS domain. On the one hand, there are simple quantitative abstractions that map raw data onto qualitative assessments of the same parameter. On the other hand, there are abstractions that use complex mathematical formulae to compute the value of a lesion indicator from a number of raw data. Because 3

For readability, in CUE the complex terms in meta-level expressions are implicitly quoted and labeled by their ontological type.

138


the knowledge used for the abstractions is of a mathematical nature and can be communicated adequately using conventional mathematical notations, it is decided not to model the detailed characteristics of the knowledge used for the abstraction inference in the ontology. That is, we do not model concepts such as sine and cosine which are used in the formulae. Because it is important to know which observable data are used to compute the lesion indications, the relation ars-abstracted-from is defined in ars-application. This relation can be used to specify which knowledge is needed for the abstractions without specifying how the abstractions are computed. The formulae that describe how the abstractions are computed are only specified in the documentation slots that are associated with every knowledge piece in CUE.

8.4.2

Ontology for Select-ARS-Treatment

Therapeutic hypotheses In therapy planning, the most obvious candidates for the hypotheses role are therapies. Using guideline B.1, the concept therapy is found in the library theory therapy. Because the definition appears suitable for the current application, this theory is included in the application ontology. Therapeutic problems Therapeutic problems are the prime targets of therapy planning. Obviously, in the ARS domain these are the lesion gradings. However, other information is also needed to decide on the appropriate therapeutic action. For example, there may be conditions in the patient that prohibit the application of a particular therapy. Because there may be different types of conditions that affect the choice of therapy, it is not possible to be very precise about their nature in the application ontology. Using guideline B.5, it is decided to model therapeutic problems using the general concept finding. Although guideline B.5 advises on making a specialization of the general concept, this is not done yet, because it is not clear in what way the specialization could be more specific than finding itself. Therapeutic Data As was the case with diagnostic data, the data that are used to derive the therapeutic problems are coming from the computerized record. Therefore, these data are also modeled using the concept ars-datum. Therapeutic abduction In the theory therapy, the relation has-therapy is defined as a relation between disorders and therapies. Therefore, this relation is used as a first guess for an appropriate abductive relation. However, in the ARS application the therapies are not related to disorders but to lesion gradings, which are modeled as a subtype of findings. This is the same situation that occured with the manifestation-of relation for diagnostic abduction. According to guideline B.4, the concept must be copied to ars-application, modified and renamed. The renamed concept is called ars-has-therapy. For modeling the factors that are important for deciding whether a particular therapy is the right therapy for a disorder, therapy provides the relations has-indicator and has-contra-indicator. These are defined as relations between tuples of has-therapy and findings. However, because the application ontology uses ars-has-therapy instead of has-therapy, has-indicator and has-contra-indicator must also be modified and copied to ars-application. The modified concepts are named ars-has-indicator and ars-has-contra-indicator.


139

Therapeutic abstraction There are many different kinds of therapeutic abstraction with varying degrees of complexity. Thus, the same arguments that were used for modeling the diagnostic abstractions in broad terms, are also applicable for therapeutic abstraction. For this reason, the ars-abstracted-from relation is used again to describe the relation between data and therapeutic problems.

Fig. 8.7 shows a large part of the application ontology for the ARS application, using QUOTE’s graphical representation. The figure also illustrates which parts of the ontology are library concepts, specializations of library concepts or modifications of library concepts and which concepts are new.

8.5 Extending the Library As described in chapter 5, the concepts that were newly defined for the ARS application can be used to extend CUE’s ontology library. To do this, they must be scored on the domain-specificity index and the method-specificity index. In cases where the present domain and the used methods are not in the domain and method hierarchies, these must also be added. Table 8.2 shows how the newly defined concepts were scored on the domain- and method-specificity attributes.

Domain specificity In Sec. 8.4 it was mentioned that the current domain — ARS management — is related to four medical subdomains: haemotology, dermatology, neurology and gastroenterology, but that there are as yet no entries for these subdomains in the library. In this situation, there are two options. We could add the subdomains to the domain hierarchy and make ARS management a specialization of each of them. This strategy is appropriate when there are new concepts in the application ontology that are specific to these subdomains. However, inspection of the concepts in ars-application shows that this is not the case. The other option is to make ARS management a direct specialization of the domains from which it uses concepts. As was explained in the previous section, most of the newly defined concepts are specializations or modifications of core library concepts. The other newly defined concepts (ars-abstracted-from and ars-indicator-value) were defined from scratch. For this reason it is decided to make ARS management a direct specialization of “medicine”, the root of the domain hierarchy. Now it must be decided whether the newly defined concepts are specific for ARS management or whether they are generic for the medical domain. For the concepts that are specializations or modifications of core library concepts it is evident that they are specific to ARS management. Therefore this domain becomes their domain specificity value. Also ars-indicator-value gets ARS treatment as its domain-specificity value. This concept is only intended for modeling the set of possible values for ars-lesion-indicator. Because the two concepts are closely related, they should have the same values on the domain- and method-specificity attributes. The concept ars-abstracted-from was used for modeling the situation where the abstractions are made using diverse (mathematical) procedures which are not directly related to the expertise required for problem solving. Because this is a situation which is often found in medicine, it is decided to rename this concept as abstracted-from and assign the value “medicine” to it for the domain-specificity attribute.

140


1 2

part-of

1 2

component

connected-to 1

syndrome body-part

disorder.location

2

is-aggregation-of

disorder ars-organ-system-lesion

anatomical-space

organ

clinical personal laboratory

< =< = > >=

one-of

one-of

human-body organ-system

finding-type thing 1

patient-parameter

1

operator 3

2

expression

finding.type

1

observable

ars-abstracted-from

1

1

finding

1

finding-generalization

2

2

2

ars-has-contra-indicator

2

ars-datum

ars-lesion-indication

ars-lesion-grading

1

ars-datum.time-stamp 1

ars-has-indicator 1

2

3

1

ars-manifestation-of

1

time-descriptor ars-lesion-indicator ars-indicator-value time-interval

ars-has-therapy

one-of

time-point

2

therapy

fatal very-severe severe moderate mild

time-interval.end time-interval.start

legend Type of nth parameter of relation pointed at

time-point

Ontolingua class

abstracted-from

Ontolingua relation

Subclass-of

finding.type

Ontolingua function

Type of parameter and value of function

clinical personal laboratory

Instances of enumerated class

library concept

specialized library concept

n

one-of

modified library concept

Figure 8.7: The ARS ontology.

Enumerated class pointed from has instances pointed at. newly defined concept


141

Method specificity In the ARS application two types of methods were used: “abduction by direct associations” and “abstraction by invoking mathematical procedures”. Both methods are represented in the method hierarchy. To score the concepts on this attribute, the following guideline is used. When a concepts plays a primary role in the reasoning process (e.g. hypothesis, datum or patient finding in diagnosis), it gets the method-specificity value “medical method”, which is the root of the method hierarchy. If the concept is used for an inference, the method specificity value of the concept is similar to the method specificity value of the concept that is a specialization or modification of, except when the specialization or the modification was introduced for enabling the use of a more specialized method. In the latter case, the specialized method is used as method-specificity value. Concept

Domain Specificity

Method Specificity

ars-datum ars-datum.time-stamp ars-lesion-indication ars-indicator-value ars-has-therapy ars-has-contra-indicator ars-manifestation-of abstracted-from ars-lesion-grading ars-lesion-indicator ars-has-indicator ars-organ-system-lesion

ARS Management ARS Management ARS Management ARS Management ARS Management ARS Management ARS Management Medicine ARS Management ARS Management ARS Management ARS Management

Medical method Medical method Medical method Medical method Abduction by D.A. Abduction by D.A. Abduction by D.A. Abstraction by M.P. Medical method Medical method Medical method Medical method

Table 8.2: The domain- and method-specificity values of the concepts that were newly defined in the ARS application.

Abduction by D.A. stands for abduction by direct associations, and Abstraction by M.P. stands for abstraction by mathematical procedures.

8.6 Mapping Task Model and Ontology Because application ontology construction was initiated by determining the ontological features of the concepts that play the primary roles in the reasoning process, the mapping between the roles in the STModels and the ontology is straightforward. As illustrated in Fig. 8.8, QUITE has specialized editors for defining the mappings between the task model components and the concepts in the application ontology. The mappings are summarized in Table 8.3 and Table 8.4. The tables also indicate how the ontological concepts were included in the application ontology: (i) directly from the library (library), (ii) by specializing a library concept (specialized), (iii) by making a modified copy of a library concept (modified) or (iv) defined from scratch (new). In Sec. 8.3, the two generic-task instances were connected by means of a control link. When the ontology mappings have been defined, it is also possible to specify the role-to-role mappings. The purpose of these role-to-role mappings is to specify how the knowledge roles of the different generic-task instances in the task model are related. If there is a role-to-role mapping between two knowledge roles, a piece of knowledge that plays the role that the role-to-role mapping points from automatically also plays the role that the mapping points to. As can be seen in Fig. 8.8, there are two role-to-role mappings in the ARS task model: diagnostic data are mapped onto therapeutic

142


Diagnostic Role

Ontological Concept

How Included

Data Patient Findings Hypotheses Abstraction Abduction Ranking Deduction Induction

ars-datum ars-lesion-indication ars-lesion-grading ars-abstracted-from ars-manifestation-of — — —

specialized modified specialized new modified — — —

Table 8.3: Ontology mappings between the diagnostic STModel of the task model and the application ontology. The

table also shows how the ontological concepts were included in the application ontology.

Therapeutic Role

Ontological Concept

How Included

Data Therapeutic Problems Hypotheses Abstraction Abduction

ars-datum finding therapy ars-abstracted-from ars-has-therapy ars-has-indicator ars-has-contra-indicator — — —

specialized library library new modified modified modified — — —

Ranking Deduction Induction

Table 8.4: Ontology mappings between the therapeutic STModel of the task model and the application ontology. The

table also shows how the ontological concepts were included in the application ontology.

data and diagnostic hypotheses are mapped onto therapeutic problems. The first of these mappings is essential for the reasoning process. It explicates that the hypothesized diagnoses are therapeutic problems, thereby connecting the two generic task instances. The other role-to-role mapping is for convenience. It explicates that the data that are used for ARS grading may also be used for planning a therapy. For the current application, this has no impact since both the diagnostic data and the therapeutic data are retrieved from the same database. However, such mappings are important when data acquisition is a laborious task.

8.7 Acquiring Domain Knowledge 8.7.1

Generating the Elicitation Agenda

For the acquisition of the actual domain knowledge QUAKE is invoked. When the tool is started, its first task is to generate an initial elicitation agenda. For generating this agenda it must be determined which of the concepts in the application ontology need to be instantiated in the knowledge base, and which are only used for adding higher-level structure to the application ontology. This decision can be made manually or automatically in QUAKE. When performed manually, the tool presents all the classes, relations and functions and invites the user to specify which of


143

Figure 8.8: Ontology mappings and role-to-role mappings in the ARS task model. The figure shows that the diagnostic

hypotheses are mapped onto the ontological type ars-lesion-indication and that the therapeutic abstraction inference is mapped onto the relation ars-abstracted-from. Further, the figure shows role-to-role mappings between diagnostic hypotheses and therapeutic problems and between diagnostic and therapeutic data.

these concepts will have instances or tuples in the knowledge base. In automatic mode, QUAKE uses the mappings between the task model and the application ontology to decide which classes and relations need to be instantiated. The underlying idea is that only the concepts mentioned in those mappings are used in the actual reasoning process. Therefore, these are the only ones that can affect the behavior of the KBS. For the ARS application, the initial agenda is generated automatically.

8.7.2

Defining the Knowledge Elicitation Strategy

When it has been decided which knowledge must be elicited, the next step is to decide in which order the knowledge must be elicited. In QUOTE this is specified by means of a knowledge elicitation strategy. In chapter 6, two general principles were formulated for specifying knowledge elicitation strategies. Firstly, it was observed that there are usually basic objects in an application domain. For medical domains these are typically disorders, and in engineering domains components. Secondly, it was observed that the elicitation strategy is usually based on some kind of graph traversal: already elicited knowledge is used to prompt for related knowledge. From these principles and the application ontology in the ARS domain the following elicitation strategy was derived.

144


1. Elicit the diagnostic hypotheses (ars-lesion-gradings). 2. For each of the elicited hypotheses, use the main abductive relation to elicit the abstract findings that would trigger that hypothesis. In this case, this is the relation ars-manifestation-of. Note that the abductive knowledge and the patient findings (lesion-indications) are elicited in one step. 3. For each of the abstract findings, elicit the knowledge used to make the abstractions (the ars-abstracted-from tuples and the instances of ars-datum). 4. Elicit for each of the diagnostic hypotheses the associated therapies, using the basic therapeutic abduction relation (ars-has-therapy). 5. Elicit the findings that are indicators and contra-indicators for using a particular therapy for a lesion grading. 6. Elicit for each of the findings that are indicators or contra-indicators for the therapies the data that they are abstracted from. Note that in this strategy a number of ordering decisions have been taken which are not derived from the principles mentioned above. For example, the principles do not suggest that the knowledge used for diagnosis should be elicited before the knowledge used in therapy planning. In other words, it is not possible to derive a unique best strategy from the principles. There are a number of sensible strategies possible. From these, one has been chosen arbitrarily. Fig. 8.9 shows how this strategy was formulated in QUAKE’s knowledge-elicitation-strategy language.

8.7.3

Eliciting the Application Knowledge

Given the application ontology and the knowledge elicitation strategy, elicitation is a straightforward activity. QUAKE prompts the domain expert with a series of questions of the type “Enter a possible grading of the haemopoietic lesion”. Fig. 8.10 shows a transcript of the part of the scenario where the system elicits the indicators and contra-indicators of therapies.

8.8 Building the Computational Model When the epistemological model has been completed, it must be transformed into an executable system. In GAMES, computational modeling consists of three steps: (i) selecting or constructing meta rules, (ii) selecting problem solvers and (iii) translating the knowledge. This section will concentrate mainly on the first two of these steps. When the problem solvers are selected and the mappings between the application ontology and the representational meta models have been specified, the translation step can be done automatically.

8.8.1

Selecting or Constructing Meta Rules

The role of the meta rules is to specify the high-level control of the reasoning process. This involves both sequencing of the inferences within an instantiated task model and switching between these models. At the highest level, it must be specified that diagnosis is performed before therapy planning. This is the most common situation. Only in time-critical situations it might occur that the two processes are interleaved. However, it is not intended that the ARS system be embedded in a real-time environment. Further, the amount of knowledge in the epistemological model is limited


145

(define-ka-strategy main () ;; Elicit the ARS syndrome. This is a bit tricky. It is assumed that ;; the expert will only enter ARS, but this is not made explicit. (elicit-all ?s (syndrome ?s)) ;; Elicit the diagnostic hypotheses, that is the ars-lesion-gradings (for-each ?s (syndrome ?s) (elicit-all ?lesion (ars-organ-system-lesion ?lesion) (elicit-all ?grading (ars-lesion-grading ?lesion = ?grading)))) ;; For each of the elicited hypotheses, use the abductive relation ;; to elicit the findings that would trigger that hypothesis. (for-each $lg (ars-lesion-grading $lg) (elicit-all $li (manifestation-of (ars-lesion-indication $li) (ars-lesion-grading $lg)))) ;; For each of the abstract findings, elicit the knowledge that is ;; used to make the abstractions (for-each $li (ars-lesion-indication $li) (elicit-all $datum (ars-abstracted-from (ars-lesion-indication $li) (ars-datum $datum)))) ;; Elicit for ;; therapies, (for-each $lg (elicit-all

each of the diagnostic hypotheses the associated using the basic therapeutic abduction relation (ars-lesion-grading $lg) ?t (ars-has-therapy (ars-lesion-grading $lg) (therapy ?t))))

;; Elicit the findings that are indicators and contra-indicators for ;; using a particular therapy for a lesion grading. (let (@findings) (for-each $aht (ars-has-therapy $aht) (elicit-all $finding (ars-has-indicator $aht $finding) (push $finding @findings)) (elicit-all $finding (ars-has-contra-indicator $aht $finding) (push $finding @findings))) ;; Finally, elicit the data from which the findings are abstracted. (for-each $finding (member-of $finding @findings) (elicit-all $datum (ars-abstracted-from (finding $finding) (ars-datum $datum))))))

Figure 8.9: The knowledge elicitation strategy used for the ARS application. The language used for defining strategies

distinguishes three types of variables: (i) instance variables (?varname), which unify with class instances, (ii) tuple variables ($varname), which unify with tuples of the indicated types and (iii) set variables (@varname) which can be used for the temporary storage of elicited instances and tuples. The basic constructs in the language are elicit-all and for-each. Both have as their first parameter a variable, and as their second parameter an expression that constrains the instances and tuples with which the variable can unify. The (optional) remaining arguments must be operations that are to be performed on each of the instances or tuples that are unified with the variable. The difference between elicit-all and for-each is that the former obtains the objects that are unified with the variable by asking the QUAKE user, whereas the latter searches for objects that unify with the variable in QUAKE’s knowledge repository. Further, the ARS strategy uses the constructs push, which includes an object in a set, and let, for (lexical) variable scoping. Besides these constructs, the language also provides simple constructs for conditional branching, supports user-defined procedures and allows recursion. In Appendix C, the language is explained in further detail.

146


At a certain moment in the scenario, the system is eliciting therapies for the various lesion-gradings: (ars-has-therapy (HPS = 4) ) Enter therapy: autologous-BMT The user enters that autologous-BMT is a possible therapy for grading 4 of HPS (haemopoietic syndrome). The system continues by asking for possible therapies for every lesion-grading. It then starts asking for the indicators and contra-indicators of these therapies. (ars-has-contra-indicator (ars-has-therapy (HPS = 4) autologous-BMT) ) Enter Finding: stem-cells-preserved = no (ars-has-contra-indicator (ars-has-therapy (HPS = 4) autologous-BMT) ) Enter Finding: identical-twin-available = no Figure 8.10: A transcript of a part of the knowledge elicitation session for the ARS application.

and well structured, so it is not expected that the system will have to traverse huge search spaces. The following meta rules specify when the two generic task instances may be invoked. It is assumed that when control is passed to the task invocation module, the presence of hypotheses in the hypotheses space indicates whether the task has been completed. IF Hypotheses-space of ARS-Grading = empty THEN invoke-task-instance ARS-Grading

IF Hypotheses-space of ARS-Grading = NOT empty AND Hypotheses-space of Select-ARS-Treatment = empty THEN invoke-task-instance Select-ARS-Treatment

For each of the generic task instances, the local control regimes must also be specified. The suitability of a particular control regime depends on the goal that is associated with the task. For ARS-grading this is “grading the disease”. Computationally, this is an easy kind of diagnosis, because it allows us to make the single fault assumption: according to the application ontology a lesion can only have one true grading. Because of the single fault assumption and because there is a finite number of possible gradings, the search space is finite. Furthermore, in this particular case the search space is very small. The attractive computational characteristics allow for a straightforward control regime. First the data are obtained, then all the possible abstractions are made, and then the hypotheses are generated. The following meta rules implement this strategy for ARS-grading. IF Observable-Data-Space = empty THEN Invoke-inference Request-Data


147

IF Observable-Data-Space = NOT empty AND Patient-Findings Space = Empty THEN Invoke-inference Abstraction

IF Hypotheses-space = empty AND Patient-Findings Space = NOT empty THEN Invoke-inference Abduction

8.8.2

Selecting Problem Solvers

As argued in chapter 7, the problem solvers that implement the inferences should be both epistemologically and computationally adequate. Considering the limited amount of domain knowledge, it is not likely that computational complexity will be an important issue in this case. Therefore, the discussion will focus on epistemological adequacy. A problem solver is epistemologically adequate if the distinctions between different kinds of knowledge in the domain are preserved in the data structures used by the problem solver. In chapter 7 this idea was operationalized by means of mappings between the application ontology and representational meta models of the problem solvers. When the mappings are simple, the problem solver is epistemologically adequate. Diagnostic abduction Diagnostic abduction is performed by traversing tuples of the relation ars-manifestation-of. As can be seen in Fig. 8.7, the abductive inferences are straightforward: the findings are directly associated with the hypotheses that they trigger and no uncertainty is involved. Such associational reasoning can easily be performed by a forward-chaining production-rule interpreter. Therefore, the representational meta model of a simple rule interpreter is selected from CUE’s problem solver library. Fig. 8.11 shows this model using QUOTE’s graphical representation. has-condition

rule

condition

has-counter condition

counter-condition

has-action

action

expression-list

contains

1

2

attribute-expression 1

attribute

2

object

3

attribute-value

Figure 8.11: The representational meta model of a production-rule interpreter, represented using QUOTE’s graphical

language.

The representational meta model specifies that a rule consists of three sets of attribute expressions: conditions, counter-conditions and actions. Attribute expressions are the symbol-level equivalent of findings in the application ontology. They consist of an attribute, an operator and an attribute-value. The representational meta model makes an explicit distinction between

148


conditions and counter-conditions. A rule may fire when all of its conditions and none of its counter-conditions are true. There are two reasons for making this distinction. Firstly, without this distinction, modeling of attribute expressions would be more complicated, since there would be a need for “negative” attribute expressions. Secondly, as we will see later, conditions and counter-conditions are often mapped onto different ontological concepts. The semantics of the representational meta model are that a rule may fire when all of its conditions are satisfied and when none of its counter-conditions are satisfied. There are different ways to map the relevant parts of the application ontology onto the representational meta model. The main ontological concept for the mapping is the ars-manifestation-of relation. A straightforward way of mapping this relation onto the representational meta model is to generate a rule for every tuple of the relation. The mappings could then be specified as shown in Fig. 8.12. (ars-manifestation-of (ars-lesion-indication ?li = ?v) (ars-lesion-grading ?lg = ?g)) :-> (and (rule ?rule) (has-condition ?rule ?condition) (contains ?condition (attribute-expression ?li patient ?v)) (has-action ?rule ?action) (contains ?action (attribute-expression ?lg patient ?g)))

Figure 8.12: A simple mapping from the ars-manifestation-of relation onto the representational meta model of

the production rule system. The mappings are specified by means of mapping rules. On both sides of a mapping rule are expressions in CUE’s logical notation. The expressions may contain variables. When the mapping rules are applied, every expression that can be unified with the left-hand side of the mapping rule can be rewritten as the right-hand side.

One complication that must be handled is that the second argument of finding (of which ars-lesion-indication and ars-lesion-grading are subtypes) may be either =, whereas in the attribute expressions in the representational meta model it can only be specified that an object has a particular value for an attribute. Thus, only the = operator may be used. Further, there is no explicit representation of the object of the attributes (the patient) in the application ontology. In the mappings in Fig. 8.12 this is handled by enforcing that only findings with the = operator may be mapped and by using the constant patient as a dummy object in the attribute expressions in production rules. Inspection of the application knowledge shows that the restriction to the = operator does not cause problems. A problem with the mapping in Fig. 8.12 is that it generates a large number of hypotheses. As soon as one of the manifestations of a particular grading has been established, the hypothesis will be generated. In the ARS domain a more conservative abductive strategy is preferred: a lesion grading should only be hypothesized if all of its manifestations are present. This can be realized by specifying the mapping rules in such a way that all the manifestations are grouped in the condition part of a single rule. Note that the representational meta model does not allow disjunctive conditions. Although allowing disjunction does not affect the representational power of the formalism — it is equivalent to the introduction of extra rules — it may affect the mapping relations. For example, if disjunctions are allowed, it is always possible to generate one and only one rule for every possible action. If disjunction is not allowed, this is only possible in cases where every condition is a necessary condition, and if there are no subsets of the set of conditions that are sufficient for the action.


149

In terms of the application ontology, this means that a particular lesion grading can only be the true grading if all of its associated manifestations are present. As described in Sec. 8.4, this requirement is met in the ARS domain. It was for this reason that the attributes frequency and evoking-strength were left out of the application ontology. The mapping is realized by means of the rules shown in Fig. 8.13. (ars-lesion-grading ?lg = ?g) :-> (and (rule ?rule) (has-action ?rule ?action) (contains ?action (attribute-expression ?lg patient ?g)))

(ars-manifestation-of (ars-lesion-indication ?li = ?v) (ars-lesion-grading ?lg = ?g)) :-> (=> (and (rule ?rule) (has-action ?rule ?action) (contains ?action (attribute-expression ?lg patient ?g)) (has-condition ?rule ?condition)) (contains ?condition (attribute-expression ?li patient ?v)))

Figure 8.13: The mapping rules that are used for diagnostic abduction in the ARS application.

The first mapping rule in Fig. 8.13 states that for every lesion grading in the epistemological model there is a rule in the computational model, where the action part of the rule asserts a particular lesion-grading. The second mapping expresses that for every tuple of the ars-manifestation-of relation which has the particular lesion-grading as its second argument, the rule that is based on that grading has a condition that corresponds to the first argument of the tuple. Diagnostic abstraction In the application ontology, the abstractions are modeled by means of ars-abstracted-from relations between findings and lesion indications. In the computational model, we must specify the procedures that compute the abstractions and build a wrapper around these procedures to ensure that they can be invoked in the same way as “real” problem solvers. As mentioned, the complexity of the abstractions in the ARS domain ranges from simple table lookups to complex computational procedures. We will concentrate here on one abstraction of each type. An example of a simple qualitative abstraction is the derivation of the lesion-indicator vomiting-severity from the data vomiting-time and accident-time. The value of this indicator must be one of five time periods, which represent the time period in hours between the exposure to radiation and the moment of vomiting. The Lisp function shown in Fig. 8.14 is used to compute the vomiting severity. A complex kind of abstraction is the derivation of the severity of the granulocyte decrease. This lesion indicator, which is an indicator of the severity of the lesion to the haemopoietic system, is abstracted from a measurement of the granulocytes concentration and the measurement time relative to the date of the radiation exposure. The severity of the decrease is expressed by a number between 1, meaning not severe, and 5, meaning very severe. The value of the granulocyte

150


(defun compute-vomiting-severity (accident-time vomiting-time) (let ((period (- vomiting-time accident-time))) (cond ((< period 0.2) ’(0 0.2)) ((< period 0.5) ’(0.2 0.5)) ((< period 2.0) ’(0.5 2.0)) ((< period 6.0) ’(2.0 6.0)) (t ’(6.0 :infinity)))))

Figure 8.14: The Lisp function that computes the vomiting severity abstraction.

decrease is computed by comparing the measured granulocyte concentration with time-dependent threshold values. The computation of the threshold values is based on a quantitative model of the development of the granulocytes concentration, which can be expressed by means of the function g : g (t)

=

a

,

a

+b

,at x +

e

, a

a

b

,bt x + a e,bt y

e

The model is based on four parameters: x, the number of maturing granulocytes in the bone marrow; y , the number of granulocytes in the blood; a, the the maturation time of granulocytes and b, the loss rate of granulocytes. The severity of the haemopoietic lesions can be modeled in terms of values for the four parameters in the model. To generate the functions that discriminate between the five levels of severity of the haemopoietic lesion, the parameter values shown in Table 8.5 are used. (These values are based on empirical results.) degree

x

y

a

b

1-2 2-3 3-4 4-5

101 120 105 100

5 5 5 5

1 0.475 0.166 0.062

2.4 2.4 2.4 1.185

Table 8.5: Parameter values for the threshold functions to discriminate between different values of the granulocyte-

decrease abstraction.

The Lisp function that computes the granulocyte-decrease abstraction is shown in Fig. 8.15. To embed the Lisp functions in the KBS they must be wrapped in an object that can be invoked as a problem solver. In the current application this is realized by wrapping the abstraction functions into production rules. The conditions of these production rules are used to bind the parameters of the Lisp functions to particular values, and the actions are used to write the function result to the appropriate space of the blackboard. Diagnostic data entry In the ARS application, the diagnostic data are derived from computerized medical records. In Sec. 8.4 it was explained that the diagnostic data are modeled by means of ars-datum, a specialization of finding. However, the data are not represented in this format in the medical record.


151

(defun compute-granulocyte-decrease (concentration time) (flet ((threshold-function (x y a b) (+ (* (/ a (- b a)) (exp (* -1 a time)) x) (* (/ a (- a b)) (exp (* -1 b time)) x) (* a (exp (* -1 b time)) y)))) (cond ((< concentration (threshold-function 101 5 1 2.4)) 5) ((< concentration (threshold-function 120 5 0.475 2.4)) 4) ((< concentration (threshold-function 105 5 0.166 2.4)) 3) ((< concentration (threshold-function 100 5 0.062 2.4)) 2) (t 1))))

Figure 8.15: The Lisp function that computes the granulocyte decrease abstraction.

In order to enable the ARS application to make use of the data in the database, a transformation must be defined between the ars-datum concept and the database schema. As with problem solvers, this is done in two steps: first, make a mapping between the ontology and a representational meta model of the database, and then use a translation program to translate between the representational meta model and the actual database representation. For the present purpose, a simple database representational meta model is used: a database consists of sections, and each of these sections consists of a number of records. In turn, records consist of a number of fields. Different sections of the database may have different kinds of records, but, within a section, all records must have the same types of fields. Fig. 8.16 shows the mappings between the representational meta model and the application ontology for the erythema part of the database (see Table 8.1).

(has-record erythema-section ?erythema-location ?yes no ?unknown ?begin ?end ?maximum ?degree) :-> (ars-datum ?erythema-location = no)

(has-record erythema-section ?erythema-location yes ?no ?unknown ?begin ?end ?maximum ?degree) :-> (and (ars-datum ?erythema-location = ?degree) (ars-datum.time-stamp (ars-datum ?erythema-location = ?degree) (time-interval ?begin ?end)))

Figure 8.16: The mapping rules used for diagnostic data entry.

152


The mapping between the database records and the application ontology has a different nature from the mappings between the ontology and the representational meta models of the problem solvers described earlier. In contrast with the earlier mappings, the mapping shown in Fig. 8.16 is specific for one particular kind of ars-datum, namely data about erythema. For each of the different kinds of data used in the application another mapping must be defined. This is necessary because the ARS database uses a variety of record structures.

Therapeutic Abduction For therapeutic abduction, the relations ars-has-therapy and ars-has-contra-indicator are used. ars-has-therapy directly connects the therapeutic problems to the therapies. This suggests that, as for diagnostic abduction, the production rule interpreter might be suitable. However, for therapy planning the situation is more complicated because we must also deal with the indicators and the contra-indicators. The indicators are conditions that must hold for the therapy to be appropriate. It is clear that these can be realized computationally as additional conditions in the production rules. The contra-indicators can be realized as counter-conditions in the production rules. Fig. 8.17 shows the mapping rules that implement this operationalization. (ars-has-therapy (lesion-grading ?l1 = ?v) ?t) :-> (and (rule ?rule) (has-action ?rule ?action) (contains ?action (attribute-expression therapy patient ?t)) (has-condition ?rule ?condition) (contains ?condition (attribute-expression ?l1 patient ?v)))

(ars-has-indicator (ars-has-therapy (lesion-grading ?l1 = ?g) ?t) (finding ?ob = ?v)) :-> (=> (and (rule ?rule) (has-action ?rule ?action) (contains ?action (attribute-expression therapy patient ?t)) (has-condition ?rule ?condition) (contains ?condition (attribute-expression ?l1 patient ?g)) (contains ?condition (attribute-expression ?ob patient ?v)))

(ars-has-contra-indicator (ars-has-therapy (lesion-grading ?l1 = ?g) ?t) (finding ?ob = ?v)) :-> (=> (and (rule ?rule) (has-action ?rule ?action) (contains ?action (attribute-expression therapy patient ?t)) (has-condition ?rule ?condition) (contains ?condition (attribute-expression ?l1 patient ?g)) (has-counter-condition ?rule ?counter-condition)) (contains ?counter-condition (attribute-expression ?ob patient ?v)))

Figure 8.17: The mapping rules used for therapeutic abduction in the ARS application.


153

Therapeutic abstraction and data entry We can be brief about the problem solvers that are selected for therapeutic abstraction and therapeutic data entry. Both inferences make the same ontological commitments as the corresponding steps in the diagnostic subtask, and are therefore implemented in a similar way. Table 8.6 summarizes which problem solvers were selected to implement the inferences in the ARS task model. Inference

Problem solver

diagnostic request data diagnostic abstraction diagnostic abduction therapeutic request data therapeutic abstraction therapeutic abduction

ARS Database Lisp functions production rules ARS Database Lisp functions production rules

Table 8.6: Problem solvers used in the ARS application.

8.8.3

Translating the Knowledge

Once the mappings between the ontology and the representational meta models have been specified, translating the knowledge to the particular formalisms is largely an automatic process. As was mentioned in chapter 7, the representational meta models are associated with procedures that translate back and forth between the representational meta models and the internal representations of the problem solvers. The mappings between the application ontology and the representational meta models can therefore be considered as a specification of how the knowledge in the epistemological model should be represented in the computational model. For example, the knowledge pieces which were elicited in Fig. 8.10 are translated according to the mapping rules shown in Fig. 8.17 into the following attribute expression in terms of the representational meta model: (rule rule34) (has-action rule34 action34) (contains action34 (attribute-expression therapy patient autologous-BMT)) (has-counter-condition rule34 counter-condition34) (contains counter-condition34 (attribute-expression identical-twin-available patient no)) (contains counter-condition34 (attribute-expression stem-cells-preserved patient no))

These attribute expressions are then translated automatically into production rules in the syntax of the particular production rule interpreter: IF NOT identical-twin-available patient no AND NOT stem-cells-preserved patient no THEN therapy patient autologous-BMT

154


8.9 QUAARS in Action To illustrate how the final system solves problems in the ARS domain, this section presents an execution trace where the system diagnoses the haemopoietic syndrome. In the trace, the system retrieves 8 pieces of data from the database and uses these to abstract the severity of the vomiting reaction, the severity of the diarrhea reaction and the severity of the granulocyte decrease. Based on these findings, the system derives that the haemopoietic syndrome has grading 4. > (quaars) ;;;-----------------------------------------------------------;;; QSHELL (Version 0.1) ;;;----------------------------------------------------------------- Invoking Task ARS-GRADING ------ Invoking Inference REQUEST-DATA ------ Retrieving data from database Retrieved: (ars-datum radiation-exposure = yes) Retrieved: (ars-datum.time-stamp (ars-datum radiation-exposure = yes) (time-point )) Retrieved: (ars-datum vomiting = yes) Retrieved: (ars-datum.time-stamp (ars-datum vomiting = yes) (time-point )) Retrieved: (ars-datum diarrhea = yes) Retrieved: (ars-datum.time-stamp (ars-datum diarrhea = yes) (time-point )) Retrieved: (ars-datum granulocyte-count = 3.5) Retrieved: (ars-datum.time-stamp (ars-datum granulocyte-count = 3.5) (time-point )) ------ Invoking Inference ABSTRACTION ------ Mapping inputs from DATA space to Representational Meta Model of ABSTRACTION-WRAPPER Mapped: (ars-datum radiation-exposure = yes) :-> (attribute-expression radiation-exposure patient yes) Mapped: (ars-datum.time-stamp (ars-datum radiation-exposure = yes) (time-point )) :-> (attribute-expression time radiation-exposure ) Mapped: (ars-datum vomiting = yes) :-> (attribute-expression vomiting patient yes) Mapped: (ars-datum.time-stamp (ars-datum vomiting = yes) (time-point )) :-> (attribute-expression time vomiting )


Mapped: (ars-datum diarrhea = yes) :-> (attribute-expression diarrhea patient yes) Mapped: (ars-datum.time-stamp (ars-datum diarrhea = yes) (time-point )) :-> (attribute-expression time diarrhea ) Mapped: (ars-datum granulocyte-count = 3.5) :-> (attribute-expression granulocyte-count patient 3.5) Mapped: (ars-datum.time-stamp (ars-datum granulocyte-count = 3.5) (time-point )) :-> (attribute-expression time granulocyte-count ) ------ Translating inputs to representation of ABSTRACTION-WRAPPER Finished ------ Invoking Problem solver ABSTRACTION-WRAPPER Finished ------ Translating outputs of ABSTRACTION-WRAPPER to Representational Meta Model Finished ------ Mapping outputs from Representational Meta Model of ABSTRACTION-WRAPPER to PATIENT-FINDINGS Mapped: (attribute-expression vomiting patient severe) :-> (ars-lesion-indication vomiting = severe) Mapped: (attribute-expression diarrhea patient severe) :-> (ars-lesion-indication diarrhea = severe) Mapped: (attribute-expression granulocyte-decrease patient severe) :-> (ars-lesion-indication granulocyte-decrease = severe) ------ Invoking Inference ABDUCTION ------ Mapping inputs from PATIENT-FINDINGS space to Representational Meta Model of Q-CHAIN Mapped: (ars-lesion-indication vomiting = severe) :-> (attribute-expression vomiting patient severe) Mapped: (ars-lesion-indication diarrhea = severe) :-> (attribute-expression diarrhea patient severe) Mapped: (ars-lesion-indication granulocyte-decrease = severe) :-> (attribute-expression granulocyte-decrease patient severe) ------ Translating inputs to internal representation of Q-CHAIN Finished

155

156


------ Invoking Problem Solver Q-CHAIN Finished ------ Translating outputs of Q-CHAIN to Representational Meta Model Finished ------ Mapping outputs from Representational Meta Model of Q-CHAIN to HYPOTHESES space Mapped: (attribute-expression HPS patient 4) :-> (ars-lesion-grading HPS = 4)

8.10 Conclusions This chapter addressed the top of the methodological pyramid described in chapter 2: using the methodology. According to the pyramid, use provides feedback about the tools, the methods the theory and, ultimately, about the world view. This section summarizes some of the conclusions that can be drawn about the GAMES theory, methods and tools.

Theory With respect to the theory layer, the case study presents feedback about the use of the STModel, the separation of application ontology and application knowledge, and about knowledgebased integration. With respect to the STModel, it may be concluded that it was not difficult to describe the reasoning process in terms of the inferences distinguished in this model. The structure of the model was exploited for developing the application ontology (the guidelines A.1 and A.2 in Sec. 8.4) and for computational design: each of the inferences in the STModel was associated with the problem solver that was appropriate for that inference. With respect to the separation of application ontology and domain knowledge an interesting phenomenon occurred. Developing the application ontology was by far the most time consuming part of the development process. However, once the application ontology was completed, elicitation of the application knowledge was straightforward. Secondly, the separation turned out to be very useful for computational design. The application ontology provides “handles” on the domain knowledge so that design decisions can be taken in terms of collections of domain knowledge expressions. For example, the decision to represent contra-indicators as counter-conditions in the production rules was taken at one time. Without the explicit representation of the application ontology as a meta model, this decision should have been taken for each contra-indicator individually. Knowledge-based integration as a means for achieving communication between problem solvers was successfully applied in the ARS application. Although the production rule interpreter is the only “real” problem solver part of the application, it is used in different ways in different parts of the problem solving process. Further, knowledge-based integration ensures that the knowledge in the problem solvers remains connected to the knowledge in the application ontology. This is important for making knowledge-based systems less brittle. For example, in principle the ARS application “knows” that a lesion is related to a body part. Although this information is not represented in the production rules, it is represented in the application ontology which is connected to the rules by means of the mappings.


157

Methods In chapter 2, four activities were distinguished for epistemological modeling, which were all performed for the ARS application. Most of the effort was dedicated to the development of the application ontology. GAMES acknowledges that this is a difficult activity and provides a library to support this process. A number of guidelines were formulated to use the library for developing a full-fledged application ontology. In short, these guidelines amount to the principles that (i) ontology development should start with modeling the concepts that play the primary roles in the reasoning process, (ii) concepts are suitable when they are sufficiently general to cover all the knowledge pieces that play a particular role in the reasoning process and when they are sufficiently specific to reflect all relevant distinctions, and (iii) new concepts can be defined by specializing and modifying general concepts that can be found by terminological matching. The application ontology constructed by applying these principles is described in Appendix C. The other activities in epistemological modeling: task modeling, ontology mapping and knowledge elicitation were straightforward, mainly because of appropriate tools. For developing the computational model, GAMES distinguishes three activities: (i) specifying meta rules, (ii) selecting problem solvers, and (iii) translating the knowledge. The specification of the meta rules was simple because the task characteristics allow a straightforward control regime. The chapter therefore mainly concentrated on the second and the third activity. It was shown that the use of representational meta models, as a layer of abstraction between the epistemological model and the representations of the problem solvers, facilitates selection of problem solvers. These models make explicit what the problem solvers can and cannot represent. The representational meta models also make it possible to automate a large part of the translation process while the knowledge engineer keeps control over how the knowledge will be represented in the problem solver. Tools Tools are good inasmuch as they support the methods of the methodology. In the ARS case study, CUE’s tools for epistemological modeling were used for developing the task model, for constructing the application ontology, for specifying the mappings between the task model and the application ontology and for eliciting the domain knowledge. Thus, the four main activities in the GAMES epistemological modeling process are supported. For computational modeling, we used a mapping rule interpreter, a blackboard shell (the QSHELL) and a production rule interpreter. CUE contains no tools which support the activities in computational modeling. This chapter has illustrated the two main roles of ontologies in knowledge engineering that are distinguished in this thesis: to drive knowledge acquisition and to support computational design.

158


Chapter 9

Conclusions and Discussion In the previous chapters, a number of ways have been described in which explicit ontologies can be used in the knowledge engineering process. This chapter will review the conclusions of each of those chapters, and use these to formulate answers to the research questions that were put forward in chapter 1.

9.1 Review of the Individual Chapters Chapter 2 presented the GAMES approach to knowledge engineering. In this approach, knowledge acquisition is viewed as the construction of two models, the epistemological model and the computational model. The construction of each model involves a number of distinct activities which require different kinds of expertise. One activity for epistemological modeling is the construction of an explicit model of the kinds of domain knowledge that are used in problem solving — the application ontology. It was argued that the availability of this model is useful for managing the interaction with the expert during later stages in the knowledge acquisition process, and also that it facilitates computational design. Chapter 3 presented the paradigm of model-based knowledge acquisition as a general framework for describing tools that support the KA process. This paradigm views knowledge acquisition as a process that consists of four separate activities: skeletal-model construction, model instantiation, model compilation and model refinement. Each of these activities can be supported in a number of different ways by knowledge acquisition tools. An analysis of the history of knowledge acquisition tools showed that there is a trend towards concentrating more and more on the use of explicit skeletal models of the knowledge to be acquired. In the past, different types of skeletal models have been used. What has been missing until now is a theory about the kinds of information which should be present in skeletal models for providing different types of support for the other activities in the framework. Chapter 4 described generalized directive models, or GDMs. These are task models that leave parts of the task which is being modeled unspecified. The unspecified parts can be filled in later, when more is known about the nature of the domain knowledge. Initially, the idea of GDMs was that they allow interleaving of the skeletal-model construction and model instantiation activities. However, a closer look at the way GDMs are used revealed that they actually interleave task modeling and ontology modeling, two steps within the skeletal-model construction activity. The GDMs are constructed using a GDM grammar that specifies possible ways in which a part of the 159

160


skeletal model can be filled in. The rewrite rules in the grammar have associated conditions which express the ontological commitments that the rewrite rules require. Chapter 5 discussed two problems that impede the development of libraries of reusable ontologies: the hugeness problem and the interaction problem. It was argued that these problems can be addressed by associating a domain-specificity index and a method-specificity index to the concepts defined in an ontology. In this way it is made explicit under which circumstances ontological concepts and their instantiations can be used in a knowledge-based system. Chapter 6 presented CUE, a knowledge engineering workbench developed according to the model-based KA paradigm. The system consists of QUITE, a tool for task modeling, QUOTE, a tool for constructing application ontologies, and QUAKE, a tool that supports the model-instantiation activity. A large part of the chapter is dedicated to the description of the ways in which QUAKE exploits the application ontologies developed with QUOTE to organize the knowledge-elicitation process. QUAKE uses the ontology to take decisions about (i) the consistency of the elicited knowledge, (ii) the completeness of the elicited knowledge, (iii) which terminology to use in the knowledge elicitation dialogue and (iv) how to visualize the elicited knowledge. The chapter also discussed the notion of knowledge-elicitation strategies and suggested principles on which they can be based. Chapter 7 illustrated how application ontologies can be used for the computational design of a knowledge-based system. The chapter argued that in domains with different types of knowledge, the requirement of computational adequacy may require that KBSs consist of multiple problem solvers. These problem solvers might use different representation formalisms. In order to let the problem solvers communicate, it must be specified what the expressions in one formalism mean in terms of the other formalisms. In existing systems which make use of multiple formalisms, the integration is usually realized by means of fixed, syntactical mappings between the constituent formalisms. Chapter 7 argued that this kind of integration is not sufficient. Therefore, an alternative type of integration was suggested, which is based on the contents of the knowledge instead of on its syntactical form. For this type of integration — knowledge-based integration — an explicit model is needed of the knowledge that is represented. In chapter 7 application ontologies were used for this purpose. Finally, chapter 8 showed how the GAMES approach was applied to build a knowledge-based system that supports the management of acute radiation syndrome (ARS). The chapter presented guidelines for developing application ontologies and showed how these guidelines were applied for constructing the ARS ontology. Further, it was illustrated how the application ontology was used for developing a computational model.

9.2 Synthesis In chapter 1, the problem addressed in this thesis was formulated as follows: How can explicitly represented ontologies be obtained and used to make the knowledge engineering process more manageable? This problem was then divided into three specific research questions: (i) how can the knowledge engineering process be organized in such a way that explicit ontologies are useful, (ii) how can explicit ontologies be constructed and (iii) can ontologies be reused with different problem-solving

Chapter 9: Conclusions and Discussion

161

methods? This section presents an attempt to answer each of these questions, using the results of the individual chapters. 1. How can the knowledge engineering process be organized to maximize the leverage of explicitly represented ontologies? In methodologies which take a knowledge-level stance, the knowledge acquisition process consists of two parts: (i) the construction of a knowledge-level model of the expertise required for problem solving and (ii) the construction of a design model for the computational realization of the problem-solving behavior. We have called these models the epistemological model and the computational model respectively. An ontology is part of the epistemological model. It can be viewed as a layer of abstraction between the reasoning knowledge (the task model) and the domain knowledge. The construction of the epistemological model and the computational model requires five activities: (i) skeletal-model construction, (ii) model instantiation, (iii) model compilation, (iv) model refinement and (v) skeletal-model validation. The first two of these activities, skeletalmodel construction and model instantiation, yield an epistemological model. The third activity, model compilation, produces the computational model. The fourth activity, model refinement, is intended for verifying the run-time properties of the computational model. The fifth activity uses the instantiated skeletal model to assess the validity of the skeletal model. This thesis focused on the first three activities. To maximize the leverage of explicit ontologies, the activities can be decomposed in a number of distinct steps, which are described below. For each of the steps it will be explained how, and to which extent, they can benefit from an explicit ontology. Skeletal model construction Knowledge acquisition is facilitated by a strong skeletal model, which consists of both a task model and an application ontology. Therefore, the skeletalmodeling activity involves three steps: (i) building a task model, (ii) constructing an application ontology and (iii) connecting the two. In each of these steps, ontological considerations play a role.

Building a task model. The development of task models is a process of making increasingly detailed ontological commitments. To facilitate this process, the ontological requirements of the task model components should be formulated explicitly. Building an application ontology. To maximize the leverage of ontologies in knowledge engineering it is important that early in the knowledge engineering process a model is constructed of the ontological structure of the application knowledge. We have called this model the application ontology. For the construction of application ontologies, knowledge engineers can use a library. The organization of this library is based on the observations that (i) some concepts are natural categories in the domain, (ii) some concepts are specific for particular subdomains and (iii) some concepts are specific for the use of particular problem-solving methods (chapter 5). Mapping task model onto application ontology to complete the skeletal model. In order to obtain a fully-fledged skeletal model, the task model and the application ontology need to be connected. This can be done by means of mapping relations, which specify that only the instantiations of specific ontological constructs may play particular knowledge roles during problem solving.

162


Model instantiation This activity involves filling the skeletal model with domain knowledge. The ability to support model instantiation depends heavily on the availability of explicit ontologies. This is illustrated by QUAKE, a tool in the CUE workbench, which is able to inspect application ontologies written in Ontolingua. QUAKE uses a knowledge-acquisition oriented interpretation of the vocabulary defined in the Frame ontology — a representational ontology which defines the vocabulary for specifying Ontolingua ontologies — to support model instantiation by consistency checking, completeness checking, using domain-specific terminology, intuitive visualization and dialogue structuring. Model compilation The purpose of the model-compilation activity is to transform the epistemological model into a computational model. This involves three steps: (i) selecting problem solvers that are appropriate for implementing (parts of) the reasoning process, (ii) specifying the order in which the problem solvers must be invoked, and (iii) translating the application knowledge in the epistemological model into the private representation formalisms of the problem solvers. In each step, ontologies play a role.

Selecting appropriate problem solvers. Explicit application ontologies are indispensable for selecting adequate problem solvers. To decide whether a particular problem solver is suitable, its representational capacity must be compared with the epistemological distinctions in the domain knowledge. The application ontology is an explicit representation of these epistemological distinctions. Specifying a control regime. The application ontology can be useful in this step, as the suitability of a control regime can depend on ontological features of domain knowledge. For example, in the ARS application described in chapter 8, the — ontological — observation that a particular organ-system lesion can only have one true grading allowed the knowledge engineer to make the single-fault assumption, which in turn had consequences for the control regime. Translating the knowledge. The translation step is required because languages which are useful for knowledge modeling are usually not appropriate for efficient reasoning. The translation step can not be predefined by tool builders without losing either epistemological or computational adequacy. Therefore, the specification of the translation procedure must also be part of the knowledge engineering process. To facilitate this job, representational meta models can be used. A representational meta model is an explicit model of the types of things that can be represented in a representation formalism, but which abstracts from the syntactical details of the formalism. The translation can then be made by specifying mappings between the application ontology and the representation meta model of the selected problem solver.

2. How can explicitly represented ontologies be constructed? Ontologies can be built by selecting and configuring ontological theories from a library and by defining ontologies “from scratch”. To facilitate navigation in a library of reusable ontological theories, the theories should be indexed according to domain specificity and method specificity. The basic idea here is that some concepts are more reusable than others, and that the reusability of concepts depends on (i) how specific these are for particular domains and (ii) how specific these are for particular problem-solving methods.


163

An ontology library should be organized in a core part, containing definitions of the basic concepts in the field, and a peripheral part, containing definitions that are only needed for specific methods and specific subdomains. By indicating which subdomains and which methods are to be used in an application, the library indexes can be used to find definitions that are likely to be useful for the application. The core part is thus specific for a field (e.g. medicine) but generic across all specializations and tasks within that field. Often, the library will not contain entries for the subdomain and for the methods used by an application. For this situation, a number of guidelines have been developed for using the library as a source of inspiration. These guidelines were based on the considerations that (i) only concepts that are referred to by the task-model (and the concepts that they depend on) are needed for an application ontology, (ii) similar concepts will often have similar names, and (iii) it is easier to define new concepts by specifying or modifying existing concepts then to define concepts from scratch. When there is no library available, application ontologies must be developed by the knowledge engineer. For defining an ontological concept, the following guidelines can be used: (i) a concept should be sufficiently general to cover all the pieces of knowledge that the concept is intended for, (ii) a concept should be sufficiently specific to cover only those pieces of knowledge that the concept is intended for, and (iii) a concept should have a name that is meaningful in the application domain. 3. Can ontologies be reused with different problem-solving methods? The final question raised in chapter 1 refers to the reusability of ontologies. In this context, the interaction problem was mentioned. The interaction problem states that the way that knowledge is represented is determined by how that knowledge will be used in the reasoning process. The interaction problem can be managed by means of the explicit interaction principle: Different elements of an ontology are affected in different ways by the nature of the method that is used by an intelligent agent. By making the nature of the interaction between the method and the elements of the ontology explicit, it can be determined under which conditions ontological elements can be reused. The explicit interaction principle can be applied from a task perspective and from a domain perspective. The GDM approach is an example where the principle is applied from a task perspective. Here, the explicit representation of the interaction — the conditions on the rewrite rules — is exploited to develop task models. The use of a method-specificity index for organizing an ontology library is an example where the explicit interaction principle is applied from a domain perspective. Here, the explicit representation of the interaction — the method-specificity index — is exploited to guide the development of application ontologies. Given the methodological framework described above, we can formulate some requirements for KA tools that support that methodology. To provide strong support in knowledge acquisition, tools should be able to inspect and interpret skeletal models. In order to have a wide scope, these skeletal models should be editable and thus be represented explicitly. The skeletal models should contain both a task model and an application ontology. The task model is needed for determining which knowledge is needed for problem solving and the application ontology is needed for determining

164


the nature of that knowledge in the application domain. The knowledge acquisition tool should be able to give a KA-oriented interpretation of the information represented in the skeletal model.

9.3 A Perspective on Knowledge Engineering As announced in chapter 1, this thesis mainly concentrated on the usefulness of ontologies in the context of a systematic approach to knowledge engineering. In particular, the potential merits of ontologies in model-based knowledge acquisition have been discussed. To conclude this thesis, some of the assumptions and ideas that underly the present work are compared with the assumptions that underly the work of other researchers who investigate the potential role of ontologies in artificial intelligence. Most ontology-related research in AI is done for the purpose of knowledge sharing. Knowledge sharing refers to the idea that a knowledge base can act as a knowledge provider (a server) for other knowledge bases (clients). An influential research project in this context is the knowledge sharing effort (KSE) described in Neches et al. (1991). In an analysis of the obstacles that prohibit knowledge sharing between existing knowledge bases, one of the problems that these researchers identify is that servers and clients can make different ontological commitments. The solution proposed in the KSE project is to develop a library of standardized ontologies, and to enforce KBS developers to adhere to these ontological standards. To help KBS developers to comply with the standards, the Ontolingua language and program were developed. The Ontolingua language is the language which is used for encoding the library of ontologies. This language was also used for ontological modeling in this thesis. The Ontolingua program consists of a collection of translation routines that translate ontologies formulated in the Ontolingua language into the representation formalisms of a number of different problem solvers. The view on knowledge engineering that underlies the Ontolingua approach is that knowledge engineers first decide which ontological commitments must be made, then use the ontology library to make these commitments explicit, and then use their favorite tool for developing the knowledge base. Roughly speaking, this approach is similar to the approach to knowledge engineering advocated in this thesis, although in the Ontolingua approach many subtleties of the use of reusable ontologies for knowledge engineering remain unaddressed. For example, in theory the builders of the KSE ontology library do not take into account that a problem-solving method may require particular ontological commitments. That is, the approach does not provide guidelines for dealing with the interaction problem. In practice, however, the importance of the interaction problem is certainly recognized, as can be seen in the Ontolingua theories developed as part of the VT experiment (Schreiber & Birmingham, 1994). The ontology for this application is split into two theories: one which models concepts that are specific to elevators (the domain), and one that is specific to engineering design (the task). This is exactly what should have been done according to the principles put forward in chapter 5. A more serious problem with the Ontolingua approach to achieving knowledge sharing is that it requires that the knowledge bases are based on the same ontological commitments. Therefore, knowledge can only be shared between knowledge bases developed with that very purpose in mind. In the Ontolingua approach, a KBS can only share knowledge with other KBSs that are also developed using the KSE library. Unfortunately, the world is filled with knowledge bases and databases which are not developed according to this philosophy. The information in these servers cannot be shared. In this thesis, this problem was touched upon in chapter 8, where an external


165

database was used as an information server that provides input to the ARS application. Here, this problem was solved by wrapping the database into an ontological theory which conformed to the commitments in the application ontology. The wrapper was then connected to the database by means of accessor functions. A more generic solution for this problem is to use more flexible ways of specifying which ontological commitments are made in a knowledge base. In both the KSE library and the GAMES library, committing to the ontological distinctions defined in a theory means including that theory. That is, making the concepts in the included theory directly accessible to the includer. A more flexible way of connecting ontologies is to allow ontology mappings. The idea here is that knowledge bases have a base ontology and a number of ontologies that are developed for specific uses of the knowledge base. These use-specific ontologies are then connected to the knowledge base by means of mappings between the base ontology and the use-specific ontologies. The mappings, which specify different viewpoints on the contents of a knowledge base, can be used to reformulate the ontological commitments in the knowledge base in such a way that it is possible to share knowledge with another knowledge base. This possibility is currently being investigated in the European KACTUS project (Wielinga et al., 1994). This thesis has addressed questions about the utility of ontologies in KBS development. However, some important issues remain open with respect to the role of ontologies in knowledge engineering. One thing that needs to be investigated is the relation between ontologies as they are being used in knowledge engineering and similar concepts in related fields. For example, in the field of machine learning, much research effort is dedicated to the effects of different types of representational bias. This is reminiscent of the way in which QUAKE uses ontologies as knowledge elicitation bias. In the same way in which machine-learning algorithms may only learn particular types of expressions, QUAKE may only elicit particular types of expressions. It would be interesting to see to what extent representational bias corresponds to our notion of ontologies. Other concepts which are related to ontologies include meaning postulates in formal linguistics and conceptual schemata in database research. Another open issue concerns the “right” language for defining ontologies. In this thesis, Ontolingua was used, but other languages have been proposed as well in the literature (e.g. CML; Schreiber et al., 1994, MODEL; Gennari, 1993 etc.). To date, there are no generally agreedupon criteria for deciding which of these languages, if any, is the most appropriate language in a particular situation. The formulation of such criteria is an important research goal, which can only be achieved by collecting experiences in using these languages and reporting their strengths and weaknesses. A third research issue concerns the hugeness problem mentioned in chapter 5. Realistic ontology libraries will contain large numbers of concepts with all kinds of dependencies. In this thesis, a number of principles were put forward for keeping the hugeness problem manageable by indexing on domain specificity and method specificity. However, when the libraries grow larger it is likely that more principles will be needed. The identification and formulation of these principles is one of the most important challenges for ontological-engineering research in the near future.

166


Appendix A

GDM Grammar for Design This appendix presents a slightly revised version of the GDM grammar for modeling design problem solving which was developed by Allemang and van Heijst (Allemang & van Heijst, 1993). The grammar is presented here as an illustration of the use of GDMs to generate KADSlike inference structures. The informal nature of the conditions associated with the rewrite rules was one of the main reasons for directing our attention to ontologies. It should be emphasized that we do not claim that the contents of the grammar are a valid or complete theory of design problem solving. The main purpose of formulating this grammar was to illustrate the close correspondence between the work on KADS and the work on Generic Tasks. The contents of the rules represent our interpretation of the the analysis of design problems solving described in (Chandrasekaran, 1990). The rewrite rules are written down using the KADS graphical notation, where ellipses represent knowledge sources, double ellipses represent generalized knowledge sources and boxes represent meta classes. The boxes which are labeled ?input1, ?input2 or ?output represent variables that can be unified with meta classes in the generalized directive model. For readability, these variables have been typed. In the actual implementation of the grammar, the type constraints are specified in the conditions associated with the rule. rule 1 ?output:design

?output:design

NT-Design

T-Select

?input1:spec

?input2:parts

?input1:spec

?input2:parts

Conditions:

For every possible specification there is a component in the parts library that satisfies that specification.

Comments: This is the trivial form of design: design as selection.

167

168


rule 2 ?output:design

?output:design

NT-Design

NT-PVCM

?input1:spec

?input2:parts

?input1:spec

?input2:parts

Comments: This is the default rule. It is always applicable if design by selection is not applicable. rule 3 Faults

NT-Critique

?output:design

NT-Verify

Critisism

NT-PVCM

Design

NT-Modify

?input1:spec

?input2:parts

?output:design

NT-Propose

?input2:parts

?input1:spec

Comments This is the main form of design distinguished by Chandrasekaran. Design can be decomposed into four basic subtasks: (i) propose a design, (ii) verify it, (iii) if the design does not satisfy the specifications, locate parts of the design that need modification and (iv) apply the modifications. rule 4 ?output:design

NT-combine Compbination Knowledge

Subdesigns

?output:design

NT-Design

NT-Propose

Subproblems

?input1:spec

?input2:parts

T-Abstract

T-Abstract ?skeletal-plan

T-Select

?input1:spec

Conditions:

There are design plans available in the domain.

Design Plans

?input2:parts

Appendix A: GDM Grammar for Design

169

Comments: A design plan consists of a set of design subtasks which are known in advance and knowledge how to combine the results of the subtasks. rule 5 ?output:design

NT-Combine ?output:design

subdesigns

NT-Propose

Nt-Design

?input1:spec

?input2:parts

?input2:parts

?skeletal-system-model

subproblems T-Decompose ?input1:spec

Conditions:

There are skeletal system models available in the domain.

Comments: This is design by configuration. A skeletal system model is an abstract design model which needs to be made concrete by “filling” the skeletal model with specific parts. rule 6 ?output:design

NT-Modify ?output:design

NT-Propose

?input1:spec

?input2:parts

?input2:parts

Similar Case

T-Select

Case Library

?input1:spec

Conditions:

There is a properly indexed library of solved cases available.

Comments: This is the case based method of design.

170



?output:design

Conflict Sets

T-Assign-Value

NT-Propose

T-Propagate

?input1:spec

?input1:spec

?input2:parts

Instantiated Constraint Model T-Assemble

?constraint-model

?input2:parts

Conditions:

There is a finite set of possible designs. There is a constraint model in the domain.

Comments: One way of designing is to simply generate all possible designs, and then let some reasoner (e.g. a TMS) find inconsistencies using a constraint model. This approach is only feasible in cases of parametric design. rule 8 ?output:design ?output:design

NT-Propose

?input1:spec

Conflict Sets

T-Assign-Value

T-Propagate

Instantiated Constraint Model

?input2:parts

?input1:spec

T-Assemble

Constraint Model

?causal-model

?input2:parts

T-Transform

Conditions:

There is a finite set of possible designs. There is a causal model in the domain which is sufficiently strong to derive a constraint model.

Comments: This rule is similar to the previous rule, but now the constraint model is derived from a causal model.


171

rule 9 ?output:faults

?output:faults

NT-Verify

T-Simulate

?input1:design

Simulation-model

Test Cases

?input1:design

Conditions:

There is a simulation environment for testing designs.

Comments: Designs are often verified by means of computer simulations. It may be necessary to make some test data from the specifications as well. rule 10 ?output:faults ?output:faults

Prototype

NT-Verify

Result

T-Compare

T-Run

?specifications

T-Build

?input1:design

?input1:design

Conditions:

This method can be used if you have the technology and the resources to build a prototype and if it is possible to work out a representative set of test data from the specifications.


?output:design

NT-Combine

T-Assemble

?input1:designs

?input2: combination-rules

?input1:designs

?input2: combination-rules

Comments: This rule has no competitors. rule 12 ?output:critisism

?output:criticism

NT-Critique

T-Match

?input1:design

?input2:faults

?input1:design

?input2:faults

172


Conditions:

This method is applicable if the design contains information that allows going directly from the faults to the parts that are responsible.

Comments: This rule implements critiquing by deduction along back links. This means that the abductive knowledge is compiled into deductive knowledge. rule 13 ?output:critisism

?output:criticism

NT-Critique

T-Abduce

?input1:design

?input2:faults

?input1:design

?input2:faults

?causal-model

Conditions:

There must be some causal model that specifies how the parts in the design contribute to what the design does.

Comments: In practice, this rule is always applicable. If there is no way to go from the design to something what the design does you can’t do anything at all. rule 14 ?output:design

?output:design

?input1:design

NT-Modify

Partial Derivates

T-Compute

?input2:parts

?input3:criticism

?input1:design

?input2:parts

?input3:critisism

Conditions:

The criticism must be of the type that only parameter vales in the design are wrong, but that the selected parts are in principle appropriate. There must be knowledge of how changes in design parameters propagate to other design parameters (the partial derivates).

Comments: We speak about partial derivates because they relate a change in one thing to a change in another. Qualitative derivates are sufficient. rule 15 ?output:design

?output:design

?input1:design

NT-Modify

T-Match

?input2:parts

?input3:criticism

?input1:design

?input2:parts

?input3:critisism


173

Comments: This rule simply depends on the availability of a part library. Since this is assumed for the entire task this rule is always applicable.

174


Appendix B

A Part of MOLE’s Elicitation Strategy is a knowledge acquisition tool for systems that apply the Cover-and-Differentiate problem solving method. This appendix describes a part of MOLE’s ontology using Ontolingua and a part of MOLE’s knowledge elicitation strategy in CUE’s strategy language. The descriptions of both the ontology and the knowledge acquisition method are based on Eshelman’s description in (Eshelman, 1988). Knowledge acquisition in MOLE consists of two phases: a static phase and a dynamic phase. These phases correspond to what chapter 3 called model instantiation and model refinement. MOLE’s static phase consists of three steps: MOLE

Elicit initial symptoms, Elicit covering knowledge, Elicit differentiating knowledge.

We have only modeled the strategy of the first two steps in CUE’s elicitation strategy language. The strategy that MOLE uses for eliciting differentiating knowledge depends on detailed characteristics of MOLE’s ontology, which are not explicated in the literature. For example, depending on the structure of the causal network, MOLE sometimes needs “event qualifying” knowledge or “connection qualifying” knowledge. However, we could not determine the (ontological) conditions under which this knowledge is needed.

B.1 MOLE’s Ontology This section shows the part of MOLE’s ontology relevant for understanding how MOLE acquires its initial symptoms and its covering knowledge. MOLE’s ontology is basically a causal network where the nodes are events and the links are causal relations. In MOLE’s terminology, events are called causes or hypotheses. When the causal links are interpreted in the abductive direction, they are called covering knowledge. When they are interpreted in the causal direction, they are called anticipatory. Not all causal links are both covering and anticipatory. Events have an attribute which represents their acquisition method. If the value on this attribute is “ask” the user of the application developed with MOLE may be asked as to whether the event occurred. Otherwise, the system has to infer this itself. ;;------ beginning of Ontolingua file generated by QUOTE ------

175

176


;; ;; ;; ;; ;;

File: Author: Works With: History:

mole-ontology.doe Gertjan Van Heijst QUOTE (V1.0), Ontolingua V3.2, Q 25/1/1995 (Created)

(in-package "ONTO-USER") (in-theory ’mole-ontology)

(define-class event (?e) "An event is a something that might explain another event or a symptom. Eshelman uses the terms events and hypothesis as synonyms" :AXIOM-DEF (class event))

(define-class symptom (?s) "A symptom is something that needs to be explained. Eshelman uses also the term complaint for this class" :AXIOM-DEF (class symptom))

(define-class acquisition-method (?m) "Acquisition-methods is one of ask or infer" :DEF (instance-of ?m (one-of ask infer)) :AXIOM-DEF (class acquisition-method))

(define-relation manifestation-of (?e ?s) "The has-manifestation relation specifies that a symptom is the manifestation of an event" :AXIOM-DEF (and (domain manifestation-of event) (range manifestation-of symptom) (relation manifestation-of) (arity manifestation-of 2)))

(define-relation has-acquisition-method (?event ?method) "The acquisition methods of an acquisition method specifies whether the status of the event can be obtained by asking or whether it needs to be obtained." :AXIOM-DEF

Appendix B: A Part of MOLE’s Elicitation Strategy

177

(and (domain has-acquisition-method event) (range has-acquisition-method acquisition-method) (maximum-slot-cardinality has-acquisition-method 1) (relation has-acquisition-method) (arity has-acquisition-method 2)))

(define-relation covers (?e1 ?e2) "The covers relation is the principal building block of MOLE’s causal network." :AXIOM-DEF (and (domain covers event) (range covers event) (relation covers) (arity covers 2)))

B.2 MOLE’s Knowledge Elicitation Strategy MOLE’s

elicitation strategy is modeled by means of two procedures. The first one (main) elicits the initial symptoms, and elicits the events that explain these symptoms. The second procedure, elicit-covers, recursively builds the causal network in a breadth-first way. (define-ka-strategy main () ;; first Mole elicits the initial symptoms (elicit-all ?s (symptom ?s)) ;; since MOLE acquires the causal network breadth-first ;; the entered events must be collected. For this, the ;; set variable @events is used. (let (@events) (for-each ?s (symptom ?s) (elicit-all ?e (manifestation-of ?e ?s) (push ?e @events))) ;; now elicit the events that explain the elicited events (elicit-covers @events)))

(define-ka-strategy elicit-covers (@events) ;; this procedure constructs the causal network in a ;; recursive breadth-first manner. The procedure stops ;; when no new events are elicited (let (@new-events) (for-each ?e1 (member-of ?e1 @events) (elicit-all ?e2 (covers ?e2 ?e1) (push ?e2 @events) (elicit-all ?method (has-acquisition-method ?e2 ?method)))) (elicit-covers @new-events)))

178


B.3 Description of CUE’s Elicitation Strategy Language

(define-ka-strategy () ) define-ka-strategy is the form for defining knowledge elicitation strategies or substrategies. define-ka-strategy takes a list of parameters and a body. The body consists of a list of other forms that are evaluated sequentially. The forms in the body may refer to the parameters in the parameter list. (elicit-all ) elicit-all takes as first argument a variable. The second argument is an expression that uses terms defined in the ontology to constrain the possible values that the variable may take. When elicit-all is evaluated it invokes QUAKE to elicit instances or tuples that satisfy and binds these to . Each time when is bound to an instance or tuple, the forms in are evaluated. elicit-all returns when the user of QUAKE stops entering instances or tuples.

(for-each ) for-each is similar to elicit-all but instead of prompting the user for instances or tuples that satisfy the specification, it searches in the repository with already elicited knowledge.

(let () ) let can be used for declaring local variables. The let form is the (lexical) scope for the variables in .

(member-of ) member-of takes a variable and a set variable and unifies the members of with one at a time. The construct is intended to be used within the for-each construct to iterate through the objects that are stored in a set variable.

(push ) push adds the value of to the values of .

Variables The language distinguishes three types of variables: instance variables, tuple variables and set variables. All types of variables are lexically scoped within the forms in which they are defined. Variables can be defined within the forms define-ka-strategy, let, elicit-all and for-each. – Instance variables (?var) can be bound to instances of classes. – Tuple variables ($var) can be bound to tuples of relations or functions. – Set variables @var can be bound to sets of either instances or tuples. When set variables are created they are bound to the empty set.

Appendix C

The ARS Application Ontology This appendix presents the Ontolingua specification of the ARS ontology described in chapter 8. ;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: operator.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created)

(in-package "ONTO-USER")

(define-theory EXPRESSION (FRAME-ONTOLOGY) "") (in-theory ’EXPRESSION)

(define-relation expression (?par ?operator ?value) "An expression is a simple equation" :AXIOM-DEF (and (subrelation-of expression expression) (nth-domain expression 1 thing) (nth-domain expression 2 operator) (nth-domain expression 3 thing) (relation expression) (arity expression 3)))

(define-class operator (?operator) "An operator is one of: < == less than =< == less than or equal to > == greater than >= == greater than or equal to = == equal to" :DEF

179

180


(instance-of ?operator (one-of < =< > >= =)) :AXIOM-DEF (class operator))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: time.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created)


(define-theory TIME (FRAME-ONTOLOGY) "") (in-theory ’TIME)

(define-class time-point (?tp) "A time point represents a moment in time" :AXIOM-DEF (and (subclass-of time-point time-descriptor) (class time-point))) (define-class time-interval (?ti) "A interval between two time points" :AXIOM-DEF (and (subclass-of time-interval time-descriptor) (class time-interval))) (define-function time-interval.start (?ti) :-> ?tp "The beginning of the time interval" :AXIOM-DEF ((function time-interval.start) (domain time-interval.start time-interval) (range time-interval.start time-point) (arity time-interval.start 2))) (define-function time-interval.end (?ti) :-> ?tp "The end of a time interval" :AXIOM-DEF ((function time-interval.end) (domain time-interval.end time-interval) (range time-interval.end time-point) (arity time-interval.end 2))) (define-class time-descriptor (?td)

Appendix C: The ARS Application Ontology

"A time descriptor is either a time point or a time interval" :AXIOM-DEF (and (exhaustive-subclass-partition time-descriptor (set-of time-interval time-point)) (class time-descriptor)))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: components.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created)

(in-package "ONTO-USER") (define-theory COMPONENTS (FRAME-ONTOLOGY) "Components defines a basic ontology of components and how they can be related. The current version of the ontology only defines the concepts of component, connected to and part-of.")

(in-theory ’COMPONENTS)

(define-class component (?component) "A component is a physical entity" :AXIOM-DEF (class component)) (define-relation connected-to (?comp1 ?comp2) "" :AXIOM-DEF (and (domain connected-to component) (range connected-to component) (symmetric-relation connected-to) (relation connected-to) (arity connected-to 2))) (define-relation part-of (?comp1 ?comp2) "" :AXIOM-DEF (and (domain part-of component) (range part-of component) (transitive-relation part-of) (antisymmetric-relation part-of) (relation part-of) (arity part-of 2)))

181

182


;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: medical-ontology.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created)


(define-theory MEDICAL-ONTOLOGY (GENERIC-CONCEPTS) "") (in-theory ’MEDICAL-ONTOLOGY)

(define-class medical-ontology-object (?object) "General class of all objects in the medical ontology" :AXIOM-DEF (class medical-ontology-object))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: anatomy.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created)


(define-theory ANATOMY (COMPONENTS MEDICAL-ONTOLOGY) "ANATOMY defines concepts that can be used to describe the human body in terms of interrelated components. It is based on the definitions in the Pavia library.") (in-theory ’ANATOMY)

(define-class human-body (?b) "Human body is defined as a subclass of body part. This is a bit strange of course, but the idea is that the human body is the largest possible body part." :DEF (not (exists (?bp) (part-of ?b ?bp))) :AXIOM-DEF (and (subclass-of human-body body-part)


(class human-body))) (define-class organ (?organ) "" :AXIOM-DEF (and (subclass-of organ body-part) (class organ))) (define-class organ-system (?system) "" :DEF (exists (?hb) (and (human-body ?hb) (part-of ?system ?hb))) :AXIOM-DEF (and (subclass-of organ-system body-part) (class organ-system))) (define-class anatomical-space (?space) "An anatomical space is an organic component represented as a compartment generally isolated from others by a membrane barrier" :AXIOM-DEF (and (subclass-of anatomical-space body-part) (class anatomical-space))) (define-class body-part (?bp) "" :AXIOM-DEF (and (subclass-of body-part component) (subclass-of body-part medical-ontology-object) (class body-part)))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: observable.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created) (in-package "ONTO-USER") (define-theory OBSERVABLE (FINDING) "") (in-theory ’OBSERVABLE)

(define-class observable (?observable) "Some information item that can be observed directly,

183

184


(e.g. temperature, diarrhea)" :AXIOM-DEF (and (subclass-of observable patient-parameter) (class observable))) (define-class observable-group (?group) "Group of observables e.g. signs, blood test" :AXIOM-DEF (and (subclass-of observable-group medical-ontology-object) (class observable-group))) (define-relation observable-subtype (?super ?sub) "Relation for denoting sub-type relations between groups of observables, e.g. physical signs can be gastro-intestinal signs, neurological signs etc." :AXIOM-DEF (and (domain observable-subtype observable-group) (range observable-subtype observable-group) (relation observable-subtype) (arity observable-subtype 2))) (define-relation observable.group (?obs ?group) "Relation for specifying that observable can be grouped together, e.g. ’stiff neck’ is a neurological sign. It is NOT defined as a function from observable to group as some observable could well belong to several groups, e.g. ’stiff neck’ could also be a muscular sign" :AXIOM-DEF (and (domain observable.group observable) (range observable.group observable-group) (relation observable.group) (arity observable.group 2)))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: disorder.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created)


(define-theory DISORDER (ANATOMY OBSERVABLE) "") (in-theory ’DISORDER)


(define-class disorder (?d) "Disorder is the class of all phenomena that might trigger medical action" :AXIOM-DEF (and (exhaustive-subclass-partition disorder (set-of disease syndrome)) (subclass-of disorder observable) (class disorder))) (define-function disorder.location (?d) :-> ?bp "A disorder is always associated with a part of the body. In cases where the disorder is not associated with a specific organ system, the human body is used as a default" :AXIOM-DEF ((function disorder.location) (domain disorder.location disorder) (range disorder.location body-part) (arity disorder.location 2)))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: finding.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created) (in-package "ONTO-USER") (define-theory FINDING (EXPRESSION) "") (in-theory ’FINDING)

(define-relation finding-generalisation (?f1 ?f2) "Generalization relation between two findings, used to represent for example: (finding-generalisation (immuno-suppressed = true) (compromised-host = true))" :AXIOM-DEF (and (domain finding-generalisation finding) (range finding-generalisation finding) (relation finding-generalisation) (arity finding-generalisation 2)))

(define-class patient-parameter (?par) "Patient parameters are (possibly abstract) descriptions about the signs and symptoms of a patient. Contrary to observables, patient-parameters do not have to be directly observable"

185

186


:AXIOM-DEF (class patient-parameter))

(define-relation finding (?parameter ?operator ?value) "A finding is an expression that symbolizes that something has been found in a patient : e.g (finding fever = present). To ensure that a parameter has only one value, finding is defined to be functional." :AXIOM-DEF (and (subrelation-of finding expression) (nth-domain finding 1 patient-parameter) (function finding) (relation finding) (arity finding 3))) (define-function finding.type (?f) :-> ?ft "The type of the finding" :AXIOM-DEF ((function finding.type) (domain finding.type finding) (range finding.type finding-type) (arity finding.type 2))) (define-class finding-type (?ft) "" :DEF (instance-of ?ft (one-of clinical personal laboratory)) :AXIOM-DEF (class finding-type))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: therapy.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created) (in-package "ONTO-USER") (define-theory THERAPY (DISORDER FINDING) "") (in-theory ’THERAPY)

(define-class therapy (?therapy) "A treatment for a disease"


:AXIOM-DEF (and (subclass-of therapy medical-ontology-object) (class therapy))) (define-relation has-therapy (?dis ?therapy) "" :AXIOM-DEF (and (domain has-therapy disorder) (range has-therapy therapy) (relation has-therapy) (arity has-therapy 2))) (define-relation has-contra-indicator (?ht ?f) "" :AXIOM-DEF (and (range has-contra-indicator finding) (domain has-contra-indicator has-therapy) (relation has-contra-indicator) (arity has-contra-indicator 2)))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: syndrome.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created) (in-package "ONTO-USER") (define-theory SYNDROME (DISORDER) "") (in-theory ’SYNDROME)

(define-class syndrome (?s) "A syndrome is a collection of phenomena that co-occur but for which there is no known direct causal connection. Contrary to diseases, syndromes can thus not be described in terms of sequences of pathophysiological states. Syndromes can be defined as consisting of other syndromes." :AXIOM-DEF (and (subclass-of syndrome disorder) (exhaustive-subclass-partition syndrome (set-of complex-syndrome simple-syndrome)) (class syndrome))) (define-relation is-aggregation-of (?s1 ?s2) "" :AXIOM-DEF

187

188


(and (domain is-aggregation-of syndrome) (range is-aggregation-of syndrome) (antisymmetric-relation is-aggregation-of) (antireflexive-relation is-aggregation-of) (relation is-aggregation-of) (arity is-aggregation-of 2)))

;;------ beginning of Ontolingua file generated by QUOTE -----;; ;; File: ars-application.doe ;; Author: Gertjan van Heijst ;; Works With: QUOTE (V1.0), Ontolingua V3.2, Q ;; History: 25/1/1995 (Created) (in-package "ONTO-USER") (define-theory ARS-APPLICATION (THERAPY FINDING SYNDROME) "") (in-theory ’ARS-APPLICATION)

(define-function ars-datum.time-stamp (?f) :-> ?time-stamp "A datum is always associated with a time stamp in the acute radiation syndrome application" :AXIOM-DEF ((function ars-datum.time-stamp) (domain ars-datum.time-stamp ars-datum) (range ars-datum.time-stamp time-descriptor) (arity ars-datum.time-stamp 2))) (define-relation ars-lesion-indication (?ob ?op ?val) "A lesion indicator is a finding with a qualitative value that indicates the severeness of the value. In the ARS application, the value must be one of mild, moderate, severe, very-severe or fatal." :AXIOM-DEF (and (subrelation-of ars-lesion-indication finding) (nth-domain ars-lesion-indication 1 ars-lesion-indicator) (nth-domain ars-lesion-indication 3 ars-indicator-value) (relation ars-lesion-indication) (arity ars-lesion-indication 3))) (define-class ars-indicator-value (?iv) "A qualitative value that expresses the severity of a lesion in the ARS domain. Five different values are used: fatal, very-severe, severe, moderate and mild" :DEF (instance-of ?iv (one-of fatal very-severe severe moderate mild)) :AXIOM-DEF


(class ars-indicator-value)) (define-relation ars-has-therapy (?sg ?th) "" :AXIOM-DEF (and (domain ars-has-therapy ars-lesion-grading) (range ars-has-therapy therapy) (relation ars-has-therapy) (arity ars-has-therapy 2))) (define-relation ars-has-contra-indicator (?ahs ?f) "" :AXIOM-DEF (and (domain ars-has-contra-indicator ars-has-therapy) (range ars-has-contra-indicator finding) (relation ars-has-contra-indicator) (arity ars-has-contra-indicator 2))) (define-relation ars-manifestation-of (?li ?lg) "The ARS-MANIFESTATION-OF relation is a redefinition of the MANIFESTATION-OF relation defined in the library When a lesion-indication is a manifestation of a lesiongrading, the indication must be present in the patient if the lesion has that particular grading" :AXIOM-DEF (and (domain ars-manifestation-of ars-lesion-indication) (range ars-manifestation-of ars-lesion-grading) (relation ars-manifestation-of) (arity ars-manifestation-of 2))) (define-relation ars-abstracted-from (?li ?f) "" :AXIOM-DEF (and (domain ars-abstracted-from finding) (range ars-abstracted-from ars-datum) (relation ars-abstracted-from) (arity ars-abstracted-from 2))) (define-relation ars-lesion-grading (?ob ?op ?v) "An ars-lesion-grading’s are the diagnoses in the the diagnosis of the acute radiation syndrome. They are modeled as expressions about the severity (grading) of a particular organ system lesion" :AXIOM-DEF (and (subrelation-of ars-lesion-grading expression) (nth-domain ars-lesion-grading 1 ars-organ-system-lesion) (function ars-lesion-grading) (relation ars-lesion-grading) (arity ars-lesion-grading 3))) (define-relation ars-datum (?ob ?op ?v)

189

190


"" :AXIOM-DEF (and (subrelation-of ars-datum finding) (nth-domain ars-datum 1 observable) (relation ars-datum) (arity ars-datum 3))) (define-class ars-lesion-indicator (?instance) "" :AXIOM-DEF (and (subclass-of ars-lesion-indicator patient-parameter) (class ars-lesion-indicator))) (define-relation ars-has-indicator (?has ?f) "" :AXIOM-DEF (and (domain ars-has-indicator ars-has-therapy) (range ars-has-indicator finding) (relation ars-has-indicator) (arity ars-has-indicator 2))) (define-class ars-organ-system-lesion (?instance) "An organ-system-lesion is an injury to an organ system caused by acute irradiation." :AXIOM-DEF (and (subclass-of ars-organ-system-lesion disorder) (class ars-organ-system-lesion)))

Bibliography ABEN, M. (1993). Formally specifying re-usable knowledge model components. Knowledge Acquisition, 5:119–141. ABEN, M. (1995). Formal Methods in Knowledge Engineering. PhD thesis, University of Amsterdam. ABU-HANNA, A. (1994). Multiple Domain Models in Diagnostic Reasoning. PhD thesis, University of Amsterdam. ABU-HANNA, A., BENJAMINS, V. R., & JANSWEIJER, W. N. H. (1991). Functional models in diagnostic reasoning. In Proceedings of The Eleventh International Workshop on Expert Systems and Their Applications, General Conference on Second Generation Expert Systems, pages 243–256, Avignon, France. EC2. ALBERT, P. & JACQUES, G. (1993). Putting commonKADS at work using kads-tool. In Kennistechnologie’93. ALBERTS, L. K. (1993). YMIR: an Ontology for Engineering Design. PhD thesis, University of Twente. ALLEMANG, D. & ROTHENFLUH, T. E. (1992). Acquiring knowledge of knowledge acquisition: A self-study of generic tasks. In Wetter, T., Althoff, K. D., Boose, J. H., Gaines, B. R., Linster, M., & Schmalhofer, F., editors, Current Developments in Knowledge Acquisition: EKAW-92, pages 353–373, Berlin, Germany. Springer-Verlag. ALLEMANG, D. & VAN HEIJST, G. (1993). Generic tasks in KEW. In Aussenac, N., Boy, G., Gaines, B. R., Linster, M., Ganascia, J. G., & Kodratoff, Y., editors, Knowledge Acquisition for Knowledge-Based Systems. Proceedings of the 7th European Workshop EKAW’93, Toulouse and Caylus, France, Lecture Notes in Computer Science, pages 139–158, Berlin Heidelberg, Germany. Springer-Verlag. ANJEWIERDEN, A., SHADBOLT, N. R., & WIELINGA, B. J. (1992a). Supporting knowledge acquisition: The ACKnowledge project. In Enhancing the Knowledge Engineering Process – Contributions from ESPRIT, pages 143–172. Amsterdam, The Netherlands, Elsevier Science. ANJEWIERDEN, A., WIELEMAKER, J., & TOUSSAINT, C. (1992b). Shelley - computer aided knowledge engineering. Knowledge Acquisition, 4(1). Special issue:“The KADS approach to knowledge engineering”. BARANOV, A., DENSOW, D., FLIEDNER, T. M., & KINDLER, H. (1994). Clinical Pre-Computer Proforma for the International Computer Database for Radiation Exposure Case Histories. Heidelberg, Springer. BELLAZZI, R., QUAGLINI, S., BERZUINI, C., & STEFANELLI, M. (1991). GAMEES: a probabilistic environment for expert systems. Computer Methods and Programs in Biomedicine, 35:177– 191. 191

192


BENJAMINS, V. R. (1993). Problem Solving Methods for Diagnosis. PhD thesis, University of Amsterdam, Amsterdam, The Netherlands. BENNETT, J. S. (1985). ROGET : A knowledge-based system for acquiring the conceptual structure of a diagnostic expert system. Journal of Automated Reasoning, 1:49–74. BLOIS, M. S. (1984). Information and Medicine: the Nature of Medical Descriptions. Berkeley, University of California Press. BOOSE, J. H. (1985). A knowledge acquisition program for expert systems based on personal construct psychology. International Journal of Man-Machine Studies, 23:495–525. BOOSE, J. H. & BRADSHAW, J. M. (1988). Expertise transfer and complex problems: using AQUINAS as a knowledge acquisition workbench for knowledge-based systems. In Boose, J. H. & Gaines, B. R., editors, Knowledge acquisition for knowledge based systems (vol. 2), pages 39–64. Academic Press. BRACHMAN, R. J., FIKES, R. E., & LEVESQUE, H. J. (1985). KRYPTON : A functional approach to knowledge representation. In Brachman, R. J. & Levesque, H. J., editors, Readings In Knowledge Representation, pages 411–429. Los Altos, California, Morgan Kaufmann. BREUKER, J. A. & VAN DE VELDE, W., editors (1994). The CommonKADS Library for Expertise Modelling. Amsterdam, The Netherlands, IOS Press. BREUKER, J. A. & WIELINGA, B. J. (1989). Model Driven Knowledge Acquisition. In Guida, P. & Tasso, G., editors, Topics in the Design of Expert Systems, pages 265–296, Amsterdam, The Netherlands. North-Holland. BREUKER, J. A., WIELINGA, B. J., VAN SOMEREN, M., DE HOOG, R., SCHREIBER, A. T., DE GREEF, P., BREDEWEG, B., WIELEMAKER, J., BILLAULT, J. P., DAVOODI, M., & HAYWARD, S. A. (1987). Model Driven Knowledge Acquisition: Interpretation Models. ESPRIT Project P1098 Deliverable D1 (task A1), University of Amsterdam and STL Ltd. BUCHANAN, B. G. & FEIGENBAUM, E. A. (1978). DENDRAL and meta-DENDRAL: Their applications dimension. Artificial Intelligence, 11:5–24. BURTON, A. M., SHADBOLT, N. R., RUGG, G., & HEDGECOCK, A. P. (1990). The efficacy of knowledge elicitation techniques: a comparison across domains and levels of expertise. Knowledge Acquisition, 2:167–178. BYLANDER, T., ALLEMANG, D., TANNER, M. C., & JOSEPHSON, J. R. (1991). The computational complexity of abduction. Artificial Intelligence, 49:25–60. BYLANDER, T. & CHANDRASEKARAN, B. (1988). Generic tasks in knowledge-based reasoning: The right level of abstraction for knowledge acquisition. In Gaines, B. R. & Boose, J. H., editors, Knowledge Acquisition for Knowledge Based Systems, volume 1, pages 65–77. London, Academic Press. CHANDRASEKARAN, B. (1987). Towards a functional architecture for intelligence based on generic information processing tasks. In Proceedings of the 10th IJCAI, pages 1183–1192, Milan, Italy. CHANDRASEKARAN, B. (1990). Design problem solving: A task analysis. AI Magazine, 11:59–71. CHANDRASEKARAN, B. & JOHNSON, T. R. (1993). Generic tasks and task structures: History, critique and new directions,. In David, J. M., Krivine, J. P., & Simmons, R., editors, Second Generation Expert Systems. Springer Verlag. CHI, M. T. H., GLASER, R., & FARR, M. (1988). The Nature of Expertise. Hillsdale, New Jersey, Erlbaum. CLANCEY, W. J. (1983). The epistemology of a rule based system -a framework for explanation. Artificial Intelligence, 20:215–251.

Bibliography

193

CLANCEY, W. J. (1985). Heuristic classification. Artificial Intelligence, 27:289–350. CLANCEY, W. J. (1992). Model construction operators. Artificial Intelligence, 53(1):1–115. CLANCEY, W. J. & LETSINGER, R. (1984). NEOMYCIN: Reconfiguring a rulebased expert system for application to teaching. In Clancey, W. J. & Shortliffe, E. H., editors, Readings in Medical Artificial Intelligence: the First Decade, pages 361–381. Reading, Massachusetts, Addison-Wesley. CONSOLE, L. & DUPRE´ , D. T. (1992). Choices in abductive reasoning with abstraction axioms. In Lakemeijer, G., editor, Proceedings of ECAI the workshop on foundations of knowledge representation, Vienna. CONSOLE, L., PORTINALE, L., DUPRE´ , D. T., & TORASSO, P. (1993). Combining heuristic reasoning with causal reasoning in diagnostic problem solving. In David, J. M., Krivine, J. P., & Simmons, R., editors, Second Generation Expert Systems, pages 46–68. Berlin Heidelberg, Germany, Springer-Verlag. CONSOLE, L. & TORASSO, P. (1988). Heuristic and causal reasoning in CHECK. In Proceedings of the 12th IMACS World Conference on Scientific Computation88, pages 283–286, Paris. DAVIS, R. (1979). Interactive transfer of expertise. Artificial Intelligence, 12(2):121–157. DAVIS, R., SHROBE, H., & SZOLOVITS, P. (1993). What is a knowledge representation? AI Magazine, Spring:17–33. DE KLEER, J. H. & BROWN, J. S. (1984). A qualitative physics based on confluences. Artificial Intelligence, 24:7–83. DE KLEER, J. H. & WILLIAMS, B. C. (1987). Diagnosing multiple faults. Artificial Intelligence, 32:97–130. ´ , P. F. & DE VRIES, P. H. (1985). Epistemology of medical expert systems. In DE VRIES ROBBE van Bemmel, J. H., Grémy, F., & Zvárová, J., editors, Medical Decision Making: Diagnostic Strategies and Expert Systems, pages 89–94. Amsterdam, North Holland. DUDA, R. O., GASCHING, J. G., & HART, P. E. (1979). Model design in the PROSPECTOR consultant system for mineral exploration. In Michie, D., editor, Expert Systems in the Micro-Electronic Age, pages 153–1674. Edinburgh University Press. ELSTEIN, A. S., SHULMAN, L. S., & SPRAFKA, S. A. (1978). Medical problem solving: An analysis of clinical reasoning. Cambridge, Harvard University Press. ERIKSSON, H., PUERTA, A. R., & MUSEN, M. A. (1994). Generation of knowledge acquisition tools from domain ontologies. In Gaines, B. R. & Musen, M. A., editors, Proceedings of the 8th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop., pages 7–1–7–20, Alberta, Canada. SRDG Publications, University of Calgary. ESHELMAN, L. (1988). MOLE: A knowledge-acquisition tool for cover-and-differentiate systems. In Marcus, S., editor, Automating Knowledge Acquisition for Expert Systems, pages 37–80. Boston, Kluwer. FALASCONI, S. (1993). Ontological foundations of knowledge based systems in medicine. Master’s thesis, University of Pavia, Italy. in Italian. FALASCONI, S. & STEFANELLI, M. (1994). A library of implemented ontologies. In Proceedings of the ECAI Workshop on Comparison of Implemented Ontologies, pages 81–91, Amsterdam. FEIGENBAUM, E. A. (1984). knowledge engineering: the applied side of artificial intelligence. Annals of the New York Academy of Sciences, 246:91–107. FENSEL, D. & VAN HARMELEN, F. (1994). A comparison of languages which operationalise and formalise KADS models of expertise. The Knowledge Engineering Review.

194


FIKES, R. E. & KEHLER, T. (1985). The role of frame based representation in reasoning. Communications of the ACM, 28(9):904–920. FORBUS, K. D. (1984). Qualitative process theory. Artificial Intelligence, 24:85–168. FORD, K. M., BRADSHAW, J. M., ADAMS-WEBBER, J. R., & AGNEW, N. M. (1993). Knowledge acquisition as a constructive modeling activity. International Journal of Intelligent Systems, 8(1):9–32. GENESERETH, M. R. & FIKES, R. E. (1992). Knowledge interchange format version 3. 0. Technical Report Logic-92-1, Computer Science Department, Stanford University. GENNARI, J. H. (1993). A brief guide to MAÎTRE and MODEL: an ontology editor and a frame based knowledge representation language. Technical report, Computer Science Department, Stanford University. GENNARI, J. H., TU, S. W., ROTHENFLUH, T. E., & MUSEN, M. A. (1994). Mapping domains to methods in support of reuse. International Journal of Human-Computer Studies. (in press). GRUBER, T. R. (1992). Ontolingua: A mechanism to support portable ontologies. version 3. 0. Technical report, Knowledge Systems Laboratory, Stanford University, California. GRUBER, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5:199–220. GRUBER, T. R. (1994). Towards principles for the design of ontologies used for knowledge sharing. In Guarino, N. & Poli, R., editors, Formal Ontology in Conceptual Analysis and Knowledge Representation. Kluwer. GUARINO, N. & BOLDRIN, L. (1993). Ontological requirements for knowledge sharing. Paper presented at the IJCAI workshop for knowledge sharing and information interchange, Chambery, France. HAYES-ROTH, B. (1985). A blackboard architecture for control. Artificial Intelligence, 26(3):251– 321. IRONI, L., CATTANEO, A., & STEFANELLI, M. (1993). A tool for pathophysiological knowledge acquisition. In AIME 93 - 4th Conference on Artificial Intelligence in Medicine Europe, Munich. JULLIEN, C., SHADBOLT, N. R., WIELINGA, B. J., AAKVIK, G., ADEY, S., ANJEWIERDEN, A., CALABRETTA, S., CHALMERS, P., CORBRIDGE, C., DEHLI, E., EGGEN, J., VAN HEIJST, G., MAJOR, N., MENGSHOEL, O., NORDBØ, I., RAMPARANY, F., REICHGELT, H., SOLORZANO, L., SØLVBERG, I., TERPSTRA, P., & VESTLI, M. (1992). ACKnowledge Final Report. ESPRIT Project P2576, Deliverable ACK-CSI-WM-DL-007, ACKnowledge Consortium. KINDLER, H., DENSOW, D., & FLIEDNER, T. M. (1993). A knowledge-based advisor to deal with rare diseases. In Proceedings AIME’93 Munich, 3-6 October, Medical Artificial Intelligence, Amsterdam. The Netherlands. Elsevier Science Publishers. KIRSH, D. (1990). When is information explicitly represented. In Hanson, P., editor, Vancouver Studies in Cognitive Science 1, pages 340–365. Vancouver BC., University of British Columbia Press. KLINKER, G., BHOLA, C., DALLEMAGNE, G., MARQUES, D., & MCDERMOTT, J. (1991). Usable and reusable programming constructs. Knowledge Acquisition, 3:117–136. KLINKER, G., MARQUES, D., MCDERMOTT, J., MERSEREAU, T., & STINSON, L. (1993). The active glossary: taking integration seriously. Knowledge Acquisition, 5. KUIPERS, B. (1986). Qualitative simulation. Artificial Intelligence, 29:289–388. LANZOLA, G., QUAGLINI, S., & STEFANELLI, M. (1995). Knowledge-acquisition tools for medical knowledge-based systems. Methods of Information in Medicine, 34(1). (in press).

Bibliography

195

LANZOLA, G. & STEFANELLI, M. (1992). A specialized framework for medical knowledge based systems. Computers and Biomedical Research, 25:351–365. LENAT, D. B. & FEIGENBAUM, E. A. (1991). On the thresholds of knowledge. Artificial Intelligence, 47(1-3):185–251. LENAT, D. B. & GUHA, R. V. (1990). Building large knowledge-based systems. Representation and inference in the Cyc project. Reading, Massachusetts, Addison-Wesley. LEVESQUE, H. J. & BRACHMAN, R. J. (1985). A fundamental tradeoff in knowledge representation and reasoning. In Levesque, R. J. B. H. J., editor, Readings in Knowledge Representation, pages 41–70. Morgan Kaufmann. LINDBERG, D. A. B., HUMPHREYS, B. L., & MCCRAY, A. T. (1993). The unified medical language system. Methods of Information in Medicine, 32:281–291. MACGREGOR, R. (1991). The evolving technology of classification-based knowledge representation systems. In Sowa, J., editor, Principles of Semantic Networks: Explorations in the Representation of Knowledge, pages 385–400. Morgan Kaufmann. MAJOR, N. & REICHGELT, H. (1990). ALTO: an automated laddering tool. In Wielinga, B. J., Boose, J. H., Gaines, B. R., Schreiber, A. T., & van Someren, M., editors, Current trends in knowledge acquisition, pages 222–236, Amsterdam, The Netherlands. IOS Press. MARCUS, S., editor (1988). Automatic knowledge acquisition for expert systems. Boston, Kluwer. MARCUS, S. & MCDERMOTT, J. (1989). SALT: A knowledge acquisition language for proposeand-revise systems. Artificial Intelligence, 39(1):1–38. MCDERMOTT, J. (1982). R1: A rule-based configurer of computer systems. Artificial Intelligence, 19:39–88. MCDERMOTT, J. (1988). Preliminary steps towards a taxonomy of problem-solving methods. In Marcus, S., editor, Automating Knowledge Acquisition for Expert Systems, pages 225–255. Boston, Kluwer. MILLER, R. A., POPLE, H. E., & MYERS, J. D. (1982). INTERNIST-I: A general computer-based diagnostic consultant for general internal medicine. New England Journal of Medicine, 307:468–476. Also in: Readings in Medical Artificial Intelligence: The First Decade, W. J. Clancey and E. H. Shortliffe (eds. ), Addison Wesley, Reading, MA, 1984. MOTTA, E., O’HARA, K., SHADBOLT, N. R., STUTT, A., & ZDRADAHL, Z. (1994). A VITAL solution to the sisyphus II elevator design problem. In Schreiber, A. T. & Birmingham, W. P., editors, Proceedings of the 8th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop. Volume 3: Sisyphus II – VT Elevator Design Problem, pages 40–1 – 40–25, Alberta, Canada. SRDG Publications, University of Calgary. MOTTA, E., RAJAN, T., DOMINGUE, J., & EISENSTADT, M. (1990). Methodological foundations of KEATS, the knowledge engineering assistant. In Wielinga, B. J., Boose, J. H., Gaines, B. R., Schreiber, A. T., & van Someren, M., editors, Current trends in knowledge acquisition, pages 257–275, Amsterdam, The Netherlands. IOS Press. MUSEN, M. A. (1989a). Automated Generation of Model-Based Knowledge-Acquisition Tools. London, Pitman. Research Notes in Artificial Intelligence. MUSEN, M. A. (1989b). Automated support for building and extending expert models. Machine Learning, 4:347–376. MUSEN, M. A. (1992). Overcoming the limitations of role-limiting methods, editorial special issue. Knowledge Acquisition, 4(1):163–168. MUSEN, M. A. (1993). An overview of knowledge acquisition. In David, J. M., Krivine, J. P., & Simmons, R., editors, Second Generation Expert Systems, pages 405–427. Berlin Heidelberg,

196


Germany, Springer-Verlag. MUSEN, M. A., FAGAN, L. M., COMBS, D. M., & SHORTLIFFE, E. H. (1988). Use of a domain model to drive an interactive knowledge editing tool. In Boose, J. H. & Gaines, B. R., editors, Knowledge-Based Systems, Volume 2: Knowledge Acquisition Tools for Expert Systems, pages 257–273, London. Academic Press. NECHES, R., FIKES, R. E., FININ, T., GRUBER, T. R., PATIL, R. S., SENATOR, T., & SWARTOUT, W. R. (1991). Enabling technology for knowledge sharing. AI Magazine, pages 36–56. Fall. NEWELL, A. (1982). The knowledge level. Artificial Intelligence, 18:87–127. NEWELL, A. & SIMON, H. A. (1963). GPS – A program that simulates human thought. In Computers and Thought, pages 279–296. New York, McGraw-Hill. NII, P. (1986). Blackboard systems. Technical report, Knowledge Systems Laboratory, Stanford University, Stanford (CA). O’HARA, K. (1993). A representation of KADS-I interpretation models using a decompositional approach. In Proceedings of the 3th KADS User Meeting, Munich. Siemens AG. PATIL, R. S. (1981). Causal Representation of Patient Illness for Electrolyte and Acid-Base Diagnosis. PhD thesis, Laboratory for Computer Science, MIT. PATIL, R. S. (1988). Artificial intelligence techniques for diagnostic reasoning in medicine. In Shrobe, H. E., editor, Exploring Artificial Intelligence: Survey Talks from the National Conferences on Artificial Intelligence, pages 347–379. San Mateo, California, Morgan Kaufmann. PATIL, R. S., SZOLOVITS, P., & SCHWARTZ, W. B. (1981). Causal understanding of patient illness in medical diagnosis. In Proceedings of the Seventh International Joint Conference on Artificial Intelligence, pages 893–899. Los Altos California, Morgan Kaufmann. Also in: Readings in Medical Artificial Intelligence: The First Decade, W. J. Clancey and E. H. Shortliffe (eds. ), Addison Wesley, Reading, MA, 1984. PEIRCE, C. S. (1932). Collected Papers of Charles Saunders Peirce, volume 2, Elements of Logic. Cambridge MA, Harvard University Press. PENG, Y. & REGGIA, J. A. (1986). Plausibility of diagnostic hypotheses: The nature of simplicity. In Proc. AAAI-86, pages 140–145, Philadelphia, PA. AAAI. POPLE, H. E. (1985). Evolution of an expert system: from INTERNIST to CADUCEUS. In DeLotto, I. & Stefanelli, M., editors, Proceedings of the International Conference on Artificial Intelligence in Medicine, pages 179–208, Pavia, Italy. POST, W. M., KOSTER, R. W., ZOCCA, V., & SRAMEK, M. (1993). Cooperative medical problem solving. In AIME 93 - 4th Conference on Artificial Intelligence in Medicine Europe, Munich. PUERTA, A. R., EGAR, J., TU, S. W., & MUSEN, M. A. (1992). A multiple-method shell for the automatic generation of knowledge acquisition tools. Knowledge Acquisition, 4:171–196. QUAGLINI, S., BELLAZZI, R., LOCATELLI, F., STEFANELLI, M., & SALVANESCHI, C. (1994). An influence diagram for assessing GVHD prophylaxis after bone marrow transplantation in children. Medical Decision Making, 14:223–235. RADEMAKERS, P. & PFEIFER, R. (1992). The role of knowledge level models in situated adaptive design. In Neumann, B., editor, Proceedings of the 10th European Conference on Artificial Intelligence, pages 601–602. RAMONI, M. & STEFANELLI, M. (1992). The epistemology of problem solving methods. Submitted for Publication. RAMONI, M., STEFANELLI, M., BAROSI, G., & MAGNANI, L. (1992). An epistemological framework for medical knowledge based systems. IEEE Transactions on Systems, Man and Cybernetics, 22:1361–1375.

Bibliography

197

RECTOR, A. L., NOWLAN, W. A., KAY, S., GOBLE, C. A., & HOWKINS, T. J. (1993). A framework for modelling the electronic medical record. Methods of Information in Medicine, 32:109–119. ROSCH, E. (1973). Natural categories. Cognitive Psychology, 4. RUNKEL, J. T. & BIRMINGHAM, W. P. (1993). Knowledge acquisition in the small: Building knowledge acquisition tools from pieces. Knowledge Acquisition, 5(2):221–243. RUNKEL, J. T. & BIRMINGHAM, W. P. (1994). Separation of knowledge: a key to reusability. In Gaines, B. R. & Musen, M. A., editors, Proceedings of the 8th Banff Knowledge Acquisition for Knowledge–based Systems Workshop, pages 36–1 — 36–19. SCHREIBER, A. T. (1992). Pragmatics of the Knowledge Level. PhD thesis, University of Amsterdam. SCHREIBER, A. T. & BIRMINGHAM, W. P., editors (1994). Proceedings of the 8th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop. Volume 3: Sisyphus II – VT Elevator Design Problem, Calgary, Alberta, Canada. SRDG Publications, University of Calgary. SCHREIBER, A. T., WIELINGA, B. J., AKKERMANS, J. M., VAN DE VELDE, W., & ANJEWIERDEN, A. (1994). CML: The CommonKADS conceptual modelling language. In Steels, L., Schreiber, A. T., & Van de Velde, W., editors, A Future for Knowledge Acquisition. Proceedings of the 8th European Knowledge Acquisition Workshop EKAW’94, pages 1–25, Berlin/Heidelberg. Springer-Verlag. SCHREIBER, A. T., WIELINGA, B. J., & BREUKER, J. A., editors (1993). KADS: A Principled Approach to Knowledge-Based System Development. London, Academic Press. SHADBOLT, N. R., MOTTA, E., & ROUGE, A. (1993). Constructing knowledge based systems. IEEE Software. SHADBOLT, N. R. & WIELINGA, B. J. (1990). Knowledge based knowledge acquisition: the next generation of support tools. In Wielinga, B. J., Boose, J. H., Gaines, B. R., Schreiber, A. T., & van Someren, M. W., editors, Current Trends in Knowledge Acquisition, pages 313–338, Amsterdam, The Netherlands. IOS Press. SHAW, M. L. G. & GAINES, B. R. (1987). An interactive knowledge elicitation technique using personal construct technology. In Kidd, A. L., editor, Knowledge Acquisition for Expert Systems: A Practical Handbook, New York. Plenum Press. SHAW, M. L. G. & GAINES, B. R. (1989). Comparing conceptual structures: Consensus, conflict correspondence and contrast. Knowledge Acquisition, 4(1):341–364. SHORTLIFFE, E. H. (1979). Computer-Based Medical Consultations: Mycin. New York, American-Elsevier. SIMMONS, R. (1992). The roles of associational and causal reasoning in problem solving. Artificial Intelligence, 53(2-3):159–208. SIMMONS, R. (1993). Generate test and debug: a paradigm for combining associational and causal reasoning. In David, J. M., Krivine, J. P., & Simmons, R., editors, Second Generation Expert Systems, pages 79–92. Berlin Heidelberg, Germany, Springer-Verlag. SIMON, H. A. (1985). Artificial-intelligence approaches to problem solving and clinical diagnosis. In Shaffner, K. F., editor, Logic of Discovery and Diagnosis in Medicine, pages 72–93. Berkely and Los Angeles, University of California Press. SRINIVAS, S. & BREESE, J. (1990). Ideal: A software package for analysis of influence diagrams. In Proceedings of 6th Conference on Uncertainty in AI, Cambridge, MA. STEELS, L. (1985). Second generation expert systems. FGCS, 1(4):213–221. STEELS, L. (1990). Components of expertise. AI Magazine, 11(2):30–49.

198


STEELS, L. (1993). The componential framework and its role in reusability. In David, J. M., Krivine, J. P., & Simmons, R., editors, Second Generation Expert Systems, pages 273–298. Berlin Heidelberg, Germany, Springer-Verlag. SWARTOUT, W. R. (1983). XPLAIN: A system for creating and explaining expert consulting systems. Artificial Intelligence, 20:285–325. TERPSTRA, P., VAN HEIJST, G., WIELINGA, B. J., & SHADBOLT, N. R. (1993). Knowledge acquisition support through generalised directive models. In David, J. M., Krivine, J. P., & Simmons, R., editors, Second Generation Expert Systems, pages 428–455. Berlin Heidelberg, Germany, Springer-Verlag. TU, S. W., ERIKSSON, H., GENNARI, J. H., SHAHAR, Y., & MUSEN, M. A. (1995). Ontology-based configuration of problem-solving methods and generation of knowledge acquisition tools: The application of PROTE´ GE´ -II to protocol-based decision support. Artificial Intelligence in Medicine. (in press). TU, S. W., KAHN, M. G., MUSEN, M. A., FERGUSON, J. C., SHORTLIFFE, E. H., & FAGAN, L. M. (1989). Episodic skeletal-plan refinement based on temporal data. Communications of the ACM, 32(12):1439–1455. VALENTE, A., BREUKER, J. A., & BREDEWEG, B. (1993). Integrating modeling approaches in the CommonKADS library. In Sloman, A., Hogg, D., Humphreys, G., Ramsay, A., & Partridge, D., editors, Prospects for Artifical Intelligence, Proceedings of the AISB’93, pages 121–130. IOS Press. ¨ VALENTE, A. & LOCKENHOFF , C. (1994). Assessment. In Breuker, J. A. & Van de Velde, W., editors, The CommonKADS Library for Expertise Modelling, chapter 7, pages 155–174. Amsterdam, The Netherlands, IOS Press. VAN BEMMEL, J. H. (1993). Criteria for the acceptance of decision support systems by clinicians. In Andreassen, S., Engelbrecht, R., & Wyatt, J., editors, Proceedins of the 4th Conference on Artificial Intelligence in Medicine Europe, 3-6 October 1993, Munich, volume 10 of Studies in Health Technology and Informatics, pages 7–10, Amsterdam. The Netherlands. IOS Press. VAN HEIJST, G., FALASCONI, S., ABU-HANNA, A., SCHREIBER, A. T., & STEFANELLI, M. (1995). A case study in ontology library construction. AI in Medicine. (in press). VAN HEIJST, G., LANZOLA, G., SCHREIBER, A. T., & STEFANELLI, M. (1994a). Foundations for a methodology for medical KBS development. Knowledge Acquisition, 6:395–434. VAN HEIJST, G., POST, W. M., & SCHREIBER, A. T. (1994b). Knowledge-based integration of representation formalisms. In Cohn, A., editor, Proceedings of the 11th European Conference On Artificial Intelligence, pages 319–323, London. Wiley. VAN HEIJST, G. & SCHREIBER, A. T. (1994). CUE: Ontology-based knowledge acquisition. In Steels, L., Schreiber, A. T., & Van de Velde, W., editors, A Future for Knowledge Acquisition. Proceedings of the 8th European Knowledge Acquisition Workshop EKAW’94, volume 867 of Lecture Notes in Artificial Intelligence, pages 178–199, Berlin/Heidelberg. Springer-Verlag. VAN HEIJST, G., TERPSTRA, P., WIELINGA, B. J., & SHADBOLT, N. R. (1992b). Generalised directive models. In Proceedings of KAW-92, Banff. VAN HEIJST, G., TERPSTRA, P., WIELINGA, B. J., & SHADBOLT, N. R. (1992a). Using generalised directive models in knowledge acquisition. In Wetter, T., Althoff, K. D., Boose, J. H., Gaines, B. R., Linster, M., & Schmalhofer, F., editors, Current Developments in Knowledge Acquisition: EKAW-92, pages 112–132, Berlin, Germany. Springer-Verlag. VAN MELLE, W. (1979). A domain independent production rule system for consultation programs. In IJCAI–79, pages 923–925.

Bibliography

199

VANLEHN, K. (1989). Architectures for Intelligence. Hillsdale, New Jersey, Lawrence Erlbaum. WEISS, S. M. & KULIKOWSKI, C. A. (1979). EXPERT: a system for developing consultation models. In Proceedings of IJCAI, pages 826–832. WEISS, S. M., KULIKOWSKI, C. A., AMAREL, S., & SAFIR, A. (1984). A model-based method for computer-aided medical decision making. In Clancey, W. J. & Shortliffe, E. H., editors, Readings in Medical Artificial Intelligence, the First Decade. Addison Wesley. WICK, M. R. & THOMPSON, W. B. (1992). Reconstructive expert system explanation. Artificial Intelligence, 54:33–70. WIELEMAKER, J. & ANJEWIERDEN, A. (1989). Separating user interface and functionality using a frame based data model. In Proceedings Second Annual Symposium on User Interface Software and Technology, pages 25–33, Williamsburg, Virginia. ACM Press. WIELINGA, B. J. & BREUKER, J. A. (1986). Models of expertise. In Proceedings ECAI–86, pages 306–318. WIELINGA, B. J. & SCHREIBER, A. T. (1993). Reusable and sharable knowledge bases: A european perspective. In Proceedings International Conference on Building and Sharing of Very LargeScaled Knowledge Bases ’93, pages 103–115, Tokyo, Japan. Japan Information Processing Development Center. WIELINGA, B. J., SCHREIBER, A. T., & BREUKER, J. A. (1992). KADS: A modelling approach to knowledge engineering. Knowledge Acquisition, 4(1):5–53. Special issue ‘The KADS approach to knowledge engineering’. Reprinted in: Buchanan, B. and Wilkins, D. editors (1992), Readings in Knowledge Acquisition and Learning, San Mateo, California, Morgan Kaufmann, pp. 92-116. WIELINGA, B. J., SCHREIBER, A. T., & DE GREEF, P. (1989). Synthesis report. ESPRIT Project P1098, Deliverable Y3, University of Amsterdam. WIELINGA, B. J., SCHREIBER, A. T., JANSWEIJER, W. N. H., & ANJEWIERDEN, A. (1994). Framework and formalism for expressing ontologies. ESPRIT Project 8145 KACTUS, deliverable DO1b. 1, UvA. WIELINGA, B. J., VAN DE VELDE, W., SCHREIBER, A. T., & AKKERMANS, J. M. (1993). Towards a unification of knowledge modelling approaches. In David, J. M., Krivine, J. P., & Simmons, R., editors, Second Generation Expert Systems, pages 299–335. Berlin Heidelberg, Germany, Springer-Verlag. YOST, G., KLINKER, G., LINSTER, M., MARQUES, D., & MCDERMOTT, J. (1994). The SBF framework, 1989-1994: From applications to workplaces. In Steels, L., Van der Velde, W., & Schreiber, A. T., editors, Proceedings European Knowledge Acquisition Workshop EKAW’94, Heidelberg/Berlin. Springer Verlag.

200


Samenvatting De oorspronkelijke doelstelling van artificiële intelligentie (AI), het ontwikkelen van computerprogramma’s die intelligent gedrag vertonen, is een zeer moelijk probleem gebleken. Alhoewel op sommige gebieden interessante resultaten zijn behaald — denk hierbij bijvoorbeeld aan computers die kunnen schaken — bestaan er momenteel geen systemen die een “algemene vorm van intelligentie” bezitten. Kennistechnologie is een toepassingsgerichte tak van artificiële intelligentie. In tegenstelling tot de “algemene” artificiële intelligentie stelt de kennistechnologie zich tot doel systemen te ontwikkelen die een gespecialiseerde vorm van intelligentie vertonen en daardoor specifieke taken uit kunnen voeren. Omdat dit vaak taken betreft waarbij expertise nodig is, worden de produkten van kennistechnologie soms “expertsystemen” genoemd, alhoewel heden ten dage de term kennissystemen meer in zwang is. De ontwikkeling van dergelijke systemen vereist ten minste twee participanten: iemand die weet hoe je kennissystemen moet bouwen, de kennis-ingenieur, en iemand die verstand heeft van het toepassingsgebied, de domein-expert. Deze twee participanten moeten samen de expertise in een vorm gieten die geschikt is als basis voor de ontwikkeling van een kennissysteem. Dit proces wordt het kennis-acquisitieproces genoemd. Oorspronkelijk werd het kennis-acquisitieproces gezien als een dialoog waarbij de domein-expert vertelt hoe hij of zij problemen oplost in het toepassingsdomein en waarbij de kennis-ingenieur de kennis die naar voren wordt gebracht vertaalt in een taal om kennis te representeren die rechtstreeks door de computer kan worden ge¨ınterpreteerd. De ervaring heeft echter geleerd dat deze kijk op het kennis-acquisitieproces nogal na¨ıef was. Domein-experts hebben vaak grote moeite om hun kennis onder woorden te brengen, en de kennis die zij naar voren brengen is vaak niet de kennis die de kennis-ingenieur nodig heeft om een kennissysteem te ontwikkelen. Om deze reden zijn er in de jaren tachtig en negentig een aantal — vaak op psychologische technieken gebaseerde — methoden ontwikkeld om het kennis-acquisitieproces te ondersteunen. Tevens zijn er een aantal gestructureerde methodologieën ontwikkeld voor het bouwen van kennissystemen. In deze methodologieën word benadrukt dat kennisacquisitie een modeleerproces is waarbij het de taak is van de kennis-ingenieur om de expertise in het domein op zo’n manier in kaart te brengen dat vervolgens goed overwogen beslissingen kunnen worden genomen met betrekking tot de computationele realisatie van het kennissysteem. Zo’n gestructureerde beschrijving van de kennis noemt men ook wel een kennis-nivobeschrijving. Een belangrijk kenmerk van methodologieën die gebaseerd zijn op het gebruik van kennisnivobeschrijvingen is dat ze sterk de nadruk leggen op het hergebruik van stukjes kennismodel. Het achterliggende idee hierbij is dat kennismodellen kunnen worden ontwikkeld door stukjes kennis te selecteren uit bibliotheken van herbruikbare kenniscomponenten. Deze componenten kunnen dan vervolgens worden geconfigureerd tot complete kennismodellen voor een specifieke taak en 201

202


een specifiek domein. Op deze wijze wordt de taak van de kennis-ingenieur vergemakkelijkt omdat een deel van de expertise niet meer gemodeleerd hoeft te worden. In de kennistechnologie worden verschillende types van herbruikbare componenten onderscheiden, die kunnen worden onderverdeeld in twee categorieën: componenten om het redeneerproces te modeleren en componenten om de domeinkennis te modeleren. Dit proefschrift richt zich met name op de tweede categorie. Er kunnen met betrekking tot de domeinkennis twee typen componenten worden onderscheiden: (i) ontologieën, abstracte beschrijvingen van de structuur en inhoud van de domeinkennis, en (ii) de domeinkennis zelf. Dit onderscheid is belangrijk omdat de types componenten onder verschillende omstandigheden herbruikbaar zijn en omdat ze verschillende rollen kunnen vervullen bij de ontwikkeling van een kennissysteem. De centrale vraagstelling in dit proefschrift betreft de verschillende rollen die expliciet gerepresenteerde ontologieën kunnen vervullen binnen het kennissysteem-ontwikkelingsproces. Een eerste rol voor ontologieën die word beschreven in dit proefschrift heeft betrekking op het kennis-elicitatieproces. Kenniselicitatie is dat deel van het kennis-acquisitieproces waarbij de kennis-ingenieur probeert de kennis te ontlokken aan de domein-expert die relevant is voor het kennissysteem. Omdat kenniselicitatie in het verleden een zeer moeilijk proces is gebleken zijn hiervoor tal van technieken ontwikkeld, en ook computerprogramma’s die deze technieken ondersteunen. De programma’s die deze taak ondersteunen worden kennis-acquisitietools (KAtools) genoemd. Deze KA-tools zijn in staat om het kennis-elicitatieproces te ondersteunen omdat ze aannames maken over de soort van kennis en de vorm van deze kennis die dient te worden geëliciteerd. Deze aannames kunnen van allerlei aard zijn. In dit proefschrift, met name in de hoofstukken 3 en 6, wordt betoogd dat dit soort aannames vaak ontologisch van aard zijn en dat het expliciet maken van deze aannames nuttig is om te beslissen onder welke omstandigheden een bepaalde techniek of tool bruikbaar is. Dit word in dit proefschrift ge¨ıllustreerd met behulp van het CUE systeem. CUE is een computersysteem dat bestaat uit een aantal KA-tools waarmee kennis-nivomodellen kunnen worden gespecificeerd. Vervolgens gebruikt CUE de door de kennisingenieur gespecificeerde ontologieën om gerichte vragen te stellen aan de domein-expert. Een tweede manier waarop ontologieën nuttig kunnen zijn in het kennissysteemontwikkelingsproces heeft te maken met de interactie tussen redeneertechnieken en domeinkennis. Om een bepaalde redeneertechnieken te gebruiken moet de domeinkennis vaak aan specifieke eisen voldoen. Om probabilistische redeneertechnieken te gebruiken is het bijvoorbeeld vaak nodig dat de domeinkennis kan worden beschreven in termen van gebeurtenissen met bepaalde waarschijnlijkheden. De interactie tussen redeneertechnieken en domeinkennis maakt het onmogelijk om willekeurige redeneertechnieken te gebruiken met willekeurige domeinkennis. Om deze reden vormt de interactie een serieuze hindernis voor de herbruikbaarheid van zowel methodecomponenten als van domein-kenniscomponenten. In de hoofdstukken 4 en 5 van dit proefschrift wordt betoogd dat de eisen waaraan domeinkennis moet voldoen om te worden gebruikt door een bepaalde redeneertechniek vaak in ontologische termen kunnen worden geformuleerd, d.w.z. in de vorm van een abstracte beschrijving van de structuur van de domeinkennis. Dit heeft twee voordelen. Ten eerste maakt dit het mogelijk om te beslissen of een redeneertechniek geschikt is voor een specifiek domein zonder eerst alle domeinkennis te vergaren. Ten tweede kan de koppeling tussen de rollen die worden onderscheiden in de redeneertechniek worden gekoppeld aan de domeinkennis die deze rollen kan vervullen door middel van connecties tussen deze rollen en de ontologie. Op deze wijze kan gelijk voor hele categorieën van domeinkennis worden aangegeven welke rol zij kunnen spelen in het redeneerproces. Een derde rol voor ontologieën in het kennissysteem-ontwikkelingsproces heeft te maken

Bibliography

203

met het computationele ontwerp. Als de kennis-nivobeschrijving is gecompleteerd moet deze vervolgens worden vertaald naar een ontwerp voor het uiteindelijke systeem. Er moet beslist worden op welke wijze de domeinkennis en de redeneertechniek moeten worden gerepresenteerd in het geheugen van een computer. Een van de uitgangspunten van het werk in dit proefschrift is dat er in deze stap zoveel mogelijk gebruik moet worden gemaakt van al bestaande programmatuur. In de loop der jaren is door AI onderzoekers een grote verscheidenheid aan probleem-oplossende programma’s ontwikkeld, waarbij elk van deze programma’s specifieke aannames maakt over de aard van de kennis die gerepresenteerd kan worden. Om te beslissen of de domeinkennis in een specifiek kennismodel kan worden gebruikt door zo’n probleemoplossend programma moet dus de aard van de domeinkennis in het kennismodel worden vergeleken met de soort van kennis die gerepresenteerd kan worden in een probleemoplossend programma. In hoofstuk 7 van dit proefschrift wordt beargumenteerd dat expliciete ontologieën kunnen worden gebruikt om deze beslissingen te nemen. Naast de vraagstelling hoe ontologieën kunnen worden gebruikt houdt dit proefschrift zich ook bezig met de vraag hoe ontologieën kunnen worden gebouwd. In hoofdstuk 5 wordt beargumenteerd dat dit kan op basis van ontologie-componenten die zijn opgeslagen in een bibliotheek die is georganiseerd op basis van drie principes: (i) zo’n bibliotheek zou moeten bestaan uit een centrale sectie waar de fundamentele concepten van een bepaald toepassingsgebied zijn gedefiniëerd en een perifere sectie waar (ii) methode-specifieke uitbreidingen van de fundamentele concepten zijn gedefinieerd en (iii) domein-specifieke uitbreidingen van de fundamentele concepten zijn gedefinieerd. Het idee is hier dat de bibliotheek dusdanig is ge¨ındexeerd dat door aan te geven over welke domeinen een kennissysteem dient te redeneren, en door aan te geven welke redeneermethodes het systeem hiervoor gebruikt, de bibliotheek kan worden gebruikt om concepten te vinden die waarschijnlijk bruikbaar zullen zijn voor de ontologie van het kennissysteem. In hoofstuk 8 word het hierboven beschreven gezichtspunt op het ontwikkelingsproces van kennissystemen ge¨ıllustreerd door middel van een beschrijving van de ontwikkeling van een systeem dat ondersteuning biedt bij de behandeling van patienten met het acute-stralingsziektesyndroom. In hoofstuk 9 worden de voornaamste conclusies van dit proefschrift samengevat en worden een aantal suggesties gedaan voor vervolgonderzoek.

Name Index Aakvik G. 57 Aben M. 12, 46, 71 Abu-Hanna A. 71, 85, 118 Adams-Webber J. R. 41 Adey S. 57 Agnew N. M. 41 Akkermans J. M. 37, 74, 165 Albert P. 50 Alberts L. K. 4 Allemang D. 13, 66, 167 Amarel S. 15, 84 Anjewierden A. 50, 51, 57, 74, 99, 165 Baranov A. 130 Barosi G. 13, 80 Bellazzi R. 29, 31 Benjamins V. R. 66, 67, 118 Bennett J. S. 44 Berzuini C. 29 Bhola C. 37, 50, 71 Billault J. P. 58 Birmingham W. P. 37, 51, 107, 115, 164 Blois M. S. 9 Boldrin L. 74 Boose J. H. 42, 45, 49 Brachman R. J. 11, 118, 119 Bradshaw J. M. 41, 45, 49 Bredeweg B. 58, 66 Breese J. 124 Breuker J. A. 2, 3, 7, 10, 12, 36, 41, 42, 58, 65, 66, 71 Brown J. S. 15 Buchanan B. G. 1 Burton A. M. 108 Bylander T. 3, 13, 72 Calabretta S. 57 Cattaneo A. 29 Chalmers P. 57

Chandrasekaran B. 3, 17, 42, 66, 72, 167 Chi M. T. H. 15 Clancey W. J. 3, 7, 15, 20, 65 Combs D. M. 42, 45, 49 Console L. 13, 82, 118 Corbridge C. 57 Dallemagne G. 37, 50, 71 Davis R. 43, 44, 74 Davoodi M. 58 Dehli E. 57 Densow D. 129, 130 de Greef P. 9, 58 de Hoog R. 58 de Kleer J. H. 15, 119 de Vries P. H. 119 de Vries Robbé P. F. 119 Domingue J. 50 Duda R. O. 44, 48 Dupré D. T. 13, 82 Egar J. 36, 51, 71 Eggen J. 57 Eisenstadt M. 50 Elstein A. S. 15 Eriksson H. 36, 73, 74, 91, 115 Eshelman L. 15, 27, 45, 48, 65, 71, 106, 175 Fagan L. M. 42, 45, 49, 71 Falasconi S. 71, 74, 78 Farr M. 15 Feigenbaum E. A. 1, 2, 11 Fensel D. 127 Ferguson J. C. 71 Fikes R. E. 11, 17, 35, 119, 164 Finin T. 17, 35, 164 Fliedner T. M. 129, 130 Forbus K. D. 15 Ford K. M. 41

Bibliography Gaines B. R. 42, 54 Gasching J. G. 44, 48 Genesereth M. R. 17 Gennari J. H. 15, 36, 73, 74, 91, 127, 165 Glaser R. 15 Goble C. A. 73 Gruber T. R. 4, 7, 17, 35, 73, 74, 78, 97, 112, 113, 126, 164 Guarino N. 74 Guha R. V. 119 Hart P. E. 44, 48 Hayes-Roth B. 18 Hayward S. A. 58 Hedgecock A. P. 108 Howkins T. J. 73 Humphreys B. L. 73 Ironi L. 29 Jacques G. 50 Jansweijer W. N. H. 118, 165 Johnson T. R. 66, 167 Josephson J. R. 13 Jullien C. 57 Kahn M. G. 71 Kay S. 73 Kehler T. 119 Kindler H. 129, 130 Kirsh D. 111 Klinker G. 37, 38, 50, 71 Koster R. W. 124 Kuipers B. 15 Kulikowski C. A. 15, 44, 48, 84 Lanzola G. 7, 76, 97, 129 Lenat D. B. 11, 119 Letsinger R. 3 Levesque H. J. 11, 118, 119 Lindberg D. A. B. 73 Linster M. 37, 50 Locatelli F. 31 Löckenhoff C. 71 MacGregor R. 119 Magnani L. 13, 80 Major N. 28, 45, 49, 57, 108

205

Marcus S. 15, 27, 42, 45, 49, 71, 106 Marques D. 37, 38, 50, 71 McCray A. T. 73 McDermott J. 1, 7, 15, 27, 37, 38, 45, 49, 50, 71, 106 Mengshoel O. 57 Mersereau T. 38 Miller R. A. 15, 22, 23 Motta E. 50, 66 Musen M. A. 2, 7, 10, 15, 24, 36, 42, 45, 49, 50, 51, 71, 73, 74, 91, 115, 127 Myers J. D. 15, 22, 23 Neches R. 17, 35, 164 Newell A. 1, 4, 10 Nii P. 18 Nordbø I. 57 Nowlan W. A. 73 O’Hara K. 66 Patil R. S. 15, 17, 35, 76, 78, 164 Peirce C. S. 13, 80 Peng Y. 13 Pfeifer R. 22 Pople H. E. 15, 22, 23 Portinale L. 82 Post W. M. 117, 124 Puerta A. R. 36, 51, 71, 115 Quaglini S. 29, 31, 97 Rademakers P. 22 Rajan T. 50 Ramoni M. 13, 15, 80 Ramparany F. 57 Rector A. L. 73 Reggia J. A. 13 Reichgelt H. 28, 45, 49, 57, 108 Rosch E. 76 Rothenfluh T. E. 15, 66, 127 Rouge A. 66 Rugg G. 108 Runkel J. T. 37, 51, 107, 115 Safir A. 15, 84 Salvaneschi C. 31

206


Schreiber A. T. 4, 7, 9, 10, 12, 36, 37, 41, 42, 58, 65, 68, 71, 74, 91, 93, 117, 164, 165 Schwartz W. B. 15 Senator T. 17, 35, 164 Shadbolt N. R. 43, 51, 57, 63, 66, 99, 108 Shahar Y. 73, 74, 91 Shaw M. L. G. 42, 54 Shortliffe E. H. 1, 42, 45, 49, 71, 82 Shrobe H. 74 Shulman L. S. 15 Simmons R. 118, 119 Simon H. A. 1, 15 Solorzano L. 57 Sprafka S. A. 15 Sramek M. 124 Srinivas S. 124 Steels L. 7, 21, 37, 51, 107, 118 Stefanelli M. 7, 13, 15, 29, 31, 71, 76, 78, 80, 97, 129 Stinson L. 38 Stutt A. 66 Swartout W. R. 7, 17, 35, 164 Szolovits P. 15, 74 Sølvberg I. 57 Tanner M. C. 13 Terpstra P. 57, 63 Thompson W. B. 7, 38 Torasso P. 82, 118 Toussaint C. 50 Tu S. W. 15, 36, 51, 71, 73, 74, 91, 127 Valente A. 66, 71 van Bemmel J. H. 38 Van de Velde W. 37, 66, 71, 74, 165 van Harmelen F. 127 van Heijst G. 7, 41, 57, 63, 66, 71, 93, 117, 167 VanLehn K. 15 van Melle W. 44, 48 van Someren M. 58 Vestli M. 57 Weiss S. M. 15, 44, 48, 84 Wick M. R. 7, 38 Wielemaker J. 50, 58, 99

Wielinga B. J. 2, 3, 4, 7, 9, 10, 12, 36, 37, 41, 42, 43, 51, 57, 58, 63, 65, 71, 74, 91, 99, 165 Williams B. C. 119 Yost G. 37, 50 Zdradahl Z. 66 Zocca V. 124

Curriculum Vitae Gertjan van Heijst was born in Oudenbosch, the Netherlands on the 28th of April 1965. He attended secondary school at the Thomas More College in Oudenbosch. In 1983 he began a degree in psychology at Tilburg University. In 1989 he received a M.Sc. in economic psychology at Tilburg University and a M.Sc. in cognitive science at Nijmegen University. In 1990 he started working as a research scientist and as a scientific programmer at the department of Social Science Informatics at the University of Amsterdam. He has been involved in two projects funded by the European Union in the field of knowledge engineering. From 1990 until 1992 he was involved in ACKnowledge, an ESPRIT project which focused on the development of a knowledge engineering workbench. After this project was finished, he started working on GAMES-II. The purpose of GAMES-II was to develop a methodology for medical knowledge-based system construction. Gertjan van Heijst is currently working in the areas of automated knowledge acquisition and methodological issues involved in knowledge-based system development.

207