IBM Agent Building Environment Developer's Toolkit


Chapter 2. Writing Rules and Understanding Rule Inferencing

This section describes the syntax of the KIF subset employed for storing rules and facts by the IBM Agent Building Environment Developer's Toolkit. It also describes current restrictions of the current inference engine implementation and presents suggestions for proper rule formulation.

KIF is an evolving standard for exchange of inferencing rules. It is not intended as a user-friendly interface for rule formulation, but it is essential that it be understood by the writers of rule editors, additional engine implementations, and, to a lesser extent, by adapter writers. It is also used here as a neutral syntax for explaining rule formulation in general with the present engine implementation as a base. Many limitations will be eliminated with future versions, this one being particularly early and not yet intended for production use. After you have become somewhat familiar with the prefix, KIF syntax, the tutorial switches to the more friendly infix form of rules and facts, which is employed by the IBM Agent Building Environment Developer's Toolkit rule editor. You are encouraged to employ this rule editor to examine the sample rules and generally become familiar with rule writing. This rule editor converts your rules from the more natural infix form to the internal KIF form that is employed by the Library for persistent storage. You are briefly introduced to both forms in this tutorial because KIF is occasionally exposed and is needed on occasion, while the infix rule syntax is used externally wherever possible. You will see that the differences between prefix (KIF) and infix are minimal and are not enough to cause significant confusion.

Logical Implication

At the broadest level there are two parts to a Rule:

The antecedent-expression logically implies the consequent-expression, symbolically:

antecedent-expression => consequent-expression

But KIF uses a prefix notation:

(=> (antecedent-expression) (consequent-expression) )

Atoms and Predicates

The antecedent and consequent expressions are built from logical atoms. Atoms consist of a named predicate followed by a list of terms:

(predicate term_list)

A predicate is a symbol for a relation between objects or a property of an object, specifically for the particular object(s) in the term_list that follows the predicate in the same atom. Predicate names are formed by a series of case-sensitive, alphanumeric characters, beginning with an alpha character, and including no special characters other than underscore (_). Here are some predicate examples (terms not shown):

  1. LocationOf
  2. Between
  3. Red
  4. Heavier_Than
  5. Oldest_of_3

A term_list consists of zero or more logical terms. Each term represents an object. Following are some examples of atoms:

  1. (SmarterThan Joe John)

  2. (Neighbors Stephens Bennett Coleman Woodnorth Glarakis)

  3. (Intelligent Benjamin)

  4. (TuesdayAfternoon)

In the first example, the predicate_name SmarterThan expresses a relationship between the terms (objects) Joe and John: Joe is smarter than John. Notice that the sequence in which the terms are listed is important for expressing the meaning of the atom. In the second example, the predicate Neighbors names a relationship between the named objects in the term list: Stephens, Bennett, Coleman, Woodnorth, and Glarakis are neighbors. This illustrates an atom where more than two objects are appropriate and where the order is not necessarily significant. In the third example, the predicate Intelligent is a property of the object Benjamin: Benjamin is intelligent. The last example is a predicate with no terms.

A term is either a constant or a variable. Constants and variables are syntactically distinguished by a ? prefix to the variable name:

?date

Our previous atom examples had constant terms. Here is an example of an atom with a variable as a term:

(BirthdayOf UncleJoe ?date)

The name used for a variable, such as date above, is a symbol type (see symbol below). A variable such as ?date is initially unbound or free. When a constant is substituted for the variable, it is considered to be bound.

Constants can be one of three types:

Potentially a variable can be bound with any of these constant types.

Symbols, like predicates, are represented as a sequence of alphanumeric characters, beginning with an alphabetic character and including no blanks or special characters other than _ (underscore), such as:

JOHN
Mary
MyDogSpot
Mailbox
Memo
My_3_Sons
Tel_545_3876
ConferenceCall

There is case sensitivity in symbol interpretation.

Strings are delimited by double quotes. You can have anything inside the quotes except other quotes. Escape characters will be forthcoming, but are not yet provided for. Following are some examples:

