I sent the following feedback yesterday to the W3C SPARQL Working Group on their proposal for a RESTful approach to managing graphs.

I reviewed the document at http://www.w3.org/TR/2010/WD-sparql11-http-rdf-update-20101014/ and enclose my initial comments below. Note that I stopped my review after section 4.2



Note: in my comments I use the word "represent" and "representation" only in the sense as defined by rfc2616.





Section 2



Graph Store is defined to be mutable. I don't see why it needs that requirement. The read only aspects of this document could apply to a non-mutable Graph Store



Section 4.1



I don't at all understand the need for the distinction in this document between a graph and RDF knowledge. I find the supplied explanation particularly confusing:



"we are not directly identifying an RDF graph but rather the RDF knowledge that is represented by an RDF document, which serializes that graph"



I have seen serialization and representation used interchangeably in many REST discussions but never seen them used as distinct operations so I don't know what to make of it really.



If my understanding of the terminology is correct than I think the relationships are that RDF Knowledge is the result of interpreting an RDF graph which may be represented by an RDF document. In this case the identified resource that is emitting representations is the graph itself. The RDF Knowledge is not explicitly named here, but could be somehow.



The immediately following sentence "Intuitively, the interpetations that satisfy [RDF-MT] the RDF graph serialized by the RDF document can be thought of as this RDF knowledge" implies that the Graph IRI identifies multiple things, i.e. multiple interpretations. It's axiomatic on the web that a URI (IRI) identifies only one resource so I see this as a conflict.



I assume the introduction of the term "RDF Knowledge" is motivated by an attempt to unify the concept of distinct document-like resources that you encounter on the web and an aggregation of the data in those documents as you might find in a database. I think this document would benefit from the removal of that term entirely and the addition of a section describing how a Graph Store might aggregate and interpret the graphs to form one or more datasets that may be accessed with zero or more SPARQL or other services. What form of entailment used by the Graph Store is out of scope of the document, but certainly will affect the behaviour of the SPARQL services it provides.



Section 4.2



The diagram implies that the encoded URI (e.g. http://www.example.org/other/graph ) and the indirect URI http://example.com/rdf-graphs/employees?graph=http%3A//www.example.org/other/graph identify they same RDF Knowledge. Does this imply this triple:





<http://example.com/rdf-graphs/employees?graph=http%3A//www.example.org/other/graph>

<http://www.w3.org/2002/07/owl#sameAs>

<http://www.example.org/other/graph> .



http://foo.com/graphs?graph=http%3A//www.example.org/other/graph

http://bar.org/rdf-data?graph=http%3A//www.example.org/other/graph

http://api.talis.com/dataset1/graphs?http://ex1.com/g?graph=http%3A//www.example.org/other/graph

http://api.talis.com/dataset2/graphs?http://ex1.com/g?graph=http%3A//www.example.org/other/graph