この標準情報(TR)は, 2001年8月にTopicMaps.Orgから公表されたXML Topic Maps (XTM) 1.0規定を翻訳し, 技術的内容を変更することなく作成した標準情報(TR)である。
この規定は，トピックと，トピック間の関連(関係)とを定義するために使用する，情報資源の構造表現のためのモデル及び文法を提供する。名前，資源及び関係は，トピックと呼ばれる抽象的な主題の特質になる。トピックは，有効範囲内でその特質をもつ。すなわち，限定された文脈内で，名前及び資源が，トピックの名前特質，資源特質及び関連特質とみなされる。この文法を利用する一つ以上の相互に関係する文書を“トピックマップ”と呼ぶ。
TopicMaps.Orgは，XML規格群を利用して，ウェブへのトピックマップの考え方[ISO13250]の適用を開発している独立したコンソシアムである。
この規定は，TopicMaps.Orgの文書作成グループのメンバによって記述された，XMLトピックマップ[XML Topic Maps (XTM)] 1.0 [XTM]の第1版，すなわち，ウェブに基づくトピックマップの交換のための抽象モデル及びXML文法，を示す。XTM及びTopicMaps.Orgについてのより詳細な情報は，http://www.topicmaps.org/about.htmlを参照すること。
XTM規定のすべての版は，TopicMaps.Orgの憲章に示されるとおり，永久的に公共に対して利用許諾が与えられる。
XMLトピックマップ(XTM)は，最初，Michel Biezunski及びSteven R. Newcombが議長を務め，この標準情報(TR)の原規定の配布時点では，Steve Pepper及びGraham Mooreが議長を務めるTopicMaps.Orgという名前の独立なコンソシアムが2000年に立ち上げたTopicMaps.Org文書作成グループの成果物である。XTM文書作成グループの参加メンバは，附属書H 貢献者に列挙されている。
トピックマップの考え方それ自体の起源は，Davenportグループの作業における作業文書として最初に示された1993年まで遡る。その考え方は，その後，HyTimeの応用のための規約(Conventions for the Application of HyTime)と呼ばれた活動の中で，GCA研究所(GCA Research Institute。現在はIDEAllianceとして知られている。)の作業において十分に開発された。GCA研究所の作業中及びその後も，その考え方は，個々のグループによって独立に，開発され，実装され，公表された。個々の国際的なグループによる数年の継続的な努力の後，2000年の始めに，トピックマップ考え方は，ISO国際規格，ISO/IEC 13250:2000，として，初めて，完全に公的な形で定式化された。その後，ほとんど時を移さず，トピックマップの考え方をウェブへ適用可能にすることを開発するために，及び情報の発見可能性及び管理可能性を改良する目的でその考え方のもつ非常に大きな可能性を実現するために，TopicMaps.Orgが設立された。
XTMの設計目標は，次のとおりとする。
| a) | XTMは，インターネット上で容易に利用可能でなければならない。 | |
| b) | XTMは，多種多様な応用を支援しなければならない。 | |
| c) | XTMは，XML，XLink及びISO/IEC 13250と互換性がなければならない。 | |
| d) | XTM文書を処理するプログラムを容易に書けなければならない。 | |
| e) | XTMにおける任意選択の機能は，絶対的に最小，理想的には存在しないように保たれることが望ましい。 | |
| f) | XTM文書は，人が読むことができて，適切な水準で明確であることが望ましい。 | |
| g) | XTMによる(文書の)設計は，迅速に準備されることが望ましい。 | |
| h) | XTMの設計は，形式的及び簡潔でなければならない。 | |
| i) | XTM文書は，作成が容易でなければならない。 | |
| j) | XTMマーク付けの簡明さは，それ程には重要とはしない。 |
この規定は，マーク付け構文のためのXML 1.0 [XML]，リンク付け構文のためのXLink 1.0 [XLink]，基底URI解決のためのXML Base [XML Base]，及びIETFのURI規定 [RFC 2396]([RFC 2732]によって改訂されている。)と一緒になって，XTM 1.0を理解し，適合トピックマップ文書を作成するために必要なすべての情報を提供する。
XTM規定のこの版及びその関連する規定は，すべてのテキスト及び法的告知が完全に残っている限り，自由に配布してよい。
XTM文書を記述するために使用する用語は，この規定の本体及びその附属書の中で定義される。1.3で定義される用語は，それらの定義を構築するために使用する。
その識別性が計算可能な情報資源。ここで，識別性が計算可能とは，コンピュータシステムが，その資源を検索可能であって，その資源と他の資源との間で，それらが同一か異なっているかを確定するために，決定論的な比較が可能なこととする。この規定文書のオンライン版は，番地付け可能な情報資源の例である。この規定では，資源という用語は，特に記述のない限り，番地付け可能な情報資源と同義に使用される。
文書作成者がそれによって意味したことに基づくのではなく，それ自体で主題として考えられる番地付け可能な情報資源。番地付け可能な主題の識別性は，定義によって，直接的に計算可能とする。番地付け不可能な主題(non-addressable subject)を参照すること。
| a) | <association>要素によって表明されたトピック間の関係。 |
| b) | <association>要素。 |
| a) | 関連のクラスの一つ。 |
| b) | <association>要素の<instanceOf>子要素によって指定された関連のクラス。関連は，ただ一つのクラスだけに属してもよい。 |
| c) | 主題が関連のクラスであるトピック。 |
| a) | <topic>要素の子要素(<baseName>)。 |
| b) | <baseNameString>要素の内容によって提供されるトピックの名前特質。基底名は，与えられた有効範囲の中で一意でなければならない(トピック名前付け制約(topic naming constraint)参照)。 |
異形名(variant name)も参照すること。
トピック特質(topic characteristic)を参照すること。
附属書F XTM処理要件に定義されているとおりに，主題ごとに一つのトピックが存在し，更なる併合又は重複抑制の機会がないトピックマップ。
| a) | <association>要素の子要素(<member>)。 |
| b) | 関連において特定の役割を演じるトピックの集合。 |
| a) | 明示的な<mergeMap>指令の結果として，又は応用特有の理由のために，二つのトピックマップを併合する処理。 |
| b) | 二つのトピックを併合する処理。 |
併合のすべての形式を支配する規則は，附属書F XTM処理要件に与えられる。
コンピュータシステムの境界の外に存在し，そのために，その識別性が計算可能ではない主題。番地付け不可能な主題の例としては，William Shakespeare，演劇Hamlet及びその1604-05年版，登場人物Hamlet，復讐の概念，Shakespeare & Companyという組織などがある。番地付け不可能な主題の識別性は，間接的にだけ，例えば主題指示子の使用を通してだけ，確定できる。
| a) | <topic>要素の子要素(<occurrence>)。 |
| b) | トピック出現のこと。[トピック出現(topic occurrence)を参照]。 |
| a) | トピック出現のクラスの一つ。 |
| b) | <occurrence>要素の<instanceOf>子要素によって指定されるトピック出現のクラス。出現は，ただ一つのクラスにだけ属することができる。 |
| c) | 主題がトピック出現のクラスであるトピック。 |
| a) | <variant>要素の子要素(<parameters>)。 |
| b) | トピックの集合の形式による，異形名のための適切な処理文脈を表現する情報。 |
附属書F XTM処理要件において定義されるとおりにXTM処理応用によって処理済みトピック，関連及び有効範囲の集まり。
附属書F XTM処理要件において定義されるとおりに適合XTMプロセサによって実行される処理に関する要件。
トピックマップの交換及び併合可能性を促進するために，公表された番地上で，公開され，維持管理される主題指示子。
トピックを生成する行為。何かが具体化されるとき，その何かは，このように生成されるトピックの主題になる。そのために，何かを具体化するとは，その何かが主題となるトピックを生成することになる。主題の具体化は，それを具体化するトピックにトピック特質が割り当てられることを許す。言い換えれば，具体化は，トピックマップの考え方による用語の範囲で，その主題について論じることを可能にする。
トピックが関連のメンバとして演じる役割。すなわち，その関連の中にトピックが関わる性質。
| a) | トピック特質割当てが有効となる範囲。その中で，名前又は出現が，与えられたトピックに割り当てられる文脈であって，複数のトピックが，関連を通して関係付けられる文脈。 |
| b) | <scope>要素を通じて指定されるトピックの集合。 |
制約のない有効範囲(unconstrained scope)も参照すること。
この規定は，応用が有効範囲をどのように解釈するかについては制約を置かない。
| a) | 人間が語ったり心に抱いたりできるあらゆるもの。最も一般的な意味において，主題とは，存在しているかどうか，又は他の特定の特質をもっているかどうかにかかわらず，それについていかなる手段で表明してもよいあらゆるもののこととする。 |
| b) | トピックマップの作成者が論じるために選ぶあらゆるもの。 |
| c) | トピックマップにおけるトピックによって具体化されるあらゆるもの。トピックの組織化の原理にもなる。人間は，トピックの主題を決めるための究極的な権威者とする。 |
| a) | <topic>要素の<subjectIdentity>子要素。 |
| b) | 二つの主題を同一とする，又は一つの主題をもう一方の主題と区別するもの。主題識別性の決定は，公開主題指示子の使用によって支援され，自動化されてもよい。 |
| c) | 附属書F XTM処理要件において定義されるとおりにトピックを併合するための基準。 |
トピックマップの作成者が，主題の識別性の，明白であいまいでない指示の提供を意図した資源。トピックマップには，主題を指示する次の三つの方法が存在する。
a) 同じ主題を共有する<topic>要素への<topicRef>要素を通じての指示。 b) 主題を指示する資源への<subjectIndicatorRef>要素を通じての指示。 c) 主題である資源への<resourceRef>要素を通じての指示。
主題指示子によって指示された主題は，番地付け不可能でも番地付け可能でもよい。c)の場合には，主題は資源なので，必然的に番地付け可能となることに注意すること。
| a) | ある主題に対してプロキシとして振る舞う資源。すなわち，その主題のトピックマップシステムにおける表現。トピックとその主題との間の関係は，具体化の一つとして定義される。主題の具体化は，その主題を具体化するトピックにトピック特質が割り当てられることを可能にする。 |
| b) | <topic>要素。 |
次の一つ。
a) トピック名。 b) トピック出現。 c) 関連においてトピックが演じる役割。
トピックの名前，出現，及び関連の中で演じる役割は，トピックの特質として集合的に知られている。
トピック名(topic name)，トピック出現(topic occurrence)及び役割(role)も参照すること。
与えられたトピックが特定の特質をもっていることを表明する行為。それら表明は，ある有効範囲内で有効とする。
| a) | 次の二つの形式のうちの一つとして存在してよい，トピック，関連及び有効範囲の集まり。
|
||||
| b) | XTM構文を使用して表現されたトピックマップ文書の文書要素(<topicMap>)。 |
この規定に適合する一つ以上のトピックマップを含む文書。記憶又は交換のために，この規定又は他の規定によって規定される構文で，直列化してもよい。
| a) | トピックの基底名特質。ただし，これには，基底名の異形(名)も含む。 |
| b) | (非形式的定義) <baseNameString>要素を使用して，トピックの名前として指定された文字列。 |
同じ有効範囲内で同じ基底名をもつトピックは，暗黙的に同じ主題を参照し，そのために，併合されることが望ましい，という，トピックマップの考え方によって課された制約。
与えられた主題に対し関係するとして指定されている情報を含む資源。XTMトピックマップにおいて表現されるためには，それら資源は，次のいずれかでなければならない。
a) <resourceRef>要素を使用しURIを通じて番地付け可能。 b) <resourceData>要素として行内に置かれることが可能。
| a) | トピックのクラスの一つ。 |
| b) | <topic>要素の<instanceOf>子要素によって指定されたトピックのクラス。一つのトピックは，二つ以上のクラスに属してもよい。 |
| c) | トピックのクラスを主題にもつトピック。 |
異形名(variant name)を参照すること。
整列(sort)又は表示といった特定のコンピュータ処理目的のために最適化された基底名の代替形式。
この規定が定義する構文で表現されるトピックマップ文書。
2.では，XMLトピックマップ(XTM)の構成要素を理解するために必要な概念を示す。
トピックマップの目的は，資源の上に重ね合わせた層(これをマップという。)を通じて，資源に関する知識を伝達することにある。トピックマップは，実装とは独立した方法で，資源が語る主題及び主題間の関連を捉える。
トピックマップにおける重要な概念は，トピック，関連及び出現とする。
トピックとは，実世界の主題に立脚した(又は主題を“具体化”した)コンピュータ内の資源とする。それら主題の例として，演劇Hamlet，劇作家William Shakespeare，又はそれらの“作品及び作者”の関係がある。
トピックは，名前をもつことができる。トピックは，出現，すなわち，トピックの主題に何らかの方法で関係すると考えられる情報資源，をもつこともできる。さらに，トピックは，関連と呼ばれる関係に参加することができる。その関連の中で，トピックは，メンバとして役割を演じる。
このように，トピックは，3種類の特質，すなわち，名前，出現，及び関連のメンバとして演じられる役割，をもつ。それら特質の割当ては，ある有効範囲，つまり文脈，の内で有効と考えられる。
トピックマップは，併合することができる。併合は，利用者又は応用の自由裁量によって(実行時に)行うことが可能だが，作成時にトピックマップの作成者が指示してもよい。
2.1では，百科事典出版の分野から採用した簡単な例を使用して，やさしい導入を与える。トピックマップの概念のより詳細な概要を，その後に示す。トピックマップで宣言されるXML要素型の一覧については，3.1 XTM構文への導入を参照すること。
この規定で定義されるトピックマップ記法の使用を具体的にする方法として，次の例を検討する。電子化された百科事典への主題インデクスに含まれているかもしれない文書の主題についての情報の種類を，装置及び実装に依存しない形式で記録することを望んでいると仮定してみよう。
いろいろな主題，例えば，他の数千の主題の中の，William Shakespeare，Ben Jonson，彼らの演劇Hamlet及びVolpone，並びにLondon及びStratfordの市街，に対して，百科事典の中における(それらの)位置のすべてを，すなわち，テキストの一節，画像，又はマルチメディア百科事典に記録されている音に関わらず，それらが議論され，描写され，又は言及されている場所のすべてを，記録したいと望むとする。我々は，これらの位置を，これらの主題の出現と表現することとする。異なる出現は，我々が区別したいその異なった方法で，主題と関係していてもよいことに注意すること。詳細な議論，簡単な言及，及び解説は，利用者が必要なことを最も早く見つけられるように，必要ならば区別してもよい。
我々が作業をしている百科事典は，電子化されて存在している。そのために，主題のすべての出現は，番地を計算できる電子化された資源になっている。番地の性質についての詳細はふれないが，番地を，適当なプロセサに資源の位置決めを可能とする，通常は短い表現として定義する。このように，主題の出現は，番地付け可能な情報資源となる。
それに反して，劇作家であるWilliam Shakespeare及びBen Jonsonは，番地付け不可能な資源になる。すなわち，彼らは，電子的な人工物ではなく，実際の人間である。主題の出現と主題それ自体との間のリンクを表現するために，単に各々を順に指し示し，“この位置は，この主題を論じる。”，ということにしたい。マーク付けを使って，主題の番地，出現の番地，及びそれらの関係を与えることによって，ある電子的な記法で等価な意志表示を行うことにしてもよい。
しかし，すべての主題が電子的な人工物ではないので，それら主題に対しては，番地を提供できない。その代わりに，(電子化されており，)番地をもつことができる，主題に対する電子的代理を提供する。この代理をトピックと呼ぶ。すべてのトピックは，ある主題の代理として振る舞う。これを，トピックが主題を“具体化する”，という。システムのために主題を“実在化”するといってもよい。主題を具体化するトピックを生成することで，システムは，そのトピックに対して，操作，処理及び特質割当てをすることによって，主題に対して，操作，処理及び特質割当てを行うことが可能になる。主題の番地が必要な場合には，それを具体化し，システム内でその代理として振る舞うトピックに番地を与える。
混乱を招かない場合には，トピック及び主題という用語を相互に入れ替えて使用することがある。各トピックはある主題を具体化しており，各主題に対してそれを具体化するトピックを構成できるという理由のために，その差異は，常に重要というわけではない。
主題インデクスの情報の集まり全体は，様々なトピックが言及され議論される場所を示すという点で，百科事典のある種の地図(マップ)を提供するので，主題インデクスの電子的表現をトピックマップと呼ぶ。
William Shakespeare劇の幾つかを表現するトピックは，例えば次のとおりになる。
<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>
備考
簡潔に示すために，この規定におけるURIの例は，断片的な識別子(素片識別子)だけを含むことがある。例えば，この例では，#playがそれに当たる。それらの場合，これらの識別子は，同じトピックマップの中の，その素片識別子に一致する“id”属性値をもつ<topic>要素を参照すると仮定する。
シソーラス及び主題インデクスにおいて，主題間の関係を示すことが有用となることが多い。例えば，Hamlet及びThe Tempestは，両方とも演劇の例であり，Shakespeareは，それらの著者であって，Rosencrantz及びGuildensternは，演劇Hamletの登場人物となる，などである。従来の参照作業では，これらの種類の関係は，相互参照の作成において編集者を導くために使用される。これらの関係は，主題の出現間の関係ではなく，主題間の関係を保持しているという点に注意すること。それらの電子的な表現は，出現とは完全に独立していることが可能であって，非常に異なった資源の集まりに適用させることができる。もちろん，主題間の関係の電子的な表現は，それらの主題を具体化するトピックの間の関係，すなわち，関連，の形式を取る。
Shakespeareと演劇Hamletとの間の関係を表現する関連は，例えば，次のとおりになる。
<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>
関連は，本来的に複数の方向の関係を表すので，“Hamletは，Shakespeareによって書かれた。”ならば，自動的に，“Shakespeareは，Hamletを書いた。”ことになる。それらは，わずかに異なった方法で表現された，一つの同じ関係になっている。方向性の代わりに，関連は，その関連にメンバが関与する様々な形式を区別するために，役割を使用する。このようにして，この例は，自然言語を使用して次のように直列化してよい。“('著者'の役割を演じる)Shakespeareと('作品'の役割を演じる)Hamletとの間には，'によって書かれた'の関係が存在する。”関係は，一つ以上の役割を含んでもよい。
この方法で記録できる主題間の関係の種類には，本質的な制限はない。ある目的のためには，〜に住む 及び 〜の例 で十分となり，他の目的のためには，主題間の全く異なる関係が関心事となる。
トピック及びトピックの関係は，情報資源の与えられた集合において，それらの出現と独立に記述できるので，トピックの与えられた集合は，異なる応用において，情報資源の多くの異なる集合と結び付けられてもよいと期待できる。逆に，情報資源の一つの集合は，多くの異なるトピックマップによって記述されてもよい。異なるトピックマップが，同じ主題に対してトピックを定義してもよい。実際には，同じ主題を示すトピックを併合できることが重要になる。
抽象的なレベルでは，百科事典は，番地付け可能な情報資源の集合から構成され，その情報資源の各々は，より大きなある番地付け可能な情報資源の内側に位置決めされ，各々が一つ以上の主題と関係している，と言うことができる。主題インデクスは，次の三つのものから構成される。
a) トピックの集合。ここで，各トピックは，ある主題に対する電子的な代理として利用でき(すなわち，主題を具体化しており)，一つ以上の名前をもってもよい。 b) トピックから，それらのトピックが具体化する主題の出現と考えられる情報資源へのリンク。リンクの例としては，〜で議論される，〜で言及される，〜で描写される，などがある。 c) トピック間の関連。関連の例には，〜の例，〜を書いた，〜によって書かれた，〜に住んでいる，などがある。
トピックマップという用語を，それらのものの集まりを示すために使用する。既に定義したとおり，主題は，人間が考えたり，議論したり，電子的な形式で表現したりしたいものを含むので，二つの主題が同じかどうか，又は二つのトピックが同じ主題を具体化しているかどうかを決定するための機械的な試験は存在しない点に注意すること。したがって，主題それ自体は，この規定で与えられる形式的記述の中に現れない。トピックとそれの出現との間，又はトピックと他のトピックとの間，の関係の性質を制約しようとはしない。この理由のために，この規定で定義される定式化は，歴史的には，多くのメディアでの異なる素材の本体に関する主題探しの問題における関心から発達しているのだが，百科事典の主題インデクス作成の問題とは全く異なった(又は異なって見える)多くの問題に適用してもよい。用語定義は，明確性及び具体性のために，各用語の歴史的経緯を反映している。
いかなる種類の電子的な資源も注意の対象になるので，それらもトピックとして取り扱ってもよいことに注意すること。例えば，William Shakespeareを描いた絵は，William Shakespeareを表現するトピックの出現ではあるが，それは，芸術の歴史において，図形フォーマットの議論において，デジタル資源の目録の中で，又はトピックマップの中で，絵として言及されるかもしれない。
2.2は，すべてのトピックマップの概念の完全な概観を提供する。主として，1.3 定義に基づいているが，アルファベット順というよりも論理的な順で示し，追加の説明を含んでいる。
トピックは，ある主題のプロキシ(代理)として振る舞う資源とする。それは，主題のトピックマップシステムの表現とする。トピックとその主題との間の関係は，具体化の一つとして定義される。主題の具体化によって，その主題を具体化するトピックにトピック特質を割り当てることが可能となる。
個々のトピックは，明示的に示されてもよいし明示的には示されなくともよいが，トピックの一つ以上のクラスのインスタンスとなる。このクラスは，トピック型としても知られる。デフォルトのトピック型は，“topic”という公開された主題によって定義される。
主題は，人間が話したり心に描いたりするあらゆるもの，とする。最も一般的な意味において，主題とは，存在しているかどうか，又は他の特定の特質をもっているかどうかにかかわらず，それについて何らかの手段で表明できるあらゆるもののこととする。特に，トピックマップの作成者が，それについて論じることを選んだあらゆるものとする。
トピックマップの考え方の中で主題を論じるためには，主題は，トピックの生成を通して具体化されなければならない。主題は，このようにして，トピックの組織化の原理となる。
無矛盾トピックマップにおいて，各主題は，ただ一つのトピックによって表現される。一方，トピックマップ文書においては，複数のトピックが同じ主題を具体化してもよい。ただし，その場合には，それら複数のトピックは，処理中に一つのトピックに併合できることが望ましい。
大部分の主題は，コンピュータシステムの境界の外側に存在する。それらの主題は，直接的に番地付け可能ではなく，そのために，それらの識別性は，計算可能ではない。それら番地付け不可能な主題の例としては，William Shakespeare，演劇Hamlet及びその1604-05年版，登場人物Hamlet，復讐の概念，Shakespeare & Companyという組織，このXTM規定などがある。番地付け不可能な主題の識別性は，間接的に，主題指示子として機能する資源を通じてだけ確立できる。
しかし，あらゆるものが，トピックマップにおいて議論の主題になることができる。これには，直接的に番地付け可能なコンピュータ内部の資源が含まれる。主題として考えられる資源を，番地付け可能な主題と呼ぶ。番地付け可能な主題の例としては，HTML文書としてのこの規定がある。
トピックを生成する行為を具体化と呼ぶ。あるものが具体化される場合，それは，生成されるトピックの主題になる。そのために，あるものを具体化するということは，そのあるものを主題とするトピックを生成することになる。主題の具体化によって，それを具体化するトピックにトピック特質を割り当てることができる。言いかえれば，具体化は，トピックマップの考え方の用語を使って，その主題について論じることを可能にする。
具体化の概念は，トピックマップの考え方のまさに中心的なものとする。トピックマップにおいて，あるものを語ることを可能にするただ一つの手段は，トピックを生成し，それに特質を割り当てることとする。トピックは，システムにとって主題を“実在化”するものであって，人間にとっての“実在”するものの表現に，機械が可能な限り近づけたものである。
いかなるものも何であれ主題となることができるので，具体化は，関連，名前及び出現といったトピックマップそれ自体内のオブジェクトに対しても適用できる。構文的にこれがどのように行われるかの例については，3. XTM構文の文書化における<association>及び<occurrence>を参照すること。このことによって，トピックマップの考え方の威力をトピックマップ自体に適用でき，表明についての表明を行うことを含んだ，一つの同じマップ内での複数レベルの知識表現を可能にする。
主題識別性は，それによって，どの主題が特定のトピックによって具体化されているかを確立できる手段とする。二つのトピックが同じ主題識別性をもつ場合，それらは，“ほぼ”同じものと考えられ，そのために，それらは併合されなければならない。トピックマップを併合可能にする必要性のために，実際的には，セマンティクスを交換できる必要性のために，トピックマップの考え方は，トピックの識別性(及びその結果として主題の識別性)を可能な限り頑健に確立できるために，多くの努力を払っている。
主題識別性は，次の二つの方法の一つで確立できる。
a) 直接に主題を番地付けすることによって。これは，主題が番地付け可能な情報資源の場合だけ可能になる。 b) 主題指示子(2.2.1.4を参照)を通じて，主題を指示することによって。
主題指示子は，トピックマップの作成者が，主題の識別性の明白であいまい性のない指示を提供することを意図した資源とする。二つのトピックがそれらの主題を指示するために同じ資源を使用する場合，それらは，定義によって，“ほぼ”同じものであって，そのために，処理中に併合されなければならない。
主題識別性は，トピックマップの併合及びセマンティクスの交換のための基礎を形成するので，トピックマップの作成者は，可能な限り頑健な方法で，特に，公開主題指示子として表現された標準化されたオントロジの使用を通して，トピックの主題識別性を指示することが望ましい。
一つの同じ主題は，多くの方法で指示されてもよいので，同じ主題を具体化する二つのトピックが，異なる主題指示子を使用し，そのために併合されないことが可能になる。このような状況は，両方の主題指示子を通してその識別性を確立する(同じ又は他のトピックマップ文書における)第3のトピックを使うことで回避してもよい。このようにして，トピックマップを，オントロジ間での仲介のために使用してもよい。
トピックマップの考え方において，トピックについて表明してよいあらゆるものは，そのトピックの特質として知られる。特質は，次の一つとすることができる。
それら特質の割当ては，ある有効範囲，すなわち文脈，の内で有効と考えられる。
有効範囲は，トピック特質割当ての有効性の範囲を指定する。有効範囲は，与えられたトピックに名前又は出現が割り当てられる文脈，及びトピックが関連を通して関係付けられる文脈，を確立する。すべての特質は，有効範囲をもつ。この場合，有効範囲は，トピックの集合として明示的に，又は制約なしの有効範囲として知られる場合には暗示的に，指定されてよい。制約なしの有効範囲で行われた割当ては，常に有効とする。
有効範囲は，トピックの基底名のための名前空間を確立すると考える。これによって，トピックマップの考え方によって課せられた，トピック名前付け制約と呼ぶ制約が導かれる。この制約は，同じ有効範囲内の同じ基底名をもつトピックは，暗黙的に同じ主題を参照し，そのために併合されることが望ましい，とする制約とする。この制約を除いて，特質の有効範囲の解釈及び処理に関するその効果は，応用に任されており，この規定によっては制約されない。
トピックは，0個以上の名前をもってよく，その各々は，ある有効範囲内で有効と考えられる。この場合，有効範囲は，制約なしの有効範囲であってもよい。
各々の名前は，複数の形式で存在してもよい。名前は，常に，基底名として知られる，ただ一つの基本の形式をもつが，それに加えて，特定の処理文脈における使用のために，一つ以上の異形をもってもよい。
基底名は，トピック名の基本形式とする。それは，常に文字列とする。応用がトピックをラベル付けするために特定のトピック名の使用を選択する場合，処理の文脈においてより適切と思われる異形が存在しないときには，基底名が，応用の使用する文字列を提供する。
基底名は，処理済みトピックマップが，同じ有効範囲の中に同じ基底名をもつ複数のトピックを含むことを禁じる，トピック名前付け制約に従う。
出現は，与えられた主題に関係するとして指定されたあらゆる情報とする。出現は，トピックに割当てが可能であってそのために有効範囲によって支配される，3種類の特質の一つを構成する。個々の出現は，明示的に指示されてもされなくてもよい(出現型としても知られる)出現の一つのクラスのインスタンスとする。省略時の出現型は，“occurrence”という公開された主題によって定義される。
XTMトピックマップで表現されるためには，出現は次のどちらかの資源でなければならない。
a) URIを使用した参照によって番地付け可能な資源(“資源参照”)。 b) 文字データとして行内に置くことが可能な資源(“資源データ”)。
b)の資源データは，例えば作曲日などの，主題についての情報の短い断片を表現する有用な方法を提供する。
関連は，一つ以上のトピック間の関係であって，各々のトピックが，その関連のメンバとして役割を演じるものとする。関連においてトピックが演じる役割は，トピックに割り当てられた特質の一つであって，そのために，有効範囲によって支配される。個々の関連は，明示的に指示されてもされなくてもよい(関連型としても知られている)関連の一つのクラスのインスタンスとする。省略時の関連型は，“association”という公開された主題によって定義される。
関連においては，固有の方向性はない。関連は，(相互の)関係を記述する。すなわち，A がB に関係している場合には，B もA に関係していなければならない。問題となるのは，むしろ，関係の型は何か，及びそのメンバによって演じられる役割は何か，である。関係をラベル付けする方法は，名前付けの一つであって，方向付けに関するものではない。
役割の概念は，関連のメンバとしてトピックが(関連に)関係する性質を表現する。
クラスとインスタンスとの関係は，それぞれに，クラス及びインスタンスの役割を演じるトピック間のクラスとインスタンスとの関係を表現する関連のクラスとする。主題である，“class-instance”，“class”及び“instance”は，この規定で公開される公開主題指示子(PSI)によって，すべて定義される。
上位クラスと下位クラスとの関係は，それぞれに，上位クラス及び下位クラスの役割を演じるトピック間の上位クラスと下位クラスとの関係を表現する関連のクラスとする。主題である，“superclass-subclass”，“superclass”及び“subclass”は，この規定において公開されるPSIによって，すべて定義される。
トピックマップは，トピック，関連及び有効範囲(これらを集合的にトピックマップノードと呼ぶ。)の集合であって，次の二つの形式の一つとして存在してよい。
a) 直列化された交換形式。例えば，XTM又は他の構文で表現されたトピックマップ文書としての形式になる。 b) 附属書Fに定義されたXTM処理要件が制約するとおりの，応用の内部形式。
トピックマップの目的は，資源の上に重ね合わせた層，すなわちマップ，を通して，資源についての知識を伝達することにある。トピックマップは，実装とは独立した方法で，資源が語る主題及び主題間の関連を捉える。
トピックマップノードは，トピックマップのシステム内部表現におけるオブジェクトであって，トピック，関連及び有効範囲を表現する。
無矛盾トピックマップは，附属書F XTM処理要件に定義されるとおりに，一つの主題に一つのトピックが存在し，更なる併合又は重複抑制の機会がないトピックマップとする。
トピックマップ文書は，この規定に適合する一つ以上のトピックマップを含む文書とする。記憶又は交換の目的のために，この規定又は他の規定が支配する構文で，直列化されてもよい。
XTM文書は，この規定が定義する構文で表現されるトピックマップ文書とする。
公開された主題は，主題指示子が公開使用のために利用可能にされた主題であって，URIを通じてオンラインでアクセス可能とする。そのために，公開主題指示子は，トピックマップの交換及び併合可能性を促進するために，主題の識別性の明白であいまい性のない指示を提供する公開された資源とする。
幾つかの主題は，必須で，本質的であって，そのために，この規定で公開される。この規定が課す多様な制約は，トピック，関連及び出現の省略時クラス，並びに<instanceOf>の使用と制約なしの有効範囲の中での型class-instanceの関連との等価性を含んだ，これらの公開された主題によって表現される。
XTMで必須の主題のためにこの規定が提供する公開主題指示子を，次に簡潔に示す。この簡潔な記述は，附属書E XTM 1.0コアの公開主題指示子で示すトピックマップ(core.xtm)の中に含まれる<topic>要素によって，主題指示子として参照される。
参考 次に示す公開主題指示子は，附属書Eのcore.xtmへの参照を容易にするために英語を，その意味を明確にするために日本語訳を，それぞれ併記して示す。
トピックのコア概念。他に指定されない限り，すべてのトピックが属する一般的なクラス。
core.xtm#topic
関連のコア概念。他に指定されない限り，すべての関連が属する一般的なクラス。
core.xtm#association
出現のコア概念。他に指定されない限り，すべての出現が属する一般的なクラス。
core.xtm#occurrence
クラスとインスタンスとの関係のコア概念。トピック間のクラスとインスタンスとの関係を表現する関連のクラスであって，<instanceOf>下位要素を使用することと意味的には等価になる。
core.xtm#class-instance
クラスのコア概念。クラスとインスタンスとの関連のメンバの一つが演じるとおりのクラスの役割。
core.xtm#class
インスタンスのコア概念。クラスとインスタンスとの関連のメンバの一つが演じるとおりのインスタンスの役割。
core.xtm#instance
上位クラスと下位クラスとの関係のコア概念。トピック間の上位クラスと下位クラスとの関係を表現する関連のクラス。
core.xtm#superclass-subclass
上位クラスのコア概念。上位クラスと下位クラスとの関連のメンバの一つが演じるとおりの上位クラスの役割。
core.xtm#superclass
下位クラスのコア概念。上位クラスと下位クラスとの関連のメンバの一つが演じるとおりの下位クラスの役割。
core.xtm#subclass
整列キーとしての使用のためのトピック名の適性。異形名のパラメタの中での使用のため。
core.xtm#sort
表示のためのトピック名の適性。異形名のパラメタの中での使用のため。
core.xtm#display
併合という用語は，次の二つの異なる処理を含む。
a) 明示的な<mergeMap>命令の結果として，又は何らかの応用固有の理由による，二つのトピックマップの併合処理。 b) 二つのトピックの併合処理。
併合のすべての形式を支配する規則，及び主題識別性の決定は，附属書F XTM処理要件で完全に与えられる。それらは，(完全ではないが)簡単には，次のとおりに述べることができる。
a) 二つのトピックマップが併合される場合，いかなる方法にしても，応用が同じ主題をもつと断定したトピックは併合され，重複する関連は削除される。 b) 二つのトピックが併合される場合，その結果は，重複の削除とともに，元のトピックの特質の合併になる特質をもつ一つのトピックとなる。
次の場合，二つのトピックは，常に，同じ主題をもつとみなす。
a) 二つのトピックが，一つ以上の共通の主題指示子をもつ場合。 b) 二つのトピックが，同じ番地付け可能な主題を具体化している場合。 c) 二つのトピックが，同じ有効範囲の中に同じ基底名をもつ場合。
この規定に適合するトピックマップ文書を直列化し交換するための構文は，附属書D XTM 1.0文書型宣言で提供されるXML文書型定義によって定義される。3.では，そのDTDの中で定義されるすべての要素型に対してそれらを文書化したものを提供する。
次に，XTM要素型の文書化されている順番での完全な一覧を示す。