Preliminary mapping of the JBoss Rules condition language

Dear All,

Due to me having been ill for the last 10 days or so, this is the first
cut at a mapping of JBoss Rules language to the RIF condition language.
This is to respond to my action item.

The JBoss Rules language (http://www.jboss.com/products/rules) is a
powerful and rich rule language based on the RETE algorithm and
appropriate representation. The system runs in Java and is especially
well integrated with the JBoss application server but is quite general
and is suitable for use in any Java-based environment. The system was
previously known as Drools and has now been completely incorporated into
the JBoss framework.

Conceptually, the JBoss knowledge base consists of a fact base and a
rule base. The fact base of the JBoss Rules is called a Working Memory
(WM). The "facts" stored in the WM are actually Java object instances
(beans). WM is optimized for efficient access and asserts/retracts of
these objects. The rule base consists of production rules stored
separately and grouped into packages. The forward-chaining RETE
algorithm continuously examines the contents of the WM and fires the
production rules that have matching conditions resulting in further
updates to the WM. An API is used for querying the WM to collect the
results. Backward chaining is the intended future extension of the JBoss
Rules engine.

The top-level structure of production rules is very simple:
   when
      <condition>
   then
      <action>
The rules have unique names as well as an optional collection of
attribute/value pairs, for example, the value of "salience" denotes the
priority assigned to the rule. It should be noted that the action part
is not limited to a single action and in addition to the WM updates can
include updates to global (package-scoped) variables, calls to
functions, and arbitrary Java method invocations on accessible object
instances.

We now look in more detail into the condition part of the rules. The
conditions are built from expressions that are evaluated against the
object instances in the WM. The overall condition is built from
Condition Elements (CE) and Columns. CE's are effectively the usual
logical connectives such as "and", "or", or "not"; plus an existential
quantifier "exists" with "forall" expected to be added in future.
Columns are individual conditions evaluated against specific object
types.

A column regroups a set of "field constraints" on an object instance of
a particular type. Such constraints can be most easily mapped to Frame
Logic The simplest constraint allows to simply extract the field value
of an object of a specified type. 

Cheese( cheeseType : type )

Here "Cheese" is an object type (concretely, a Java type) for which the
constraint is defined. In brackets, "type" is the name of the object
(bean) field. "cheeseType" is a variable that will be assigned the value
of the field "type".

Here is a more complex constraint that checks the value of a field
against another variable uses the following syntax.

Person( favouriteCheese = cheeseType )

The most obvious mapping to RIF would be via a Frame Logic (F-Logic)
extension to FOL. The mapping to F-Logic is justifiable in the context
of RIF because F-Logic can be reduced to FOL by using appropriate
predicates and axioms for various molecules. Combining the above two
expressions by "and" in JBoss Rules gives:

Cheese( cheeseType : type ) and Person( favouriteCheese = cheeseType )

This can be equivalently represented using the F-Logic "attribute
molecules":

C : cheese[cheeseType->FC], P : person[favouriteCheese->FC]

The meaning of the above expression is that the WM contains an instance
of C class Cheese and an instance P of class Person such that P has the
favouriteCheese field equal to the type of C.

A more complex example follows.

JBoss Rules:

Person(girlAge : age, sex == "F") and
Person( age == (new Integer(girlAge.intValue()+2)), sex = "M" ) )

F-Logic:

p1 : person[age->girlAge, sex->"F"],
p2 : person[age->girlAge+2, sex->"M"]

The JBoss Rules syntax uses Java-specific field manipulation that is
clearly not directly interoperable with the non-Java specific rule
systems. This is a clear disadvantage. However, the actual semantics
represented by a more complex syntax are directly amenable to model or
proof semantics of F-Logic.

There are two further considerations to this mapping: the use of
negation and the use of the Condition Elements (connectives) different
from conjunction.

Negation is denoted by the Condition Element "not" in front of a Column:

not Person(sex="F")

This simple form of negation can be assigned a trivial NAF semantics
using a simple database closed world assumption.

The issue of multiple connectives is not as obvious and probably should
be further investigated. One rule cannot be split into separate rules if
a disjunction is present due to the production rule evaluation that may
not make the resulting rule base equivalent.

Alex Kozlenkov

Advanced Technologies Group
Betfair Ltd.
+44 (0)20 88346854

Received on Tuesday, 1 August 2006 14:52:04 UTC