RE: Comments on SPARQL 1.1 Uniform HTTP Protocol and Service Description

Hi all

I would like to add a couple comments expanding on Leigh's points which I
had planned to send as a comment to the Working Group today anyway.

My main concerns are regarding the use of OPTIONS for a Uniform Protocol
service to return a Service Description and the contents of the Service
Description itself:

1. The Uniform Protocol document does not state what it expects to be
returned from an OPTIONS request.  Am I expected to do a 30x redirect to the
Service Description document OR to return a 200 OK with a Location: header
pointing to the service description OR am I expected to return the Service
Description directly in response to the request?
This needs clarifying as currently I've been forced to assume the middle
option (200 OK with a Location header) based on my reading of the draft:

> It is RECOMMENDED that the OPTIONS and GET  methods be used as
> a request whose URI identifies the service that implements 
> this protocol in order to retrieve information about the 
> communication options available"

2. Service Description only has means to describe Query and Update endpoints
but not to describe a Uniform Protocol service.  This seems a fairly major
oversight, while I appreciate that such a service does not necessarily have
a single URI it will typically have a base URI under which it accepts and
processes all requests.
I appreciate that the SPARQL Protocol and the Uniform Protocol are intended
to be separate and the Service Description document implies that it intended
for the SPARQL Protocol only.  So if this is the intention what business
does a Uniform Protocol endpoint have producing a Service Description anyway
unless it will also provide Query/Update endpoints via the SPARQL Protocol.
Which realistically IMHO is going to be a fairly common use case.

3.  How much of the Service Description is required?  I assume pretty much
everything is optional including the dataset description.  This is of
interest to me since in my implementation the HTTP endpoint does not have
direct access to the dataset behind it due to various layers of abstraction
in my APIs.  Should a Service Description always describe the dataset or is
it sufficient to just describe the basic properties of the service?

4. Are Query and Update endpoints expected to always return the Service
Description in response to an OPTIONS request?  Also under what other
circumstances should the description be returned?  I'm inclined to assume
that if a GET request is made with no query and the client does not want
HTML (or prefers RDF over HTML) then they should get the Service
Description.  Some clarification over how and when the Service Description
is retrieved would be nice.

Regards,

Rob Vesse

-----Original Message-----
From: public-rdf-dawg-comments-request@w3.org
[mailto:public-rdf-dawg-comments-request@w3.org] On Behalf Of Leigh Dodds
Sent: 26 January 2011 09:48
To: public-rdf-dawg-comments@w3.org
Cc: Kjetil Kjernsmo
Subject: 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 10:41:42 UTC