Ripple-Down Rules has been shown to be a highly effective tool for KA and KM. However, its lack of ability to handle tasks with multiple possible conclusions significantly limits the method’s ability to be applied in many domains. The aim of Multiple Classification Ripple-Down Rules (MCRDR) was to redevelop the RDR methodology to provide a general approach to building and maintaining a KB for multiple classification domains, with all the advantages found in RDR. Such a system would be able to add fully validated knowledge in a simple incremental contextually dependant manner without the need of a KE (Kang 1996; Kang et al. 1995).
3.3.1 Structure and Inference
The new methodology developed by Kang (1996) is based on the proposed solution by Compton et al (Compton et al. 1991; Compton et al. 1993). The primary shift was to switch from the binary tree to an n-ary tree representation. The context is still captured within the structure of the KB and explanation can still be derived from the path followed to the concluding node. The main difference between the systems is that RDR has both an exception (true) branch
and an if-not (false) branch, whereas MCRDR only has exception branches. The false branch instead simply cancels a path of evaluation. Like with RDR, MCRDR nodes each contain a rule and a conclusion if the rule is satisfied. Each, however, can have any number of child branches and each one represents an exception branch.
Inference occurs by first evaluating the root and then moving down level by level. This continues until either a leaf node is reached or until none of the child rules evaluate to true. Each node tests the given case against its rule. If false it simply returns, X (no classification). This is essentially the same as following the false branch in RDR. However, if this node’s rule evaluates to true then it will pass the case to all the child nodes. Each child, if true, will then return a list of classifications. Each list of classifications is then collated with those sent back from the other children and returned. However, if none of the children evaluate to true, and thus they all return X, then this node will instead return its classification. Like with RDR the root node’s rule always evaluates to true, ensuring that if no other classification is found then a default classification will be returned.
For example, a case with the attributes {a, c, d, e, g, i} is presented to the MCRDR KB shown in Figure 3-4. The case ripples down through two child
Rule 1: If ‘a’ then Conclusion - A Rule 2: If ‘b’ then Conclusion - B Rule 0: If true then Conclusion - default Rule 3: If ‘d’ and ‘f’ then Conclusion - C Rule 4: If ‘c’ and ‘d’ then Conclusion - C Rule 8: If ‘h’ then Conclusion - D Rule 5: If ‘g’ then Conclusion - A Rule 9: If ‘e’ then Conclusion - F Rule 6: If ‘f’ and ‘h’ then Conclusion - E Rule 7: If ‘h’ then Conclusion - F Rule 10: If ‘i’ then Conclusion - B Case attributes a, c, d, e, g, i
Figure 3-4: Example of the MCRDR n-ary tree structure. The rectangle nodes of the tree contain a rule and a classification. All branches are essentially exception (true) branches. The straight arrows indicate the direction of possible inference. The grey filled boxes show the rules that are tested and evaluate to true for the
rules, 1 and 4, from the root node as these were the only nodes with rules evaluating to true. The path followed to rule 1 is, however, immediately halted as all its children return, X. The path continuing from rule 4 passes through rule 5 and concludes at rules 9 and 10. These three concluding rules, 1, 9 and 10
return our conclusions A, F and B. The conclusion of A, in this example, however, is redundant because the inference process for classifications F and B
had the rule paths {0 – 4 – 5 – 9} and {0 – 4 – 5 – 10}. Both paths past through rule 5, and due to rule 5 having the same classification as rule 1, and because an exception was found to rule 5, then that exception is also an exception to rule 1. Thus, the final conclusion is F and B.
3.3.2 Learning
Knowledge acquisition in MCRDR occurs for the same situations as with RDR, when a case is misclassified or when no classification other than the default is found. Once an error is found the MCRDR procedure for refinement is mildly more complicated than the approach used in RDR. This complexity comes from enforcing the need for validation during the KA task. Kang et al (1995) describe a three step process:
1. The expert supplies the correct classification. This is a trivial step and was also required in RDR. It is simply the process of the expert informing the system of the correct classification for the case presented
2. The system identifies the new rule’s location. This is a new step and will be discussed in the following section (3.3.2.1)
3. The expert defines the new rule from a series of difference lists. This step was also in RDR but has been expanded (3.3.2.2).
3.3.2.1 Locating Rules
In the RDR methodology each new node was simply attached to the appropriate node at the bottom of the tree where inference had halted. However, in MCRDR there can be multiple nodes attached to a parent node, thus a new node should be able to be attached at any location in the tree hierarchy, between the root and the terminating inference node. Kang et al. (1995) identifies three reasons for
Wrong Classification Method to Correct the KB
A new independent classification
Add the new rule at an appropriate higher level so that it does not cancel the already
correct classification.
A classification is wrong and should be replaced by another
classification
Add a rule at the end of the path to give the new classification. This cancels the
old incorrect classification
Classification is wrong and should simply be stopped
Add a new stopping rule at the end of the path to prevent the classification
Table 3-1: Three ways for adding new rules when correcting an MCRDR KB (Kang et al.
1995).
wishing to correct the knowledge base and identifies recommendations for what types of rules should be created and where they should be placed, shown in Table 3-1. The middle situation is identical to RDR’s reason for creating a new rule. However, the other two are unique to MCRDR. The first circumstance allows for the possibility of increasing the number of classifications of a case. The final situation introduces a special rule, referred to as a stopping rule, which is used to halt and cancel a particular path of evaluation. The stopping rule plays an important role in MCRDR by preventing incorrect classifications being given for a presented case.
It can be seen here that a decision must be made as to whether the new rule being created is a refinement (or exception) to an existing rule, or whether it is an entirely new classification. If it is new then it should be added further up the tree, after the last relevant node. The last relevant node is the final one in the original evaluation path that the new rule could be considered to be offering a refinement. However, in some ways it does not matter as any location between the root and the terminating node will still work regardless of the expert’s view of the new rule. The primary effect of location is on the evolution and maintenance of the KB. If the chosen rule creation strategy tends to place new rules towards the end of inference paths, then the domain coverage will be slow but each rule will generate fewer errors because they are seen less frequently. If the strategy used tends to position new rules higher in the path then the KB structure will be flatter and broader, meaning more rules are in context at any
time. This will result in the faster coverage of the entire domain but each rule will generate more errors, because the use of context is not as great (Kang 1996).
While these added decisions may imply the need to return to employing a KE, research has shown that through using various interface strategies, the RDR philosophy of the expert having no knowledge of the underlying structure, can remain. For instance, Kang et al (1995) offers a number of possible interaction methods that can lead towards either a more general wide ranging KB or a more highly specified KB. These outcomes can be achieved by asking the expert to select the important data used to reach the new conclusion, or alternatively, to delete the irrelevant data. Then the selected or remaining data is used to create a
mini-case12, which is processed by the tree to find how far down the identified path the new rule should be placed. This process is effectively searching for the correct context to place the rule.
3.3.2.2 Rule Creation
The idea in incremental validation is that the new rule does not cause any previously seen correctly-classified cases to now be misclassified after the new rule is added. Generally, validation is performed by maintaining a database of previous cases. In RDR this is simply done by testing the new case against the cornerstone case that was stored at the time of the parent rules creation, thus there is only the one previous case stored in the database. In MCRDR this notion of a cornerstone case is retained, however, it has been extended due to the possibility of relevant rules being created elsewhere in the tree. Each node in the MCRDR tree can contain a number of cornerstone cases. There are two situations when a case can be added as a cornerstone case:
• Firstly, as in RDR, when a new rule is created, the case that was incorrectly classified and caused the new rule is added as the first cornerstone case of the new node.
• Secondly, if a case is correctly classified at a particular node but incorrectly classified simultaneously at another node causing a new rule to
12
A mini-case is a case that only has a selection of attributes of the actual case that caused a misclassification. Thus, if a mini-case is represented by ‘c’, then c ⊆C.
be created elsewhere in the tree. The case is added to the newly created rule, (per the first point) and also to the node that classified it correctly.
The second point is performed because it is known that this is a correctly represented case by the KB. The system knows this because the expert has taken the time to correct a rule. Cases that the expert has simply accepted as correctly classified are not stored, because they could be wrong. This would occur when the expert had little concern about the error and had not taken the time to correct them. Thus, they are never used for validation.
A second complexity in the multiple classification knowledge acquisition methodology, is that with the possibility of multiple children, the system would be required to also validate any rule being created against not only all the cornerstone cases at the parent node, but also all the cornerstone cases at all the sub branches from the parent node. Figure 3-5, illustrates which nodes’ cornerstone cases would need to be checked for validation. It can be seen that the higher up the tree a correction is being made the more cornerstone cases from which the current case will be required to be differentiated.
To create a new rule a difference list will need to be generated between the current case and all the relevant cornerstone cases. Equation (3-1) shows an example of what needs to be accomplished. In this example, case A is the
Rule 1: If ‘a’ then Conclusion - A Rule 2: If ‘b’ then Conclusion - B Rule 0: If true then Conclusion - default Rule 3: If ‘d’ and ‘f’ then Conclusion - C Rule 8: If ‘h’ then Conclusion - D Rule 7: If ‘h’ then Conclusion - F New Node to be created Rule 5: If ‘g’ then Conclusion - A Rule 9: If ‘e’ then Conclusion - F Rule 6: If ‘f’ and ‘h’ then Conclusion - E Rule 10: If ‘i’ then Conclusion - B Rule 4: If ‘c’ and ‘d’ then Conclusion - C
Figure 3-5: MCRDR tree showing the nodes that cornerstone cases should be taken from when a new node is added to the node containing Rule 4. This is the same tree as in Figure 3-4. The new node to be created, when added, will have the rule 4 node as a parent. Cornerstone cases should be drawn from all the nodes below the parent node in the tree, shown in the grey section. Thus, they will be taken
current case needing to be differentiated from two cornerstone cases, case B and
case C.
(
)
(
)
(
caseB caseC caseA)
from conditions negated or C case B case A case − ∩ ∪ − (3-1)
However, finding an attribute in the new case that is not in any of the cornerstone cases is often not possible, as illustrated in Figure 3-6. Kang (1996; Kang et al. 1995) argues that the exclusivity of the attributes themselves is, however, not what is important, only the uniqueness of the attribute combination is required. To extract such a combination, Kang suggests a simple incremental approach to rule construction, where a series of difference lists are
(a) Difference List between A and (B and C) a not f (b) Difference List between A and (B and C) empty Difference List between A and B d not c Difference List between (A and C) b not g
Figure 3-6: Comparison of two rule selection methods using two similar situations. In both situations: case A is the current case requiring a new rule; and, cases B and C are both cornerstone cases. In situation (a) the simple method is able to find the attributes {a, !f} separating the new case from the two cornerstone cases, identified by the light grey areas. In situation (b) there are no attributes in the locations used in situation (a), therefore, the simple method fails to find any attributes separating A from B and C. However, the second method finds {d, !c} differentiating A from B, identified by the light grey areas, and {b, !c} separating A from C, shown in dark grey. Thus, case A can be uniquely identified through the attribute combination of {b, d, !c, !g}. Note: in this example all possible attributes were selected, the expert, however, would only need to select a minimum of 1 from each difference list (taken from Kang et al. 1995).
generated. Therefore, in the example of Equation (3-1, A is first compared against B, and then compared against C. Figure 3-6, shows how, in certain situations, this can find a rule where the simpler approach could not.
This method appears rather time consuming for the expert, as they potentially would have to select differences in hundreds of comparisons. However, in practice this is not the case. When the expert selects an attribute from the first difference list all the other cornerstone cases are checked against this partial rule. All cornerstone cases not satisfied are removed from the list of cornerstone cases. Then the case is compared against one of the remaining cases. This process of eliminating cornerstone cases significantly reduces the amount of comparisons required and only very rarely does an expert need to make more than 3 or 4 comparisons (Kang 1996; Kang et al. 1995; Kang et al. 1998).