Explanations and Case-Based Reasoning: Foundational Issues

Explanations and Case-Based Reasoning: Foundational Issues Thomas R. Roth-Berghofer1,2 1

Knowledge-Based Systems Group, Department of Computer Science, University of Kaiserslautern, P.O. Box 3049, 67653 Kaiserslautern, Germany 2 Knowledge Management Department German Research Center for Artificial Intelligence DFKI GmbH, Erwin-Schr¨ odinger-Straße 57, 67663 Kaiserslautern, Germany [email protected]

Abstract. By design, Case-Based Reasoning (CBR) systems do not need deep general knowledge. In contrast to (rule-based) expert systems, CBR systems can already be used with just some initial knowledge. Further knowledge can then be added manually or learned over time. CBR systems are not addressing a special group of users. Expert systems, on the other hand, are intended to solve problems similar to human experts. Because of the complexity and difficulty of building and using expert systems, research in this area addressed generating explanations right from the beginning. But for knowledge-intensive CBR applications, the demand for explanations is also growing. This paper is a first pass on examining issues concerning explanations produced by CBR systems from the knowledge containers perspective. It discusses what naturally can be explained by each of the four knowledge containers (vocabulary, similarity measures, adaptation knowledge, and case base) in relation to scientific, conceptual, and cognitive explanations.

1

Introduction

Case-Based Reasoning (CBR) systems, especially in today’s commercial contexts, do not have deep general knowledge. One of the strengths of CBR is that it is best applicable when there is no model available or a model is too hard to acquire and when cases are available or easy to generate. The downside is that, obviously, model-based explanations are just not possible to give. But this does not necessarily mean that a CBR system cannot provide good explanations. In his book ‘Visual Explanations’ [31], Edward Tufte invites the reader to ‘enter the cognitive paradise of explanation, a sparkling and exuberant world, intensely relevant to the design of information.’ The author addresses the human reader. But – because Artificial Intelligence (AI) is all about simulating human intelligence, and Case-Based Reasoning is all about simulating a major aspect of human problem solving ability – we as AI researchers should take Tufte’s words especially to heart. In AI, we are striving (not only but also) for the goal that AI systems discover explanations themselves and that they represent them appropriately in order to P. Funk and P.A. Gonz´ alez Calero (Eds.): ECCBR 2004, LNAI 3155, pp. 389–403, 2004. c Springer-Verlag Berlin Heidelberg 2004


390

Thomas R. Roth-Berghofer

communicate with their users. Until that goal is reached, we should at least provide such a system with pre-formulated explanation and representation templates, to support human users in their interaction with the system. In contrast to commercial expert systems in the 1980s, commercial Case-Based Reasoning systems were never marketed as potential replacement to human experts [17], although case-based expert systems exist. CBR tools such as CBRWorks and empolis orenge1 , or Kaidara Advisor2 were designed as parts of interactive decision support systems. Their explanation capabilities are rudimentary, yes, but do CBR systems per se need as much explanation capabilities as expert systems? Looking at all the efforts, already invested in explanation research, I think, we have just rattled at the gates of the above mentioned cognitive paradise. This paper tries to get a glimpse of what is behind those gates and shed some light on explanations in Case-Based Reasoning. It addresses foundational issues of explanations that CBR systems principally can provide, on the basis of the knowledge containers metaphor. The notion of knowledge containers, introduced by Richter [18] in 1995, is widely acknowledged and of great use in CBR system development, application, and maintenance [3, 21]. It helps to ask questions on how to structure available knowledge in order to ‘feed’ a case-based reasoner properly with knowledge. In the next section, we will have a look at explanations in Philosophy of Science and revisit some of Roger Schank’s work on explanation in AI. Section 3 recapitulates categories of explanations and major quality criteria for explanations. In Section 4, the knowledge containers are examined with respect to their explanatory power, before the explanation categories of Section 3 are related to the knowledge containers in Section 5.

2

What Is an Explanation?

In Philosophy of Science, the main kind of explanation discussed are scientific explanations. Scientific explanations answer why-questions [24]: Can some fact E (the explanandum) be derived from other facts A with the help of general laws L (the explanans L ∪ A)? There is an ongoing debate on the definition and semantics of scientific explanations which goes well beyond the scope of this paper. It is certainly domain dependent, how relevant explanations are that answer why-questions on the basis of laws of nature. One should also be aware of the distinction between (cause giving) explanations and (reason giving) justifications [24]. Explanation-seeking why-questions ask why an explanandum event occurred, i.e., for its cause or reason for being (‘Seinsgrund’). Reason-seeking why-questions ask why it is reasonable to believe that the explanandum event has occurred or will occur. They seek the reason for believing (‘Vernunftgrund’). Whatever kind of why-question 1 2

