Date: Wed, 19 May 93 17:05:58 -0400
Message-Id: <9305192105.AA11622@zippy.lcs.mit.edu>
From: Karen R. Sollins <sollins@lcs.mit.edu>
To: clw@merit.edu
In-Reply-To: Chris Weider's message of Tue, 18 May 93 15:51:54 -0400 <9305181951.AA13334@merit.edu>
Subject: Comments on URN ID
Chris (and Peter and everyone else):
I strongly agree with the position you took in the URN draft document,
with respect to content in the names. If URNs are to be useful for
decades (I often try to think in terms of one or more centuries), they
had better not be dependent on anything that has semantics that may
change in that time frame. I can imagine that such information might
be:
* the name of the holder of the authoritative version
* the language in which it was programmed at some time or other
* anything about storage of it - which server, which part of the
storage structure, formatting, etc.
* the purpose or function of the resource
* access methods
and many others. Only those aspects or facts about a resource that
are immutable might be considered as candidates for being contained in
a URN. Of course, it is possible to include these sorts of facts in a
URN, on the assumption that not all the human-readable information in
a URN is correct, but is only there for uniqueness and recollection.
This leaves us with two options: (1) include this semantic
information, knowing that it may be incorrect, or (2) don't include
it. In both cases, an alternative mechanism is needed for either
verifying or learning such information. Chris and Peter, you have
called this "metainformation", we call it "factoids" in the
Information mesh. But this is the place for information, both because
it will allow us to present it in a more appropriate form as needed,
and because it is necessary in order to support the mutability of such
information. This additional information will be absolutely necessary
as part of the glue making the whole thing hold together, so why also
stick some of that information in an inappropriate place such as in
the URN.
I strongly urge you not to remove the part of the document that states
that URNs should not be what you call "human-readable". I believe
that it will affect the persistent naming functionality you/we are
trying to achieve and will increase the problem of duplicate
detection, since there may be many more alternate URNs for a resource
reflecting the changes in semantics in the name.
Karen Sollins