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

Hi Chimezie,

Thank you for the considered response, and apologies for being slow to respond.

I've inlined answers to your questions and some additional comments.

On 2 February 2011 17:14, Chimezie Ogbuji <chimezie@gmail.com> wrote:
> 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?

The Atom Protocol spec leads directly with the different types of
resources being managed, and clear diagrams and illustrations of the
HTTP protocol. The Uniform Protocol spec instead largely maps things
to SPARQL Update operations.

>From a user-developer perspective I'd prefer to see some clear
examples of how the protocol is intended to operate, complete with
HTTP operations, right from the outset.

>From an implementor-developer perspective, the mapping to SPARQL
Update operations is a useful guide to how this protocol could be
implemented as a layer over that language. But that's really just one
approach, so perhaps should be moved to a non-normative section.

My other area of concern relates to the lack of "Dataset" as a
resource that is managed by this protocol. My view is that this is a
specific type of resource, analogous to an Atom Collection, that I
should be able to RESTfully manage.

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

Yes that's correct, I did suggest that enhancement. But that feature
supports client's submitting data without wanting to or needing to
care about the graph URI. It also supports servers in deciding to
manage their own graph identifiers.

However my comment relates to management of Datasets, not graphs. I
think it would be useful to be able to:

* Add/Remove Datasets
* Add/Remove Graphs from Datasets

The specification already discusses the addition and removal of Graphs.

Datasets added via a RESTful interface might then be available via a
SPARQL endpoint that shares the same backing store.

This seems me to map onto the model that's implicit in the Service
Description documentation which indicates that a SPARQL endpoint might
have several datasets, and that those datasets contain graphs. However
at present the Uniform Protocol does not describe how to create
datasets.

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

I've commented on your specific example, below.

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

This is a good example and helps focus the discussion.  I think a
number of my issues relate to confusion between the Uniform Protocol
and the Service Description document. As a general point I think the
Service Description definitely needs more examples.

Some further questions:

>From your example it appears that a "Graph Store" IS a sd:Dataset,
which is defined to be a SPARQL Dataset. So why use the term Graph
Store at all, why not say, explicitly in the Uniform Protocol that its
a protocol for managing datasets? That is much clear, IMO

If I perform an HTTP GET on <http://example.com/graph-store> what is
returned? I'd expect to retrieve a description of the dataset, i.e. a
list of the graphs, that it is made up of. From a REST and Linked Data
perspective, I'd expect to be able to access the resources directly,
not have to refer to a Service Description document.

How do the sd:defaultGraph and sd:namedGraph predicates in the Service
Description document relate to the uniform protocol? The only example
shows these as blank nodes, with sd:name giving the URI of the graph
to be used in a SPARQL query. However I'd expect these predicates to
refer to resources accessible via the Uniform Protocol, i.e. so I can
GET/PUT/DELETE the graphs.

The Service Description document defines a concept of Graph Collection
(http://www.w3.org/TR/sparql11-service-description/#sd-GraphCollection)
its not clear to me what this is for, and whether it relates to the
uniform protocol.

If "Graph Store" == Dataset, then how does a Dataset get added/removed
from a SPARQL endpoint? You may decide this is outside scope of the
specification, but it could perhaps be acknowledged as a potential
extension

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

OK, understood. I think most of my confusion relates to that area.

The Service Description document seems to have been written purely as
an attempt to describe useful metadata about a SPARQL endpoint. The
Uniform Protocol addresses exposing collections of graphs (or
datasets?) via HTTP. But there are areas of overlap that are unclear
to me (at least).

It also seems to me that I should be able to implement the Uniform
Protocol without necessarily exposing a SPARQL endpoint or using
SPARQL Update to manage the graphs.

Cheers,

L.

-- 
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.dodds@talis.com
http://www.talis.com

Received on Friday, 11 February 2011 12:06:39 UTC