xml-dev - Re: Public identifiers and topic maps

["Martin Bryan" <mtbryan@sgml.u-net.com>]

Steve

>I've been a bit worried about this so I've been floating trial
>balloons about it in the xml-dev mailing list.  There is considerable
>sentiment to the effect that we're making a mistake here.

I've been trying to track this work while I have been away this week. It has
been very frustrating because most of the comments seem to be ill-informed
in that they were unaware of the main intention of the public attribute,
which you explained to me as being to allow the meaning of topic navigation
maps to be documented. We must bear this foremost in our mind when
considering the role of this attribute and the FPIs it references.

The second thing we need to bear in mind is the definitions of FPIs. The
following points need to be borne in mind:

What we are referring to are basically problems related to owner
identifiers, which are defined in ISO 8879 as "The portion of a public
identifier that identifies the owner or originator of public text", public
text being defined as "Test that is known beyond the context of a single
document or system environment, and which can be accessed with a public
identifier". No there are two questions that need discussion here:
i) what is the difference between an owner and an originator?
ii) what does "can be accessed with a public identifier mean?

I will come back to these questions shortly.

Eliot wrote:

>3. That existing naming schemes such as SGML formal public IDs can be used
>within a URN context if you're willing to escape lots of special characters
>(but we're used to that with URLs anyway).
>
>4. That URNs cannot be generally used today because there is no
>generally-available resolution service.  There is a "Real Soon Now" promise
>of a service, at least experimentally, but no indication from what I found
>that one is available for general use.


However, the existence of a trial resolution service for Digital Object
Identifiers (DOIs) shows us the way to go. This service, which has been put
together by CNRI, who seem to 'own' the whole process for URL
identification,  suggests that we should be able to use urn:fpi, urn:idn or
just fpi: or, better still, idn:, to provide a resolution service for XML
users. If we amend the ISO 9070 spec so that one of these is used in place
of/addition to the +//IDN currently used to identify the use of internet
domain names as owner identifiers we should be able to get an easily
automatable service up and running soon after identifying a sponsor for the
service (e.g. GCA)

Paul Prescod wrote
>An FPI is persistent because ISO legally constracts to not reassign them.
>This may mean nothing technically, but neither does the fact that the
>American government legally asserts that e-commerce transactions based on
>USD have value. If either ISO or the American government goes out of
>business, their promises are worthless, but by then we'll have other,
>bigger problems than our links breaking (which, I guess, is the real
>point).

FPIs have no legal status. Registered ones must have the names of their
ownders declared via the GCA, but unregistered ones have no such
constraints, and there in no guarantee that they will be unique. This does
not, however, stop them being useful.

Eliot riposted:
>SGML Formal public identifiers are not necessarily persistent names because
>there is nothing in ISO 8879 or ISO 9070 that requires them to be (nor
>could such a requirement be enforced or validated).  All that ISO 9070
>provides is a process for registering *owner identifiers*, which are,
>presumably, persistent (at least as defined by the assigning body).
>However, the name owner is responsible for managing the names within their
>slice of the FPI name space and can do whatever they want with them,
>including reassigning them without regard for persistence at all.


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.

>According to the current Topic Navigation Map draft (soon to be CD
>13250), this would appear as the following FPI:
>
>-//Sears, Roebuck & Co.//NONSGML TOPIC 1922 Farm Catalog Number : R205//EN

Part of the porblem with this whole set of correspondence is the ineptness
of this example FPI (sorry Steve). Let me suggest what it should have been:


-//TechnoTeacher//NONSGML TOPIC Sears, Roebuck & Co 1922 Farm Catalog
Number: R205//EN

If this form had been used originally the discussion would never have
started. The point is that the owner of the FPI is not the owner of the
referenced data, but the owner of the public identifier. (See 8879
definition given above). Claiming to represent Saer Roebuck is not only
morally illegal, it is illegal in terms of 8879.

Steven Newcomb wrote:
>> Will URNs permit pointing to things that aren't now and may never be
>> on the web? I mean, things that their owners never intended to be on
>> the web and either that their owners do not want to appear on the web,
>> or that their owners may not (currently) see any interest in putting
>> on the web?


URNs may not permit pointing to thins that are not on the web, but Digital
Object Identifiers will. They will even allow you to point to information
resources that will exsit in the future (one of their biggest advantages
from the marketeer's viewpoint). Resolving a DOI can send you to web
resources that a) allow you to order a copy of the document when it becomes
available b) provide you with name and address of someone who can tell you
where to find the data you need or, if really necessary, c) point you to a
set of electronic copies of the document and ask you which format you would
like to purchase it in. They do not need to resolve to the actual data.

