Message-Id: <199404211858.LAA25060@rock>
From: Terry Allen <terry@ora.com>
Date: Thu, 21 Apr 1994 11:58:35 PDT
To: uri@bunyip.com
Subject: More URIURC
Thanks to all for the response to my recent query; please bear with
me through some additional comments based on bibliographic concerns
rather than protocol considerations.
I had thought it might be sensible to have a basic URN>URL resolver
for the case of a URN that names something that is available in only
one format, one edition, one language, and so on. In this case no
meta is required to come up with URLs. But apparently the wrapper
for this URN and its associated URLs is to be a URC anyway, so this
supposedly simple case needs no special handling (and it isn't really
so simple: the thing named by the
URN might be stored in compressed format in one place, uncompressed
in another; and some meta about the URLs may be needed to deal with
user prefs).
I am concerned, as Mitra is, about distributing URCs around among
a number of servers. Now it is true that this is the way our libraries
catalogue books: the National Union Catalogue is real useful, but
there are others; to get all the biblio info possible one must
consult several catalogues (and in many major libraries, more
than one catalogue even under the same roof). But there aren't
too many top-level catalogues, and consulting one of them is enough
for most purposes. These catalogues are mirrored (in the case of
the NUC, in print), and derivative catalogues are constructed for
local collections. But these derivative catalogues, for the most
part, don't contain additional info not in the top-level catalogues
(rare book rooms excepted; their catalogues provide details about
specific copies of books, for example).
I bring up the library parallel partly because it deserves emphasis
(let's figure out what we're doing before we consider how existing
protocols can do it) and partly because it pertains to the second
point on which I queried Mitra: who's in charge when it comes
to URCs. I maintain that it isn't the publisher.
Mitra suggests that the publisher arrange for a service to
handle URN>URC resolution, evidently on the assumption that
the publisher controls or may controls what URC resolution service
a URN query will lead to. But URCs, unlike URNs, may be constructed
*by anybody*, just as anyone may catalogue a book. Users will want
to use the best such service they can have access to, not necessarily
the one suggested by the publisher.
On something of a related issue, Ron Daniel suggests filing URNs of citations
within a URC for the original source; I'd say that a collection composed of a
work and annotations about it is a (virtual) collection, which
deserves its own URN, and I join with Jon Knight in wondering why
a URC service (the equivalent of library cataloguing staff) is to
be burdened with this job. In addition:
rd> However, not everyone thinks that URCs should be like this. As an
rd> example, consider when we want to write documents that are
rd> annotations, critiques, or extensions of earlier documents.
There is a difference between writing annotations and publishing
a new edition of the original text that includes those annotations;
likewise with extensions of earlier docs. If you want to
publish such a new version (text+anno, or text+continuation)
you'll have to use a piece of *your* name space to construct
a new URN, as well as securing the permission of the original author,
if the work is under copyright. If you just publish a critique
as a separate item, it still needs its own URN, but, yes, it would
be useful to have some sort of Uniform Title thing to wrap
around the whole collection (original work plus all commentaries
and critiques of it). I should think that it would be up to
librarians to assign URNs to collections of this sort, and
to compose URCs to handle them.
-- Terry Allen (terry@ora.com) Editor, Digital Media Group O'Reilly & Associates, Inc. Sebastopol, Calif., 95472