RE: [xtm-wg] Topic Naming Constraint

[Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>]

Personally, I have some sympathy to the view Kal and Steve express here.
However, I don't think we necessarily have to accept the conclusion that the
topic naming constraint needs to be dropped.

"Topics should be merged if they have the same Subject." I believe that to
be the underlying principle. How do we know whether they have the same
Subject? Sometimes because they have the same Subject Descriptor; sometimes
because they point to the same Resource using their <resourceRef>
subelements, thereby inidicating that that resource is their subject;
sometimes because a human being determines that the Subjects indicated by
their *different* Subject Descriptors are in fact the same.

Does the fact of two <topic> elements having the same <baseNameString> in
the same Scope ensure that they have the same Subject? The answer is "yes"
if the scope is a "controlled vocabulary". The answer is "no" if the scope
is something more vague (Shakespeare's Plays, for example, or even "the
play: The Tragedy of Hamlet, Prince of Denmark" in which there are two
characters called Hamlet, namely the Prince and his dead father).

Interestingly, NewsML deals with this issue explicitly, by recognising a
clear distinction between "FormalName" which must be drawn from a controlled
vocabulary, and "Description" which may have a "Variant" and/or an
"xml:lang" attribute, which is intended for human interpretation and which
need not be unique.

It could be that a later version XTM makes a distinction like that in
NewsML. In the meantime, we have a choice, it seems to me: maintain the
topic naming constraint, and warn people that they have to be rigorous in
their choice of baseNames and treat baseNames, in effect, as controlled
vocabularies (this is the current situation, and is consistent with ISO
13250), or relax the topic naming constraint and bring in a different, more
rigorous construct later.

My preference is to keep the constraint in, and to explain clearly that it
exists. This will also help to explain the odd term "baseName". It is not
just any name. It is a very special name, to which specific constraints
apply. We could however add a special kinds of occurrence, that are inline
resources (their content being in the <resourceData> subelement of
<occurrence>), and with <instanceOf> subelements pointing to public subject
called "Description" or "Name". Applications could choose to display the
(necessarily unique) baseName, or the (not necessarily unique) Name
occurrence accompanied by the description occurrence that serves to
distinguish topics that have the same Name.

Daniel

-----Original Message-----
From: Steve Pepper [mailto:pepper@ontopia.net]
Sent: 15 January 2001 11:51
To: xtm-wg@egroups.com
Cc: srn@coolheads.com
Subject: Re: [xtm-wg] Topic Naming Constraint
Importance: High


At 10:20 15/01/01 +0000, Kal Ahmed wrote:
>I would like to express my concerns about and objection to the Topic Naming
>Constraint expressed in the XTM 1.0 specification. Having worked with both
>the ISO 13250 specification and XTM 1.0 specification and implemented
>programming libraries for both of these specifications, I find the topic
>naming constraint to be an unecessary restriction which makes the creation
>of consistent, mergeable topic maps exceedingly difficult in any but the
>most restricted situations. My objections are four-fold and I will attempt
>to express them here.

[*five* objections elided :-) ]

>For these reasons I propose the removal of the topic naming constraint from
>the XTM 1.0 processing model and urge the authoring group participating
>members to seriously consider and openly discuss this proposal.

Kal raises a very important point and I urge everyone to think seriously
about it during the run-up to Paris. It is a radical proposal, because
it will break backwards-compatibility with ISO 13250, but as WG3 convenor
I am prepared to countenance an amendment to fix that. If Kal is right
and the topic naming constraint is going to seriously impair the use of
topic maps in the future, then it is better to do a radical fix now,
before it is too late, than to ignore the problem on the grounds of
13250 compatibility.

I admit that I am unsure myself. I am worried that the immense amount
of time I have spent during the last couple of years trying to justify
this aspect of the model may be clouding my judgement...

I can certainly confirm that my practical experience when creating
topic maps has been that the constraint causes intense irritation.

Consider the example in 4.3.1 of the Dec 4 Review Specification:
Here the baseName "Hamlet" is used for both the play and the main
character, and scoping is used to avoid the topic naming constraint.
As a result, neither topic has a name in the unconstrained scope,
which means that neither will be visible unless scoping is in
effect. To solve this problem, new, unscoped names must be added that
do not clash, e.g. "Hamlet (the play)" and "Hamlet (the character)".
These then become the "default" names for these topics except in the
very specific processing contexts of "characters", or "plays + 
shortname", or "plays + fullname".

(This presupposes that topic maps are designed based on the assumption
that applications will only show unscoped names when in an
unconstrained processing context. An alternative to this would be
that applications display *all* names, scoped and unscoped, when
in an unconstrained processing context. This leads to problems of
its own that I won't go into here.)

The topic naming constraint was put there to facilitate merging in
situations where the creators of topic maps had not done the
necessary disambiguation (through the use of the more robust subject
identity mechanism) up front. My understanding of Kal's contention
is that those who disambiguate using the robust mechanism should not
be "penalized" (through the imposition of a draconian and, for them,
unnecessary constraint) in order to enable some form of unreliable
merging capability for those who don't.

In other words: Let non-merging be the default. Smart applications
can always offer baseName-based merging as an additional service.

I would very much appreciate the comments of the editors in particular
on this issue.

Steve

--
Steve Pepper, Chief Technology Officer <pepper@ontopia.net>
Convenor, ISO/IEC JTC 1/SC 34/WG 3 (Information Association)
Ontopia AS, Maridalsveien 99B, N-0461 Oslo, Norway
http://www.ontopia.net/  phone://+47 90827246/


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com