Public Identifiers

Steven R. Newcomb srn at
Tue Sep 22 06:15:07 BST 1998

[John Cowan:]

> Global uniqueness *is* a requirement of URNs, in the sense that two
> distinct things ought not be described by the same URN, and someone
> has to define what counts as "distinct things".

OK. I necessarily conclude from your answer that URNs can't do what
FPIs can do.

> My understanding is that the widespread use of unregistered FPIs
> merely reflects the lack of easy access to registration until
> recently.

My understanding is that there is a need to refer to things that
nobody has registered and that nobody who needs them to be registered
has the authority to register.  Surely you're not proposing that Joe
User should take it upon himself to register Sears and/or it's 1922
Farm Catalog on behalf of Sears, if Sears hasn't done this already for

> I think that Sears itself might be quite unhappy about people invading
> its FPI namespace in this fashion.  Such an FPI is more like a
> prose description of the resource.

In my hypothetical example, it doesn't matter what Sears thinks about
it.  Sears has published a resource (the 1922 Farm Catalog) that some
person regards as authoritative.  Sears doesn't get to say whether
people are allowed to regard its publications as authoritative.
(Nobody gets to control what others believe, and, at least in the
U.S., free speech and free thought are constitutionally protected.)  I
gather from what you say, however, that URNs can only be used to
reference things that their owners have arranged to be referencable
via URIs, by going to the expense and trouble of registering
themselves and/or their published information assets.  This constraint
excludes -- and may *forever* exclude -- most knowledge from being
referencable.  If URIs can't reference most of the knowledge in
existence, I'll use FPIs and/or HyTime biblocs to do that.

By the way, my example FPI is *not* a prose description of a resource.
It is a formal identification of an authority, a namespace created by
that authority, and a name within that namespace.  These three
elements are machine parsable, and they are not expressed in natural

> I think that the identifiers of ISO 9070 are intended here.

OK.  If the intent is to conform to ISO 9070, it would be a good idea
to say so.  It would be extraordinary to expect people to understand
that 9070 applies to a standard, if that standard doesn't establish
9070 as a normative reference.

> > * There is an even more problematic statement: "A URL identifies the
> >   location or a container for an instance of a resource identified by
> >   a URN."  This strongly implies that there must be a URL behind every
> >   URN, even if that URL is fictitious or doesn't happen to work.  It
> >   also implies that there is some sort of locatable online container.
> Not so.  You take that sentence out of its context, which makes clear that
> it's quite possible for an URN to never have any corresponding URLs.

The sentence and its context contradict one another.  I'm glad that
you can divine which one is supposed to be regarded as authoritative,
but I personally don't have any basis for making that judgment.

> > In the scenario I'm asking about, there is never any need to transmit
> > the FPI, so there's no need to convert it.

> I don't understand this point.  An FPI that's never transmitted
> remains within the brain of its inventor only.  The point of
> URI-encoding is simply to make clear where the delimiters of the URI
> are.  Allowing embedded spaces is good for human readability, but
> not for parsability.

You're right, you don't understand my point.  Consider: if two FPIs
reference the same thing, even if they are never resolved, we know
something about both of them, and what we know about them may well be
the only thing we need to know: that whatever one of them specifies,
the other specifies, too.  In the case of Topic Navigation Maps, this
is a critical piece of information, and it is often the only piece of
information needed by the underlying processing system in order to
perform its function.  Such FPIs are never resolved; they are never
transmitted to a server.


Steven R. Newcomb, President, TechnoTeacher, Inc.
srn at

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

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