[sc34wg3] Question on TNC / Montreal minutes

[Marc de Graauw]

* Steve Pepper

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

I fully agree, I think my example is completely counter-intuitive.

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

I agree again. In fact, yesterday after I posted my message I scribbled
down the following fragment:

<scopeSet id="s1" uniquenames="true">
  <topicRef xlink:href="#t1"/>
  <topicRef xlink:href="#t2"/>
  <topicRef xlink:href="#t3"/>
</scopeSet>

<topic id="t1">
  <scope>
    <scopeSetRef xlink:href="#s1"/>
  </scope>
  <baseName>
    <baseNameString>Mama Michelle</baseNameString>
  </baseName>
</topic>

<topic id="t2">
  <scope>
    <scopeSetRef xlink:href="#s1"/>
  </scope>
  <baseName>
    <baseNameString>Mama Cass</baseNameString>
  </baseName>
</topic>

(Don't look at this as a syntax proposal, just thoughts in tags. The
idea is the merge flag should be on the namespace, not elsewhere.)

Allowing merge on/off on basenames or basenamestrings makes it
tremendously easy to make inconsistent use of scope (as namespace).
Putting merge on/off on the namespace on the contrary makes it very easy
to have a consistent and simple design, and declare namespaces with
unique names where the TNC should apply, and have other "namespaces"
where the TNC does not apply and homonyms are allowed.

The only advantage of putting the flag on the basenamestring is it
allows authors greater flexibility. While in general I'm very much in
favour of giving flexibility to authors, this is one case where I cannot
see how this flexibility is going to needed, and I think the price
(unclarity) is too high. Does anybody have a use case for the greater
flexibility that a merge flag on basenamestrings would allow, which
cannot be supported by a merge flag on the namespace level?

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

I have doubts about option 1. This is probably far too inflexible.
Authors will probably in most cases want just a few namespaces where the
TNC applies (i.e. for social security numbers within a country context,
ISBN codes, data element names in the context of a B2B vocabulary) and
plenty of room for "namespaces" where the TNC does not apply.

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

I am not so sure whether I agree here. Backward compatibility is an
issue. Also having the TNC "on" forces authors to take a close look at
their homonyms, and possibly provide a cue to their users (through scope) on
what
the different homonyms refer too. However, I do see the other side of
the picture, and probably switching the TNC "off" is the more general
behaviour.

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

I am not part of a national body, just a non-voting ISUG member with no
formal muscle to flex, so my opinion will have to do... :-)

Marc