======================================================================
Proposal for the removal of variant items from Topic Maps - Data Model
(ISO/IEC 13250-2)
======================================================================
Authors: Robert Barta
Lars Heuer
Date: November 2005
Introduction
------------
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)
[3].
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]
"http://www.w3.org/2001/XMLSchema#string" (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
"context".
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
items.
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
construct.
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
complexity.
Necessary changes to TMDM
-------------------------
- 3.26
Remove
- 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
names"
- Remove the [variants] property from topic name.
- 5.5 Variant items
Remove
- 6.4 Merging variant items
Remove
- 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 "http://psi.topicmaps.com/iso13250/sort"."
- 7.5 Subjects for defined terms
Remove the "http://psi.topicmaps.com/iso13250/variant-name" 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
"http://www.topicmaps.org/xtm/1.0/variant-name").
The [scope] property of the occurrence is set to the union of the
variants [parent] [scope] property and the variants [scope]
property.
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).
Summary
-------
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.
References
----------
[1] "Recommendations of November 2005 Meeting of WG3"
[2] Garshol, Lars Marius; Moore, Graham:
"ISO/IEC 13250: Topic Maps — Data Model"
(2005)
[3] Durusau, Patrick; Newcomb, Steven R.:
"ISO/IEC 13250: Topic Maps — Reference Model"
(2005)
[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"
(2005)
[7] Ciancarini, Paolo; Gentilucci, Riccardo; Pirruccio, Marco;
Presutti, Valentina; Vitali, Fabio:
"Metadata on the Web: On the integration of RDF and Topic Maps"
(2003)
[8] Barta, Robert; Garshol, Lars Marius:
"ISO/IEC 13250: Topic Maps Query Language"
(2005)
[9] Bogachev, Dimtry; Moore, Graham:
"ISO/IEC 13250: Topic Maps Constraint Language"
(2005)
