From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199404151348.AA08997@oit.gatech.edu>
Subject: Re: URN and citations (fwd)
To: uri@bunyip.com
Date: Fri, 15 Apr 1994 09:48:56 -0400 (EDT)
Keith Moore said this:
> Karen writes...
> > I'm not going to include your whole message here but rather just
> > address the point you are making. The naming authority (for example
> > publisher of a book) will assign URNs. What algorithm that naming
> > authority uses for determining whether two resources are "the same"
> > and therefore should have the same URN or different and therefore
> > should have different URNs is purely a decision of that particular
> > naming authority.
>
> The problem with this argument is that whether or not two resources
> are "the same" differs depending on your purpose.
<stuff deleted for brevity>
>
> The point here is that any particular idea of "sameness" used by the
> publisher may not be appropriate for all purposes. And the publisher might
> not really be sufficiently aware of my needs in order to assign the right
> variety of names, unless the publisher actually assigns a separate name to
> every instance of the object.
I can accept that argument. It doesn't preclude the use of URNs or make
them any less usefull. (Correct me if I'm wrong here, Peter) The
concept of sameness as it applies to URNs was specifically restricted to
intellectual content, not actual file difference or use to the user.
That would probably be solved by the combination of an LIFN and a SOAP
or some such critter.
> One means of doing this is to have a distinguished "location independent
> file name" (LIFN) for each valid instance of an object, with a description
> of that object (containing e.g. the MD5 signature) available from the
> naming authority. (I would think that the Trojan horse introduced in the
> wuarchive ftpd source code would convince people that such a function is
> necessary.)
>
> Ideally, this LIFN would be always used as the actual handle from which a
> location of the resource were derived. In that way it would be possible to
> verify the authenticity and/or integrity of a resource. Furthermore, a
> LIFN->URL mapping obtained from the naming authority for the LIFN, would
> provide reasonable assurance that the URL pointed to the correct (and
> current) version of that resource.
>
> URNs intended to identify fuzzier concepts (like "RFC 1521") could be
> defined in terms of several LIFNs associated with specific instances (like
> "the PostScript version of RFC 1521"). There could be hiererchies of
> resource descriptions, but the LIFNs would be at the leaves.
That's cool. I'm all for specifying another URI called an LIFN. Would
something like this work:
URN:bla (RFC1521 in your example)
LIFN:bla
MD%:8oo495687towf498t7ghwo948576fgo5
URL:bla
LIFN:bla
MD%:8oo495687towf498t7ghwo948576fgo5
Which gives you a) the URN so you can know that according to the
publisher those two are the same b) two LIFNs which also have
a corresponding URL listed for each. Now, what would be needed in
an LIFN? Do we need the concept of naming authorites here as well?
Or just a wrapper of LIFN: and then some opaque string that can
be resolved into a URL OR a URN?
> > In fact, there may be several naming authorities assigning names to
> > the same resources and one may choose to make different printings
> > distinct and another may not.
>
> While a publisher might choose to use the same name for any of several
> different representations of a resource, I believe there will always
> be a need for each representation of the resource to have its own specific
> name.
I agree but I would still leave that up to the publisher. For example,
my URC draft, did I need a name for it each time I saved and quit out
of vi? No. It was my choice as author/publisher that each on of those
versions was the 'same'. I agree it would have been nice to have a name
for each one but I don't have good version control....
I really do see URNs for collections with each member having it's own
URN. For example:
URN:bla
Title:Top 40 Records of 1993
Author: Casy Kasum (sp?)
Collection: URN:bla
URN:bla
URN:bla
URN:bla
URN:bla
> > It is not the business of this
> > architecture to make policy choices like that but rather allow
> > flexibility and heterogeneity in how these decisions are made. It is
> > for exactly this reason that version management, for example, is NOT
> > in the list of requirements.
>
> I'll note that the requirements of the "architecture" have not yet been
> agreed to. Furthermore, the requirements so far developed for the naming
> scheme, should be dictated by the requirements for the architecture, not the
> other way around.
But the one non-technical dictate is that it must be as flexible as
possible in order to accomodate the very different communities that will
use these things.
> We should carefully consider the limitations imposed by whatever
> architecture we develop. While I do not want the architecture to prevent
> similar representations of an resource from being recognized as such (or
> identified in a search for that object), neither do I want it to be so
> limited that it cannot provide for authentication and integrity guarantees.
I don't think we're in danger of limiting either of those. I don't think
they will be solved by URLs and URNs by themselves. I think we would
be very naive if we thought that URNs and URLs could do everything.
-MM
-- ------------------------------------------------------------------------------ Michael Mealling ! Hypermedia WWW, WAIS, and gopher will be Georgia Institute of Technology ! here soon via MIME. Your view of the Michael.Mealling@oit.gatech.edu ! internet is about to change completely!