http://www.empolis.com http://www.kaidara.com

Explanations and Case-Based Reasoning: Foundational Issues

391

is to be answered in a knowledge-based system depends in the end on the goals of the respective system and its application domain. In real world situations, explanations are often literally false due to moral, pedagogical, and other context-dependent reasons [7]. Such explanations are designed to satisfy the questioner (at least temporarily). Nevertheless, they do not necessarily fulfill the purpose the questioner expects them to. For example, imagine the situation where a child asks her parents about where babies come from. The explanation most probably will not answer the question, it will just make the questioner stop asking. The adequacy of explanations as well as of justifications is dependent on pragmatically given background knowledge. What counts as a good explanation in a certain situation is determined by contextdependent criteria [7]. In Section 3, we will have a closer look at such quality criteria. According to Roger Schank, a famous cognitive psychologist and computer scientist who considerably contributed to the early phase of Case-Based Reasoning research, explanations are considered the most common method used by humans to support decisions [23]. Their main purpose is to explain a solution and the path that led to the solution, and to explain how the respective system works as well as how to handle the system. Explanations, therefore, must be inclusive as well as instructive. As soon as a system explains its own actions not only to those who inquire about how the system works, but also to itself, the system becomes an understanding system according to Schank’s spectrum of understanding. The spectrum ranges from making sense over cognitive understanding to complete empathy [23]. In this spectrum, work on computer understanding can only reasonably claim the left half of the spectrum, i.e., from making sense to cognitive understanding, as its proper domain. I think this is still true today and will not change in the near future, if ever. Schank distinguishes three classes of things that humans explain [22]: the physical world, the social world, and individual patterns of behavior. The three classes together with the above mentioned spectrum of understanding can help deciding what reasonably can be explained by a computer. Most explanations certainly can be given with respect to the physical world, providing scientific explanations. In a world of software agents, recognizing, identifying, and explaining individual patterns of agent behavior becomes more and more important. But the purpose of explaining is not only a technical one. The (human) user is also interested in how much trust he or she can have in a system. An obvious approach to increasing the confidence in a system’s result is to output explanations as part of the result [15]. Belief in a system can be increased not only by the quality of its output but, more importantly, by evidence of how it was derived [29]. In recent work, Doyle et al. [8] address not only the point of credibility, they also demand that knowledge-based systems, such as expert systems and Case-Based Reasoning systems, need to justify and be accountable for their predictions, giving the user a sense of control over the system [30].

392

3

Thomas R. Roth-Berghofer

Explanation in Expert Systems

Expert Systems are programs designed to solve problems similar to a human expert in a particular, well-defined domain. The ability to explain the solution and the reasoning process that led to the solution is another characteristic of so-called First-Generation expert systems. It is seen as an important activity for any knowledge-based system as it satisfies the user’s need to decide whether to accept or reject a recommendation. The explanations of First-Generation expert systems were often found unsatisfactory and the dialogues unnatural [17], i.e., explanations often were nothing more than (badly) paraphrased rules, important aspects were missing, or too much information was given. In order to improve on dialogues, SecondGeneration expert systems focused on context, goals and actions, methods and justifications to support explanations, together with an even richer knowledge representation. But what kinds of explanations are of interest and what makes an explanation good? 3.1

Useful Kinds of Explanation

According to Spieker [27], there are five useful kinds of explanations in the context of expert systems: – Conceptual Explanations are of the form ‘What is . . . ?’ or ‘What is the meaning of . . . ?’. The goal of this kind of explanation is to map unknown concepts to known ones. – Why-explanations describe the cause or the justifications for a fact or the occurence of an event. Again, one has to clearly distinguish between causes and justifications. Whereas the first concept is causal in nature and not symmetric, the latter only provides evidence for what has been asked for. – How-explanations are a special case of why-explanations, describing processes that lead to an event by providing a causal chain. How-questions ask for an explanation of the function of a device. – The goal of Purpose-explanations is to describe the purpose of a fact or object. Typical questions are of the form ‘What is . . . for?’ or ‘What is the purpose of . . . ?’. – Cognitive Explanations are also a special case of why-explanations. Cognitive explanations explain or predict the behavior of ‘intelligent systems’ on the basis of known goals, beliefs, constraints, and rationality assumptions. The first four categories of explanations describe variations of scientific explanations, which answer questions based on laws of nature, thus explaining the physical world. Expert systems answer such questions by using the knowledge contained in their (static) knowledge base. Cognitive explanations, on the other hand, reflect a system-related view. They deal with the processing of the system. In a way, cognitive explanations explain the social world and individual patterns of behavior. We will come back to these kinds of explanations in Section 5.

