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

Re: HTTP Update : graph naming

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 10 Nov 2009 18:25:16 +0000
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-Id: <7A104FF6-3CBF-4506-B6F7-CA8D51415C4F@garlik.com>
To: Andy Seaborne <andy.seaborne@talis.com>
On 10 Nov 2009, at 12:45, Andy Seaborne wrote:

> I had a quick look at implementing the update protocol and a couple  
> of points came up regarding ?graph= vs http://host/service/http://  
> vs http://host/graphs/mygraph56
> I wanted a service endpoint that could handle both server controlled  
> URIs e.g. http://host/graphs/mygraph56 and also graph names that  
> were not server local. http://host/graphs/?graph=.. or the non-query  
> concatenation form.
> (Aside: some agreed neutral terminology needed!
>   server-relative URIs
>   query string identification
>   concatenation identification
> )
> 1/ Service endpoint naming.
> It's not always clear what service endpoint URI actually is so  
> splitting request URIs at the service endpoint can be tricky.
> This can be because the service endpoint is actually inside the  
> firewall and the request is passed from the front end.  Aligning  
> these names would be an additional deployment constraint that might  
> be hard to justify. (Steve has mentioned this before.) Also, in a  
> framework like servlets, the processing code might not actually know  
> their own service endpoint name very well, or it may be registered  
> under several different URLs.
> This gets into service endpoint vs dataset/graph store naming.

It doesn't suffer the same issues as graphs named after the request  
endpoint, as you're not required to know the domain used in the client  
request - which it is often not possible to discover.

We require that the SPARQL side requests have to be directed to  
exactly /data/, this means that the requests look like:

PUT /data/http%3A%2F%2Ffoo%2Ecom%2Fbar HTTP/1.1

And get interpreted as talking about "http://foo.com/bar".

Then the only requirement is that reverse proxies have to map to / 
data/ on the SPARQL side. This has not been an issue for anyone so far.

> 2/ Extreme URIs.
> For the non-query string form, corner case URIs can be difficult or  
> ambiguous.  URI scheme names may appear in URIs as legitimate  
> character strings so looking for a ":" is not always safe enough.
> Some (unusual URIs - but this is a spec) cases: one level of  
> encoding removed for clarity.
> # Two encoded http: in URI
> http://service/graphs/http://other/abc/http://yetanother/xyz

We do exactly one URI decode pass, remove the "known" prefix and the  
rest is the graph URI.

However, I'm not especially advocating the /path/$(uri-encoded-uri)  
approach, we'd be happy with
/path/?graph=$(uri-encoded-uri) also.

- Steve
Received on Tuesday, 10 November 2009 18:25:47 UTC

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