RE: Peering over the edge of the RDF cliff

Ora,

While I don't think this addresses what I see as the fundamental
model/syntax disconnect, I think that it would solve the particular problem
that is causing me to peer over the edge. I thought someone posted
something, however, indicating a reason why having both ID and resource
attributes in the same property would not work.

Jeff

-----Original Message-----
From: Ora.Lassila@nokia.com [mailto:Ora.Lassila@nokia.com]
Sent: Thursday, January 06, 2000 9:57 AM
To: jeff.sussna@quokka.com
Cc: www-rdf-interest@w3.org
Subject: RE: Peering over the edge of the RDF cliff


Jeff,

you bring up an interesting point.

you wrote:
> I really don't want to do this, but it seems to be the
> only really clean way I can find to treat RDF properties
> as first-class objects in a uniform way. The constraint
> against having both ID and resource attributes of a
> property appears to be the final straw. 

It seems to me that using an ID attribute on a property would be a
convenient way of naming the otherwise anonymous node resulting from
reifying the particular statement. At this point I cannot think of a good
reason why we would have restricted this (speaking as the editor of the
spec). It should be noted, though, that using the ID only makes sense if you
are reifying, since otherwise there obviously is no representation for it
(in the triple space).

OK, so let's for a moment think slightly outside the spec: what would be
wrong with writing something like

  <rdf:Description rdf:about="some.url" rdf:bagID="some.bag.id">
    <someProperty rdf:ID="some.id" rdf:resource="some.other.url"/>
  </rdf:Description>

If anybody is keeping track, this is one of the things we may want to fix in
the next version... :-)

Regards,

	- Ora

P.S. SiRPAC already "does the right thing"

> --
> Ora Lassila, <ora.lassila@nokia.com>
> Research Manager
> Agent Technology, Nokia Research Center / Boston
> +1 (781) 993-4603 (please note new email & phone number!)
>

Received on Thursday, 6 January 2000 13:28:42 UTC