W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2009

[PRD] Proposal for object representation (and ACTION-592 complete)

From: Christian de Sainte Marie <csma@ilog.fr>
Date: Mon, 02 Mar 2009 18:52:43 +0100
Message-ID: <49AC1CEB.3060301@ilog.fr>
To: RIF WG <public-rif-wg@w3.org>
All,

I completed my ACTION-592, and opened ISSUE-94 on the RIF representation of objects' attributes and methods.

I also have a proposal to reslove the issue, btw :-)

My proposal for dealing with object would be to extend PRD terms (BLD basic terms) to include a construct to represent the value of an object member (attribute or method); that is, instead of adding a frame-like atomic formula for single-valued attributes.

That would add another kind of TERM, in addtion to the Const, Var and External function call (and Expr for uninterpreted functions, in BLD): in the following, I call it a "Getter", but it is probably not very difficult to find a better name.

The essential idea is that, as a term, it has one single value, and that it is compatible with the frame, too. 

To represent a Getter, one needs to represent the "object" (from which the value is got) and the "member" (that indicates how the value is got from the object). The object is represented by a TERM and the member is represented by a "Const" or "Expr", depending on whether the value to be got is assigned to an attribute of the object, or whether it is returned by a method of the object. The presentation syntax could look like (see also attached diagram):

 TERM           ::= IRIMETA? (Const | Var | 'External' '(' Expr ')' | Getter)
 Getter         ::= TERM '.' (Const | Expr)

And the XML syntax:

 <Getter>
   <object> TERM </object>
   <member> [ Const | Expr ] </member>
 </Getter>

Assume, for instance, that a variable ?p is bound to an object of the class person: 

 CLASS Person
     Integer : age
     Person : spouse
     Person : childFromSpouse(Person : child)

where childFromPreviousSpouse is a method that takes a Person as its single argument and that returns the Person with whom ?p had the child bound to ?ps.

?p.age is a Getter, with TERM: ?p the object and Const: age the identifier of the field;
?p.spouse.age is also a well-formed Getter, with Getter: ?p.spouse the object and Const: age, again, the identifier of the field;
and ?p.childsFormPreviousSpouse(?ps) is a Getter as well.

Such a Getter TERM would allow atomic condition elements such as: ?p.age > 18, etc.

In PRD, we would need to add a "setter" action: Set(Getter, TERM), that would replace the value of the first argument (the Getter) by the value of the second argument. 

And, btw, we could then restrict the intitialization part, in the declaration of an action variable, to be a TERM, thus avoiding the ambiguity of allowing (multi-valued) frames. That would make "New" a TERM, too, btw, which makes sense...

Finally, it is compatible with Frames, as far as I can see. At least, there is an easy fallback to Frames in Core (if Core does not add the Getter as well), since a Getter obj.mem in a expression can always be replaced by a variable and the expression wrapped inside an existential quantifier for that variable, and conjoined with a Frame that cpnstrain the bonding of the variable. E.g.:
 ?p.age > 18
would fallback to
 Exists ?a (?p[age->?a] AND ?a > 18)

Of course, we would need multiple existential variables for chained fieds:
 ?p.spouse.age > 18
would give
 Exists ?s (?p[spouse->?s AND (Exists ?a (?s[age->?a] AND ?a > 18)))

Of course, that does not truly address the relationship betweem Frames and single-valued attributes in objects (e.g. whether ?x[attr->?x.attr] etc), but that is probably out of RIF's scope, anyway.

Notice that the above proposal does not cover the use of boolean methods as condition elements in rule conditions: that would require to add an (external) atom equivalent of the Getter, restricted to the TERM.Expr syntax.

Discussion?

Cheers,

Christian 
Received on Monday, 2 March 2009 17:53:31 GMT

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