ISO/IEC JTC 1/SC 34N0705

ISO/IEC logo


Information Technology --
Document Description and Processing Languages

TITLE: Proposal to remove variants in 13250-2 Topic Maps - Data Model
SOURCE: Mr. Robert Barta
PROJECT: FDIS 13250-2: Information Technology - Topic Maps - Data Model
PROJECT EDITOR: Mr. Lars Marius Garshol; Mr. Graham Moore
STATUS: Personal contribution
ACTION: For information
DATE: 2006-01-12

Dr. James David Mason
(ISO/IEC JTC 1/SC 34 Chairman)
Y-12 National Security Complex
Bldg. 9113, M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
Network: [email protected]

Mr. G. Ken Holman
(ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada)
Crane Softwrights Ltd.
Box 266,
Telephone: +1 613 489-0999
Facsimile: +1 613 489-0995
Network: [email protected]

Proposal for the removal of variant items from Topic Maps - Data Model
(ISO/IEC 13250-2)

Authors: Robert Barta 
         Lars Heuer   

Date:    November 2005

In Atlanta the committee members decided that the Topic Maps - XML
Syntax XTM 1.1 need not be backwards compatible to XTM 1.0.

The namespace for the new XTM 1.1 standard will be different from XTM
1.0 and this gives the opportunity to modify the syntax. The committee
members voted for renaming some elements and to remove the nesting of
variant elements (for details see [1]).
Possibly more syntax changes will follow (i.e. the [reifier] property
will be modelled explicitly).

The authors of this proposal realized that the mentioned backward
compatibility break hold the opportunity to simplify the Topic Maps -
Data Model (TMDM) [2] and to remove the variant items (TMDM 5.5) from
the standard.

In the authors opinion the variant items were kept in TMDM because it
is difficult to keep the variant element in XTM but not in TMDM. Now
the committee decided to break backwards compatibility, variant items
could be safely removed from XTM 1.1 and TMDM.

First class items vs. variant items
While occurrence and topic name items can be modelled with
associations between topics it is difficult to express the semantics
of variant items in terms of the Topic Maps - Reference Model (TMRM)

A variant is an appendix to a topic name "that may be more suitable in
a certain context than the corresponding base name." (see TMDM 5.5)
and is commonly used to model "sort names" (see [4]) and "display 
names" (see [5]).

For the mentioned sort name and display name purposes, the variants
[value] property is commonly set to a value of [datatype]
"" (short xs:string) and can
also be expressed with a topic name item: The topic name items [value]
property is set to the variants [value] property and the [scope] 
property is set to union of the variants [parent] [scope] property and
the variants [scope] property.

The definition: "A variant name is an alternative form of a topic name
that may be more suitable in a certain context than the corresponding
base name." (TMDM 5.5.) is not any different from the definition of
scope that states "The scope represents the context within which a
statement is valid" (TMDM 5.3.3), since both definitions rely on a

In conclusion, variant name items with a datatype "xs:string" are
replacable with topic names that have an appropriate [scope] property.
Since "scope" now has "all" semantics (all subjects in the scope must
be applied), any level of complexity is expressable with
correspondending topic name items. And since topic names are "first
class items" they can be modelled with TMRM.

Problems may occur because variant items can hold values that are not
of datatype "xs:string" (XTM 1.0 allows only xs:string and xs:anyURI,
but in TMDM any kind of datatype is possible). But this feature is not
widely used and may be better expressed with appropriate occurrence

Topic Maps and RDF
The removal of variant items may simplify the ongoing efforts to
provide data interoperability between RDF and Topic Maps (see [6]).
Only one known Topic Maps to RDF model (see [7]) provides a solution 
for variant items.
The other models are ignoring variant items because it is difficult to
provide an elegant and logical solution for such an artificial

Removing variant items from TMDM is a step to provide data
interoperability between Topic Maps and RDF.

Minimality of TMDM
Since the functionality of variant items can be modelled with topic 
names and occurrences the TMDM is not minimal. It contains more than 
one possibility to model the same thing. There is no reason to offer 
different possibilities for the same functionality. 
Quite the reverse, since this is a source of confusion and unecessary

Necessary changes to TMDM
- 3.26
- 4 The metamodel
  Figure 1  The class hierarchy
  Remove "Variant" from the UML diagramm

- 5.4 Topic name items
  - 1st sentence: Remove ", consisting of the base form, known as 
    the base name, and variants of that base form, known as variant 
  - Remove the [variants] property from topic name.

- 5.5 Variant items
- 6.4 Merging variant items

- 7.4. Sort names
  Replace "variant name" with "topic name"

  Change the last paragraph to the following:
  "Sort names are represented by topic name items whose [scope]
  property contains a topic item whose [subject identifiers] property
  contains the string ""."

- 7.5 Subjects for defined terms
  Remove the "" subject

Compatibility to XTM 1.0 topic maps
The authors think that a XTM 1.0 to 'TMDM without variant items'
mapping is managable with the following techniques:
- All variants with [datatype] xs:string are modelled with topic names
  whose [value] property is set to the variants [value] property. 
  The [scope] property is set to the union of the variants [parent]
  [scope] property and the variants [scope] property.
- Variants of [datatype] xs:anyURI may be modelled with occurrences
  with a [type] property that is set to a topic item that contains an
  appropriate string in the [subject identifiers] property
  (i.e. creating a subject indicator
  The [scope] property of the occurrence is set to the union of the
  variants [parent] [scope] property and the variants [scope] 
  Note that the transformation from an XTM 1.0 variant to an 
  occurrence is not sufficient and needs further work (because the 
  'connection' to the variants [parent] is lost).

The decision to break backwards compatibility holds the potential
to simplify the Topic Maps - Data Model and to remove the legacy
variant items without the loss of expressiveness of topic maps.

Not taking the opportunity to remove variants at this time, it will
be even more difficult to make this necessary move because upcoming
standards such as Topic Maps - Query Language (TMQL) [8],
Topic Maps - Constraints Language (TMCL) [9] etc. will rely on TMDM
and all these standards will carry the legacy variant items.

[1] "Recommendations of November 2005 Meeting of WG3"
[2] Garshol, Lars Marius; Moore, Graham: 
    "ISO/IEC 13250: Topic Maps  Data Model"
[3] Durusau, Patrick; Newcomb, Steven R.: 
    "ISO/IEC 13250: Topic Maps  Reference Model"
[4] Moore, Graham; Pepper, Steve:
    "XML Topic Maps (XTM) 1.0"
[5] Moore, Graham; Pepper, Steve:
    "XML Topic Maps (XTM) 1.0"
[6] Garshol, Lars Marius; Gessa, Nicola; Pepper, Steve;
    Presutti, Valentina; Vitali, Fabio:
    "A Survey of RDF/Topic Maps Interoperability Proposals"
[7] Ciancarini, Paolo; Gentilucci, Riccardo; Pirruccio, Marco; 
    Presutti, Valentina; Vitali, Fabio: 
    "Metadata on the Web: On the integration of RDF and Topic Maps"
[8] Barta, Robert; Garshol, Lars Marius:
    "ISO/IEC 13250: Topic Maps Query Language"
[9] Bogachev, Dimtry; Moore, Graham:
    "ISO/IEC 13250: Topic Maps Constraint Language"