Re: Comments on SPARQL 1.1 Uniform HTTP Protocol Working Draft 14 October 2010

Hey Leigh.  See my response below.  Note, this is not an official WG
response, but my attempt to extract some actionable specifics from
various points you raised below.

On Wed, Feb 2, 2011 at 11:23 AM, Andy Seaborne
<andy.seaborne@epimorphics.com> wrote:
> ..snip..
> The Atom protocol is a good resource to draw on, not just in terms of
> the simplicity of how the operations are documented for developers (of
> both audiences), but also in terms of a basic model for the protocol
> itself.

The organization of the document is influenced by the Atom protocol.
Do you have some examples of places in the specification that contrast
the writing style (or protocol model) of the Atom protocol?

> Ian raised the issue of describing operations on a dataset, including
> listing graphs. In my view there ought to be a simple RESTful way to
> interact directly with the dataset, treating it as a container of
> graphs that can be added and removed, similar to Atom collections.

Yes, the secondary POST operation (described in 5.3 HTTP POST) was
directly motivated by the Atom collection use case (and from an
earlier comment and request from you for this behavior, if I'm not
mistaken).

> I'm not convinced that the Service Description document fulfils that
> particular role.

As described in 5.3, when the request URI of an HTTP POST identifies
the Graph Store, then the result will be the addition of a new graph
to the store.  Note the editor's note in the bottom of that section
which seeks input from the community on this exact question.  The idea
currently is that an OPTIONS (or GET) request to the service directly
will return an SD document, which could include statements about
instances of sd:Dataset and the corresponding URL would be understood
to be the URL of the Graph Store.  Does this mechanism address the
usecase you have in mind?

> The current Working Draft suggests returning an
> reference to a description document from an OPTIONS request. But I
> think there are several issues with that:
> * I may be misunderstanding, but Service Description documents are
> accessible from the URI of a SPARQL endpoint. However I'm not sure
> there's necessarily a 1:1 mapping between a GraphStore and SPARQL
> endpoint.

See above.  The scenario is as follows.  If the URL to the endpoint is
http://example.com/sparql-endpoint then

GET /sparql-endpoint HTTP/1.1
Host: example.com

Then response (as N3/Turtle) could be:

@prefix sd: <http://www.w3.org/ns/sparql-service-description#>.
[] a sd:Service;
   sd:url <http://example.com/sparql-endpoint>;
   sd:defaultDatasetDescription <http://example.com/graph-store> .
<http://example.com/graph-store>
   a sd:Dataset;
   sd:defaultGraph ..snip..;
   sd:namedGraph ..snip..

So, from this the client would glean that the URL of the Graph Store
is http://example.com/graph-store and can then dispatch HTTP POST
requests with an RDF document as the body in order to add an RDF graph
to the Graph Store and have the service return the newly minted URL of
the graph.  Does this clarify the mapping for you? If an example like
this was incorporated into the text, would it address your concerns
about this relationship and usecase?

The remaining points below will need to be addressed by the WG since
it raises a larger issue of the relationship between an endpoint and
the (possibly many) Graph Stores it manages as well as the issue of
how to manipulate a named graph within a particular Graph Store.

> * It's (still) not clear to me how GraphStore relates to Dataset.

> * The service description document indicates that a SPARQL endpoint
> may expose several datasets, so how does a client identify the correct
> Service or Dataset in the description.

> * If a GraphStore supports the creation and management of datasets,
> then presumably these need to be identified so I can interact with it,
> e.g. to DELETE it? If not then how do I add/remove graphs from a
> specific dataset?

> * From a Service Description document I should be able to find the URI
> for manipulating a specific sd:Graph via the Uniform Protocol. It's
> not enough to simply reference the URI of the service as that will
> require URI construction on the client side.

Chime

Received on Wednesday, 2 February 2011 17:15:56 UTC