TopicMaps.Org

XML Topic Maps (XTM) 1.0

TopicMaps.Org Specification

Superseded by:
http://www.isotopicmaps.org/sam/sam-xtm/
Latest XTM version:
http://www.isotopicmaps.org/sam/sam-xtm/
Latest XTM 1.0 version:
http://www.topicmaps.org/xtm/1.0/
This version:
http://www.topicmaps.org/xtm/1.0/xtm1-20010806.html
Authors:
Members of the TopicMaps.Org Authoring Group;
see Acknowledgements
Editors:
Steve Pepper  <pepper@ontopia.net>
Graham Moore  <gdm@empolis.co.uk>
Revision:
$Id: index.html,v 1.16 2001/08/06 14:31:44 pepper Exp $

Abstract

This specification provides a model and grammar for representing the structure of information resources used to define topics, and the associations (relationships) between topics. Names, resources, and relationships are said to be characteristics of abstract subjects, which are called topics. Topics have their characteristics within scopes: i.e. the limited contexts within which the names and resources are regarded as their name, resource, and relationship characteristics. One or more interrelated documents employing this grammar is called a “topic map.”

TopicMaps.Org is an independent consortium of parties developing the applicability of the topic map paradigm [ISO13250] to the World Wide Web by leveraging the XML family of specifications.

This specification describes version 1.0 of XML Topic Maps (XTM) 1.0 [XTM], an abstract model and XML grammar for interchanging Web-based topic maps, written by the members of the TopicMaps.Org Authoring Group. More information on XTM and TopicMaps.Org is available at http://www.topicmaps.org/about.html.

All versions of the XTM Specification are permanently licensed to the public, as provided by the Charter of TopicMaps.Org.

Status of This Document

(This section describes the status of this document at the time of its publication. Other documents may supersede this document. For the latest version, refer always to the URL given above.)

This document has been reviewed by the TopicMaps.Org Authoring Group and other interested parties and has been endorsed by the Authoring Group as a TopicMaps.Org Specification. It is a stable document and may be used as reference material or cited as a normative reference from another document.

The English version of this specification is the only normative version. However, translation of this document into other languages is actively encouraged by TopicMaps.Org.

An errata list for this Specification will be maintained at http://www.topicmaps.org/xtm/1.0/errata.html.

Please report errors in this document to xtm-editor@topicmaps.org.


top Contents


top 1. Introduction

top-of-section 1.1 Origins

XML Topic Maps (XTM) is a product of the TopicMaps.Org Authoring Group (AG), formed in 2000 by an independent consortium named TopicMaps.Org, originally chaired by Michel Biezunski and Steven R. Newcomb, and chaired at the date of delivery of this specification by Steve Pepper and Graham Moore. The Participating Members of the XTM Authoring Group are listed in Annex H: Acknowledgements.

The origins of the topic maps paradigm itself date back to 1993, when it was first expressed as a working document in the context of the Davenport Group. The paradigm was more fully developed thereafter in the context of the GCA Research Institute (now known as IDEAlliance), in an activity called Conventions for the Application of HyTime, during and after which the paradigm was independently developed, implemented, and promulgated. Early in 2000, after several years of continuous effort by an international group of individuals, the topic map paradigm was fully formalized for the first time as an ISO International Standard, ISO/IEC 13250:2000. Almost immediately thereafter, TopicMaps.Org was founded in order to develop the applicability of the paradigm to the World Wide Web, and to realize its enormous potential to improve the findability and manageability of information.

top-of-section 1.2 Goals

The design goals for XTM are:

  1. XTM shall be straightforwardly usable over the Internet.
  2. XTM shall support a wide variety of applications.
  3. XTM shall be compatible with XML, XLink, and ISO 13250.
  4. It shall be easy to write programs that process XTM documents.
  5. The number of optional features in XTM is to be kept to the absolute minimum, ideally zero.
  6. XTM documents should be human-legible and reasonably clear.
  7. The XTM design should be prepared quickly.
  8. The design of XTM shall be formal and concise.
  9. XTM documents shall be easy to create.
  10. Terseness in XTM markup is of minimal importance.

This specification, together with XML 1.0 for markup syntax [XML], XLink 1.0 for linking syntax [XLink], XML Base for base URI resolution [XML Base], and the IETF URI specification [RFC 2396] (as updated by [RFC 2732]), provides all the information necessary to understand XTM 1.0 and create conforming topic map documents.

This version of the XTM specification and its associated materials may be distributed freely, as long as all text and legal notices remain intact.

top-of-section 1.3 Terminology

The terminology used to describe XTM documents is defined in the body of this specification and its annexes. The terms defined in this section are used in building those definitions.

addressable information resource

An information resource whose identity is computable (that is, a computer system can retrieve the resource and make deterministic comparisons between it, and some other resource, to establish their identity or difference). An example of an addressable information resource is the online version of this document. In this specification, the term resource is used synonymously with addressable information resource unless otherwise stated.

addressable subject

An addressable information resource, considered as a subject in and of itself, and not considered in terms of what an author meant by it. The identity of an addressable subject is by definition directly computable. (Cf. non-addressable subject.)

association
  1. A relationship between topics asserted by an <association> element.
  2. An <association> element.

association type
  1. One of the classes of association.
  2. The class of association specified by an <association> element's <instanceOf> child element. An association may belong to only one class.
  3. A topic whose subject is a class of association.

base name
  1. A child element (<baseName>) of a <topic> element.
  2. A name characteristic of a topic that is provided by the content of a <baseNameString> element. Base names must be unique within a given scope (cf. topic naming constraint).

See also variant name.

characteristic

See topic characteristic.

consistent topic map

A topic map in which there is one topic per subject and no further opportunities for merging or duplicate suppression, as defined in Annex F: XTM Processing Requirements.

member
  1. A child element (<member>) of an <association> element.
  2. A set of topics that play a particular role in an association.

merging
  1. The process of merging two topic maps, either as a result of explicit <mergeMap> directives, or for any application-specific reasons.
  2. The process of merging two topics.

The rules governing all forms of merging are given in Annex F: XTM Processing Requirements.

non-addressable subject

A subject that exists outside the bounds of the computer system and whose identity is therefore not computable. Examples of non-addressable subjects include William Shakespeare, the play Hamlet and its 1604-05 edition, the character Hamlet, the concept of vengeance, the organization Shakespeare & Company, etc. The identity of a non-addressable subject may only be established indirectly, for example through the use of a subject indicator.

occurrence
  1. A child element (<occurrence>) of a <topic> element.
  2. A topic occurrence (q.v.).

occurrence type
  1. One of the classes of topic occurrence.
  2. The class of topic occurrence specified by an <occurrence> element's <instanceOf> child element. An occurrence may belong to only one class.
  3. A topic whose subject is a class of topic occurrence.

parameters
  1. A child element (<parameters>) of a <variant> element.
  2. Information, in the form of a set of topics, that expresses the appropriate processing context for a variant name.

processed topic map

The collection of topics, associations, and scopes which have been processed by the XTM processing application as defined in Annex F: XTM Processing Requirements.

processing requirements

The requirements on processing performed by a conforming XTM processor as defined in Annex F: XTM Processing Requirements.

PSI

See published subject indicator.

published subject indicator

A subject indicator that is published and maintained at an advertised address for the purpose of facilitating topic map interchange and mergeability.

reification

The act of creating a topic. When anything is reified it becomes the subject of the topic thus created; to reify something is therefore to create a topic of which that thing is the subject. Reification of a subject allows topic characteristics to be assigned to the topic that reifies it: In other words, it makes it possible to discourse about that subject within the terms of the topic map paradigm.

resource

See addressable information resource.

role

The role that a topic plays as a member of an association; the nature of its involvement in that association.

scope
  1. The extent of the validity of a topic characteristic assignment. The context in which a name or an occurrence is assigned to a given topic, and the context in which topics are related through associations.
  2. The set of topics specified via a <scope> element.

See also unconstrained scope.

This specification places no constraints on how applications interpret scope.

subject
  1. Anything that can be spoken about or conceived of by a human being. In the most generic sense, a subject is anything whatsoever, regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever.
  2. Anything on which the author of a topic map chooses to discourse.
  3. Anything that is reified by a topic in a topic map; the organizing principle of a topic. Humans are the ultimate authorities for determining the subjects of topics.

See also subject identity, subject indicator.

subject identity
  1. The <subjectIdentity> child of a <topic> element.
  2. That which makes two subjects identical, or distinguishes one subject from another. The determination of subject identity is aided, and may be automated, by the use of published subject indicators.
  3. A criterion for merging topics as defined in Annex F: XTM Processing Requirements.

subject indicator

A resource that is intended by the topic map author to provide a positive, unambiguous indication of the identity of a subject. There are three ways of indicating a subject in a topic map:

  1. Pointing via a <topicRef> element to a <topic> element that shares the same subject;
  2. Pointing via a <subjectIndicatorRef> element to a resource that indicates the subject;
  3. Pointing via a <resourceRef> element to a resource that is the subject.

The subject indicated by a subject indicator may be either non-addressable or addressable. (Note that in case 3, the subject is necessarily addressable, since it is a resource.)

topic
  1. A resource that acts as a proxy for some subject; the topic map system's representation of that subject. The relationship between a topic and its subject is defined to be one of reification. Reification of a subject allows topic characteristics to be assigned to the topic that reifies it.
  2. A <topic> element.

topic characteristic

One of the following:

  1. a topic name,
  2. a topic occurrence, or
  3. a role played by a topic in an association

A topic's names, occurrences, and roles played in associations are collectively known as its characteristics.

See also topic name, topic occurrence, and role.

topic characteristic assignment

The act of asserting that a given topic has a particular characteristic. Such assertions are deemed to be valid within a certain scope.

topic map
  1. A collection of topics, associations, and scopes that may exist in one of two forms:
    1. a serialized interchange format (e.g. as a topic map document expressed in XTM syntax), or
    2. some application-internal form, as constrained by the XTM Processing Requirements defined in Annex F.
  2. The document element (<topicMap>) of a topic map document expressed using XTM syntax.

topic map document

A document that contains one or more topic maps that conform to this specification. It may be serialized for the purpose of storage or interchange in a syntax governed by this or some other specification.

topic map node