Explanations and Case-Based Reasoning: Foundational Issues

3.2

393

Aspects of Good Explanations

Five aspects of good explanation in a knowledge-based system are deemed important and fall into three classes [30]. The first requirement is concerned with how the explanations are generated. The second and third are requirements on the explanations themselves. The fourth and fifth concern the effect of an explanation facility on the construction and execution of an expert system. – Fidelity. The explanation must be an accurate representation of what the expert system does. Therefore, the explanations must be based on the same knowledge that the system uses for reasoning. – Understandability. The generated explanations must be understandable, i.e., conceptually as well as regarding its content. According to Spieker [27], they also should be innovative with respect to the knowledge of the user. Explanations, generally, should not contain already known information apart from knowledge required for argumentation. They must be relevant with respect to the goals and intentions of the users at an appropriate level of abstraction. And last, but not least, explanations must be convincing, i.e., explanations which are based on assumptions accepted by the user should be preferred. Swartout and Moore [30] call those factors involved in understandability terminology, user sensitivity, abstraction, and summarization. They further identfied the factors perspectives, feedback, and linguistic competence. The system should be able to explain its knowledge from different perspectives and should allow for follow-up questions if the user indicates that he or she does not understand (part of) an explanation. The explanations should sound ‘natural’ and adhere to linguistic principles and constraints. – Sufficiency. The system has to know what it is talking about. Enough knowledge must be represented in the system to answer the questions users have. – Low construction overhead. Explanation must either impose a light load on the construction of an expert system, or any load that is imposed should be rewarded, for example, by easing some other phase of the expert system’s life cycle. – Efficiency. The explanation facility should not degrade the run time efficiency of the expert system. Studies indicate that novice users prefer higher-level explanations mixed with background information and low level explanations, whereas experts tend to prefer low-level explanations [8]. Novice users also tend to prefer explanations that justify results (why-explanations), while experts are more interested in anomalies and tend to prefer explanations that explain the reasoning trace (howexplanations). But, according to Cawsey [6], there is no simple relation between the level of user expertise and the level of detail described, and appropriate user models are hard to develop. Therefore, Swartout and Moore [30] suggest to use stereotypical user models where the level of detail is customized to each stereotype.

394

4

Thomas R. Roth-Berghofer

Explanations in Case-Based Reasoning Systems

Doyle et al. recently reviewed CBR systems with respect to their explanation capabilities [8]. All reviewed systems contain rich background knowledge. But what, in principle, can CBR systems explain with respect to the knowledge containers? Artificial Neural Network systems cannot explain their decisions because knowledge is not available explicitly. Knowledge is compiled into the structure of the neural net. Rule-based systems, e.g. expert systems, can refer to their rules. But even experienced users often have problems following those explanations. In contrast to expert systems, case-based reasoners can present cases to the user to provide compelling support for the system’s conclusions, as pointed out by Leake [10]. But cases are not the only source of knowledge in a CBR system and cases cannot provide provide information about how they were selected, i.e., they cannot give cognitive explanations. Vocabulary

c Vo

y

lar

bu

ca

ula

Adaptation knowledge

ab

Similarity measures

Vo

ry

Case base

Fig. 1. The four knowledge containers of a CBR system

4.1

The Knowledge Containers Revisited

Knowledge-based systems store knowledge explicitly to use it for problem-solving. Part of the knowledge is represented directly and another part can be derived using methods of inference. For CBR systems, Richter [18] introduced the notion of knowledge containers that contain and structure the knowledge of a case-based reasoner. A knowledge container is a collection of knowledge that is relevant to many tasks rather than to one. Prominent knowledge containers in rule-based systems, for instance, are facts and rules. For CBR systems, Richter describes four such knowledge containers: vocabulary, similarity measures, solution transformation (also called adaptation knowledge), and case base. They are depicted in Fig. 1. The vocabulary knowledge container covers everything that defines the system, e.g., attributes, predicates, and the structure of the domain schema. Thus

Explanations and Case-Based Reasoning: Foundational Issues

395

