Re: Comment on "Dataset HTTP Protocol": Uses of "indirect"

Hello, Kjetil.  Sorry again for the late response on this thread as well.

On Fri, 25 Mar 2011, Kjetil Kjernsmo wrote:
> Another problem with the Dataset protocol: It seems to talk about direct and indirect graph identification in two different contexts. The first is to distinguish between direct (i.e. GET the request-URI) and indirect graph identification (i.e. use a graph query parameter). For want of a better term, I think this is OK. 
> 
> However, in section 4.1, about direct graph identification, it says "However, in using a URI in this way, we are not directly identifying an RDF graph but rather the RDF graph content that is represented by an RDF document, which is a serialization of that graph." 
> 
> I must admit that I cannot se how this usage is founded in Webarch. Quite to the contrary, when webarch talks about indirect identification, it is something quite different: 
> 
> http://www.w3.org/TR/webarch/#indirect-identification 
> 
> In RDF terms, this kind of indirect identification would amount to something like: 
> 
> <uri-of-nadia> foaf:mbox <mailto:nadia@example.com>
> or 
> 
> <uri-of-british-prime-minister> ex:residence [ vcard:adr "10 Downing Street" ] 
> 
> 
> 
> I must admit that I get a bad gut feeling whenever I hear that a URI indirectly identifies something, so perhaps my gut feeling clouds my rational evaluation, but it seems wrong to me. 
The primary mechanism being re-used here is that of RFC3986 [1], which say in 3.4. Query (more on this later):



"[...] query components are often used to carry identifying information in the form of "key=value" pairs and one frequently used value is a reference to another URI"

However, this is not in conflict with how that Webarch document discusses 'indirect identification' as it also goes on to say (in the second paragraph):

"Globally adopted assignment policies make some URIs appealing as general-purpose identifiers. Local policy establishes what they indirectly identify."

In the nadia@example.com example their indirection is to prevent mailto:nadia@example.com from identifying both an Internet mailbox and Nadia, the person. In this case, there is no concern for collision as the full IRI is understood to identify RDF triples to manipulate as a result of the policy. RFC3986 permits this:

"The query component contains [..] along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)"

In this case the local policy specifies that an implementation perform the requested operation on the resources identified by the embedded IRI.

We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.

Regards,

Chime Ogbuji, on behalf of the SPARQL WG.

[1] http://www.ietf.org/rfc/rfc3986.txt 

-- 
Sent with Sparrow (http://www.sparrowmailapp.com)

Received on Wednesday, 8 August 2012 19:13:04 UTC