Re: Comments on RDF Update Protocol for HTTP

Thanks for the comments.  Updates to the document are indicated below

On 10/1/09 9:22 AM, "Seaborne, Andy" <andy.seaborne@hp.com> wrote:
> 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.

I have added an example and some supporting text in the ' Graph
Identification' section.

> 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."
> 

This has been added to the section on the POST operations

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

I removed the term 'core' from the title, and changed it to:

"Uniform HTTP Protocol for Managing RDF Graphs"

to indicate (as you mentioned below) that the protocol is doing more than
just updates

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

I was trying to avoid the term REST because of the unnecessary burden that
comes with its usage.  I used the adjective uniform to essentially serve the
same purpose.

> == Sec 1
> 
> The first sentence is quite long.

I attempted to break up the sentence into its parts.
 
> """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.

The use of the word constraints was another attempt to appeal to the REST
style in a pragmatic way.  One of the major components of the REST style (as
I understand it) is to abstract the network protocol into a set of simple
components by constraining what those components are and how how they work
together.  So, one of the things I was trying to achieve was to take that
same principle and apply it to the general use case of RDF graph management
over HTTP.

I have incorporated some of the suggested text above emphasizing
deliverables and not constraints, but I've put a note about whether the
language is sufficient to demonstrate how we are appealing to the REST
style.
 
> == 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 have removed this portion of that statement.
 
> 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.

I have added a statement that a compliant implementation MUST accept RDF/XML
(which seems reasonable). I have expanded the editorial note to raise the
question regarding other RDF notation (such as Turtle) and GRDDL.

With respect to GRDDL, I have moved mention of it into the editorial note
with links to the GRDDL security section.

> == 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."

Done.

> == 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).

It seems to me that this behavior is already covered by HTTP PUT.  I'm not
sure, however, if that suggests that we should clearly indicate that the use
of HTTP POST on a non-existent graph is not allowed. I have added a brief
note to highlight this.
 
> == 5.1 (which is 6.1) HTTP GET
> 
> This is the same as CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <....> { ?s ?p /o }
> }, right?

Done.
 
> == 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.

I have added placeholders with @@s

-- Chime


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

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 (2008).  
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, 6 October 2009 16:22:44 UTC