Message-Id: <9310222021.AA04357@merit.edu>
To: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)
From: "Fred Swartz" <fred.swartz@umich.edu>
Subject: Sameness useful -- but what does it mean? (ad nauseum)
In-Reply-To: Your message of "Fri, 22 Oct 1993 11:36:52 CDT."
<9310221636.AA17004@joe.uwex.edu>
Date: Fri, 22 Oct 1993 16:21:37 -0400
> From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)
> To: "Fred Swartz" <fred.swartz@umich.edu>
>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".
Of course knowing whether documents are the "same" or not will be
very important for some applications. Let's look at the simple
question for the URN draft: "should Postscript and ASCII versions
of a paper have the same URN?". I don't think it's worth our
while debating this, and I don't think it's the kind of ruling
that belongs in a definition of URNs. The answer to that question
will be made implicitly/explicitly by each naming authority.
>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.
I'm in complete agreement. Part of the problem with the current URN
document is that it fails to specify the semantics of URNs, the
operations that go along with them. You're saying you need some
that allow you to retrieve various other kinds of information (if
I understand correctly). How about making a specific proposal for
the operations on URNs that you need.
-- Fred (fred.swartz@merit.edu)
>
>
>