Message-Id: <9310220300.AA26530@merit.edu>
To: jak@violet.berkeley.edu (John A. Kunze)
From: "Fred Swartz" <fred.swartz@umich.edu>
Subject: Re: URN definition -- a way out?
In-Reply-To: Your message of "Thu, 21 Oct 1993 16:57:08 PDT."
<199310212357.QAA19366@violet.berkeley.edu>
Date: Thu, 21 Oct 1993 23:00:56 -0400
> From: jak@violet.berkeley.edu (John A. Kunze)
...
>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?)
URNs should not address the sameness issue. This is purely
pragmatic; organizations which devote a lot of time to this
issue still have plenty of problems. Even I don't agree with
myself from one moment to the next. Or really from one purpose
to the next. "Sameness" is relative to some attribute. This
worthwhile task should be left to the naming authority, and NOT
put into a URx layer. Well, if someone wants to attempt it,
that's fine, but I think it's a massively impractical goal.
>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!).
Right, as above.
>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.
ditto.
>4. Adopt the document it and move on.
No, I think other worthwhile changes have been proposed.
>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.
I'm not feeling any grief :-). It seems to me a lot of very
good issues are being discussed. URNs are going to be a critical
element of the Internet, and I think it's far more important to
get it right than to have it done next week.
-- Fred (fred.swartz@merit.edu)