W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > February 2011

Re: Direct and indirect graph identification

From: Chimezie Ogbuji <chimezie@gmail.com>
Date: Mon, 7 Feb 2011 11:56:33 -0500
Message-ID: <AANLkTik0+xTwsj0CTtPT6ts-08X2VzFjoBOJaRfWz-A5@mail.gmail.com>
To: Gregg Reynolds <dev@mobileink.com>, public-rdf-dawg-comments@w3.org
Hello, Greg. Thanks for your comments, see the response(s) below (in context).

On Sat, Jan 6, 2011, Gregg Reynolds wrote:
> I see nothing indirect about a graph identifier encoded in the query string.

The indirection is due to the fact that when a request URI encodes a
graph identifier in the query string, it is not the request URI that
is used to determine which RDF graph is modified but the embedded URI.

> An indirect reference would involve a lookup table of some kind (e.g. "URI number 9"), which is not what happens in the query string.

The word 'indirect' is being used in the normal english language sense
rather than in any technical (or computer science-specific) sense. It
is a principle of REST that a resource identifier is used to identify
the particular resource involved in an interaction between components.
As this document attempts to define the semantics of manipulating a
graph store with the REST principles and constraints in mind, it is
necessary to clarify that (in this case) the request URI does not
directly identify the resource that is modified as a result.

> In my view it would be better to make this distinction in purely syntactic terms, e.g. there are two ways to encode a graph identifier in the IRI syntax.
> One is to make it the "Request-URI" (ref. to RFC2616) and the other is to encode it in the query string (ref. to RFC2616).

The distinction is more that just syntactic since  (as was mentioned
above) the protocol model is constrained by the REST view of
hypermedia applications which requires clarity in how resources are
identified by HTTP messages.

-- Chime
Received on Monday, 7 February 2011 17:04:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 February 2011 17:04:51 GMT