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

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

2/ Do we support graph naming via 

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.

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.

I have tried to pick out points inline where I see this as a signficant 
issue and ask for confirmation, or not, of the intent in a couple of places.

== Title
"... for Managing RDF Graphs"

Minor: In SPARQL Update, managing graphs applies to creating and 
removing them but not changing them.

== 1 Introduction


"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 

This specification relies on an intuitive interpretation of the 
underlying HTTP protocol semantics to determine how the RDF graphs are 

I would say something stronger:

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.

== 1 Terminology

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?

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

It's not server but service - may be several services on one server with 
different URIs managing different collections of graphs - because query 
is over datasets this is an observable difference.

The protocol does constrain the form of URIs to be local names under 
some point like http://host/graphstore/myGraph or of the form 
http://host/graphstore?graph=http://other (please confirm)

The URI space of each server
The URI space of each service (or service endpoint)

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

This would be a good point to discuss "?graph=uri" - this diagram and 
editorial note is the only place it occurs in the document.

[[ 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

This confuses me:

There are two cases:
a) local names where the graph name includes the service name
b) foreign names where the graph name can be at a different authority or 
have a URI prefix different from the service endpoint.

The "this would be different from using the Request URI" text seems to 
imply that foreign names are not supported.  Is that true?

== 4 Graph Management Operations

The examples of SPARQL/Update do not work for foreign graph names.

Concrete example: suppose the PUT request URI is


Does a graph called <http://host2/graph1> get created in the dataset
or must it be <http://host/store?graph=http://host2/graph1> ?

== 4.1 HTTP PUT

Editorial: "SHOULD" was bolded in "1 Introduction".

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>
  CLEAR <uri>


It's equivalent to DROP, not CLEAR, isn't it?

== 4.3 HTTP GET

Typo: /o => ?o

Received on Tuesday, 22 December 2009 17:30:12 UTC