Cascon2011_5_rules+owl

1,873 views
1,766 views

Published on

ONTORULE's fifth presentation at CASCON'11

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,873
On SlideShare
0
From Embeds
0
Number of Embeds
560
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cascon2011_5_rules+owl

  1. 1. ONTORULEGrounding business rules in OWL2 ontologies
  2. 2. Production rules and the RETE algorithm Skip
  3. 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. 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. 5. ExamplesA 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. 6. Production rule engine cycle1. Match and instantiate – Match rule conditions to facts/objects in the working memory – Instantiate rules whose conditions are satisfied2. Select – Apply conflict resolution strategy to select one instantiated rule for execution3. Execute – Execute actions instantiated from selected rule and update working memory – Check ending condition and loop back to step 1 is not satisfied
  7. 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. 8. The RETE AlgorithmeRootClass 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. 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. 10. IBM Websphere ILOG JRules Skip
  11. 11. ILOG Rule Languages
  12. 12. ILOG Rule LanguagesThe 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. 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. 14. Business Object Model
  15. 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. 16. ILOG Rule languages
  17. 17. Business action language (BAL) rule
  18. 18. Decision table
  19. 19. Decision tree
  20. 20. Technical rule
  21. 21. ILOG rule language (IRL)
  22. 22. IRL abstract grammar• action  := binding | insert | update | retract• insert := value• update := value• retract := value(Only minimal kernel presented here: working memory operations)
  23. 23. OWL2Skip
  24. 24. OverviewRich Logical Knowledge Descriptions Descriptions Axioms Class Expressions OWL2 Ontology Property Expressions Axioms AssertionsSimple 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. 25. Descriptions Axioms OWL2 Ontology AssertionsClassExpr ::= 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. 26. Descriptions Axioms OWL2 Ontology AssertionsClassAxiom ::= 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. 27. Descriptions Axioms OWL2 Ontology AssertionsAssertion ::= classAssertion(ClassExpr,Individual)| positivePropertyAssertion(PropExpr,Individual,Constant)| negativePropertyAssertion(PropExpr,Individual,Constant)| sameIndividual(Individual ...)| differentIndividuals(Individual,Individual ...)
  28. 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. 29. AxiomsDerived Knowledge is built by recursive application of Axioms on direct and derived KnowledgeExample The direct assertions do not initially say much about Marge wife(Homer,Marge) property wife { range Girl; => }; Girl(Marge)
  30. 30. Open World AssumptionExistence of Individuals is inferred according to the constraints accumulated along the reasoning pathExample The direct assertions do not initially say much about Apus 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. 31. Non-unique name assumptionIndividuals with different identifiers are not different by defaultExample 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. 32. InconsistencyIt is easy to introduce inconsistencies OWL2 Reasoning is complex OWL2 Ontologies contain many redundanciesBut it is impossible to reason on an inconsistent OntologyInconsistencies must be Statically Detected or Automatically FixedExample After a few drinks at Moes, Homer and MrBurns get married wife(Homer,MrBurns) property wife { range Girl; => }; Girl(MrBurns) Boy(MrBurns) => (Girl && Boy)(MrBurns) Boy <> Girl => Nothing(MrBurns)
  33. 33. LimitationsOnly 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) ErrorThats why Rules with more powerful conditions have to be added to Ontologies
  34. 34. Coupling production rules and OWL2 ontologies Problems and approaches
  35. 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. 36. Coupling Strategies Weak Coupling Tight Coupling OWL2 Ontology OWL2 Reasoner OWL2 OntologyQuery / Answer EngineCheck Rule Engine Rules Rules 36
  37. 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. 38. Coupling JRules and an OWL2 reasoner Weak coupling
  39. 39. Compile time OM-like Class OM-like Property Complex Axioms Axioms Axioms OWL2 Named NamedOntology Complex Descriptions Classes PropertiesObject OM Classes OM AttributesModel isa get add new get / set OO RETE Class Compiled Production Compiled Nodes Conditions Rule Nodes ActionsNetwork Legacy Conditions Production ActionsOO Rules Rules
  40. 40. Run time ReadOWL2 OWL2 Reasoner Axioms Direct Assertions isa query get query Write add class add / remove assertion property assertion Start HereObject OM Classes OM AttributesModel isa get get / set add new OO Class Compiled Production CompiledRETE Nodes Conditions Rule Nodes ActionsEngine Conflict Resolution
  41. 41. Authoring : OWL 2 BOM Mapping Classes Property Caracteristics OWL BOMOWL 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. 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. 43. Taking full advantage of RETE-based production rules and OWL2 Tight coupling
  44. 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 ActionsCombination Language action Compiled Compiled Logical body Compiled condition Production Rules Conditions Rules Rules Logical Production Rules Rules
  45. 45. Run time direct derivedOWL2 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 AssertionsEngine action Conflict Resolution body Compiled Compiled condition Compiled Logical Conditions Production Rules Rules
  46. 46. Assessment – Tight couplingRule Language + OWL2 Constructs are first class citizens of the Language + Compatible with OWL2 ad RIF-PRD Standards - No dedicated authoring Tool yetStatic Update Verification + Verified Assertion updates will never introduce an inconsistency that cannot be automatically fixed at runtimeStatic Type Checking in Actions + Cannot be broken Only Thing (the Top Class) is allowed to type Action VariablesRuntime Inconsistency Fixing Strategy The most recent Assertion is the right one + Now both direct and derived Assertions are fixedHowever 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. 47. Conclusion
  48. 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

×