the vocabulary forms the basis for all of the other three containers. The knowledge that defines how the most useful case is retrieved and by what means the similarity is calculated, is held by the similarity measures container. The adaptation knowledge container covers the knowledge for translating a prior solution to fit a given query and the case base stores the experience of the CBR system in the form of cases. The structure of the knowledge of CBR systems is a major advantage of CBR compared with expert systems [11]. It reduces the knowledge acquisition bottleneck to a large degree by forcing attention to issues on the relation between cases, the level of abstractions to encode them, how to generalize them to new problems, etc. Cases are acquired relatively easily in contrast to general knowledge. Another advantage is that each knowledge container can be changed locally. Changes in one container have little effect on the other containers. For example, adding new cases to the case base does not change the similarity measures. This property helps in maintaining the knowledge of case-based reasoners [21]. Of course, changing one knowledge container will have some impact on the other knowledge containers, but the knowledge containers view helps keeping changes local. The flexibility to decide pragmatically which container holds which knowledge, is a third advantage, because, in principle, each container can carry almost all available knowledge, but that does not mean that it is advisable [18]. For instance, when the case base contains all potential cases, neither a similarity measure (the identity function would suffice) nor adaptation knowledge would be needed. In fact, a traditional database could be used. The other extreme would be to have a complete model of adaptation. Starting with some arbitrary case and adapting it to solve the current problem, no case base – better, a case base containing only one arbitrary case – and no similarity measure would be needed. In fact, this resembles a model-based reasoner. Based on the knowledge container view, I will now try to show what a CBR system can explain quite naturally. In the following, I assume an attribute-value representation as is found most commonly in commercial as well as in research CBR shells. 4.2

The Case Base: The Main Source for Explanations?

Cases often are said to be self-explaining. This is probably true if we look at help-desk applications (e.g., [26],[25], or [9]) or hotline scenarios (e.g., [12] or [21]) where prior experience is reused and cases contain problem as well as solution descriptions. But if we look at e-commerce scenarios where complex products are sold such as Electronic Designs [28], the statement is highly questionable. Here, more complex explanation strategies are needed [13]. The two scenarios show two types of cases which, according to Richter [19], are called cases of rule-type and cases of constraint-type. For cases of rule-type it is known a priori which of the attributes are the problem attributes and which of them are the solution attributes. This distinction is determined at design time of

396

Thomas R. Roth-Berghofer

the CBR system. In contrast, cases of constraint-type have no subdivision into problem and solution attributes. Which of the attributes describe the problem situation and which of them describe the solution is determined at run time of the application. Here, the subdivision into problem description and solution is only known a posteriori. Watson [32] adds two other dimensions of case types: homogeneous vs. heterogeneous and episodic vs. prototypical cases. Homogeneous cases all have the same attributes that are easily determined. The set of attributes remains fixed. Real estate is a good example domain. In contrast, heterogeneous cases have different attributes but may share some (e.g., patient cases from a hospital or cases of a help-desk support system). A full set of attributes is hard to elicit. Such applications may have to learn new attributes throughout their lifetime. The other important distinction is the source of the cases. Episodic cases are records of events such as insurance claims, equipment faults, or patient files. These kinds of cases may easily be converted from existing data in a bottom-up approach. In Textual Case-Based Reasoning [12], documents are transformed into structured cases. This transformation process reduces, in general, the richness of the semantic structure of a document, resulting in an index, the case, that represents the document. Here, the document is the explanation of the corresponding case. Prototypical cases are designed as examples of events, for instance, typical symptoms, or a typical tax fraud. They are designed top-down by experts and require knowledge elicitation. All of the case types have an impact on what explanations are possible to be constructed. Finding the optimal case, i.e., the case that solves a user’s problem, is the goal of the reasoning process. Thus, the resulting case cannot answer explicitly why it was selected or how. Those explanations can only be provided by the other three knowledge containers. 4.3

The Vocabulary: What Is the CBR System Talking About?

Commercial CBR system shells such as empolis orenge or those available from Kaidara employ an object-oriented or frame-like approach in order to capture necessary domain knowledge in a domain model or domain schema. The entities of the model, often called concepts, represent objects or facts about objects of the real world. Specialization of concepts is described by the is-a relation (e.g., a car is a vehicle). Properties of a super-concept are inherited by its sub-concept. The other important relation is the has-part /part-of relation, which decomposes a complex object into its simpler parts (e.g., a car has wheels/wheels are part of a car). The two structuring techniques, inheritance and decomposition, allow for answering such questions as ‘What is the structure of a case?’, ‘Where is the case’s class situated in the domain schema?’, ‘What other classes could I ask for?’, ‘Tell me about the parts of the case?’, and ‘Which parts of the case are specific to the case’s class, and which of the parts are inherited?’. Each attribute (slot, facet) of a concept can only contain values of a certain class limited by type constraints or range restrictions. The values may be of

