[sc34wg3] Question on TNC / Montreal minutes

17 Sep 2002 22:11:15 +0200

Here you make scopes a first-class construct with identity. Personally
I am not very happy with that idea, but I know a lot of other people
have been thinking along the same lines.

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

That was proposed at the meeting, but the proponents of the TNC did
not like it. Their argument was that one might sometimes want to use
a particular scope (or scoping topic) for merging and at other times
not.

I can certainly imagine situations where a TNC topic map and a non-TNC
topic map are merged and scoping topics also merge, causing topics in
the non-TNC topic map to suddenly be merged on the basis of base names
because the other topic map used that particular scope as a "namespace".

| Allowing merge on/off on basenames or basenamestrings makes it
| tremendously easy to make inconsistent use of scope (as namespace).

Well, that assumes that "namespace"-ness is somehow inherent in the
particular scope used. I am not at all sure that that is true. If you
look at a scoping topic or a scope, how can a human decide whether it
is a "namespace" or not? As far as I can tell, the only way is to look
at the "uniquenames" attribute, which basically tells you how someone
used that scope. It seems to me that another person might decide to
use the same scope without making it a "namespace".

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

I don't, but then I don't have any use cases for allowing us to turn
this capability on anywhere.

* Marc de Graauw
|
| I have doubts about option 1. This is probably far too inflexible.

Hmmm. It is more flexible than what we have now, in the sense that it
allows you to choose whether or not to apply the TNC. So if allow
authors to say "follow XTM 1.0" or "follow XTM 1.0 minus the TNC" is
not enough, it implies that there's something wrong with XTM 1.0.
Which of course there is.

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

Yes, this is absolutely true, but I think you derive the wrong
conclusion from it. Different applications will have different rules
for how to do merging based on topic characteristics, and base name +
scope is just a small part of that.

Applications will almost certainly want to say things like:

 - merge topics of type X based on their names irrespective of scope,

 - merge topics of all types based on their email address occurrences, 
   and

 - merge all topics which have an association of type X where they
   play role Y with the same topic.

What is so special about name + scope that we need to put that
particular merging rule in the core standard, while the others can go
into TMCL/application space? 

The only honest answer to that question is: because it was so in the
previous versions.

The real problem here is that we are trying to solve the right problem
(how to do merging based on topic characteristics) in the wrong place
(the core standard) while looking at only a fraction of the real
problem (base name + scope).

* Steve Pepper
|
| [discusses default behaviour; thinks "TNC off" should be default]

* Marc de Graauw
|
| 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.

Backwards compatibility is definitely an issue, but I've started to
realize that it affects us less than we think. The problem arises when
you have (a) a topic map that relies on the TNC and (b) a topic map
implementation which is not going to apply it.

If you have a tool that can read in a topic map and export a version
of the topic map where TNC mergings have been applied, the problem
goes away. Just preprocess your topic map before you use it. 

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >