[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xtm-wg] Topic Naming Constraint
At 10:20 15/01/01 +0000, Kal Ahmed wrote: >I would like to express my concerns about and objection to the Topic Naming >Constraint expressed in the XTM 1.0 specification. Having worked with both >the ISO 13250 specification and XTM 1.0 specification and implemented >programming libraries for both of these specifications, I find the topic >naming constraint to be an unecessary restriction which makes the creation >of consistent, mergeable topic maps exceedingly difficult in any but the >most restricted situations. My objections are four-fold and I will attempt >to express them here. [*five* objections elided :-) ] >For these reasons I propose the removal of the topic naming constraint from >the XTM 1.0 processing model and urge the authoring group participating >members to seriously consider and openly discuss this proposal. Kal raises a very important point and I urge everyone to think seriously about it during the run-up to Paris. It is a radical proposal, because it will break backwards-compatibility with ISO 13250, but as WG3 convenor I am prepared to countenance an amendment to fix that. If Kal is right and the topic naming constraint is going to seriously impair the use of topic maps in the future, then it is better to do a radical fix now, before it is too late, than to ignore the problem on the grounds of 13250 compatibility. I admit that I am unsure myself. I am worried that the immense amount of time I have spent during the last couple of years trying to justify this aspect of the model may be clouding my judgement... I can certainly confirm that my practical experience when creating topic maps has been that the constraint causes intense irritation. Consider the example in 4.3.1 of the Dec 4 Review Specification: Here the baseName "Hamlet" is used for both the play and the main character, and scoping is used to avoid the topic naming constraint. As a result, neither topic has a name in the unconstrained scope, which means that neither will be visible unless scoping is in effect. To solve this problem, new, unscoped names must be added that do not clash, e.g. "Hamlet (the play)" and "Hamlet (the character)". These then become the "default" names for these topics except in the very specific processing contexts of "characters", or "plays + shortname", or "plays + fullname". (This presupposes that topic maps are designed based on the assumption that applications will only show unscoped names when in an unconstrained processing context. An alternative to this would be that applications display *all* names, scoped and unscoped, when in an unconstrained processing context. This leads to problems of its own that I won't go into here.) The topic naming constraint was put there to facilitate merging in situations where the creators of topic maps had not done the necessary disambiguation (through the use of the more robust subject identity mechanism) up front. My understanding of Kal's contention is that those who disambiguate using the robust mechanism should not be "penalized" (through the imposition of a draconian and, for them, unnecessary constraint) in order to enable some form of unreliable merging capability for those who don't. In other words: Let non-merging be the default. Smart applications can always offer baseName-based merging as an additional service. I would very much appreciate the comments of the editors in particular on this issue. Steve -- Steve Pepper, Chief Technology Officer <pepper@ontopia.net> Convenor, ISO/IEC JTC 1/SC 34/WG 3 (Information Association) Ontopia AS, Maridalsveien 99B, N-0461 Oslo, Norway http://www.ontopia.net/ phone://+47 90827246/ To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC