[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] The Topic Naming Constraint
First of all I'd like to say that I wholeheartedly agree with Lars Marius on this matter. The Topic Naming Constraint is [extremely] painful and too awkward - in my eyes it is a real show-stopper. I'll try to explain what I think is the problem with draconian Topic Naming Constraint enforcement, which the standard(s) at this point requires from an XTM processor. A conformant XTM processor has to enforce these constraint, e.g. there cannot be _any_ exceptions if you'd like to claim that your processor is conformant. - - - I see the usefulness of being able to do automatic namespace-based merges. This is extremely useful, but unfortunately the problem is that people (myself included) believe that base names are intended for labelling purposes, not for identification. Applications need to be able to display labels for topics. The obvious way to do this is to use names. Occurrences are usually out of the question, since _generic_ applications wouldn't be able to know when to use a basename and when to display occurrences. I believe that it is a problem [actually a bug] that base names are subject for namespace-merges. As I said, I believe that namespace-merges are _extremely_ useful. But we should not use base names for this. Proposal: o We need another kind of name, e.g. identifying-name. (I don't think that it makes sense for an identifying name to have variants like basenames do.) A name targeted towards namespace-based merges complements subject indicators. Instead of just identifying a topic by subject indicators (the _meaning_ of the resource content) you're then also able to identify a topic by the name resource _content_ (byte-by-byte). - - - Here are some thoughts on why the TNC doesn't work in real-life in its current incarnation. Problem: Topics are merged even though the author(s) didn't intend them to merge because it is known by the authors that they have different subjects. This is what I believe is the main problem with the TNC in real life. I see at least four ways that a processor can behave when merging two or more topic maps: o The merge happens automatically and parts of the topic map no longer makes sense (is inconsistent), because resulting topics now represents more than one subject. o The merge is interactive. Unfortunately this requires the author(s) to be present when the merge happens. This is unacceptable in most cases. You cannot expect the authors to be present when a merge happens. Note that there are many [an unlimited number of] reasons why a merge happens. o The processor marks the topics as to-be-merged. This prevents the merged topic map to be presented to the user[!]. (A non-consistent topic map cannot be presented to the user by a conforming processor.) o The processor doesn't do merging based on the TNC. This is not allowed by the standard. - - - It has been pointed out that one of the reason why the base name constraint exist is to avoid ambiguities when presented with identical names. I agree with the usefulness of being able to avoid ambiguities. Something to be aware of is that a name can be disambiguated by a processor even without looking at the name scope: o A basename belongs to a topic, which itself represents a subject. The subject and subject descriptors _disambiguates_ the name! o The type-hierarchy and the classes of which the topic is an instance describes what the topic is about and that should to some extent disambiguate the name. o Basically all the other characteristics can be used by the XTM processor to further disambiguate a name to the end-user. All of the forementioned information is always available to an XTM processor. - - - Why is the TNC awkward? 1. It is impossible to universally scope basenames at the time of authoring to avoid unintended merges to happen in the future. You cannot know at a given point in time that you'll never have unintended merges caused by the Topic Naming Constraint. 2. Most merges will be done automatically by a computer (without user intervention). You cannot expect the authors of the two topic maps to be present the merge happens. 3. A computer cannot automatically correctly and sensibly scope names to avoid the TNC. - - - Conclusion: o Get rid of the TNC and introduce a separate content-based identifying name. All the best, Geir O. ------------------------ 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