Explanations and Case-Based Reasoning: Foundational Issues

397

simple or complex type. Simple types are, for example, strings or numerical values, whereas complex types themselves are decomposable. This property allows for explanations in response to questions such as ‘What are allowed values for this slot?’ and, thus, for ‘What could I have entered instead?’. For simple types, such questions are often answered in advance by providing drop down menus, where the user just selects the desired values from a certain range of values. For complex types, more elaborate selection and explanation processes are required. In general, the domain model should be enriched with comments about the model’s structure and about design decisions. Those could be posed to users who want to understand the intentions behind a given domain model. In many domains, the user knows about the values that he or she may enter or select to fill a slot, but in knowledge-intensive scenarios, the user often is at a loss. In those situations the user does not know enough to choose between alternatives, e.g., between two graphics cards for a new PC. In general, it surely holds that the more elaborate a model is, the more explanatory power it has. The vocabulary can be further divided into subcontainers [20]: input, output, and retrieval attributes. Input attributes are used to trigger completion rules, which set the values of dependent retrieval attributes. Those attributes are used by the retrieval process. Output attributes contain the result values. Each attribute can play one or all of the three roles at once. Again, the substructure can help to structure our thinking about the knowledge contained in the vocabulary. Exploring the vocabulary using such standards as Topic Maps3 with an appropriate browser can help make the user more familiar with the application domain addressed by a given CBR system. Topic Maps are used to organize and visualize topics and associations (relationships) between them. They are optimized to support the navigation in an information space. 4.4

Similarity Measures: Domain and Utility Knowledge

The similarity measures knowledge container provides the means to determine the degree of similarity between a query and a case. In [20], Richter describes two subcontainers, the local measures and the amalgamation function. Each local measure compares one attribute of a case. Local measures contain domain knowledge (e.g., similarity of car colors) while the amalgamation function is task oriented and contains utility knowledge (relevances for the task, e.g., the importance of the attribute car color vs. the attributes manufacturer and horse power in a used car trading scenario). A local measure can be used to explain how the values of one attribute are related to each other. It can explain relations between portions of the vocabulary. An amalgamation function, e.g., the weighted sum of local similarity values, can then explain the importance or relevance of an attribute based on the weight vector. Dependencies between attributes are often expressed using completion rules, which are filling in missing attribute values depending on the values of other 3

See [16] for an introduction.

398

Thomas R. Roth-Berghofer

attributes. For example, in an apartment recommendation system, the attribute ‘area’ depends on the width and length of the respective apartment. A completion rule could easily compute the missing values. The local-global principle [20] can not only be employed as a guideline for comparing or contrasting cases in order to develop appropriate similarity measures. With the local-global principle, one naturally can derive explanations related to the decomposition hierarchy, dealing with detailed attribute explanations as well as with higher level explanations. Similarity measures with their inherent utility knowledge are useful for justifying how and why the CBR system derived a particular list of results. 4.5

Adaptation Knowledge: The More the Better!

Solutions obtained from the case base using similarity measures may not be sufficient. This can be due to ill-formed similarity measures or to simply the fact that no better solution is in the case base. In this situation, the solution is adapted to better fit the user’s demands. Adaptation knowledge, often represented by rules, requires the most thorough understanding of the domain to be available and it requires the most formal representation to be applicable. Hence, as soon as adaptation knowledge is available, obviously, a lot more can be explained by the CBR system. In commercial scenarios, adaptation rules play only a tangential role. But, ‘there is little known about a systematic improvement of adaptation rules’ [20]. Table 1. Knowledge containers and their contribution to supporting explanations Knowledge container contributes to Vocabulary conceptual explanations, why-explanations, how-explanations, and purpose explanations Similarity measures why-explanations, how-explanations, purpose explanations, and cognitive explanations Adaptation knowledge why-explanations, how-explanations, and cognitive explanations Case base (provides context for explanations)

5

Relating Knowledge Containers to Explanations

In Section 3, we briefly described five categories of explanations. In the following, I will discuss which kind of questions could be answered by using primarily the knowledge of a particular knowledge container. Table 1 briefly summarizes to which kind of explanation each knowledge container contributes mainly.

Explanations and Case-Based Reasoning: Foundational Issues

399

