Re: Review of "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"

Thanks for the detailed review.  Most of the suggestions were incorporated.
See response inline below.

On 12/22/09 12:29 PM, "Andy Seaborne" <andy.seaborne@talis.com> wrote:

> == Review of SPARQL 1.1 Update
> SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs
> CVS v1.20
> 
> == Overall:
> 
> 1/ See comments about relationship of documents
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0660.html

The references to SPARQL-HTTP in that review suggest that there was some
forthcoming text that should be copied into SPARQL-HTTP to better relate the
two documents.  Has this text been written yet (I wasn't able to find it in
the discussion threads regarding that review)?
 
> 2/ Do we support graph naming via
> http://host/graphstore?graph=http://other/graph?

Yes, I have added text describing this interface
 
> Throughout section 4, equivalence of the HTTP operation and SPARQL
> Update language uses <request_uri> but what if the request-URI is
> http://host/graphstore?graph=http://other/graph ?
> 
> This should affect http://other/graph in the store.

I removed the use of <request_uri> in the SPARQL update snippets.
 
> We need to have text that discusses the transformation from "X?graph=Y"
> to <Y>.  I believe this is the intent (please confirm) but the content
> does not discuss it and contradicts it in examples and in the editorial
> note of sec 2 where it is described as different from using the request-URI.

This has been addressed.  See below
 
> == Title
> "... for Managing RDF Graphs"
> 
> Minor: In SPARQL Update, managing graphs applies to creating and
> removing them but not changing them.

I was using 'managing' in a more general sense

> == 1 Introduction
> 
> Editorial:
> 
> "on an HTTP server."
> =>
> "over HTTP." or "at an HTTP service"
> 
> No presumption of how the server end is implemented or that there is one
> server.

Changed.
 
> [[
> This specification applies the HTTP protocol semantics in managing and
> modifying RDF graphs.
> ]]
> I don't think it is only intuitive - it really is the correct use of HTTP.

Changed.
 
> == 1 Terminology
> 
> Editorial:
> A second section 1!
> 
> "Network-manipulable RDF (Dataset)"
> 
> Surely this manipulates a graph store?  Terminology needs aligning.
> 
> In fact, all I see are graphs - there is no URI for the Dataset or graph
> Store is there?

There isn't.  However, the methods in this protocol only involve URIs for
graphs in an RDF dataset, so I use the term Network-manipulable RDF dataset
to refer to these graphs collectively.

> == 2 Protocol Model
> 
> [[
> This protocol does not constrain the form of the URIs that are used. The
> URI space of each server is controlled by the server.
> ]]
> This is at odds with foreign graph naming via ?graph=uri.

Removed.
 
> == 3 Graph Identification
> 
> [[
> We recall from [SPARQL] that IRIs for RDF graphs in SPARQL queries
> identify a resource, and the resource is represented by a graph (or,
> more precisely: by a document that serializes a graph)
> ]]
> 
> A graph is the abstraction - a set of triples.  The serialization only
> exists for the purposes of transfer through content negotiation.  A
> resource is not represented by a document from the point of view of a
> SPARQL engine when you get do GRAPH <uri> - it really is a set of
> triples at that point (the abstraction).  That is, you don't query the
> representation.

The relevant sentence came directly from the SPARQL 1.0 specification - see
right before 8.2.3, so I'm not sure how to reconcile the distinction you are
drawing with the language used there.  I have removed the editorial note and
replaced it with a section describing the indirect interface for managing
RDF graphs.  The diagram still needs to be updated accordingly.
 
> This would be a good point to discuss "?graph=uri" - this diagram and
> editorial note is the only place it occurs in the document.

The indirection described here is different from the more (newly) specified
interface involving query components.  Here, the text was meant to emphasize
that the URIs in the operations don't directly identify (which is allso
called out in SPARQL 1.0).  The use of ?graph=uri is now described in 3.2
Indirect Graph Identification
 
> [[ Editorial note
> The working group has also considered the need to use query components
> to specify the URI of the graph to manage. (e.g. the graph keyword in
> the above example). This would be different from using the Request URI
> of inbound messages to directly identify the networked RDF knowledge
> ]]

The note has been removed, since section 3.2 attempts to directly address
the issue.

> == 4 Graph Management Operations
> 
> The examples of SPARQL/Update do not work for foreign graph names.
> 
> Concrete example: suppose the PUT request URI is
> 
> http://host/store?graph=http://host2/graph1
> 
> Does a graph called <http://host2/graph1> get created in the dataset
> or must it be <http://host/store?graph=http://host2/graph1> ?

I've updated the leading paragraph in section 4 to indicate that <graph_uri>
is either the request uri or the URI specified via the given query component
form to clarify.  So hopefully, it should now be clear that in your example,
a graph called <http://host2/graph1> is created.
 
> == 4.1 HTTP PUT
> 
> Editorial: "SHOULD" was bolded in "1 Introduction".

I wasn't sure of your intent here.  The should in this section was not
bolded (or if it was, I have since changed it).
 
> [[
> This is only necessary if the identified facts do not already exist.
> ]]
> CREATE many still be needed - see ISSUE-20.
> 
> Empty PUT is equivalent to:
>   DROP SILENT GRAPH <request_uri>
>   CREATE SILENT GRAPH <request_uri>
> or
>   CREATE SILENT GRAPH <uri>
>   CLEAR <uri>
>

The suggested changes have been incorporated including an editorial note
calling out the dependency on the unresolved ISSUE-20
 
> == 4.2 HTTP DELETE
> 
> It's equivalent to DROP, not CLEAR, isn't it?

Fixed
 
> == 4.3 HTTP GET
> 
> Typo: /o => ?o

Fixed 

----------------------
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 06:25:13 UTC