Eliots claim that:
> Public identifiers, and formal public identifiers in particular, are just
>a special case of URN.
seems wrong to me. URNs are designed for electronic access. Now, depending
on how you interpet the 8879 definition of public text (see above) I am not
certain that FPIs need to reference electronically accessible text in the
way URNs (or at least URLs) are designed to do. To support this argument let
me point out that a special class of FPIs was created to reference data
within ISO standards, yet ISO does not allow electronic access to its
standards. As the Internet did not exist in 1986 I would argue that the term
"accessed" as used in 8879 should not be read as "electronically accessed
via a network". At best it can be interpreted as being "electronically
accessed in some local system dependent way" (e.g. via a catalog).

 Eliot also said
> Therefore, the PUBLIC/SYSTEM distinction made by
>SGML (and XML) is inappropriate as a matter of syntax.  A name is a name
>and there should be exactly one declared for each entity.

While this may be true in an XML context, where FPIs only apply to entity
declarations, it does not make sense in the sense they are being used in the
topic navigation mao specification, where they are *only* being used to
indirectly document the meaning of a topic. Now whether we should claim that
the names of the public identifiers used for this purpose should be
implicitly similar to those used for identifying entities containing markup
declarations or replacement text is another question. Some form of
structured name is required. Basing this structure on the existing structure
for FPIs makes sense to me.

Steve Newcomb wrote:
>But what is the correct solution, in your mind?  The only alternative
>I know of is the HyTime "bibloc" architectural form.  In your opinion,
>John, should there be a similar architectural form (in XML jargon,
>"template") in XML?  Or do you have another proposal for indicating
>bibliographic references?


This just would not be acceptable as a methodology for documenting topic
maps, which, I repeat, is what the public attribute is all about.

The comment that you originally quoted (from Paul Prescod I believe, though
it might have been John Cowan) was;
>> # [T]he registration indicator, public text class, and language fields
>> # are as specified for formal public identifiers in ISO/IEC 8879:1986.
>> # The 'topic authority' [the string after the "+//" or "-//"] is
>> # the owner of <em>the information resource</em> that defines the
>> # concept.  [Emphasis added.]


Note that what is bieng complained about here is the definition of topic
authority. This term is currently undefined in ISO 13250. To my mind adding
the following definition to Clause 4 would solve this misunderstanding:

Topic Authority
The person or organization responsible for the maintenance of the topic map.

The emphasised part of the definition is wrong and should be corrected in
ISO 13250. It should be replaced by "the public identifier used to reference
the information resource".

If we make this small change then we do not need to take in Ricks suggestion
at all (though it is a good one).


Rick Jelliffe wrote:
>Do we need a public text type of TOPIC?

You most definitely do.

>You could have something like this
>
>"+//IDN techno.com//TOPIC
>Sears, Roebuck & Company:: 1922 Farm Catalog:: [catalog number] R204//EN//
>www.techno.com/topics/sr1922r204"


You do not need the part after the EN. As shown above, it is simply enough
to identify the Topic Authority at the start: you do not need to identify
where that authority has stored an electronic copy of the definition, which
is all Rick's useful extension adds to what is suggested above.

As Rick said:
>I think it is important that I should be able to assign a topic, like
>the farm catalog above, even if I cannot locate the canonical form,
>and there should be a chance my systems will work.


This is what the public topic references in clause 6.1.1 of ISO 13250 are
designed to do. Mixing this up with other useers of FPIs has muddied the
water so much that everybody seems to have missed the illumination that this
vital option adds to topic navigation maps.

Martin Bryan



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)