- From: David Booth <david@dbooth.org>
- Date: Thu, 25 Aug 2011 13:07:32 -0400
- To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
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