Date: Thu, 7 Apr 94 17:43:42 -0400
Message-Id: <9404072143.AA00299@zippy.lcs.mit.edu>
From: Karen R. Sollins <sollins@lcs.mit.edu>
To: jak@violet.berkeley.edu
In-Reply-To: "John A. Kunze"'s message of Wed, 6 Apr 1994 11:24:10 -0700 <199404061824.LAA08273@violet.berkeley.edu>
Subject: URC's
My apologies for incorrect credit. It was unintended - all I can do
is apologize for a fuzzy memory of things that far in the past.
John, I'm glad you sent out your whole original message though, because in
that context let me describe what we are doing in the Information
Mesh, which is capturing those ideas slightly differently, as food for
thought for everyone.
To begin with, first each object has an identifier, which we call its OID
(think URN, lots of the same qualities, differences are not important
for this discussion).
Second, there are things called DESCRIPTORS. A descriptor has two
components the name of the object, in our terminology an OID, and a
QUALIFIER. An OID, as with URNs, does not itself contain location
information. The qualifier distinguishes a selection, region, or part
of the object in question. This is all part of the business of
identification, identifying some useful aspect or part of the object.
There is form of a qualifier that indicates "the whole object," in
case that is what's needed. Needless to say the qualifier is
expressed in terms the object can understand. For example, if the
object is an article that can distinguish individual characters (the
ascii text), but does not support any recognition of sentences, and I
want to quote or otherwise refer to a particular sentence, that may
have to be in terms of character counts, specifying the beginning and
ending characters of what I want. If the book supports pages, I can
specify in page 17.)
Third, there is something we call a LINK. It expresses a relationship
between two (or maybe more) objects or parts of objects. It thus has
a type and descriptors for the two things it is relating.
Fourth, we have left dangling the problem of location of an object.
This is handled through a HINT mechanism. Hints are, in fact, only
one sort of meta-information, that help in the business of finding an
object. Some hints may be generic to the object, while others may be
specific to particular instances. Hints may range from being very
specific and perhaps shortlived, eg addresses where the object was
recently know to exist, to much more long-lived and perhaps less
specific such as qualities of the object that might help narrow down a
set of mapper or location services that are in the business of mapping
OIDs to addresses (or URNs to URLs) and might be good bets for helping
to find an instance of the object. As I have mentioned it is in this
same sort of mechanism (artifact) that I expect to find other
meta-information that might be useful, such as access control,
charging or billing policy, etc. information.
This is a very quick summary of a different view of capturing the
ideas that John K. also was suggesting capturing, in that we have
distinguished links from meta-information. One reason to want to do
this is that there are situations (at least some) in which I might
really want links to be first class objects because I want them to
have OIDs or URNs. An example of the need for this is that someone
out there declares by means of a link that one document is a
refutation of another. This is not part of a third document, but just
a idea embodied in a link. I would like to be able to name that link
in order to be able to refer (cite?) it in something that I am
writing. I suppose the refutation link could be encapsulated in an
object, but not itself be an object, but this is just a round-about
way of saying that I need an OID or URN for the link. It is not
meta-information, but is the realization of something I need to be
able to identify as a first class object.
I believe that we are trying to capture the same or similar
functionality and concepts, but perhaps just slightly (or not so
slightly? :-) differently.
Karen