# Knowledge Base Maintenance and Ripple-Down Rules

Knowledge acquisition for an expert system is often a continuing process because new knowledhe may come to light or some things that used to be true are no longer true. This means that an expert system's rule set must be modified to reflect the new knowledge. A major problem in updating a rule set is to ensure that any modifications leave the rule set consistent. That is, we don't want changes to break already working rules.

## Ripple-Down Rules

Ripple-down rules were devised by Paul Compton to make it easier to maintain a knowledge base and keep all the rules consistent. We will use the following formulation of a ripple-down rule:
if condition then conclusion [because case] except
if ....
else if ...
For example:
`if a and b then c except        if d then eelse if f and g then h`
This is interpreted as "if a and b are true then we conclude c unless d is true. In that case we conclude e. Here are the outputs of the RDR under different conditions:
`a and b       => ca and b and d => ea and f and g => h`
Notice that an RDR can always be rewritten as an ordinary if-then-else statement. The rule above would be:
`if a and b then       if d then e       else celse if f and g then h`
We use the exception conditions instead of the normal if-then-else form because this will make it easier for us to update rules.

## Building RDR's

Ripple-down rules are built interactively. Initially an RDR consists of a default rule, such as:
`if true then normal                                            rule 0`
This simply says that no matter what, the expert system will always draw the conclusion normal.If this were a problem in medical diagnosis, this rule would work most of the time because most people are normal!

Now suppose that a person comes to the doctor with symptoms a and b and the doctor concludes that the patient has disease c. The RDR would conclude that this person is normal. To correct this, we add an exception rule:

`if true then normal except                                     rule 1        if a and b then c`
This rule now works for this patient since the RDR would conclude that the person is normal except when the symptoms a and b are present.

Now suppose another patient with disease h comes along. He as symptoms f and g. Because there is no rule to cover these conditions, we still get a diagnosis of normal. This is because true is always true, so in the absence of any other rules, normal is the conclusion. How do we fix this? We add a new else part:

`if true then normal except                                     rule 2       if a and b then c       else if f and g then h`
This RDR now works for the new patient. Now suppose another patient comes to the doctor. This patient has symptoms a, b and d. The doctor concludes that the patient has disease e, but the RDR concludes c because of a and b. To fix this problem, we add another exception rule:
`if true then normal except                                     rule 3       if a and b then c except              if d then e       else if f and g then h`
This process is repeated for each case that is seen.

How do we know where to add a new rule? Here is the algorithm:

• if a rule fires, but produces an incorrect conclusion, we add an except branch.

• For example, rule 0, above fires, but produces the wrong conclusion so an except branch is added. Similarly, in rule 2, the a and b condition succeeds when given the example a and b and d. It should not so we add the exception condition.

• if a rule fails to fire when it should, an else branch is added.

• For example, in rule 1 above, the true condition succeeds and then we test a and b. This fails so we add an else branch to handle the new case.

## Using Case Differences to Build Conditions

How do we decide which conditions to add to a new rule? We would like to chose the conditions so that the new rule is as general as possible so that new cases can be diagnosed correctly. The interactive RDR methodology requires an expert to tell the system what conditions to use. However, the expert can get some help from the system.

An RDR system keeps track of which cases caused a rule to be created. Here is rule 2 above, rewritten with the associated cases:

`if true then normal because [] except       if a and b then c because [a, b]       else if f and g then h because [f, g]`
Now let's see what happens when we get case [a, b, d]. Initially it is classified as d, which is incorrect. Now what is the difference between the original case [a, b] and [a, b, d]? The new case has the additional condition d. So if we want to distinguish the two cases, we just look to see if d is present. Thus the new rule is:
`if true then normal because [] except       if a and b then c because [a, b]              if d then e because [a, b, d]       else if f and g then h because [f, g]`
Suppose that instead of the case [f, g] we had [a, f, g]. The RDR above would still produce the correct diagnosis, but the cases would be a little different.
`if true then normal because [] except       if a and b then c because [a, b]              if d then e because [a, b, d]       else if f and g then h because [a, f, g]`
According to this rule, the case [f, g] would be diagnosed as h. Suppose it should be diagnosed as i. What is the difference between the cases? The original case has an additional a. Thus the new rule could be:
`if true then normal because [] except       if a and b then c because [a, b]              if d then e because [a, b, d]       else if f and g then h because [a, f, g] except              if not a then i because [f, g].`
Thus, we can make a difference list of conditions from the old and new case like this:
• if the new case has any conditions not in the old case, add those extra conditions to the difference list.
• if the old case has any conditions not in the new case, add the negation of those conditions to the difference list.
These differences can then be presented to the expert to select the best ones.

Note: when attributes are numeric, we may have to do something else. For example, if case 1 has age 20 and case 2 has age 40, we might pick the mid point and build a condition age > 30.