From SPARQL Working Group
Hello, Greg. Thanks for your comments, see the response(s) below (in context). I had some difficulty in some cases parsing out the substantive points in your comment that were both in scope and addressable via modifications to the text. In some cases I will ask for clarifications and possible suggested text. In others, I will try to paraphrase your point to ensure I understood it. Please indicate if the responses (and modifications) address your concerns or if there are concerns you mentioned that were not either addressed in this response or for which I didn't ask for clarification.
In summary: - In my view this document is unnecessary and possibly harmful.
Can you elaborate how this document is harmful beyond the issues you have raised (presumably with the intent that they be addressed by modification to the text)? Are you saying that the text is not salvageable given its original aim, which is to define how the HTTP protocol can be used natively (i.e., in a manner consistent with the constraints of REST) to modify the graphs in a graph store?
I don't see what this document adds; or rather, I don't see what problem it addresses that is not already addressed elsewhere.
There is no existing specification of how HTTP methods can be used to manage RDF graphs in a manner that takes immediate advantage of the semantics of the underlying protocol. The existing protocols (in a manner similar to SOAP interfaces) use HTTP POST to dispatch operations where the actions taken are defined by the content of the message rather than the semantics of the protocol (which specifies how resources are manipulated via the various methods: DELETE, GET, POST, etc.). This protocol is meant to address this by defining a protocol that uses the constraints of REST to define how RDF graphs can be manipulated directly and natively in HTTP.
"RDF knowledge". Please don't do this.
After some discussion this term will not be used. The current editor's draft has been modified to use the term 'RDF Graph content' as a result of discussion within the WG regarding an alternative. Later in this comment, you suggest that an alternative term would not address concerns you have about how the notion that IRIs "identify resources" is problematic. Is your comment that this particular phrase should not be used, or that something more systemic is at fault?
In my view the source of the problem is probably the notion that RDF somehow represents or encodes or [pick your verb]s "knowledge", which in turn is probably traceable to the notion that IRIs "identify resources". Both ideas are fundamentally wrong in my view; RDF is about graphs, not knowledge,
The term 'RDF Graph content' (although it doesn't use the word 'knowledge' which many found not helpful) does distinguish between the syntax (or structure) of an RDF graph and its meaning (or content). This follows from the model theory of RDF, which provides a way for RDF graphs to be interpreted and there is an understood (as with other such formal languages such as in OWL for instance) distinction between the statements or sentences of a language and the meaning that they convey. Whether or not this distinction is problematic for RDF as a whole is not in scope for what this protocol intends to do and is probably better directed at the new RDF working group, perhaps. However, the point with the term 'knowledge' has been taken.
and the IRI may or may not identify something (just because TBL et al. used "identifier" in the name does not make it an identifier *of* something). "Resource" is just a way of saying "we can't think of a better term".
Note that RFC 3986 is very clear in stating that URIs do identify 'something', even if the term used to define what that something is is (admittedly) vague:
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.
Now suppose I declare "let x be the integer 3". Will anyone think it important to draw a distinction between "the integer and what x identifies"?
This distinction is in fact very important to the use of model theory to specify (in a mathematical way) how the meaning of a formal language can be determined in order to facilitate machine understandability. For example, the RDF model theory does indeed distinguish between a URI reference and what it 'denotes':
The semantics treats all RDF names as expressions which denote. The things denoted are called 'resources',
It is not clear from my reading your comment if your issue is with the RDF model theory or if it is with some liberties that have been taken in the document you are commenting on. Can you clarify?
Compare: "in using x to refer to the integer 3 in this way, I am not directly identifying the integer but rather the mathematical knowledge it represents." You'd be laughed out of town.
The distinction you are quoting before your statement above (between the what the IRI of a graph in a dataset identifies and the graph itself) is part of the SPARQL 1.0 specification (see the end of 8.2.2 Specifying Named Graphs). Do you take issue with that part of the SPARQL 1.0 specification or with something unique to the specification you are commenting on?
An IRI that is used to name an RDF graph refers to that graph,
This is not the case. Please refer to the section of the SPARQL 1.0 referred to above, which states:
The FROM NAMED syntax suggests that the IRI identifies the corresponding graph, but the relationship between an IRI and a graph in an RDF dataset is indirect. The IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph). For further details see [WEBARCH].
To be honest I think the problem goes back to the use of model theory to provide semantics.
This suggests that your issues have more to do with the (semantic) foundations of RDF rather than this particular specification. Is this the case and if not can you elaborate on the distinction?
I hasten to add that your text does touch on the critical issue, albeit only in passing. That is the issue of open-world semantics.
This issue is beyond the scope of the protocol which only attempts to define how HTTP can be used to manipulate RDF graphs. Unfortunately, I had some difficulty following your description of an 'open graph' or how it is relevant for the intention of this specification.