Re: HTTP RDF Update review

On 1/6/10 3:09 AM, "Lee Feigenbaum" <lee@thefigtrees.net> wrote:
> This is my review of http://www.w3.org/2009/sparql/docs/http-rdf-update/
> in discharge of action-167.
> 
> Overall, I support publication of th document as-is as a next Working Draft.
> 
> ~~~ general comments ~~~
> 
> * The introduction needs to explain the relationship (or lack thereof)
> between this and the SPARQL Protocol. This will also be helped if we
> assemble an overall SPARQL guide doc, but we don't have that yet.

I agree that a better explanation of the relationship between this and the
SPARQL protocol is needed, but I (unfortunately) don't have enough of grasp
of the larger picture (including caveats regarding WSDL bindings, etc.) to
produce text for such an explanation on my own.  It seems to me that this is
something that needs to be composed independent of both documents and either
repeated in both (as Andy suggest) or at least summarized in context in each
document.
 
> * Terminology. I think this section is well thought-out in terms of its
> precision, but nevertheless is difficult to take in as a reader of the
> specification. I wonder if we could move this to later in the document
> and hyperlink the terms when they occur in the context of the specification?

Treating this section as an appendix is a good suggestion.  However, I
hesitate to make such a drastic reorganization prior to the next working
draft.  I wonder how strongly you feel about making this change within this
publication cycle. 
 
> * I appreciate the lengths the document goes to to correctly interpret
> both the semantics of HTTP and of RDF. I think, though, that the
> document would benefit from presenting the most straightforward cases in
> a straightforward manner. Perhaps a section with examples that consist
> of setup (e.g. "a graph store stores graphs g1 and g2 and implements
> this protocol at URI u1"), request, response, and effect would be
> useful. These examples could also help the reader with the terminology,
> by making clear, e.g., what exactly is the networked-RDF knowledge in a
> particular example.

I will try to tie together a sequence of examples that walk through a
simple, common use case.

> ~~~ minor comments ~~~
> 
> * "This protocol specifies HTTP operations for managing
> network-manipulable RDF datasets as well as their semantics". Unclear
> what "their semantics" refers to. Suggest "This protocol specifies the
> semantics of HTTP operations for managing network-manipulable RDF datasets"

Changed.
 
> * In section 3, shouldn't the example request only have the URI path in
> the GET line?
> 
>     GET /rdf-graphs/employees HTTP/1.1
>     Host: example.com
>     Accept: application/rdf+xml
> If so, the text following the request needs to also be changed to
> reflect this.

Both have been changed
 
> * Section 3 - in FF3.6 on Windows, the image appears inline rather than
> below the text that references it.

I moved the <img .. /> outside the <p>, so this should be fixed

> * 4.1  "SHOULD can be used" -> "SHOULD be used"

Changed.
 
> * 4.1 I don't understand what "identified facts" refers to.

This has been changed to 'networked RDF knowledge' in order to be consistent
with the terminology.

> In any case, 
> I think it's not necessary to show shorthand SPARQL Update statements.
> It's most straightforward to give one SPARQL Update translation of each
> HTTP operation.

I tried to reduce the shorthand SPARQL Update statements in this section to
only 2.  However, I left

DROP SILENT GRAPH <graph_uri>
CREATE SILENT GRAPH <graph_uri>

In order to emphasize the relationship with ISSUE-20 (which is relevant to
the semantics of this operation) and the following editorial note on this.
 
> * 4.3 Is "subordinate" a standard term? If so, can it be referenced? If
> not, it's meaning in this context is not clear to me.

This has been changed to ".. the origin server incorporate the RDF payload
enclosed in the request with the networked RDF knowledge identified by the
Request-URI in the Request-Line."
 
> * 4.3 "usecase" -> "use case" ... but I don't think we need to explain
> the use case for POST, just what it is.

This sentence has been removed.
 
> * "4.3 HTTP GET" -> "4.4 HTTP GET"
> 
> * "/o" -> "?o"

Changed

----------------------
Chime (chee-meh) Ogbuji (oh-bu-gee)
Heart and Vascular Institute (Clinical Investigations)
Architect / Informatician
Cleveland Clinic (ogbujic@ccf.org)
Ph.D. Student Case Western Reserve University
(chimezie.thomas-ogbuji@case.edu)


===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S.News & World Report (2009).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Tuesday, 12 January 2010 07:01:25 UTC