[rdaniel@acl.lanl.gov: Re: FPIs to URNs]

Date: Wed, 04 Dec 1996 10:07:54 -0700
To: lee@sq.com, bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org
From: Ron Daniel <rdaniel@acl.lanl.gov>
Subject: Re:  FPIs to URNs
Cc: rdaniel@lanl.gov
Content-Length: 3053

Thus spoke lee@sq.com (at least at 09:07 PM 12/3/96 EST)
Ron Daniel(forwarded by Jon Bosak) said:
>> the N2C 
>> CGI script [...] starts to 
>> build a custom SOCAT on-the-fly by trolling through its huge 
>> catalog and only returning entries that match.
>
>If matching entries are based only on ownr identifier, N2C would
>need to have a list of every ISBN used in an FPI, with corresponding
>URLs, and also every registered owner.  This isn't the same as every
>ISBN ever issued, if you don't mind it failing on obscure ones that
>the owner had not registered with the orgnisation running N2C.
>Right?

Well, that would be the ideal, but this fallback to the big catalog in
the sky should be regarded as a "best effort", not a guarantee.
For one thing, there will be a large set of resources identified by an
FPI that do not have a URL.

>> This response might look like:
>> 
>> Content-type: application/socat
>> DELEGATE  -//Sun Microsystems::SunSoft//  
>>           http://www.sunsoft.com/sunsoft.socat
>> DELEGATE -//Sun Microsystems
>>           http://www.sun.com/suncat.socat
>[...]
>> This new mini-catalog is then processed by the client. It 
>> fetches the SunSoft catalog and procedes as usual.
>
>So how big would a CATALOG be of every SGML or XML public identifier
>ever issued at Sun?  Isn't this likely to be more than a kilobyte?
>I see problems with performance here.

Right. You don't want to do this sort of thing for on-the-fly
rendering of pages. You want to use local catalogs for that.
This sort of thing is only for when you have an FPI that
can't be resolved by way of the local catalog, and you are
willing to wait in the hope of getting the resource.


>It needs to be a more hierarchical namespace, so that noone needs
>to manage the whole list.

That can be accomodated pretty easily. bigcat.sgmlopen.org (or wherever
the "root" happens to be) could have a catalog with entries of the form:
DELEGATE -//U.S. Navy//CALS   http://www.navy.mil/foo/cals_catalog.socat
DELEGATE -//Sun Microsystems  http://www.sun.com/bar/suncat.socat
DELEGATE -//DOE//OSTI         http://www.osti.doe.gov/baz/ostifpis.socat

The root does not have to know ALL FPIs, it would need to know
of sites that make their catalogs available and the prefix that is
common to the entries in that catalog.

The US Navy might well want to split their CALS catalog into smaller
pieces, so it could have entries of the form
DELEGATE -//U.S. Navy//CALS//nuts-n-bolts
         http://www.navy.mil/stores/fasteners/nutscat.socat
DELEGATE -//U.S. Navy//CALS//paints-n-brushes
         http://www.navy.mil/stores/preservatives/paints.socat
etc.
Eventually one would stop being delegated to other catalogs and
would finally bottom out at a PUBLIC entry.
Ron Daniel Jr.                       email: rdaniel@lanl.gov
Advanced Computing Lab               voice: +1 505 665 0597
MS B287                                fax: +1 505 665 4939
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"

Received on Wednesday, 4 December 1996 15:21:19 UTC