Date: Thu, 21 Oct 1993 16:57:08 -0700
From: jak@violet.berkeley.edu (John A. Kunze)
Message-Id: <199310212357.QAA19366@violet.berkeley.edu>
To: uri@bunyip.com
Subject: URN definition -- a way out?
The idea of an FAQ for URNs came up, based on the "foundation" premises
I posted a month ago. Looking back I have to admit there was an awful row
that pretty much derails that idea. What if we scale back for a second:
1. Start with Chris and Peter's Internet URN Draft (which needs changes).
2. Acknowledge that "relatedness" (i.e., things being "the same" except for
certain properties) is an area we're exploring, and state that URNs will
*not* address relatedness at all. Instead, that will be taken up at a
higher level inside a UR? structure -- maybe URV, maybe URC, maybe URM.
(... hey, wouldn't it be neat if we ended up with exactly seven layers?)
3. Concentrate on Chris and Peter's document:
3a. In the Intro, forget about "uniquely identifying" a resource -- just
"identify" it in a location independent way. If you start talking about
uniqueness, you invite back the entire relatedness discussion; you also
start suggesting rules on IdAuthorities that will be difficult to impose
(e.g., did you know that the same printing of the same book can get two
different ISBNs for the soft and hard cover editions? Otherwise they're
bitwise identical!).
3b. In the Motivation section, drop all mention of URN de-duping features.
The simplistic URN described in this draft collapses the list of URLs it
maps into down to one thing, and that's it. Not that the prose promises
very much, but knee-jerk readers such as myself (and we are legion) read
your de-duping hint as a cruel tease, dangling the fat and slippery red
herring of "relatedness" in front us. I'm suggesting that you minimize
the possibility of misinterpretation by leaving it out.
3c. In the Functionality section also strike mention of de-duping.
4. Adopt the document it and move on.
Ugly Drawback:
A URN is assigned by an entity after an examination of an object, often
after examining related objects. This is the perfect entity and perfect
time to assign relationships among objects. The URN layer is the natural
and cheapest place to carry this function.
On the Other Hand:
But we can't agree. Some say the user needs arbitrary transformations on
objects in order to produce related derivative objects. I say fine, that
kind of relatedness is still called/arbitrated/refereed by some entity,
if only because it performed the transformation. Another need has been
expressed to map between classes of related URNs, for example, from more
specific to more general. Both these needs beg entirely new URN-to-URN
mapping services with as yet undefined function.
That's why I'm wondering if we shouldn't just get in touch with our grief,
go with Chris and Peter's URN Draft, and move on.
-John