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

On Jan 26, 2011, at 5:40 AM, Rob Vesse wrote:

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

The last working draft now states (informatively):

"""
Per section 2 of SPARQL 1.1 Service Descriptions, it is RECOMMENDED that a service description document be returned from such a request, especially if the implementation also supports the SPARQL Protocol for RDF.
"""

So, a service description document should be returned (especially if the server implementation also supports the SPARQL Protocol for RDF).


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

Prior to the current last call working draft, the WG decided[1] that a comprehensive specification of how the Service Description specification and the Graph Store protocol interact was out of scope. In the end, the description of how an SD document can be returned by an implementation of the Graph Store protocol is only informative and (as the text indicates) such a document only makes sense to return if the server implements the SPARQL Protocol as well.

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

The latest working draft of the Service Description document contains a conformance section which addresses this question. Basically, an endpoint must return RDF and have at least one service described as being accessible at the endpoint URI (using the sd:endpoint property).

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


Dereferencing an endpoint URI with an HTTP GET is the only action described by the service description document that should result in a service description. Other methods (e.g. OPTIONS) are possible but are not discussed directly. As to the choice between RDF and HTML, the "Accessing a Service Description" section of the document says that a service description "must be made available in an RDF serialization", and "should use content negotiation" if the SD is available in multiple formats.


We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.

Regards, Gregory Williams, on behalf of the SPARQL WG.


[1] http://www.w3.org/2009/sparql/meeting/2011-03-15#resolution_2

Received on Tuesday, 28 June 2011 15:08:55 UTC