W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > December 2011

Re: Indirect Graph Identification

From: Gregg Reynolds <dev@mobileink.com>
Date: Fri, 9 Dec 2011 03:51:00 -0600
Message-ID: <CAO40MikLkECtkAJkFdeLxTosd-CfPQL=c+JqiSywT65JrjLc0g@mail.gmail.com>
To: Kjetil Kjernsmo <kjekje@ifi.uio.no>
Cc: public-rdf-dawg-comments@w3.org
On Thu, Dec 8, 2011 at 6:37 AM, Kjetil Kjernsmo <kjekje@ifi.uio.no> wrote:
> On Tuesday 29. November 2011 00.12.12 Sandro Hawke wrote:
>> With indirect identification, those graph containers each get nice,
>> normal, RDF IRIs again.  Let's say you, me, and David each have sparql
>> stores on the same host, and we all use that IRI to tag OUR OWN COPY of
>> some data fetched from that URL.   (I think it's a terrible practice,
>> but its clear from discussions in the RDF WG that people like it and we
>> can't stop it.)
> It is terrible, terrible, TERRIBLE practice, and it should be explored what
> can be done to stop it... They should be saying
> http://example.org/my-graph-copies/http://www.example.com/other/graph
> instead and use that URI in their FROM clauses. Hmpf.

But how would you know to do that?  You've got your endpoint; I've got
mine.  We can't require that all endpoints at a given host be
centrally administered.  We're both free to name our graphs however we
like, whenever we like.  Nothing says the three URI's in Sandro's
example must yield identical representations.  They don't even have to
mean the same thing - meanings change, after all.
> At the very least, if the WG persists on using this any reference to REST
> should be removed, as this is very clearly not RESTful.

I don't see why not.  Three different URIs, three (possibly) different
resources, no?

This kind of thing is inevitable with any kind of hierarchical
namespace whose use is not centrally controlled.  Nobody says that
/foo should have the same meaning on every server; why should embedded
IRIs be any different?

My only quibble is with the term "indirect".  The URIs in question are
not indirect (URIs never are), any more than the address on an
envelope inside another addressed envelope is indirect.  It's the
whole package (and the access/delivery) that is indirect, not the
embedded name alone.  The spec says "...the embedded graph IRI
(http://www.example.com/other/graph) ... indirectly identifies RDF
triples to manipulate".  Not really; it's the composite that
identifies the triples, not the embedded IRI alone.  I think the spec
would be improved if references to "indirect graph identification"
were replaced with "embedded IRIs" along with language like "embedded
IRIs support reference to graphs under the control of an endpoint" or
the like.


Received on Friday, 9 December 2011 09:51:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:12 UTC