Algernon Tutorial 3.b
Introduction to rules


previous   next

Syntax

Each rule is a path:
  Forward chaining:
    (antecedent clauses
     ->
     consequent clauses)

  Backward chaining:
     (consequent clauses
      <-
      antecedent clauses)

Forward chaining rules

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))

Backward chaining rules

In backward chaining rules the key clause is the first clause in the consequent.
  A component is onsite unless it has been sold.

  ((location ?x ONSITE)
   <-
   (:FAIL (status ?x Sold)))

Usage

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 a2 or a3 is asserted, the rule will continue processing without requiring human intervention.

IMPORTANT!

Any relation (slot) referenced in a rule must be defined in the KB. Although it's tempting, you can't make up arbitrary relations to be "proved" with a rule.
  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)))
   )

previous   next
Author: Micheal S. Hewett
Email: hewett@cs.stanford.edu
Last Updated: Saturday, February 8, 2003