There is a need to be able to define facts in drl/rules themselves (deftemplates these are called in CLIPS and Jess). These are an alternative to "POJO" facts. We use the term "ontology" to describe this here (although it means more).

The idea is that as drools uses JVM class structures internally, that these ontologies should be converted, automatically, to "beans" in bytecode. The advantage of this is speed and efficiency, and making use of the JVM to its full extent. It also means that "POJOs" suitably constructed, can be used as facts as they are currently, without change.

Thus, from a users point of view, they can define fact models as POJOs and import them, or as an ontology in a drl (eg, using a GUI tool).

See: what is an ontology

In AI/SemWeb sense, there is a lot more to an ontology then we will need here, we will cherry pick the concepts and terminology we need.

Concepts/terminology

• Property: A property is a field, it can be defined in a class, or on its own (and reused)

• Facets: constraints placed on the value of a property

• Class: a record/concept definition, which is generally made up of Properties

• Atomic types: The lowest level types, String, int etc which will not be decomposed.

• Cardinality: a Property on a Class can be either single or multiple

ideas: Structure of a class

You can define a re-usable property:
Property age : int { min(0), max(150) }
 
Which can then be used in a class

Class Person {
    age
}
 
aliases are allowed
Class Person {
    someage : age
}
--------------
 
Or you could define an anonymous property, that is local to this class. 
Class Person {
    age : int { min(0), max(150) }
}
 
Constraints can be dynamic against data
Person postCode : char[] { postcode_filter( this ), from PostCode( code == this ) }
 
The above provides a char validation filter and then uses a 'from' statement to check
that it exists in the WM.
 

UNKNOWN (to resolve)

• Q: Should we have class inheritance?

• Q: Should we have class instances?

Generated beans

A suggestion for how this would work is to ASM generate beans. Facets will be added as attributes on properties.

A multiple cardinality field will be a List. Instances that are a member of a another instance, will automatically have a belongsTo property back to the containing bean instance - so you can navigate back up.