Public identifiers and topic maps

W. Eliot Kimber eliot at
Mon Sep 28 19:37:52 BST 1998

At 11:30 AM 9/27/98 +0100, Martin Bryan wrote:

>The FPIs used in public attributes in topic navigation maps do not need to
>be persistent: they do need even need to be resolvable. They do need to be
>"researchable": you should be able to find a copy of the original definition
>somewhere to be able to ensure that you are using the topic correctly.

If you can find the definition of something by an FPI, then you have
resolved the thing. Thus the FPI is resolvable. It may not be resolvable
electronically (I called you up and said, hey, what does this FPI mean),
but so what?  If you need electronic resolution, then you create a bibloc
that provides the electronic proxy representation for the thing itself:
that's what a bibliographic location is for (see my signature at the bottom
of this note for an example).

If your argument is that it doesn't need to be *electronically* resolvable,
I'd argue that, in today's world, it would take more effort to make
something researchable but not resolvable than it would be to make it
resolvable.  That's because whatever you publish will probably start as an
electronic data set anyway, so why not simply publish it to the Web?  If I
do that and then tell you "FPI 'x' maps to URL 'y', the FPI is
electronically resolvable.

If I can't figure out what an FPI maps to, whether the resource is
electronic or not, then the FPI is meaningless because it doesn't get me to
anything. Thus, if an FPI is researchable, it's just as easy to make it


<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list