ONTORULE's fifth presentation at CASCON'11

1. ONTORULE
Grounding business rules in OWL2
ontologies

2. Production rules and the RETE
algorithm
Skip

3. What are Business Rules?
• “Business Rules” is an ambiguous term
– Business Rules are a kind of requirement or a definition of business
behavior
– Business Rules are a declarative approach to system behavior
• Source (Business) Rules
– Definitions of business behavior
– Part of the CIM (computer independent model)
• Production (Business) Rules
– Definitions of system behavior
– Part of the PIM (platform independent model)

4. Production rules
• Condition-action rules
– If <condition> then do <actions>
• Behaviour
– Operational semantics
• Mostly RETE-based
• Intrinsically non-monotonic
– 90+ % of the BRMS market
• As opposed to logical rules
– If <condition> then <condition>
• Axiom, definition
– Model theoretic semantics
• Usually monotonic
– Computational logics and logic programming
• E.g. OWL2 and Prolog

5. Examples
A customer who has purchased for over $1000 in the past three months, reaches status: gold
Forall ?c such that ?c # Customer
If Exists ?v1 ?v2 ?v3 (And (QuarterMonthlyPurchase(?c ?v1 ?v2 ?v3)
func:numeric-greater-than(func:numeric-add(?v1 ?v2 ?v3) 1000)
Then Modify(?c[status -> "Gold" ])
If customer cart contains CD-player and no CD, then advertise CDs on sidebar, based on
customer’s musical preferences
Forall ?c such that ?c # Customer
Forall ?s ?iList such that And(?s # ShoppingCart ?c[shoppingCart -> ?s] ?s[items -> ?iList])
If And (Exists ?cd-p (And ?cd-p # CD-Player pred:list-contains(?cd-p ?iList))
Not (Exists ?cd (And ?cd # CD pred:list-contains(?cd ?iList))))
Then Do ((?pref ?c[preferences ->?pref])(?pref-music ?pref[musical -> ?pref-music))
Execute(act:print(my:prepareAdvertisement(?pref-music))))
The brother of a parent is an uncle
Uncle(?x, ?z) :- Brother(?x, ?z) and Parent(?z, ?y)
The spouse of one’s spouse is oneself
?x = ?z :- ?x [spouse -> ?y] and ?y [spouse -> ?z] then

6. Production rule engine cycle
1. Match and instantiate
– Match rule conditions to facts/objects in the working
memory
– Instantiate rules whose conditions are satisfied
2. Select
– Apply conflict resolution strategy to select one
instantiated rule for execution
3. Execute
– Execute actions instantiated from selected rule and
update working memory
– Check ending condition and loop back to step 1 is not
satisfied

7. The RETE Algorithme
• Efficient many patterns-many objects matching
– Charles Forgy 1982
• Rule conditions are compiled in a network (latin: «
rete ») of atomic patterns and joins
– Tokens corresponding to every objects/facts in the
working memory are sent through the network and and
kept there until the object/fact is retracted
⇒ Each object/fact is tested only once against each pattern

8. The RETE Algorithme
Root
Class or fact type tests ... ...
Discrimination trees ... ...
(intr-object/fact tests)
Alpha nodes ... ...
(single objects/facts)
Join nodes
(inter-objects/facts tests)
Beta nodes
(tuples)
...
Rule instances
(tuples that satisfy a rule’s condition)

9. Example
If { A (a1==3; ?x:a2); B (b1==2; ?y:b2; b3==?x); C (c1==?y); } then {do something }
Working memory:
A( a1=3 a2=10 )
B( b1=2 b2=4 b3=10 )
B( b1=2 b2=7 b3=10 )
C( c1=4 )

10. IBM Websphere ILOG JRules
Skip

11. ILOG Rule Languages

12. ILOG Rule Languages
The vocabulary is the set of terms and phrases
attached to the elements of the Business
Object Model (BOM). Vocabulary elements
appear in the drop-down lists of business rule
editors.

13. ILOG BOM contains the classes and methods that
A
Rule Languages
rule artifacts act on. As an object model, the BOM
is very similar to a Java object model. It consists
of classes grouped into packages. Each class has
a set of attributes, methods, and possibly other
nested classes.

14. Business Object Model

15. Studio: Modularity and Re-use
• Business Object Model is decoupled from
Implementation
Business Vocabulary 1 Business Vocabulary 2
Business Object Model
BOM2XOM 1 BOM2XOM 2
Execution Object Model 1 Execution Object Model 2

16. ILOG Rule languages

17. Business action language (BAL) rule

18. Decision table

19. Decision tree

20. Technical rule

21. ILOG rule language (IRL)

22. IRL abstract grammar
• action := binding | insert | update | retract
• insert := value
• update := value
• retract := value
(Only minimal kernel presented here: working memory operations)

23. OWL2
Skip

24. Overview
Rich Logical Knowledge Descriptions Descriptions Axioms
Class Expressions
OWL2 Ontology
Property Expressions
Axioms Assertions
Simple Runtime Model
Assertions about Constants
Class
Constant ::= Individual | Literal Axiom
Class Class
Expr Expr
Individuals may belong to many Classes
Class or
Properties are Relations by default Property
Non Unique Name Assumption (UNA) Axiom
Open World Assumption (OWA)
Object
Literal individual individual
Data Property Expr
(DataRange)
Property Expr
Property
Axiom Individual
Axiom
Object
Property Property Expr
Axiom individual

25. Descriptions Axioms
OWL2 Ontology
Assertions
ClassExpr ::= DataRange ::=
Class Name Datatype Name
| oneOf(Individual ...) | oneOf(Literal ...)
| unionOf(ClassExpr,ClassExpr) | unionOf(DataRange,DataRange)
| intersectionOf(ClassExpr,ClassExpr) | intersectionOf(DataRange,DataRange)
| complementOf(ClassExpr) | complementOf(DataRange)
| allValuesFrom(PropExpr, ClassExpr | restriction(DataRange,
| DataRange) ( ConstrainingFacet
| someValuesFrom(PropExpr, ClassExpr Literal ) ...)
| DataRange)
| cardRestriction((<= | >= | =) nonNegInt ,
PropExpr) ConstrainingFacet ::=
| hasValue(PropExpr,Constant) Constraint Name
// XSD: minValue,maxValue...
PropExpr ::=
Property Name
| propertyChain(PropExpr ...)
| inverseOf(PropExpr)

26. Descriptions Axioms
OWL2 Ontology
Assertions
ClassAxiom ::= PropertyAxiom ::=
equivalentClasses(ClassExpr,ClassExpr) equivalentProperties(PropExpr,PropExpr)
| subClassOf(ClassExpr,ClassExpr) | subPropertyOf(PropExpr,PropExpr)
| disjointClasses(ClassExpr ...) | domain(PropExpr,ClassExpr)
| disjointUnion(ClassExpr,ClassExpr ...) | range(PropExpr, ClassExpr
| hasKey(ClassExpr,PropExpr ...) | DataRange)
| reflexive(PropExpr)
| irreflexive(PropExpr)
| symmetric(PropExpr)
| asymmetric(PropExpr)
| transitive(PropExpr)
| functional(PropExpr)
| inverseFunctional(PropExpr)

27. Descriptions Axioms
OWL2 Ontology
Assertions
Assertion ::=
classAssertion(ClassExpr,Individual)
| positivePropertyAssertion(PropExpr,Individual,Constant)
| negativePropertyAssertion(PropExpr,Individual,Constant)
| sameIndividual(Individual ...)
| differentIndividuals(Individual,Individual ...)

28. A small ontology of the Simpsons
// Descriptions and Axioms: // Assertions:
class Person; Girl(Maggie);
class Girl << Person;
Girl(Lisa);
class Boy << Person;
class Girl <> Boy; Boy(Bart);
class Parent == some(child,>=1); Boy(Homer);
class OneChildParent == some(child,=1); Boy(MrBurns);
property child { Boy(Apu);
domain Person;
Parent(Apu);
range Person;
}; child(Marge,Maggie);
property wife { child(Marge,Lisa);
domain Boy; child(Marge,Bart);
range Girl;
wife(Homer,Marge);
};
property cash { cash(Homer,12);
functional; cash(MrBurns,3500000000);
domain Person;
range integer ! (>= 0);
};

29. Axioms
Derived Knowledge is built by recursive application of Axioms on direct and derived
Knowledge
Example
The direct assertions do not initially say much about Marge
wife(Homer,Marge)
property wife {
range Girl; =>
}; Girl(Marge)

30. Open World Assumption
Existence of Individuals is inferred according to the constraints accumulated
along the reasoning path
Example
The direct assertions do not initially say much about Apu's children
Parent(Apu)
class Parent == some(child,>=1); <=>
(some(child,>=1))(Apu)
=>
child(Apu,new1) // there exists at least
// one child even if
// not directly mentioned

31. Non-unique name assumption
Individuals with different identifiers are not different by default
Example
Bart fills an administrative form and asserts that Marge has only one child
OneChildParent(Marge)
class OneChildParent == some(child,=1); <=>
(some(child,=1))(Marge)
child(Marge,Maggie);
child(Marge,Lisa); =>
child(Marge,Bart); sameIndividual(Maggie,Lisa,Bart)

32. Inconsistency
It is easy to introduce inconsistencies
OWL2 Reasoning is complex
OWL2 Ontologies contain many redundancies
But it is impossible to reason on an inconsistent Ontology
Inconsistencies must be Statically Detected or Automatically Fixed
Example
After a few drinks at Moe's, Homer and MrBurns get married
wife(Homer,MrBurns)
property wife {
range Girl; =>
}; Girl(MrBurns)
Boy(MrBurns) =>
(Girl && Boy)(MrBurns)
Boy <> Girl =>
Nothing(MrBurns)

33. Limitations
Only predicates, arity <= 2 are supported
BoyProfile(b,10,“Bart”,Sk8)
(Boy && has(age,10) && has(name,“Bart”) && has(vehicle,Sk8))(b)
Restriction values can only be constants, not variables
some(child,<= ?x) ! Boy Error
some(cash) ! integer!(>= ?y) Error
That's why Rules with more powerful conditions have to be added to
Ontologies

34. Coupling production rules and
OWL2 ontologies
Problems and approaches

35. Production rules VS OWL2
• Objects VS assertions about objects
– Static typing VS dynamic classification
– Unique Name Assumption VS not UNA
• Explicit facts VS axioms
– Axioms may make it difficult to detect inconsistencies
• Closed VS Open World Assumption
• Variables VS constants only
• Update VS query only
– Updating may introduce inconsistencies
⇒ Need Inconsistency Fixing Strategy
– Detect and fix inconsistent Updates at compile time
– Automatically fix inconsistent Updates at runtime

36. Coupling Strategies
Weak Coupling Tight Coupling
OWL2 Ontology
OWL2 Reasoner OWL2 Ontology
Query / Answer Engine
Check
Rule Engine Rules
Rules
36

37. Assumptions
• The OWL2 Ontology is initially consistent
• The Production Rules do not modify the
Descriptions of the OWL2 Ontology (the T-
Box)
• The Production Rules
– match the direct and the derived assertions of the
OWL2 Ontology
– update the direct assertions of the OWL2
Ontology (the A-Box is the Working Memory)

38. Coupling JRules and an OWL2
reasoner
Weak coupling

39. Compile time
OM-like Class OM-like Property Complex Axioms
Axioms Axioms
OWL2
Named Named
Ontology Complex Descriptions
Classes Properties
Object OM Classes OM Attributes
Model
isa get add new get / set
OO
RETE Class Compiled Production Compiled
Nodes Conditions Rule Nodes Actions
Network
Legacy Conditions
Production
Actions
OO Rules Rules

40. Run time
Read
OWL2 OWL2 Reasoner Axioms
Direct
Assertions isa query get query
Write
add class add / remove
assertion property assertion
Start
Here
Object OM Classes OM Attributes
Model
isa get get / set
add new
OO Class Compiled Production Compiled
RETE Nodes Conditions Rule Nodes Actions
Engine
Conflict
Resolution

41. Authoring : OWL 2 BOM Mapping
Classes Property Caracteristics
OWL BOM
OWL BOM P(A,B) Class A{ B P; }
P' subPropertyOf P Class A{ B P;
Class A Class A B P' ;
P'' equivalentProperty P
B P''; }
B subClassOf A Class B extends A P transitiveProperty Class A{
A P;
C = intersectionOf (A,B) Class C extends A,B P' symetricProperty
A P';}
A extends C P' inverseOf P Class B{
C = unionOf (A,B) A P'; }
B extends C
P functionalProperty
Class A{ B P; }
P inverseFunctionalProperty

42. •
Assessment – OWL plug-in
Ontology reasoning Capabilities
– Depend on the plugged OWL2 Reasoner
• Rule Language
– + Compliant with legacy authoring and maintenance Tools
– - No complex OWL2 Class Expressions
– - No complex OWL2 Property Expressions
– - No update of Individual Classes
– - No update of Individual identity Assertions
• Static Update Verification
– Not implemented
– Consistency Checking can be delegated to OWL2 Reasoner
• Static Type Checking in Actions
– Can be broken, updating Attributes can change the Classes of
Individuals
• Inconsistency Fixing Strategy
– Experiments using OWL2 Reasoner to identify inconsistent Assertions
going on

43. Taking full advantage of RETE-based
production rules and OWL2
Tight coupling

44. Compile time
OWL2 Property and Class Property and Class
Expressions Axioms
Ontology
Compiled Compiled Compiled
Predicates Predicate Axioms
Expression New
head
Compiled
Rules +
Tight add / remove Ontology
Assertions Actions
Combination Language
action
Compiled Compiled
Logical body Compiled condition Production
Rules Conditions Rules
Rules Logical Production
Rules Rules

45. Run time direct
derived
OWL2 Direct
classic
Assertions
Start forward
Here Export
Import
New Toplevel
Assertions Compiled Compiled
Compiled
Predicates Predicate Axioms
Query the Expressions
Extension
head add / remove Compiled
Tight Actions
Assertions
Engine action Conflict
Resolution
body
Compiled Compiled condition
Compiled
Logical Conditions Production
Rules
Rules

46. Assessment – Tight coupling
Rule Language
+ OWL2 Constructs are first class citizens of the Language
+ Compatible with OWL2 ad RIF-PRD Standards
- No dedicated authoring Tool yet
Static Update Verification
+ Verified Assertion updates will never introduce an inconsistency that cannot be
automatically fixed at runtime
Static Type Checking in Actions
+ Cannot be broken
Only Thing (the Top Class) is allowed to type Action Variables
Runtime Inconsistency Fixing Strategy
The most recent Assertion is the right one
+ Now both direct and derived Assertions are fixed
However
Tight is an extension of the Production Rule Technology, not a Logic Engine
- Only a subset of OWL2 is supported (+/- OWL2RL, CWA,UNA)
Compile time Error Messages are available to warn about Limitations

47. Conclusion

48. Assessment – weak VS tight
coupling
• OWL2 is not an Object Model
– It is a Logic, Knowledge is available as Facts, not as complex Terms
(Objects)
• The Weakly Coupled Approaches are limited
– Not incremental Query interface of the OWL2 Reasoner
– Performance of the OWL2 Reasoner
• The Tightly Coupled Approach is promising but getting
Production Rules and OWL2 Ontology to work together
requires tradeoffs
– By extending a Production Rule Technology, we add Update but only
with a subset of OWL2 Logic
– Extending a (Constraint) Logic Programming Technology would give us
the full power OWL2 Logic but Update is unlikely