Explanation, trust, and transparency are concepts that are strongly tied in with users' con dence in, and acceptance of computerised systems. Case-based reasoning (CBR) systems lend themselves easily to generate explanations, as they typically organise and represent knowledge in a way that makes it possible to reason about and thereby generate explanations. The work presented here is a rst step towards making a CBR engine explanation-aware. We demonstrate how a plugin for Protege and myCBR can facilitate explanations for the retrieval phase of a CBR system.
An increasing number of tasks are delegated to computerised and automated systems. With more and more systems being in charge of a process users have less control over which operations are done and why. This can lead to confusion since the user does not know the motivation behind actions performed; they might not even know which actions are performed. If a system performs actions that is unexpected con dence in the system will decrease unless it can justify its behaviour. Mitigating these problems can be done by putting e ort into making systems explanation-aware.
The ability to explain yourself, your reasoning and actions, has been identi ed
as one core capability of any intelligent entity [
The term explanation has been widely investigated in di erent disciplines such as cognitive science, arti cial intelligence, linguistics, philosophy of science, and teaching. All these disciplines consider certain aspects of the term and make clear that there is not only one such concept but quite a number of them. Some of these aspects have been applied in knowledge-based systems.
One way of looking at explanations that allows to handle explanations by software systems is to treat explanations as answers to questions. Whenever you experience something unexpected while working with a software system you have a question, and you expect an answer to it. It does not matter whether the question is raised explicitly or not.
Explanations are an important vehicle to convey information to understand
one another in everyday conversations. They enhance the knowledge of
communication partners in such a way that they understand each other better.
Explanation-aware computing (ExaCt) is the vision of software systems being
smart in interactions with their users [
The work presented in this paper reports on the rst step on enhancing a
case-based reasoning engine with explanatory capabilities [
The rest of the paper is organised as follows: Section 2 gives an overview of related work; Section 3 describes the design and implementation of the explanationaware case-based reasoner (myEACBR); Section 4 discusses the implementation; the paper concludes with a summary and outlook on future work. 2
In order to use information we have to know how it relates to other things. There
is a signi cant di erence between knowing that a system works and how or why
it works. Further, the user of a system is more likely to trust it when the system
can rationalise its behaviour, in particular how it reaches an answer [
Generally, there is no point in giving an explanation if its content is not
understandable to the user; regardless of whether it is valid and can be
considered a true explanation. When constructing an explanation we therefore have to
consider who the receiver is and the user's level of understanding. This aspect
of explanations and user modelling has received some attention over the years
(see, e.g., [
Originally, case-based reasoning emerged from an understanding of reasoning
as being a process of explanation [
S rmo et al. [
Roth-Berghofer [
Other work has focused on using CBR as a mechanism to realise ambient
intelligent systems [
myCBR is an open source case-based reasoning tool4. Key motivation for
implementing myCBR was the need for a compact, easy-to-use tool for building
prototype CBR applications in teaching, research, and small industry projects
with minimal e ort [
Protege is an application for editing ontologies. Initially built for a few
specialised programs in medical planning it has since then evolved into a much
more general-purpose set of tools with a large community of users and
contributors [
The major change in Protege's software architecture made myCBR 2 incompatible with Protege 4. This and the demand for an SDK triggered the development of the myCBR 3 SDK and GUI. The SDK provides a completely rewritten foundation for the OSGi-based GUI. The work reported here shows one way of using the myCBR 3 SDK. 3
Protege is based on the idea that as much functionality as possible should be implemented as plugins. The \plugin part" of our implementation is de ned by three les. The only source le we have in this regard is RetrievalComponent which extends AbstractOWLViewComponent, which is roughly equivalent to JPanel in Swing. It allows one to add components to be viewed on the screen. RetrievalComponent contains all of our components, both the ones that are shown on screen as well as the \back-end" objects.
Thing hasConceptName Distinct name of the concept explained; hasExplanationSource Name of the class that constructed the explanation;
hasLink Link to an Internet resource used when constructing the explanation; hasTextualExplanation The textual explanation itself.
To test our implementation we use the dinner domain. We have created an ontology importing the CBR ontology introduced in the above section and a wine and food ontology provided by W3C.6 The two ontologies have been imported into a new ontology with the shared namespace.
The top-level of the resulting ontology is shown in Figure 2. In addition to these two imports the ontology contains two primitive classes, DinnerCase, as a sub class of CBR-Case, and Person, as a sub class of Thing. Instances of DinnerCase are supposed to be cases of dinners that have been recorded, and instances of Person are normal persons that for instance have eaten a dinner. An instance of DinnerCase typically has data properties and object properties representing the person(s) that has eaten the dinner, where it was eaten, what was eaten, the type of beverages and so on.
Thing
We chose to create cases directly in Protege instead of creating a separate interface for this in our plugin. This is done by creating instances of DinnerCase and assigning properties to the instance.
Before the user has added any attributes to the query it has attributes for the ID, always being \a query"; the author, defaulting to the system user name; and the time when the query was initialised. The next thing to specify is what concept the property should belong to, done by selecting a class from the class hierarchy. If the attribute is supposed to represent the person eating the dinner, Person is the appropriate class to choose in this step. After this the name of the attribute has to be speci ed in a standard input eld. To represent the person eating dinner this has to be eatenBy, as this is the name we have used in all our test cases.
What happens after the name has been speci ed depends on the type of attribute speci ed. For most attribute types a standard input eld is used to input the desired value. This dialogue accepts only certain input based on attribute type, so that if an invalid value (e.g. \food" in a eld for an integer attribute) is speci ed the input eld reappears. The input eld is shown until either the value is valid or \cancel" is pressed. When attribute type Instance is selected a dialogue showing all de ned instances of the speci ed concept is shown. When the query is fully speci ed \Execute query" is pressed, and the query is executed. The top queries are then listed in the middle of the screen ordered by their similarity with the query. 3.1
In our test ontology, most dinner cases are inferred to be members of the MealCourse class as well as DinnerCase. Protege will explain this by showing that the dinner case is a member of DinnerCourse because it has the property hasDrink, which is speci ed to have the domain of MealCourse. It has also been inferred that MealCourse is disjoint with the class NonConsumable. The explanation provided is that MealCourse is a subclass of ConsumableThing, and NonConsumable is equivalent to the complement of this class.
This type of explanation given by Protege is not of very much use for a novice user. The explanations are simply a trace of the axioms that result in the inferred statement that we have requested an explanation for. We do however doubt that the intent of these explanations is to explain things to novice users. It is more likely that they are intended for debugging, and perhaps understanding, the active ontology, and it is not very likely that persons with these goals are novices. Similarity Explanations The ability to explain the similarities between query and instance comes mainly from the improvements done to myCBR 3. We think it is useful for the user to be able to see a decomposition of the similarity computation, such that he can better understand how the attributes he speci es in the query a ects the result. Similarity explanations are cognitive (or action) explanations (see Figure 3 for an explanation of case similarity).
It is possible to view the selected case's attributes. Thereby its similarity explanation can be shown in a separate panel on the screen. The panel shows the corresponding attribute in the selected case instance. We see from the figure that the total similarity was 75%, with sub similarities of 100% and 50% for eatenBy and priceInNOK respectively.
Having selected the first row in this panel and pressing justification the window shown in Figure 3.16 is shown. This shows a slightly more detailed view of the instance the query has been compared to. As in the view shown in Figure 3.14 only the attributes present in the query is shown.
same information as in the query result, the case name and the total similarity.
When the querItyalso showdseefiacnheadttribute speci eduintethe query andntohetsimilarity between its has an attrib that is present in the case instance the similarity vvaalulueseins tshheoquwerny ainsd Nthe/cAas.e in the selected case instance. In addition tIon asdhdiotiwon ttohsehowq utheerqyueraynadnd ccaases einsitannscteaanttrcibeutaetvtalruiebs uwtiteh tvheairlues with their similarity in Figure 4, an explanation of how the similarity metric works is shown. similarity in FWige ucarnese3e.t1ha6t,thaenInsetxanpcleaFunnacttiioonnis oaffunhcotiwon tthahtesimspimlyciloamrpiuttyes amnetric works is shown. We canaggsreegeattehoaftthetshimeilIarnitsytvaanluceseoFf uthne cintsitoannce'issatatrifbuutnescutsiiongnatchonatgusreidmply computes method. We can also see that the shown function is con gured to compute a an aggregate owfeigthhteed ssuimmoiflathreistiymilvaraitliuesewsheonfcotmhpeareidntsotaaqnucerey’.s attributes using a configured method. As we can see that the shown function is configured to compute a
Concept Explanation myEAhCeBnR pcroovides explanation for the concept thee she-ave chosen not weighted sum of the similarities w mpared to a query. W lected attribute belongs to. For an example, the two concepts, Person and Cost for eatenBy and priceInNOK respectively. The concept explanations originate from both online and o ine sources, providing several explanations for each concept given that each source contains information about it. We have implemented four knowledge sources for concepts that we now will describe.
Wordnet is a lexical database containing more than 118,000 di erent word forms and more than 90,000 di erent word senses and semantic relations between words.7 We do however not make use of all these relations, only the description and synonyms of the words being names of the concepts to be explain.
When the user demands a concept explanation the Wordnet dictionary is queried, resulting in zero or more word de nitions. When the result contains more than one word, the user is given the ability to choose which meaning of the word should be used. Both the de nition of the meaning of the word and
its synonyms are shown in this dialogue. Since there are other relations between words stored in Wordnet it would be possible to display more information about each word, but this was not prioritised as high as other matters in the project. Wikipedia and Wiktionary The explanations we construct from Wikipedia and Wiktionary8 are simply the text that is available on the page with the same name as the concept. This could be enhanced by providing some option to the user to change to a di erent page when there are alternative pages with topics sharing a name, but the API provided did not have such functionality \out of the box" so this feature would have been quite complex to implement. Wolfram Alpha is a \computational knowledge engine", matching queries to a controlled library and computing answers and relevant visualisations from a core knowledge base of curated, structured data9. The results returned when queried contains the meaning which the engine assumes was intended by the query as well as a number of \pods", each containing some bit of information about the subject. An API to query Wolfram Alpha by other means than through a browser is available and is free, but the number of queries available is limited to 2,000
per month. It provides the data in several formats and provides an easy way to navigate to alternative interpretations of the query in our plugin.
Figure 5 depicts a collage of the three di erent concept explanations arriving from Wordnet, Wikipedia and Wolfram Alpha. To trust an explanation it is important to be aware of its provenance, where it came from. This is important for both the experts behind the system as well as the users of it. When the experts need to verify the explanations given, the system needs to be able to tell how the answers were derived such that the experts know that it was not based on a bug or some other anomaly. The same reason applies for the users of the system, they need to know that the knowledge used originates from a trusted knowledge source and that valid methods are used for computing answers from these sources.
To some degree this is the same as the cognitive and justi cation explanation, showing the steps gone through when computing the answer and why this method was used. In our plugin and myCBR 3 it is possible to examine the whole tree of similarities resulting in the nal similarity value, and the similarity metrics underlying the computation is described in the justi cation explanations. In addition to this the source giving each particular concept explanation is shown, as well as a link showing where to obtain a similar explanation of the concept in a browser.
In the case of Wikipedia, Wiktionary, and Wolfram Alpha these links will show exactly the same explanation as shown in our plugin. In the case of Wordnet we were not able to nd a method for specifying which of the di erent meanings of a word is required.
A comment we can make on the three former knowledge sources is that they themselves have quite good provenance. Wolfram Alpha does not list speci c references for the di erent items in their result, but provide information about the sources for each topic of knowledge as a link (\Source information"). For all Wikipedia entries it is possible to view the history of everyone that has contributed to the entry and what they have contributed. We will not go into the discussion of how reliable this information is since this is far outside the scope of the project. 4
In evaluating our approach we followed a staged model for AI research as
described by Cohen and Howe [
The similarity explanations we have presented are a combination of action and justi cation explanations aiming at transparency. The nal similarity value can always be decomposed into its local similarity measurements. The justi cation comes from the fact that each explanation contains information about what method was used to calculate the similarity value. In particular the name of the similarity function as well as a description of how it works and what con guration parameters has been set.
There are some elements missing regarding the content of the similarity explanation, in particular regarding justi cation. Missing are for the most part visualisations; if present they would make the explanations easier to understand for a novice user, increasing the con dence in the system. It would, for example, be easier to understand how the IntegerFunction works if a graph was presented such that the user could see how the similarity values were distributed.
The explanations are however highly relevant (as long as the description of a similarity function is done properly). Since the function description is exclusively text, there may be some problems in cases where it contains concepts that should have been linked such that they could be explained.
The explanations, since they were constructed from local to global similarity measurements have high delity, veri cation and duplication, exposing what knowledge has been used to generate the explanation. 4.2
The concept explanations presented are not really constructed from a knowledge source within our system, but rather an aggregate of other knowledge sources outside the system. We merely fetch descriptions from other sources based on the name of the concept for which an explanation has been requested. That an explanation should be constructed from a particular knowledge source is of course not a requirement or criterion. It does however mean that the explanation given is not necessarily coherent, since it comprises up to four di erent explanations of the concept. Here it becomes visible how much the quality of concept explanations depends on the quality of the attached knowledge sources and on the abilities of the knowledge engineer in providing the knowledge.
We are undecided to whether the transparency and justi cation aspects of the concept explanations should be evaluated as good or poor. The system does not show the user how the explanations were generated, it only gives it to the user along with a link indicating where the online version might exist. It is indicated to the user where the information is originating from, and that several alternatives are o ered when there are several entries with the same title. Because of this, one could argue that the explanation is transparent and justi ed since it is fairly clear that the explanation is gathered from this knowledge source, and that this is the entry the particular source had for the concept in question. Again, this is quite dependent on the knowledge engineer's work. The concept explanations are however in most cases good explanations of what the concept in question is, and how it is used. The four sources we have used are quite good and reliable. 5
In this paper we presented our work on a rst step of enhancing a case-based reasoning engine with explanatory capabilities. We demonstrated how the retrieval phase in myCBR 3 can be made explanation-aware by implementing a plugin for Protege 4.x that generates explanations for the similarity values found in the retrieval step of the case-based reasoning cycle. In addition to this, the presented system is able to explain concepts used in the domain model by consulting external knowledge sources.
A next step will be to analyse requirements from the experience with this integration and to further enhance the explanation capabilities of the myCBR 3 SDK and the myCBR 3 GUI.
This work has partially been supported by the RAE-funded project \Explanationaware myCBR development" at the University of West London.