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

Hi,

On 26 January 2011 06:18, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:
> On Tuesday 25. January 2011 17:49:24 Chimezie Ogbuji wrote:
>> Also.  As a result of internal discussion and comments regarding this
>> term, the current editor's draft replaces 'RDF knowledge' with 'RDF
>> graph content' and I will be using this latter terminology in
>> subsequent parts of this email.
>
> That's a better term, but I feel that we should first identify the audience of
> this spesification. Is it the thousands of developers who could implement this,
> or is it a foundational document that other authors could use to document how
> it should be done for the former group? Honestly, I think that the current
> document is both too opaque and not sufficiently specified to be useful to
> developers, but I also feel that the current discussion is interesting and
> important.

I agree with comments raised in this thread that the current document
could be simplified. I see from the discussion that some changes to
terminology have been incorporated into subsequent editors drafts, but
broadly I think avoiding introduction of new terms should be avoided.
E.g. "RDF payload" isn't this just the entity body for the HTTP
request, why not just use the existing terms?

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.

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.

I'm not convinced that the Service Description document fulfils that
particular role. 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.

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

Cheers,

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

Received on Wednesday, 26 January 2011 09:48:24 UTC