Re: URN Resolution Paths Considered Harmful

 > Mark Fisher wrote:
 > <snip>
 > > Because:
 > > 1) URN resolution services are just a database system; and
 > > 2) The most successful database technology so far (relational
 > > databases) does not include the resolution path in the query, but
 > > leaves up to the resolver;
 > > I think that we should follow the direction of other database
 > > systems by not encoding the resolution path into the URN.

Mark Madsen writes:

 > I would like to reiterate my agreement with this position in the
 > strongest possible terms.

I would say thanks for raising the issue, but I disagree in two
very different ways.

Yes, URN resolution is a database problem, but it is a different kind
of database than most since it is a large, global one.  A database
system that has access to all the identifiers in its domain does not
have nearly the same kind of problem as a large, global database that
cannot possibly keep track of all the identifiers in the world in one
place.  Thus the resolution problem becomes one of finding out which
part of a large distributed system knows how to resolve the identifier
without asking all of them.  The CNRI handle system finds the part by
having a globally accessible hash table.  A hierarchical system
further subdivides each part, thus there is a resolution path.

Now, while a resolution path is very useful for scalable resolution,
and it can be made persistent, as we describe for the path scheme, the
path itself does not have to be used at all in resolving the
identifier.  It can be used as an opaque string ignoring any hierarchy
that might be in it, and resolving it in some other completely
different way, such as by hashing it as in the handle system.  So it
is irrelevant if there is a resolution path encoded in a URN if you
choose to ignore it.  But if you don't have a resolution path encoded
in the URN, you certainly have no possibility to make use of it.

So my recommendation is that we do not impose on all URNs that they
do or do not encode a resolution path, or even necessarily a naming 
authority.

If you don't agree, please respond.  (If you do agree, I'd be happy
to hear from you too.)

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

Received on Friday, 14 July 1995 14:47:41 UTC