Re: OCLC's URN Services Proposal

Erik Jul (jul@oclc.org)
Thu, 8 Jun 1995 08:28:41 -0400


From: jul@oclc.org (Erik Jul)
Date: Thu, 8 Jun 1995 08:28:41 -0400
Message-Id: <199506081228.IAA04142@ws20-02.dev.oclc.org>
To: ietf-lists@proper.com, uri@bunyip.com
Subject: Re: OCLC's URN Services Proposal
Cc: weibel@fssun09.dev.oclc.org

Paul Hoffman <ietf-lists@proper.com> wrote:

> I fully expect that there will be different, more structured URC styles
> in the future.

To be fair, we should recognize that many well developed "URC styles"
currently exist, are broadly deployed, and supported by professional
communities and standards organizations, if by "URC style" you mean
methods of recording and communicating what is being called metadata
(or, as Mr. Hoffman called it, "metatext," being such information as
"who the author is or when [a book] was published," for example).

Thus, "more structured URC styles" do not lie in the future.  In fact,
the common challenges of all current URC schemes are how to exploit the
current state of practice so as to maximally benefit from cumulated 
knowledge and experience while simultaneously avoiding the invention of
schemes that fail to serve major stakeholder communities.  The benefit
of the former seems great, as does the risk of the latter.


> Throughout the document, you talk about URNs resolving to URLs, and I think
> that's wrong. Specifically, you say "URNs are meant to be resolved to
> URLs." I strongly disagree. In my mind, URNs do not resolve just to URLs:
> they resolve to URCs.

To extend this thought: perhaps a URN could be viewed as a token (to adopt a
very mechanistic metaphor).  Drop it in at the top, specify what you want,
and get your request out at the bottom.  Why not, therefore, imagine that
a URN could be "resolved" into the object itself, as well as any intermediate
representation?  Or, viewed another way as a continuum, the URN is the *minimal
object representation* on the one hand, and the object or resource is the
fullest manifestation on the other.  In between are URLs, that tell us 
where the object can be found; URCs (of many types), that tell us the object's
metadata (which may also include the URL); abstracts or other partial
representations of the object's content; up to the object itself.

To return to my arcade analogy, what we need are the tokens (URNs), a slot
to drop them in (resolver service), a mechanism of specifying the desired
output (some buttons to push), and a way of delivering the requested output.

All of this is to say that we need a smooth and continuous link between
the token and the object, and that resolution should not stop at the URC.

--Erik

Erik Jul
jul@oclc.org