1. Object Oriented Rules and Inheritance Fabrício Teles & Marcos Aurélio, August 2006

2. Outline Purely Relational Rule Languages x Purely Object Oriented Languages Hybrid Object Oriented Rule Languages Inheritance Taxonomy Yang’s Inheritance Postulates CHORD: Extending CHR  with High-Order Object Oriented Constraints Case Study: Triangram

3. Knowledge Representation and Rule Based Languages Strong points – provides built-in FOL deduction with negation as failure the most powerful and versatile inference mechanism with formal semantics provides bases for implementation of other mechanisms like abduction, induction, planning, non-monotonic reasoning – uses rules that: are intuitive and modular preserve the truth (detachment) can be acquired by machine learning Weak points –non-intuitive codification of the terminological and procedural knowledge –poor facility to structure complex entities –limitations of the tools and methodologies of distributed development on a large scale –poor standardization –few non-AI computational services, libraries available for reuse –limited interoperability with other languages

4. Knowledge Representation and Rule Based Languages Rules often represent expert knowledge in a natural way (If...Then) Rules represent modular knowledge X Y = (   X)  Y =  Y = (   X)  Y = X

5. Knowledge Representation and Object Oriented Languages Strong points –intuitive codification of the terminological and procedural knowledge –facilities to structure complex entities –tools and methodologies of distributed development on a large scale consolidated and very spread out –API for the most varied computational services and languages –emphasis in the standardization, interoperability and reuse Weak points –no built-in general purpose inference machine –any mechanism of inference beyond inheritance must be implemented from scratch –codifies behaviors procedurally –no techniques to learn objects from data – neither complete nor standard declarative formal semantics

6. Hybrid Object Oriented Rule Languages Reasoning Requirements: Declarative Language Predicates with logical variables Automatic deduction Formal semantics Computational completeness OO Requirements: Object identity Complex Objects Classes Encapsulation Inheritance Overriding and Overloading Hybrid Rules + Objects

7. Rules and objects: how integrate? Rule Based Systems Rules Base f1(...,X,...) ...  fn(...,X,...)  f0(...,X,...) Fact Base f1(...,a,...) fn(...,a,...) f0(...,a,...) f1(...,b,...) fn(...,c,...) f0(...,d,...) Object Oriented Systems Classes Hierarchy Cn Ani: Cnq Mnj: {while... do... if... then... else... } Cp Api: Cpk Mpj: {while... do... if... then... else... } Cm Ami: Cmr Mmj: {while... do... if... then... else... } Object Base Opi Api: Opk Omj Ami: Omr Opmk Ami: Omr

8. Integrating rules with objects: syntactic alternatives Hybrid system = object oriented system in which : –procedural methods of the classes are substituted by encapsulated rules bases, or Hybrid system = rule based system in which –instances of logical terms in the facts base are substituted by: objects instances of a hierarchy of classes –logical terms in the premises and conclusions of the rules are substituted by: object patterns with logical variables in the place of: –object names and attribute values –possibly also name of classes and attributes

9. Substitute procedural methods by encapsulated rule bases Classes Hierarchy Cn Ani: Cnq Mnj: Cp Api: Cpk Mpj: Cm Ami: Cmr Mmj: fpj1(...,X,...) ...  fpjn(...,X,...)  fpn0(...,X,...) fnj1(...,X,...) ...  fnjn(...,X,...)  fnn0(...,X,...) fmj1(...,X,...) ...  fmjn(...,X,...)  fmn0(...,X,...) Object Base Opi Api: Opk Omj Ami: Omr Opmk Ami: Omr

10. Substitute fact base by object base Rules Base f1(...,X,...) ...  fn(...,X,...)  f0(...,X,...) Classes Hierarchy Cn Ani: Cnq Mnj: {while... do... if... then... else... } Cp Api: Cpk Mpj: {while... do... if... then... else... } Cm Ami: Cmr Mmj: {while... do... if... then... else... } Object Base Opi Api: Opk Omj Ami: Omr Opmk Ami: Omr