Generally, a question can either address the CBR application (i.e., how to use the system), or it can be related to its content (i.e., its knowledge). Questions regarding the CBR application are beyond the scope of this paper. They commonly are answered by means of documentation, frequently asked questions, and user communities. Case-Based Reasoning approaches usually are classified using three categories: Conversational, Structural, and Textual Case-Based Reasoning [3]. Conversational CBR is a form of interactive Case-Based Reasoning. This approach is very useful in domains with many simple problems that must repeatedly be solved. Conversational CBR systems, in general, contain little domain knowledge (in machine processible form). Thus, I will not regard it in the following. Structural CBR relies on cases described with attributes and corresponding values. Structural CBR systems organize attributes in different ways, e.g., as flat attribute lists, as relational tables, or in an object-oriented way. The structural approach is useful in domains where additional knowledge such as complex similarity measures must be used in order to get good results, and where the domain model is easy to acquire. Textual Case-Based Reasoning systems aim at managing information contained in semi-structured documents and providing means for content-oriented retrieval. A domain model determines the structure of the cases, and a preprocessor fills the cases from the texts. Hence, Textual CBR is Structural CBR at its core where semi-structured texts are transformed into a structured representation. The textual approach is useful in domains where large collections of know-how documents already exist and the intended user is able to immediately make use of the knowledge contained in the respective documents.

5.1

Conceptual Explanations

Conceptual explanations answer questions regarding the semantics of concepts. They mainly address the vocabulary knowledge container. In Structural CBR systems, often object-oriented modeling is employed. The class structure with its inheritance relation and its decomposition structure provide further conceptual explanations. In systems such as CREEK [1, 2], where general (domaindependent) knowledge is represented as semantic network, much more detailed conceptual explanations can be given4 . In Textual CBR, as mentioned above, well written documents are to some degree self-explaining, giving at least clues where to look also for more information on the topics described by this document. Due to the fact that Textual CBR is Structural CBR at its core, there is a lot of additional knowledge available that is necessary for transforming a text into a case structure. In order to identify the concepts of the domain model, for example, synonyms and antonyms, different ways of writing, abbreviations, etc. are modelled. They map words or phrases 4

In CREEK, explanations are generated to explain reasoning steps or to justify conclusions to the user, and, more important, for the internal use of the reasoner.

400

Thomas R. Roth-Berghofer

to concepts of the domain schema5 . Thus, explanations of concepts could be supported by providing contextual information using the transformation information. 5.2

Why-, How-, and Purpose-Explanations

Why-explanations as well as how- and purpose-explanations are scientific explanations (as described in Section 3). Questions expecting those kinds of answers, in general, can only be answered by systems that have an elaborate model of reality, i.e., that have a detailed domain model, rich in classes, attributes, and predicates. Hence, the vocabulary knowledge container with its static knowledge provides most of the knowledge for scientific explanations. The similarity knowledge container contributes additional domain and utility knowledge. Utility knowledge may help to select the correct level of detail because it contains knowledge about the relevance of attributes. Even more explanatory value can be provided by the adaptation knowledge because, in order to adapt a prior solution to a new situation, complex knowledge is necessary. The case base can only provide indirect or contextual knowledge. It may be used to enrich model-based explanations. 5.3

Cognitive Explanations

In my opinion and from my experience with the development and maintenance of (commercial) CBR applications, cognitive explanations are the most important kind of explanations. Most users ask such questions as ‘Why did the CBR system suggest these results?’. Explanations provided, for example, by empolis orenge use coloring schemes in order to markup concepts identified in the query and the case together with the degree of matching (cf. [28]). But there is more to explain. The similarity measures knowledge container, including completion rules, provide the starting point to explain the match between query and case on different levels of granularity. Together with available adaptation knowledge, the relations between result cases can be explored along different dimensions. This could help the user in developing a mental image of the competence of the CBR system and, thus, building up trust in the CBR system.

6

Conclusions and Future Research Directions

