Changes to editor's draft of the SPARQL 1.1 HTTP Protocol

The following changes were committed to the editor's draft of the SPARQL 1.1
HTTP Protocol:

- Per Ian D.s comment, Serialize (verb.) was added to the terminology
section to clarify the use of the word between RDF graphs and documents
- All references to Network-manipulable Graph Store were removed (the use of
?default removes the last vestige of a distinction from a Graph Store)
- Other minor typos
- Added description of ?default mechanism to 4.2
- Added text describing that (for indirect requests via embedded graph
URIs), the part minus the query identifies the service which can be
targetted
- Added text tying in RFC-3986's statements regarding the scope of what the
path + query component identify to conclude that indirect, embedded
requests identify the same RDF knowledge as does the embedded URI itself
(this is new and figure 2 has been updated to reflect this)
- The behavior of the use of HTTP PATCH with SPARQL Update documents is
clarified along with appropriate status codes to respond with
- The non-normative language at the end of section 8 has been modified such
that the response to OPTION/GET requests to the service directly
return service description documents
- Added text clarifying what to do if the content-type header is not
provided
- Added text clarifying the use of 204 and 404 in response to HTTP DELETE
requests

The most substantive of the changes is the incorporation of text from
section 3.3 of RFC 3986 and what it suggests about what the fully specified
request URI of an indirect request identifies.  This is relevant to a
portion of Ian D.'s recent comments [1] where he asks if:

@prefix ex: <http://example.com/>
@prefix exGraphs: <http://example.com/other/>
@prefix oxl: <http://www.w3.org/2002/07/owl#>

<http://example.com/rdf-graphs/employees?graph=http://www.example.org/other/
graph> owl:sameAs exGraphs:graph .

That section in RFC 3986 states that data in the query component further
distinguishes which resource (within the scope of the naming authority and
path) is being identified.  So intuitively (with request that use embedded
graph URIs), the underlying graph store is scoped to the naming authority /
service, and graphs identified by the requests to this protocol are scoped
to this graph store.  That suggests that the full request URI *does*
identify the same resource as does the embedded URI (so the owl:sameAs
statement is true).

So, the scoping (with respect to naming) would be

|  .----------------------------------------------------.  |
|  |  .----------------------------------------------.  |  |
|  |  |  .----------------------------------------.  |  |  |
|  |  |  |  .----------------------------------.  |  |  |  |
|  |  |  |  |            RDF graph             |  |  |  |  |
|  |  |  |  `----------------------------------'  |  |  |  |
|  |  |  |              Graph store               |  |  |  |
|  |  |  `----------------------------------------'  |  |  |
|  |  |             HTTP Protocol Service            |  |  |
|  |  `----------------------------------------------'  |  |

For 'direct' requests, the authority and path fully determine the resource.
For 'indirect' requests, the authority (example.com:80) determines the HTTP
protocol service, the path (/rdf-graphs/employees) determines the Graph
store, and the embedded URI determines the graph targeted for the operation.

This could also provide a conceptual framework for TimBL's "Graph Mirroring"
usecase [2] in the sense that for graphs whose URIs can not be directly used
to manipulate them, they can be copied over to a different service and graph
store and accessed via the ?graph interface.

[1] 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Dec/0005.ht
ml
[2] 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Aug/0004.ht
ml  

-- 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 (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 Monday, 20 December 2010 19:51:11 UTC