Object Oriented Rules and Inheritance

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. 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 Knowledge Representation and Rule Based Languages • 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. 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 Knowledge Representation and Object Oriented Languages • 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 OrientedRule Languages • OO Requirements: • Object identity • Complex Objects • Classes • Encapsulation • Inheritance • Overriding and Overloading • Reasoning Requirements: • Declarative Language • Predicates with logical variables • Automatic deduction • Formal semantics • Computational completeness Hybrid Rules + Objects

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

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. fpj1(...,X,...) ... fpjn(...,X,...)  fpn0(...,X,...) fnj1(...,X,...) ... fnjn(...,X,...)  fnn0(...,X,...) fmj1(...,X,...) ... fmjn(...,X,...)  fmn0(...,X,...) Cm Cn Cp Ani: Cnq Api: Cpk Ami: Cmr Opi Omj Opmk Mmj: Mnj: Mpj: Api: Opk Ami: Omr Ami: Omr Substitute procedural methodsby encapsulated rule bases Classes Hierarchy Object Base

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

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. STFLP STLP FLP GLP HLP DLP Flora Metamodel Sequential Transaction Frame Logic Programming Sequential Transaction Logic Programming Frame Logic Programming General Logic Programming Hilog Logic Programming Definite 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. InstanceFAtom dog1 : dog. cat1 : cat. F-Logic Metamodel

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

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

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

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

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

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

23. F-Logic Program Example with Rules Triangram: Rules - Poligon Regularity 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].

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

25. Facts softDept[total*->10] R1 john : softDept softDept[total*->10]. john[total->30]. john:softDept softDept[bonus()*->1000] john[bonus()->1000] john : softDept R2 john[total->30] john[bonus1()->B] :- john[total->T], B=T*100. john[bonus()->3000] 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. ?- john[bonus()->B].B = 1000. ?- john[bonus1()->B].B = 3000.

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

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

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

29. c3 c2 +m[0..*] = {y0,y1,...} +m[0..*] = {x0,x1,...} 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) 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 cand mvis 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. Inheritance Contexts: Local Contexts: Overriding: Inheritance Candidates: Inheritance Conflict: • party[policy]-quaker • party[policy]-republican • party[policy]-nixon • quaker[policy]-nixon • republican[policy]-nixon • party[policy] • quaker[policy] • republican[policy] • quaker[policy] • overrides party[policy] • republican[policy] • overrides party[policy] • quaker[policy]-nixon • republican[policy]-nixon • quaker[policy]-nixon and republican[policy]-nixon Example quaker[policy*pacifist]  republican[policy*hawk]  party[policy*->pacifist] quaker :: party  republican :: party nixon : quaker  nixon : republican ________________________________________________________

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 Process Overriding Constraint Simplification Remove Candidates Block Multiple-source Inheritance Propagate Class Structure Inherit Candidates Propagate Inheritance 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 STORE quaker[policy*pacifist], republican[policy*hawk], republican[count*7], party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican Process Overriding Constraint Simplification Remove Candidates Applies user rules, as in CHR There are no rules to fire Block Multiple-source Inheritance Propagate Class Structure Inherit Candidates Propagate Inheritance Candidates

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

48. CHORD Runtime State Machine 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) Process Overriding Constraint Simplification Remove Candidates Block Multiple-source Inheritance Propagate Class Structure Calculate exhaustive list of inheritance candidates, without taking overriding into consideration Inherit Candidates Propagate Inheritance Candidates

49. CHORD Runtime State Machine Removes overriden inheritance candidates Process Overriding Constraint Simplification Remove 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) Block Multiple-source Inheritance Propagate Class Structure Inherit Candidates Propagate Inheritance Candidates

50. CHORD Runtime State Machine Process Overriding Constraint Simplification Remove 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) Block Multiple-source Inheritance Propagate Class Structure Removes inheritance Candidates causing multiple inheritance conflicts Inherit Candidates Propagate Inheritance Candidates