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

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 
identification.

So

GET http://server/graphStore

either
   => quads
or
   => 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

	Andy

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