Date: Tue, 5 Oct 93 14:58:55 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9310051358.AA04429@www3.cern.ch>
To: Jon_Bosak@novell.com
Subject: URIs Was: A different approach to linking
>Date: Tue, 5 Oct 1993 00:55:39 -0400
>From: Jon_Bosak@novell.com (Jon Bosak)
>I've been rethinking this whole business of linking between books
and
>have come to the conclusion that the approach to addressing that's
>been adopted so far in this discussion is opposite to the direction
>that I think would best serve the kind of books that I am
responsible
>for publishing online....
>
>A couple of things seem to be generally agreed upon:
>
>1. You can't put system-dependent addresses directly into portable
>documents (unless the target document is in fact unique and exists
in
>just one physical location, such as a manuscript in the Bodleian
>Library), and
>
>2. It therefore follows that the association between the link target
>specification in the source document and the physical location of a
>copy of the target has to take place in a separate mapping.
I think you'll have most of the information world
in agreement with you here. I suggest you join the
URI working group of the IETF to meet other people
trying to solve these problems. There isa consensus
tha the net addresses (URLs, uniform resource
locators) which we are forced
to use (through want of an instrstructure for anything
better) should be replaced with a logical "URN"
(uniform resource name). Ther is much discussion about
how the mapping should be done, and what the models
are of differt versions, etc of works. Look at the
archive of recent discussion (where is it?) for
some of the points maybe. I think you will find these
issues addressed.
>As far as I can tell, all of the approaches that have been suggested
>so far assume that the link mapping adheres somehow to the source
>document rather than to the target. I now believe this strategy to
be
>fundamentally incorrect. The mapping belongs at the target end.
Well, the mapping function at least down to the document
level is seen as an independent function of a naming
authority whcih will need a distribted replicated
naming scheme to solve at the technical level.
Often, names will be maintained by the people who
provide the document source as well, but not
necessarily.
>Referencing one book from another is not a new thing. On the
>contrary, this is something that we've been doing for quite a while,
>and over the course of many centuries we have worked out a method
that
>works pretty well. Suppose that I am writing a book and wish to
>direct you, the reader, to another book. I say something like, "See
>the section titled 'Love of Learning, or overmuch Study' in Burton's
>_Anatomy of Melancholy_ for the reasons that scholars go mad." Then
>you go find that book.
This method, of giving hints about a book like
its title and author, is of course in general a
heuristic. Karen Sollins (sollins@lcs.mit.edu)
is working in this area. Most others are assuming
a "name" is allocated someweher along the line.
>Notice that I, as the writer, say nothing at all about the physical
>location of the book (unless, as noted before, there is only one
copy
>in existence). The obligations on either side are well defined:
it's
>my job to tell you unambiguously which book I'm talking about, and
>it's your job to go find a copy.
The roles are seen as separate for
- author
- publisher
- name allocator
- name server
- information server
This all fits in with the case in which in fact you have
local CDrom copies of some books. But it is intended to
work for the general distributed case.
> [...]
>The correspondence between the library's card catalog and a map file
>is too obvious for me to belabor the point. What I'm getting at
here
>is the fact that the mapping lives at the target end, not the
source.
>It is part of the repository.
The card catlogue contains two sets of information:
Bibliograhic, allowing you to find the right work,
and holdings, allowing you to find an actual copy.
There is no reason for these two functions to be in the
same place. The URN/URL translation if the holdings
info. The bibliogrpahic information can be anywhere
else, independent of the holdings. Indeed, the keeping
of the copies and themaking of bibliographical
catalogues will be separate professions requiring very
different skills and machinery.
>There are two basic reasons that the mapping cannot be located at
the
>source end:
>
>1. There is no way that I, as the author, can know the location of
>the repository nearest to you that contains the referenced document.
Certainly.
>2. There is no way that I can know the "system-specific" access
scheme
>used by that repository.
Absolutely. Though you have to start somewhere.
>[...]
>For the role of unambiguous identifier I don't think that we have
>to look any farther than the SGML Public Identifier. I propose that
>each book be given a unique PID by its author or publisher and that
>the PID be displayed online in the book's copyright section or other
>easy-to-find place. This would give third parties the single piece
of
>information they need in order to unambiguously refer to the book in
>documents written outside of the original preparation process. (For
>DocBook purposes we might also wish to standardize an associated
>parameter giving the version number; I leave this as a detail to be
>worked out later.)
The URN tree and the PID tree I see as being subsets of each
other. That is, you will be able to smake up a PID for
any URN and vice-versa, using suitable subtrees.
This is all very timely, as the URI list needed a bit of info
in PIDs. The URN properties are being discussed now.
Tim BL
>+------------------------------------------+
>| Jon Bosak, Novell Corporate Publications |
>| jbosak@novell.com == jb@sjb.novell.com |
>+------------------------------------------+
__________________________________________________________
Tim Berners-Lee timbl@info.cern.ch
World Wide Web team leader (NeXTMail is ok)
CERN, CN Division Tel: +41(22)767 3755
1211 Geneva 23, Switzerland Fax: +41(22)767 7155