Release Level	1.9
Release Date	2000 06

Rules and RTrules

Rules are the main driving construct in both the backward and forward chaining expert system; while they share many basic syntactic features, and have a very similar format, please note that the underlying logic of the backward chaining and forward chaining rules are quite different, even though the two systems can be intricately (and fully transparently) integrated.

Rules files or sets of files are declared in the KBconfig file as RULE-FILES and RTRULE-FILES, respectively:

   RULE-FILES
      Rules.backward
   END-RULE-FILES

   RTRULE-FILES
      Rules.forward
   END-RTRULE-FILES

Rules: backwards chaining

A detailed description of the syntax of Rules, Tables, and the associated descriptors is given in Embedded Expert System Syntax.

Please note that Rules in the backwards chaining system are driven (triggered) by the Descriptor Rule References (by Rule Number) in the Descriptor's R field.

WARNING: a backward chaining Rule does NOT automatically become effective by adding it to a Rule file; it must be referenced by a Descriptor, and will be processed only if and when this Descriptor in turn is addressed (as an editor target or within another Rule) to determine its value.

Rules in the forward chaining system are screened (for example, Rules that can trigger an ACTION that is already set to done will be ignored), and are then ALL evaluated in sequence until the first Rule meeting all conditions can be fired.

RTrules: forward chaining

Forward chaining rules (RTRULES) are similar to the backwards chaining rules; the main functional difference is that their THEN part can either:

• set an ACTION to ready with => ready
• assign a Descriptor value with DESCRIPTOT(name) = value.

  While RULES require a consistent numbering scheme (they are referenced by these numbers from the descriptors, numbers for RTRULES server only diagnostic purposes.

  In both cases, sequence in the Rules files (and sequence of Rule files in the KBconfig controlled loading sequence) is relevant.

Common Syntax

RULE ID
   IF       TOKEN COMPARISON_OPERATOR  VALUE
   AND      TOKEN COMPARISON_OPERATOR  VALUE
   OR       TOKEN COMPARISON_OPERATOR  VALUE
   THEN     TOKEN ASSIGNEMENT_OPERATOR VALUE
ENDRULE

TOKEN can be

• backward chaining: Descriptor_name
• forward chaining: DESCRIPTOR(Descriptor_name) or ACTION(Action_name)

VALUE can be any legal value (string, numerical value, or arithmetic expression) defined in the V field(s) of the respective TOKEN;

OPERATOR can either be used for comparison (condition parts) or assignement (consequence part) of a Rule.

• COMPARISON_OPERATORs: equality (==) and greater/small greater/small-equal
• ASSIGNEMENT_OPERATORs:
  • to assign a new descriptor value: =
  • to set an ACTION to ready: =>

The condition parts of a Rule can contain AND and OR (inclusive OR) in arbitrary nesting, using [ ] to make the nesting explicit.

Where "[" (square brackets) are used for nested AND and OR contructs, please make sure to keep a blank between strings and the brackets:

RULE 01004
IF   DESCRIPTOR(source_type)       == road_accident
AND  [ ACTION(call_road_police)    == done
     OR   ACTION(call_road_police) == pending ]
THEN ACTION(pick_substance)        => ready
ENDRULE