RE: production rule object creation actions and frame axioms

Gary: continued discussion below:
Cheers
Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Gary Hallmark
> Sent: 12 August 2008 20:26
> To: RIF WG
> Subject: production rule object creation actions and frame axioms
> 
> 
> This is a discussion related to ACTION-554
> <http://www.w3.org/2005/rules/wg/track/actions/554> and ACTION-555
> <http://www.w3.org/2005/rules/wg/track/actions/555>.
> 
> Many production rule languages have a Java-like notion of object.
E.g.
> Jess and CLIPS have slotted facts.  Jess, OBR, Ilog, and others have
> Javabeans.  Like RIF frames, these objects have
> 
>     * classification,
>     * named slots, and
>     * object identity.
> 
> Unlike RIF frames, with typical PRD objects,
> 
>     * classification is externally defined -- you can't have a rule
>       "forall ?e (?e # Employee :- exists ?i (?e[empNo->?i))"
[PV>] Clarification: classification by class hierarchy is externally
defined (for example in the Java class or XSD). However, I can always
have a "classification property" as a text field in a class. Of course,
I lose inheritance etc if I do that, and in practice I will normally be
using the same fixed object model for source and destination anyway...

>     * the cardinality of object:slot is 1:1 -- forall ?o ?x ?v1 ?v2
>       (?v1=?v2 :- ?o[?x->?v1 ?x->?v2])
[PV>] Surely a "slot" refers to a frame.attribute (or object.property)
pair? Objects can have multiple properties so I would expect the
cardinality of object:slot to be n:1 - a slot is associated with only a
single object, but an object can have associated with it multiple slots
(o.p1, o.p2, ...). 
 
>     * a datamodel (typically not expressed in rules) associates slots
>       with the class, e.g.
>       forall ?o (exists ?s ?i (And(?o[salary->?s empNo->?i]
>       ?s#xs:decimal ?i#xs:string)) :- ?o#Employee)
[PV>] That wording gave me a problem too - data models don't define
slots per se, but data and attribute relationships that are the
equivalent of slots. But maybe I'm being too pedantic! 

> 
> In PRD WD1, there are 2 actions w.r.t. frame formulas:
> 
>    1. assert, e.g. ?e[salary->200000] :- ?e#Employee -- the salary of
>       every employee is 200000
>    2. retract, e.g. Retract(?e[salary->?s]) :- And(?e#Employee
>       ?e[salary->?s]) -- no employee has a salary
> 
> There is no way in PRD WD1 to create a new Employee instance in order
to
> assert information (slots) about it.  Nor is it possible to remove an
> Employee instance (even though one may remove all its slots --
probably
> a violation of the datamodel).  Also note that in most PR systems, it
is
> not possible to retract individual slots.  You can only retract the
> entire object: all of its slots and its classification.
[PV>] Isn't this the requirement for an "external"? In other words I
invoke the (external) constructor for the associated class? Possibly I
can also handle "slot removal" through assignment to "null", although
that might make the logicians squirm a bit...

> 
> One could use existential quantification in the conclusion to express
> object creation:
> 
> exists ?e And(?e#Employee ?e[empNo->?ssn salary->50000]) :-
> And(?p#Person ?p[ssn->?ssn college->"MIT"])
> 
> Because we would like to share the same solution with BLD, we
skolemize
> (using "f") the above to
> 
> And(?e#Employee ?e[empNo->?ssn salary->50000]) :- And(?p#Person
> ?p[ssn->?ssn college->"MIT"] ?e=f(?p ?ssn))
> 
> We can limit PRD's use of logical functions to skolem functions.
> 
> To support removing an object, we need to be able to retract its
> classification as well as remove its slots:
> 
> Forall ?e ?sn ?sv (Do(Retract(?e#Employeee) Retract(?e[?sn->?sv]) ) :-
> ?e#Employee
> 
> Because the semantics of frames differs from the more typical
Javabeans,
> as mentioned above, we need to account for this difference.  E.g.
> consider the following rule set:
> 
> Joe#Employee
> Joe[salary->40000]
> ?e[salary->?salary * 1.1] :- And(?e#Employee ?e[salary->?salary]
?salary
> < 48000)
> 
> With frame semantics, a model is Joe[salary->40000 salary->44000
> salary->48400].  With Javabean/PRD semantics, we must have a final
> configuration with only Joe[salary->48400] (or maybe
Joe[salary->44000]
> ??)
[PV>] Of course, that is a pretty ambiguous rule from a production rule
perspective. For example, the rule engine may only "execute" the
following (and PRD source rule, I hope) rule once, as the state of the
condition does not change after the 1st rule execution. 

If 
	?e is some Employee
	?e.salary < 48000
Then
	?e.salary = ?e.salary * 1.1

> 
> One way to account for the difference is to use rules, aka frame
axioms,
> like
> forall ?o ?x ?v1 ?v2 (?v1=?v2 :- ?o[?x->?v1 ?x->?v2])
> forall ?o (exists ?s ?i (And(?o[salary->?s empNo->?i] ?s#xs:decimal
> ?i#xs:string)) :- ?o#Employee)
> 
> The first rule (1:1 object:slot cardinality) uses equality in the
head.
> The second rule (datamodel) uses an existential in the head, which is
> not legal in BLD, and would need to be skolemized.
> 
> Some may object to using rules to express these frame axioms.  Special
> syntax may indeed be easier to understand and to implement in PRD
> systems that don't have a logic rule engine.  We could add the
following
> syntax
> 
> FrameType ::= 'Class' TYPENAME '(' SlotType* ')'
> SlotType ::= ['set'] TYPENAME SLOTNAME [= Expr] ';'
> TYPENAME ::= Const
> SLOTNAME ::= Const
> 
> e.g.
> 
> Class Employee (
>   xs:string empNo = "";
>   xs:decimal salary = 0;
> )
> Note the optional keyword 'set' means that slot can occur more than
once
> and the optional default value expression means that slot occurs at
> least once.  So "empNo" and "salary" occur exactly once.
> 
> Similarly, some may object to the rather verbose syntax for object
> creation and prefer
> 
> new Employee[empNo->?ssn salary->50000]) :- And(?p#Person ?p[ssn->?ssn
> college->"MIT"])
> 
> instead of
> 
> And(?e#Employee ?e[empNo->?ssn salary->50000]) :- And(?p#Person
> ?p[ssn->?ssn college->"MIT"] ?e=f(?p ?ssn))
> 
> and also prefer
> 
> Forall ?e (Retract(?e)  :- ?e#Employee)
> 
> instead of
> 
> Forall ?e ?sn ?sv (Do(Retract(?e#Employee) Retract(?e[?sn->?sv]) ) :-
> ?e#Employee)
> 
> Note that it is important to add the sugared "new" and "Class"
> constructs to BLD and to PRD, so that the intersection ("core") is as
> large as possible to promote interoperability.  Rather than add the
> sugar to PRD only and thus not be able to interoperate with BLD, I
would
> resist the sugar and make PRD translators figure out the frame axioms
> expressed as rules.
[PV>] I would also prefer the latter if the target platform (BLD, PRD)
semantics were the same (...but of course, they are not).  

> 
> Some may suggest that instead of expressing frame axioms using rules
or
> the proposed Class construct, that we could reuse Owl.  That's fine,
> this note is supposed to provoke discussion...make a proposal :-)
[PV>] I'll have to think about that!

Received on Tuesday, 12 August 2008 21:07:19 UTC