UR Accessors

We need a new name for a URI concept that has been bouncing around
under the name "URC0".  A URC0 has been thought of as a set of URLs
(previously called a list of URLs) where any one of the URLs would do
as the identifier of the resource.  I want to generalize this further,
and distinguish it from the other URC issues.

The "C" in URC is either citation or characteristics, and it certainly
involves the concept of metadata.  As such, I have trouble with URCs
been even under the URI umbrella since identifiers are clearly simpler
beasts than general metadata.  If we go back to when URCs first
started squeezing under the umbrella, I think it probably has to do
with this set of URLs to provide location independence rather than
general metadata.  Nevertheless, this distinction can be made pretty
clearly, and therefore, this set of URLs idea needs a new name to keep
it from getting confused with general metadata.

Keith Moore mentioned the distinction between intrinsic metadata and
extrinsic access information.  (Others have made this distinction
too.)  In their case, the access information is a list of location
independent file names (LIFNs).  This distinction is the same concept
I am trying to get at.  More general than a set of URLs is a set of
URIs.

Maybe we should call this new thing a URA, with "A" for "accessor".
(Footnote: I have trouble with URAs being universal resource agents.
Why are they not just "agents"?  What do they have to do with
resources.  Agents probably ought to find their own umbrella anyway
since they are even further removed from identifiers.)

In the path scheme, we (Michael Shapiro and I) came up with the idea
of folding a fallback system into the path resolution process.  The
idea is that after trying one set of equivalent URIs and not getting a
satisfactory answer, you (the client) could try another set known by
higher-level path servers, and so on until you reach the root.  This
whole package of identifiers is an ordered list of sets of equivalent
URIs.  (Footnote: There could certainly be fallback mechanisms outside
the path scheme as well, but it seemed reasonable to build one in.  At
the root, we would probably want something like the handle service.)

When resolving a path URN in a proxy, we would like to return this
list of sets of URIs as a package for the client resolve in whatever
way it wants.  Either we do that or the proxy must resolve it, but
that is a problem for a number of reasons: It interferes with client
directed URI resolution, caching, authentication, etc.  In general,
clients should do as much as they can to off-load servers, and to do
things as they want to or need to.  

Another possible solution is to soup up the protocol by which clients
talk to proxies such that a proxy can ask the client to resolve a
URI or a set of URIs and the client does that and tells the proxy
whether it is satisfied or it wants another set.  This extension to
the proxy protocol (an extended subset of HTTP?) is not a bad idea to
consider.

One way or another, handling this list of sets of URIs involves
changes to clients, either to understand the new proxy protocol, or to
handle the list of sets of URIs itself.

Another reason to make this list of sets of URIs into an object that
can exist on its own rather than to treat it as just part of the
resolution process is so that it can be cached for reuse later rather
than recreating it each time.  (Footnote: At least for the path
scheme, it would be more appropriate to build a cache tree that
partially replicates the tree of the whole path name space, similar to
what DNS caches do.  Each node of the tree would be a set of URIs that
also references a higher level node, on up to the root.  This would
allow the higher level nodes in the cache to be shared.)

Another thing to consider in the generalization of the list of sets of
URIs is that for each URI, or each set of URIs, there could be
additional information about cost, speed of service, and other access
related things.  This should not go so far as to include various
representations, versions, etc; that gets into composite structures or
at least intrinsic metadata.

So in conclusion, I am suggesting we need a new name for the concept
of accessing resources.  This is not a URN, and not necessarily a
single URL, and not as much as general metadata.  The work on this
concept does fall under the URI umbrella whereas general metadata goes
too far.  "URC0" is ad hocish and confuses the issue, though it has
done well in the interim.  I like URA, for Universal Resource
Accessor, but I am open to other names.

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

Received on Wednesday, 14 June 1995 10:10:17 UTC