この標準情報(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要素型の文書化されている順番での完全な一覧を示す。
<topicRef>要素は，トピックへのURI参照を提供する。<topicRef>リンクのターゲットは，このXTM規定に適合する<topicMap>文書の子の<topic>要素に解決されなければならない。ターゲットの<topic>は，元の文書実体の中にある必要はない。
<topicRef>は，<topic>要素を指し示さなければならないという付加的な制約を除いて，<subjectIndicatorRef>と同一とする。
出現場所： <instanceOf>, <member>, <mergeMap>, <parameters>, <roleSpec>, <scope>, 又は<subjectIdentity>
<!ELEMENT topicRef EMPTY >
<topicRef>要素は，内容をもたない。
<!ATTLIST topicRef
id ID #IMPLIED
xlink:type NMTOKEN #FIXED 'simple'
xlink:href CDATA #REQUIRED
>
<topicRef>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|---|
| xlink:type | このリンクをXLinkの単純リンク型と識別する。 |
| xlink:href | このリンクに対するURI参照を供給する。 |
備考 適合性及び利用法のために，[XLink]の5.2及び5.4も参照すること。
language.xtm文書の中のID “en”をもつトピックへの参照。これは，英語用の実際に公開された主題である。
<topicRef xlink:href="language.xtm#en"/>
現在の文書の中に物理的に位置決めされているID “play”をもつトピックへの参照。
<topicRef xlink:href="#play"/>
更なる例としては，<scope>，<instanceOf>，<variant>，<association>，及び<mergeMap>を参照すること。
<subjectIndicatorRef>要素は，主題指示子として振る舞う資源へのURI参照を提供する。
出現場所： <instanceOf>，<member>，<mergeMap>，<parameters>，<roleSpec>，<scope>，又は<subjectIdentity>
<!ELEMENT subjectIndicatorRef EMPTY >
<subjectIndicatorRef>要素は，内容をもたない。
<!ATTLIST subjectIndicatorRef
id ID #IMPLIED
xlink:type NMTOKEN #FIXED 'simple'
xlink:href CDATA #REQUIRED
>
<subjectIndicatorRef>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|---|
| xlink:type | このリンクをXLinkの単純リンク型として識別する。 |
| xlink:href | このリンクに対するURI参照を供給する。 |
備考 適合性及び利用法のために，[XLink]の5.2及び5.4も参照すること。
公開主題指示子への参照。
<subjectIndicatorRef xlink:href="language.xtm#en"/>
それほど形式的でなく主題を指示する(架空の)資源への参照。
<subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays.html#hamlet"/>
更なる例としては，<scope>，<instanceOf>，及び<subjectIdentity>を参照すること。
トピックマップの構成要素を具体化するために，どのように<subjectIndicatorRef>を使用するかという例は，<association>及び<occurrence>を参照すること。
<scope>要素は，一つ以上の<topicRef>要素，<resourceRef>要素又は<subjectIndicatorRef>要素から構成される。これらの要素に対応する主題の合併が，トピック特質の割当てが有効と考えられる文脈を指定する。
トピック特質の宣言は，有効範囲内だけで有効とする。トピック特質宣言が有効範囲を指定しない場合は，制約なしの有効範囲内で有効とする。
出現場所： <baseName>，<occurrence>，又は<association>
<!ELEMENT scope ( topicRef | resourceRef | subjectIndicatorRef )+ >
<!ATTLIST scope
id ID #IMPLIED
>
<scope>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
公開された主題を使用して，主題“英語”から成る有効範囲を定義する。
<scope>
<subjectIndicatorRef
xlink:href="language.xtm#en"/>
</scope>
現在の文書の中の，“悲劇(tragedy)”及び“劇場(theatre)”から成る有効範囲を定義する。
<scope>
<topicRef xlink:href="#tragedy"/>
<topicRef xlink:href="#theatre"/>
</scope>
更なる例としては，<baseName>を参照すること。
<instanceOf>要素は，<topicRef>子要素又は<subjectIndicatorRef>子要素を通じて，その親要素が属するクラスを指定する。
<instanceOf>の利用法の制約については，その親要素になることができる要素型，すなわち，<topic>，<occurrence>，及び<association>の記述を参照すること。
<instanceOf>要素は，class-instanceという公開された主題が定義する特殊な型の関連のための構文的な簡略形とする。
出現場所： <topic>, <occurrence>, 又は<association>
<!ELEMENT instanceOf ( topicRef | subjectIndicatorRef ) >
<!ATTLIST instanceOf
id ID #IMPLIED
>
<instanceOf>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
ID “hamlet”をもつトピックは，IDを“play”とするトピック型のインスタンスであることを宣言する。
<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>
更なる例としては，<topic>，<association>，及び <occurrence>を参照すること。
<topicMap>要素は，トピックマップ文書における，すべての<topic>要素，<association>要素，及び<mergeMap>要素の親とする。
<topicMap>要素は，トピックマップの構文的な認識が行われる出発点のルート要素とする。<topicMap>要素は，トピックマップだけを含む文書(すなわち，それが文書要素の場合)のルート，又はトピックマップそれ自体以外の他の情報を含むXML文書の内部の部分木のルートになることができる。後者の場合，要素<topicMap>から始まる部分木だけが，トピックマップの構文認識及び適合性に対して考慮される。
<!ELEMENT topicMap
( topic | association | mergeMap )*
>
<!ATTLIST topicMap
id ID #IMPLIED
xmlns CDATA #FIXED ''
xmlns:xlink CDATA #FIXED 'http://www.w3.org/1999/xlink'
xml:base CDATA #IMPLIED
>
<topicMap>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|---|
| xmlns | 省略時のXML名前空間のための名前空間識別子。 |
| xmlns:xlink | XLink名前空間のための名前空間識別子。 |
| xml:base | 文書基底URIへの参照。 |
備考
適合性及び利用法のために，[XLink]の5.2 及び5.4を参照すること。
xml:base属性の使用に関する詳細については，[XML Base]の3.を参照すること。
XML文書の中に埋め込まれた<topicMap>要素。
...
<topicMap>
<!-- topics, associations, and merge map directives go here -->
</topicMap>
...
完全な文書を構成する<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=''
xmlns:xlink='http://www.w3.org/1999/xlink'
xml:base='http://www.shakespeare.org/hamlet/'>
<!-- topics, associations, and merge map directives go here -->
</topicMap>
<topic>要素は，一つのトピックの名前特質及び出現特質を指定する。その要素は，一つの一意な識別子をもち，トピックがインスタンスとなるクラス，及びトピックが具体化する主題の識別性を示す能力をもつ。
定義によって，トピックは，ただ一つの主題を具体化する。すべてのトピックは，主題が暗黙的に定義されている場合であっても，正確に一つの主題のついて組織化されるように意図されている。XTMの処理中に，同等な主題をもつトピックは，附属書F XTM処理要件で指定される規則に従って併合される。
しかし，トピックマップ文書は，同じ主題を具体化する複数のトピック要素を含んでもよい。処理後，各主題に対して一つのトピックだけが存在するようになる。そのトピックの特質は，その主題を具体化するすべてのトピックの特質の合併になる。併合処理についての更なる議論については，2.4 併合を参照すること。
トピックがインスタンスとなるクラスは，トピック又は主題指示子を番地付けする<instanceOf>子要素を通じて指示される。<instanceOf>子要素が存在しない場合は，トピックのクラスは，topicという公開された主題によって定義されている省略時のクラスとする。
<topic>要素は，その主題に関係する0個以上の名前及び0個以上出現を指定する。名前は，<baseName>子要素によって宣言される。出現は，<occurrence>子要素によって指定される。
出現場所： <topicMap>
<!ELEMENT topic
( instanceOf*, subjectIdentity?, ( baseName | occurrence )* )
>
<!ATTLIST topic
id ID #REQUIRED
>
<topic>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
IDを“hamlet”とするトピックは，IDを“play”とするトピック型のインスタンスである。
<topic id="hamlet">
<instanceOf>
<topicRef xlink:href="#play"/>
</instanceOf>
<!-- base names and occurrences go here -->
</topic>
更なる例としては，<subjectIdentity>，<baseName>，<variant>，<association>，及び<occurrence>を参照すること。
<subjectIdentity>要素は，<resourceRef>子要素，<subjectIndicatorRef>子要素，及び/又は<topicRef>子要素を通じて，トピックによって具体化される主題を指定する。
トピックが番地付け可能な主題をもつ場合，主題は，<resourceRef>要素を通じて，直接に番地付け可能とする。その場合，トピックの主題と考えられるものは，資源が意味するもの又は指示するものではなく，資源それ自体になる。それら資源は，トピックごとに一つだけ存在できる。
資源は，それ自体がそれだけで主題となることとは対照的に，主題指示子になることもある。資源は，一つのトピックに対して二つ以上存在してもよい<subjectIndicatorRef>要素を通じて主題を指示するために使用される。
トピックは，<topicRef>要素を通じて，そのトピックを番地付けすることによって，他のトピックと同じ主題をもつことを指示してもよい。トピックの併合を発生させる複数のそれら要素が存在してもよい。
出現場所： <topic>
<!ELEMENT subjectIdentity
( resourceRef?, ( topicRef | subjectIndicatorRef )* )
>
<!ATTLIST subjectIdentity
id ID #IMPLIED
>
<subjectIdentity>要素は，次の属性をもつ。
| id | 要素に対して一意な識別子。 |
|---|
トピックマップ1。公開主題指示子(この例では，ISO 3166に基づいたTopicMaps.OrgのPSIによって定義されるとおりの，デンマーク国)を参照することによって識別性を確立する。
<topic id="dk">
<subjectIdentity>
<subjectIndicatorRef
xlink:href="country.xtm#dk"/>
</subjectIdentity>
</topic>
トピックマップ2。かなり非公式のオントロジ(この例では，CIA World Factbookのオンライン版)を参照することによって識別性を確立する。
<topic id="da">
<subjectIdentity>
<subjectIndicatorRef
xlink:href="http://www.cia.gov/cia/publications/factbook/geos/da.html"/>
</subjectIdentity>
</topic>
トピックマップ3。ISOオントロジ(トピックマップ1で使用したもの)とCIAオントロジ(トピックマップ2で使用したもの)との間の対応付けを表現し，正しい併合を発生させるトピックを宣言する。
<topic id="denmark">
<subjectIdentity>
<subjectIndicatorRef
xlink:href="country.xtm#dk"/>
<subjectIndicatorRef
xlink:href="http://www.cia.gov/cia/publications/factbook/geos/da.html"/>
</subjectIdentity>
</topic>
<baseName>要素は，トピック名を指定する。トピック名は，一つの文字列，すなわち，<baseName>の子である<baseNameString>の内容，によって表現される。トピックへの名前の割当てが有効な文脈は，<scope>子要素を使用して表現されてもよい。それが存在しない場合には，有効範囲は制約なしでって，名前は常に有効になる。トピックは，同じ及び/又は複数の有効範囲の中で，複数の基底名をもってもよい。
基底名の間の自然言語の区別は，子である<scope>要素によって指定されてもよい。それら有効範囲を定義するのに適した公開された主題は，自然言語のための公開された主題を提供するTopicMaps.Orgが維持管理しているトピックマップ，XTM Language Topics，において見つけることができる。附属書E XTM 1.0コアの公開主題指示子を参照すること。）
基底名は，同じ有効範囲の中の同じ基底名をもつ二つのトピックは，暗黙的に同じ主題を具体化しており，そのために併合されるのが望ましい，というトピック名前付け制約に従う。
整列，検索及び表示といった計算処理の目的のために最適化されたトピック名の代替形式は，<variant>要素によって指定される。
出現場所： <topic>
<!ELEMENT baseName ( scope?, baseNameString, variant* ) >
<!ATTLIST baseName
id ID #IMPLIED
>
<baseName>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
単純な例
<topic id="shakespeare">
<baseName>
<baseNameString>William Shakespeare</baseNameString>
</baseName>
</topic>
有効範囲によって区別された異なる言語で記述された複数の名前をもつトピック。ID “en”及びID “da”をもつトピックの存在を仮定する。このトピックは，主題“English”及び主題“Danish”をそれぞれを具体化している。
<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>
トピック名前付け制約による望ましくない併合を避けるために有効範囲の使用する。名前“Hamlet”の2回の使用が異なる方法で有効範囲指定されていなかった場合には，これら二つのトピックは併合されてしまうだろう。
<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>
一つの関連型に複数の名前を与える。これは，捉える視点からの役割に依存して，この型の関連が異なってラベル付けされてもよいとするために行う。この例のトピックは，(制約なしの有効範囲の中で)省略時の名前“written by”をもつ。しかし，“author”文脈において(例えば，ある応用において，“現在のトピック”とみなされるトピックが“author”の役割を演じる場合)，文字列“author of”は，より適切な基底名を提供すると考えられる。
<topic id="written-by">
<baseName>
<baseNameString>written by</baseNameString>
</baseName>
<baseName>
<scope><topicRef xlink:href="#author"/></scope>
<baseNameString>author of</baseNameString>
</baseName>
</topic>
<baseNameString>要素は，先祖である<topic>親要素の基底名を表現する文字列とする。
出現場所： <baseName>
<!ELEMENT baseNameString ( #PCDATA ) >
<baseNameString>要素は，#PCDATAを含む。すなわち，それは，文字データだけを含んでよい。
<!ATTLIST baseNameString
id ID #IMPLIED
>
<baseNameString>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
<baseName>要素を参照すること。
<variant>要素は，異形の<parameters>子要素が指定する処理文脈のために適切なトピックの基底名の代替形式とする。これら文脈には，整列化及び表示があってもよい。
再帰的な構造の中の各<variant>子要素は，基底名の一つの代替形式を提供する。この形式が適切と考えられる処理文脈は，再帰的構造のこのレベル及びより高位のレベルのすべてのパラメタの合併によって定義される。言い換えれば，パラメタは，木に沿って下向きに継承される。完全な記述については，附属書F XTM処理要件における“異形有効範囲処理”を参照すること。
パラメタが，“display”又は“sort”といった公開された主題(2.3.2 XTMで必須の公開主題指示子を参照)を含む異形名は，それぞれ，ISO 13250に定義されている表示名及び整列名と意味的に等価とする。
出現場所： <baseName>
<!ELEMENT variant ( parameters, variantName?, variant* ) >
<!ATTLIST variant
id ID #IMPLIED
>
<variant>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
整列化の目的で，基底名の代替形式を指定する。
<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="core.xtm#psi-sort"/>
</subjectIdentity>
</topic>
次の例は，可視表現及び可聴表現のための代替形式を含む，基底名“Hamlet”の異形を示す。“display”のための異形の部分木は，異形の入れ子を使用する方法，及びパラメタが構造に沿って“積み重ねられる”方法を説明している。
<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>
<variantName>要素は，基底名の異形として使用される資源を提供する。その資源は，<resourceRef>要素によって参照されてもよいし，<resourceData>要素として直接に含まれてもよい。
出現場所： <variant>
<!ELEMENT variantName ( resourceRef | resourceData ) >
<!ATTLIST variantName
id ID #IMPLIED
>
<variantName>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
<variant>要素を参照すること。
<parameters>要素は，一つ以上の<topicRef>要素又は<subjectIndicatorRef>要素から構成される。これらの要素に対応する主題の合併は，異形の部分木の中の異形名が適切と考えられる付加的な処理文脈を指定する。
出現場所： <variant>
<!ELEMENT parameters ( topicRef | subjectIndicatorRef )+ >
<!ATTLIST parameters
id ID #IMPLIED
>
<parameters>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
<variant>要素を参照すること。
<association>要素は，関連のメンバとしての役割を演じるトピック間の関係を表明する。
<association>が属するクラスは，<instanceOf>子要素によって指定される。その要素が存在しない場合には，関連のクラスは，省略時の値として，associationという公開された主題になる。
関連によってなされた表明が有効な文脈は，<scope>子要素を使用して表現してよい。それが存在しない場合には，有効範囲は制約なしであって，関連は常に有効とする。
出現場所： <topicMap>
<!ELEMENT association
( instanceOf?, scope?, member+ )
>
<!ATTLIST association
id ID #IMPLIED
>
<association>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
“author”[著者]の役割を演じるトピック“shakespeare”と“work”[作品]の役割を演じるトピック“hamlet”との間には，型“written-by”[によって書かれた]の関連が存在する。言い換えると，[作品] Hamletは，[著者] Shakespeare [によって書かれた] (又は [著者] Shakespeareは，[作品] Hamletを[書いた]），がいえる。
<association id="will-wrote-hamlet">
<instanceOf>
<topicRef xlink:href="#written-by"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#author"/>
</roleSpec>
<topicRef xlink:href="#shakespeare"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#work"/>
</roleSpec>
<topicRef xlink:href="#hamlet"/>
</member>
</association>
特質の割当てを可能にするために，この関連を具体化すると，次のとおりになる。
<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>
<instanceOf>要素の代わりに，関連を使用して，“hamlet”と“play”との間の，クラスとインスタンスとの間の関係を宣言する。これは，<instanceOf>の最初の例と意味的には等価になる。
<association>
<instanceOf>
<subjectIndicatorRef
xlink:href="core.xtm#class-instance"/>
</instanceOf>
<member>
<roleSpec>
<subjectIndicatorRef
xlink:href="core.xtm#class"/>
</roleSpec>
<topicRef xlink:href="#play"/>
</member>
<member>
<roleSpec>
<subjectIndicatorRef
xlink:href="core.xtm#instance"/>
</roleSpec>
<topicRef xlink:href="#hamlet"/>
</member>
</association>
<topic id="play">
...
</topic>
<topic id="hamlet">
...
</topic>
<member>要素は，関連において与えられた役割を演じるすべてのトピックを指定する。<roleSpec>要素は，これらのトピックが演じる役割を指定する。
出現場所： <association>
<!ELEMENT member
( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )+ )
>
<!ATTLIST member
id ID #IMPLIED
>
<member>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
<association>要素を参照すること。
<roleSpec>要素は，関連においてメンバが演じる役割を指定する。
出現場所： <member>
<!ELEMENT roleSpec ( topicRef | subjectIndicatorRef ) >
<!ATTLIST roleSpec
id ID #IMPLIED
>
<roleSpec>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
<association>要素を参照すること。
<occurrence>要素は，トピックに関係する情報を供給する資源を指定する。
出現がインスタンスとなるクラスは，<instanceOf>子要素を通じて指示される。そのような要素が存在しない場合，出現の型は，省略時の値として，occurrenceという公開された主題によって定義されるクラスとする。
出現が有効となる文脈は，<scope>子要素を使用して表現してよい。存在しない場合には，有効範囲は制約なしであって，出現は常に有効とする。
出現場所： <topic>
<!ELEMENT occurrence
( instanceOf?, scope?, ( resourceRef | resourceData ) )
>
<!ATTLIST occurrence
id ID #IMPLIED
>
<occurrence>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
IDを“hamlet”とするトピックは，内容が文字列“1600-01”である型“date-of-composition”のクラスの出現，及び示されたURLにおける型“xml-version”の出現をもつ。
<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>
<resourceRef>要素は，資源へのURI参照を提供する。
資源は，次の理由の一つのために参照してよい。
a) トピックの出現として。これは，<occurrence>要素の中で行われる。 b) 番地付け可能な主題として。これは，<member>，<mergeMap>，<scope>，及び<subjectIdentity>要素の中で行われる。 c) トピックの異形名として。これは，<variantName>要素の中で行われる。
出現場所： <member>, <mergeMap>, <occurrence>, <scope>, <subjectIdentity>, 又は<variantName>
<!ELEMENT resourceRef EMPTY >
<resourceRef>要素は，内容をもたない。
<!ATTLIST resourceRef
id ID #IMPLIED
xlink:type NMTOKEN #FIXED 'simple'
xlink:href CDATA #REQUIRED
>
<resourceRef>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|---|
| xlink:type | このリンクをXLinkの単純リンク型として識別する。 |
| xlink:href | このリンクに対してURI参照を供給する。 |
備考 適合性及び利用法のためには，[XLink]の5.2及び5.4を参照すること。
<variant>，<occurrence>，及び<mergeMap>要素を参照すること。
<resourceData>要素は，次の文字データ形式の情報を含む。
a) トピックの出現。 b) 基底名の異形。
出現場所： <occurrence>又は<variantName>
<!ELEMENT resourceData ( #PCDATA ) >
<resourceData>要素は，文字データだけを含んでよいことを意味する#PCDATAと宣言される。
<!ATTLIST resourceData
id ID #IMPLIED
>
<resourceData>要素は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|
<variant>及び<occurrence>.要素を参照すること。
<mergeMap>要素は，URIを含むxlink:href属性を通して，外部の<topicMap>要素を参照する。附属書F XTM処理要件で規定される規則に従って，含む側のトピックマップ及び参照される側のトピックマップを併合する指令とする。
<mergeMap>の子供は，参照される側のトピックマップに起源をもつすべての特質の有効範囲に追加されるのが望ましいトピックを指示する。併合された特質の有効範囲は，トピック名前付け制約を考慮してのトピックの併合をを避ける理由で，又は起源のトピックマップに基づく特質を区別する理由で，修正してもよい。
出現場所： <topicMap>
<!ELEMENT mergeMap ( topicRef | resourceRef | subjectIndicatorRef )* >
<!ATTLIST mergeMap
id ID #IMPLIED
xlink:type NMTOKEN #FIXED 'simple'
xlink:href CDATA #REQUIRED
>
<mergeMap>は，次の属性をもつ。
| id | 要素に対する一意な識別子。 |
|---|---|
| xlink:type | このリンクをXLinkの単純リンク型と識別する。 |
| xlink:href | このリンクに対するURI参照を供給する。これは，グラフの生成時に，このトピックマップと併合されるのが望ましいトピックマップへの参照とする。 |
備考 適合性及び利用法のために，[XLink]の5.2及び5.4を参照すること。
“plays.xtm”トピックマップに起源をもつすべての特質の有効範囲に，(現在のトピックマップの中の)トピック“shakespeare”及びトピック“drama”を追加して，“plays.xtm”を現在のトピックマップと併合する。
<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>
“biography.xtm”トピックマップに起源をもつすべての特質の有効範囲に，(番地付け可能な主題としての)資源それ自体を追加して，“biography.xtm”を現在のトピックマップと併合する。この技術によって，作成者は，トピックマップを主題として使用し，併合結果の中にそれ自体のトピックを有効範囲付けすることが可能となる。
<mergeMap xlink:href="http://www.shakespeare.org/biography.xtm">
<resourceRef
xlink:href="http://www.shakespeare.org/biography.xtm"/>
</mergeMap>
4.では，文書及び応用がXTM規定に適合していると正確に主張可能な条件を示す。
文書又は応用は，次の適合性基準のすべてが満たされる場合にだけ，XTM規定に適合する。
a) 必須条件[“しなければならない(shall及びmust)”と規定されている条件]を守ること。 b) 任意選択条件[“することが望ましい(should)”及び“してもよい(may)”と規定されている条件]に対しては，それが示されたとおりに守ること。
これらの適合性基準は，文書及び応用の適合性をXTM規定に対して保証するいかなるプログラムにも，試験スイート，並びに適合性の主張が求められる文書及び応用の適合性を測定し報告するための他の道具の開発にも，適用されなければならない。
この規定内では，キーワード “しなければならない(MUST)” “してはならない(MUST NOT)” “要求された又は必須の(REQUIRED)” “しなければならない(SHALL)” “してはならない(SHALL NOT)” “することが望ましい(SHOULD)” “しないほうがよい(SHOULD NOT)” “することが望ましい(RECOMMENDED)” “してもよい(MAY)” 及び “任意選択の(OPTIONAL)” は，RFC 2119([RFC 2119]参照)に示されているとおりに解釈することが望ましい。
XTM処理は，[XML]，[XML Names]，[XLink]，[XML Base]，及び[RFC 2396]([RFC 2732]によって更新されている。)に依存する。
このXTM規定を識別する(W3C勧告Namespaces in XML [XML Names]が指定する意味での)“名前空間名”として使用されるURI参照を次に示す。
http://www.topicmaps.org/xtm/1.0/
このXTM規定に適合する文書のために，W3Cの名前空間を意識した処理の利用を望む応用は，W3Cの名前空間名が確実にこのURIとなっているものとしなければならない。
この規定は，このXTM規定，及びTopicMaps.Orgによって作成された関係規定の使用のために，(('X'|'x') ('T'|'t') ('M'|'m'))に一致する文字列の使用を予約する。
トピックマップ文書は，4.1 “XTM適合性のための用語使い”の中で列挙された条件に加えて，次の条件のすべてを満たす場合及びその場合に限り，XTM 1.0規定に適合する。
<topicMap>要素の外側であってXML文書の中に存在するXTMマーク付けは，この規定によっては定義されない。
XTM応用は，次を行うあらゆるソフトウェアモジュールとする。
XTM応用は，次の条件のすべてを満たす場合及びその場合に限り，XTM 1.0規定に適合する。