- From: Patrick Albert <palbert@ilog.fr>
- Date: Tue, 19 Aug 2008 17:18:49 +0200
- To: "Gary Hallmark" <gary.hallmark@oracle.com>
- Cc: "RIF WG" <public-rif-wg@w3.org>
- Message-ID: <4412C4FCD640F84794C7CF0A2FE890D2F191CA@parmbx02.ilog.biz>
Hi Garry,
Thanks for the precision; I add a couple of remarks.
- I suspect that the (TERM '->' TERM)* component of the construct 'New' CLASS '[' (TERM '->' TERM)* ']' deals with slot initialization, so I'd propose to replace by (SLOT '->' TERM)*, SLOT being a legal slot for the class - defined locally or inherited - and TERM being defined as a legal value for SLOT.
- We need to complement the New with a construct for attaching the newly created object to a variable local to the conclusion of the rule. This is needed to reference it at any appropriate place in the conclusion.
Patrick.
__________________________________
PS: still related to how object and rules interact, I've (rapidly) been through the OWL compatibility section and found something intriguing "frame formulas[...] of the form s[p -> o], where p is not rdf:type, [are interpreted] as membership of the pair (s, o) in the binary relation denoted by p." .
I am not sure I get the exact meaning but I suspect that we want support applying the rules to the members of the set created by the relation.
It is fine for "mono-valued" slots where sets are singletons, but the so-called mutli-valued slots are usually supported in two complementary ways. Typically those who have a set as value, such as "parents" - there are two ways of accessing the slot: one way is to apply the rules on the individual members of the set, iterating on each value of the slot - one of the parents at a time -- , and the other way is to reference the set itself to reason on its values or for example on its cardinality - for example reasoning on the size of the family.
I am not sure that what we propose supports this.
-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com]
Sent: vendredi 15 août 2008 19:58
To: Patrick Albert
Cc: RIF WG
Subject: 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 Tuesday, 19 August 2008 15:20:55 UTC