CommentResponse:KK-13

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, which in page 24 says (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:

 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 (in 3.4 Query) where it says:

 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.