OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[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