An object (in the system's internal representation of a topic map) that represents a topic, association, or scope.

topic name
  1. A base name characteristic of a topic (including that base name's variants).
  2. (Informally) The string of characters specified as a name of a topic using a <baseNameString> element.

topic naming constraint

The constraint, imposed by the topic map paradigm, that any topics having the same base name in the same scope implicitly refer to the same subject and therefore should be merged.

topic occurrence

A resource containing information that is specified as relevant to a given subject. In order to be expressed in an XTM topic map, such a resource must either

  1. be addressable via a URI using a <resourceRef> element, or
  2. be capable of being placed inline as a <resourceData> element.

topic type
  1. One of the classes of topic.
  2. A class of topic specified by an <instanceOf> child of a <topic> element. A topic may belong to more than one class.
  3. A topic whose subject is a class of topic.

unconstrained scope

The absence of a specified scope in the assignment of a topic characteristic.

variant

See variant name.

variant name

An alternative form of a base name, optimized for a particular computational purpose, such as sorting or display.

XTM document

A topic map document that is expressed in the syntax defined by this specification.


top 2. Concepts

This section describes concepts necessary to understand the constructs of XML Topic Maps (XTM).

The purpose of a topic map is to convey knowledge about resources through a superimposed layer, or map, of the resources. A topic map captures the subjects of which resources speak, and the relationships between subjects, in a way that is implementation-independent.

The key concepts in topic maps are topics, associations, and occurrences.

A topic is a resource within the computer that stands in for (or “reifies”) some real-world subject. Examples of such subjects might be the play Hamlet, the playwright William Shakespeare, or the “authorship” relationship.

Topics can have names. They can also have occurrences, that is, information resources that are considered to be relevant in some way to their subject. Finally, topics can participate in relationships, called associations, in which they play roles as members.

Thus, topics have three kinds of characteristics: names, occurrences, and roles played as members of associations. The assignment of such characteristics is considered to be valid within a certain scope, or context.

Topic maps can be merged. Merging can take place at the discretion of the user or application (at runtime), or may be indicated by the topic map's author at the time of its creation.

The following section provides a gentle introduction using a simple example taken from the domain of encyclopedia publishing. It is followed by a more detailed overview of topic map concepts. For a list of the XML element types declared in a topic map, see Section 3.1, Introduction to XTM Syntax.

top-of-section 2.1 A Gentle Introduction to Topic Maps

As a way of making concrete the use of the topic map notation defined in this specification, consider the following example. Let us suppose that we wish to record, in a device-independent and implementation-independent way, the kind of information about the subject matter of a document that might be included in the subject index to an encyclopedia in electronic form.

For various subjects — for example, William Shakespeare, Ben Jonson, their plays Hamlet and Volpone, and the towns of London and Stratford, among thousands of others — we will wish to record all of the locations in the encyclopedia — whether passages of text, or images, or sound recordings in a multi-media encyclopedia — where they are discussed, depicted, or mentioned. We will speak of these locations as occurrences of these subjects. Note that different occurrences may relate to their subject in very different ways, which we would like to distinguish. In-depth discussions, brief mentions, and illustrations may need to be distinguished in order to allow the users to find more quickly what they need.

The encyclopedia we are working with exists in electronic form, so every occurrence of a subject is an electronic resource, for which we can compute an address. (Without going into detail about the nature of the address, we define an address as an expression, usually short, which allows a suitable processor to locate a resource.) They are thus addressable information resources.

The playwrights William Shakespeare and Ben Jonson, by contrast, are not addressable resources: they are not electronic artifacts at all, but real human beings. In order to represent the link between an occurrence of a subject and the subject itself, we would like simply to point to each in turn and say “this location discusses this subject” (or perform the equivalent gestures in some electronic notation, by giving the address of the subject, the address of the occurrence, and describing the relation between them using markup).

Because not all subjects are electronic artifacts, however, we cannot provide an address for the subject. Instead, we provide an electronic surrogate for the subject, which (being electronic) can have an address. This surrogate we call a topic. Every topic acts as a surrogate for some subject. We say that the topic “reifies” the subject — or makes the subject “real” for the system. The creation of a topic that reifies a subject enables the system to manipulate, process, and assign characteristics to the subject by manipulating, processing, and assigning characteristics to the topic that reifies it. When we need an address for the subject, we give the address of a topic which reifies it, and acts as its surrogate within the system.

(Where it will not lead to confusion, we will sometimes use the terms topic and subject interchangeably; since each topic reifies some subject, and since for each subject we can construct a topic to reify it, the difference is not always important.)

Since our entire collection of subject-index information provides a sort of map of the encyclopedia, showing where various topics are mentioned and discussed, we call our electronic representation of the subject index a topic map.

Topics representing several of William Shakespeare's plays might look like this:

  <topic id="hamlet">
    <instanceOf><topicRef xlink:href="#play"/></instanceOf>
    <baseName>
      <baseNameString>Hamlet, Prince of Denmark</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf><topicRef xlink:href="#plain-text-format"/></instanceOf>
      <resourceRef
        xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt"/>
    </occurrence>
  </topic>

  <topic id="tempest">
    <instanceOf><topicRef xlink:href="#play"/></instanceOf>
    <baseName>
      <baseNameString>The Tempest</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf><topicRef xlink:href="#plain-text-format"/></instanceOf>
      <resourceRef
        xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws4110.txt"/>
    </occurrence>
  </topic>

Note: For brevity, examples of URIs in this specification sometimes include only a fragment identifier (e.g. #play above). In such cases, it is assumed that these identifiers refer to a <topic> element elsewhere in the same topic map with an “id” attribute value that matches the fragment identifier.

It is often useful in thesauri and subject indexes to indicate relationships among the subjects: Hamlet and The Tempest are both examples of plays, Shakespeare is their author, Rosencrantz and Guildenstern are characters in the play Hamlet, etc. In traditional reference works, these kinds of relationships are used to guide the compiler in the creation of cross references. Note that these relationships hold not among the occurrences of the subjects but among the subjects themselves; an electronic representation of them can be wholly independent of the occurrences and might be applied to very different collections of resources. The electronic representation of relationships among subjects, of course, will take the form of relationships, or associations, among the topics that reify those subjects.

An association representing the relationship between Shakespeare and the play Hamlet might look like this:

  <association>
    <instanceOf><topicRef xlink:href="#written-by"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#author"/></roleSpec>
      <topicRef xlink:href="#shakespeare"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#work"/></roleSpec>
      <topicRef xlink:href="#hamlet"/>
    </member>
  </association>

Because associations express relationships they are inherently multidirectional: If “Hamlet was written by Shakespeare”, it automatically follows that “Shakespeare wrote Hamlet”; it is one and the same relationship expressed in slightly different ways. Instead of directionality, associations use roles to distinguish between the various forms of involvement members have in them. Thus the example above may be serialized using natural language as follows: “There exists a 'written by' relationship between Shakespeare (playing the role of 'author') and Hamlet (playing the role of 'work').” Relationships may involve one, two, or more roles.

There is no intrinsic limit to the kinds of relationships among subjects which we can record in this way; for some purposes, lived in and example of will suffice; for other purposes, very different relationships among subjects will be of interest.

Because topics and their relationships can be described independently of their occurrences in any given set of information resources, it may be expected that a given set of topics may be connected, in different applications, with many different sets of information resources. Conversely, one set of information resources may be described by many different topic maps. Different topic maps may define topics for the same subject; it will be important, in practice, to be able to merge topics which denote the same subject.

At an abstract level, we can say that our encyclopedia consists of a set of addressable information resources, each of which may be located inside of some larger addressable information resource and each of which pertains to one or more subjects. Our subject index consists of the following three things:

  1. a set of topics, each of which serves as an electronic surrogate for (reifies) some subject, and each of which may have one or more names
  2. links from topics to information resources that are considered to be occurrences of the subjects those topics reify, (e.g. discussed-in, mentioned-in, depicted-in)
  3. associations between topics, (e.g. example-of, wrote/written-by, lived-in)

We use the term topic map to denote any collection of such things. Note that since subjects, as we have defined them, include anything human beings want to think about, discuss, or represent in electronic form, there is no mechanical test to determine whether two subjects are identical or not, or whether two topics reify the same subject or not. Accordingly, the subjects themselves make no appearance in the formal description just given. Nor do we attempt to restrict the nature of the relationships between topics and their occurrences, or between topics and other topics. For this reason, the formalism defined here, while historically developing out of an interest in problems of subject search over bodies of disparate material in many media, may be applied to many problems far distant (or so they appear) from the problems of subject indexing for encyclopedias. The terminology continues to reflect the historical origins of the terms, in the interests of clarity and concreteness.

Note that since electronic resources of any kind can themselves become the objects of our attention, they may also be treated as topics. (A picture depicting William Shakespeare, for example, is just an occurrence of the topic representing William Shakespeare, but it might also be mentioned, as a picture, in a history of art, or in a discussion of graphics formats, or in an inventory of digital resources — or in a topic map.)

top-of-section 2.2 Overview of Topic Map Concepts

This section provides a complete overview of all topic map concepts. It is based largely on the definitions in 1.3 Terminology, but uses a logical rather than alphabetical order of presentation and includes some additional explanatory material.

top-of-section 2.2.1 Topic

A topic is a resource that acts as a proxy for some subject; it is the topic map system's representation of that subject. The relationship between a topic and its subject is defined to be one of reification. Reification of a subject allows topic characteristics to be assigned to the topic that reifies it.

Each individual topic is an instance of one or more classes of topics (also known as topic types) that may or may not be indicated explicitly. The default topic type is defined by the “topic” published subject.

top-of-section 2.2.1.1 Subject

A subject is anything that can be spoken about or conceived of by a human being. In the most generic sense, a subject is anything whatsoever, regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever. In particular, it is anything on which the author of a topic map chooses to discourse.

In order to discourse on a subject within the topic map paradigm, that subject must be reified through the creation of a topic. Subjects are thus the organizing principle of topics.

In a consistent topic map each subject is represented by just one topic. In a topic map document, on the other hand, multiple topics may reify the same subject (though preferably in such a way that they can be merged to a single topic during processing).

Most subjects exist outside the bounds of the computer system; they cannot be addressed directly and their identities are therefore not computable. Examples of such non-addressable subjects include William Shakespeare, the play Hamlet and its 1604-05 edition, the character Hamlet, the concept of vengeance, the organization Shakespeare & Company, this XTM specification, etc. The identity of non-addressable subjects can only be established indirectly, via a resource that functions as a subject indicator.

However, anything can be a subject of discourse in a topic map, including resources inside the computer, which can be addressed directly. Resources considered as subjects are called addressable subjects. An example of an addressable subject would be this specification, considered as an HTML document.

top-of-section 2.2.1.2 Reification

The act of creating a topic is called reification. When anything is reified it becomes the subject of the topic thus created; to reify something is therefore to create a topic of which that thing is the subject. Reification of a subject allows topic characteristics to be assigned to the topic that reifies it: In other words, it makes it possible to discourse about that subject within the terms of the topic map paradigm.

The notion of reification is at the very heart of the topic map paradigm. The only means whereby it is possible to say anything at all in a topic map is to create a topic and then assign characteristics to it. Topics are what make subjects “real” for the system and come as close as a machine can to a representation of what is “real” for humans.

Since anything whatsoever can be a subject, reification can also be applied to objects within the topic map itself, such as associations, names, and occurrences. (For examples of how this can be done syntactically, see under <association> and <occurrence> in Section 3, XTM Syntax Documentation.) This makes it possible both to apply the power of the topic map paradigm to topic maps themselves, and to enable multiple levels of knowledge representation within one and the same map, including making assertions about assertions.

top-of-section 2.2.1.3 Subject Identity

Subject identity is the means whereby it can be established which subject is reified by a particular topic. When two topics have the same subject identity, they are considered to be “about” the same thing, and must therefore be merged. Because of the need to be able to merge topic maps — in effect, to interchange their semantics — the topic map paradigm goes to great lengths to make it possible to establish the identity of a topic (and hence its subject) as robustly as possible.

Subject identity can be established in one of two ways:

  1. By addressing the subject directly. This is only possible when the subject is an addressable information resource.
  2. By indicating the subject via a subject indicator (see below).

top-of-section 2.2.1.4 Subject Indicator

A subject indicator is a resource that is intended by the topic map author to provide a positive, unambiguous indication of the identity of a subject. When two topics use the same resource to indicate their subject, they are by definition “about” the same thing, and must therefore be merged during processing.

Since subject identity forms the basis for merging topic maps and interchanging semantics, authors are encouraged to always indicate the subject identity of their topics in the most robust manner possible, in particular through the use of standardized ontologies expressed as published subject indicators.

Since one and the same subject may be indicated in many ways, it is possible for two topics that reify the same subject to use different subject indicators and therefore not be merged. Situations like this may be avoided through the use of a third topic (in the same or another topic map document) that establishes its identity through both subject indicators. Thus topic maps may be used for mediating between ontologies.

top-of-section 2.2.1.5 Topic Characteristic

Anything that may be asserted about a topic in the topic map paradigm is known as a characteristic of that topic. Characteristics can be one of the following:

The assignment of such characteristics is considered to be valid within a certain scope, or context.

top-of-section 2.2.1.6 Scope

Scope specifies the extent of the validity of a topic characteristic assignment. It establishes the context in which a name or an occurrence is assigned to a given topic, and the context in which topics are related through associations. Every characteristic has a scope, which may be specified either explicitly, as a set of topics, or implicitly, in which case it is known as the unconstrained scope. Assignments made in the unconstrained scope are always valid.

Scope is considered to establish a namespace for the base names of topics. This leads to the constraint, imposed by the topic map paradigm, called the topic naming constraint, that any topics having the same base name in the same scope implicitly refer to the same subject and therefore should be merged. With the exception of this constraint, the interpretation of a characteristic's scope and its effect on processing is left to the application and is in no way constrained by this specification.

top-of-section 2.2.2 Name

A topic may have zero or more names, each of which is considered to be valid within a certain scope (which may be the unconstrained scope).

Each name may exist in multiple forms. A name always has exactly one base form, known as the base name, and it may, in addition, have one or more variants for use in specific processing contexts.

top-of-section 2.2.2.1 Base Name

A base name is the base form of a topic name; it is always a string. When an application chooses to use a particular topic name to label a topic, the base name provides the string for the application to use unless a variant exists that is deemed to be more apposite in the processing context.

Base names are subject to the topic naming constraint, which prohibits a processed topic map from containing multiple topics with the same base name in the same scope.

top-of-section 2.2.2.2 Variant Name

A variant name is an alternative form of a base name, that is optimized for a particular computational purpose, such as sorting or display. It may be any kind of a resource, including a string. An application chooses among variant names by evaluating their parameters.

top-of-section 2.2.2.3 Parameters

Parameters are information, in the form of a set of topics, that expresses the appropriate processing context for a variant name. Having selected a particular topic name, an application may choose to examine the parameters of its variants (if any) in order to select the most suitable form of that name.

top-of-section 2.2.3 Occurrence

An occurrence is any information that is specified as being relevant to a given subject. Occurrences constitute one of the three kinds of characteristic that can be assigned to a topic and are therefore governed by scope. Each individual occurrence is an instance of a single class of occurrence (also known as an occurrence type) that may or may not be indicated explicitly. The default occurrence type is defined by the “occurrence” published subject.

In order to be expressed in an XTM topic map, such occurrences must be resources that are either

  1. addressable by reference using a URI (a “resource reference”), or
  2. capable of being placed inline as character data (“resource data”).

The latter (resource data) provides a useful way of expressing a short piece of information about a subject (e.g. a work's date of composition).

top-of-section 2.2.4 Association

An association is a relationship between one or more topics, each of which plays a role as a member of that association. The roles a topic plays in associations are among the characteristics that can be assigned to it and are therefore governed by scope. Each individual association is an instance of a single class of association (also known as an association type) that may or may not be indicated explicitly. The default association type is defined by the “association” published subject.

There is no directionality inherent in an association. (Associations describe relationships: If A is related to B, then B must also be related to A. The issue is rather, what is the type of the relationship, and what roles are played by its members. The question of how to label a relationship is one of naming, not direction.)

top-of-section 2.2.4.1 Member

A member is a set of topics that play a particular role in an association.

top-of-section 2.2.4.2 Role

The concept of role expresses the nature of a topic's involvement as a member of an association.

top-of-section 2.2.4.3 Class-Instance

Class-instance is a class of association that expresses class-instance relationships between topics that play the roles of class and instance respectively. The subjects “class-instance”, “class”, and “instance” are all defined by published subject indicators (PSIs) published in this specification.

top-of-section 2.2.4.4 Superclass-Subclass

Superclass-subclass is a class of association that expresses superclass-subclass relationships between topics that play the roles of superclass and subclass respectively. The subjects “superclass-subclass”, “superclass”, and “subclass” are all defined by PSIs published in this specification.

top-of-section 2.2.5 Topic Map

A topic map is a collection of topics, associations, and scopes (collectively called topic map nodes) that may exist in one of two forms:

  1. a serialized interchange format (e.g. as a topic map document expressed in XTM or some other syntax), or
  2. an application-internal form, as constrained by the XTM Processing Requirements defined in Annex F

The purpose of a topic map is to convey knowledge about resources through a superimposed layer, or map, of the resources. A topic map captures the subjects of which resources speak, and the relationships between resources, in a way that is implementation-independent.

top-of-section 2.2.5.1 Topic Map Node

Topic map nodes are objects in the system's internal representation of a topic map that represent topics, associations, and scopes.

top-of-section 2.2.5.2 Consistent Topic Map

A consistent topic map is one in which there is one topic per subject and no further opportunities for merging or duplicate suppression, as defined in Annex F: XTM Processing Requirements.

top-of-section 2.2.5.3 Topic Map Document

A topic map document is a document that contains one or more topic maps that conform to this specification. It may be serialized for the purpose of storage or interchange in a syntax governed by this or some other specification.

top-of-section 2.2.5.4 XTM document

An XTM document is a topic map document that is expressed in the syntax defined by this specification.

top-of-section 2.3 Published Subjects

top-of-section 2.3.1 Introduction

A published subject is any subject for which a subject indicator has been made available for public use and is accessible online via a URI. A published subject indicator is therefore any resource that has been published in order to provide a positive, unambiguous indication of the identity of a subject for the purpose of facilitating topic map interchange and mergeability.

top-of-section 2.3.2 XTM Mandatory Published Subject Indicators

Certain subjects are necessary for, intrinsic to, and therefore published in this specification. Various constraints imposed by this specification are expressed in terms of these published subjects, including the default class of topics, associations, and occurrences, and the equivalence between the use of <instanceOf> and an association of type class-instance in the unconstrained scope.

The Published Subject Indicators provided by this specification for the XTM mandatory subjects are briefly identified in this section. The brief descriptions found here are referenced as subject indicators by the <topic> elements contained in the topic map found in Annex E: XTM 1.0 Core Published Subject Indicators.

topic

The core concept of topic; the generic class to which all topics belong unless otherwise specified.
http://www.topicmaps.org/xtm/1.0/core.xtm#topic

association

The core concept of association; the generic class to which all associations belong unless otherwise specified.
http://www.topicmaps.org/xtm/1.0/core.xtm#association

occurrence

The core concept of occurrence; the generic class to which all occurrences belong unless otherwise specified.
http://www.topicmaps.org/xtm/1.0/core.xtm#occurrence

class-instance relationship

The core concept of class-instance; the class of association that represents class-instance relationships between topics, and that is semantically equivalent to the use of <instanceOf> subelements.
http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance

class

The core concept of class; the role of class as played by one of the members of a class-instance association.
http://www.topicmaps.org/xtm/1.0/core.xtm#class

instance

The core concept of instance; the role of instance as played by one of the members of a class-instance association.
http://www.topicmaps.org/xtm/1.0/core.xtm#instance

superclass-subclass relationship

The core concept of superclass-subclass; the class of association that represents superclass-subclass relationships between topics.
http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass

superclass

The core concept of superclass; the role of superclass as played by one of the members of a superclass-subclass association.
http://www.topicmaps.org/xtm/1.0/core.xtm#superclass

subclass

The core concept of subclass; the role of subclass as played by one of the members of a superclass-subclass association.
http://www.topicmaps.org/xtm/1.0/core.xtm#subclass

suitability for sorting

Suitability of a topic name for use as a sort key; for use in the parameters of variant names.
http://www.topicmaps.org/xtm/1.0/core.xtm#sort

suitability for display

Suitability of a topic name for display; for use in the parameters of variant names.
http://www.topicmaps.org/xtm/1.0/core.xtm#display

top-of-section 2.4 Merging

The term merging covers two distinct processes:

  1. The process of merging two topic maps, either as a result of explicit <mergeMap> directives, or for any application-specific reasons.
  2. The process of merging two topics.

The rules governing all forms of merging and the determination of subject identity are given in full in Annex F: XTM Processing Requirements. They can be briefly (and incompletely) stated as follows:

  1. When two topic maps are merged, any topics that the application, by whatever means, determines to have the same subject are merged, and any duplicate associations are removed.
  2. When two topics are merged, the result is a single topic whose characteristics are the union of the characteristics of the original topics, with duplicates removed.

Two topics are always deemed to have the same subject if:

  1. they have one or more subject indicators in common,
  2. they reify the same addressable subject, or
  3. they have the same base name in the same scope.

top 3. XTM Syntax Documentation

top-of-section 3.1 Introduction to XTM Syntax

The syntax for serializing and interchanging topic map documents conforming to this specification is defined by the XML document type definition provided in Annex D: XTM 1.0 Document Type Declaration. This section provides documentation for all the element types defined in that DTD.

The following is a complete list of XTM element types in the order in which they are documented:

top-of-section 3.2 References to Topics and Subject Indicators

top-of-section 3.2.1 <topicRef> Element

The <topicRef> element provides a URI reference to a topic. The target of a <topicRef> link must resolve to a <topic> element child of a <topicMap> document that conforms to this XTM specification. The target <topic> need not be in the document entity of origin.

<topicRef>s are identical to <subjectIndicatorRef>s, except for the additional constraint that they must point to <topic> elements.

Occurs in: <instanceOf>, <member>, <mergeMap>, <parameters>, <roleSpec>, <scope>, <subjectIdentity>

Content Model


  <!ELEMENT topicRef  EMPTY >

The <topicRef> element has no content.

Attributes


  <!ATTLIST topicRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

The <topicRef> element has the following attributes:

id unique identifier for element
xlink:type identifies this as an XLink simple link type
xlink:href supplies the URI reference for this link.

Note: See sections 5.2 and 5.4 of [XLink] for conformance and usage.

Examples

Reference to a topic with the ID “en” in the document language.xtm (this is in fact a published subject for the language English):

  <topicRef
    xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>

Reference to a topic with the ID “play” that is physically located in the current document:

  <topicRef xlink:href="#play"/>

For further examples, see <scope>, <instanceOf>, <variant>, <association>, and <mergeMap>.

top-of-section 3.2.2 <subjectIndicatorRef> Element

The <subjectIndicatorRef> element provides a URI reference to a resource that acts as a subject indicator.

Occurs in: <instanceOf>, <member>, <mergeMap>, <parameters>, <roleSpec>, <scope>, <subjectIdentity>

Content Model


  <!ELEMENT subjectIndicatorRef  EMPTY >

The <subjectIndicatorRef> element has no content.

Attributes


  <!ATTLIST subjectIndicatorRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

The <subjectIndicatorRef> element has the following attributes:

id unique identifier for element
xlink:type identifies this as an XLink simple link type
xlink:href supplies the URI reference for this link.

Note: See sections 5.2 and 5.4 of [XLink] for conformance and usage.

Examples

Reference to a published subject indicator:

  <subjectIndicatorRef
    xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>

Reference to a (fictitious) resource that indicates a subject less formally:

  <subjectIndicatorRef
    xlink:href="http://www.shakespeare.org/plays.html#hamlet"/>

For further examples, see <scope>, <instanceOf>, <subjectIdentity>.

For examples of how to use <subjectIndicatorRef> to reify topic map constructs, see <association> and <occurrence>.

top-of-section 3.3 Scope and Context

top-of-section 3.3.1 <scope> Element

The <scope> element consists of one or more <topicRef>, <resourceRef>, or <subjectIndicatorRef> elements. The union of the subjects corresponding to these elements specifies the context in which the assignment of the topic characteristic is considered to be valid.

A declaration of a topic characteristic is valid only within a scope. When a topic characteristic declaration does not specify a scope, it is valid in the unconstrained scope.

Occurs in: <baseName>, <occurrence>, <association>

Content Model


  <!ELEMENT scope  ( topicRef  | resourceRef | subjectIndicatorRef )+ >
<topicRef>
Each repeatable <topicRef> child element references a <topic> element (“scoping topic”) whose subject contributes to the scope.
<resourceRef>
Each repeatable <resourceRef> child element references a resource that contributes to the scope.
<subjectIndicatorRef>
Each repeatable <subjectIndicatorRef> child element references a resource that indicates the identity of the subject that contributes to the scope.

Attributes


  <!ATTLIST scope
     id              ID        #IMPLIED
  >

The <scope> element has the following attribute:

id unique identifier for element

Examples

Define a scope consisting of the subject “English” using a published subject:

  <scope>
    <subjectIndicatorRef
      xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
  </scope>

Define a scope consisting of the topics “tragedy” and “theatre” in the current document:

  <scope>
    <topicRef xlink:href="#tragedy"/>
    <topicRef xlink:href="#theatre"/>
  </scope>

For further examples, see <baseName>.

top-of-section 3.4 Classes and Instances

top-of-section 3.4.1 <instanceOf> Element

The <instanceOf> element specifies the class to which its parent belongs, via a <topicRef> or <subjectIndicatorRef> child element.

For the constraints on the usage of <instanceOf>, see the description of the element types that can be its parent:  <topic>, <occurrence>, and <association>.

The <instanceOf> element is a syntactic shortcut for an association of a special type defined by the class-instance published subject.

Occurs in: <topic>, <occurrence>, <association>

Content Model


  <!ELEMENT instanceOf  ( topicRef | subjectIndicatorRef ) >
<topicRef>
The <topicRef> child element references a <topic> element that reifies a class of subject.
<subjectIndicatorRef>
The <subjectIndicatorRef> child element references a resource that indicates the identity of a class of subject.

Attributes


  <!ATTLIST instanceOf
     id              ID        #IMPLIED
  >

The <instanceOf> element has the following attribute:

id unique identifier for element

Examples

Declare that the topic with the ID “hamlet” is an instance of the topic type whose ID is “play”:

  <topic id="play">
    ...
  </topic>

  <topic id="hamlet">
    <instanceOf>
      <topicRef xlink:href="#play"/>
    </instanceOf>
  </topic>

Reference a subject indicator to establish the subject of which a topic is an instance:

  <topic id="hamlet">
    <instanceOf>
      <subjectIndicatorRef
          xlink:href="http://www.shakespeare.org/plays.html"/>
    </instanceOf>
  </topic>

Reference a published subject in a public ontology to establish the subject of which a topic is an instance:

  <topic id="shakespeare">
    <instanceOf>
      <subjectIndicatorRef
          xlink:href="http://www.iptc.org/NewsML/topicsets/-
          topicset.iptc-topictype.xml#TopicTypes.Person"/>
    </instanceOf>
  </topic>

For further examples, see <topic>, <association>, and <occurrence>.

top-of-section 3.5 The Topic Map

top-of-section 3.5.1 <topicMap> Element

The <topicMap> element is the parent of all <topic>, <association>, and <mergeMap> elements in the topic map document.

The <topicMap> element is the root element from which topic map syntactical recognition is performed. The <topicMap> element can be the root of a document containing only a topic map (i.e. when it is the document element), or it can be the root of a subtree inside an XML document containing other information than the topic map itself. In the latter case, only the subtree starting with the element <topicMap> is taken into account for topic map syntactical recognition and conformance.

Content Model


  <!ELEMENT topicMap
     ( topic | association | mergeMap )*
  >
<topic>
Each optional and repeatable <topic> child element reifies a single subject.
<association>
Each optional and repeatable <association> child element specifies a relationship among topics.
<mergeMap>
Each optional and repeatable <mergeMap> child element causes its parent topic map to be merged with another topic map.

Attributes


  <!ATTLIST topicMap
     id              ID        #IMPLIED
     xmlns           CDATA     #FIXED 'http://www.topicmaps.org/xtm/1.0/'
     xmlns:xlink     CDATA     #FIXED 'http://www.w3.org/1999/xlink'
     xml:base        CDATA     #IMPLIED
  >

The <topicMap> element has the following attributes:

id unique identifier for element
xmlns namespace identifier for default XML namespace
xmlns:xlink namespace identifier for XLink namespace
xml:base reference to document base URI

Notes:
See sections 5.2 and 5.4 of [XLink] for conformance and usage.
See section 3 of [XML Base] for details on use of the xml:base attribute.

Examples

A <topicMap> element embedded in an XML document:

  ...
    <topicMap>

      <!-- topics, associations, and merge map directives go here -->

    </topicMap>
  ...

A <topicMap> element that constitutes a complete document:

  <?xml version="1.0"?>
  <!DOCTYPE topicMap
            PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN"
                   "file://usr/local/home/gromit/xml/xtm/xtm1.dtd">
  <topicMap xmlns='http://www.topicmaps.org/xtm/1.0/'
            xmlns:xlink='http://www.w3.org/1999/xlink'
            xml:base='http://www.shakespeare.org/hamlet/'>

    <!-- topics, associations, and merge map directives go here -->

  </topicMap>

top-of-section 3.6 Topics and Subjects

top-of-section 3.6.1 <topic> Element

The <topic> element specifies the name and occurrence characteristics of a single topic. It has a single unique identifier, and the ability to state the class(es) of which it is an instance and the identity of the subject that it reifies.

By definition, a topic reifies only one subject. Every topic is intended to be organized around exactly one subject, even if that subject is only implicitly defined. During XTM processing, topics with identical subjects will be merged according to the rules specified in Annex F: XTM Processing Requirements.

However, a topic map document may contain multiple topic elements that reify the same subject. After processing there will only be one topic for each subject; its characteristics will be the union of the characteristics of all topics that reified that subject. (For further discussion of the merging process, see Section 2.4, Merging.)

The class(es) of which the topic is an instance are indicated via the <instanceOf> child element(s), each of which addresses either a topic or a subject indicator. If no <instanceOf> children are present, the class of the topic defaults to the class defined by the topic published subject.

A <topic> element specifies zero or more names and zero or more occurrences that are relevant to its subject. Names are declared by means of <baseName> child elements. Occurrences are specified by means of <occurrence> child elements.

Occurs in: <topicMap>

Content Model


  <!ELEMENT topic
     ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* )
  >
<instanceOf>
Each optional and repeatable <instanceOf> child element specifies a class of which this topic is an instance.
<subjectIdentity>
The optional <subjectIdentity> child element specifies the subject identity of this topic.
<baseName>
Each optional and repeatable <baseName> child element specifies a name characteristic of this topic.
<occurrence>
Each optional and repeatable <occurrence> child element specifies information resources that are relevant to this topic.

Attributes


  <!ATTLIST topic
     id              ID        #REQUIRED
  >

The <topic> element has the following attribute:

id unique identifier for element

Example

The topic whose ID is “hamlet” is an instance of the topic type whose ID is “play”:

  <topic id="hamlet">
    <instanceOf>
      <topicRef xlink:href="#play"/>
    </instanceOf>
    <!-- base names and occurrences go here -->
  </topic>

For further examples, see <subjectIdentity>, <baseName>, <variant>, <association>, and <occurrence>.

top-of-section 3.6.2 <subjectIdentity> Element

The <subjectIdentity> element specifies the subject that is reified by a topic, via <resourceRef>, <subjectIndicatorRef>, and/or <topicRef> child elements.

When a topic has an addressable subject, the subject can be addressed directly via a <resourceRef> element. In that case, it is the resource itself which is considered the subject of the topic, not what the resource means or indicates. There can be only one such resource per topic.

Resources may also be subject indicators, as opposed to subjects in and of themselves. Resources are used to indicate subjects via <subjectIndicatorRef> elements, of which there may be more than one per topic.

A topic may also indicate that it has the same subject as another topic by addressing that topic via a <topicRef> element. There may be multiple such elements, each of which causes topic merging to occur.

Occurs in: <topic>

Content Model


  <!ELEMENT subjectIdentity
     ( resourceRef?, ( topicRef | subjectIndicatorRef )* )
  >
<resourceRef>
The optional <resourceRef> element references an addressable subject.
<topicRef>
Each optional and repeatable <topicRef> child element references a <topic> element that shares the same subject.
<subjectIndicatorRef>
Each optional and repeatable <subjectIndicatorRef> child element references a subject indicator.

Attributes


  <!ATTLIST subjectIdentity
     id              ID        #IMPLIED
  >

The <subjectIdentity> element has the following attribute:

id unique identifier for element

Examples

In Topic Map 1: Establish identity by referencing a published subject indicator (here, the country Denmark, as defined by the TopicMaps.Org PSIs based on ISO 3166):

  <topic id="dk">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/country.xtm#dk"/>
    </subjectIdentity>
  </topic>

In Topic Map 2: Establish identity by referencing a more informal ontology (here, the online version of the CIA World Factbook):

  <topic id="da">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.cia.gov/cia/publications/factbook/geos/da.html"/>
    </subjectIdentity>
  </topic>

In Topic Map 3: Declare a topic that expresses a mapping between the ISO and CIA ontologies and causes correct merging:

  <topic id="denmark">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/country.xtm#dk"/>
      <subjectIndicatorRef
        xlink:href="http://www.cia.gov/cia/publications/factbook/geos/da.html"/>
    </subjectIdentity>
  </topic>

top-of-section 3.7 Topic Names

top-of-section 3.7.1 <baseName> Element

The <baseName> element specifies a topic name. A topic name is represented by one string: the content of the <baseNameString> child of <baseName>. The context within which the assignment of a name to a topic is valid may be expressed using a <scope> child element. If none such is present, the scope is unconstrained and the name is always valid. A topic may have multiple base names in the same and/or multiple scopes.

Natural language discrimination between base names may be specified by a child <scope> element. (Published subjects suitable for defining such scopes can be found in XTM Language Topics, a topic map maintained by TopicMaps.Org that provides published subjects for natural languages. See Annex E: XTM 1.0 Core Published Subject Indicators.)

Base names are subject to the topic naming constraint that two topics with the same base name in the same scope implicitly reify the same subject and should therefore be merged.

Alternate forms of the topic name, optimized for computational purposes like sorting, searching, and display, are specified by <variant> elements.

Occurs in: <topic>

Content Model


  <!ELEMENT baseName  ( scope?, baseNameString, variant* ) >
<scope>
The optional <scope> child element specifies the context in which this base name is valid.
<baseNameString>
The single mandatory <baseNameString> child element provides the string that is the base name of the topic.
<variant>
The optional and repeatable <variant> child element provides alternate forms of the base name.

Attributes


  <!ATTLIST baseName
     id              ID        #IMPLIED
  >

The <baseName> element has the following attribute:

id unique identifier for element

Examples

Simple example:

  <topic id="shakespeare">
    <baseName>
      <baseNameString>William Shakespeare</baseNameString>
    </baseName>
  </topic>

Topic with multiple names in different languages, differentiated by scope (assumes the existence of topics with the IDs “en” and “da” that reify the subjects “English” and “Danish” respectively):

  <topic id="denmark">
    <!-- baseName for English -->
    <baseName>
      <scope><topicRef xlink:href="#en"/></scope>
      <baseNameString>Denmark</baseNameString>
    </baseName>
    <!-- baseName for Danish -->
    <baseName>
      <scope><topicRef xlink:href="#da"/></scope>
      <baseNameString>Danmark</baseNameString>
    </baseName>
  </topic>

Use of scope to avoid undesired merging due to the topic naming constraint (if the two uses of the name “Hamlet” were not scoped in different ways, these two topics would be merged):

  <topic id="hamlet">
    <baseName>
      <baseNameString>The Tragedy of Hamlet, Prince of
        Denmark</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#play"/></scope>
      <baseNameString>Hamlet</baseNameString>
    </baseName>
  </topic>

  <topic id="character-hamlet">
    <baseName>
      <scope><topicRef xlink:href="#character"/></scope>
      <baseNameString>Hamlet</baseNameString>
    </baseName>
  </topic>

Give an association type multiple names in order that associations of this type may be labeled differently depending on which role they are viewed from. The topic in this example has the default name “written by” (in the unconstrained scope); however, in the context “author” (e.g. when, in an application, what is regarded as the “current topic” plays the role of “author”), the string “author of” is deemed to provide a more appropriate base name:

  <topic id="written-by">
    <baseName>
      <baseNameString>written by</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#author"/></scope>
      <baseNameString>author of</baseNameString>
    </baseName>
  </topic>

top-of-section 3.7.2 <baseNameString> Element

The <baseNameString> element is a string that represents the base name of its ancestor <topic> parent.

Occurs in: <baseName>

Content Model


  <!ELEMENT baseNameString  ( #PCDATA ) >

The <baseNameString> element contains #PCDATA; it may only contain character data.

Attributes


  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

The <baseNameString> element has the following attribute:

id unique identifier for element

Example

See the <baseName> element.

top-of-section 3.7.3 <variant> Element

The <variant> element is an alternate form of a topic's base name appropriate for a processing context specified by the variant's <parameters> child element. Among these contexts may be sorting and display.

Each <variantName> child element in the recursive structure provides a single alternate form of the base name; the processing context in which this form is considered to be appropriate is defined by the union of all the parameters at this and higher levels of the recursive structure. (In other words, parameters are inherited down the tree.) For a full description, see “Variant scope processing” in Annex F: XTM Processing Requirements.

A variant name whose parameters include the “display” or “sort” published subjects (see Section 2.3.2, XTM Mandatory Published Subject Indicators) is semantically equivalent to display names and sort names (respectively) as defined in ISO 13250.

Occurs in: <baseName>

Content Model


  <!ELEMENT variant  ( parameters, variantName?, variant* ) >
<parameters>
The single mandatory <parameters> child element specifies an additional processing context for its parent <variant> element.
<variantName>
The optional <variantName> child element provides an alternate form of the base name.
<variant>
Each optional and repeatable <variant> child element specifies additional parameters and variant names, within the context of the parameters declared by its parent <variant> element.

Attributes


  <!ATTLIST variant
     id              ID        #IMPLIED
  >

The <variant> element has the following attribute:

id unique identifier for element

Examples

Specify an alternate form of the base name for purposes of sorting:

  <topic id="shakespeare">
    <baseName>
      <baseNameString>William Shakespeare</baseNameString>
      <!-- form for sorting (sort name) -->
      <variant>
        <parameters><topicRef xlink:href="#sort"/></parameters>
        <variantName>
          <resourceData>shakespeare,william</resourceData>
        </variantName>
      </variant>
    </baseName>
  </topic>

  ...

  <topic id="sort">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#psi-sort"/>
    </subjectIdentity>
  </topic>

The example below shows variants of the base name “Hamlet,” including alternate forms for visual and audible presentation. The variant subtree for “display” illustrates how the nesting of variants is used, and how parameters are “accumulated” down through the structure:

  <topic id="hamlet">
    <baseName>
      <baseNameString>Hamlet</baseNameString>

      <!-- alternative forms for display (display name) -->
      <variant>
        <parameters><topicRef xlink:href="#display"/></parameters>

        <!-- variant subtree for icon -->
        <variant>
          <parameters><topicRef xlink:href="#icon"/></parameters>
          <!-- variant subtree for large -->
          <variant>
            <parameters><topicRef xlink:href="#large"/></parameters>
            <variantName>
              <!-- effective parameters = display + icon + large -->
              <resourceRef xlink:href="img/hamlet64x64.png" />
            </variantName>
          </variant>
          <!-- variant subtree for small -->
          <variant>
            <parameters><topicRef xlink:href="#small"/></parameters>
            <variantName>
              <!-- effective parameters = display + icon + small -->
              <resourceRef xlink:href="img/hamlet16x16.png" />
            </variantName>
          </variant>
        </variant>

        <!-- variant subtree for full screen -->
        <variant>
          <parameters><topicRef xlink:href="#full-screen"/></parameters>
          <!-- variant subtree for VGA -->
          <variant>
            <parameters><topicRef xlink:href="#vga"/></parameters>
            <variantName>
              <!-- effective parameters = display + full-screen + vga -->
              <resourceRef xlink:href="img/hamlet640x480.png" />
            </variantName>
          </variant>
          <!-- variant subtree for SVGA -->
          <variant>
            <parameters><topicRef xlink:href="#svga"/></parameters>
            <variantName>
              <!-- effective parameters = display + full-screen + svga -->
              <resourceRef xlink:href="img/hamlet800x600.png" />
            </variantName>
          </variant>
        </variant>

      </variant>

      <!-- alternative form for audible delivery -->
      <variant>
        <parameters><topicRef xlink:href="#audible"/></parameters>
        <variantName>
              <!-- effective parameters = audible -->
          <resourceRef xlink:href="au/hamlet.au"/>
        </variantName>
      </variant>

    </baseName>
  </topic>

top-of-section 3.7.4 <variantName> Element

The <variantName> element provides the resource to be used as a variant of a base name. The resource may be referenced by a <resourceRef> element, or may be included directly as a <resourceData> element.

Occurs in: <variant>

Content Model


  <!ELEMENT variantName  ( resourceRef | resourceData ) >
<resourceRef>
The <resourceRef> child element references a resource that supplies the variant name.
<resourceData>
The <resourceData> child element is the resource that supplies the variant name.

Attributes


  <!ATTLIST variantName
     id              ID        #IMPLIED
  >

The <variantName> element has the following attribute:

id unique identifier for element

Example

See the <variant> element.

top-of-section 3.7.5 <parameters> Element

The <parameters> element consists of one or more <topicRef> or <subjectIndicatorRef> elements. The union of the subjects corresponding to these elements specifies an additional processing context in which variant names in the variant's subtree are considered to be appropriate.

Occurs in: <variant>

Content Model


  <!ELEMENT parameters  ( topicRef | subjectIndicatorRef )+ >
<topicRef>
The repeatable <topicRef> child element references a topic element that indicates the processing context of the parent <variant> element.
<subjectIndicatorRef>
The repeatable <subjectIndicatorRef> element references a resource that indicates the processing context of the parent <variant> element.

Attributes


  <!ATTLIST parameters
     id              ID        #IMPLIED
  >

The <parameters> element has the following attribute:

id unique identifier for element

Example

See the <variant> element.

top-of-section 3.8 Associations and Members

top-of-section 3.8.1 <association> Element

The <association> element asserts a relationship among topics that play roles as members of the association.

The class to which an <association> belongs is specified by an <instanceOf> child element. If no such element is present, the association's class defaults to the association published subject.

The context within which the assertion made by the association is valid may be expressed using a <scope> child element. If none such is present, the scope is unconstrained and the association is always valid.

Occurs in: <topicMap>

Content Model


  <!ELEMENT association
     ( instanceOf?, scope?, member+ )
  >
<instanceOf>
The optional <instanceOf> child element specifies the class to which this association belongs.
<scope>
The optional <scope> child element specifies the context in which the assertion made by the association is valid.
<member>
The mandatory and repeatable <member> element specifies the topics that play roles in the association.

Attributes


  <!ATTLIST association
     id              ID        #IMPLIED
  >

The <association> element has the following attribute:

id unique identifier for element

Examples

There exists an association of type “written-by” between the topic “shakespeare” (playing the role of “author”) and the topic “hamlet” (playing the role of work). In other words, [the work] Hamlet was written by [the author] Shakespeare (or [the author] Shakespeare wrote [the work] Hamlet).

  <association id="will-wrote-hamlet">
    <instanceOf>
      <topicRef xlink:href="#written-by"/>
    </instanceOf>
    <member>
      <roleSpec>
        <topicRef xlink:href="#author"/>
      </roleSpec>
      <topicRef xlink:href="#shakespeare"/>
    </member>
    <member>
      <roleSpec>
        <topicRef xlink:href="#work"/>
      </roleSpec>
      <topicRef xlink:href="#hamlet"/>
    </member>
  </association>

Reify the preceding association in order to be able to assign characteristics to it:

  <topic id="will-wrote-hamlet-topic">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="#will-wrote-hamlet"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Shakespeare's authorship of
        Hamlet</baseNameString>
    </baseName>
    <!-- occurrences may go here -->
  </topic>

Declare the class-instance relationship between “hamlet” and “play” using an association, instead of an <instanceOf> element (this is semantically equivalent to the first example given under <instanceOf>, above):

  <association>
    <instanceOf>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef
          xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#class"/>
      </roleSpec>
      <topicRef xlink:href="#play"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef
          xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#instance"/>
      </roleSpec>
      <topicRef xlink:href="#hamlet"/>
    </member>
  </association>

  <topic id="play">
    ...
  </topic>

  <topic id="hamlet">
    ...
  </topic>


top-of-section 3.8.2 <member> Element

The <member> element specifies all topics that play a given role in an association. The <roleSpec> element specifies the role played by these topics.

Occurs in: <association>

Content Model


  <!ELEMENT member
     ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )+ )
  >
<roleSpec>
The optional <roleSpec> child element specifies the role played in this association by this member.
<topicRef>
Each repeatable <topicRef> child element references a topic that plays the specified role.
<resourceRef>
Each repeatable <resourceRef> child element references a resource that plays the specified role.
<subjectIndicatorRef>
Each repeatable <subjectIndicatorRef> element references a subject indicator for a subject that plays the specified role.

Attributes


  <!ATTLIST member
     id              ID        #IMPLIED
  >

The <member> element has the following attribute:

id unique identifier for element

Example

See the <association> element.

top-of-section 3.8.3 <roleSpec> Element

The <roleSpec> element specifies the role played by a member in an association.

Occurs in: <member>

Content Model


  <!ELEMENT roleSpec  ( topicRef | subjectIndicatorRef ) >
<topicRef>
The <topicRef> child element references a topic that reifies a role in an association.
<subjectIndicatorRef>
The <subjectIndicatorRef> child element references a subject indicator for a role in an association.

Attributes


  <!ATTLIST roleSpec
     id              ID        #IMPLIED
  >

The <roleSpec> element has the following attribute:

id unique identifier for element

Example

See the <association> element.

top-of-section 3.9 Occurrences and Resources

top-of-section 3.9.1 <occurrence> Element

The <occurrence> element specifies a resource supplying information relevant to a topic.

The class of which the occurrence is an instance is indicated via the <instanceOf> child element. If no such element is present, the occurrence type defaults to the class defined by the occurrence published subject.

The context within which the occurrence is valid may be expressed using a <scope> child element. If none such is present, the scope is unconstrained and the occurrence is always valid.

Occurs in: <topic>

Content Model


  <!ELEMENT occurrence
     ( instanceOf?, scope?, ( resourceRef | resourceData ) )
  >
<instanceOf>
The optional <instanceOf> child element specifies the class of which the topic occurrence is an instance.
<scope>
The optional <scope> child element specifies the context in which the resource is relevant to the topic.
<resourceRef>
The <resourceRef> child element references a resource that is an occurrence of the topic.
<resourceData>
The <resourceData> child element is the resource that is an occurrence of the topic.

Attributes


  <!ATTLIST occurrence
     id              ID        #IMPLIED
  >

The <occurrence> element has the following attribute:

id unique identifier for element

Example

The topic whose ID is “hamlet” has an occurrence of type “date-of-composition” whose content is the string “1600-01”, and an occurrence of type “xml-version” at the URL shown:

  <topic id="hamlet">
    <occurrence>
      <instanceOf>
        <topicRef xlink:href="#date-of-composition"/>
      </instanceOf>
      <resourceData>1600-01</resourceData>
    </occurrence>
    <occurrence id="hamlet-in-xml">
      <instanceOf>
        <topicRef xlink:href="#xml-version"/>
      </instanceOf>
      <resourceRef
        xlink:href="http://www.csclub.uwaterloo.ca/u/relander/XML/hamlet.xml"/>
    </occurrence>
  </topic>

Reify one of the preceding occurrences in order to be able to assign characteristics to it:

  <topic id="hamlet-in-xml-topic">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="#hamlet-in-xml"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Jon Bosak's XML version of
        Hamlet</baseNameString>
    </baseName>
    <!-- occurrences may go here (e.g. commentaries
         on the XML version of Hamlet)-->
  </topic>

top-of-section 3.9.2 <resourceRef> Element

The <resourceRef> element provides a URI reference to a resource.

Resources may be referenced for one of the following reasons:

  1. as occurrences of topics (in <occurrence> elements)
  2. as addressable subjects (in <member>, <mergeMap>, <scope>, and <subjectIdentity> elements), and
  3. as variant names of topics (in <variantName> elements)

Occurs in: <member>, <mergeMap>, <occurrence>, <scope>, <subjectIdentity>, <variantName>

Content Model


  <!ELEMENT resourceRef  EMPTY >

The <resourceRef> element has no content.

Attributes


  <!ATTLIST resourceRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

The <resourceRef> element has the following attributes:

id unique identifier for element
xlink:type identifies this as an XLink simple link type
xlink:href supplies the URI reference for this link.

Note: See sections 5.2 and 5.4 of [XLink] for conformance and usage.

Example

See the <variant>, <occurrence>, and <mergeMap>. elements.

top-of-section 3.9.3 <resourceData> Element

The <resourceData> element contains information in the form of character data that may be:

  1. an occurrence of a topic, or
  2. a variant form of a base name

Occurs in: <occurrence>, <variantName>

Content Model


  <!ELEMENT resourceData  ( #PCDATA ) >

The <resourceData> element is declared #PCDATA, meaning that it may only contain character data.

Attributes


  <!ATTLIST resourceData
     id              ID        #IMPLIED
  >

The <resourceData> element has the following attribute:

id unique identifier for element

Example

See the <variant> and <occurrence>. elements.

top-of-section 3.10 Merging

top-of-section 3.10.1 <mergeMap> Element

A <mergeMap> element references an external <topicMap> element through an xlink:href attribute containing a URI. It is a directive to merge the containing topic map and the referenced topic map according to the rules specified in Annex F: XTM Processing Requirements.

The children of <mergeMap> indicate topics that are to be added to the scopes of all characteristics originating in the referenced topic map. (The reason for modifying the scopes of the merged characteristics may be to prevent topics from merging on account of the topic naming constraint, or to distinguish between characteristics on the basis of their topic map of origin.)

Occurs in: <topicMap>

Content Model

  <!ELEMENT mergeMap  ( topicRef | resourceRef | subjectIndicatorRef )* >
<topicRef>
The optional and repeatable <topicRef> child element references a topic whose subject is to be added to the scope of all characteristics originating in the referenced topic map.
<resourceRef>
The optional and repeatable <resourceRef> child element references an addressable subject that is to be added to the scope of all characteristics originating in the referenced topic map.
<subjectIndicatorRef>
The optional and repeatable <subjectIndicatorRef> child element references a subject indicator whose subject is to be added to the scope of all characteristics originating in the referenced topic map.

Attributes


  <!ATTLIST mergeMap
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

The <mergeMap> element has the following attributes:

id unique identifier for element
xlink:type identifies this as an XLink simple link type
xlink:href supplies the URI reference for this link. This is a reference to a topic map to be merged with this one at Graph creation time

Note: See sections 5.2 and 5.4 of [XLink] for conformance and usage.

Examples

Merge the topic map “plays.xtm” with the current topic map, adding the topics “shakespeare” and “drama” (in the current topic map) to the scopes of all characteristics originating in the “plays.xtm” topic map:

  <mergeMap xlink:href="http://www.shakespeare.org/plays.xtm">
    <topicRef xlink:href="#shakespeare"/>
    <topicRef xlink:href="#drama"/>
  </mergeMap>

  <topic id="shakespeare">
    ...
  </topic>

  <topic id="drama">
    ...
  </topic>

Merge the “biography.xtm” topic map with the current topic map, adding that resource itself (as an addressable subject) to the scopes of all characteristics originating in the “biography.xtm” topic map. This technique allows an author to use a topic map as a subject, to scope its own topics in the merged result:

  <mergeMap xlink:href="http://www.shakespeare.org/biography.xtm">
    <resourceRef
            xlink:href="http://www.shakespeare.org/biography.xtm"/>
  </mergeMap>

top 4. Conformance

This section sets forth the conditions under which it can be accurately claimed that documents and applications conform to the XTM Specification.

A document or application conforms to the XTM Specification only if all of the following conformance criteria are satisfied:

  1. it observes the mandatory conditions (“shall” and “must”), and
  2. for any optional conditions (“should” and “may”) it observes, it observes them in the way prescribed.

These conformance criteria must be applied in any program for certifying the conformance of documents and applications to the XTM Specification, and in the development of test suites and other instruments for measuring and reporting the conformance of documents and applications for which such conformance will be claimed.

top 4.1 XTM Conformance Vocabulary

Within this specification, the key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” are to be interpreted as described in RFC 2119 (see [RFC 2119]). However, for readability, these words do not appear in all uppercase letters in this specification.

top 4.2 XTM Processing Dependencies

XTM processing depends on [XML], [XML Names], [XLink], [XML Base], and [RFC 2396] (as updated by [RFC 2732]).

top-of-section 4.3 The XTM Namespace

The URI reference used as the “namespace name” (in the sense specified by the W3C Recommendation Namespaces in XML [XML Names]) identifying this XTM specification is:

    http://www.topicmaps.org/xtm/1.0/

Applications wishing to make use of W3C namespace-aware processing for documents conforming to this XTM specification must ensure that the W3C namespace name is the above URI string.

This specification reserves use of any string which would match (('X'|'x') ('T'|'t') ('M'|'m')) for the use of this XTM specification and any related specifications produced by TopicMaps.Org.

top 4.4 XTM Document Conformance

A topic map document conforms to the XTM 1.0 Specification if and only if all of the following conditions are satisfied, in addition to those conditions listed above in “XTM Conformance Vocabulary”:

  • The document is an XML document that conforms to the W3C XML 1.0 Recommendation, editions thereof, or subsequent W3C XML Recommendation, insofar as such subsequent Recommendations or editions do not invalidate existing XML documents that are XTM-conformant.
  • The document contains at least one <topicMap> element.
  • Each <topicMap> element contained in the document conforms to the syntactic constraints imposed on <topicMap> elements by the XTM 1.0 DTD specified by this Specification.
  • There are no elements or attributes contained in any of the <topicMap> elements that are not explicitly declared by the XTM 1.0 DTD specified by this Specification. A <topicMap> element is non-conforming if it contains elements or attributes from any other “XML Namespaces” at any recursive level of element containment.
  • All of the syntactic and other constraints specified by the XTM 1.0 Specification are honored in each of the <topicMap> elements contained in the document. When each <topicMap> element is processed as defined and described in Annex F: XTM Processing Requirements, there must be no Reportable XTM Errors.

XTM markup existing in an XML document outside of a <topicMap> element is undefined by this specification.

top 4.5 XTM Application Conformance

An XTM application is any software module that:

An XTM application conforms to the XTM 1.0 Specification if and only if all of the following conditions are satisfied:

  • All of the constraints specified in Annex F: XTM Processing Requirements regarding the handling of each XTM element and attribute are honored by the XTM application.
  • All Reportable XTM Errors are detected, and the XTM application is capable of reporting all of them.
  • All Merging Rules and other Rules specified in Annex F: XTM Processing Requirements are honored by the XTM application.

top Annexes


top Annex A: References (Informative)

The following are specifications that this document is derived from, related to, dependent upon, or informed by:

[ISO13250]
ISO/IEC 13250:2000 Topic Maps: Information Technology -- Document Description and Markup Languages,
Michel Biezunski, Martin Bryan, Steven R. Newcomb, ed., 3 Dec 1999.
See: http://www.y12.doe.gov/sgml/sc34/document/0129.pdf (PDF, 332K)
[XML]
Extensible Markup Language (XML) 1.0 (Second Edition),
Tim Bray, Jean Paoli, and C.M. Sperberg-McQueen, Eve Maler, editors. World Wide Web Consortium, W3C Recommendation 6 October 2000.
See http://www.w3.org/TR/REC-xml.
[XLink]
XML Linking Language (XLink) Version 1.0.,
Steve DeRose, Eve Maler, David Orchard, Ben Trafford, editors. World Wide Web Consortium, W3C Candidate Recommendation 3 July 2000.
See http://www.w3.org/TR/xlink.
XLink processing depends on [XML], [XML Names], [XML Base], and [IETF RFC 2396].
[XML Base]
XML Base (XBase),
Jonathan Marsh, editor. World Wide Web Consortium, W3C Proposed Recommendation 8 September 2000.
See http://www.w3.org/TR/xmlbase.
[XML Names]
Namespaces in XML,
Tim Bray, Dave Hollander, and Andrew Layman, editors. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, W3C Recommendation 14 January 1999.
See http://www.w3.org/TR/REC-xml-names/.
[RFC 1738]
Uniform Resource Locators (URL),
IETF (Internet Engineering Task Force) RFC 1738, December 1994.
See http://www.ietf.org/rfc/rfc1738.txt.
[RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels,
IETF (Internet Engineering Task Force) RFC 2119, S. Bradner, March 1997.
See http://www.ietf.org/rfc/rfc2119.txt.
[RFC 2141]
URN Syntax,
IETF (Internet Engineering Task Force) RFC 2141, R. Moats, May 1997.
See http://www.ietf.org/rfc/rfc2141.txt.
[RFC 2396]
Uniform Resource Identifiers (URI): Generic Syntax,
IETF (Internet Engineering Task Force) RFC 2396, August 1998.
See http://www.ietf.org/rfc/rfc2396.txt.
[RFC 2732]
Format for Literal IPv6 Addresses in URL's,
IETF (Internet Engineering Task Force) RFC 2732, 1999.
See http://www.ics.ietf.org/rfc/rfc2732.txt.


top Annex B: XTM Conceptual Model (Informative)

top-of-section B.0 Introduction

This annex presents the XML Topic Maps Conceptual Model. The model uses a simple notation drawn from Unified Modeling Language UML object modelling notation; only the aspects used in the model (and the particular interpretations used in the model) are described here.

An Explanation of the Notation used in the Conceptual Model

The notation is made up of boxes, which represent classes (kinds of things), and connections between these boxes, which represent relationships between those classes, or between instances of those classes (individual things of the kinds represented by the boxes). There are four different kinds of connections:

arrow Line ending in hollow triangle: from subtype to type

This notation can be seen most clearly in the initial “Class Hierarchy” diagram. For example, the top levels say that both “Resource” and “Non-addressable Subject” are subtypes of “Subject”. One level lower, “String” is stated to be a subtype of “Resource”. Where a type has more than one subtype, they are gathered together using a horizontal line — this does not provide any connection between the subtypes (e.g. the only relationship asserted here between “String” and “Topic” is that they are both, separately, subtypes of “Resource”.

arrow Line optionally ending in line arrowhead: named relationship

This can be seen in the diagram “A topic reifies a subject”: the line between “Topic” and “Subject” states that the named relationship “reifies” holds between zero or more Topics (“zero or more” is denoted by 0..*) and one Subject.

If there is an arrowhead, then this denotes that the relationship is traversible in one direction only. In this case, what is being said is that given a Topic, you can find out what Subject it reifies ... but given just a Subject, e.g. the character named “Hamlet”, there is no guarantee that you can find any Topic reifying it.

If there is no arrowhead, this denotes that there is no directionality to the relationship. This means it is possible to pass from either end to the other.

A further variation on this notation is that the ends of the connecting lines can be labeled. This can be seen in the diagram “Base name within scope”: the label “+baseNameString” next to “String” states that it is a “String” that serves as a baseNameString relative to the “Base Name”.

Finally, the connection itself may be labeled with a name between double angle brackets, indicating the nature of the relationship (e.g. <<REIFIES>>).

arrow Line ending in black diamond: strict dependency, commonly called ownership

This can be seen in the diagram “Base Name Within Scope”: the relationship of “Base Name” to “Topic” is such that it makes no sense to call anything a base name otherwise than as a base name of a topic.

arrow Line ending in open diamond: a set

This can be seen in the diagram “Topic Characteristics are assigned within Scopes”: the relationship of “Topic” to “Scope” is that a Scope is a set of one of more Topics.

In this Annex, the names of classes are capitalized, as: Class.

top-of-section B.1 Class Hierarchy

Figure B-1: Class Hierarchy (class diagram)
Figure B-1: Class Hierarchy (class diagram)

A Subject is anything that can be spoken about or conceived of by a human being. A Resource is a Subject that has identity within the bounds of a computer system. Any other Subject is known as a Non-addressable Subject. There are many types of Non-addressable Subject. A Class is a Non-addressable Subject. Types of Resource include String, XML Element, and XML Attribute, as well as Topic Map, Topic Map Node and Topic Characteristic, and many others. Types of XML Element include <topic> Element and <association> Element, and many others. There are just three types of Topic Map Node: Topic, Association, and Scope. There are just three types of Topic Characteristic: Base Name, Occurrence, and Role.

top-of-section B.2 Class-Instance Relationship

Figure B-2: Class-Instance Relationship (class diagram)
Figure B-2: Class-Instance Relationship (class diagram)

A Subject may be an instance of zero or more Classes.

top-of-section B.3 A Topic Reifies a Subject

Figure B-3: A Topic Reifies a Subject (class diagram)
Figure B-3: A Topic Reifies a Subject (class diagram)

A Topic is a Resource that reifies a Subject. It is the Topic Map system's representation of the Subject. Reification of a Subject allows Topic Characteristics to be assigned to the Topic that reifies it.

top-of-section B.4 Referencing the Subject

Figure B-4: Referencing the Subject (class diagram)
Figure B-4: Referencing the Subject (class diagram)

A Topic can have any number of Subject Indicators. A Subject Indicator is a Resource that indicates what Subject is reified by the Topic. If the Subject is itself a Resource, there can be a direct reference from the Topic to that Resource in addition to any references there may be to Subject Indicators.

top-of-section B.5 Topic Characteristics Are Assigned Within Scopes

Figure B-5: Topic Characteristics Are Assigned Within Scopes (class diagram)
Figure B-5: Topic Characteristics Are Assigned Within Scopes (class diagram)

A Scope is set of Topics that defines the extent of the validity of the assignment of a Topic Characteristic to a Topic. If no Scope is specified, the Scope is deemed to be the unconstrained Scope, and the assignment is always valid.

top-of-section B.6 Base Name Within Scope

Figure B-6: Base Name Within Scope (class diagram)
Figure B-6: Base Name Within Scope (class diagram)

A Base Name is a String that is used to name a Topic within a Scope. Only one Topic may be assigned a particular Base Name within a given Scope. The set of Base Names assigned within a given Scope thus constitutes a namespace, and may be used to identify Topics unambiguously.

top-of-section B.7 Occurrence

Figure B-7: Occurrence (class diagram)
Figure B-7: Occurrence (class diagram)

An Occurrence designates a Resource that relates to a Topic.

top-of-section B.8 Association Between Topics

Figure B-8: Association Between Topics (class diagram)
Figure B-8: Association Between Topics (class diagram)

An Association relates Topics to one another. It comprises one or more Roles, each of which corresponds to a Topic that specifies a type of involvement that Topics may have in the Association. Each Role is assigned to zero or more Topics that are involved in the Association in the way specified. These Topics are said to be players of that Role in the Association.

NOTE: In XTM, it is not permissible for the different Roles in an Association to be governed by different Scopes. The XTM syntax expresses the Scopes on all the Roles of an Association through a single <scope> subelement of the <association> element.

top-of-section B.9 Topic Map

Figure B-9: Topic Map (class diagram)
Figure B-9: Topic Map (class diagram)

A Topic Map comprises zero or more Topic Map Nodes (Topics, Scopes, and Associations). It is possible for more than one Topic in the Topic Map to reify the same Subject. If no Subject is reified by more than one Topic in the Topic Map, then the Topic Map is said to be a Consistent Topic Map.


top Annex C: XTM Conceptual Model to Interchange Syntax Mapping (Informative)

The XTM Conceptual Model and its Interchange Syntax do not map to one another directly through a one-to-one correspondence between syntactic constructs and objects in the Conceptual Model. There are several ways in which objects described by the Conceptual Model may relate to constructs in the XTM Interchange Syntax:

  • In some cases, a syntactic construct IS the object described by the model.
  • In some cases, a syntactic construct REFERENCES the object described by the model through the conventions of URI syntax.
  • In some cases, a syntactic construct REPRESENTS the object described by the model.
  • In some cases, the object described has no direct correspondence in the syntax at all, but instead is INDICATED by the human-readable content of a Resource.

The ways in which the constructs in the Interchange Syntax relate to the objects in the Conceptual Model are specified in the prose descriptions of the syntactic constructs in Section 3, XTM Syntax Documentation. A more formal specification of these relationships is under development and will be published in a subsequent document from TopicMaps.Org.


top Annex D: XTM 1.0 Document Type Declaration (Normative)

Note: In the online version of this DTD, the element type name of each element declaration links to documentation in this specification. Element type names in content models link to their respective declarations in the DTD.


  <!-- ............................................................. -->
  <!-- XML Topic Map DTD  .......................................... -->
  <!-- file: xtm1.dtd
  -->
  <!-- XML Topic Map (XTM) DTD, Version 1.0

       This is XTM, an XML interchange syntax for ISO 13250 Topic Maps.

       XML Topic Map (XTM)
         Copyright 2000-2001 TopicMaps.Org, All Rights Reserved.

       Permission to use, copy, modify and distribute the XTM DTD and its
       accompanying materials for any purpose and without fee is hereby
       granted in perpetuity, provided that the above copyright notice and
       this paragraph appear in all copies. The copyright holders make no
       representation about the suitability of the DTD for any purpose. It
       is provided "as is" without expressed or implied warranty.

          Editors:    Steve Pepper      <pepper@ontopia.net>
                      Graham Moore      <gdm@empolis.co.uk>
          Authors:    Murray Altheim    <altheim@eng.sun.com>
                      Michel Biezunski  <mb@infoloom.com>
                      Sam Hunting       <shunting@etopicality.com>
                      Steven R. Newcomb <srn@coolheads.com>
          Status:     Release
          Version:    v1.0.1
          Revision:   $Id: xtm1.dtd,v 1.2 2001/02/08 16:03:12 pepper Exp $
          PublicId:   "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN"

          Revisions:
  #2001-01-21: removed baseName from occurrence
  #2001-02-02: made variantName optional in variant
  #2001-02-02: changed ID to #IMPLIED on association
  #2001-02-02: changed ID to #IMPLIED on resourceData
  #2001-02-02: changed PLUS to REP on member

  -->
  <!-- Use this URI to identify the default XTM namespace:

           "http://www.topicMaps.org/xtm/1.0/"

       Used to identify the XLink namespace:

           "http://www.w3.org/1999/xlink"
  -->

  <!-- topicMap: Topic Map document element ........................ -->

  <!ELEMENT topicMap
     ( topic | association | mergeMap )*
  >
  <!ATTLIST topicMap
     id              ID        #IMPLIED
     xmlns           CDATA     #FIXED 'http://www.topicmaps.org/xtm/1.0/'
     xmlns:xlink     CDATA     #FIXED 'http://www.w3.org/1999/xlink'
     xml:base        CDATA     #IMPLIED
  >

  <!-- topic: Topic element ........................................ -->

  <!ELEMENT topic
     ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* )
  >
  <!ATTLIST topic
     id              ID        #REQUIRED
  >

  <!-- instanceOf: Points To a Topic representing a class .......... -->

  <!ELEMENT instanceOf  ( topicRef | subjectIndicatorRef ) >
  <!ATTLIST instanceOf
     id              ID        #IMPLIED
  >

  <!-- subjectIdentity: Subject reified by Topic ................... -->

  <!ELEMENT subjectIdentity
     ( resourceRef?, ( topicRef | subjectIndicatorRef )* )
  >
  <!ATTLIST subjectIdentity
     id              ID        #IMPLIED
  >

  <!-- topicRef: Reference to a Topic element ...................... -->

  <!ELEMENT topicRef  EMPTY >
  <!ATTLIST topicRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

  <!-- subjectIndicatorRef: Reference to a Subject Indicator ....... -->

  <!ELEMENT subjectIndicatorRef  EMPTY >
  <!ATTLIST subjectIndicatorRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

  <!-- baseName: Base Name of a Topic .............................. -->

  <!ELEMENT baseName  ( scope?, baseNameString, variant* ) >
  <!ATTLIST baseName
     id              ID        #IMPLIED
  >

  <!-- baseNameString: Base Name String container .................. -->

  <!ELEMENT baseNameString  ( #PCDATA ) >
  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

  <!-- variant: Alternate forms of Base Name ....................... -->

  <!ELEMENT variant  ( parameters, variantName?, variant* ) >
  <!ATTLIST variant
     id              ID        #IMPLIED
  >

  <!-- variantName: Container for Variant Name ..................... -->

  <!ELEMENT variantName  ( resourceRef | resourceData ) >
  <!ATTLIST variantName
     id              ID        #IMPLIED
  >

  <!-- parameters: Processing context for Variant .................. -->

  <!ELEMENT parameters  ( topicRef | subjectIndicatorRef )+ >
  <!ATTLIST parameters
     id              ID        #IMPLIED
  >

  <!-- occurrence: Resources regarded as an Occurrence ............. -->

  <!ELEMENT occurrence
     ( instanceOf?, scope?, ( resourceRef | resourceData ) )
  >
  <!ATTLIST occurrence
     id              ID        #IMPLIED
  >

  <!-- resourceRef: Reference to a Resource ........................ -->

  <!ELEMENT resourceRef  EMPTY >
  <!ATTLIST resourceRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

  <!-- resourceData: Container for Resource Data ................... -->

  <!ELEMENT resourceData  ( #PCDATA ) >
  <!ATTLIST resourceData
     id              ID        #IMPLIED
  >

  <!-- association: Topic Association  ............................. -->

  <!ELEMENT association
     ( instanceOf?, scope?, member+ )
  >
  <!ATTLIST association
     id              ID        #IMPLIED
  >

  <!-- member: Member in Topic Association ......................... -->

  <!ELEMENT member
     ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )* )
  >
  <!ATTLIST member
     id              ID        #IMPLIED
  >

  <!-- roleSpec: Points to a Topic serving as an Association Role .. -->

  <!ELEMENT roleSpec  ( topicRef | subjectIndicatorRef ) >
  <!ATTLIST roleSpec
     id              ID        #IMPLIED
  >

  <!-- scope: Reference to Topic(s) that comprise the Scope ........ -->

  <!ELEMENT scope  ( topicRef  | resourceRef | subjectIndicatorRef )+ >
  <!ATTLIST scope
     id              ID        #IMPLIED
  >

  <!-- mergeMap: Merge with another Topic Map ...................... -->

  <!ELEMENT mergeMap  ( topicRef | resourceRef | subjectIndicatorRef )* >
  <!ATTLIST mergeMap
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

  <!-- end of XML Topic Map (XTM) 1.0 DTD -->

top Annex E: XTM 1.0 Core Published Subject Indicators (Normative)

Note: In the online version of this topic map, the unique identifier (“id”) of each topic or association element links to documentation in this specification.


  <?xml version="1.0"?>
  <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN"
                            "xtm1.dtd">
  <topicMap id="xtm1.0-psi-core"
      xmlns="http://www.topicmaps.org/xtm/1.0/"
      xml:base="http://www.topicmaps.org/xtm/1.0/">
  <!--
       XTM 1.0 Core Published Subject Indicators (PSIs)

       XML Topic Map (XTM)
         Copyright 2000-2001 TopicMaps.Org, All Rights Reserved.

       Permission to use this document for any purpose and without
       fee is hereby granted to the public in perpetuity, provided
       that the above copyright notice and this paragraph appear in
       all copies. The copyright holders make no representation as
       to its suitability for any purpose. It is provided "as is"
       and without expressed or implied warranty.

          Editors:    Steve Pepper <pepper@ontopia.net>
                      Graham Moore <gdm@empolis.co.uk>
          Status:     Final
          Version:    v1.0
          Revision:   $Id: core.xtm,v 1.3 2001/02/21 21:27:27 pepper Exp $
          PublicId:
            "-//TopicMaps.Org//DOCUMENT XTM 1.0 Core Published Subject Indicators//EN"

          Revisions:
  #2000-12-03: added comments from XTM 1.0 Core
  #2001-02-01: major revision to align with Paris decisions
  #2001-02-01: turned descriptions into occurrences and subject indicators
  -->
  <!-- XTM Published Subject Indicators

       The topic elements in this document are designed to serve as
       published subject indicators for topics declared in other topic
       maps whose subjects are the same as the subjects of these topic
       elements.

       In the referencing topic maps, the addresses used to refer to
       these topic elements must use the unique identifiers (i.e. the
       "URI" values indicated within the occurrences) of these elements,
       because their unique identifiers are permanent; their relative
       positions in the document are not necessarily permanent.
       Addressing may use indirection via a topic element.

       TopicMaps.Org reserves the right to enhance the usefulness of
       these published subject indicators, and to provide additional
       published subject indicators, but only in ways that will not
       negatively impact the value or usefulness of any existing
       conforming topic map documents.

       The subjects of these published subject indicators are described
       in the XTM 1.0 Specification as "mandatory," that is, conforming
       applications must be capable of supporting the use of these
       subjects as described in the XTM 1.0 Specification.

       The subject indicators referenced by these topic elements are the
       portions of the XTM 1.0 Specification that provide their
       normative descriptions. Other topic maps should normally use
       these topic elements as the identity points of these subjects,
       rather than the subject indicators that they themselves
       reference. These topic elements may be edited, at some future
       date, in such a way as to provide additional subject indicators
       that will refer to any portions of future versions of the XTM
       Specification that describe the same subject.
  -->

    <!-- begin: XTM core concepts -->

    <topic id="topic">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-topic"/>
        <subjectIndicatorRef xlink:href="#psi-topic-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>topic</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-topic-description">
          Topic: The core concept of topic; the generic class to
          which all topics belong unless otherwise specified.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#topic
        </resourceData>
      </occurrence>
    </topic>

    <topic id="association">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-association"/>
        <subjectIndicatorRef xlink:href="#psi-association-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>association</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-association-description">
          Association: The core concept of association; the generic class
          to which all associations belong unless otherwise specified.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#association
        </resourceData>
      </occurrence>
    </topic>

    <topic id="occurrence">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-occurrence"/>
        <subjectIndicatorRef xlink:href="#psi-occurrence-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>occurrence</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-occurrence-description">
          Occurrence: The core concept of occurrence; the generic class
          to which all occurrences belong unless otherwise specified.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#occurrence
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: XTM core concepts -->

    <!-- begin: the class-instance relationship -->

    <topic id="class-instance">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-class-instance"/>
        <subjectIndicatorRef xlink:href="#psi-class-instance-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>class-instance relationship</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-class-instance-description">
          Class-instance relationship: The core concept of class-instance;
          the class of association that represents class-instance
          relationships between topics, and that is semantically
          equivalent to the use of &lt;instanceOf&gt; subelements.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance
        </resourceData>
      </occurrence>
    </topic>

    <topic id="class">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-class"/>
        <subjectIndicatorRef xlink:href="#psi-class-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>class</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-class-description">
          Class: The core concept of class; the role of class as played
          by one of the members of a class-instance association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#class
        </resourceData>
      </occurrence>
    </topic>

    <topic id="instance">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-instance"/>
        <subjectIndicatorRef xlink:href="#psi-instance-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>instance</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-instance-description">
          Instance: The core concept of instance; the role of instance as
          played by one of the members of a class-instance association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#instance
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: the class-instance relationship -->

    <!-- begin: the superclass-subclass relationship -->

    <topic id="superclass-subclass">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-superclass-subclass"/>
        <subjectIndicatorRef xlink:href="#psi-superclass-subclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>superclass-subclass relationship</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-superclass-subclass-description">
          Superclass-subclass relationship: The core concept of
          superclass-subclass; the class of association that represents
          superclass-subclass relationships between topics.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass
        </resourceData>
      </occurrence>
    </topic>

    <topic id="superclass">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-superclass"/>
        <subjectIndicatorRef xlink:href="#psi-superclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>superclass</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-superclass-description">
          Superclass: The core concept of superclass; the role of superclass
          as played by one of the members of a superclass-subclass association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#superclass
        </resourceData>
      </occurrence>
    </topic>

    <topic id="subclass">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-subclass"/>
        <subjectIndicatorRef xlink:href="#psi-subclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>subclass</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-subclass-description">
          Subclass: The core concept of subclass; the role of subclass as
          played by one of the members of a superclass-subclass association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#subclass
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: the superclass-subclass relationship -->

    <!-- begin: variant name parameter concepts -->

    <topic id="sort">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-sort"/>
        <subjectIndicatorRef xlink:href="#psi-sort-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>suitability for sorting</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-sort-description">
          Suitability for sorting: Suitability of a topic name for
          use as a sort key; for use in the parameters of variant names.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#sort
        </resourceData>
      </occurrence>
    </topic>

    <topic id="display">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-display"/>
        <subjectIndicatorRef xlink:href="#psi-display-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>suitability for display</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-display-description">
          Suitability for display: Suitability of a topic name for
          display; for use in the parameters of variant names.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#display
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: variant name parameter concepts -->

  <!-- end of XTM 1.0 Core Published Subject Indicators (PSIs) -->

  </topicMap>

In addition to the XTM 1.0 Core Published Subject Indicators topic map shown above, XTM topic maps for natural language and country (e.g. for use in topic map internationalization), are provided below:


top Annex F: XTM Processing Requirements (Informative)

top-of-section F.1 Introduction

This annex describes the minimal requirements for a conformant XTM processor. At a minimum an XTM processor is required to be capable of processing one or more topic map documents into an internal model which represents the topic map information contained in those documents in such a manner that a consistent topic map is accessible by clients of the processor.

The XTM processing requirements are stated in terms of:

  • Equality principles
  • Equivalence principles
  • Variant operations
  • Merge operations
  • Duplicate suppression

top-of-section F.2 Equality principles

The following equality statements define the rules by which a conformant XTM processor is required to determine the equality of topic map constructs.

top-of-section F.2.1 String equality principle

A conformant XTM processor is required to be capable of comparing two strings for equality. Before any comparison occurs, a compliant XTM processor must transcode all strings into Unicode/ISO 10646. Given this transcoding, two strings are considered equal if they are encoded as identical sequences of scalar values. A conformant XTM processor application may apply additional algorithms for determining string equality.

top-of-section F.2.2 URI equality principle

A conformant XTM processor must consider two URIs to be equal if they are found to be equal using the rules defined for the appropriate URI scheme.

Section 6 of RFC 2396 provides the general definition of how 2 URIs are deemed to be equal. Below is a set of references to URI schemes that a conformant XTM processor must support:

  • http (RFC 1738 section 3.3)
  • ftp (RFC 1738 section section 3.2)
  • https (RFC 1738 section 3.3)
  • file (RFC 1738 section 3.10)
  • urn (RFC 2141),
    • A conformant XTM processor must decide URN equality based on the URI equivalence rules as defined in RFC 2396 section 6.
    • A conformant XTM processor may decide URN equality based on the definitions in particular URN scheme documentation.

top-of-section F.2.3 Scope equality principle

In a consistent topic map a conformant XTM processor must consider two scopes equal if they contain the same set of topics.

top-of-section F.2.4 Association equality principle

A conformant XTM processor must considrer two associations to be equal if the following are true:

  1. The associations are comprised of the same set of roles.
  2. The set of topics playing each role in the associations are equal.
  3. The associations are instances of the same class.
  4. The scopes of the associations are equal as defined by the scope equality principle.

top-of-section F.2.5 Topic Name equality principle

Two base names are considered equal if the following are true:

  1. The string values of the base names are equal as defined by the string equality principle.
  2. The scopes in which the base names occur are equal as defined by the scope equality principle.

Variant Names are ignored when deciding if two names are equal.

top-of-section F.2.6 Topic Occurrence equality principle

Two topic occurrences are considered equal if the following are true:

  1. In the case of <resourceRef> elements, the URIs used to address the occurrences are equivalent as defined by the URI equality principle; or

    In the case of <resourceData> elements, the resource data values that are the occurrences are equal. (Before any comparison of values occurs, an XTM processor must transcode all strings into Unicode/ISO 10646. Given this, two resource data values are considered equal if they are encoded as identical sequences of scalar values.)

  2. The occurrences are of the same class.
  3. The scopes of the occurrences are equal as defined by the scope equality principle.

top-of-section F.3 Equivalence principles

Equivalence principles state the different ways in which the same topic map nodes may be conveyed by different syntactic representations. A conformant XTM processor is required to recognise all equivalent syntactic representations of topic map constructs, as listed in this section and process them in such a way that in the processed topic map it is undetectable which syntactic representations were used.

top-of-section F.3.1 Equivalence of <subjectIndicatorRef> and <topicRef>

A <subjectIndicatorRef> element which references topic A may be equivalently expressed by a <topicRef> element which also references topic A.

A <subjectIndicatorRef> element that references a resource other than a topic may be equivalently expressed by a <topicRef> element that refers to a topic which regards the resource as a subject indicator.

top-of-section F.3.2 Equivalence of <instanceOf> and <association>

An <instanceOf> element expresses a relationship between the <topic>, T,  referenced from the child element of the <instanceOf> element and the <topic>, <association> or <occurrence> which is the parent element of the <instanceOf> element.

This relationship may be equivalently expressed by an <association> that is an instance of the published subject “class-instance” and which has two roles in the unconstrained scope — the “class” role and the “instance” role. The player of the “class” role is the topic T. If the parent element of <instanceOf> is a <topic> element then the player of the “instance” role is the topic represented by that <topic> element. If the parent element of <instanceOf> is not a <topic> element, then the player of the “instance” role is a topic which reifies the association or occurrence represented by that parent element.

If an <association> is used to express a “class-instance” relationship it is a reportable XTM Error if any of the following are true:

  1. The “class” role is played by a topic with an addressable subject.
  2. Either the “class” or “instance” roles are not roles of the association.
  3. Roles other than the “class” and “instance” roles are part of the association.

top-of-section F.3.3 Equivalence of Multiple <member>s of the Same Role

An association containing multiple members, M1 and M2 of the same role R may be equivalently defined by an association containing a single member M3 of role R whose set of players is the union of the sets of players of role R in members M1 and M2.

top-of-section F.4 Variant Operations

top-of-section F.4.1 Variant scope processing

The processing context of a variant name defined by a <variant> element is defined as the union of the parameters of the <variant> element and all of its ancestor <variant> elements.

Thus a variant name with a set of parameters is equivalent to having the same set of parameters on a parent variant and having no additional parameters itself.

top-of-section F.5 Merge operations

top-of-section F.5.1 Topic merge operation

Precondition:

  1. Two topics, A and B are to be merged.

Postcondition:

  1. A single topic M exists.
  2. The set of name characteristics of M is equal to the union of the set of name characteristics of A and B.
  3. The set of subject indicators of M is equal to the union of the set of subject indicators of A and B.
  4. The addressable subject of M is equal to the addressable subject of either A or B.
  5. M replaces A and B as a player of any roles played in associations in the topic map.
  6. The set of occurrence assignments of M is equal to the union of occurrence assignments of A and B.
  7. A and B no longer exist

Error Condition:

It is a Reportable XTM Error if:

  1. Topics A and B have different addressable subjects

Example:

Before:
  <topicMap>

    <topic id="t34">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet.html" />
      </occurrence>
    </topic>

    <topic id="t35">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Prince Of Denmark</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html" />
      </occurrence>
    </topic>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t34" />
      </member>
    </association>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t35" />
      </member>
    </association>

  </topicMap>
After:
  <topicMap>

  <!--
     Note that the topics are merged and as a result of this the
     association duplicate redundancy rule is invoked. This removes
     the now duplicate association.
  -->

    <topic id="t36">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Prince Of Denmark</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet.html" />
      </occurrence>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html" />
      </occurrence>
    </topic>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t36" />
      </member>
    </association>

  </topicMap>

top-of-section F.5.2 Subject-based merge operation

Precondition:

Two topics A and B exist in topic map M such that:

  1. the URIs of the addressable subjects of A and B are equal according to the URI equality principle, or
  2. topic B is a subject indicator of topic A, or
  3. there exists two URIs U1 and U2, where U1 is a subject indicator of topic A and U2 is a subject indicator of topic B and U1 is equal to U2 according to the URI equality principle, or
  4. there exist two URIs U1 and U2, where U1 is a subject indicator of topic A and U2 is a subject indicator of topic B and the XTM processing application has determined via application specific processing that the subject indicator referenced by U1 indicates the same subject as that referenced by U2.

Postcondition:

  1. Topics A and B are merged with pre and post-conditions as specified by the topic merge operation.

Example 1. The URIs of the addressable subjects of A and B are equal:

Before:
  <topicMap>
    <topic id="t1">
      <subjectIdentity>
        <resourceRef xlink:href="http://www.topicmaps.org" />
      </subjectIdentity>
      <baseName>
        <baseNameString>TopicMaps.Org web-site</baseNameString>
      </baseName>
    </topic>

    <topic id="t2">
      <subjectIdentity>
        <resourceRef xlink:href="http://www.topicmaps.org" />
      </subjectIdentity>
      <baseName>
        <baseNameString>The Web-site of TopicMaps.Org</baseNameString>
      </baseName>
    </topic>
  </topicMap>
After:
  <topicMap>
    <topic id="t3">
      <subjectIdentity>
        <resourceRef xlink:href="http://www.topicmaps.org" />
      </subjectIdentity>
      <baseName>
        <baseNameString>TopicMaps.Org web-site</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Web-site of TopicMaps.Org</baseNameString>
      </baseName>
     </topic>
  </topicMap>

Example 2. The two topics have at least one subject indicator URI in common:

Before:
  <topicMap>
    <topic id="t1">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays/hamlet.html" />
        <subjectIndicatorRef xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt" />
      </subjectIdentity>
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
    </topic>

    <topic id="t2">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays/hamlet.html" />
      </subjectIdentity>
      <baseName>
        <baseNameString>The Tragedy of Hamlet, Prince of Denmark</baseNameString>
      </baseName>
    </topic>
  </topicMap>
After:
  <topicMap>
    <topic id="t3">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays/hamlet.html" />
        <subjectIndicatorRef xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt" />
      </subjectIdentity>
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Tragedy of Hamlet, Prince of Denmark</baseNameString>
      </baseName>
    </topic>
  </topicMap>

top-of-section F.5.3 Topic naming constraint-based merge

Precondition:

Two topics A and B exist in topic map M such that:

  1. Topic A has a base name string B1 in a scope S1 and,
  2. Topic B has a base name string B2 in scope S2 and,
  3. Scope S1 is equal to scope S2 according to the scope equality principle and,
  4. The base name string B1 is equal to the base name string B2 according to the string equality principle.

Postcondition:

  1. T1 and T2 are merged according to the topic merge operation

Notes:

The scopes S1 and S2 may be the unconstrained scope.

Example 1. Topic naming constraint merge in unconstrained scope:

Before:
  <topic id="t1">
    <baseName>
      <baseNameString>Hamlet, Prince of Denmark</baseNameString>
    </baseName>
  </topic>

  <topic id="t2">
    <baseName>
      <baseNameString>Hamlet, Prince of Denmark</baseNameString>
    </baseName>
  </topic>
After:
  <topic id="t3">
    <baseName>
      <baseNameString>Hamlet, Prince of Denmark</baseNameString>
    </baseName>
  </topic>

Example 2. Topic naming constraint merge in scope:

Before:
  <topicMap>
   <topic id="t1">
    <baseName>
     <scope>
      <topicRef xlink:href="#shakespearean-tragedy" />
     </scope>
     <baseNameString>Hamlet, Prince of Denmark</baseNameString>
    </baseName>
   </topic>

   <topic id="t2">
    <baseName>
     <scope>
      <topicRef xlink:href="#shakespearean-tragedy" />
     </scope>
     <baseNameString>Hamlet, Prince of Denmark</baseNameString>
    </baseName>
   </topic>
  </topicMap>
After:
  <topicMap>
    <topic id="t3">
      <baseName>
        <scope>
          <topicRef xlink:href="#shakespearean-tragedy" />
        </scope>
        <baseNameString>Hamlet, Prince of Denmark</baseNameString>
      </baseName>
    </topic>
  </topicMap>

top-of-section F.5.4 Explicit topic map merge

Precondition:

  1. A <mergeMap> element is processed in topic map M that references a topic map document D.
  2. The <mergeMap> element contains references to a set of subjects S by means of its child elements.

Postcondition:

  1. Every topic and association in D is added to the topic map; the scope of every base name, occurrence and association role originating in D is expressed as the union of the set of subjects in its original scope and the set S.

Note: Any merge map directives in D are further processed according to this rule. Sets of subjects S are accumulated down the chain.

top-of-section F.5.5 Implicit topic map merge

Precondition:

  1. A <topicRef> is processed.
  2. The processed <topicRef> references a topic in a topic map, M,  which has not yet been processed.
  3. The application chooses to resolve the <topicRef> to the referenced topic

Postcondition:

  1. Every topic and association in M is added to the topic map and additional merging and duplicate suppression may occur.

Note: Any merge map directives in M are processed according to the explicit topic map merge rule.

top-of-section F.6 Duplicate suppression

top-of-section F.6.1 Subject indicator duplicate suppression

Precondition:

  1. A topic A exists in topic map M with two URI references to subject indicators, U1 and U2.
  2. U1 is equal to U2 according to the URI equality principle.

Postcondition:

The reference to the subject indicator specified by U2 is removed from A.

Example:

Before:
  <topic id="t1">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" />
      <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" />
    </subjectIdentity>
  </topic>
After:
  <topicMap>
    <topic id="t1">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" />
      </subjectIdentity>
    </topic>
  </topicMap>

top-of-section F.6.2 Topic name duplicate suppression

Precondition:

  1. A topic A exists in topic map M with basename B1 that contains a base name string N1 in scope S1 and base name B2 which contains a base name string N2 in scope S2.
  2. N1 is equal to N2 as defined by the string equality principle.
  3. S1 is equal to S2 as defined by the scope equality principle.

Postcondition:

  1. A base name B3 is created which contains a base name string equal to N1 in a scope equal to S1.
  2. All variants of B1 are added to B3.
  3. All variants of B2 are added to B3.
  4. B3 is added to the set of names of A.
  5. B1 and B2 no longer exist.

top-of-section F.6.3 Association duplicate suppression

Precondition:

  1. The topic map contains two associations A1 and A2
  2. A1 is equal to A2 as defined by the association equality principle.

Postcondition:

  1. A2 is removed from the topic map

Example:

Before:
  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
        <topicRef xlink:href="#ctb" />
      </member>
    </association>

    <association id="a35">
     <member>
       <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
       <topicRef xlink:href="#gdm" />
       <topicRef xlink:href="#ctb" />
     </member>
    </association>
  </topicMap>
After:
  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
        <topicRef xlink:href="#ctb" />
      </member>
    </association>
  </topicMap>

top-of-section F.6.4 Role player duplicate suppression

Precondition:

  1. An association A has members M1 and M2
  2. M1 and M2 reference the same topic RT as the role-defining topic
  3. M1 and M2 reference the same topic RPT as the role-playing topic

Postcondition:

  1. M2 is removed from association A.

Example:

Before:
  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#ctb" />
      </member>
    </association>
  </topicMap>
After:
  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#ctb" />
      </member>
    </association>
  </topicMap>

top Annex G: ISO 13250 to XTM 1.0 Document Transformation (Informative)

This annex provides a link to information describing the transformation of topic map documents conforming to ISO 13250 into XTM 1.0 syntax.


top Annex H: Acknowledgements (Informative)

The development of XML Topic Maps (XTM) 1.0 was a team effort, led by the TopicMaps.Org Authoring Group. The editors would like to thank the following people in particular for major contributions to the editorial process:

  • Michel Biezunski & Steven R. Newcomb (co-chairs, Interchange Syntax Subgroup)
    Daniel Rivers-Moore (chair, Conceptual Model Subgroup)
    Kal Ahmed (chair, Processing Requirements Subgroup)
    Murray Altheim & Sam Hunting (associate editors)

The Participating Members of the TopicMaps.Org Authoring Group in good standing at the time of publication include:

  • Murray Altheim (Sun Microsystems)*, Michel Biezunski (InfoLoom, Inc.)*, Jean Delahousse (Mondeca)*, Patrick Durusau (Society of Biblical Literature)*, Eric Freese (Isogen/DataChannel)*, Sam Hunting (Etopicality)*, Andrius Kulikauskas (Minciu Sodas)*, Luis Martinez*, Graham Moore (Empolis)*, Steven R. Newcomb*, Nikita Ogievetsky (Cogitech, Inc.)*, Jack Park (VerticalNet Solutions)*, Steve Pepper (Ontopia)*, Daniel Rivers-Moore (RivCom)*, and Bryan Thompson (GlobalWisdom, Inc.)*.

Thanks also to Invited Guests and others who have provided valuable input into the process:

  • Kal Ahmed (Ontopia)*, Chris Angus (Kalido Ltd), David Duncan (ADIS International)*, Lars Marius Garshol (Ontopia), David Goldstein (Versaware)*, Geir Ove Grønmo (Ontopia), Jason Hanna (EMC)*, Ivan Harré (ADIS International)*, Michael Hoexter*, G. Ken Holman (Crane Softwrights Ltd.)*, Peter Jones (Wrox Press)*, Dianne Kennedy (InfoLoom, Inc.)*, W. Eliot Kimber (Isogen/DataChannel)*, Daniel Koger (Herrick Douglass)*, Benedicte LeGrand (Laboratoire d'Informatique de Paris 6)*, Aaron Lowe (Wrox Press)*, James Mason (Y-12 National Security Complex), Norbert Mikula (DataChannel)*, Peter Newcomb (Epremis Corporation), Laurent Olivry (Electricité de France), Eugene Pereira (CCH)*, Christina Portillo (Boeing)*, Hans Holger Rath (Empolis), Adrian Rivers (RivCom), Vishal Shah (NEC)*, Daniel Speck (The Bureau of National Affairs)*, Drew Stevens (McKinsey & Company)*, Bliksem Tobey (McKinsey & Company)*, Bernard Vatant (Mondeca), Jenny Watson (Wrox Press)*, Matthew West (Shell Services International), and Ann Wrightson (Ontopia).

Many thanks to others who have provided comments and feedback, as well as to those organizations that have supported the development of XTM through their commitments of valuable resources.

Finally, we'd like to thank Shakespeare & Company for permission to use their web site's URL in our examples.

*founding member of TopicMaps.Org.

top-of-document