issue-57 Two cases of indirect 'identification'

Since I've seen two examples recently of people assuming that
'indirect identification' is a perfectly natural idea for hashless
retrieval-enabled URIs, I thought I'd record them in the www-tag
archives and let tracker connect them to issue-57.

At the recent TAG F2F we had the following:

http://www.w3.org/2001/tag/2011/09/13-minutes#item02
yves: The problem comes when you use fragment vs. SVG view box...
<masinter> and W3C shouldn't invent any more systems for using
fragment identifiers without having a markup equivalent.
<masinter> Using new data is a way in which that's been done
<masinter> and you can bookmark markup with data:

I interpret this to mean that a data: URI that carries a little bit of
markup (equivalent to some fragment identifier usage) could be
understood as 'identifying' what the equivalent fragment id would
otherwise identify, i.e. the thing that the fragment id and markup
both 'identify'. That is, it identifies something indirectly (using
the term from my issue-57 draft; used similarly in RFC 3986).

I'm probably reading too much into this, as Larry's word was
"bookmark", not "identify". But using data: for indirect
'identification' does seem like something that someone is likely to
want to do, eventually.

A second example is here:

http://www.ietf.org/mail-archive/web/urn/current/msg01627.html
"These URN:NBNs will be resolved to work level metadata, which should
include links to manifestations of the work."

That is, some urn:nbn:... URIs will resolve (I take that to mean
retrieval, equivalent of HTTP 200) to a description of the thing the
URI 'identifies'. Again, this is 'indirect'. ... Maybe I'm
overinterpreting again, but this seems notable.

Add these examples to our list of existing indirect identifications in
the wild, including the (probably unintentional) Flickr and Jamendo
ones, and the intentional Talis and (withdrawn) Pat Hayes ones.

Jonathan

Received on Thursday, 13 October 2011 13:53:43 UTC