Re: Proposal: 'tag' URIs

At 10:01 AM 4/27/01 -0400, Sandro Hawke wrote:
>Philosophically, you can say "tags are really names".  But aren't all
>identifiers really names?  Perhaps there is some distinction between
>identifying things by qualities (like how you might find them) and by
>some outside-the-system mapping between names and objects in a domain
>(like the thing just has a name), but I don't know how that could
>matter.  There are lots of "arbitrary" URIs not using URN syntax, like
>"mid:" and "data:".  Are those historical anomolies, which really
>should have been URNs?  I don't understand this line well enough to
>figure out where mailto: should go.  It's just an arbitrary name for a
>mailbox, right?

Our proposal rejects URNs for the given requirements. There are two 
practical reasons why URNs do not meet the requirements, from my point of 
view. One, as Sandro says, is their administrative overhead. To buy into 
URNs I have to register a new name space even though, as we show, my 
assigned domain name or even email address suffices to achieve uniqueness 
over space and time. The cafe or the gallery down the street, which wants 
to identify itself and objects within it, is effectively precluded from 
using URNs but can use tags (assuming the owner has at least an email 
address) without consultation with anyone else.

The other is that URNs are predicated upon default naming contexts in which 
they are to be looked up: if I give you a URN then you're likely (if URNs 
ever take off) to try to resolve that URN in the default context. 
Similarly, if I were to use a URL as an identifier, you're likely to try to 
dereference that URL. In each case, your action would be reasonable. And 
wasteful. And it wasn't what I intended!

Tags are specifically intended to be 'agnostic' with respect to any 
particular resolution scheme. It's not that they will not get resolved (in 
CoolTown, resolution, usually to URLs, is precisely what we do with them) 
-- but we want all resolvers to be equal, and for the choice of resolver to 
be made in context, not mandated as a simple function of the given URI.

Tim.

Tim Kindberg

internet & mobile systems lab  hewlett-packard laboratories
1501 page mill road, ms 1u-17
palo alto
ca 94304-1126
usa

www.champignon.net/TimKindberg/
timothy@hpl.hp.com
voice +1 650 857 5609
fax +1 650 857 2358

Received on Friday, 27 April 2001 10:52:56 UTC