Re: Comments on SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs WD 20091022

Leigh,
Thanks for your comments.  Sorry for the delayed response.
Below is an account of our response to your comments regarding the SPARQL
1.1 Uniform HTTP Protocol for Managing RDF Graphs first Working Draft:

On 10/24/09 4:25 PM, "Leigh Dodds" <leigh.dodds@talis.com> wrote:
> Hi,
> 
> Some personal comments on the SPARQL 1.1 Uniform HTTP Protocol for
> Managing RDF Graphs, 22/10/2009.
> 
> * General question re: scope. The document at present describes a
> mechanism for coarse grained graph updates, and does not attempt to
> offer the fine-grained access that SPARQL 1.1 Update offers. But
> there's a wide spectrum between those extras. For example the Talis
> Changeset format and protocol provides a RESTful way to manage updates
> to RDF graphs that is more expressive than the protocol described here
> but less so that SPARQL Update. Are the WG likely to consider
> something like Changesets too? (I note as an aside that there's at
> least one completely independent implementation using Changesets).

Unfortunately, the initial scope of the document was to cover the minimal
behavior covered by an intuitive interpretation of the HTTP protocol
specification. As a result the granularity is quite coarse and more
fine-grained interactions were delegated to the SPARQL Update language.
 
> * The main SPARQL protocol specification includes a wording on
> scenarios where a SPARQL processor might refuse to carry out
> operations. Perhaps this document should include similar wording to
> note that implementations may be free to refuse to create, update, and
> delete graphs for a variety of reasons?

See the paragraph added to the 'Security Considerations' section to this
effect.
 
> * Section 4.1. Is a PUT to a graph resource with an empty payload
> allowed? i.e. can I create an empty graph?

See modifications to the end of section 4.1 (HTTP PUT) regarding the
semantics of an empty PUT request
 
> * Section 4.3. An HTTP POST is described as being mapped to a
> inserting an RDF/XML payload into the target graph identified in the
> Request-URI. This means that a client has full control over how the
> URI space of the server is managed. Having the option for the server
> to assign a graph URI, e.g. into which the payload is then stored,
> would also be useful. Typically this would be treated as a POST to a
> "container" resource, e.g. /graphs. The server would then deposit the
> data into a newly assigned graph URI and return a 201 Created response
> with a Location header to inform the client of its location.

See modifications to section 4.3 (HTTP POST) regarding this mechanism.

> * Section 4.3. Notes that conditional GETs should be supported
> wherever possible. What about conditional updates and deletions? This
> seems like a useful extension that could be documented perhaps as a
> MAY or a SHOULD.

Note that the language regarding conditional requests was moved from the GET
section into a general section that discusses the general use of
conditioning headers to indicate a conditional request.
 
> * Finally I think that the specification should discuss some of the
> different strategies for managing graphs, not to constrain
> implementations but to at least tease out some of the related issues.
> I think this relates particularly to the second editorial note
> relating to use of aliases, but also to how the graphs described in
> this document relate to the URIs of the dataset(s) exposed through the
> SPARQL service description mechanism.

I tried to better emphasize the issues related to graph naming , authority,
etc. as it relates to the HTTP RFCs.  Hopefully, the effort that went into
reworking this section addresses some of your needs here

Please indicate if these changes address your concerns.

Thanks

----------------------
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, 9 February 2010 14:22:36 UTC