5 Forward Chaining

This chapter discusses a forward chaining rule based system and its expert system applications. It shows how the forward chaining system works, how to use it, and how to implement it quickly and easily using Prolog. A large number of expert systems require the use of forward chaining, or data driven inference. The most famous of these is Digital Equipment Corporation's XCON system. It configures computers. It starts with the data about the customer order and works forward toward a configuration based on that data. The XCON system was written in the OPS5 (forward chaining rule based) language. Data driven expert systems are different from the goal driven, or backward chaining systems seen in the previous chapters. The goal driven approach is practical when there are a reasonable number of possible final answers, as in the case of a diagnostic or identification system. The system methodically tries to prove or disprove each possible answer, gathering the needed information as it goes. The data driven approach is practical when combinatorial explosion creates a seemingly infinite number of possible right answers, such as possible configurations of a machine.

5.1 Production Systems

Forward chaining systems are often called "production" systems. Each of the rules is actually a miniature procedure called a production. When the patterns in the left hand side match working storage elements, then the actions on the right hand side are taken. This chapter concentrates on building a production system called Oops. Production systems are composed of three components. These are: the rule set; a working storage area which contains the current state of the system; an inference engine which knows how to apply the rules. The rules are of the form: left hand side (LHS) ==> right hand side (RHS). The LHS is a collection of conditions which must be matched in working storage for the rule to be executed. The RHS contains the actions to be taken if the LHS conditions are met. The execution cycle is: 1. Select a rule whose left hand side conditions match the current state as stored in the working storage. 2. Execute the right hand side of that rule, thus somehow changing the current state.

3. Repeat until there are no rules which apply. Production systems differ in the sophistication of the algorithm used to select a rule (step 1). The first version of Oops will use the simplest algorithm of just selecting the first rule whose conditions match working storage. The knowledge engineer programs in Oops by creating rules for the particular application. The syntax of the rules is: rule <rule id>: [<N>: <condition>, .......] ==> [<action>, ....]. where: rule id - a unique identifier for the rule; N - optional identification for the condition; condition - a pattern to match against working storage; action - an action to take. Each condition is a legal Prolog data structure, including variables. Variables are identified, as in Prolog, by an initial upper case letter, or underscore. In general, the condition pattern is matched against those stored in working storage. The comparison operators (>, =<, etc.) are also defined for comparing variables which are bound during the pattern matching. Note that the data representation of Oops is richer than that used in Clam. In Clam there were only attribute - value pairs, or object - attribute - value triples. In Oops the data can be represented by any legal Prolog term including variables. The following RHS actions are supported: assert(X) - adds the term X to working storage; retract(all) - retracts all of the working storage terms which were matched in the LHS of the rule being executed; retract(N) - retracts LHS condition number N from working storage; X = <arithmetic expression> - sets X to the value of the expression; X # Y - unifies the structures X and Y; write(X) - writes the term X to the terminal; nl - writes a new line at the terminal; read(X) - reads a term and unifies it to X; prompt(X, Y) - writes X and reads Y;