W3C home > Mailing lists > Public > uri@w3.org > April 2001

Re: Proposal: 'tag' URIs

From: Michael Mealling <michael@bailey.dscga.com>
Date: Fri, 27 Apr 2001 11:32:33 -0400
To: Tim Kindberg <timothy@hpl.hp.com>
Cc: Sandro Hawke <sandro@w3.org>, "Roy T. Fielding" <fielding@eBuilt.com>, uri@w3.org
Message-ID: <20010427113233.Z15395@bailey.dscga.com>
On Fri, Apr 27, 2001 at 08:06:46AM -0700, Tim Kindberg wrote:
> 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.

Huh? You don't register a new URN namespace for each entity wanting to
assign a new subset of your tree. You simple define the characteristics
of the namespace and register that. How you assign below that is your
business and you only do it once. I.e. you could easily take the
entire 'tag' proposal and simply stick 'urn:' in front of it and be
done with it. From what I see the 'tag:' document you have would
make a pretty nifty URN namespace pretty much as is. You'd just need
to stick the registration template in RFC 2611 in an appendix...

> 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. 

If I did that I would be in error. URNs are not required to be resolved
to be used. There is a 100% optional resolution mechanism that aplies
to _all_ URIs that you could use to resolve a URN if you wanted to but
that 100% depends on whether or not you application wants to or not.

> 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!

And isn't what we intended with URNs either. The OID URN namespace
is fundamentally unresolvable outside some very constrained local 
context because there is not such thing as a global OID database.
There are _many_ cases where you use identifiers to do just that: simply
identify. Requiring resolution to be useful is wasteful of network
resources and something that is explicitly not a part of URNs.

> 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.

URNs made that exact same determination many years ago....


Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com
Received on Friday, 27 April 2001 11:42:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:02 UTC