- From: Michael Mealling <michael@bailey.dscga.com>
- Date: Fri, 27 Apr 2001 10:50:48 -0400
- To: Sandro Hawke <sandro@w3.org>
- Cc: "Roy T. Fielding" <fielding@eBuilt.com>, Tim Kindberg <timothy@hpl.hp.com>, uri@w3.org
On Fri, Apr 27, 2001 at 10:01:39AM -0400, Sandro Hawke wrote: > > Creating a specific URI scheme to do what can be done by any existing > > URI scheme (namely, allow an authority to define a unique name) is a > > total waste of time. > > To our knowledge, no existing scheme meets our requirements. Can I find your requirements somewhere? > If you > know of one which does, please let us know. All the schemes we know > about do not work for us because they have have at least one of these > problems: > > (1) significant administrative overheard Some URNs have this, some don't. It depends on how you organize your namespace... > (2) no provision against unintentional conflicting reuse (such as > when a domain name is re-assigned), URNs require that, once bound a resource, that URN cannot be reassigned to another resource.... > (3) a limitation on the class of things which can be identified > according to the specification (such as a mail message, for > mid: identifiers), or URNs have no such limitations.... > (4) a syntax which makes them impractical for humans to compare, > remember, or type correctly. This depends on how you organize you're namespace. There is considerable evidence that making the name 'human friendly' causes bad semantic drift and affects your ability to make the name 'persistent' or temporaly unique. > > ... you should use the URN syntax: at least > > then you will be arbitrary in the same way as the others. > > I don't see a reason for using URN syntax here, but perhaps I > misunderstand URNs. The two kinds of reasons one might use URN > syntax, as I understand it, are philosophical and operational: > > Philosophically, you can say "tags are really names". But aren't all > identifiers really names? Whether or not some identifier is a 'name' depends more on how you use it than its own structure. The question should be more of: what aspects of a given identifier make it easier or hard to use it as a name. You _could_ use an http URI as a name and it would work just fine. But due to domain-name reasignment and ties to filesystems that move, http URIs often make poor choices as a name that needs to be persistent beyond 100 years or so.... > 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. It depends on whether or not you want the identifier to out-live one or the other or be independent of other semantics... > There are lots of "arbitrary" URIs not using URN syntax, like > "mid:" and "data:". Are those historical anomolies, which really > should have been URNs? For those of us who use URNs, probably. But we're not going to make a huge stink about it. They're all URIs and thus exist in the same 'layer' of the web and have the same very basic semantics. > 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? Yes. But the question should be: what is it about mailboxes and how you'll be identifying them that determine whether one identifier or another will give you good, long term use. I could name all mailboxes using social security numbers but that creates yet another process of a lookup that you have to go through. Mailboxes aren't persistent so the identifiers don't have to be either.... > Operationally, the only reason I've seen for using URN syntax is that > it allows some browsers to potentially invoke some local database > lookup code to turn it into another URI (such as an http: one). But > we don't want that. If we wanted that, we would have used an http: > URI in the first place. URNs do more than that. Infrastructure and systems are being deployed now that provide all sorts of things for URNs (and URIs in general). For example, we're setting up a URN based service called a Personal Internet Name which is a permanent name for a individual or organization. The ISBN organization is in the process of registering a URN for all ISBN numbers... > If you're going to argue that we really DO want that, then you're > getting into per-application territory. Tim Kindberg can say why HP > Labs Cooltown doesn't want that. I can say why it's a useful > experiment (at least) in design of semantic web components to keep > certain terms free of pre-defined semantics. Other application may have > their own reasons. And that's why we have URNs. Its a framework within which you can define your own namespace but which defines a more specific set of semantics (persistence, location independence, etc) than URIs in the general case. -MM -- -------------------------------------------------------------------------------- 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 10:54:35 UTC