Rule editors allow for convenient and easy-to-use graphical user interfaces (GUIs), templates, etc. to make entry of new rules and modification of existing rules a relatively easy task. Typically rule editing is in an application-specific environment affording the user known terminology and a familiar context for rule formulation. Rule editors would use the IBM Agent Building Environment Developer's Toolkit Library objects to store and retrieve rules in the library. The programming interface for accomplishing this is relatively straight-forward. It involves converting the rule as formulated from templates or GUIs into a linear KIF form (refer to Chapter 2. "Writing Rules and Understanding Rule Inferencing"), running the constructors for Rule and RuleSet, and using the put member function of RuleSet to store the rules in RuleSets in the library's persistent storage.
This Level 6 of the IBM Agent Building Environment Developer's Toolkit includes a generic rule editor for building rules. Refer to Chapter 8. "Using the ABE Rule Editor" for a description.
If you decide to write your own rule editor, or you need to use the IBM Agent Building Environment Developer's Toolkit Library directly as a part of your application for some other purpose, refer to Chapter 1. "Building ABE-Related Components" of the Components and Adapter Reference book to guide you in compiling and linking to the IBM Agent Building Environment Developer's Toolkit Library class interfaces. Refer to Chapter 4. "Library Reference" of the Components and Adapter Reference book for the description of the Library class interfaces.
You configure the library by selecting a particular Library implementation. This is done by dynamically linking to a particular library dll. Currently there is only one Library implementation, a file-based implementation and the load module for this file implementation is iaglibf. This gives you the current file system implementation of the Library (later there could be additional choices of Library implementations, such as a data base implementation). Following are the steps for dynamically linking to a Library implementation and initializing the Library:
The attachImplementation() method does the dynamic link to the Library for you. It also builds a top Collector object for you.
Now you are ready to use the Library interface.
The interface for your rule editor may allow users to assign a name for each rule. This may be helpful for them to use in identifying rules for editing changes. If assigning a name to rules is optional, you may consider generating a name for the rule for them because such names may be helpful in interpreting tracing and logging by an inference engine. Also, later options/functions may require rule names.
Each RuleSet created by your rule editor must include RuleSet-level metadata. The user of the rule editor programs should not have to be aware of this metadata. The syntax used in this metadata is not necessarily intended to suggest any external syntax for rule editing or interchange and it may change in a future version of the IBM Agent Building Environment Developer's Toolkit. This metadata must have a metadata name of 0 (which is the default metadata name). The metadata is created through a member function of the RuleSet object, setMetadata. Note: Future versions of this IBM Agent Building Environment Developer's Toolkit will probably include changes to the current form of this metadata. This metadata currently is formatted as illustrated by the following example:
Each line in the example is numbered for reference as before, but numbers are not to be entered in the metadata itself. However, there must be a newline (\n) character at the end of each line as represented by the beginning of a new line in the example.
Note the separators between the three sections for predicate descriptions (lines 1, 14), predicate/sensor mappings (lines 15, 19), and predicate/effector mappings (lines 20, 26), each with BEGIN.... and END.... delimiter lines. The specific predicates, sensors and effectors used are only for illustration. You should use your own. Predicates are entered as signatures: a predicate name followed by a list of terms in parentheses, with separating comas and terminating semicolon. Each term is represented by a type indicator. Predicates can have 0 - n terms. The signatures tell the inference engine the type and number of terms for each term in a particular predicate. These predicate signatures may be unnecessary in post-alpha releases by taking more advantage of KIF. Following are the type indicators that you can use for the predicate terms:
These types apply to terms that are either constants or variables. For constants, this typing applies directly to the term. For example, you could have symbol, string, and integer constants respectively as follows:
The terms in an atom can also be a variable name, represented by a ? prefixed symbol such as ?Salary. In the case of variable name terms, the typing has no effect on the syntax of the variable name term itself. For a variable term, the type applies to the binding of the variable. For example, ?Salary might bind to one of the following (integer, string, and symbol respectively):
The sensors and effectors are preceded by the SENSOR or EFFECTOR keywords and have the following format:
The names are all symbols (alphnumeric with no blanks, beginning with an alphbetic character and including no special characters except underscore(_)). Blanks separate the symbols. A domain identifies an adapter and allows for limiting the scope of sensor/effector names to that domain. The colon associates the domain with a sensor or effector in that domain. Sensor or effector names are unique within their domain. A predicate name should be one that is also listed in the PREDICATES section of the metadata. Domain sensor and effector names are registered with the agent at run time by the associated adapter.
The purpose of the entries is to associate selected predicates with registered sensors or effectors. You can map multiple predicates to the same sensor. The scope of this mapping is the RuleSet for which the metadata is associated. That is, you can have multiple RuleSets, each with predicate names that map to sensors in different ways. For example, you can have a predicate named P in RuleSet R that is mapped to sensor S; then in another Ruleset R' you can map a predicate with the same name, P, to different sensor S'. The signature of the predicate must match the signature of the registered sensor/effector.
You do NOT supply such metadata for LTFactSets (Long Term Fact Sets). Of course, you only build a LTFactSet file when you have a need for long term facts. When you build the LTFactSet file, you give it the same name as you did for the RuleSet that is paired with it. This pairing depends on your inferencing needs. Often it is appropriate to inference with a particular set of rules and long term facts (paired), in which case the LTFactSet uses the metadata file of its paired RuleSet to define its LTFact predicate signatures.