Review of SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs review, rev1.56

I've just read through the document. There's nothing catastrophically wrong, but there are some things that should be looked at. It could be draft published as-is, but I'd like to understand the Major issues first.

Major

§4.3

I'm concerned that "Implementations of this protocol MUST obey the rules specified there regarding the resolution of relative URI references" rules out reverse proxies as implementations of this protocol. In our experience reverse proxies are commonly used infront of SPARQL endpoints to provide load balancing, additional security, and/or hardening. From the clients p.o.v. the proxy is the SPARQL endpoint.

Also HTTPS is an issue here, it's not generally possible for the server to tell from HTTP headers whether the HTTP or HTTPS protocol was used by the client, unless it has sight of the outer layers of the networking code. It may be possible to guess from the port number, but I don't think that's a good basis for picking URIs.

I find the logic in the last example in 4.3 (http://example2.com/rdf-graphs/employee/1) a bit convoluted. It seems like it's necessary to parse the RDF document before you can determine which graph is to be updated. If I sent that request, and got that result I would certainly be surprised.

Minor

Abstract

"SPARQL update language", should it be SPARQL Update...?
Why is “statements” italicised?
http://www.w3.org/TR/ is not linked

§1

"It emphasizes a clear separation between a RDF graph management action from the networked body of RDF knowledge identified as the target of the action, the lexical form of a Request URI, the URI of a graph in an Network-manipulable Graph Store, and the (optional) RDF delivered with the message" — I can't parse this sentence.

§2

I think REST should be in []s, there's a informative reference at the end of the doc.
"Network-manipulable Graph Store - The subset of a Graph Store comprised of named RDF graphs that can be directly managed by interactions through this protocol" — does this imply that you can't managed the unnamed graph?
"RDF knowledge" seems to overlap heavily with "RDF Graph", and "RDF graphs" used earlier, and "RDF payload" defined later.

§4

in 4.1 it might be worth a quick note about what to do in the presence of reverse proxies, or even just noting that they're a problem in this case.

I didn't feel that Figure 1 made the situation clearer. I think if the network operations were separated out from the conceptual relationships it might help.

Is Figure 2 missing some arrows? There doesn't seem to be a connection between the encoded URI, the graph store, and the operation.

§5

It's not clear if the 404 requirement trumps the 400/405 or not. e.g. if I send an
TRACE http://server/?graph=doesnotexist
should it return 404 or 405?

The 404 requirement presumably doesn't apply to PUT and POST.

§5.1

What does "native" mean in this section?

I think it should be
   DROP SILENT GRAPH <graph_uri> ;
   INSERT DATA { GRAPH <graph_uri> { .. RDF payload .. } }
As per the latest Update draft.

§5.2

Don't understand opening sentence "The HTTP DELETE method SHOULD be used to delete the RDF knowledge identified by either the request or encoded URI. This method MAY be overridden by human intervention (or other means) on the origin server." does this imply that HTTP DELETE is the preferred way to delete content? I suspect "be used to" should be removed. There's similar wording in other parts of §5 too.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Tuesday, 5 October 2010 20:27:53 UTC