# Re: URN definition -- a way out?

Dirk Herr-Hoyman (hoymand@joe.uwex.edu)
Fri, 22 Oct 93 11:36:52 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dirk Herr-Hoyman: "Re: Revision of Chris & Peter's URN paper"
- Previous message: Michael Mealling: "Re: Pre-houston video-conference?"
- Maybe in reply to: John A. Kunze: "URN definition -- a way out?"
- Next in thread: Fred Swartz: "Sameness useful -- but what does it mean? (ad nauseum)"
- Reply: Fred Swartz: "Sameness useful -- but what does it mean? (ad nauseum)"

    Date: Fri, 22 Oct 93 11:36:52 -0500

    Message-Id: <9310221636.AA17004@joe.uwex.edu>

    To: "Fred Swartz" <fred.swartz@umich.edu>

    From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)

    Subject: Re: URN definition -- a way out?

At 11:00 PM 10/21/93 -0400, Fred Swartz wrote:
>> 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.
>
If we leave out "sameness", then the URN does not look all that useful to
me for the applications I am working on. I believe we can allow the URN to
use for this purpose, without solving the question of what it means to be
the "same".

Consider that for the URN->URL lookup, there will need to be some way to
arbitrate which location to use, i.e. a protocol. Once we have a protocol
for location, why can't we scale this up to other dimensions/attributes? I
think type/format is one that alot of us are looking for, but others such
as language and cost could be done too. If we stop and just location
resolution, then we are going to have to reinvent this for type/format,
language and so on. No, let's do this right and within the URN!

There are a couple of example URN->URL lookup servers, I believe Rob Raisch
has one and a nice write up along with it. Both of these provide for
location AND type resolution.

Again, providing for this mechanism does not mean we have to decide with it
means to be the "same". It's just a mechanism. If we don't have such a
mechanism, then folks, such as myself, will create them on an ad hoc basis
and we will have a mess we'll never escape from (at least in my lifetime).
Think of this as a one-to-many mapping, if you will. We just need to
provide a protocol to resolve this to a single instance. Doing multiple
dimensions is really only a little harder than a single dimension
(location). And if a publisher chooses to assign a separate URN to every
type of a document, then fine. But let's have a chance, for those of us so
inclined, to provide for a client specified format when multiples exist.

- Next message: Dirk Herr-Hoyman: "Re: Revision of Chris & Peter's URN paper"
- Previous message: Michael Mealling: "Re: Pre-houston video-conference?"
- Maybe in reply to: John A. Kunze: "URN definition -- a way out?"
- Next in thread: Fred Swartz: "Sameness useful -- but what does it mean? (ad nauseum)"
- Reply: Fred Swartz: "Sameness useful -- but what does it mean? (ad nauseum)"