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 Tuesday, 12 August 2008 19:29:21 UTC