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

Re: GET on a graph store URI / Graph Store HTTP Protocol

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Mon, 19 Dec 2011 11:24:42 +0000
Message-ID: <4EEF1EFA.50202@epimorphics.com>
To: public-rdf-dawg@w3.org

On 17/12/11 05:44, Gregory Williams wrote:
> On Dec 17, 2011, at 12:05 AM, Sandro Hawke wrote:
>>> 2/ Could we allow GET on a graph store URI return quads?
>> I think so, yes.
>> There are two very different things people might reasonably want to do
>> here: get a dump of the dataset, and get a dump of the URLs used to
>> access the graphs in the dataset.   I think at some point both need to
>> be supported, but it looks like we have that with SD.
>> As I understand it, given a SPARQL endpoint with address E:
>>    GET E
>>    ... returns the Service Description (SD)

This conflates service description and graph store.

Describes a service => E is a service (endpoint).

>>    Query SD for { ?S sd:endpoint<E>; sd:defaultDataset ?D }
>>    GET ?D
>>    ... should return a TriG/N-Quads serialization of the given dataset;
> We agree that this is at odds with the GSHP text as it currently stands, right?

It is certainly a different URI to <graphStore>.  A URI denotes a 
resource.  <foo?queryString> is a resource that is the result of the 
question in the query string.  There is nothing special about 
?queryString in RFC 3986 (see section 3.4) in terms of resource 


GET http://server/graphStore

   => quads
   => a description of the graph store (e.g. contents.)

GET http://server/graphStore?serviceDescription
   => service description of the graph store.

>>      (but doesn't with the current GSHP)
>>    PUT ?D<somedata>
>>    ... should replace the dataset
> I'm not sure we've ever really nailed down whether this should work. ?D here is the resource for the default dataset, which I wouldn't assume is necessarily the same thing as the graph store. For that matter, ?D might not even be a dereferenceable IRI.
>>         Query SD for { ?D sd:namedGraph/sd:name ?N } and ?N comes back
>>         with each of the graph URLs.
>> I don't suppose we can require SPARQL 1.1 endpoints to answer queries
>> about their own SD, maybe using FROM their own endpoint address...?
>> Otherwise, what, you need your own SPARQL server before you can start to
>> poke at someone else's?
> We had early discussions about this while deciding how a service description was to be made available. I think it would be nice for systems to be able to do this (you get it for free on systems that dereference FROM IRIs), but I wouldn't want to mandate it. Also, I don't think you need a full SPARQL implementation to benefit from a service description. A simple triple store would allow you to access the data you've discussed above with simple triple pattern matching and a couple of loops.
> .greg

Received on Monday, 19 December 2011 11:27:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:05 UTC