[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] The case against the TNC
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC