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

On Wed, 2011-12-14 at 10:00 +0000, Andy Seaborne wrote:
> (from this week's telecon - this email picks off this one point in the 
> hope of "divide-and-conquer" progress)
> 
> The GET on a graph store URI is defined to return the service 
> description.  We didn't understand why.
> 
> 
> The RDF-WG is (likely to) define formats for n-quads and TriG that can 
> represent an RDF datasets.
> 
> GET <uri> returns a representation of the resource at <uri>.
> 
> So returning n-quads seems natural (an implementation can 403 it if it's 
> too big).
> 
> 
> A service description describes a service and its endpoints.
> 
> It connects a service to a dataset with sd:defaultDataset.
> 
> If GET of the graph store URI is the SD then don't we have:
> 
>      <uri> sd:defaultDataset <uri> .
> 
> 
> A graph store is a container of graphs (unnamed and named).  It is not a 
> general RDF processing service.

That is, in RESTful terms, it's a resource whose state is an RDF
Dataset.   ("Dataset-State Resource" is even more clumsy than
"Graph-State Resource", but it's still pretty darn precise.)

> It might be that the graph store URI is overloaded with ?query= and 
> ?request= functionality but it is overloading the service endpoints with 
> the resource itself.  In this case alone, does returning the SD make 
> complete sense to me.
> 
> I can see why returning a description of the graph store makes sense and 
> the SD vocabulary has language for that but that's only a part of the 
> service description.
> 
> 1/ Should the return at least be a description of the graph store (using 
> the sd:defaultGraph sd:NamedGraph etc vocab)?

I don't quite understand this question.

> 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)

   Query SD for { ?S sd:endpoint <E>; sd:defaultDataset ?D }

   GET ?D
   ... should return a TriG/N-Quads serialization of the given dataset;
     (but doesn't with the current GSHP)
   PUT ?D <somedata> 
   ... should replace the dataset

        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?
    
    -- Sandro



>  Andy
> 
>

Received on Saturday, 17 December 2011 05:05:46 UTC