CommentResponse:RV-5

Rob Vesse wrote:

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