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

Hi Patrick,

After your comments and the email thread with Michael, I think I should 
try some PRD-specific syntax.  This is related to ACTION-554  Currently 
the PRD action syntax is:

  ACTION    ::= ASSERT | Retract 
  ASSERT    ::= Atom | Frame
  Retract   ::= 'Retract' '(' Atom | Frame ')'

I propose we change to

  ACTION    ::= ASSERT | Retract 
  ASSERT    ::= Atom | Frame | New
  New       ::= 'New' CLASS '[' (TERM '->' TERM)* ']' 
  CLASS     ::= TERM
  Retract   ::= 'Retract' '(' Atom | OBJECT ')'
  OBJECT    ::= TERM


New creates a new instance of the given class, initializes its slots, 
and asserts its classification and frame slots.

Instead of retracting frame slots, one specifies only the object.  The 
semantics are to remove all that object's frames and classifications 
from WM.

Patrick Albert wrote:
> 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 Friday, 15 August 2008 17:59:43 UTC