Comments on RDF Update Protocol for HTTP

ACTION-105

This is looks good to publish so even though I have some suggestions, it is enough for FPWD to me.

== Overall

I like the use of equivalent SPARQL/Update.

1/ Lexical form of URI: The use of "?graph=" is the key element of this doc.  The only place ?graph= comes up is in the diagram yet it is the naming scheme from URIs to graphs at endpoints.  An example of an HTTP request with for the FPWD would be nice even if the full text isn't ready.  This would help with the term Request-URI and exactly what that means in HTTP.

If there is one thing before FPWD, this, to me, would be the most useful.


2/ Some mention of SPARQL/Update over POST and it being different.  Eventually, a link. But for now, including a line or two. Suggestion:

"This document describes updating and fetching RDF data from RDF datasets over HTTP in the REST style. It is a companion to the use of SPARQL/Update over the SPARQL protocol which uses HTTP POST to transmit a SPARQL/Update request."

== Title

Not sure about title.  
(Is there a non-core protocol as well? Is SPARQL/Update over POST "non-core" or "non-uniform"?)

"RDF Update Protocol for HTTP" maybe.  Not as fun.

The doc also describes the use of "GET /endpoint?graph=" so it's not just update.

"RESTful SPARQL Protocol"
"RESTful RDF Protocol"

For consistency, do we want to include "1.0"?

== Sec 1

The first sentence is quite long.

"""This specification describes a set of architectural constraints on the HTTP protocol that aim to emphasize separation between...
"""

As the first line, would it be better to say that this specification describes the use of the HTTP protocol and gives a way of naming graphs managed by a server.  Those are the deliverables, not architectural constraints.  And I hesitate over saying "constraints" in the area of REST and HTTP.

== Sec 2

"Although this protocol limits the format of the representations exchanged"

I think the design should just defer to HTTP mechanisms and say HTTP is used in the normal way.  I don't think you are saying that if client C and server S arrange to use SuperBinaryRep that would be wrong because it's not W3C.

I would like to see something that says that a compliant implementation MUST accept RDF/XML. 

Mention Turtle for future proofing (I'm assuming it will be standardised sometime although the move from one standard representation to two is not trivial).

Not sure about mention of GRDDL being the payload because of the implications of server side processing and calling out to 3rd party transforms.  If nothing else, the doc will need a security section (it can also refer to the GRDDL security issues).  RDFa is safer here.

== Sec 4 Graph Management Operations

I'm not sure the splitting into 4/5/6 and not just going through the HTTP Verbs helps.  Suggest having one section each verb as subsection. 

Suggestion:

"This section describes the use of the HTTP verbs with the graph identification scheme."

The framing for me is that, given the "?graph=" naming, this is the natural application of the REST verbs.  No additional magic or machinery is introduced.

== 5.1 HTTP POST

Can the POST create a graph that does not already exists?  HTTP POST is neutral on this.  You can get back 201 (Created).

If it can, I think it needs a graph create as well in case the graph does not yet exist:

CREATE [ SILENT ] GRAPH <uri>
INSERT [ INTO <uri_of_knowledge> ] { .. RDF payload .. }

== 5.1 (which is 6.1) HTTP GET

This is the same as CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <....> { ?s ?p /o } }, right?

== Placeholders 

Just ideally, placeholders for security and conformance would be good.  I think we will need a security section and so flagging that would be ideal.  Not essential for FPWD.

 Andy

Received on Thursday, 1 October 2009 13:23:42 UTC