-
Notifications
You must be signed in to change notification settings - Fork 40
Technical Description
Each rule in a Ruleby program is made up of a pattern, and an action. The pattern is the left hand side (LHS) of the if-then production, and the action is the right hand side (RHS).
The pattern (LHS) is actually made up of one or more sub-patterns. Each pattern either checks that an object exists in working memory, or that an object does not exist in working memory. If there are multiple patterns, then they are aggregated with a logical “and.” In the current version (0.2), the patterns can only be combined using an “and.” In future releases, there will also be support for a logical “or.”
The action (RHS) is simply a block of Ruby code that will be executed if the rule is satisfied.
The Ruleby inference engine is an implementation of the Rete pattern matching algorithm. A Rete system compiles rules into a network of nodes that are used to compare against facts in working memory. The Ruleby network specifies five different node types
- RootNode – there is only one RootNode per inference-engine instance. It is the top most node in the network.
- AtomNode – this type of node is used to match objects in working memory. Each AtomNode represents a particular properties of a class. These nodes make up the alpha network.
- JoinNode – this two-input node creates a cross product of any nodes above it in the network. These nodes make up the beta network (with the next type of node).
- NotNode – this two-input node is similar to the JoinNode class, but checks for facts that are not in working memory.
- TerminalNode – this type of node represents the end of a particular branch of the network. It corresponds to a rule.
The default conflict resolution strategy employed by Ruleby uses a combination of three mechanisms. The first is LIFO (last in, first out). Each action that is to be fired by the engine is given a priority based on the order in which it was satisfied. The actions that are satisfied last are fired first.
The second mechanism of the resolution strategy is salience. Each rule can be given an explicit priority when it is compiled. This priority is an integer value, and a higher number means that the action will be fired before other rules that were satisfied at the same time (i.e. they were given the same priority in the LIFO resolution strategy).
Finally, Ruleby prioritizes activations based on the recency of the facts each depends on. Each fact in working memory is given a recency value which is based on the order in which it was added to the system. The resolution strategy then prioritizes activations based on the recency of the facts that caused each activation to be added to the agenda.
These three mechanisms are prioritized in the following order from highest to lowest: LIFO → Salience → Recency. So if two activations have the same LIFO priority and salience then they will be sorted by recency.