The four knowledge containers provide the major portion of knowledge necessary for CBR systems for constructing explanations. But it may be helpful to add an additional knowledge container for explanatory knowledge, as the knowledge required for reasoning need not be the same as for explaining (even though explanations should be based on the knowledge used for reasoning, as stated 5

In empolis orenge, such knowledge is provided by the analysis model, a part of the domain model (see Appendix A of [21] for further information).

Explanations and Case-Based Reasoning: Foundational Issues

401

earlier by the ‘fidelity principle’ of good explanations). Remember that to have understandable explanations one needs to use the users’ own terms. Using two knowledge bases is one of the main architectures found in second-generation expert system explanation [30]. Such an additional knowledge container may lessen the burden of explanation generation and could improve the explanation capabilities of a CBR system. Improving explanation capabilities of knowledge-intensive Case-Based Reasoning systems currently is an important research direction. In domains where the user easily gets lost in the information space, he or she must have trust in the application that is intended to support his or her decisions – a point that was emphasized several times in this paper. The issue of trustworthiness and trust, credibility, and confidence in computer systems, in general, is also an important issue in the upcoming Semantic Web [4], an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation [5]. The Semantic Web currently is not an application, it is an infrastructure on which many different applications will be developed. There are already initiatives on increasing trust by exchanging proofs/explanations in standardized formats between (logic-based) inference engines [14], but what about CBR systems. How could CBR systems be integrated in such a ‘Web of Trust’ ? What does a ‘CBR proof’ look like? There is currently also revived interest in the development and research of explanations produced by expert systems. For example, Wollny [33] examined the problem of explaining solutions found by cooperating expert systems. An explanation comment is attached to each partial solution of the distributed problem solving process and submitted to the expert system, which is interacting with the user. This system then provides an explanation for the whole solution. Perhaps, some of the research results could be transferred to CBR. This paper is, as stated at the beginning, just a first pass on foundational issues regarding explanations from a knowledge container perspective. The presented ideas will be elaborated in future work.

Acknowledgments I thank Rainer Maximini for inspiring me to write this paper. I also thank the anonymous reviewers. Their suggestions and comments greatly contributed to improve the preliminary versions of this paper. It was not possible to discuss in this paper all the issues they have highlighted, but this will be helpful for future work.

References 1. Agnar Aamodt. Explanation-driven case-based reasoning. In Klaus-Dieter Althoff Stefan Wess and Michal Richter, editors, Topics in Case-Based Reasoning, Berlin, 1994. Springer-Verlag.

402

Thomas R. Roth-Berghofer

2. Agnar Aamodt. A knowledge representation system for integration of general and case-specific knowledge. In Proceedings from IEEE TAI-94, International Conference on Tools with Artificial Intelligence, pages 836–839, New Orleans, 1994. 3. Ralph Bergmann, Klaus-Dieter Althoff, Sean Breen, Mehmet G¨ oker, Michel Manago, Ralph Traph¨ oner, and Stefan Wess. Developing Industrial Case-Based Resoning Applications: The INRECA Methodology. Lecture Notes in Artificial Intelligence LNAI 1612. Springer-Verlag, Berlin, second edition, 2003. 4. Tim Berners-Lee. What the semantic web can represent, 1998. http://www.w3.org/DesignIssues/RDFnot.html [Last access: 2002-07-09]. 5. Tim Berners-Lee, James Hendler, and Ora Lassila. The semantic web: A new form of web content that is meaningful to computers will unleash a revolution of new possibilities. ScientificAmerican.com, May 2001. http://www.scientificamerican.com/article.cfm?articleID= 00048144-10D2-1C70-84A9809EC588EF21 [Last access: 2004-04-29]. 6. Alison Cawsey. User modelling in interactive explanations. Journal of User Modelling and User Adapted Interaction, 3(1):1–25, 1993. 7. Daniel Cohnitz. Explanations are like salted peanuts. In Ansgar Beckermann and Christian Nimtz, editors, Proceedings of the Fourth International Congress of the Society for Analytic Philosophy, 2000. http://www.gap-im-netz.de/gap4Konf/Proceedings4/titel.htm [Last access: 2004-03-11]. 8. D´ onal Doyle, Alexey Tsymbal, and P´ adraig Cunningham. A review of explanation and explanation in case-based reasoning. Technical Report TCD-CS-2003-41, Trinity College Dublin, 2003. 9. Mehmet G¨ oker, Thomas Roth-Berghofer, Ralph Bergmann, Thomas Pantleon, Ralph Traph¨ oner, Stefan Wess, and Wolfgang Wilke. The development of HOMER – a case-based CAD/CAM help-desk support tool. In Barry Smyth and P´ adraigh Cunningham, editors, Advances in Case-Based Reasoning, Proceedings of the 4th European Workshop, EWCBR’98, Dublin, Ireland, pages 346–357, Berlin, 1998. Springer-Verlag. 10. David Leake. CBR in context: The present and the future. In David Leake, editor, Case-Based Reasoning: Experiences, Lessons, and Future Directions, pages 3–30, Menlo Park, CA, Cambridge, MA, 1996. AAAI Press/MIT Press. 11. Mario Lenz, Brigitte Bartsch-Sp¨ orl, Hans-Dieter Burkhard, and Stefan Wess, editors. Case-Based Reasoning Technology: From Foundations to Applications. Lecture Notes in Artificial Intelligence. Springer-Verlag, Berlin, 1998. 12. Mario Lenz, Andr´e H¨ ubner, and Mirjam Kunze. Textual CBR, chapter 5, pages 115–137. Lecture Notes in Artificial Intelligence. Springer-Verlag, Berlin, 1998. 13. Rainer Maximini, Andrea Fressmann, and Martin Schaaf. Explanation service for complex CBR applications. 2004. See this volume. 14. Deborah L. McGuinness and Paulo Pinheiro da Silva. Infrastructure for web explanations. In Dieter Fensel, Katia Sycara, and John Mylopoulos, editors, The Semantic Web — ISWC 2003, 2003. 15. Johanna D. Moore and William R. Swartout. Explanation in expert systems: A survey. Research Report RR-88-228, University of Southern California, Marina Del Rey, CA, 1988. 16. Steve Pepper. The TAO of Topic Maps. 2004. http://www.ontopia.net/topicmaps/materials/tao.html [Last access: 2004-06-03]. 17. Debbie Richards. Knowledge-based system explanation: The ripple-down rules alternative. Knowledge and Information Systems, 5(20):2–25, 2003.

