View
42
Download
0
Category
Tags:
Preview:
DESCRIPTION
Object Oriented Rules and Inheritance. Fabrício Teles & Marcos Aurélio, August 2006. Outline. Purely Relational Rule Languages x Purely Object Oriented Languages Hybrid Object Oriented Rule Languages Inheritance Taxonomy Yang’s Inheritance Postulates - PowerPoint PPT Presentation
Citation preview
Object Oriented Rules and Inheritance
Fabrício Teles & Marcos Aurélio, August 2006
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
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
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
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
Hybrid Object OrientedRule Languages
Reasoning Requirements:Reasoning Requirements:• Declarative Language• Predicates with logical variables• Automatic deduction • Formal semantics • Computational completeness
OO Requirements:OO Requirements:• Object identity• Complex Objects• Classes • Encapsulation• Inheritance • Overriding and Overloading
Hybrid Rules + ObjectsHybrid Rules + Objects
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
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
Substitute procedural methodsby 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
Substitutefact base byobject 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
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
Flora Metamodel
FLP
HLPGLP
DLP
STLP
STFLPFrame Logic Programming
General Logic Programming
Hilog Logic Programming
Definite Logic Programming
Sequential Transaction Frame Logic Programming
Sequential Transaction Logic Programming
HiLog Metamodel
closure(R)(X,Y) :- R(X,Y).closure(R)(X,Y) :- R(X,Z), closure(R)(Z,Y).
F-Logic Metamodel
john : person, john[age -> 31], john[children ->> {bob,mary}]
john : person[age -> 31, children ->> {bob,mary}]
F-Logic Metamodel
john.age = 31, john..children = bob, john..children = mary
F-Logic Metamodel
dog1 : dog.cat1 : cat.
InstanceFAtom
F-Logic Metamodel
dog :: mammal.mammal :: animal.
SubCIassFAtom
F-Logic Metamodel
dog[name => string].cat[name *=> string].dog[children =>> dog].cat[children *=>> cat].
AttributeSignatureSpecification
F-Logic Metamodel
dog[name -> “jerry”].cat[name *-> “tom”].dog[children ->> d1].cat[children *->> c1].
AttributeValueSpecification
F-Logic Metamodel
dog[getName()=> string].cat[getName()*=> string].dog[getChildren() =>> dog].cat[getChildren() *=>> cat].
MethodSignatureSpecification
F-Logic Metamodel
dog[getName()-> “tom”].cat[getName()*-> “jerry”].dog[getChildren()->> d1].cat[getChildren()*->> c1].
MethodValueSpecification
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
SignatureSpecification
ValueSpecification
Multiplicity: multi
Multiplicity: single
Inheritable
Non-Inheritable
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
Inheritance Taxonomy (1/4)
Structural
Inheritance
Behavioral
Signatures Values Code
*Non-monotonic reasoning in FLORA-2, Kifer, 2005
flower[petalColorcolor] mary : flowermary[petalColorcolor]
engineer[salary(2009)*5000] john:engineerjohn[salary(2009)5000]
code engineer[salary(X)*V]:-V=X*2 john:engineer john[salary(X)V]:-V=X*2
Code Inheritance Example• RulesR1 @ softDept[bonus()*->B] :- softDept[total*->T], B = T * 100.R2 @ code softDept[bonus1()*->B] :- softDept[total*->T], B = T * 100.
• Factsjohn : softDeptsoftDept[total*->10].john[total->30].
?- john[bonus()->B].B = 1000.
?- john[bonus1()->B].B = 3000.
john[bonus()->1000]
john:softDept softDept[bonus()*->1000]
softDept[total*->10] R1
john[bonus()->3000]
john[total->30] john[bonus1()->B] :- john[total->T], B=T*100.
john : softDept R2
Inheritance Taxonomy (2/4)
Inheritance
Monotonic Non-monotonic
class1[att1*color] class2[att1*tree] class2::class1 obj:class2[att1value]value : color value : tree
class1[att1*color] class2[att1*integer] class2::class1 obj:class2obj[att1integer]
Inheritance Taxonomy (3/4)
Inheritance
Simple Multiple
Single Source Multiple Source
Source Based Value Based
flower[petalColorcolor] mary : flowermary[petalColorcolor]
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:humanshaft[legs2] shaft[hasGuntrue]
Inheritance Taxonomy (4/4)
Inheritance
w/Overriding
wo/Overriding
elephant[color*gray] royalElephant[color*white] royalElephant :: elephant clyde : royalElephantclyde[colorwhite]
elephant[color*gray] royalElephant[color*white] royalElephant :: elephant clyde : royalElephant false
elephant[color*gray] royalElephant[color*white] royalElephant :: elephant clyde : royalElephantclyde[colorwhite] clyde[colorgray] white = gray
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
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
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
Main Concepts
• Inheritance Contextsc[m] is an inheritance context for o if o is a member of class c
and mv is locally defined at c for some value v
• Local contexts[m] is a local context if is a fact or if it is derived through some rule
• Overridingthe inheritance context s[m] overrides c[m] for o if c≠s and s::c
• Inheritance Candidatesc[m] is an inheritance candidate for o if it is an inheritance context
which is not overriden by any other inheritance context
• Inheritance ConflictAn inheritance conflict occurs when there is more than one
inheritance candidate for inheriting some field m to o
Main Concepts
• Each concept previously defined can be:– Strong
Some concept is “strong” if all of its preconditions are true.
– WeakSome concept is “weak” if some of its preconditions
is undefined.
Example
quaker[policy*pacifist] republican[policy*hawk] party[policy*->pacifist]
quaker :: party republican :: partynixon : 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
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
Translation Schema
Translation Schema – Trailer Rules
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.
CHORD:Extending CHR with High-Order
Object Oriented Constraints
CHORD Metamodel
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
Current Implementation
• Current implementation supports only:– F-Atoms and conjunctive F-molecules – F-Atoms are only allowed as rule defined
constraints
Trailer Rules
• Alter normal CHR execution:– insert inheritance steps between constraint
simplification stepsNormalCHR
ConstraintSimplification!
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
Example
GOAL: quaker[policy*pacifist], republican[policy*hawk, count*7],
party[policy*->pacifist], quaker :: party, republican :: party, nixon : quaker, nixon : republican
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
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
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
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
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
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)
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
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 : partycandidate_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)
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
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 : partycandidate_ifd(nixon,republican,count)candidate_ifd(nixon,quaker,policy)candidate_ifd(nixon,republican,policy)
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
Define remaining candidates as localDefinitions
CONSTRAINT STORE
quaker[policy*pacifist], republican[policy*hawk], republican[count*7], party[policy*->pacifist],quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : partynixon[count7]
CHORD Runtime State Machine
Constraint Simplification
PropagateClass
Structure
PropagateInheritanceCandidates
ProcessOverriding
BlockMultiple-source
Inheritance
InheritCandidates
RemoveCandidates
Remove remaining intermediate helperconstraints
CONSTRAINT STORE
quaker[policy*pacifist], republican[policy*hawk], republican[count*7], party[policy*->pacifist],quaker :: party, republican :: party, nixon : quaker, nixon : republican nixon : partynixon[count7]
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
Implementing State Machines in CHRD
1) Associate each state to an unique constraint name
Deduction run_program(X)
PropagateClass
Structureclass_structure()
PropagateInheritanceCandidates
propagate_candidates()
ProcessOverriding
overriding()
BlockMultiple-source
Inheritance
multiple_inheritance_blocking()
InheritCandidates
inherit_candidates()
RemoveCandidates
clean_mvd_candidates()
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].
PropagateClass
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].
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().
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().
Case Study: Triangram
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
Case Study - Triangram
• Exemplo: Tangram
Case Study - Triangram
• Triangram– Basic parts are only of a type: triangles– Uses three types of triangles
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
Case Study - Triangram
• UML/OCL– Representation of the world: convex polygons
Case Study - Triangram
• UML/OCL– Representation of the world: triangle
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
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
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
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
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].
...
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}],
...
Recommended