Date: Sat, 16 Oct 1993 14:03:27 -0700 (PDT)
From: "Rob Raisch, The Internet Company" <raisch@internet.com>
Subject: URNs and Meta-Information
To: uri@bunyip.com
Message-Id: <Pine.3.03.9310161330.C10235-d100000@hmmm.internet.com>
Having thought about Peter's recent comments, I am struck by the impression
that we all have different, perhaps conflicting, goals in this effort to
design a URN.
Peter would like something which uniquely identifies a product of a publisher.
I agree that this is something of strong value and I believe the URN as
presently proposed would meet this need (with reservations - see below.)
Tim and others would like something which can be resolved into
retrievable references to products and this is also a very important
possible feature of a URN.
In fact, there are a great number of features which we need this thingy
for. Who is responsible for this product? Who should we contact for
access? Who do we pay? etc.
Each of these problems (as well as others) can be, I believe, answered if
we make a strong distinction between the name/identifer/etc. and the
meta-information we need to assign to it.
I would suggest we take the following steps.
1. Define what the URN looks like *WITHOUT* considering any other
function than it be considered a unique and authoritative reference
to a publisher's product. It is a name or an identifier which is
assigned by the agency which maintains authority over it and it
names or identifies what the agency determines.
2. Define a core set of roles or functions which this URN must serve.
Refine (1) in light of each new role. (If (1) is general enough,
this should be trivial.)
3. Define and implement how we might fulfill each new role.
I believe that we have a good idea about (1) -- with the possible
exception that I will mention in a moment.
I do not believe that we have nailed down (2), and we really need to do
this before we even begin to consider (3.)
--------------------------------------------------------------------------
Having said that, I think we have a problem with the general idea of the
URN, and I'd like to take a stab at defining it.
There is (in Peter's worldview) a primary role which the URN must fulfill.
That is that it must uniquely identify the product of a publisher. I would
suggest that this, in itself, is insufficient to make the URN a generally
useful thing.
Each of the above 'roles' which a URN might serve implies that there is
some meta-information associated with the URN. Thus, it is not simply a
label, but must act as, at the very least, a pointer to the source of the
meta-information needed to fulfill the other roles.
In the case of retrieval, this meta-information consists of a list a URLs
which can be invoked to retrieve the product. In the case of management,
this meta-information consists of an authority which maintains control over
the product.
Each of the roles I envision for the URN assume that there is some method
we can use to retrieve this meta-information.
But before we can retrieve the meta-information, we need to know where to
go to get it. Information must reside somewhere.
Peter and Chris' current recommendation for the format of the URN does not
contain any information concerning the location of the authority which
maintains this meta-information. An example might be the ISBN number.
I *know* that I can go to a library or book store with an ISBN number and
get a copy of the product it identifies or any other bit of
meta-information, like who the publisher is, etc. But, this is something
I had to learn.
I'd like to suggest that, without encoding the location of the authority
which maintains pointers to the meta-information, we must rely on a central
"authority of first resort." I don't think that this is a very good idea.
In the previous example, if we encode the location of the ISBN number
authority in the URN,
urn:urn.isbn.org:0000-0000000000 rather than
urn:isbn:0000-000000000
we know where to go to find out who maintains the meta-information. The
urn server at isbn would be queried with the opaque identifier, and would
return the proper service to contact to retrieve the necessary meta-info.
If we use the (urn:isbn:0000-00000000) form, we need to go to some central
and generally accessable authority to find out which service maintains
authority over the 'isbn' URN namespace, which we must contact to find out
which service maintains authority over the '0000-00000000' opaque identifier.
In other words, we must:
----
Contact the top URN authority to get the location of the isbn authority.
Contact the isbn authority to get the maintainer of the meta-information.
(This assumes that the isbn authority does not maintain all of the
meta-information for all products which have isbn numbers. I think that
we can assume this.)
Contact the maintainer of the meta-information to get the location of the
repository of the product. (This assumes that the publisher maintains the
meta-information about the product. Is this right? I think so.)
Contact the repository of the product to retrieve the data. (Assuming
that the publisher and the repository are different. I know that this is
needed.)
----
This looks like four seperate transactions to retrieve data from a URN. No?
At the very least, we need three seperate transactions: isbn-authority,
meta-authority, and repository. But, this assumes that the location of the
isbn authority is included in the URN.
Either that, or we must encode the location of the authority for each
namespace into each client. This also seems like a very bad idea for
obvious reasons.
Or am I way off track here?
</rr>