Explanations and Case-Based Reasoning: Foundational Issues

403

18. Michael M. Richter. The knowledge contained in similarity measures. Invited Talk at the First International Conference on Case-Based Reasoning, ICCBR’95, Sesimbra, Portugal, 1995. http://wwwagr.informatik.uni-kl.de/~lsa/CBR/Richtericcbr95remarks.html [Last access: 2002-10-18]. 19. Michael M. Richter. Generalized planning and information retrieval. Technical report, University of Kaiserslautern, Artificial Intelligence – Knowledge-based Systems Group, 1997. 20. Michael M. Richter. Knowledge containers. In Ian Watson, editor, Readings in Case-Based Reasoning. Morgan Kaufmann Publishers, 2003. 21. Thomas R. Roth-Berghofer. Knowledge Maintenance of Case-Based Reasoning Systems – The SIAM Methodology, volume 262 of Dissertationen zur K¨ unstlichen Intelligenz. Akademische Verlagsgesellschaft Aka GmbH / IOS Press, Berlin, Germany, 2003. 22. Roger C. Schank. Explanation: A first pass. In Janet L. Kolodner and Christopher K. Riesbeck, editors, Experience, Memory, and Reasoning, pages 139–165, Hillsdale, NJ, 1986. Lawrence Erlbaum Associates. 23. Roger C. Schank. Explanation Patterns: Understanding Mechanically and Creatively. Lawrence Erlbaum Associates, Hillsdale, NJ, 1986. 24. Gerhard Schurz. Scientific explanation: A critical survey. IPS-Preprint 1, Department of Philosophy, University of Salzburg, 1993. 25. Evangelos Simoudis. Using case-based retrieval for customer technical support. IEEE Expert, 7(5):7–12, October 1992. 26. Evangelos Simoudis and James S. Miller. The application of CBR to help desk applications. In Proceedings of the DARPA Workshop on Case-Based Reasoning, pages 25–36, Washington, DC, 1991. 27. Peter Spieker. Nat¨ urlichsprachliche Erkl¨ arungen in technischen Expertensystemen. Dissertation, University of Kaiserslautern, 1991. 28. Marco Spinelli and Martin Schaaf. Towards explanations for CBR-based applications. In Andreas Hotho and Gerd Stumme, editors, Proceedings of the LLWA Workshop 2003, pages 229–233, Karlsruhe, Germany, 2003. AIFB Karlsruhe. 29. William R. Swartout. XPLAIN: A system for creating and explaining expert consulting programs. Artificial Intelligence, 21(3), 1983. 30. William R. Swartout and Johanna D. Moore. Explanation in second generation expert systems. In J. David, J. Krivine, and R. Simmons, editors, Second Generation Expert Systems, pages 543–585, Berlin, 1993. Springer Verlag. 31. Edward R. Tufte. Visual Explanations. Graphics Press, Cheshire, Connecticut, 1997. 32. Ian Watson. Workshop on automating the construction of case-based reasoners at IJCAI’99, 1999. http://www.ai-cbr.org/ijcai99/workshop.html [Last access: 2003-02-09]. 33. Stefan Wollny. Erkl¨ arungsf¨ ahigkeit kooperierender regelbasierter Expertensysteme zum diagnostischen Probleml¨ osen. PhD thesis, Technische Universit¨ at Berlin, 2003.