W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: ACTION-115: Note on proxy graph URI

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 13 Oct 2009 11:11:57 +0100
Cc: public-rdf-dawg@w3.org
Message-Id: <36BCD971-E10C-4218-8056-7D77CEA0CFF2@garlik.com>
To: Kjetil Kjernsmo <kjetil@kjernsmo.net>
On 13 Oct 2009, at 08:34, Kjetil Kjernsmo wrote:

> On Monday 12. October 2009 18:45:33 Chimezie Ogbuji wrote:
>> Ok.  I was using the term proxy to tease out whether we were talking
>> about URI 'aliases' or service endpoints
> Tihihi! I'd say that was a successful tease :-)
>> In which case, I believe this settles the issue of whether this  
>> induces
>> good 'HTTP behavior', since presumably you can use all the verbs
>> (PUT/POST/GET/DELETE) uniformly on these alias URIs as though you  
>> were
>> using the IRI of the graph directly. In addition, conditional GETs  
>> would
>> work as expected.
> Indeed. My argument was that one cannot infer the "original" graph  
> URI from
> the "proxy" URI due to the opacity axiom, which still holds true, I
> believe, but if we treat them as equivalent aliases, this becomes
> irrelevant.

That assumes that there is an "original" graph.

If I import http://dbpedia.org/data/BMW_M50.rdf into my store and run  
a few INSERTs on it to add some extra annotations I'd like, then  
there's no original graph to refer back to, as the local
will return different triples from http://dbpedia.org/data/BMW_M50.rdf

Similarly if you import stuff to the graph http://myapp.example/ 
data.rdf, you can't dereference that, so it's not really an alias for  
a URI in that sense.

But, I'm not sure if that's the sense in which you meant alias.

- Steve

Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
Received on Tuesday, 13 October 2009 10:12:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC