A Knowledge Modeling Editor and Testing Environment for Knowledge-Intensive Case-Based Reasoning
Total Page：16
File Type：pdf, Size：1020Kb
TrollCreek Tutorial A Knowledge Modeling Editor and Testing Environment for Knowledge-Intensive Case-Based Reasoning
Authors: Tore Brede Frode Sørmo [email protected] Agnar Aamodt [email protected] Ketil Bø
Tutorial ”ledgend” Entities in italic Relations underscored TrollCreek commands in bold
Revision date: 15.10.2006
1 Content:
1 Introduction...... 2 2 What is TrollCreek?...... 2 3 How to model in TrollCreek...... 3 4 Creating a new model...... 6 5 Views...... 7 6 Adding entities and connecting them with relationsships...... 9 7 Inheritance with has subclass/has instance...... 12 8 Building the hierarchy of entities...... 14 8.1 The existing hierarchy...... 15 8.2 Placing our entities in the existing hierarchy...... 15 8.3 User exercise: Adding the entities...... 17 8.4 How to build a taxonomy...... 18 9 Entities and relationships in the reasoning process...... 19 10 Adding new relation types...... 20 10.1 Steps involved in creating a new relation type...... 20 10.2 Explanation of the different fields in the New Domain Relation-dialogue...... 21 10.3 Explanation Strength...... 23 10.4 Why create new relation types?...... 24 10.5 User exercise: Adding the relation types...... 24 11 Building the network of domain knowledge...... 25 12 Adding cases...... 26 12.1 What should a case contain?...... 26 12.2 Steps involved in adding a case...... 27 12.3 Explanation of the fields in the Case View...... 29 12.4 Importance and predictive strength...... 29 12.5 User exercise: Adding the cases...... 31 13 The case matching process...... 31 13.1 The CBR-cycle...... 31 13.2 Matching a case...... 32 14 Summary...... 37 15 Advanced topics...... 37 15.1 Inherits over/transfers...... 37 16 References...... 40 17 Appendices...... 41 17.1 Appendix A: Relation types for the car model domain...... 41 17.2 Appendix B: Entities for the car model domain...... 42 17.3 Appendix C: Causal model...... 44 17.4 Appendix D: Cases...... 45
2 1 Introduction
The goal of this tutorial is to show you how to build a knowledge model in TrollCreek. To achieve this goal you will build a model concerning car problems (car starting or not). We will explain in a stepwise fashion how to do the different tasks needed to build this model, and we will also explain a number of important concepts that you must be aware of when modelling in TrollCreek. After having completed this tutorial you will be able to start exploring TrollCreek on your own.
A note on symbol use: In the following the symbol ‘→’ indicates that you should do something to the model before moving on.
2 What is TrollCreek?
TrollCreek is a knowledge model editor for the Java-version of the Case-Based Reasoning system CREEK.
What is a CBR-system? A very general description would be that it is a system that solves problems based on previous experiences. Here is a quick example: Let us say we wanted to build a CBR-system that diagnoses patients. We would then provide the system with numerous patient histories with diagnoses:
Patient #45 age 37 symptom low blood pressure symptom dizziness . . diagnosis diabetes
The collection of all these patient histories with diagnoses is called the case-base of the system, and each individual patient history is called a case. The case in turn consists of features (age, symptoms and diagnosis in the example above). When the system is asked to diagnose a new patient it is given a new patient history, but with the diagnosis missing. The system then compares the input patient history with all the cases in its case-base, and if it finds a case in the case-base that is sufficiently similar to the input, it returns the best matching case. The diagnosis of this case is then presented as a possible diagnosis of the input problem.
How is an input problem matched with a case in the case-base? There are many ways in which this can be done. A particularly easy way is to syntactically match the symptoms of the input case with the symptoms in each case in the case-base. This means that features that are identical match; low blood pressure in the input case matches low blood pressure in a case in the case-base, and so on.
TrollCreek also has a more sophisticated matching mechanism. To illustrate this we will first point out a problem with the mentioned syntactical match approach, and then show how TrollCreek handles this problem.
Let us say that one of the cases in the case-base of our medical example has the symptom dizziness, and the input problem has the symptom low blood pressure. These do not match syntactically. However, if a physician were to compare the two cases, he might know that low blood pressure can cause dizziness, and he would then see some similarity between the cases, whereas a naive CBR-system using only syntactical matching would not. A naive CBR- system does not have this kind of background knowledge about causes and effects that a physician has. We say that the naive CBR-system has shallow knowledge, since it only tries to match words and has no idea of the meaning of these words. The physician on the other hand has deep knowledge. He does not rely on word matching, but knows what causes what. TrollCreek gives the user the ability to specify this kind of deep knowledge. This means that it is able to reason more intelligently when comparing old cases to new problems.
Putting all of the above together, we now have a picture of what TrollCreek is: A knowledge editor and testing environment for a CBR-system that has the ability to reason intelligently. It can be used to solve problems within a wide
3 range of domains: solving car problems, performing medical diagnosis, assisting in oil well drilling, advising in financial matters, preparing cooking recipes, predicting the weather, etc. The list just goes on and on. As long as we can come up with a case-and knowledge structure for the problem domain at hand we can use TrollCreek.
We are now ready to go into details about how we should approach a problem domain where we want to use TrollCreek.
3 How to model in TrollCreek
Before we start using TrollCreek to reason about cases, we need to give the system the knowledge to do so. The resulting structure we have after entering all the knowledge is called a knowledge model.
Although there are many different approaches to building a knowledge model, we will suggest a process we have found to be useful in TrollCreek. It involves three steps that we must go through before the system is ready for use:
Making a taxonomy: Here we extract important terms from the domain we are modelling and enter them into the system.
Building a causal model: Here we build a model that describes causes and effects.
Adding cases: Here we add the cases, in other words concrete, previous experiences in solving the problem we would like the system to deal with.
How does this apply to the car domain we are going to model? We assume that we already have a collection of cases and domain knowledge, be it in the minds of experts, on paper or in the form of electronic documentation. Using this, the first task is to extract the terms we need to describe the cases and domain knowledge.
Although describing the actual cases is last on our list of tasks, it is often useful to start by putting down a few cases on paper. This will help us identify the terms we need in order to describe a problem in our particular domain and to identify the scope of the system. In this tutorial, we have chosen a car domain, and in particular we would like our system to help diagnose why a car will not start. This means that all our cases will be many different situations where some car refuses to start, although the reasons for this may be different. Finding the reason it why it does not start is what we would like the system to do.
In TrollCreek, a case is described by a name (for instance “Case#3” although it can be anything) and a list of features. The features represent individual, relevant facts that are known about the problem situation. Related to the term feature is the term finding. A finding is a special kind of feature which describes some observed feature of the case. For instance the symptoms in the case lined out above are findings, whereas the solution is not a finding, but it is a feature nonetheless.
A feature consists of two things, a feature type and a feature value. Let us look at a finding to illustrate this: I remember a time when my car did not start because the battery was flat. To represent this as a finding, we can define has battery status as a finding type and flat battery as a finding value. After identifying a few more facts we remember from this situation, the case may look something like this:
Case #1 Type Value has engine status engine does not fire findings has fuel status gas tank full features has battery status flat battery has solution flat battery
Here we have already defined seven terms, the finding types (e.g. has engine status) and the finding values (e.g. gas tank full) that we should include in our taxonomy. We can also see the need for defining other types of feature values, e.g. OK battery and gas tank empty. These terms can then be arranged in groups or in a tree-like structure so that the terms describing the fuel system is separate from the terms describing the electrical system.
We did not include it in our outline of the modelling approach above, but it may be purposeful to make other hierarchies at this stage too, that do not go under the term taxonomy, for instance compositional hierarchies, such as:
4 fuel system -(has part)-> fuel pump fuel pump –(is of type)-> “Acme fuel pump”
Such hierarchies are important in engineering domains.
The second step is building a causal model from the terms we have identified. A simple causal relationship for the terms we have identified so far could be that the car did not start because the battery was flat. In our knowledge model we could represent this as: flat battery –(causes) engine does not fire
At this point, we have defined the vocabulary that will allow us to actually enter the case above into the system. We can now enter more cases, possibly identifying new terms that must be included in the taxonomy and the causal model, until we feel the system knows enough about the domain to be able to solve unsolved cases.
Figure 1 is taken from TrollCreek and illustrates how the knowledge described above can be represented inside TrollCreek. All the terms from the example are included, and the meaning of the figure is intuitive. If you have knowledge of semantic networks, this way of representing knowledge should look familiar.
Figure 1. Example of car problem case represented in TrollCreek
You may have noticed that there is some overlap between the three steps involved in our knowledge modelling process. We need to look at our cases in order to find the terms we need to describe them, and then include these terms in our taxonomy. So the taxonomy is to some degree dependent on the cases. Also note that knowledge modelling is an incremental process. In real life we would continue to add to our knowledge model after the initial phase was finished: We would add new cases, both solved and unsolved, and this would probably lead to a need to expand our taxonomy. There would probably be a need to refine and revise the knowledge model too. Maybe we will discover a better way to model something and want to change the model accordingly.
Since the point of this tutorial is to show you how to use TrollCreek, and not about the intricacies involved in knowledge modelling nor about CBR-systems in general, we will not say too much about why things are modelled as they are. If you want more information about these subjects you might find the following references useful [1], [2]. In fact, the process of extracting knowledge from the car domain has already been done for you, and the results are found in the appendices. You just have to enter this knowledge into the system.
After this general introduction to knowledge modelling in TrollCreek we are now ready to get into the practicalities.
5 4 Creating a new model
First of all we have to create a new knowledge model file:
1. Select New Knowledge Model from the File menu. 2. The Knowledge Model Properties dialog box is now displayed (in Figure 2).
Figure 2. Knowledge model properties
3. Note that the .km ending used to identify TrollCreek model files is not added automatically, so you need to add this manually. Click Ok after you have filled in all the fields.
In case that you do not want to finish this tutorial in one sitting, save the knowledge model by selecting Save KnowledgeModel from the File-menu before you quit, so that you will be able to start where you left off.
You have now created a new knowledge model and are ready to input some knowledge. A window named View 0 has appeared. This is called a map view. Map views are used for manipulating and visualizing the contents of our knowledge model.
6 Figure 3. TrollCreek and all its entities after creating a new knowledge model
Click on the Entity List tab on the far right of the screen. A list containing everything that is in the knowledge model appears, and the screen should resemble that in Figure 3. As you can see there is already quite a bit of content in the model before you have added anything yourself. This is used by the system, and we will explain what it does as we go along.
5 Views
Views play an important role in TrollCreek. We will introduce the three types to give you an overview. Do not worry if you do not understand everything in this section, we will go into more details about the views later. The three types of views are Map Views, Frame Views and Case Views. The views allow you to visualize and manipulate the content of your knowledge model in different ways. When we start entering knowledge we will do this by using the views.
There is some overlap in the functionality of the different views. This means that you for several tasks can choose which view to use based on which you find the easiest to use.
Map Views You already have a map view open (View 0). Map views let you visualize the knowledge model as a graph-structure with nodes and links between them, like nouns and verbs. You manipulate the contents of the knowledge model by adding new nodes, deleting nodes and connecting them with links. The little example in Figure 1 is taken from a map view. New map views are created by pressing New Map View, , on the toolbar.
There is a tab on the sidebar on the right that says View List. If you click on this you will see a list of all the map views that you have open. If you right-click on a map view in this list a popup-menu is displayed. From here you can amongst other things rename and delete.
7 Double-clicking on an entry in the Entity List while a map view is active brings up a node representing the entry you clicked on in the map view. Try doing this now; just double-click on an entry of your own choice. A node representing this entry appears in the map view. You can right-click on the node to bring up a popup-menu. After you have done this click on the node in the map view to select it and then press Erase Entity, , from the toolbar. If you select a node and press this button you remove it from the current map view, but notice that it is still in the Entity List.
It is important to keep in mind that map views only visualize what is already in the knowledge model. Entities do not have to be in a map view in order to be in the knowledge model. Remember that when we opened the Entity List right after we created the knowledge model file there were many entries, but none of them were drawn up in a map view.
Frame Views If you select a node in a map view and click on Current Frame View on the sidebar on the right, it changes to what is called a Frame View. The Frame View has a structure like that shown in Figure 4 and Figure 6. Sometimes it is useful to have all the information regarding a node in one place, and that is when frame views are handy.
You can also open a Frame View by right-clicking on a node in a map view and selecting Open Frame View from the popup-menu. This will bring up the Frame View as a separate window.
From this you will notice that you actually need to have a node displayed in a map view in order to open its Frame View.
Case Views An example of a Case View is shown in Figure 19. You open a Case View by right-clicking on a node in a map view and selecting Open Case View. This only works for nodes that represent cases.
Case Views look somewhat like Frame Views. They let you view all the information for a given case in one place, and they provide a more intuitive way to manipulate cases than Frame Views does.
We are now going to make use of these views to enter knowledge into our model. We will add what is called entities to our model and then connect them with links (relationships) of different kinds.
6 Adding entities and connecting them with relationsships
What is an entity? It is something that has separate and distinct existence and objective or conceptual reality. To make things a little more concrete: It can be an object in the real world (i.e. a car) or it can be something that just has conceptual reality (i.e. the number seven). The nodes in Figure 1 are examples of entities. Generally in map views, entities are the nodes in the graph. We can use entities to represent almost everything.
Where do we begin? Let us look at the example from the section “How to model in TrollCreek” and enter some terms from it into TrollCreek.
→ First we will create a node (entity) called flat battery: 1. If it is not already activated, click on the Build Tool, , on the toolbar. 2. Click anywhere on a blank space in the map view (View 0). A new node named New Entity pops up, and the sidebar on the right also changes (Figure 4).
8 Figure 4. Creating the flat battery entity
3. Fill in flat battery in the Name-field. 4. Press tab. The new name for the entity has been updated in the knowledge model, but not in our map view. To update the map view hold down the Ctrl-button and click in the map view.
The reason why you held down the Ctrl-button under step 4, is that if you clicked in a map view without pressing it you would create yet another new entity, which we do not need at this time. Do not worry if you accidentally create some unwanted entities. They are easy to delete, just select the entity in the map view and press Delete Entity, , on the toolbar to delete it from the knowledge model.
Note that you only create new entities by clicking in a map view when the Build Tool is active. If you activate the Select
Tool, , you can safely click anywhere without creating anything.
From now on when you are asked to create an entity, just follow steps 1-4 in the above example.
We have several other terms in our example from section on how to model, but we will leave them alone for now and think more about flat battery. A battery can of course have other states than being flat, and it makes good sense to include terms for these other states in our model. We will in fact do just that:
→ Create two nodes called weak battery and battery ok.
We will include terms for other engine states, fuel states and so on in our model, so that we are able to describe many cases right from the start. Remember that we said that knowledge modelling was an incremental approach, and it is important to keep in mind that we can continue to add things to our model after the initial modelling phase.
As we put more and more entities into our model there is an increasing pressure to put some kind of structure on them. Our model will be very untidy if we just add entities and do not organize them in some way, and we will not be able to exploit the inheritance-mechanism (see section 7 for more).
The three terms in our model so far; battery ok, weak battery and flat battery are all examples of battery states, let us make this explicit in our model:
→ Create a node called battery state.
Now to specify that they are examples of battery states:
9 → Click on the Building Relation-drop-down list in the Tool Window (the Build Tool must be active). Scroll down the list until you find the entry has instance and click on it as has been done in Figure 5. Click and hold the mouse button on the battery state-node in the map view. Now drag the pointer over to the battery ok-node and release the button. A link between the nodes is displayed. Do the same for the weak battery-node, but wait with the flat battery-node. We will create a link to this node by using an alternative approach.
Figure 5. Tool Window when preparing for building relation between entities
→ Click on the battery state-entity. If it is not already activated, click on Current Frame View on the sidebar. It should look like in Figure 6.
Figure 6. Creating a has instance link to the flat battery node
→ Select has instance from the
10 An alternative approach to display relationships is the following: Right-click on a node in a map view and select Relations, and then on the relation type that you want to display.
There is no difference if you choose to add relationships by drawing lines in a map view or by entering information via the sidebar. You actually have two more methods to add relationships: By right-clicking on a node in a map view and selecting Open Frame View. You will then open a dialog box that is identical to the sidebar in Figure 6. By clicking on a node in a map view and then selecting New Relation from the Model-menu.
Notice the thrash can symbols on the right in Figure 6. Double-clicking on these deletes the relationship. The Build Tool has to be active for this to work.
The situation should now resemble the one displayed in Figure 7. You might not have a label on the links between the nodes. Do the following to label the links: Select Preferences from the Option-menu. Check the box next to the Show Relation Name, and click Ok. Press Ctrl and simultaneously click anywhere in the map view to update it. Now all the links displayed in map views will be labelled.
Figure 7. Resulting structure after having built three reltionships
We will not only have battery state in our model, but also engine state, fuel system state and so on. In larger domains we would also sub classify state into e.g. alarm state, ok state, failure state etc. Only those entities subjected to failures need to be state evaluated. It makes good knowledge modelling sense to have a node that ties all of these states together. We have actually begun building a hierarchy of entities using has subclass and has instance-relation types, which will be our taxonomy. What is the point of organizing the taxonomy in this way? To understand that we must explain the concept of inheritance.
7 Inheritance with has subclass/has instance
The point of this section is to describe the inheritance-mechanism. We will not add anything to our model, so if you already know how the inheritance mechanism works you can jump to the next section.
11 Inheritance makes it possible to generalize/specialize. The has subclass-relation type specifies a specialization. As an example: vehicle –(has subclass)-> car
The has subclass-relation causes all the attributes of the parent to be inherited by the child node. This inheriting mechanism is reminiscent of those used in object oriented programming. Extending our vehicle/car example a bit:
Figure 8. Inheritance example
The attributes has wheels yes and function transportation are inherited by car in this case. The attributes of vehicle are of course inherited by any descendants of car, so more and more attributes are normally accumulated as you follow has subclass-relationships.
If there is some property that all our battery states have in common then we can specify this at the battery state-node. This attribute will then be inherited by all entities that the battery state-node has has subclass or has instance relationships to.
It is also important to note that when we create a relation in TrollCreek an inverse relation is also created. If vehicle has a has subclass relation to car, then car has a subclass of relation to vehicle. In fact, when we connected battery state and battery ok it would make no difference if we drew a has instance-relation type from battery state to battery ok, or if we drew a instance of-relation type from battery ok to battery state, since the inverse is created automatically.
How do we know which relation types that are inverses of each other? To find this out you have to place the relation type in a map view and open its Frame View. If you look at the list of relationships for the node you will see one named has inverse (look at Figure 9). The value of this relation type tells which one is the inverse. There is also an alternative way of doing this, you can right-click on the relation type-node in a map view and select Relations has inverse from the popup-menu. You see that relation types can also be represented as nodes in a map view. You can find all the relation types that you find in the Building Relation-list of the Tool Window in the Entity List. So you just double-click on them in the list to bring them up in a map view just as with the entities.
12 Figure 9. Frame view of the has instance relation type
So far we have only mentioned the has subclass-relation type, so where does the has instance-relation type come in? An instance is an individual example of a class. Here are some examples that illustrate the difference between has subclass and has instance: wine –(has subclass)-> red wine –(has instance)-> Margaux vehicle –(has subclass)-> car –(has subclass)-> sportscar –(has instance) my car colour –(has instance)-> red
There are situations where the relationship between subclasses and instances are not so clear, but a discussion is not within the scope of this tutorial. In fact, TrollCreek does not separate has subclass and has instance in the reasoning process, it treats the two relation types in the same way.
To summarize: The has subclass/has instance (and their inverses) relation types are special. They cause the attributes of the entities they emerge from to be inherited by the entities they point to. Other relation types do not to this (has part, causes and so on).
8 Building the hierarchy of entities
From the previous section we now see that an important point of building a hierarchy of entities is to exploit the inheritance mechanism.
8.1 The existing hierarchy
It cannot be seen from the Entity List, but the entities in the knowledge model are already organized in a hierarchy, with Entity at the top. Figure 10 shows the top level of this hierarchy.
13 Figure 10. Top level entities
When you create new entities they should be made part of this hierarchy, so that the system knows that they are entities. Most of the entities we add to our model will be placed somewhere under the Symbol-node. Generally if the entity you are planning to add is not a case or a number, it should be placed somewhere under the Symbol-node. Explain why this in necessary. Isn’t there a more logical name than symbol, like for instance real entity?
Our cases will be placed somewhere under the Case-node, but we do not have to worry about placing them there since this is done automatically for us when we get around to entering them into the system.
8.2 Placing our entities in the existing hierarchy
It is now time to extend our example with the battery state, and connect the nodes to the hierarchy that already exists in the knowledge model.
→ Create nodes called state and domain object. We will use the state-node as a parent node to all the different types of states (battery state, engine state and so on), and the domain object-node will be the topmost node of all the terms we define.
→ Connect the battery state-node to the state-node using a subclass of-relation type, and connect the state-node to the domain object-node also using a subclass of-relation type.
→ Now open the Entity List and find the entry named Symbol. Double-click on it to bring it into the map view. Connect the domain object-node to the Symbol-node using a subclass of-relation type etc, as shown in Figure 11.
14 Figure 11. Extended battery states structure
The Symbol-node already has a relationship. If you click on it you see that it has the following relationship: has comparator class jcreek.reasoning.SymbolComparison. If you click on any of the other nodes in the map view you will see in their Frame View that they have inherited this relationship. As an example the frame view for battery ok is displayed in Figure 12.
As mentioned above, modelling is a topic by itself called ontology engineering. State for instance may alternatively be sub classified into different types of states. To relate battery to state we would then need a relation called has state, i.e. battery has state equipment error state or ok state (etc, depending on the state of the battery).
Figure 12. Example of an inherited relationship
15 Inherited relationships have a grey shade. If you click on Local Only, only those relationships that have been explicitly defined for this entity are displayed. If you double-click in the Value-column of an inherited relationship while the Select Tool is active a screen explaining where this relationship is inherited from will appear. Try doing this with one of the battery states nodes to see how it works.
You cannot directly delete relations that are inherited, but you can prevent them from being inherited further down the hierarchy. This is done by setting the value in the Strength-field for the relationship that you want to prevent from being inherited further to 0, or by clicking on the trash can symbol to the right of the relationship in the Frame View. A relationship of strength 0 is an explicit representation that this particular relationship do not exist, and it will not be used in the reasoning process.
8.3 User exercise: Adding the entities
Now that you have learnt the basics of creating entities and connecting them with relationships, it is time to enter all of the terms that we are going to use in TrollCreek.
→ Enter all entities in appendix B.
The terms are listed on the following form:
Entity Relation Relation to state subclass of domain object
The example above means that you should connect state-entity to the domain object-entity using a subclass of-relation type, or alternatively: Connect the domain object-node to the state-node using a has subclass-relation type. You remember that we said that this makes no difference since the inverse relationship is created automatically? If you have followed the tutorial up this point you have already created the state-node and connected it. You have also entered some of the other entities, but they are listed in the appendix to make it complete.
Remember that you add entities by clicking in a map view when the Build Tool is active, and then changing the name and adding the relations in the sidebar on the right or by drawing lines in the map view.
The final taxonomy should resemble that in Figure 13. Only two of the nodes existed in the knowledge model in advance: Symbol and Case.
16 Figure 13. Final taxonomy
8.4 How to build a taxonomy
What are the reasons for making our taxonomy the way we did? Are there other ways that we could have organized the entities? Yes, there are. For instance we could have dropped the state-node and let all the different “states”-nodes be direct descendents of the domain object-node. There are many possibilities as exemplified above. In any case the structure of the taxonomy needs to reflect how we are planning to use inheritance. The art of how organize entities comes under what is called ontology building, and the following reference have some pointers to how one should proceed [4].
9 Entities and relationships in the reasoning process
The process of creating new entities and connecting them with different relation types is basically what knowledge modelling in TrollCreek is all about. We create a net of entities and relationships that capture the knowledge we enter into the system. When all the knowledge is in a place, TrollCreek will be able to reason by following the links/relationships in this network. Figure 14 contains an example that illustrates how this network can be used:
17 Figure 14. Part of the car knowledge model
The figure is a bit cluttered, but we will just have to try to make it out. Actually, the picture is more complex than shown here. The model this was taken from has many more relationships and entities that are relevant for the problem at hand, but we will settle with this partial view of the knowledge model to keep things simple.
We shall look at Case 4 in Figure 14 and show how we can reason about a possible solution using the network. As you can see Case 4 is marked as unsolved (it has a link to the Unsolved Case-node). What do we know about Case 4? The car is red, the engine does not fire, the starter motor does not turn and the fuel system is OK. Where can we go from here? The system has three solved cases that have the same engine status. It is natural to look at these cases more closely to see if there are more similarities between them than just that the engine does not fire.
We see that Case 2 and Case 4 both have the colour red. We know that when cases share findings they are similar. However, that both are red do not help us when we are trying to figure out why the engine does not fire. So the cases should not be regarded as similar based on this finding alone.
Case 1 has the solution flat battery. We see that a flat battery always causes the starter motor not to turn, and in fact the starter motor of Case 4 does not turn. We do not know the battery status of Case 4, so there is a possibility that the engine does not fire because the battery is flat, making this case similar to Case 1. At this point the system could suggest this to the user. If indeed that battery turned out to be flat we would have solved Case 4 and marked it as solved. If the battery turned out to be OK we would enter this into the system and start the reasoning process again.
The algorithms TrollCreek uses for reasoning do not proceed in exactly the same way as we reasoned in the above example. However, the underlying principle is the same: The network of entities and relationships are used as a data structure for the reasoning task.
So far we have only used has subclass and has instance when making relationships, but as you can see from the Building Relation-list and the example above there are many different relation types. Causal relations (causes,
18 occasionally causes and so on) have an important role in reasoning. Structural relations (i.e. has subclass, has instance and so on) play an important role in our taxonomy. TrollCreek recognizes that the different types need to be treated differently, and this is a topic we will discuss in the next section.
One thing that might strike you with the model we used in the example is that many of the relation types (has engine status, has colour and so on) do not exist in our model. We will have to add these on our own.
10 Adding new relation types
As with entities you can also add new relation types of your own.
10.1 Steps involved in creating a new relation type
→ Do the following to create a new relation type:
1. Click on New Relation Type, , on the toolbar. 2. The New Domain Relation dialog box as shown in Figure 15 is now displayed
Figure 15. New Domain Relation
3. Fill in the fields as indicated and click Ok.
That is all, you have just created a new relation type called has engine status. Actually you have created two new relation types, since the inverse, engine status of, is also created.
10.2Explanation of the different fields in the New Domain Relation-dialogue
We now turn to the meaning of the fields.
Class Name This is the name of the relation type.
19 Class Inverse Name As mentioned each relation type in TrollCreek has an inverse. When you use the New Domain Relation-dialog box this relationship is automatically created, and you specify its name in this field.
Relation We turn to the Relation-field before Explanation Strength since we need to explain some things related to this before we are ready to tackle explanation strength.
The Relation-field sets which relation type that should be the parent of the one we are creating. The relation types are organized in a hierarchy, just as the entities are, with Relation at the absolute top. The immediate subclasses of Relation are displayed in Figure 16.
Figure 16. Top level relation types
It is important that new relation types are placed somewhere under the Relation-node so that the system knows that they actually are relation types. We do not have to worry about this if we use the New Domain Relation-dialog box to create new relation types, since only existing relation types are displayed in the Relation-drop down list. So we are certain that the new types will be placed somewhere under the Relation-node. However, we need to worry a bit about where in the hierarchy under the Relation-node to place a new relation type. Here is a summary of what should be placed where:
has finding: All relation types that are used to indicate findings or observations in cases have to be located somewhere below the has finding-node. The has engine status-relation type we created earlier is a subclass of this relation type, since it is a specific type of finding. Note that we now could define even more specific types of findings as subclasses to has engine finding, for example has cylinder status.
Causal Relation: From the start this relation type has two subclasses: causes and implies. Here is where the relation types describing cause and effect should be placed. The causal relations also play a special role in case matching, and we will have more to say about them later.
Structural Relation: Relations that structure knowledge into taxonomical and other types of hierarchies should be placed here. For instance is the has subclass a structural relation.
You should not place relation types under the other nodes, unless you really know what you are doing, and in that case you probably do not need to read this tutorial.
If you feel you need to, you could also place new relation types directly under the Relation-node. If you do, then these relation types will not be used by the system in any way.
20 10.3 Explanation Strength
This is an important concept in TrollCreek. Every relationship has a strength associated with it, and how this strength is interpreted is dependent on the type of relation.
Let us look at a causal relation from the car domain first: flat battery –(always causes)-> no lights weak battery –(might cause)-> no lights
The strength can take on any value in the interval [0,1]. In this case 1.0 means that B always follows from A, and 0.0 means that B never follows from A. Let us say that we have defined the explanation strength of the relation type might cause to be 0.5 and always causes to be 0.9. This makes intuitive sense. If the battery is flat the lights will not function, however if the battery only is weak there is some chance that the lights will function. We have modelled this knowledge by using the might cause relation, which has a lower explanation strength then the always causes relation, for the weak battery/no lights situation.
The notion of explanation strength makes intuitive sense when we are talking about causes and effects, but remember that all relation types have a strength associated with them, so what should we make of the explanation strength in the following example? car –(has subclass)-> sports car
In this case the explanation strength could be seen as measure of how similar a sports car is to our definition of a prototypical car.
Another interpretation of explanation strength arises with the has finding-relation types:
Case #15 –(has engine status)--> engine ok engine ok –(is engine status of)--> Case #15
So far we have implicitly assumed that the explanation strengths of relations and their inverses have been the same, but they do not actually have to be, and this comes out very clear in the has finding-relation types. In fact, we have names for the explanation strengths in the different directions for has finding-relation types. The explanation strength of has engine status is called predictive strength, and for engine status of it is also called predictive strength. We will come back to what these values mean in the section “Steps involved in adding a case.”
To summarize: The use of the explanation strength depends on the relation type and the context. There are four major contexts from which explanation strength can be seen in TrollCreek (the following list is taken from [3]):
1. Inferring of consequences: What are the consequences of A? 2. Matching of concepts: Is A like (in this context similar to) B? 3. Assessing a value: Is A a reasonable (plausible) value for B? 4. Assessing of support: Does the existence of A justify or support B?
That you specify an explanation strength in this field does not mean that the relation type always needs to have this strength. You can change the individual explanation strengths of relationships. If you look back at Figure 6 you see there is a column showing the explanation strengths of the relationships. If you change these values you change the explanation strengths of the given relationship. The Build Tool has to be active for this to work. In any case you should avoid setting the explanation strength to 1.0, since this can have unfortunate consequences for the reasoning mechanism (but 0.99 is ok).
From all that is written about explanation strength, it probably seems like a daunting task to set the right values for the different relation types, so here are some words of comfort: We will focus on explanation strength for causal and has finding relation types. The interpretation of explanation strength for other relation types is not within the scope of this tutorial. What are the right values? A bit of common sense is needed in selecting values, and there are probably several different sets of values that can be considered “correct.”
21 10.4Why create new relation types?
Why do we want to create new relation types? In our car model we will create a number of causal relation types, because it is convenient to have some types with different explanation strengths to choose from when we build our causal model. We will also create a number of has finding-relation types. Why do we create these? For one thing, our model will be easier to read. We also exploit the fact that we can set default explanation strengths for relation types, something which makes it easier to model afterwards (we do not have to tweak the explanations strengths of individual relationships).
10.5 User exercise: Adding the relation types
→ Add all the relation types in appendix A.
The relation types are listed on the form:
Class Name Class Inverse Name Explanation Strength Relation has engine status is engine status of 0.5 has finding
You should use the New Domain Relation-dialog box when adding the relation types. The above example corresponds to that in . As with the entities all of them are listed in the appendix, which means that if you have followed the tutorial up to this point you have already entered has engine status into the system. Entries for the Description-field are not provided, but there needs to be something in that field too. You could for instance put a sentence describing what the relation type is used for in that field.
11 Building the network of domain knowledge
Now that we have created the entities and relation types we need, we turn to the causal model. As previously mentioned a causal model describes causes and effects. We do not introduce any new concepts in this section, so it can be regarded as a user exercise.
→ First create a map view that will visualize our causal model: 1. Open a new map view. 2. Click on View List on the sidebar on the right. 3. Right-click on the name of the new map view in the list. Select Rename Map View and enter Causal model.
→ Now for the first causal relation: 1. Open the Entity List. 2. Double-click on flat battery and no lights to bring them into the map view. 3. Activate the Build Tool. Select always causes from the Building Relation-list in the Tool Window. 4. Connect flat battery and no lights with a always causes relation type.
The situation should look like that in Figure 17.
22 Figure 17. First causal relationship
→ Build the causal model as indicated in appendix C.
This is the way you will build the causal model. Entities are brought into the map view and connected with different causal links, like shown in Figure 18.
Figure 18. Final causal model
23 12 Adding cases
The only thing missing in our model before we start comparing cases, are the cases themselves. We will add a collection of cases with solved and unsolved status.
12.1 What should a case contain?
Solved cases should of course contain a solution, but what else should cases in general contain? Features that are relevant for the solution. In our model we have in fact included the colour of some of the cars as findings. This is of course not relevant for the solution of the problem, since regardless of the colour the car will start. We have included the colours to illustrate a point: We can specify that these findings are unimportant for the case at hand. Why is this important? Because the relevance of the findings depends on what problem we are trying to solve. The colour of the car is not important when trying to figure out why the car will not start, but it would be important when buying a car. So if our system instead of only dealing with car starting problems could also tell me if a car was a potential buy (based on the cars that I have previously owned), then colour would be important for this category of problems, but not for the other.
Apart from findings the case could also contain the outcome of the solution (how well did it work?), what lessons were learned from the case and so on. Figuring out what is necessary to include in a case is not always easy, and there exists much literature on the subject.
12.2 Steps involved in adding a case
→ Open a new map view so that we will have easy access to our cases. Rename this map view to Cases. We will add a case where we already know the solution:
1. Activate the Build Tool. 2. Click anywhere in a map view to create a new entity 3. Select Model->New Case from the menu. 4. A window resembling that in Figure 19 should appear. Note that you will not see any findings yet. When you have entered all of them, then the window should look like that in the figure.
24 Figure 19. Adding the first case
→ Enter the following:
Name: Case 1 Case type: car starting case Status: solved Has solution: flat battery
Relation Value Importance Predictive Strength has engine status engine does not fire Characteristic Indicative has other finding no lights Informative Strongly indicative has electrical system electrical system ok Informative Indicative status has battery status flat battery Informative Sufficient has air filter status air filter ok Informative Indicative has fuel status gas in gas tank Informative Indicative
Use the
→ Close the window by pressing the X in the top right corner. The case does not appear in the map view automatically. You have to find it in the Entity List and double-click on it to bring it into the Cases-map view. To open the case view later select Open Case View from the pop-up menu that is displayed when you right-click on a case-node in the map view.
25 12.3 Explanation of the fields in the Case View
Name and description This is pretty self-explanatory. Name is what the case will be called. In our model we only use Case 1, 2, 3… But there is nothing that hinders us from using other names. The Description-field is meant to contain a textual description of the case, and any other information that is deemed important.
Case status From the drop down list you can select:
_solved case: This marks the case as solved.
_processed case: This means that the user or the system has suggested a solution of the case, but it is not certain that the solution works. When the solution is confirmed by the user, the status should be changed to solved. On the other hand; if the user turns down the solution, the status should be changed to unsolved.
_unsolved case: This means that the case is unsolved.
Case Type The cases are indexed by their type. We only have one category of cases; car starting problems. If we had had a more ambitious model in mind we could have included categories for brake problems, gear problems and so on.
Solution This sets the solution for the case. In our domain the solution will be the entity that describes the causes of all the problems.
Findings Here the different findings are added, and for each finding two values called importance and predictive strength are set.
12.4Importance and predictive strength of solved cases
The importance of a finding indicates how important the existence of the finding is for the solution of a particular case. An example will illustrate what this means: Consider the situation in Figure 20. We have a case-base with four cases. Case 1 and Case 3 have flat battery as the solution, and Case 2 and Case 4 have empty gas tank as the solution. All the cases have the finding engine does not fire, and Case 1 also has the finding no lights.
26 Figure 20. Importance and predictive strength
Let us consider the solution flat battery. All the cases where flat battery is the solution has the finding engine does not fire. We then say that this finding is important for the solution, since we have no cases which have the solution flat battery but do not have this finding.
However, given the finding engine does not fire we cannot readily predict which solution is the right one, since all the cases in our case-base have this finding. We say the finding has low predictive strength. Predictive strength indicates how important a finding is when predicting a problem solution.
Consider the solution flat battery again. Only Case 1 has the finding no lights. This means that given the finding no lights, we have a strong indication that flat battery may be the solution. In Case 3 which has the same solution, this finding is missing. Maybe the lights were not checked in this case. This affects the importance, leading to the finding no lights not being so important for the solution flat battery, since not all the cases that have this solution also have this finding.
You can set importance to one of the following values: Necessary Characteristic informative and irrelevant
Where necessary indicates the finding is of the highest importance for belonging to the given category, and irrelevant indicates the finding is not important. The predictive strength can be set to one of these values:
Sufficient strongly-indicative indicative and spurious
Sufficient indicates the strongest predictive strength, and spurious the weakest.
27 You might remember from the section Adding new relation types, that we said importance and predictive strength actually are explanation strengths of has finding-relation types. To go along with our example: The relationship Case 1 – (has engine status)-> engine does not fire will have a high explanation strength, since this is the importance of the finding. The inverse relationship engine does not fire –(is engine status of)-> Case 1 corresponds to the prediction strength, and this will have a low value in this case.
The values you can select for importance and predictive strength are numeric constants. I.e. the value sufficient for predictive strength sets the explanation strength to some predefined numerical value. However, you can set the explanation strength of relationships to any value between [0, 1], so you are not bound to use the values defined by the constants sufficient, strongly-indicative and so on.
Note that predictive strength and importance only are set for cases that are solved. When you have an unsolved case you naturally do not have the solution, so it is not possible to set values for importance and predictive strength.
12.5 User exercise: Adding the cases
→ Add all the cases in appendix D.
Now that you have learnt how to add a case and what all the fields mean, we are ready to add the rest of the cases. If you have followed the tutorial up this point you have already entered Case 1 into the system. Just follow the procedure given in section “Steps involved in adding a case” when entering the other cases.
Bring the cases into the Cases-map view after you have added them.
13 The case matching process
Our initial knowledge model is now complete. The next step is seeing how TrollCreek tries to provide a solution for unsolved cases.
13.1 The CBR-cycle
To get a clear picture of how TrollCreek reasons we need to introduce the CBR-cycle, which is illustrated in Figure 21 (taken from [2], which also is a good place to learn more about the CBR-cycle).
28 Figure 21. The CBR-cycle
Let us take a quick tour of the cycle: First a new unsolved case is presented to the system. In the Retrieve-process the most similar case or cases are retrieved from the case-base. In Reuse the system tries to reuse the solutions that are the output from the Retrieve-process to the problem at hand. The output from this process is an attempt to solve the case by using the solution of the best matching case. If the solution is wrong the Revise-process tries to fix the solution. Finally the Retain-process decides what to retain from the case just processed.
The cycle gives us a framework for describing the CBR-system by introducing four major processes. At this point TrollCreek implements three of the processes, namely Retrieve, Reuse and Retain, hence we will only focus on them.
13.2 Matching a case
Right-click on Case 4 in the Cases-map view and select Match Case. A screen resembling that in Figure 22 should appear. Click on Case 3 near the bottom. We will use the comparison between Case 4 and Case 3 as an example in the following.
This screen actually represents the output of the Retrieve-process in the CBR-cycle. You will notice that there are two tabs on the screen, and that the one marked Retrieve is activated.
Retrieve-tab In the Retrieve-process the input case is compared with all the solved cases in the case-base, and a measure of the similarity is computed. Figure 22 illustrates the part of the knowledge network that has been activated in the similarity computation.
29 Figure 22. Resulting case matching after pressing the Retrieve-tab
Matching features The top line on the Retrieve-tab lists the names of the two cases that are compared and a percentage that shows their overall similarity. This similarity measure is calculated based on the findings, which are grouped into three different categories:
Directly matched features: If two findings of a case point to the same entity, it is a direct match.
Partially matched features: Here TrollCreek has found a route between two findings in the cases compared by following causal relations (which we have visualized in our causal model). Note that a route may extend over several intermediate entities before it reaches a finding of the other case.
Unmatched features: The system did not find any links from these findings to any of those in the other case.
The bottom line gives an overview which cases in the case base are most similar to the target case. You can click on a case to bring up the details. As you can see each case is represented by a bar that shows how similar they are to the target case. The blue part of the bar shows the strength of the direct matched features in the overall similarity, while the red part shows the strength of the partly matched features in the overall similarity. Only the ten most similar cases are displayed.
30 Matching Strength The matching strength tells us of how well two findings match. Direct matched features have highest matching strength (100%), since the findings are the same in the two cases. Unmatched features have the lowest matching strength (0%), since there is no way of finding a path between these findings.
Partially matched features have a matching strength that lies in the interval from 1% to 99%. If you select a partially matched feature and then click on Details (in the lower right part of the screen) you will see a graph showing the path between the two findings and get a textual explanation of the match.
What determines the matching strength between two findings? Without going into details regarding the calculations, the matching strength is determined by the explanation strengths of the relationships on the path between the findings. A path with relations that have low explanation strengths will give a smaller matching strength than a path of the same length, but with relations that have higher explanation strengths. This makes intuitive sense, paths with relations like always causes, causes and so on is generally seen as more probable than paths with relations like occasionally causes, implies and so on. The matching strength will also be negatively affected if the path between the findings consists of many intermediate steps.
Relevance All the findings have a relevance values associated with them. This value is computed from the importance and predictive strength of the finding in the retrieved case, and it influences the measure of overall similarity between the cases.
Note the low relevance score of the unmatched feature has colour blue in Figure 22. Remember that we sat both the importance and predictive strength of this finding to the lowest values (irrelevant and spurious) in Case 3, and now we see the result of this. The colour is not important for presence of the solution, nor does it hint at the solution of the case. It is not relevant for us in this case, and hence it only influences the similarity measure to a small degree.
Under Partially matched features several of the findings are greyed out and their relevance is set to 0%. This happens when there are several different paths to entities. As an example look at the two first lines under Partially matched features. There is a path from engine does not fire and starter motor does not turn to the same finding in the retrieved case broken carburettor membrane. If you click on one of these findings and then click on the Details-button you will see the path for each match. In such cases the path that produces the strongest matching strength is selected, and all the other paths are disregarded (relevance 0%).
The Symbol-comparator There is a subtlety involved in the actual matching of entities which we have not mentioned yet. Let us look more closely at an example of a direct match:
Case #1 –(has finding) engine does not fire (has finding)- Case #2
Here Case #1 and Case #2 have a finding that directly matches. For us this seems intuitive, but how does the system know that engine does not fire from Case #1 should match engine does not fire from Case #2? Because it is the same entity you might say, and you would be right, but the thing is that TrollCreek only tries to match entities that are descendants from the Symbol node in this way. Remember that we defined our top node, domain object, as a subclass of Symbol? If we had defined it as a subclass of an entity higher up in the hierarchy, say as a subclass of Entity, we would not have gotten any matches at all. The reason is that the Symbol-entity has a comparator connected to it, more precisely a symbol-comparator. This comparator is inherited by its descendants, and it is important for the matching process.
Reuse-tab Click on the Reuse-tab to see the results from the Reuse-process. The output of the Retrieve-process is the set of cases in the case-base that are the most similar to the case we are trying to match. The Reuse-process takes this as input and checks if the solutions of the cases it receives can be used as solutions for the unsolved case. The Reuse-tab consists of two main sections as shown in Figure 23: A graph and a listing of the possible solutions.
31 Figure 23. Reuse-tab
The graph illustrates a causal model for the selected solution. We see that the solution flat battery always causes starter motor does not turn, which in turn causes the engine not to fire.
The height of the bars under Possible Solutions is a measure of how probable a solution is. In the figure two of the cases that were retrieved during the Retrieve-process have the same solution (flat battery). The similarities of these two cases with the input case are then combined, making the solution flat battery more probable.
Note that in our model we have defined the solutions as findings also.
You can now try case matching on the other cases and see what results you get.
32 14 Summary
If you have followed the tutorial all the way through you should now have a basis for exploring TrollCreek on your own. To summarize the subjects we have touched on:
Adding entities (nodes or nouns) Connecting entities using relations (verbs) Visualizing the contents of the knowledge model using map, case and frame views Creating new relation types Adding cases Matching cases
In addition to this we have discussed some important concepts in TrollCreek (inheritance, explanation strength and so on). We have also seen the need for having a structure in our knowledge model (the terms hierarchy and causal model). It is not easy to find the best way to structure a knowledge model, and most models you create will probably go through changes before they “stabilize” in some structure that you find fitting.
You may find it useful to look at some other existing knowledge models to achieve more insight into how things can be modelled. There are some examples of knowledge models on the jCreek distribution page. Take a look at these. These models use the jcxml-format, which means that you have to import them into TrollCreek by using the Import from XML-command from the File-menu.
A final section on advanced topics is included at the end for users who want to learn more about some of TrollCreek’s features.
15 Advanced topics
In this section some less used and more advanced features of TrollCreek will be explained.
15.1 Inherits over/transfers
So far we assumed that inheritance only works with the has subclass/has instance relation types, but this is actually not the case. You can specify your own inheritance rules for all relation types.
Consider the following example: orange –(tastes)-> sour orange juice –(made of)-> orange
I would now like to model in accordance with the following logic: Since orange juice is made of oranges as modelled in Figure 24, and oranges tastes sour, orange juice also tastes sour. If I defined orange juice to be a subclass of orange it would inherit the finding tastes sour, but this would not be ontologically correct. What I would really like is to let the tastes-relation type be inherited over the made of-relation type. TrollCreek has the ability to do this.
33 Figure 24. Non-sour orange juice
If I opened the Frame View for the tastes-relation type and added the relation inherits over as shown in Figure 25, orange juice would inherit the finding tastes sour from orange through; . orange juice –(tastes)-> sour (inherited from orange)
Figure 25. Example of inherits over
The transfers-relation type is the inverse of the inherits over-relation type. This means that I could do the same by adding a transfers tastes-relationship to the made of-relation type as shown in Figure 26.
34 Figure 26. Tastes sour inherited from orange
By double clicking on a grey (inherited) relationship in the Frame View, you will get a window explaining how the relationship was inherited to the entity represented by that frame. To do this the Select Tool must be activated.
35 16 References
[1] Aamodt, A., Plaza, E.: Case-Based Reasoning: Foundation Issues, Methodological Variations, and System Approaches, AICOM, Vol. 7, no. 1, 39-59, March 1994.
[2] Aamodt, A.: Explanation-Driven Case-Based Reasoning. Topics in case-based reasoning, edited by S. Weiss et al., Springer Verlag, 274-288, 1994.
[3] Aamodt, A.: A knowledge-intensive approach to problem solving and sustained learning, Ph.D. dissertation, University of Trondheim, Norwegian Institute of Technology, May 1991.
[4] Noy, N. F., McGuinness D. L.: Ontology Development 101: A Guide to Creating Your First Ontology. http://protege.stanford.edu/publications/ontology_development/ontology101.shtml
36 17 Appendices
17.1 Appendix A: Relation types for the car model domain
Class Name Class Inverse Name Explanation Strength Relation has engine status Engine status of 0.5 has finding has battery status Battery status of 0.5 has finding has electrical system electrical system status 0.5 has finding status of has spark plugs status spark plug status of 0.5 has electrical system status has fuel status fuel status of 0.5 has finding has fuel system status fuel system status of 0.5 has finding has air filter status air filter status of 0.5 has fuel system status has carburettor status carburettor status of 0.5 has fuel system status has other finding other finding of 0.5 has finding has colour colour of 0.5 has finding always causes always caused by 0.9 Causal Relation leads to led to by 0.6 Causal Relation can cause can cause 0.4 Causal Relation occasionally causes occasionally caused by 0.3 Causal Relation
37 17.2 Appendix B: Entities for the car model domain
Entity Relation Relation to domain object subclass of Symbol state subclass of domain object colour subclass of domain object car starting case subclass of Case fuel system state subclass of state battery state subclass of state engine state subclass of state electrical system state subclass of state fuel state subclass of state other state subclass of state flat battery instance of battery state weak battery instance of battery state battery ok instance of battery state engine does not fire instance of engine state engine does not turn instance of engine state engine cranks slowly instance of engine state engine fires but stalls instance of engine state engine ok instance of engine state no chamber ignition instance of engine state electrical system ok instance of electrical system state starter motor does not turn instance of electrical system state starter motor ok instance of electrical system state starter motor turns slowly instance of electrical system state worn spark plugs instance of electrical system state condensation in gas tank instance of fuel system state water in gas tank instance of fuel system state water in gas mixture instance of fuel system state too rich gas mixture instance of fuel system state air filter blocked instance of fuel system state carburettor valve stuck instance of fuel system state broken carburettor membrane instance of fuel system state fuel system ok instance of fuel system state air filter ok instance of fuel system state hard driving instance of other state no lights instance of other state gas tank empty instance of fuel state gas in gas tank instance of fuel state red instance of colour blue instance of colour green instance of colour
38 17.3Appendix C: Car relationships in the car model domain (causal model)
Entity from Relation type Entity to flat battery always causes no lights flat battery always causes starter motor does not turn weak battery can cause starter motor does not turn weak battery leads to starter motor turns slowly weak battery can cause no lights starter motor does not turn always causes engine does not turn starter motor turns slowly causes engine cranks slowly engine does not turn always causes engine does not fire gas tank empty always causes engine does not fire condensation in gas tank leads to water in gas tank water in gas tank causes water in gas mixture water in gas mixture causes engine does not fire worn spark plugs can cause engine does not fire worn spark plugs leads to engine fires but stalls carburettor valve stuck causes too rich gas mixture air filter blocked causes too rich gas mixture hard driving occasionally causes broken carburettor membrane broken carburettor membrane leads to too rich gas mixture too rich gas mixture can cause no chamber ignition no chamber ignition always causes engine does not fire starter motor does not turn always causes engine does not turn engine does not turn always causes engine does not fire
39 17.4Appendix D: Car cases
Name: Case 1 Case type: car starting case Status: solved Has solution: flat battery
Relation Value Importance Predictive Strength has engine status engine does not fire Characteristic Indicative has other finding no lights Informative Strongly indicative has electrical system electrical system ok Informative Indicative status has battery status flat battery Informative Sufficient has air filter status air filter ok Informative Indicative has fuel status gas in gas tank Informative Indicative
Name: Case 2 Case type: car starting case Status: solved Has solution: flat battery
Relation Value Importance Predictive Strength has engine status engine does not fire Characteristic Indicative has colour red Irrelevant Spurious has battery status flat battery Informative Sufficient has other finding hard driving Informative Indicative has fuel system status condensation in gas Informative Indicative tank
Name: Case 3 Case type: car starting case Status: solved Has solution: broken carburettor membrane
Relation Value Importance Predictive Strength has engine status engine does not fire Characteristic Indicative has colour blue Irrelevant Spurious has carburettor status broken carburettor Informative Sufficient membrane has spark plugs status worn spark plugs Informative Indicative has battery status battery ok Informative Indicative
Name: Case 4 Case type: Case Status: unsolved Has solution:
Relation Value Importance Predictive Strength has engine status engine does not fire has colour red has fuel system status fuel system ok has other finding hard driving has electrical system starter motor does not
40 status turn
Name: Case 5 Case type: Case Status: unsolved Has solution:
Relation Value Importance Predictive Strength has engine status engine cranks slowly has colour blue has fuel status gas in gas tank
41