W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2004

RE: Reification - whats best practice?

From: <Patrick.Stickler@nokia.com>
Date: Thu, 2 Sep 2004 07:23:14 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50ADCAB@trebe051.ntc.nokia.com>
To: <tpassin@comcast.net>, <www-rdf-interest@w3.org>

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Thomas B.
> Passin
> Sent: 02 September, 2004 02:58
> To: www-rdf-interest@w3.org
> Subject: Re: Reification - whats best practice?
> Hamish Harvey wrote:
> > 
> > As to verbosity, for statements about statements it perhaps 
> doesn't get 
> > much less verbose than this, but to say that "X said <all 
> this>" where 
> > <all this> is a graph the named graphs approach would seem 
> to have an 
> > edge (no pun intended).
> Well, yes, if we had a good way to identify and name a subgraph that 
> would take care if it.  I'm not convinced I've seen that yet.  

Have you seen 





> FOr 
> example, using a document as a subgraph and attaching meta data to a 
> node whose identifier is the uri of the document just isn't kosher, 
> because rdf per se does not know when a uri is supposed to mean the 
> graph in a dereferencable document and when it doesn't.

Agreed. Overloading the URI is not good practice.
> OTOH, I can also imagine defining a class of resources for which - by 
> definition - their identifier *does* match up with their 
> content.  Then 
> such a scheme would work, at least if you want to create an 
> actual rdf 
> document for each case and if you can figure out how to make 
> it all work 
> in an rdf data store, which would have to import the subgraph 
> and match 
> it against the main graph but still keep it separate somehow.

Do you mean a "triple URI" where the triple is encapsulated in
the URI itself? True, that would be more concise than reification,
but named graphs seem to me to be far more efficient, particularly
when dealing with provenence and trust.


Received on Thursday, 2 September 2004 04:23:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:51 UTC