ISBNs and URI scheme support

ISBNs represent a realistic and widely deployed attempt at creating
unique and persistent identifiers for an important class of objects.
Of course, they represent a dated design with a number of flaws, but
there ought to be lessons that can be learned from their study and
attempts to implement web-based URI services using them.  I'll briefly
comment on some lessons and our current ISBN implementation work with
the bibp:ISBN scheme.

First, it is the intention that ISBNs "NEVER be re-used" according
to section 5.13 of the ISBN User's Manual. 
http://www.isbn.org/standards/home/isbn/international/html/usm5.htm
Now it may happen that errors are made.  For example, suppose
that publisher A publishes a book but inadvertently using
publisher B's publication code.  Publisher B subsequently publishes
a book with the same ISBN.  This is an example of a practical 
kind of error that can happen.  In this case, the answer is
quite clear; publisher A made an error and the ISBN uniquely
denotes the book of publisher B.  But there will be confusion.

It seems unfair to me to state that ISBNs do not meet the 
standards of URNs because of the potential for this type of 
error.   Especially as nothing in the URN namespace assignment
process enforces error-checking before assignment.  Oh well,
those who ignore history are doomed to repeat it.

Another important lesson from the widespread use of ISBNs is
to separate the processes of identifier assignment and 
identifier resolution.   Although publishers assign ISBNs,
they are typically resolved by libraries and bookstores 
when ISBN-based queries are made.   The evolving model is
that publishers will distribute metadata in regard to
a newly assigned ISBN at the time of publication.  Actually
the distribution of metadata in this way provides a strong
social force for maintaining identifier persistence.  In contrast,
if all resolution requests are funnelled through the original
assignor of the identifier, there is very little preventing
identifier reassignment.

Finally, we have been implementing a protocol and model for
decentralized bibliographic resolution with the ISBN namespace
as an initial example.  Using the URI scheme "bibp:" we
form an identifier by adding the prefix "bibp:ISBN/" to the
numerical identifier.

Although we are working towards native deployment of bibp logic
within browsers (e.g., the current lynx 2.8.4 distribution
supports bibp as a standard feature), we are able to support
about 90% of existing user contexts through a Javascript "bibp"
resolver that accompanies pages including bibp links.  It's the
only practical way to get deployability in a scalable model.

Decentralized resolution is achieved with an extremely simple
and flexible mechanism: the "bibhost" relative domain name.
For example, the academic library at stateu.edu can install
bibhost.stateu.edu to automatically handle bibp resolution
in that domain.  Individual users are permitted and encouraged
to make bibhost settings in their own hosts file.   This even
permits a "personal bibliographic server" you click on a
bibp:ISBN link and it brings up your own notes on this book
that you have in your collection.

In the absence of local bibhost support, a known global server
is searched.  We are building a model for that at http://usin.org/
to illustrate the concept.   Currently, we are working on a
concept called ZI-bot, standing for Z39.50-ISN robot.  When a
bibp:ISBN link is first requested through usin.org, we initiate
a search of hundreds of public Z39.50 servers to obtain world-wide
metadata from library catalogs.  This data is then cached to
displayed for future requests.  We have lots of work to do with
integrating other data from publishers, bookstores and book
review journals as well.

Rob Cameron
Professor of Computing Science
Simon Fraser University
http://www.cs.sfu.ca/~cameron/

Received on Monday, 27 August 2001 12:51:20 UTC