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

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:


Cm

Ami: Cmr

Mmj:


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:


Cp

Api: Cpk

Mpj:


Cm

Ami: Cmr

Mmj:


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

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

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

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



PropagateClass

Structure


ProcessOverriding


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



PropagateClass

Structure


ProcessOverriding


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



PropagateClass

Structure


ProcessOverriding


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)



PropagateClass

Structure


ProcessOverriding


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)



PropagateClass

Structure


ProcessOverriding


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)



PropagateClass

Structure


ProcessOverriding


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]



PropagateClass

Structure


ProcessOverriding


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]


• 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()


propagate_candidates()

ProcessOverriding

overriding()


Inheritance

multiple_inheritance_blocking()

InheritCandidates

inherit_candidates()

RemoveCandidates

clean_mvd_candidates()


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].


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().


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


• Exemplo: Tangram


• Triangram– Basic parts are only of a type: triangles– Uses three types of triangles


• 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


• UML/OCL– Representation of the world: convex polygons


• UML/OCL– Representation of the world: triangle


• 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


• 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


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


...

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


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].

...


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}],

...

Date post:	21-Dec-2015
Category:	Documents
View:	219 times
Download:	0 times

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

Documents