Forward chaining: (antecedent clauses -> consequent clauses) Backward chaining: (consequent clauses <- antecedent clauses)
Forward chaining rules will fire when relevant information is asserted into the KB. For efficiency they are assigned to classes and will potentially fire if any subclass or instance of the class is added or modified. They fire only once for each fact asserted, unless the fact was deleted after being previously asserted.
In order to fire, the key clause of the rule must match the new fact. In forward chaining rules the key clause is the first clause in the antecedent.
If a component is ordered, make it unavailable for other orders. ((ordered ?x ?date) -> (status ?x Reserved) (last-update ?x ?date)) When the component ships, delete it from inventory ((shipped ?x ?date) -> (status ?x Sold) (last-update ?x ?date))
A component is onsite unless it has been sold. ((location ?x ONSITE) <- (:FAIL (status ?x Sold)))
Backward-chaining rules are used to answer queries. Before Algernon retrieves information from the KB it will first try to infer additional relevant information by finding and executing relevant backward-chaining rules. After they have finished it then does a simple KBMS query.
Forward-chaining rules derive additional facts from new data. After asserting new data (slot values), Algernon fires relevant forward-chaining rules.
The antecedent of a rule is compiled in query (ask) mode, and the consequent is compiled in assert (tell) mode.
An important concept is rule continuations. If the antecedent of a rule has several clauses it may find that the first ones are satisfied but that others don't yet succeed:
(a1 a2 a3 -> c1 c2) a1 matches a new fact. a2 succeeds. rule continuation 1 created. a3 fails. rule continuation 2 created. continuation 1: a2' a3' -> c1' c2' continuation 2: a3' -> c1' c2' x' = x with bindings from previous clauses in this activation of this rule.
The continuations ensure that whenever a new
a3 is asserted, the rule will continue
processing without requiring human intervention.
This generates a syntax error if the slot PowerHitter is not defined in the KBMS. ((PowerHitter ?x True) <- (HomeRuns ?x ?homers) (:TEST (:LISP (> ?homers 40))) )