11. F-Logic Frame Logic is a deductive object oriented database language Syntactical integration between Object Oriented Paradigm and Rules Combines rules’ expressivity and declarative semantics with object oriented concepts. Implements Structural and Behavioral Inheritance with support for Single-source Multiple Inheritance Flora is an implementation for F-logic over XSB Prolog

12. Flora Metamodel FLP HLPGLPDLP STLPSTFLP Frame Logic Programming General Logic Programming Hilog Logic Programming Definite Logic Programming Sequential Transaction Frame Logic Programming Sequential Transaction Logic Programming

13. HiLog Metamodel closure(R)(X,Y) :- R(X,Y). closure(R)(X,Y) :- R(X,Z), closure(R)(Z,Y).

14. F-Logic Metamodel john : person, john[age -> 31], john[children ->> {bob,mary}] john : person[age -> 31, children ->> {bob,mary}]

15. F-Logic Metamodel john.age = 31, john..children = bob, john..children = mary

16. F-Logic Metamodel dog1 : dog. cat1 : cat. InstanceFAtom

17. F-Logic Metamodel dog :: mammal. mammal :: animal. SubCIassFAtom

18. F-Logic Metamodel dog[name => string]. cat[name *=> string]. dog[children =>> dog]. cat[children *=>> cat]. AttributeSignatureSpecification

19. F-Logic Metamodel dog[name -> “jerry”]. cat[name *-> “tom”]. dog[children ->> d1]. cat[children *->> c1]. AttributeValueSpecification

20. F-Logic Metamodel dog[getName()=> string]. cat[getName()*=> string]. dog[getChildren() =>> dog]. cat[getChildren() *=>> cat]. MethodSignatureSpecification

21. F-Logic Metamodel dog[getName()-> “tom”]. cat[getName()*-> “jerry”]. dog[getChildren()->> d1]. cat[getChildren()*->> c1]. MethodValueSpecification

22. F-Logic OO Concepts F-Logic X::Y X:Y C[M->V] C[M->>V] C[M=>V] C[M=>>V] C[M*->V] C[M*->>V] C[M*=>V] C[M*=>>V] Taxonomic F-Atom Signature Specification Value Specification Multiplicity: multiMultiplicity: single Inheritable Non-Inheritable

23. F-Logic Program Example with Rules X:irregularPolygon :- X:triangle[side->>{S1,S2}] and tnot(S1 = S2) and S1.length =\= S2.length. X[hypotenuse->Hypotenuse] :- X:triangle and X..triangleSide[position->base, side->Base] and X..triangleSide[position->left, side->Left] and X..triangleSide[position->right, side->Right] and if (Base.length > Left.length and Base.length > Right.length) then Hypotenuse = Base else if Left.length > Right.length then Hypotenuse = Left else Hypotenuse = Right. Triangram: Rule – Segment Adjacency S[adjacent->>X] :- X:segmentLine, X[adjacent->>S]. Triangram: Rules - Poligon Regularity

24. Inheritance Taxonomy (1/4) Structural Inheritance Behavioral Signatures ValuesCode *Non-monotonic reasoning in FLORA-2, Kifer, 2005 flower[petalColor  color]  mary : flower  mary[petalColor  color] engineer[salary(2009)*  5000]  john:engineer  john[salary(2009)  5000] code engineer[salary(X)*  V]:-V=X*2  john:engineer  john[salary(X)  V]:-V=X*2

25. Code Inheritance Example Rules R1 @ softDept[bonus()*->B] :- softDept[total*->T], B = T * 100. R2 @ code softDept[bonus1()*->B] :- softDept[total*->T], B = T * 100. Facts john : softDept softDept[total*->10]. john[total->30]. ?- john[bonus()->B]. B = 1000. ?- john[bonus1()->B]. B = 3000. john[bonus()->1000] john:softDeptsoftDept[bonus()*->1000] softDept[total*->10]R1 john[bonus()->3000] john[total->30]john[bonus1()->B] :- john[total->T], B=T*100. john : softDeptR2

