Warning:
This wiki has been archived and is now read-only.

CommentResponse:KK-12

From SPARQL Working Group
Jump to: navigation, search

Addressed comments: KK-2 KK-3 KK-4 KK-12

--

Dear Kjetil,

this is an attempt to address your unanswered comments

Let us start with a general response, which will also guide the other specific answers:

The rationale of the SPARQL 1.1 Graph Store HTTP Protocol document (formerly "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs") is to document a RESTful style of accessing a graph store, i.e. to provide some more direct access than the SPARQO Protocol to endpoints directly via the HTTP operations. An implementation of this protocol does not necessarily cover/support full SPARQL Update, i.e. it is not prescribed that both SPARQL Protocol and SPARQL 1.1 Graph Store HTTP Protocol are supported by every endpoint, but at the same time we do not aim at providing a *generic* solution for RDF graph management via HTTP beyond SPARQL endpoints.

Anything beyond that is beyond our WG's charter, we might need to make this rationale a bit clearer in the beginning of the document.

Now let me try to attempt to address your comments separately: 

> "For operations involving a payload (PUT and POST), the server MUST parse 
>  the RDF payload according to media type specified in the Content-Type 
>  header (if provided in the request)."
>
> I would prefer that it said what to do if Content-Type was not set. I 
> suppose the only sensible thing to do is to attempt to parse the payload as 
> RDF/XML and throw a 400 if it is not.

We now write in the current editor's draft:

"If this header is not provided, the server SHOULD attempt to parse the RDF payload as RDF/XML. Similarly, if the Accept header is not provided, the server SHOULD return an RDF XML document."

but the spec doesn't exclude other behavior (by e.g. mandating 400) if RDF/XML parsing is unsuccessful. 

> I have two questions regarding the HTTP DELETE operation of
> http://www.w3.org/2009/sparql/docs/http-rdf-update/#http-delete 
> 
> 1) If the <graph_uri> does not exist before the deletion, do I have to 
> return a 404? 
>
> 2) Why can I only return a 200, and not a 204 if successful?

We now write in the current editor's draft:

"If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code."

"A response code of 200 OK or 204 No Content SHOULD be given in the response if the operation succeeded or 202 (Accepted) if the action has not yet been enacted."

We don't think any new issues are inherited in the use of HTTP that were not there already (so normal web security precautions apply). 

> The protocol may very well be used, and I'm quite sure it is already 
> implemented (especially since it is not a new protocol for with regards to 
> PUT, GET and DELETE) to manage repositories of old style serialized RDF 
> Documents. This is not a graph store in the SPARQL sense (i.e. a single 
> service; containing at least one unnamed graph etc.).

In case the SPARQL 1.1 Graph Store HTTP Protocol is used for such repositories, we think that (in the spirit of what was said in the beginning of this mail) they can be viewed as graph stores.

We'd appreciate if you could indicate whether this response adequately addresses your comment.

Regards,

Axel (on behalf of the SPARQL WG)

p.s.: your other comments

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Nov/0000.html http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Mar/0011.html

will be answered in separate mails.

Retrieved from "https://www.w3.org/2009/sparql/wiki/index.php?title=CommentResponse:KK-12&oldid=3163"