Subject: Article-level Document URIs

From: Rob Cameron <[email-masked]>
Date: Fri, 8 Sep 2000 09:23:43 -0700

I have some questions for members of this list.   (1)  How important, as
a potential application of URIs/URNs, is the ability to link to
any article published in a journal, conference proceeding or
institutional report series?

If you think that this an important application, then (2) how important
is it that an article-linking solution based on open identifiers
be available?   By open identifiers, I am referring to identifiers
that can easily be worked out by scholars and librarians for the
great bulk of the published literature.  I contrast this with a
closed identifier model such as the DOI, in which documents have
identifiers only when rightsholders register those identifiers.

I ask these questions because I have been working in this area
and I have a strong interest in developing a system of unambiguous,
persistent identifiers for published contributions to our
collective knowledge archive, together with a library-based network
for resolving references.

We do have a specific proposal together with an implemented
prototype that comprehensively addresses this topic.   This has
recently put out as an Internet Draft; an HTML version of the
draft has working links to demonstrate the technology.

Before saying more about our proposal, I would like to ask (3) if
are you aware of any other URN-based proposals that address this
topic.  I acknowledge that RFC 2288 does note the syntactic issues
in addressing this problem using SICI document identifiers, but
there is no proposed system that builds on it.  Otherwise
I can't find any semblance of a proposal that would provide
a comprehensive URN-based solution based on an open
identifier model.

Turning to our proposal, we have focussed on the specific problem
of bibliographic linking, much narrower than we understand the
scope of the general URN work to be.   For one, this gives us
an extremely simple resolution model that emphasizes local library
services with respect to referenced documents.   Specifically,
a user in some-domain.edu will be first directed to bibhost.some-domain.edu
for information and access to the cited item.  If the bibhost
does not exist, service is directed to a publisher-specified server
or to a global server.  The resolution hierarchy has been
implemented in a short bit of JavaScript that can be easily pasted
into HTML documents that use our framework.  (No browser modification
required.)

The emphasis on local library services allows libraries to provide
local context on access to items.  This includes access to paper-based
as well as digitally held items.  It includes access to site-licensed
materials that are otherwise not freely available.  It includes
other kinds of local context, such as document delivery options,
access to nonlocal items from partner libraries and the ability
to present items in the local language.   This is consistent with
the philosophy expressed in the SFX work, metadata-based approach
to article linking.

The focus on bibliographic reference also allows a relatively
simple solution to the namespace problem, at least to get started.
Our namespace has only three top-level domains: ISSN, ISBN and
RDNS.   However, RDNS is a parameterized domain that creates
individual namespaces for institutions that have a well-established
DNS name both owned by the institution and associated with it.
RDNS(sfu.ca) is the namespace for Simon Fraser University,
RDNS(bn.pt) is the namespace for the National Library of Portugal
and so on.

We think that our approach is philosophically consistent with the
URN concept as it applies to bibliographic linking.   However,
our mechanisms are different.   We have thus proposed that
it be created with its own URI scheme, "bibp" for bibliographic
protocol.   Significantly, this allows us to go beyond N2R or
N2L style resolution.  Although our Level 1 work deals only
with resolution, we think there is substantial area for
additional protocol development with respect to metadata sharing
(server-to-server interactions under BibP level 2).

We invite your comments on the Internet Draft entitled
Bibliographic Protocol Level 1: Link Resolution and Metapage Retrieval
http://search.ietf.org/internet-drafts/draft-cameron-tatu-bibp-00.txt
An HTML version with working BibP links (most recent browsers)
is available at
http://www.cs.sfu.ca/~cameron/draft-cameron-tatu-bibp-00.html

We also invite your answers to the three questions identified
above as a survey.

Robert D. Cameron, Ph. D.
Professor of Computing Science
Associate Dean of Applied Sciences
8888 University Drive
Simon Fraser University
Burnaby, B.C., Canada  V5A 1S6
http://www.cs.sfu.ca/~cameron/

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 8 Sep 2000 18:58:15 -0400

Howdy,

As an aside to the WG -- technically, this doesn't fall into
the WG's specific mandate, but I suggested to the IESG that this
was a good place to circulate for comments.

Rob, I'm not going to answer your questions directly, but a few
technical issues I had with your draft:

> 3.3 Default Local Server
>
>    The key characteristic of BibP Level 1 is the ability for a locally
>    available server to act as the default BibP server for a particular
>    user environment. The following conventions apply.
>
>     - The DNS (Domain Name System) alias bibhost is used to identify the
>       default BibP server (if one exists) in the the local environment
>       of the web browser or other user agent. For example, if a web
>       browser accessing a BibP link is operating in the univ.edu domain,
>       then the typical configuration of the local DNS resolver would
>       interpret the relative domain name bibhost as the fully qualified
>       domain name bibhost.univ.edu (if it exists). In accord with the
>       recommendations of RFC 2219 [RFC2219], bibhost is the conventional
>       DNS alias for the BibP protocol.

For all RFC2219 does recommend certain conventions for naming hosts,
you're essentially making it a requirement that the host be
so-named in order for a client to "find" it.  Some cases where
this will be inappropriate:

        . if the administrator of the bibhost doesn't have
          control over the DNS entries for the local domain

        . if there is more than one server within a subnet

        . if it so happens that the machine named "bibhost" is
          actually already assigned (unlikely, but possible)

Generally speaking, diddling with DNS to do discovery doesn't seem
to live up to the robustness & longevity that you seek to provide
in these identifiers.

Analoguous qualms with:

>    - A bibhost server must signal its ability to respond to BibP Level
>       1 requests by provision of HTTP access to the BibP Identification
>       Icon at the URL http://bibhost/bibp1.0/bibpicon.jpg. If this icon
>       is unavailable, a user agent may direct resolution of a BibP link
>       to the next level in the server hierarchy.
>

I didn't read the document with the specific intention of trying
to implement it, but my feeling was that there are areas that
are vague and open to multiple interpretations.

Does anyone else have any comments on the technical side of this
paper?

Leslie.

--

-------------------------------------------------------------------
"Reality with a delicate splash of the imaginary...
    ... or was that the other way around?"
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------