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.

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.

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.

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

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.

2.2.1 Topic

2.2.2 Name

2.2.3 Occurrence

2.2.4 Association

2.2.5 Topic Map

2.3.1 Introduction

2.3.2 XTM Mandatory Published Subject Indicators

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.

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:

• <topicRef>: Reference to a Topic element
• <subjectIndicatorRef>: Reference to a Subject Indicator
• <scope>: Reference to Topic(s) that comprise the Scope
• <instanceOf>: Points to a Topic representing a class
• <topicMap>: Topic Map document element
• <topic>: Topic element
• <subjectIdentity>: Subject reified by Topic
• <baseName>: Base Name of a Topic
• <baseNameString>: Base Name String container
• <variant>: Alternate forms of Base Name
• <variantName>: Container for Variant Name
• <parameters>: Processing context for Variant
• <association>: Topic Association
• <member>: Member in Topic Association
• <roleSpec>: Points to a Topic serving as an Association Role
• <occurrence>: Resources regarded as an Occurrence
• <resourceRef>: Reference to a Resource
• <resourceData>: Container for Resource data
• <mergeMap>: Merge with another Topic Map

3.2.1 <topicRef> Element

  <!ELEMENT topicRef  EMPTY >

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

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

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

3.2.2 <subjectIndicatorRef> Element

  <!ELEMENT subjectIndicatorRef  EMPTY >

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

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

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

3.3.1 <scope> Element

  <!ELEMENT scope  ( topicRef  | resourceRef | subjectIndicatorRef )+ >

  <!ATTLIST scope
     id              ID        #IMPLIED
  >

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

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

3.4.1 <instanceOf> Element

  <!ELEMENT instanceOf  ( topicRef | subjectIndicatorRef ) >

  <!ATTLIST instanceOf
     id              ID        #IMPLIED
  >

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

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

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

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

3.5.1 <topicMap> 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
  >

  ...
    <topicMap>

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

    </topicMap>
  ...

  <?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>

3.6.1 <topic> Element

  <!ELEMENT topic
     ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* )
  >

  <!ATTLIST topic
     id              ID        #REQUIRED
  >

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

3.6.2 <subjectIdentity> Element

  <!ELEMENT subjectIdentity
     ( resourceRef?, ( topicRef | subjectIndicatorRef )* )
  >

  <!ATTLIST subjectIdentity
     id              ID        #IMPLIED
  >

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

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

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

3.7.1 <baseName> Element

  <!ELEMENT baseName  ( scope?, baseNameString, variant* ) >

  <!ATTLIST baseName
     id              ID        #IMPLIED
  >

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

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

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

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

3.7.2 <baseNameString> Element

  <!ELEMENT baseNameString  ( #PCDATA ) >

  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

3.7.3 <variant> Element

  <!ELEMENT variant  ( parameters, variantName?, variant* ) >

  <!ATTLIST variant
     id              ID        #IMPLIED
  >

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

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

3.7.4 <variantName> Element

  <!ELEMENT variantName  ( resourceRef | resourceData ) >

  <!ATTLIST variantName
     id              ID        #IMPLIED
  >

3.7.5 <parameters> Element

  <!ELEMENT parameters  ( topicRef | subjectIndicatorRef )+ >

  <!ATTLIST parameters
     id              ID        #IMPLIED
  >

3.8.1 <association> Element

  <!ELEMENT association
     ( instanceOf?, scope?, member+ )
  >

  <!ATTLIST association
     id              ID        #IMPLIED
  >

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

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

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

3.8.2 <member> Element

  <!ELEMENT member
     ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )+ )
  >

  <!ATTLIST member
     id              ID        #IMPLIED
  >

3.8.3 <roleSpec> Element

  <!ELEMENT roleSpec  ( topicRef | subjectIndicatorRef ) >

  <!ATTLIST roleSpec
     id              ID        #IMPLIED
  >

3.9.1 <occurrence> Element

  <!ELEMENT occurrence
     ( instanceOf?, scope?, ( resourceRef | resourceData ) )
  >

  <!ATTLIST occurrence
     id              ID        #IMPLIED
  >

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

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

3.9.2 <resourceRef> Element

  <!ELEMENT resourceRef  EMPTY >

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

3.9.3 <resourceData> Element

  <!ELEMENT resourceData  ( #PCDATA ) >

  <!ATTLIST resourceData
     id              ID        #IMPLIED
  >

3.10.1 <mergeMap> Element

  <!ELEMENT mergeMap  ( topicRef | resourceRef | subjectIndicatorRef )* >

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

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

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

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.

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

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.

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.

An XTM application is any software module that:

• interprets a <topicMap> element, producing a processed topic map as defined and described in Annex F: XTM Processing Requirements.

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.

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.

B.0 Introduction

B.1 Class Hierarchy

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.

B.2 Class-Instance Relationship

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

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

B.3 A Topic Reifies a Subject

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.

B.4 Referencing the Subject

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.

B.5 Topic Characteristics Are Assigned Within Scopes

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.

B.6 Base Name Within Scope

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.

B.7 Occurrence

Figure B-7: Occurrence (class diagram)

An Occurrence designates a Resource that relates to a Topic.

B.8 Association Between Topics

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.

B.9 Topic Map

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.

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.

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

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:

• XTM 1.0 Core Published Subject Indicators (core.xtm)
• XTM Language Topics (language.xtm)
• XTM Country Topics (country.xtm)

F.1 Introduction

F.2 Equality principles

F.3 Equivalence principles

F.4 Variant Operations

F.5 Merge operations

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

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

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

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

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

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

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

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

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

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

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

F.6 Duplicate suppression

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

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

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

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

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

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

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

• ISO 13250 to XTM 1.0 Document Transformation

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.