[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] Topic Naming Constraint
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. 1. In my mind, the most important objection is that NAME and IDENTITY are two orthogonal concepts. There is no way in which a name should be construed as asserting identity. Both ISO 13250 and XTM 1.0 recognise the orthogonality of these two concepts by providing separate constructs for each. Unfortunately the topic naming constraint then smashes the two concepts together again making a scoped name into a form of identity for a topic. 2. For the creator of a topic map, the topic naming constraint requires apriori knowledge of the vocabulary of all topic maps with which the topic map being created is used. In a certain situations, this is possible - e.g. the controlled vocabularies used by technical documentation departments; the controlled set of medical terms defined by WHO. However, in the general 'use-on-the-web' scenario, controlled vocabularies are not likely to prove practical and the topic naming constraint in effect restricts the author's freedom to name topics as he/she sees fit. 3. The topic naming constraint requires that a user has access to the content of potential merged topic maps plus specialised topic map processing in order to determine if the creation or modification of a topic will cause a merge to take place. With subject-based merging, standard string manipulation tools will work if the user has access to the potential merged topic maps and using authoritative subject identities could even mitigate the need for access to the potential merged topic maps. 4. Translation becomes difficult. Not all translations between languages are one-to-one, two concepts with distinct names which are considered distinct in one language may be translated to a single name in another language. So a translation from one language to another may potential cause topic merging not intended by the creator of the source topic map. 5. Reification becomes problematic. It would be impossible for two reified topic map objects to share the same scoped name. For example I may wish to reify an occurrence of a topic which represents 'John Smith' and give it a name 'Photograph of John Smith'. This means that for any other topic about any other John Smith, I must be sure not to use the string 'Photograph of John Smith' to name an occurrence or else the a-nodes representing the *occurrences* (not the topics!) will be merged. 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. Cheers, Kal 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