W3C home > Mailing lists > Public > public-rif-wg@w3.org > August 2008

lmost all RE: production rule object creation actions and frame axioms

From: Patrick Albert <palbert@ilog.fr>
Date: Wed, 13 Aug 2008 16:02:44 +0200
Message-ID: <4412C4FCD640F84794C7CF0A2FE890D2F191B1@parmbx02.ilog.biz>
To: "Gary Hallmark" <gary.hallmark@oracle.com>, "RIF WG" <public-rif-wg@w3.org>

Hi All, 

Two comments about the current discussion.

1/ About creation and suppression.

Most Production rules systems support the suppression of objects and the creation and initialization of new objects of a given class, so PRD must support this basic (and procedural) feature. 

I would not support the use of existential quantification in the conclusion to express object creation -- this is way too complex -- but rather a simple imperative "make" or "create" that create a new instance (possibly calling an external constructor when it exists, but this becomes then language dependant).

2/ About "removing slots"
Production Rules do not usually support this concept. A new object comes with all its slots, what are to be determined are the value of the slots.

Most systems support the removal of a value from a multi-valued slot, 
Some of them support the "removal" of a value from a mono-valued slot, usually relying on the notion of "null value", which rapidly becomes complex... In fact it is mostly  the system that support backward chaining that really use the "null" as a meta information stating that the value of a slot in not known.

 Patrick. 



 

-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On Behalf Of Gary Hallmark
Sent: mardi 12 août 2008 21: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))"
    * the cardinality of object:slot is 1:1 -- forall ?o ?x ?v1 ?v2
      (?v1=?v2 :- ?o[?x->?v1 ?x->?v2])
    * 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)

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.

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] ??)

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.

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 :-)
Received on Wednesday, 13 August 2008 14:03:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:53 GMT