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

Chime,

Thanks for making those changes.  A follow-on comments:

3.2 Indirect Graph Identification

[[
  with a query component of the form:
    ..?graph=http://other/graph
can be used to indirectly identify RDF triples to manipulate.
]]

Might be worth being very explicit and saying (1) the target URI will 
%-encoded and (2) the URI to be used will be http://other/graph, after 
reversing the %-encoding.  It is often assumed that %-encoding is an 
escaping mechanism but it isn't and it's a source of confusion.

	Andy

On 12/01/2010 6:24 AM, Chimezie Ogbuji wrote:
> 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.
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Received on Tuesday, 12 January 2010 09:24:12 UTC