26. Inheritance Taxonomy (2/4) Inheritance MonotonicNon-monotonic class1[att1*  color]  class2[att1*  tree]  class2::class1  obj:class2[att1  value]  value : color  value : tree class1[att1*  color]  class2[att1*  integer]  class2::class1  obj:class2  obj[att1  integer]

27. Inheritance Taxonomy (3/4) Inheritance SimpleMultiple Single SourceMultiple Source Source BasedValue Based flower[petalColor  color]  mary : flower  mary[petalColor  color] quaker[policy*  pacifist]  republican[policy*  hawk]  nixon : quaker  nixon : republican  nixon.policy = unknown quaker[policy*  pacifist]  republican[policy*  pacifist]  nixon : quaker  nixon : republican  nixon[policy*->pacifist] human[legs*  2]  police[hasGun*  true]  shaft:police  shaft:human  shaft[legs  2]  shaft[hasGun  true]

28. Inheritance Taxonomy (4/4) Inheritance w/ Overriding wo/ Overriding elephant[color*  gray]  royalElephant[color*  white]  royalElephant :: elephant  clyde : royalElephant  clyde[color  white] elephant[color*  gray]  royalElephant[color*  white]  royalElephant :: elephant  clyde : royalElephant  false elephant[color*  gray]  royalElephant[color*  white]  royalElephant :: elephant  clyde : royalElephant  clyde[color  white]  clyde[color  gray]  white = gray

29. Source x Value Based Multiple Inheritance Source-based: c2..m and c3..m cancel each other regardless of the set of values Value-based: c2..m and c3..m do not cancel each other when they return the same set of values (since there is no real conflict) c2 +m[0..*] = {x0,x1,...} c3 +m[0..*] = {y0,y1,...} c1

30. Inheritance and Negation Non-Monotonic Inheritance (NMI) is a form of default reasoning, Thus, in order to provide semantics and implement inheritance we can reuse another form of default reasoning: Negation As Failure (NAF) F-Logic programs inheritance semantics reuses General Logic Programs' Well-Founded Semantics for NAF Flora implements F-logic inheritance by reusing SLG resolution of XSB Prolog

31. Yang’s Postulates Embodies the common intuition behind non-monotonic multiple inheritance An object model for some F-logic program is an interpretation for every F-atom under a three-valued semantics

32. Main Concepts Inheritance Contexts c[m] is an inheritance context for o if o is a member of class c and m  v is locally defined at c for some value v Local context s[m] is a local context if is a fact or if it is derived through some rule Overriding the inheritance context s[m] overrides c[m] for o if c≠s and s::c Inheritance Candidates c[m] is an inheritance candidate for o if it is an inheritance context which is not overriden by any other inheritance context Inheritance Conflict An inheritance conflict occurs when there is more than one inheritance candidate for inheriting some field m to o

33. Main Concepts Each concept previously defined can be: –Strong Some concept is “strong” if all of its preconditions are true. –Weak Some concept is “weak” if some of its preconditions is undefined.

34. Example quaker[policy*  pacifist]  republican[policy*  hawk]  party[policy*->pacifist] quaker :: party  republican :: party nixon : quaker  nixon : republican ________________________________________________________ Inheritance Contexts: party[policy]-quaker party[policy]-republican party[policy]-nixon quaker[policy]-nixon republican[policy]-nixon Local Contexts: party[policy] quaker[policy] republican[policy] Overriding: quaker[policy] overrides party[policy] republican[policy] overrides party[policy] Inheritance Candidates: quaker[policy]-nixon republican[policy]-nixon Inheritance Conflict: quaker[policy]-nixon and republican[policy]-nixon

35. Translation Schema Transforms every FLP F into a GLP G such that: –WFS(G)  OptimisticObjectModel (F) Two parts: –Transformation rules, each one rewriting an FLP fragment into a corresponding GLP fragment –Trailer GLP rules, concatenated at the end of the transformation result

36. Translation Schema

37. Translation Schema – Trailer Rules

