[xtm-wg] The case against the TNC

[Lars Marius Garshol <larsga@garshol.priv.no>]

Now that we suddenly have a debate on the TNC I think we should try to
use that debate productively, and to that end I would like to start
afresh in a more systematic way.

First of all, I believe I have a pretty good view of the rationale for
including the topic naming constraint. I fully understand and accept
that the purpose of the TNC is to ensure that base names (together
with their scopes) uniquely identify their topics. I also accept that
this is intended to support addressing, subject identification,
searching and merging based on topic names.

My problem with this is, to put it very briefly, that I don't believe
that it really achieves anything much. On the other hand it is clear
that the TNC represents a significant inconvenience to topic map
authors and especially to developers. Furthermore, the TNC seems to me
to force authors into making statements that make no sense from an
information modeling point of view. In short, the TNC brings a lot of
pain and little gain that I can see.

What I have a problem with is not the TNC as heuristic or guiding
principle, but the TNC as an absolute rule to be applied at all times.


Let's start with why I don't think the TNC really achieves anything
much, or indeed even works at all. Addressing topics by name seems
pointless to me when we have URIs that can refer to them. Ditto for
subject identification, which we can do via subject indicators.

As for searching I really don't see how the TNC gives us any help.
Let's take the old Paris example. If I want to find Paris, Texas there
is no need for me to search for "the topic with the base name Paris in
the scope Texas" when I can search for "the topic with the base name
Paris that has a contained-in association with Texas".

A further problem is that to use scope as a basis for anything I need
to guess what the author used as scope, which is by no means easy.
Paris can quite legitimately be scoped by Texas, the US and North
America. If we try to find Paris the hero things get even worse, since
the scope may well be Greece and legend, Greece and history, Greece,
legend, history, Greece and mythology, Troja and so on and so forth.
Scope is, in short, too vague.

In order to support merging it may well be that scoping of names has
some value, but it is still subject to the problem outlined in
previous paragraph. If it is only intended to support merging then the
TNC is better used as a heuristic for merging tools than as a
draconian law that all topic maps at all times must follow.


It should also be obvious that the topic naming constraint represents
a significant inconvenience to topic map authors. My example of the
XML query language should serve to illustrate this. When creating the
topic representing the second of these the author will presumably be
confronted with a message saying that her new topic seems to share its
subject with another topic. The author will then be forced to scope
the name in order to avoid this unwanted merge, regardless of whether
the author wants to or not.

There are many situations where the author will not get such a
warning, such as when editing a topic map as an XML document or when
merging in another topic map. In these cases the TNC is in my view
likely to prove a significant problem by causing unwanted merges. 

It is of course a further problem that the best choice of scope that
anyone has been able to think of so far is to use the topic itself as
the scoping topic, because this completely subverts all the intended
uses of the basename-plus-scope-as-unique-identifier. To find this
topic by its basename-plus-scope you need to have found the topic
already before you start looking, which is absurd.

A part of the problem here is that scope-as-subject-disambiguation is
tricky because you never have any guarantee that you have
disambiguated sufficiently to avoid unwanted merges. When the two
mr. John Smiths live in different cities scoping by city is enough,
but when John Smith I moves to the same city as John Smith II it no
longer suffices. Should John Smith II then move into the same street
as John Smith I the scope needs to be adjusted again, and there is no
guarantee that this process will ever end, unless you scope both by
themselves.


When it comes to implementation of topic maps it is clear that the
TNC presents a significant obstacle to the developer in situations
where the topic map is dynamic, for example because it is really a
view of some other data source. If that other data source is huge
constantly traversing all of it in order to find all the base names of
all topics in the mapped view so that the TNC can be applied is most
likely not going to be feasible at all.

Implementing the TNC in more static situations (such as when reading
an XTM document or permanently merging two topic maps) is also
difficult, but manageable. 

However, as I believe Geir Ove and Kal have pointed out several times
already, the presence of the TNC requires total knowledge of the topic
map in order to avoid the possibility of unwanted merges. This is
generally problematic in all kinds of situations where software is
creating topic maps automatically. I expect applications that use
NewsML feeds to automatically build topic maps to be bitten by this
quite often, for example.

The major difference between merging by subject indicator and merging
by basename-plus-scope is that only the latter can cause merges that
are not wanted. If we remove the TNC we also remove this entire
problem at a single stroke.


I am hung over today and not able to express myself as clearly as I
would wish, but this is my best effort at explaining why it seems to
me that the TNC is awkward, unnatural and achieves very little of
value. I am open to the possibility that the last two of these three
statements are untrue, but for arguments to be effective they must
show convincingly how the practical benefits of the TNC can be
realised and how natural scopes for base names can be found. So far
the proponents of the TNC have not provided this.

Furthermore, if I am proven wrong it is clear that topic map practice
needs to be shaped by what the TNC is meant to achieve, and that most
people find it difficult to practice this. In other words, if we are
to accept the TNC we must give scope an entirely new prominence in
topic map schemas and applications and start using it much more
actively.

It also seems clear that many people are unhappy with the TNC and the
strict regime it forces on them, and so from a 'marketing' point of
view it seems that there is definite value in setting down the
arugments for it in a clear way to minimize this problem, and also to
ensure that people actually use scope in the intended way.

--Lars M.


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://us.click.yahoo.com/kWP7PD/pYNCAA/4ihDAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/