[sc34wg3] Question on TNC / Montreal minutes

[Steve Pepper]

At 23:09 04/09/02 +0200, Marc de Graauw wrote:
>I've read the Montreal minutes, but find a few things unclear.
>
>The TNC becomes optional, and can be switched on and off. Something like
>this will happen:

Thanks for raising this issue, Marc. I was planning on doing it myself
because I am thoroughly unhappy with the solution proposed in Montreal.
For one thing, it lacks any semblance of elegance. More importantly, I
think it will lead to complete chaos and lack of interoperability. Your
example shows the kind of counter-intuitive mess that it opens up.

The only thing I *am* happy about is the decision to make the TNC
optional.

Given that, I think there are two issues to be addressed first:

(A) At what level does the "optionality" of the TNC operate?
(B) What is the most reasonable default behaviour?

Once we've figured out those two issues, we can address the question of
syntax. (I don't like attributes either, Mary, but that is not the key
issue here.)

(A) Level
---------

The proposed solution purports to operate at the level of the *individual
base name string* (since that's where the attribute is placed). In fact
I think it really operates at the level of the base name (since it has
always been the intention that sort names and display names - later
generalized as variant names - should NOT be subject to the TNC).

However, even the base name level is too low, in my opinion - precisely
because it invites the kind of obfuscation Marc demonstrates in his
example. The thinking behind the TNC has always been that a scope
constitutes a name space. If that is the case, then *all* names within
a given scope have to be subject to the TNC, or else *none* of them
should be. It doesn't make any sense at all to allow base name A in
scope X to be unique and for base name B in the same scope not to be
-- especially if they are the very same name!!!

Either a scope constitutes a name space, or it doesn't. You can't have
it both ways. (Or else we have to separate the TNC from the notion of
scope altogether - which might not be a bad thing in itself, but would
represent a far more radical change than just making the TNC optional.)

To my mind, there are only two levels at which the TNC on/off switch
can operate meaningfully:

(1) At the level of the topic map as a whole.
(2) At the level of individual scopes.

(1) would mean that all scopes in a given topic map are to be regarded
as constituting name spaces.

(2) would mean that only specified scopes are to be so regarded.

I realise that both of these options need further elaboration before
they can be considered solutions (e.g., what effect does merging have),
but I would like to put that discussion off until the more fundamental
one of the level of operation is cleared up.

(B) Default
-----------

Regarding my issue (B) - What is the most reasonable default behaviour?

My position is that the more general behaviour should be the default.
In this case that means names not being unique, i.e. the TNC is "switched
off". Switching it on should be regarded as a specialization in terms of
the semantic interpretation of a topic map, especially since it is
something that can also be done under the control of the application -
irrespective of what the topic map itself says.

(Respondants to my question about TNC support in topic map software all
indicate that they have ways of ignoring the TNC, so they obviously
regard this as something that is partly up to the application anyway,
not just the topic map.)

I will be pressing for the Norwegian Body to present objections along
these lines to the resolution proposed in Montreal and I urge other
national bodies to do the same.

Steve

--
Steve Pepper, Chief Executive Officer <pepper@ontopia.net>
Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
Ontopia AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway.
http://www.ontopia.net/ phone: +47-23233080 GSM: +47-90827246