38. X:irregularPolygon :- X:triangle[side->>S1[length->L1], side->>S2[length->L12]], S1=\=S2, L1 =\= L2. isa(X,irregularPolygon) :- isa(X,triangle), mvd(X,side,S1), mvd(X,side,S2), fd(S1,length, L1), fd(S2, length, L2), S1=\=S2, L1=\=L2.

39. CHORD: Extending CHR  with High-Order Object Oriented Constraints

40. CHORD Metamodel

41. Reusing Yang’s Approach on CHORD Translate the initial set of CHORD rules into a set of CHR rules, transforming each F-atom in some special CHR predicate Attach some trailer rules implementing OO semantics

42. Current Implementation Current implementation supports only: –F-Atoms and conjunctive F-molecules –F-Atoms are only allowed as rule defined constraints

43. Trailer Rules Alter normal CHR execution: –insert inheritance steps between constraint simplification steps Normal CHR Constraint Simplification!

44. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates

45. Example GOAL: quaker[policy*  pacifist], republican[policy*  hawk, count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican

46. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates Applies user rules, as in CHR  There are no rules to fire CONSTRAINT STORE quaker[policy*  pacifist], republican[policy*  hawk], republican[count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican

47. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates Propagates class structures, i.e.: a::b, b::c  a::c CONSTRAINT STORE quaker[policy*  pacifist], republican[policy*  hawk], republican[count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : party

48. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates Calculate exhaustive list of inheritance candidates, without taking overriding into consideration CONSTRAINT STORE quaker[policy*  pacifist], republican[policy*  hawk], republican[count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : party candidate_ifd(nixon,republican,count) candidate_ifd(nixon,quaker,policy) candidate_ifd(nixon,republican,policy) candidate_ifd(nixon,party,policy) candidate_ifd(republican,party,policy) candidate_ifd(quaker,party,policy)

49. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates Removes overriden inheritance candidates CONSTRAINT STORE quaker[policy*  pacifist], republican[policy*  hawk], republican[count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : party candidate_ifd(nixon,republican,count) candidate_ifd(nixon,quaker,policy) candidate_ifd(nixon,republican,policy) candidate_ifd(nixon,party,policy) candidate_ifd(republican,party,policy) candidate_ifd(quaker,party,policy)

50. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates Removes inheritance Candidates causing multiple inheritance conflicts CONSTRAINT STORE quaker[policy*  pacifist], republican[policy*  hawk], republican[count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : party candidate_ifd(nixon,republican,count) candidate_ifd(nixon,quaker,policy) candidate_ifd(nixon,republican,policy)

51. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates Define remaining candidates as local Definitions CONSTRAINT STORE quaker[policy*  pacifist], republican[policy*  hawk], republican[count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : party nixon[count  7]

52. CHORD Runtime State Machine Constraint Simplification Propagate Class Structure Propagate Inheritance Candidates Process Overriding Block Multiple-source Inheritance Inherit Candidates Remove Candidates Remove remaining intermediate helper constraints CONSTRAINT STORE quaker[policy*  pacifist], republican[policy*  hawk], republican[count*  7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : party nixon[count  7]

53. CHORD Runtime State Machine Each state is associated to a sub-rule base associated with a part of the trailer Constraint Simplification state is associated to user rules and goal Since we can not control the order of the execution of the rules, we need some special strategy in order to implement state machines in CHR

54. Implementing State Machines in CHRD 1)Associate each state to an unique constraint name Deduction run_program(X) Propagate Class Structure class_structure() Propagate Inheritance Candidates propagate_candidates() Process Overriding overriding() Block Multiple-source Inheritance multiple_inheritance_blocking() Inherit Candidates inherit_candidates() Remove Candidates clean_mvd_candidates()

55. Implementing State Machines in CHRD 2) Attach to each rule head of each state rule base the constraint associated to the state X::Z, Z::Y ==> X  Y | X::Y. S::C, O:S ==> O:C. O:C, C[M*=>R] ==> O[M=>R]. Propagate Class Structure X::Z, Z::Y, class_structure() ==> X  Y | X::Y. S::C, O:S, class_structure() ==> O:C. O:C, C[M*=>R], class_structure() ==> O[M=>R].

56. Implementing State Machines in CHRD 3) For each state rule base, add an simplification rule to simulate state transitions (this rule should be the last one in state rule base) class_structure() propagate_candidates().

57. Implementing State Machines in CHRD X::Z, Z::Y, class_structure() ==> X  Y | X::Y. S::C, O:S, class_structure() ==> O:C. O:C, C[M*=>R], class_structure() ==> O[M=>R]. class_structure() propagate_candidates().

58. Case Study: Triangram

59. Case Study - Triangram Simplification of the known Chinese game, the Tangram Tangram –form complex figures using only 7 geometric 2D figures, without having overlapping between them –It considers only the following types of different parts: 5 isosceles triangles (2 small ones, 1 medium and 2 great ones) 1 square 1 parallelogram

60. Case Study - Triangram Exemplo: Tangram

61. Case Study - Triangram Triangram –Basic parts are only of a type: triangles –Uses three types of triangles

62. Case Study - Triangram Triangram –The objective is to form geometric figures from the basic types of triangles –It's only allowed to form a restricted number of types of figures: the straight hexagons, pentagons and the quadrilaterals

63. Case Study - Triangram UML/OCL –Representation of the world: convex polygons

64. Case Study - Triangram UML/OCL –Representation of the world: triangle

65. Case Study - Triangram Implementation –28 CHORD rules The largest one has 19 contraints on its head –About 125 constraints on goal –Average instances of the problem last about 1h to run

66. Case Study - Triangram Implementation –Goal Scenary being tested Class hierarchy Classes signatures –Rules Invariants Methods –Query  propagation rules with the F-Atom of the method in the body of the rule and pre-conditions in the head –Transactional  simpagation rules with pre-conditions in the head, removals in simplificateHead and pos-conditions in the body

67. Case Study - Triangram scaleneTriangle::triangle, isoscelesTriangle::triangle, equilateralTriangle::isoscelesTriangle,... CHORD Implementation - Goal main() true |... Class Hierarchy tri1 : equilateralTriangle [side ->> s11 [ adjacent ->> s12, adjacent ->> s13, length -> 3 ],... ],... Scenary being tested triangle[side *=>> segmentLine, triangleSide *=>> triangleSide, hypotenuse *=> segmentLine],... Class signatures

68. Case Study - Triangram... X:segmentLine[adjacent->>S] ==> true | S:segmentLine[adjacent->>X]. X:triangle, X[side->>S1], X[side->>S2], S1[length->L1], S2[length->L2] ==> ne(S1,S2), L1 = L2 | X:regularPolygon.... Invariants

69. Case Study - Triangram Query Methods... Pol1 : rectangle [ side ->> SidePol1[ length -> L, adjacent ->> A1[ length -> LA1 ] ], parts ->> P1, parts ->> P2 ], Pol2 : isoscelesTriangle [ triangleSide ->> TS1[ side -> SidePol2 [ length -> L, adjacent ->> A2 [length -> LA1 ] ], position -> base ] ] ==> ne(P1,Pol2), ne(P2,Pol2) | Pol1[isCompatible(Pol2, SidePol1, SidePol2)->void]....

70. Case Study - Triangram Transactional Methods... Pol11:triangle[isCompatible(Pol2, SidePol1, SidePol2)->void], Pol2 : triangle,...\ A11[adjacent ->> SidePol1], A12[adjacent ->> SidePol1], A21[adjacent ->> SidePol2], A22[adjacent ->> SidePol2] ==> A11 != A12, A21 != A22 | A11[adjacent ->> A22], A12[adjacent ->> A21], A21[adjacent ->> A12], A22[adjacent ->> A11], Pol3 : rectangle[side ->> {A11,A12,A21,A22}, parts ->> {Pol1,Pol2}],...