Re: "RDF Knowledge" (Uniform HTTP Protocol for Managing RDF Graphs)

Hello, Greg. Thanks for your comments, see the response(s) below (in
context).  Note that I no longer have access to the email account
where I originally received the comment and so I wasn't able to
compose a reply with your original email quoted but will try to do so
by hand where necessary.

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.

On Wed, Jan 5, 2011, Gregg Reynolds wrote:
> 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.

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

-- Chime

Received on Wednesday, 2 February 2011 16:12:55 UTC