Please Make a Donation:
Support This Project

Hosted by:
SourceForge.net Logo

Rule Bases

Rule bases are collections of rules. A single rule base may contain both forward-chaining and backward-chaining rules.

Rule bases are created by writing a knowledge rule base (or .krb) file with your favorite text editor. Place all of your .krb files into a directory structure. Then load this directory into your python program.

The load will walk the directory structure recursively and automatically compile any .krb files into python source files. These python modules are then automatically imported to define the rule base. Subsequent loads only recompile .krb files that have changed since the last time they were compiled.

The name of each rule base is the filename of the .krb file (with the .krb suffix removed). This must be a legal python identifier.

In addition, each directory name within the directory structure loaded becomes a python package (to facilitate importing the generated python modules) and must also be a legal python identifier.

Managing Multiple Rule Bases

There are two reasons to have more than one rule base (i.e., more than one .krb file):

  1. To divide a large set of rules into human manageable units.

    In this case, you want pyke to use all of the rule bases combined.

  2. To enable your python program to choose between different rule bases that are tailored to different specific situations.

    For example, you may have rules governing the automatic generation of SQL statements. Some of these rules may vary depending upon the target database (e.g., mysql, postgresql, oracle).

    In this case, you want to be able to tell pyke which of several mutually exclusive rule bases to use on each invocation. You would never use more than one of these rule bases at the same time.

These goals are met by three capabilities:

Rule Base Categories

Rule bases are grouped into categories. Each rule base category only gets to have one active rule base.

Thus, you place rule bases that you want to have active simultaneously into different rule base categories; and place rule bases that are mutually exclusive to each other (e.g., the mysql, postgresql and oracle rule bases) into the same rule base category.

Each rule base category has a unique name. This is the knowledge base name used within the .krb files. For example, the name database in database.insert(...).

Rule Base Inheritance

The rule bases within the same category share rules amongst themselves through rule base inheritance.

Rule bases use single inheritance to inherit the rules from another rule base. This can go on to any depth. Both forward-chaining and backward-chaining rules are inherited.

This allows mutually exclusive rule bases to share common rules in a parent rule base without having to duplicate these rules amongst themselves.

Here is the definition, then, of a rule base category:

Each root rule base (through rule base inheritance) defines a unique rule base category. All rule bases derived (directly or indirectly) from that root rule base are in the same rule base category.

The name of the rule base category is simply the name of its root rule base.

So, for our database example, we'd have a root rule base called database.krb and it would have derived rule bases called mysql.krb, postgresql.krb and oracle.krb. (Note that each of these .krb files may be placed anywhere you want them within the directory structure that you load -- in other words, the loaded directory structure does not need to match the rule base inheritance structure).

All of these .krb files are within the database rule base category, and only one of them may be active at any point in time.

In all of these .krb files, if the first name (the knowledge base name) is omitted, it defaults to the rule base category of that rule base (in this case, database). Thus, insert(...) would mean database.insert(...) in all of these .krb files because they are all in the database rule base category.

All .krb files in other rule base categories must explicitly use the knowledge base name database to refer to goals within this rule base category, for example, database.insert(...).

In this way, all of the rules will work no matter which rule base is active within the database category.

Rule Inheritance

There is an important difference between how backward-chaining rule inheritance works within pyke rule bases and how method inheritance works within python classes:

  • When a derived class in python defines a method by the same name as a method in its parent class, the derived method overrides the parent method. I.e., only the derived method is used when a call is made to it.

  • In contrast, when a derived rule base in pyke defines a backward-chaining rule for a goal that also has backward-chaining rules defined for it in the parent rule base, the derived rule extends the set of rules that may be used to try to prove this goal. All of the derived rules will be tried before any of the parent rules are tried.

    If you don't want the parent rules to be used for a particular goal, you must list that goal name in the without clause of the extending statement at the beginning of the derived rule base.

  • All forward-chaining rules in the parent rule base are always included in the derived rule base. The without clause only applies to backward-chaining rules.

Rule Base Activation

Loading the rule bases only makes the rule bases available for use. It does not automatically activate any rule bases. This must be done explicitly by your python program. Your program may decide to activate different rule bases in different situations.

Additionally, forward-chaining rules may be used to activate more specific rule bases, based on their inferencing; but once a rule base has been activated in a rule base category, only children of the currently active rule base may be activated from that point on. Because these children inherit the rules of the currently active rule base; activating rule bases only adds new rules, and doesn't take any away. Thus, any forward-chaining rule run during the activation of the first rule base are not invalidated by activating the second rule base.

In our database example, your program could activate the root database rule base and let the forward-chaining rules within the database rule base figure out which derived rule base to activate depending on the particular database in use at the time the program is run.

More:

Fact Bases

Explanation of facts and fact bases.

Rule Bases

Explanation of rule bases, overview of .krb files and how these files are compiled and loaded into your python program.

Special

Explanation of the special knowledge base.

Page last modified Fri, Jan 04 2008.