Re: FPIs

At 13:29 27/11/96 -0800, Deborah A. Lapeyre wrote:
>
>On Wed, 27 Nov 1996, Paul Prescod wrote:
>
>> But PUBLIC identifiers put that redirection under the control of end-users.
>> There are numerous techniques for doing redirection on the server side.
>
>And that is why they are critical to me. Not that there may be lookup 
>but that there must be and on the client side.

I can't agree that lookup should be on the client side.

>But perhaps that is exactly what we are trying to avoid.  
>A URL is all on the front end.  An FPI is 
>by definition NOT on the front end and guarantees indirection.
>Are we trying to forbid indirection and force front-endedness?
>Is that the objection?

Hopefully not.

An interesting statement that was made at the W3C Internationalization and
Multilingualism Symposium last week was that persistent URLs (PURLs) needed
to be stored in a "library" that guaranteed long term access to the PURL.
The idea is that the library would redirect the PURL to the current storage
location for the relevant file. 

Consider what this means. A library can be looked at as a "set of catalogued
references to objects stored in a set of local storage units". The catalogue
provides both the indirection and the means of identifying where multiple
copies of an object can be found. It also allows the same object to be
identified in more than one way, e.g. by author name or by title.

Consider if everyone wanting to create a reference to a paper on SGML
decided, instead of referencing the file directly, to reference the entry
for the paper in Robin Cover's bibliography. This would then point to the
server(s) currently containing copies of this paper. If one wanted to create
a link to anything about the subject you could do so by pointing to the
public catalogue, whose URL would be much more persistant than any
maintained at the individual sources.

What does this tell us about SGML catalogs? Firstly it suggests they are
currently stored in the wrong place. They are currently stored in the
relocatable servers or in clients: I contend that they should be stored in
an SGML Open Catalogue Library or some similar form of long-term digital
library. Secondly it suggests that the FPIs used to identify the objects to
be indirected do not need to be unique. There could be more than one way of
identifying the same file using an FPI (e.g. an unregistered name when the
file was first created, and a set of registered ones used for later
references to the same file). It also implies that different catalogues in
the same library can provide different ways of referencing the same object.

>P.S.
>Because of ownership, accidental name duplication is very easy to avoid. 
>Both registered and unregistered (the 99% case) provide simple but very 
>real duplication protection.  (It is easy to screw up your own stuff but 
>very hard to screw up someone elses if you follow the rules at all.)
>
Funny, I now seemed to have covered Debbie's last point as well!
You don't need ownership of 'your catalog', and you don't need to avoid name
duplication in FPIs. What you actually want to do is to decouple the
catalogue entry from its owner and encourage identifier duplication. What
you need to do first, however, in encourage the use of indirection, which is
the whole point of URNs, URCs, etc. They all need a directory/catalogue
mechanism in some form of "library" to be able to work (as does the DNS
service needed to resolve URLs).

Martin Bryan
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.u-net.com/~sgml/

Received on Thursday, 28 November 1996 08:01:33 UTC