Hi Chimezie,
I just looked through
http://www.w3.org/TR/2010/WD-sparql11-http-rdf-update-20101014/
Thanks for your work on this. Some suggestions:
1. Section 4.1 says that the request URI "is meant to identify RDF
triples", and it says that it identifies "the RDF knowledge that is
represented by an RDF document". I think both of these
characterizations are problematic because they are both immutable,
whereas the point of this protocol is to specify how HTTP can be used to
modify graphs. In other words, the URI needs to identify the
*container* -- not the (current) contents of that container. The
contents of the container may be a particular set of triples, but a set
is an abstract concept that can never be changed, just as the number 42
can never be changed. But if the URI identifies the *container*, then
we *can* change the content to hold a different set of triples, which
the URI still identifies the same container.
2. Section 8 quotes the AWWW definition of "information resource". I
think this definition is well known to be flawed, and hence should not
be perpetuated or used as the basis of any sort of logical argument.
3. Actually, I think the whole httpRange-14 issue and the question of
what the URI "identifies" is a distraction from the main goals of this
document and can be omitted entirely if the document instead focuses on
what is supposed to happen for each HTTP operation, much like the way
RFC 2616 focuses on what is supposed to happen rather than delving into
theoretical points about what a URI identifies. In other words, I
suggest framing this document more narrowly as a protocol spec rather
than as an architectural analysis:
- GET on the URI of an RDF Graph Store with no "?graph=..." query
parameter returns the default graph;
- GET using the "?graph=..." query parameter returns the specified
graph;
- PUT replaces the graph; etc.
I think this will significantly simplify the document and make it more
accessible and convincing to a wider audience.
4. Typos:
s/The response to such a SHOULD/The response to such a request SHOULD/
s/SHOULD be be understood/SHOULD be understood/
Thanks!
--
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/
Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.