Re: URC spec

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Tue, 13 Jun 95 17:20:47 CDT


Date: Tue, 13 Jun 95 17:20:47 CDT
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9506132220.AA21136@void.ncsa.uiuc.edu>
To: uri@bunyip.com
Subject: Re: URC spec
In-Reply-To: <9506130924.ZM1832538@macrdan.acl.lanl.gov>
 <9506130924.ZM1832538@macrdan.acl.lanl.gov>

Ron Daniel, Jr. writes:
 > ... Note that I am not
 > adding the ability for a name to resolve directly to the resource.
 > I am very hesitant to do such a thing. My take on the URC service is that
 > it provides the level of indirection between the name and the resource
 > that makes it possible to easily move resources, supply multiple copies,
 > ...

 > ...However, I am very hesitant
 > to allow the URN to return just anything. The whole point of the URN
 > was to get away from the problems we have with URLs by providing the
 > level of indirection. I can't forsee what all the consequences of
 > resolving directly to a resource are, but it has a warning bell going
 > off in my head.

I've been arguing for awhile now that a URN should be able to resolve
to anything, but this claim needs clarification and a bit of
correction.

First of all, it is possible for a name to be resolved into the
resource that it names.  If a particular resolution service wants to
return a location, then all you have to do (from the client's
perspective) is define the *full* resolution process as including the
resolution of that location as well.  Furthermore, it is important to
realize that it is *not* strictly necessary for a resolution service
to return a location (or a URC, or some other kind of indirection) in
order for the name to be persistent (i.e. live forever).  In other
words, an *explicit* indirection is not required in order to support
the requirements of a name.  I agree that indirection is required, but
it can be built into the resolution process.  The path scheme does
this since every step of the resolution process from the root down
involves a reference to the next level down until you get to the
object.

Therefore it would be an error to require that any URN must (or must
be able to) resolve to a location since, depending on the resolution
protocol, there might be no location to return.  But most people are
not arging for URN->URL as a requirement.

Second, requiring that a URN resolve to a URC is problematic.  If the
URC "is" a URL, this is the same as above.  If the URC is metadata,
what if there is no metadata?  At the very least, the URC would
*contain* another reference to the resource, its location or another
name, and we are back to the above.

Third, we should know in advance whether the thing that a name
resolves into is the resource itself or its metadata.  Consider if
what we want to reference is some metadata - not as metadata for some
resource but as data itself.  This might be useful if we want to
render the metadata itself, maybe edit it or annotate it.  If we know
in advance that names always resolve to metadata, then if a name
refers to some metadata, the name would resolve to *its* metadata.
Notice I am distinguishing what a name *refers* to from what it
*resolves* to.

If we cannot know in advance whether names resolve into data or
metadata, then it is still possible to distinguish what we are getting
back, with something like the Content-type header.  In this case, it
is not a type so much as a Meta tag.  But this seems bothersome.  It
seems simpler all around to say that, by default, a name resolves into
the resource itself, not its metadata.

Part of the problem is the somewhat arbitrary distinction between data
and metadata.  But at least we can distinguish a resource from some
other stuff that is associated with it by some "aboutness"
relationship - they are not the same thing even if we dont exactly
know how they are different.

Finally, the idea of having a number of services or methods associated
with names, so that we could resolve a name into a resource or into
its metadata, if any, seems reasonable.  But this is not much
different from the GET vs HEAD request of http.  

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/