As was discussed in the initial Literature Review chapter, an important step in designing an intelligent system is to have a sufficient scheme for knowledge representation. The MCRDR n-tree representation of knowledge, which is also
112
described in the Literature Review chapter, has been very successful for modelling knowledge in typical expert classification tasks such as medical diagnosis. However, it is clearly incapable of representing knowledge which is dependent on the presence of other knowledge such as is needed for a complex configuration task. RIMCRDR’s approach to solving this shortcoming was to add very little to the knowledge representation schema, allowing the expert to create a rule which used a classification, but little more. The main focus was on allowing this structure to be repeatedly inferred, inserting each classification of an earlier inference as another fact that applied to the current case as it was found. Unfortunately, with this method it becomes impossible to retract a classification once it has been found, and a strict chronological order of rule traversal is required, although it is conceded that, by applying some extensions to this method, retractions may be plausible. In traditional rule based expert systems this was perhaps less of a limitation, as rules were never stopped; they were either satisfied or they were not. In the MCRDR arena, however, rules can have exceptions which supersede their initial classifications, replacing the parent classification in the event that the child refinement is satisfied. If retractions are not allowed then it is not possible to define an exception which uses a classification as part of its rule conditions, as this exception would potentially retract the earlier classification when its requirements are satisfied at a later stage in the inference. An example of this is shown in Figure 4-1. In practice, an expert using an RIMCRDR system might ultimately find an alternate way to define the rule they desire. However, it is thought that this apparently unreasonable refusal to allow the expert to define the rule they initially “want” to define may be of some irritation to the expert in situations where they feel that it is the most natural way to express their knowledge.
Root – Always true
IF X,Y then ClassA IF ClassB then ClassE IF Z then ClassB
Figure 4-1 An example of an exception which uses a classification as a condition of its
rule. This rule could not be represented with the RIMCRDR knowledge representation scheme.
113
Certainly, restricting what types of rules the expert may assert at various points in the knowledge base, and enforcing a strict inference order, serves the practical purpose of making the RIMCRDR method easier to implement. The question still remains, however, are these restrictions necessary, or can a more flexible system be devised without loss?
It appeared likely that in order to provide this level of flexibility a modified knowledge representation schema is required. However, it is important that in creating this new schema no feature of the RDR philosophy should be lost, as this may compromise the method’s core selling points of not requiring a knowledge engineer, being easy to maintain, and being scalable.
To this end the n-tree structure of MCRDR was overhauled, such that it was closer to a directed graph in design, similar in ways to Exception Directed Acyclic Graphs (Gaines 1995). However, to preserve the original features of MCRDR no parts of its knowledge representation were at all removed; the properties to make it a graph were simply added separately.
A node in a traditional MCRDR tree will typically be defined as such: - Parent
o A reference back to the parent node. - Children
o A list of all children that this node has. - Rule
o The rule conditions. - Classification
o The classification that should be added if the rule is satisfied.
Alternatively, it may be defined with an equivalent variant, such as each node having a list of siblings on the same level instead of a list of children, but the end result is much the same, barring some slight differences when traversing the data structure.
This data structure remained relatively untouched, adding only one new variable, being a list of switches. Each switch represents a classification which must hold true in order for the rule to fire, and is defined as:
114 - Satisfied
o An integer that defines how turned on or turned off the switch is. 0 is completely off, but for each instance of this switch’s classification being added to the result list this value will increase by 1. If these classifications are removed later, the value will decrease by 1. By using a counter, rather than a Boolean state, it is easy to keep track of how many times a classification has been added to the result set, since the classification can potentially be reached through multiple paths. For example, if Class A has been added to the result set through three separate paths in the knowledge base, then retracting any one of these paths is not enough to require a re-inference of Class A’s dependents. It is only when all three paths have been retracted that a re-inference is required.
- Default state
o A Boolean which indicates whether the switch is one that is off by default or on by default. In other words, whether the switch is for a “class present” or “class not present” style of rule.
- Classification
o The classification this switch is for.
Further to this, the classification class itself is modified. It goes from being simply a representation of the classification (such as a simple string), to:
- Classification
o A primitive data-type (typically a string) which defines this classifications output.
- Dependents
o A list of all nodes (and therefore their associated switches) which depend on this classification in order to be able to fire.
- Dependencies
o A list of all the classifications which this classification may depend upon in order to fire. Must include information on whether it is a positive or negative dependency (class present or class not present). - Dependencies Visited
115
o A list which is tied to Dependencies. A set of flags to indicate whether a particular dependency has been searched yet. This will be discussed later when talking about cycles.
Other than these changes, the data structures remain essentially the same as in normal MCRDR. It should be clear that the original MCRDR n-tree remains entirely intact; it has just been augmented with other links which can cause a call- back to a previously evaluated node when the need arises.
For the sake of simplicity when describing various features of the knowledge base a graphical representation will be employed which makes use of three boxes. The top box containing the switches for the rule, the bottom left box containing the normal rule conditions, and the right-most box containing the rule’s classification. Each rule will be connected to other rules with a solid line to indicate a parent-child relationship, and a dashed line to indicate the relationship between a classification and a switch. An example of this is given in Figure 4-2. In this example a case [X,Y,Z] should fire with ClassA and ClassC, while a case of just [X,Y] should fire ClassA only and a case [Z] should fire ClassB only.
Switches
Conditions Classification Root – Always true
X & Y ClassA Z ClassB
ClassA
ClassC
116