W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2007

Re: slotted notation -summary

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Tue, 09 Jan 2007 09:46:57 -0500
To: Christian de Sainte Marie <csma@ilog.fr>
Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Message-ID: <12460.1168354017@cs.sunysb.edu>

> Michael Kifer wrote:
> > 
> >  [...]
> >
> > Different slotted styles
> > ------------------------
> > We can distinguish at least 2 styles of slotted notation: relational and
> > object-oriented.
> At least for those two ones, isn't it the case that a slotted predicate 
> of the OO kind can always be represented as a conjunction of binary 
> slotted predicates of the relational variety, where the predicate 
> represents the slot/property/attribute, one of the roles is the object 
> (e.g., the first, by convention), and the other one is the value?

Relational slotted notation cannot be conveniently represented this way. In
Relational notation the Id of the object is implicit and cannot be
manipulated by the language.

But from a purely mathematical point of view it can be mapped to a bunch of
binary predicates.

> > Object-oriented slot notation:
> >           This semantics is used in F-logic, RDF, etc., and can also be
> >           simulated by choosing the appropriate constraints for OSF.
> >           Again, there are two things that one might say about slots in
> >           F-logic (and RDFS):
> > 
> > 	  p(slot1->val1,...,slotn->valn)
> > 	        Here p is an object (as opposed to relation) and
> > 		slot1(p)=val1, ..., slotn(p)=valn.
> That is, couldn't that be, by convention (in RIF):
>     slot1(p, val1) and ... and slotn(p, valn)?
> I may be naive, but I did not see in the discussion anything that could 
> not be handled that way (except maybe for RDF bNodes).
> So, why not have the closed relational slotted notation in RIF Core, and 
> some convention for transforming OO slotted predicated into that 
> notation (same kind of process as the one to bring an OSF term into its 
> solved form)? (*)

You want to map the relational slotted notation to the OO slotted notation
- not the other way around. Relational slotted notation implies that object
Ids are inaccessible, while OO notation assumes that they are. So, you can
map OO to relational slots in a certain sense.
But the relational notation offers some conveniences that the OO notation
doesn't (not having to explicitly represent the object Id).

I am not sure that such a mapping makes good sense for our purposes. After
all, one can translate slotted notation into positional notation as well.
By this argument we can just leave positional stuff and nothing else.

> I am aware that that solution might have an impact on roundtrips (and, 
> thus, on efficiency in specific rule engines; readibility in specific 
> target rule languages etc), but that would be an argument in favor of 
> having data-model specific dialects, rather than having two different 
> notations (**) for the same thing in RIF Core.

Yes. We can take the OO notation or leave both of them out for dialects.

> On the other hand, if the two notations (**) are not equivalent, and if 
> there is no single notation (with a single semantics) that can account 
> for both kind of slotted syntaxes (***), we should probably not have 
> slots in RIF Core (that is, Michael's option 4).

It depends what you mean by "equivalency". Strictly speaking, you can map
all of them to positional predicates. But as slotted notations go, the OO
is more general in a certain sense.

> (*) that would not imply a closed-world assumption, if I am correct.
> (**) 1) n-ary slotted predicate where the predicate is actually the 
> object;

In relational slotted notation the predicate is NOT an object, but a class.
(Please reread my comparison to get this cleared up.)


> 2) binary slotted predicates where the predicate is the 
> attribute, and the arguments the object and the value.
> (***) what other semantics are there for slotted syntaxes? How do they 
> relate to the relational and OO ones?
> Christian
Received on Tuesday, 9 January 2007 14:48:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:41 UTC