Re: SPARQL 1.1 Service Description - Comments

Followup on an earlier comment . . . 

On Fri, 2011-07-29 at 15:18 -0400, David Booth wrote:
> Regarding 
> http://www.w3.org/TR/2011/WD-sparql11-service-description-20110512/
[ . . . ]
> 10. I suggest adding an sd:AllowsGraphCreation feature instance to
> section 3.4:
> [[
> 3.410 sd:AllowsGraphCreation
> 
> sd:AllowsGraphCreation, when used as the object of the sd:feature
> property, indicates that the SPARQL service permits new graphs to be
> created (resources permitting).  This feature is provided because some
> SPARQL services may only operate on a fixed set of 
> 
> See SPARQL 1.1 Update section 3.1:
> http://www.w3.org/TR/sparql11-update/#graphUpdate 
> 
> type: sd:Feature
> ]]

At http://www.w3.org/2009/sparql/wiki/CommentResponse:DB-6 I noticed
this draft response:
[[
@@ I'm hesitant to add this. Even without a "fixed set of [graphs]", the
endpoint is free to reject the graph creating operation for any reason.
On the other side, 4xx HTTP response codes should provide enough
information to tell that a graph creation operation was rejected and
shouldn't be retried, so I'm not sure how useful this would be.
]]

To clarify: It would be helpful to be able to distinguish between a
service that supports graph creation (provided it has sufficient
resources, permissions are adequate, etc.) and a service that does not,
so that the client knows whether there is any point in attempting graph
creation.  I'm not sure that the HTTP response codes would give enough
reliable information to enable the client to distinguish between an
unimplemented feature and an error condition for an implemented feature.
In order to rely on HTTP response codes, the SPARQL 1.1 Update spec
would have to state exactly which response codes must be returned under
which circumstance.  But the Protocol spec says:
http://www.w3.org/TR/rdf-sparql-protocol/#query-req-refused-fault
[[
The QueryRequestRefused fault message neither indicates whether the
server may or may not process a subsequent, identical request or
requests, nor does it constrain a conformant SPARQL service from
returning other HTTP status codes or HTTP headers as appropriate given
the semantics of [HTTP].
]]
and:
http://www.w3.org/TR/rdf-sparql-protocol/#query-bindings-http
[[
. . . the two faults described in SparqlQuery interface, MalformedQuery
and QueryRequestRefused, are bound to HTTP status codes 400 Bad Request
and 500 Internal Server Error, respectively [HTTP].
]]
So it seems to be that a client would receive a 500 status code in both
circumstances: when the service does not support graph creation and when
the service supports it but refuses to perform the operation at the
moment due to inadequate resources, permissions or other error
condition.



-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Thursday, 25 August 2011 17:07:55 UTC