"Last memo of June"
"Rob Stewart"
"1996-06-28"
You can have " (quote) within a string by using the escape character, \. This is illustrated in the following:
"The \"Latest\" News"
which yields an effective string value when the KIF is parsed by the engine as follows:
The "Latest" News
You can also escape from the escape character by doubling up as follows:
"you have new mail.\\nIt is very important!"
which yields an effective string value when the KIF is parsed by the engine as follows:
You have new mail.\nIt is very important!
and allows you to provide newline character encodings in your strings.

Integers are enclosed in parentheses and preceded by the keyword integer, as follows:

(integer 254)
(integer -95)
(integer 2695884)
You can also express integers less formally without using the functional form:
254
-95
2695884

Note: Currently there is a little inconsistency in the form of integers:

This inconsistency will be fixed later.

Real numbers are enclosed in parentheses and preceded by the keyword real, as follows:

(real 254)
(real -95)
(real 26.95884)
(real +4.2)
(real -3.0012)
You can also express real numbers less formally without using the functional form:
254
-95
26.95884
-3.0012

Note: Currently there is a little inconsistency in the form of real numbers:

This inconsistency will be fixed later.

If you are writing a rule editor, you must provide a way for taking your user input and using it to formulate atoms, where those atoms have signitures (typing associated with its terms). These signitures are associated with the predicate name for each atom and recorded in RuleSet metadata, as described in "RuleSet Metadata Required for RuleSets" for more information on predicate signatures. This allows for consistency checking the syntax of terms for an atom against the signature defined for that atom. That is, the RuleSet metadata defines expectations - the definition of the form of the atom - and it can be used to validate the syntax of a rule that uses that atom as named by the predicate that it contains.

For terms that are variables, the signature in the RuleSet metadata that describes its predicate applies to the value that is bound to that term. For example, consider the following atom and RuleSet metadata predicate definition:

