Re: [xtm-wg] Topic Naming Constraint

[Peter Newcomb <peter@techno.com>]

[Steve Pepper <pepper@ontopia.net> on Mon, 15 Jan 2001 12:50:42 +0100]
> I can certainly confirm that my practical experience when creating
> topic maps has been that the constraint causes intense irritation.

The topic naming constraint causes irritation because it forces topic
map creators to _think_ about what names they give topics in what
contexts.  This is a _good_ thing -- without such thought, topic maps
are much less useful.

> 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.)

Except in trivial cases, it will rarely be the case that an
application can display names from exactly one scope.  Applications
must instead display names from scopes similar to the processing
context, along with qualifiers that distinguish the scopes in which
the names are defined from the scope that describes the processing
context.  As in your example above, "Hamlet" in the "characters" scope
might be displayed as "Hamlet (the character)", while "Hamlet" in the
"plays" scope might be displayed as "Hamlet (the play)".

> 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.

Actually, the topic naming constraint was put there to require that
creators of topic maps _do_ the necessary disambiguation, either
directly through the use of subject identity specification or
indirectly through name-based identity specification.  Even so,
neither is completely required: it is perfectly acceptable to have a
topic with no addressable subject, no subject indicators, and no
basenames.

> 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.

They are not penalized, since they aren't _required_ to use basenames.

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

Normally, I would agree with this sort of proposal.  However, in this
case, it is important to retain the constraint because without it,
topic maps will be created that are not amenable to basename-based
merging, and they will be indistinguishable from those that are.

It would be better to identify and promote a second class of names
with no special properties, that topic map creators can use in order
to avoid thinking too hard about naming their topics.

-peter

--
Peter Newcomb                           Epremis Corporation
peter.newcomb@epremis.com               http://www.epremis.com/

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

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