====================================================================== 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)