Atom: (BornAfter Joe ?date)
RuleSet Metadata (atom's predicate signature): BornAfter(Symbol,String);

This indicates that date is to be bound to a String constant.

Expressions

You can formulate groups of atoms into expressions for a rule antecedent by using logical connectives: AND and OR. Each connective has a pair of subexpressions that it connects. Nesting of AND or OR connected subexpressions forms an expression tree:


                                   AND
                                    *
                                    |
                     *--------------*----------------*
                     *                               *
                    AND                             AND
                     *                               *
                     |                               |
          *----------*----------*       *------------*-----------*
          |                     |       |                        OR
          *                     *       *                        |
        atom                  atom    atom             *---------*---------*
                                                       |                   |
                                                       *                   *
                                                     atom                atom

Here is an example of a complete rule:


                                    =>
                                    *
                                    |
                    *---------------*-----------------*
                    *                                 |
                   OR                                 |
                    *                                 *
                    |                          Qualifies Joe
          *---------*----------*
          |                    |
          |                    *
          |                   AND
          |                    *
          *          *---------*----------*
OlderThan Joe David  |                    |
                     *                    *
                     *                    *
                     *                    *
               Member David           Member Joe


which is (in KIF form):
     (=>(OR (AND(Member Joe) (Member David)) (OlderThan Joe David)) (Qualifies Joe))

Or, in English, "If Joe and David are members or Joe is older than David, then Joe qualifies".

An antecedent can be formulated from a single atom or multiple atoms connected by a logical AND or OR connector.

A consequent can be formulated from a single atom or multiple atoms connected by one or more ANDs. An OR connective is not permitted for the consequent of a rule.

Note: The nesting of atoms through terms is not supported at this time. That is, the following is not currently acceptable:

     (ShorterThan Mary (MotherOf Mary))
where (MotherOf Mary) is an atom that is also a term of another atom.

FACTS

In general, facts are atoms that are used to validate and/or assist in evaluation of rules, but are not directly a part of the a rule. Facts are atoms whose terms are all bound.

Long Term Facts

Long term facts are atoms as described above. Unlike atoms in rules, long term facts are atoms that stand on their own. They aid in inferencing by providing some of the means for evaluating the truth of rule antecedents, but, unlike rules, they are not the subject of the evaluation. Like rules, long term facts are built and stored persistently, usually through a rule editor. Long term facts are stored in the Library with rules and can be associated by name with rules. This association allows you to be able to match up long term facts with the rules for which they are intended to assist in inferencing.

Following are examples of long term facts:

(Manager "D. Gilbert")
(Address "1701 North Street")
(Interest "Mobile Computing")

Short Term Facts

Unlike long term facts, short term facts are not stored persistently or created through rule editors. Short term facts originate from adapters through trigger events or sensors (discussed below). Short term facts associated with a trigger event are referred to as a fact set. Short term facts associated with sensors are referred to as a binding list (discussed below). Like long term facts, short term facts each take the form of an atom. They represent dynamic, current adapter information (which indirectly is application information) that is input to rule inferencing.

A single trigger event can be the source of multiple short term facts (fact set). After short term facts are used for inferencing, they are discarded. That is, these facts are applicable for only one application of the current set of rules.

Following are examples of Short Term Facts:

(ForumName "Mobile Computing")
(MessageSource "D. Gilbert")

Derived Facts

Derived facts are atoms that exist in the consequent of a rule that has been fired successfully (is true), so the atom(s) in the consequent are also true.

Following are some examples of derived facts:

(Importance High)

(Topic "Intelligent Agents")

Inferencing Episode and the Fact Pool


    time                   Rule Inferencing Episode
  *------------------------------------------------------------------->
            ^                 Antecedent                   Consequent
           a|                      ^                           *
           r|                      |                           |
           r|                      |                           |
           i|                      |                           |
           v|                      |                           |
           a|                      |                           |
           l|                      |                           |
            |                      |                           |
       *----*------*       *-------+---------------------------+--------*
       | Trigger   |       |       |          FACT POOL        |        |
       | Event     |       |       *                           V        |
       |           |       |    validation            add derived facts |
       |  fact1 *  |       |                          (successful rule  |
       |  fact2 *--+-------+>add                            evaluation) |
       |  fact3 *  |       | on        ^add when conduct                |
       |           |       | arrival   |set is loaded                   |
       *----*------*       *-----------+--------------------------------*
            |                          |
            |                          |
            |                          |
            |                    *-----*-----*
            |                    | LT Facts  |
            |                    |           |
            |                    |           *------------* from Library
            |                    |           |
            |                    |           |
            *                    |           |
       from adapter              *-----------*

When a trigger event arrives, it causes a set of rules to be evaluated for that trigger event. The rule inferencing for a particular trigger event is referred to as an inferencing episode. It begins when the trigger event arrives and ends when all of the applicable rules (in loaded conduct set(s)) have been evaluated for the current set of facts. The current set of facts used by the inferencing episode is called a fact pool.

For each inferencing episode, the fact pool used by that inferencing episode consists of the following:

This fact pool is the primary source of truth validation for the rules that are fired. That is, it is primarily through this fact pool that the inference engine is able to determine the truth of the antecedents of the currently evaluated rules.

The Truth of the Matter

When a rule is "fired" (evaluated for logical truth), its antecedent is evaluated to determine if it is true. When this evaluation succeeds, the consequent of the rule is implied to be true also.

In the simplest case, where an antecedent does not include any variables, the antecedent evaluation is a matter of comparing its atoms to the pool of facts in the inferencing context. When all antecedents match with this pool of facts, the antecedent is evaluated as true.

When atoms are combined into expressions with connectives AND and OR, this evaluation considers the AND/OR logic.

Binding Free Variables

The fact pool has another purpose. When there are free (unbound) variables in a rule that is fired, normally the variables must be bound to successfully evaluate the rule. This binding is accomplished by:

When a variable name in an atom is resolved by matching the atom with facts in the fact pool, and substitution takes place, it also follows that there is similar substitution for all other variables with the same name in the same rule. There can also be more than one substitution for each free variable. In this case each substitution causes a firing of the rule. Consider a simple example:

Facts: (FromName Betty), (FromName Brad), (Manager Fred)

Rule: (=>(AND (FromName ?x) (Manager ?y)) (Mail ?x))

The rule is fired once for x,y substitutions of Betty,Fred; then again for Brad,Fred. This evaluates to two consequents: (Mail Betty) and (Mail Brad).

The following sections of this tutorial look at the rules in relationship to the adapters, focusing on trigger events, sensors, and effector. The sample Stock Adapter is used as an illustration. For more information on rule formulation in general refer to Chapter 5. "More on Writing Rules" below.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]