この標準情報(TR)は, 2001年7月に公表されたTopicmaps.netのProcessing Model for XTM 1.0の1.0.2版を翻訳し, 技術的内容を変更することなく作成した標準情報(TR)である。
XTM(XML Topic Maps，XMLトピックマップ) 1.0のための処理モデルは，文書作成者が，トピックマップについて，発見，教育，開発及び試験できるようにする基本的な考え方に沿ったXTM構文の意味記述を提供する。
XTM 1.0のための処理モデルのこの版は，XTM 1.0規定，すなわち，XTMの<topicMap>要素，に適合したトピックマップ文書の処理だけを規定する。JIS X 4157:2002 SGML応用 — トピックマップ(ISO/IEC 13250:2000がこの規格に一致している。)によって規定された交換構文(meta-DTD)を含む，トピックマップ情報の交換のための他の構文の処理については，追加的に，将来の版で議論する。
この標準情報(TR)の原規定の著者(Steven R. Newcomb，mailto:srn@coolheads.com及びMichel Biezunski，mb@infoloom.com)は，Sam Hunting，Victoria T. Newcomb 及び Peter Newcombの寄与及び助言に大いに感謝する。
この標準情報(TR)の原規定の前の版は，http://www.topicmaps.orgによって公表されたXTM 1.0規定の原案の中に含まれていた。この標準情報(TR)の原規定のこの版は，すべての目的のために及びすべての方法で，一般に広く使用許諾されている。
この文及び他のすべての通告，並びに名前及び電子メールアドレスによる著者の連絡先を含めて，この標準情報(TR)の原規定に対する複写及び翻訳は，完全であって正しいことが要求される。この処理モデルへの適合性の主張は，正確であることが要求される。処理システムは，すべての詳細において正確であって包括的にモデルに適合しているか，又は適合せず適合性の主張を正当化しないかのいずれかとする。
詳細だが必ずしも厳密ではない解説形式の定義を，附属書A 定義に示す。
XTM 1.0のための処理モデルは，受け手に伝達することを意図した情報の意味を再構成するために，トピックマップ文書を処理するための規則集合を定義する。このモデルは，トピックマップ応用のための設計図の一部として使用することができるが，それが第一の目的ではない。第一の目的は，厳格な方法で，トピックマップ情報の意味についての重要な合意を示すことにある。
XTM 1.0のための処理モデルでは，<topicMap>要素を処理した結果は，"ノード"，及び何らかの方法でノードを結ぶ"弧"から構成される"トピックマップグラフ"を用いて記述される。
備考 XTM 1.0のための処理モデルは，グラフ並びにそれらの構成要素であるノード及び弧を用いて，XTM 1.0構文の意味を説明するが，すべての実装をグラフの手法に制約する意図はない。例えば，この処理モデルが説明する関係及び意味を，関係データベースを使用して正確に実装することは可能である。
トピックマップグラフ(又は交換される情報の完全な理解の他の表現)は，他の処理が行われる前に完全に完了していなければならない。トピックマップグラフが構築された後，トピックマップ応用は，交換可能なトピックマップ文書によって伝達される情報を利用するために，XTM 1.0のための処理モデルにおいて記述されることを越えて，(問合せに応えること，一つ以上の発見支援の描出などの)追加的な処理を実行してもよい。それらの追加的な処理は，XTM 1.0のための処理モデルによって制約されない。
<topicMap>要素との構造の差異トピックマップ情報は，本来的に多次元といえる。交換のためには，トピックマップ情報は，文字の列に平坦化されなければならない。交換後に，再度多次元とするために，情報は，再構成されなければならない。XTM 1.0のための処理モデルは，完全に，再構成処理及びその再構成処理の結果("トピックマップグラフ")に関係する。
例えば，W3CのDOM APIは，<topicMap>要素によって表現されたトピックマップ情報への直接のアクセスを提供しない。それは，その情報の構文的な表現，すなわち，<topicMap>要素それ自体，へのアクセスだけを提供する。DOMは，<topicMap>要素からトピックマップ情報を再構成する応用によって使用されることができるが，<topicMap>要素から作成されるDOMの木は，すぐに使用できるトピックマップ情報ではない。
トピックマップグラフは，ノード，及びノードを結ぶ弧から構成される。
トピックマップグラフには，次の3種類のノードが存在する。
ノードを特徴付けるものは，ノードが一つ以上の弧の端点として振る舞ういう事実だけとする。XTM 1.0のための処理モデルでは，ノードそれ自体は，他の特性も特質ももたない。
三つの異なるノード型は，それらのノード型が何本のどの種類の弧の端として振る舞うことができるかという規則をもつ。"3.3 あるノード型が弧型の特定の端点として振る舞うことに関する制約"を参照すること。これらの規則以外には，XTM 1.0のための処理モデルのために，3種類のノードを区別する他の形式的な特徴はない。
トピックマップグラフには，次の4種類の弧が存在する。
"関連メンバ"弧は，"関連"端及び"メンバ"端と呼ばれる二つの端をもつ。
"関連"端は，常に，aノードとする。(aノードは，常に関連を表現する。)
"メンバ"端は，aノードが表現する関連において特定の役割の演技者を表現するノードとする。
"関連メンバ"弧は，ラベルをもつ唯一の種類の弧とする。ラベルは，常に，トピックを表現するtノードとし，そのトピックの主題が，("関連"端でaノードによって表現された)関連において，("メンバ"端でそのノードによって表現された)メンバによって演じられている役割とする。
"関連有効範囲"弧は，"関連"端及び"有効範囲"端と呼ばれる二つの端をもつ。
"関連"端は，常に，aノードとする。(aノードは，常に関連を表現する。)
"有効範囲"は，常に，sノードとする。sノードは，関連が有効である有効範囲を表現する。グラフにおいて，すべての関連は，aノードとして表現され，すべてのaノードは，少なくとも一つの有効範囲をもつ。"関連有効範囲"弧は，関連(aノード)が，ある有効範囲をもつという事実を表現する。aノードだけが，有効範囲をもつ。XTM概念モデルに適合して，すべてのトピック特質は，構文的に<association>要素として表現された関連におけるメンバを含むだけでなく，グラフの中でaノードとして表現されるすべてのトピック名及びトピック出現を含む。したがって，"関連"という語が，XTM概念モデルの文脈及びXTM 1.0のための処理モデルの文脈の中で使われる場合には，一つの要素型名(XTM交換構文の文脈においては<association>)として使われる場合よりも，幾分広い定義をもつ。
"関連テンプレート"弧は，"関連"端及び"テンプレート"端と呼ばれる二つの端をもつ。
"関連"端は，常に，aノードとする。(aノードは，常に関連を表現する。"関連"という語を，ここでは，<association>要素によって構文的に表現される種類のものだけでなく，<occurrence>要素及び<name>要素によって構文的に表現される種類のものも含めた意味で，使用していることに注意すること。
"テンプレート"端は，常に，"関連"端におけるaノードが適合性に対して妥当性検証されるのに用いるモデルである主題を表現するtノードとする。(そのモデルは，ある種類のaノードの集合及びそれらのメンバによって，グラフの中に表現される。これらのaノードのすべては，ある役割を演じるメンバとしてこのtノードをもつ。このことは，以下に記述する。)
"有効範囲構成要素"弧は，"有効範囲"端及び"構成要素"端と呼ばれる二つの端をもつ。
"有効範囲"端は，常に，sノードとする。sノードによって表現される有効範囲は，そのsノードが"有効範囲"端として振る舞う"有効範囲構成要素"弧の集合の"構成要素"端として振る舞うtノード(及び/又はaノード)の集合とする。
XTM 1.0のための処理モデルは，あるノード型だけが，ある弧型のある終端として振る舞うことを許容するという方法で，トピックマップグラフの構築を制約する。与えられたノードが振る舞うことが可能な弧終端の数に関して数的な制約が存在する場合がある。3.3の表は，これらの制約を示す。
次に，"あるノード型が弧型の特定の端点として振る舞うことに関する制約"についての表を，表1として示す。
| 与えられたtノード | 与えられたaノード | 与えられたsノード | |
| "関連メンバ"弧の"関連"端点としての振る舞い | no | * | no |
|---|---|---|---|
| "関連メンバ"弧の"メンバ"端点としての振る舞い | * | * | no |
| "関連メンバ"弧のラベルとしての振る舞い | * | no | no |
| "関連有効範囲"弧の"関連"端点としての振る舞い | no | + | no |
| "関連有効範囲"弧の"有効範囲"端点としての振る舞い | no | no | * (1) |
| "関連テンプレート"弧の"関連"端点としての振る舞い | no | ? | no |
| "関連テンプレート"弧の"テンプレート"端点としての振る舞い | * | no | no |
| "有効範囲構成要素"弧の"有効範囲"端点としての振る舞い | no | no | * |
| "有効範囲構成要素"弧の"構成要素"端点としての振る舞い | * | * | no |
表1の表記の意味は，次のとおりとする。
no 与えられたノード型のインスタンスは，この端点又はラベルとしては振る舞うことができない。 ? 与えられたノード型のインスタンスは，一つのそのような端点として振る舞ってよい。(端点の個数としては，0又は1になる。) * 与えられたノード型のインスタンスは，任意の個数のそのような端点として振る舞ってよい。(端点の個数としては，0以上になる。) + 与えられたノード型のインスタンスは，一つのそのような端点として振る舞わなければならず，それ以上の個数のそのような端点として振る舞ってもよい。(端点の個数としては，1以上になる。)
注(1) XTM 1.0のための処理モデルは，aノードの有効範囲として使用されないsノードの存在を，禁止もしないし要求もしない。
トピックマップグラフにおいて，<topic>要素は，tノードによって表現される。同様に，<association>要素は，aノードによって表現される。
<topicMap>要素から構築されるトピックマップグラフの中に現れるtノードの数は，<topicMap>の中の<topic>要素の数と，通常，同じではない。同様に，ただし異なる理由のために，<topicMap>要素から構築されるトピックマップグラフの中のaノードの数は，<topicMap>の中の<association>要素の数と，同じではない。
例えば，要素よりも多くのノードが存在する可能性がある。
<topicMap>要素の内容は，<topic>要素及び<association>要素以外の(及びそれら要素に追加する形での)tノード及びaノードの存在を要求してもよい。それらのノードの存在は，"暗黙的に要求される"という。<topic>要素及び<association>要素だけが，明示的に，対応するtノード及びaノードの存在を要求する。他のすべてのtノード及びaノードの存在は，暗黙的に要求される。例えば，情報資源が<resourceRef>要素によって参照される場合，対応するtノードの存在が暗黙的に要求される。(その主題は，参照された情報資源になる。すなわち，<resourceRef>要素の場合，主題は，資源それ自体であって，資源が示すものではない。) 関連の場合，aノードの存在は，<instanceOf>要素，<occurrence>要素及び<baseName>要素によって暗黙的に要求されてもよい。
例えば，要素よりも少ないノードが存在する可能性がある。
トピックマップ処理は，複数の<topic>要素を通じて宣言されたトピック特質を併合することによって，単一のtノードを生成してもよい。これは，二つの要素が同じ主題をもっていると処理システムが判断した場合にはいつでも，発生しなければならない。(トピック併合規則についての詳細は，"7. 主題に基づく併合規則"及び"8. トピック名前付け制約に基づく併合規則"を参照すること。) 正確に同じ関連を表現する複数の<association>及びaノード要求子(demander)も，単一のaノードに併合される。
任意の与えられたtノード又はaノードに対して，"ノード要求子(demander)"の総数は，常に，一つ以上になる。
tノードは，<topicMap>要素の中の<topic>要素がそうであるように，常に，正確に一つの主題を表現する("具体化する")。
<topicMap>要素の中では，同じ主題をもつ任意の個数の<topic>要素が存在できる。しかし，トピックマップグラフの中では，その主題をもつtノードは，一つだけ存在できる。(詳細については，附属書Aの"併合"を参照すること。)
ある意味において，tノードとaノードとの間に違いはあまりない。関連に参加するという目的では，aノードは，tノードとして扱うことができる。事実，tノードと同じように，aノードは，常に，正確に一つの主題を表現する(具体化する)。しかし，aノードの場合には，その主題は，常に，他の主題の間の特定の関係になっており，それら他の主題の各々は，tノード又はaノードのいずれかによって，グラフの中に表現される。
主題を表現するという理由で，aノードは，他の関連のメンバになることができる。すなわち，それは，"関連メンバ"弧の"メンバ"端点として振る舞う。(実際，一つのaノードが一つの"関連メンバ"弧の両端として振る舞うことは，完全に可能である。この場合，その関連それ自体が，それが表現する関係に参加していることになる。)
ある状況においては，tノードがaノードと併合されることさえも可能になる。その結果は，常に，aノードになる。
次に，tノードとaノードとの間の違いを示す。
aノードだけが，一つ以上の"関連メンバ"弧の"関連"端として振る舞うことができる。
aノードだけが，そのメンバがトピックマップにおけるトピックによって表現されている関係を表現できる。(tノードは，関係という主題を表現できる。これは，tノードが，任意 の主題を表現できることによる。しかし，関係がトピックマップにおけるトピックによって表現されるメンバをもっている場合には，その関係を表現するために，aノードが使用されなければならない。これは，aノードだけが，一つ以上の"関連メンバ"弧の"関連"端として振る舞うことができることによる。そのような弧なしに，関係とその関係の参加者との間の結付きを表現することはできない。
aノードだけが，有効範囲をもつことができる。すなわち，それは，一つ以上の"関連有効範囲"弧の"関連"端として振る舞うことができる。(実際，すべてのaノードは，有効範囲をもたなければならない。すなわち，それは，少なくとも一つの"関連有効範囲"弧の"関連"端として振る舞わなければならない。)
tノードだけが，関連テンプレートになることができる。aノード(すなわち，任意の弧型の"関連"端として振る舞うaノード)が，"関連テンプレート"弧の"テンプレート"端としても振る舞う状況が存在する場合には，それは，報告可能な誤りとする。
tノードだけが，番地付け可能な主題をもつことができる。aノードは，主題識別性点として，主題構成資源をもつことができない。(aノードの主題は，それが関係であるので，常に，番地付け不可能になる。すなわち，それは，情報の一部ではない。) tノードがaノードと併合されるとき，その結果のaノードが，番地付け可能な主題をもつ場合には，それは，報告可能な誤りとする。
tノード及びaノードは，弧の端点として振る舞うことに加えて，主題識別性点の集合をもつ。主題識別性点は，常に，トピックマップグラフの外部にある番地付け可能な資源とする。言い換えれば，XTM 1.0のための処理モデルの目的に関して，ノードとそれらの識別性点との間の結付きは，弧ではなく，識別性点それ自体は，ノードではない。主題識別性点，及びtノード(及びaノード)とそれらの主題識別性点との間の結付きは，完全に実装の領域とする。実装は，実装者がこの規定の中に示される併合要件をサポートする方法で実装を提供しなければならないという注意点を除いて，XTM 1.0のための処理モデルによって制約されない。(詳細は，附属書Aの"主題識別性点"を参照すること。)
備考 各々の主題識別性点を参照するために使用されてきた番地のすべてを恐らく含んだ番地を，利用者が検索できる方法で，tノード及びaノードを実装することは，妥当と思われる。あらゆる主題指示子又は主題構成資源へのたどりをサポートする方法でトピックマップ応用を実装することも，妥当と思われる。実際，あらゆる主題識別性点へのたどりだけでなく，あらゆる主題識別性点からのたどりの開始をサポートする方法でトピックマップ応用を実装することは，"トピックマップ"の考え方においてその名前が暗黙的に示す目標と整合すると思われる。しかし，XTM 1.0のための処理モデルは，そのような要件は課さない。
一つのtノードが一つより多くの主題構成資源をもつように見える状況が存在する場合，それは，報告可能な誤りとする。
関連は，関連テンプレートをもつことを要求されない。トピックマップグラフにおいて，このことは，aノードが，任意の関連テンプレート弧の端点として振る舞うことを要求されるのではないことを意味する。
tノードが一つ以上の"関連テンプレート弧"の"テンプレート"端として振る舞う場合，それは，"関連テンプレートtノード"と呼ばれる。関連テンプレートtノードは，aノードのメンバが演じることのできる役割のすべてを確立する。aノードがテンプレートをもつ場合(すなわち，それが"関連テンプレート"弧の"関連"端として振る舞う場合)，そのaノードのメンバがテンプレートによって指定された役割の一つを演じないときには，それは，報告可能な誤りとする。
関連テンプレートtノードは，一つ以上の"template-role-rpc"関連において"テンプレート"の役割を演じなければならない。任意の"関連テンプレート"弧の"テンプレート"端として振る舞うtノードが，一つ以上の"template-role-rpc"関連の"テンプレート"の役割を演じない場合には，報告可能な誤りとする。
すべての"template-role-rpc"関連aノードは，XTM 1.0規定の元の版で，それ自体テンプレート化されている。それらは，http://www.topicmaps.org/xtm/1.0/core.html#xtmmapsで，公開されている。公開主題指示子は，http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-template-role-rpcとする。
関連テンプレートtノードが"テンプレート"の役割を演じる"template-role-rpc"関連の各々は，次を確立する。
テンプレートそれ自体(である主題)。これは，"template-role-rpc"関連において"テンプレート"の役割を演じる正確に一つのtノードによって表現される。
テンプレートのメンバ役割の一つ(の主題)。これは，"template-role-rpc"関連において"役割"の役割を演じる正確に一つのtノードによって表現される。
役割のすべての演技者がインスタンスでなければならないトピックのクラス(の主題)。これは，"template-role-rpc"関連において"rpc"("役割演技者制約")の役割を演じる正確に一つのtノードによって任意選択的に表現される。
次の事実がある。
テンプレート化されている役割を演じるトピックは，そのテンプレートの中で"rpc"の役割を演じるインスタンスになる。これは，次におけるクラス及びインスタンスの関連によって，トピックマップの中で表現されなければならない。
テンプレート化されている役割を演じるトピックは，"インスタンス"の役割も演じ，"クラス"の役割を演じるトピックは，次のいずれかとする。
- テンプレートの中で"rpc"の役割を演じるトピック。
- テンプレートの中で"rpc"の役割を演じるトピックの上位クラス。
上記の段落の中で言及された"クラス及びインスタンス"の関連は，XTMで定義された"class-instance"関連テンプレートのインスタンスでなければならない。ただし，"class-instance"関連テンプレートの公開主題指示子は，http://www.topicmaps.org/xtm/1.0/core.html#xtmmapsで，http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-class-instanceとして，公開されている。
トピックの多くのクラスが役割を演じることを許されなければならない場合，"rpc"役割を演じるトピックは，それらのすべての下位クラスでなければならない。そうすることによって，テンプレート化されている役割を演じる適切なトピックは，実質的に，少なくともそれらの一つのインスタンスであるという事実によって，適切であると知らされる。
rpc役割を演じるトピックが他のトピックの下位クラスであるという事実は，XTMで定義された"superclass-subclass"(上位クラス及び下位クラス)関連テンプレートのインスタンスである関連(aノード)によって表現されなければならない。"superclass-subclass"関連テンプレートは，その公開主題指示子が，http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-superclass-subclassとして，公開されている。さらに，その"下位クラス"役割は，"rpc"役割も演じるトピックによって演じられる。
rpc役割を演じるトピックの上位クラスがXTMで定義される"Apply to Set"(集合適用)クラスのインスタンスとなる場合，それら上位クラスが課す制約は，テンプレート化されている役割を演じそれら上位クラスのインスタンスになるトピックの集合全体に適用される。rpc役割を演じるトピックの上位クラスがXTMで定義される"Apply to Set"(集合適用)クラスのインスタンスでない 場合，それら上位クラスが課す制約は，テンプレート化されている役割を演じそれら上位クラスのインスタンスになるトピックの各々に適用される。
備考 この標準情報(TR)の原規定を開発している時点では，テンプレート化された関連において特定の役割を演じなければならない(演じてもよい)トピックの数を制約するための公開主題指示子は，提供されていない。XTM 1.0のための処理モデルの利用者は，望む方法で自由にそれを行ってよい。しかし，XTM 1.0のための処理モデルと整合するためには，そのようなトピックは，"Apply to Set"トピックのインスタンスになることが望ましい。関連テンプレートにおいて特別の役割を指定するtemplate-role-rpc関連の中で，"rpc"役割を演じるトピックが存在しない場合，テンプレートのインスタンスである関連においてその役割を演じることが許されているトピックについての妥当性制約は存在しない。
最低限，役割演技者のその役割演技者制約に対する適合性を検査する行為は，その役割を演じるトピックと主題が役割演技者制約になるトピックとの間のクラス及びインスタンスの関連の存在に対する検査の行為とする。すべての他の役割演技者制約，及びそれらの各々の制約に対して役割演技者の適合性を検査するすべての他の処理は，必然的に，応用で定義されることになる。
sノードは，事実上は，トピック名前空間になる。トピック名前空間は，利用者がトピックの名前を知っている場合にトピックを検索できる，トピック索引に類似する。与えられたトピック名前空間において，各々の名前は，正確に一つのトピックに対応する。"有効範囲"端が与えられたsノードになる"関連有効範囲"弧の"関連"端として振る舞うトピック及び基底名の関連であるaノードの集合は，事実上，与えられたsノードによって表現されるトピック名前空間における，トピック基底名及びそれら基底名をもつtノードの集合になる。
備考 大域的な知識交換のためには，与えられたトピックマップ交換構文を処理できるすべての応用がサポートすることを要求される最小の基底名文字列の長さが存在しなければならないと考えられる。それらの交換構文の作成及び保守に責任がある応用に対して，次の二つの可能な値の検討を提案する。
サポートすることを保障された最小の基底名の長さが短すぎる場合，トピックマップの作成者が，基底名に短縮形の名前を強制される危険性がある。それは，トピックマップ規定の意図に反する可能性がある。一方，サポートすることを保障された最小の基底名の長さが長すぎる場合，トピック名前空間のサポートが，ある実装においては，不幸な量の負荷を生じてしまう。
- 31 (幾つかのRDBMSの実装における最大のキーフィールド長)
- 255 (幾つかのRDBMSの実装において最大のフィールド長になっている名前長)
完全に処理されたトピックマップグラフは，主題ごとに正確に一つのtノードをもつことが望ましい。これは，トピックマップ処理システムに対して利用可能な情報に関する制限によるものであって，自動的に完全に到達できてもよいしできなくてもよい理想的な状態とする。主題に基づく併合規則は，適合トピックマップ処理システムが，あらゆる利用可能な情報をもとにして，それらシステムが同じ主題をもつと知っているtノードを併合することを要求する。さらに，主題に基づく併合規則は，適合トピックマップ処理システムが，ある条件をもとにして，二つのtノードが同じ主題をもち，そのために，それらは一つのtノードに併合されなければならないと，結論付けることを要求する。
人間が，人間の知識をもとにして，二つのtノードの併合を引き起こすために介入しなければならない多くの状況が存在する。それらの状況の例には，二つのトピックが主題指示子資源をもたないが，それらの一つが基底名トピック特質として"Buster Keaton"をもち，他方が基底名トピック特質として"The Great Stone Face"をもつ場合がある。アメリカの映画史の知識が豊富な人間は，二つのトピックは，両方とも，同じ主題("Buster Keaton"という名前のハリウッドの男優)をもつと合理的に結論し，したがって，これらの二つのtノードを一つのtノードへと併合することが起こるように，トピックマップ処理に介入するかもしれない。
適合トピックマップ処理システムは，そのような人の介入に備えておくことを要求されない。しかし，トピックマップ応用の実装者には，トピックマップ情報の作成，交換，処理，使用及び保守において，人間を含めることの必要性をどのように考えるのが最もよいかを考慮することが強く推奨される。これは，それら人間の介入の必要性を最小限にする効果をもつ。すべてのトピックマップ処理システムによってサポートされなければならない最小限の自動併合能力を最大限活用するために，トピックマップの作成者には，共通の公開主題指示子を使用することが強く推奨される。利益共同体に奉仕する組織には，自分たちの共同体が使用する主題について，公開主題指示子を作成しその使用を普及させることが強く推奨される。それによって，共通的な主題識別性点が存在し，その回りに，関連する素材が，XTM 1.0のための処理モデルに適合するトピックマップ処理システムによって実行される併合操作を介して，自動的に"集められる"ことが可能になる。それら組織は，そのような識別性点を使用するトピックマップの価値及び併合可能性を守るために，それら識別性点の公開された番地の有効性を長期的に維持すること表明することが望ましい。
XTM 1.0のための処理モデルに従うと，主題に基づく併合規則のもとで，すべての適合トピックマップ処理システムが実行しなければならない最小の併合操作は，次のとおりになる。
二つのtノードの両方が主題構成資源である識別性点をもつ場合はいつでも，その資源がどのように異なった番地付けをされていようとも，二つの主題構成資源が一つであって同じ資源であると処理システムに対して知られている場合及びその場合に限り，それら二つのtノードは，併合されなければならない。言い換えれば，併合は，二つの番地が等価であると処理システムに対して知られている場合及びその場合に限り，要求される。
すべてのtノードは，少なくとも一つの主題指示子資源をもつ。(そうでない場合には，tノードは，少なくとも，その主題指示子の一つとしてその存在を要求した構文的な構成要素をもたなければならない。)主題構成資源をもたない二つのtノードは，次のいずれかの場合及びその場合に限り，併合されなければならない。
主題に基づく併合規則のためには，二つの主題指示子資源又は二つの主題構成資源が，同じデータを含むとか，同じ文字列であるとかは，重要ではない。二つの主題指示子資源の単純な文字列比較は，一般の場合には，同じ主題が記述されているかどうかの信頼できる指示ではない。例えば，異なった販売カタログにおける異なった製品は，偶然，同じカタログ番号をもっているかもしれないし，その二つのカタログ番号の比較が，それらが同じ製品であることを示すわけではない。したがって，主題に基づく併合規則は，識別性点として振る舞う資源のデータ内容の比較に基づかない。併合は，次の場合及びその場合に限り，起こらなければならない。
両方の 主題識別性点が主題指示子である，又は両方の 主題識別性点が主題構成子である，のいずれかの場合。(すなわち，これらの場合は，入り混じることができない。)
それらが，一つであって同じ資源である，すなわち，たとえ同じ番地付け可能な文脈の中で同じ資源に到達できる複数の異なる等価な番地付け表現がある場合であっても，正確に同じ番地付け可能な文脈の中に，それらが存在することを意味する場合。
備考1 番地付けされた情報が異なっていると判明した場合には，併合は，起こらないことが望ましい。これは，そのような場合，二つの資源は同じ資源でないことが明白なことによる。しかし，この議論の要点は，番地付けされた情報が同じ文字列であると判明することが，併合の発生が望ましいという指示とはみなせないということにある。
備考2 文字列比較を基礎にした併合が望ましい場合，名前に基づく併合規則の利用を考慮するのがよい。その規則は，結局のところ，それを目的にしている。
XTM 1.0のための処理モデルは，トピックマップ応用に対して，インターネット番地が同じ資源を番地付けしているかどうかを決定するために，通常のインターネット番地付け規則に従って，インターネット番地を比較できることを要求する。例えば，(インターネットドメイン名の場合のように，) インターネット番地において，大文字・小文字の違いが一般に無視できる場合，トピックマップ処理システムは，同じ資源を番地付けしているかどうかを決定するためにインターネット番地を比較するとき，大文字・小文字の違いを無視することが要求される。
備考 トピックマッププロセサは，必須ではないが，方式(scheme)名によって接頭辞修飾されていないが文字"www"で始まる番地を"http://"で始まるとみなすことが望ましいと自動的に仮定するといった，さまざまな発見的手法を適用してもよい。トピックマッププロセサは，二つの番地が等価かどうかを確立するために，カタログ化のサービス及び資源を利用してもよい。これは，XTM 1.0のための処理モデルに適合するシステムの提供者の間での競争のために，適切な領域になる。
トピックマップ処理の間，主題に基づく併合規則を繰り返して適用する必要があってもよい。これは，併合が，名前に基づく併合規則を基礎にして起こってもよいこと，及びそのような併合の効果として主題に基づく併合規則のもとで更なる併合が要求されてもよいことによる。
備考 これは，その逆があってもよい。
すべてのトピックマップに適用され，名前に基づく併合規則が基づいている"トピック名前付け制約"は，次の方法で，XTM 1.0のための処理モデルによって表現できる。
二つのtノード及び/又はaノードは，同じトピック名前空間(すなわち，同じ有効範囲)において，同じ基底名をもつことができない。("基底名をもつ"とは，"基底名"役割を演じる資源が"基底名"役割を演じるトピックの番地付け可能な主題(主題構成資源)になるという"トピック及び基底名"関連において，"トピック"役割を演じることとする。"トピック及び基底名"関連の有効範囲は，事実上，その有効範囲をもつトピック及び基底名の関連のすべてから構成される名前空間になる。)
名前に基づく併合規則は，トピックマップ処理の間に，二つ以上のtノード(及び/又はaノード)が同じ有効範囲の中で同じ基底名をもつことを見つけられた場合，その二つのノードは，その有効範囲(トピック名前空間)の中でその名前をもつ唯一のtノード又はaノードとなる一つのノードに併合されなければならない。
構文的には(すなわち，<topicMap>要素内では)，各々の基底名は，<baseNameString>要素の内容とする。
備考 すべての他の主題識別性点を用いる場合と同様に，主題が
<baseNameString>要素の内容である(及び"トピック及び基底名"関連において"基底名"役割も演じる)トピックから<baseNameString>要素の実際の内容までの結付きの性質は，存在する場合には，XTM 1.0のための処理モデルによって定義されないことを，思い出すこと。
トピックマップグラフでは，"トピック及び基底名"関連の有効範囲(すなわち，"構成要素"であるトピックの集合が"トピック及び基底名"関連の有効範囲を構成するsノード)は，<baseName>要素の子である<scope>要素を介して指定されたトピックの集合とする。
備考 他のトピックのための他の基底名は，同じトピックのための他の名前と同様に，この同じトピック名前空間にも出現してよい。トピック名前空間が，基底名の一つを用いてtノード又はaノードを見つけるためにトピックマップグラフの利用者によって使用される場合，そのトピック名前空間の中で基底名を選択する行為は，実際，その名前空間の中でその基底名をもつトピックを選択する行為になる。これは，与えられた名前空間の中で，与えられた名前をもつことができるのは，ただ一つのトピックであることによる。
すべての"トピック及び基底名"関連は，公開主題指示子が，http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-topic-basenameとして利用可能な，XTMが定義する"topic-basename"関連テンプレートにおいて，テンプレート化されている。(基底名及び異形名の扱いは，XTM 1.0のための処理モデルの中で完全に記述される。)
トピックマップ処理の間に，名前に基づく併合規則を繰り返して適用する必要があってもよい。これは，併合が，主題に基づく併合規則を基礎にして起こってもよいこと，及びそのような併合の効果として名前に基づく併合規則のもとで更なる併合が要求されてもよいことによる。
備考 これは，その逆があってもよい。
トピックマップの第一の目的は，過剰な情報の利用及び管理可能性を高めることにある。特に，このことは，冗長性を最小限にすることを意味する。
トピックマップグラフの構築が完了したときには，いかなる集合においても重複した項目は存在しない。重複した項目が禁止されている集合の一覧を，次に示す。
与えられたtノードの主題指示子資源の集合。
sノードの集合。二つのsノードが，同一の有効範囲を表現することはできない。すなわち，二つのsノードは，"構成要素"端の集合がトピックの同一の集合である"有効範囲構成要素"弧の集合の"有効範囲"端として振る舞うことができない。賢明ではない実装アルゴリズムの副作用として，交換可能な<topicMap>要素(の集合)におけるすべての有効範囲規定が，十分に理解され考慮された後で，二つのsノードが同一の有効範囲を表現する場合，それらは，併合され，一つのsノードにならなければならない。
備考1 定義によって，トピック名前空間の重複もありえない。これは，sノードがトピック名前空間を定義することによる。
備考2 sノードは，トピック出現"空間"，及びすべての他の種類の関連のための"空間"も定義する。このことは，興味深い情報管理の可能性を生じさせる。いずれにせよ，XTM 1.0のための処理モデルでは，sノードがすべての種類の資源の関係を集める方法が，この処理モデルの最も興味深い特徴の一つと考えられる。
aノードの集合。次の文の一つ以上が真の場合，二つのaノードは，(冗長でなく)異なる。
各々の役割を演じるトピックの集合に何らかの違いがある。
関連は，異なる関連テンプレートをもつ。関連テンプレートが異なるtノードによって表現される場合には，それらは異なる。
関連は，異なる役割をもつ。役割が異なるtノードに対応する場合には，それらは異なる。
これらの文のいずれもが真でない場合には，二つのaノードは，たとえそれらが異なる有効範囲をもっているとしても，一つのaノードに併合されなければならない。それらが異なる有効範囲をもつ場合，併合されたaノードは，二つのaノードが"関連"端であった"関連有効範囲"弧の集合の合併集合の"関連"端として振る舞う。
与えられたaノードのメンバとしての与えられた役割を演じるtノード及びaノードの集合。
与えられた有効範囲を構成するtノード及びaノードの集合。
与えられた関連テンプレートのために定義された役割の集合。二つの役割が異なるtノードの主題の場合，その二つの役割は，異なる。
次の二つの間の対応関係を考える。
<topicMap>要素のインスタンスの中に見つかる構文的構成要素のすべて。
XTM 1.0のための処理モデルで記述される"トピックマップグラフ"。
これらの対応関係の特徴の一つは，次のとおり表現できる。
"すべてのノード要求子(node demander)は，主題指示子とする。"
このことは，トピックマップグラフの構築過程でトピックマップの構文的構成要素に出会ったとき，そのトピックマップの構文的構成要素が，その過程(の処理)に，一つのtノード又はaノードを作成する(又はそれらのノードに特質を追加する)ことを要求する場合，そのtノード又はaノードは，そのトピックマップの構文的構成要素を主題指示子の一つとしてみなさなければならないことを意味する。この機構は，たとえ，<topic>要素がそのtノードに対応しなくとも，すべての番地付け可能な資源を(例えば)トピック(すなわち，tノード)として扱うことを可能にする。このようにして，トピックの出現として振る舞うすべての情報資源は，実際，それ自体その情報資源が主題になるトピックになり，そのトピックをその出現の一つと結合する結付きは，次のとおりの，二つのトピック間の"トピック及び出現"関連とみなされる。
トピック要素それ自体。これは，"トピック"役割を演じる。
主題が出現になるトピック。これは，"出現"役割を演じる。
備考1 この規則の効果の一つは，すべてのaノード及びtノードが，それに特質が追加できる方法で，結果として，構文的に番地付け可能になることである。これは，そのノードが，
<topic>又は<association>として構文的に表現されているかどうかに関係しない。そのような付加的な特質は，ノード要求子を主題指示子資源の一つとみなす<topic>要素又は<association>要素を提供することによって，追加できる。
備考2 この規則の他の効果は，XTMの意味規則のために何らかの特別な条項を作ることを不必要にすることである。すなわち，
<topicRef>又は<subjectIndicatorRef>が，トピックマップグラフの構築過程への入力の一部を形成する<topic>要素又は<association>要素を参照するとき，<topicRef>又は<subjectIndicatorRef>は，<topic>又は<association>が示す主題を参照していて，したがって，<topic>又は<association>を主題識別性点とみなす。特別な条項が作成される必要性がない理由は，<topic>要素及び<association>要素がノード要求子になることによる。
11.では，XTM 1.0規定において提供されるDTDに適合する<topicMap>要素の処理について，要素型ごとに示す。
<topicMap>要素及び<mergeMap>要素すべてのXTMグラフ構築過程は，一つの"開始"<topicMap>要素から始まる。開始<topicMap>要素の内容全体が，XTM 1.0のための処理モデルに従って処理される。
開始<topicMap>要素は，<mergeMap>要素を含んでよい。その場合には，その<mergeMap>要素によって参照される<topicMap>要素も，再帰的に，グラフ構築過程の入力になる。これは，トピックマップが併合される方法である。
備考 参照される
<topicMap>要素が処理される順番は，XTM 1.0のための処理モデルによって制約されない。
XTM 1.0のための処理モデルでは，<mergeMap>によって参照される<topicMap>要素を，"従属"<topicMap>要素と呼ぶ。一方，<mergeMap>要素の包込み(ラッパ，wrapper)として動作する主<topicMap>要素を，"開始"<topicMap>要素と呼ぶ。
従属<topicMap>要素の処理は，次のことを除いて，開始<topicMap>要素の処理と正確に同じとする。<mergeMap>要素が子どもをもつ場合，その内容の中で作成された参照に対応するtノード及び/又はaノードは，適用可能な<mergeMap>要素のxlink:href属性によって参照される<topicMap>要素の中で宣言されたすべてのトピック特質の有効範囲に，再帰的に，追加される。
<topic>要素及びその子孫<topic>要素の取扱い各々の<topic>要素は，対応するtノードの存在を要求する。
<topic>要素の中の<instanceOf>要素の取扱い<topic>要素の子である各々の<instanceOf>要素は，関連テンプレートが"class-instance"関連テンプレートのインスタンスであるaノードの存在を暗黙的に要求する。(このテンプレートの公開主題指示子の一つは，クラス及びインスタンスの関連のためのテンプレートであるhttp://www.topicmaps.org/xtm/1.0/psi1.xtm#at-class-instanceでなければならない。)
そのような各々のaノードにおいて，<topic>要素によってその存在が明示的に要求されるtノードは，"インスタンス"役割を演じ，<instanceOf>の中に含まれる参照する側の要素によってその存在が暗黙的に要求されるtノード又はaノードは，"クラス"役割を演じる。このトピックの主題は，"トピック型"という。"クラス及びインスタンス"(関連)のaノードの有効範囲は，制約なしの有効範囲(空集合の有効範囲)に，あらゆる適用可能な<mergeMap>要素によって指定されたあらゆる追加的有効範囲になるトピックを加えたものとする。
備考 グラフ上で同じ効果を生じる，正確に同じであるクラス及びインスタンスの関係は，同じクラス及びインスタンスのテンプレートによってテンプレート化される
<association>要素を介して表現できる。明示的な<association>要素を使用する利点は，有効範囲を明示することを可能にすることであって，この有効範囲は，制約なしの有効範囲になる必要はない。
<topic>要素の中の<subjectIdentity>要素の取扱い<topic>要素によってその存在が明示的に要求されるtノードは，次のいずれかをもってよい。
資源によって構成される主題。そのような資源は，"主題構成資源"又は"番地付け可能な主題"とも呼ばれる。
備考 これらの項目は，トピックの主題は，番地付け可能又は番地付け不可能のどちらかであって，両方ではないことを示すことを意図している。（トピックは，常に，正確に一つの主題をもち，一つの主題は，番地付け可能及び番地付け不可能の両方であることはできない。）主題が番地付け可能な場合，トピックの主題識別性点の正確に一つが，番地付け可能な主題(すなわち，主題構成資源)それ自体でなければならず，さらに，同じ番地付け可能な主題のために一つ以上の主題指示子も存在する。("ノード要求子は主題指示子"という規則は，たとえ主題が番地付け可能であっても，常に少なくとも一つの主題指示子が存在することを保証する。）トピックの主題が番地付け不可能な場合，どのトピックの識別性点も，主題構成資源になることはできない。しかし，再び，"ノード要求子は主題指示子"という規則のために，常に，少なくとも一つの主題指示子が存在し，任意の個数の追加的な主題指示子が存在してもよい。
<subjectIdentity>要素の子が<resourceRef>要素を含む場合，tノードの主題は，参照された資源それ自体であって，資源が意味する解釈できるものではない。参照資源は，"主題構成資源"になる。これは，資源それ自体が主題を構成することによる。参照された資源は，tノードのための主題識別性点になる。
トピックマップ処理が一つ以上の主題構成資源をもつ一つのtノードを結果として生じた場合，それは，報告可能な誤りとする。
tノードの主題識別性点が("番地付け可能な主題"としても知られている)主題構成資源を含んでいない場合，その主題は，"番地付け不可能な主題"であって，<subjectIdentity>要素の子どもである<subjectIndicatorRef>要素によって参照される資源の各々によって"指示される"ことだけが可能である。参照された資源の各々は，別々に及び強制的にトピックの主題を指示することが可能と考えられる。
<subjectIndicatorRef>要素によって参照される資源がそれ自体<topic>要素である場合，参照される<topic>要素の主題は，<subjectIndicatorRef>要素を含む<subjectIdentity>要素の，更にその要素を含む<topic>要素の主題と同じ主題と考えられ，二つの<topic>要素によってその存在が明示的に要求される二つのtノードは，主題に基づく併合規則の支配のもとに，併合される。一つ以上の<topicRef>要素が<topic>要素の中に含まれる<subjectIdentity>要素の内部に現れる場合，それらの各々は，<subjectIndicatorRef>要素であるものとして扱われる(この段落の最初を参照)。<subjectIdentity>要素が存在するかどうかにかかわらず，少なくとも一つの主題指示子が存在し，それは，<topic>要素(又は暗黙的若しくは明示的にノードの存在を要求したあらゆる要素)になる。
<topic>要素の中の<baseName>要素の取扱い<baseName>要素の中の<baseNameString>要素の取扱い<baseName>要素の各々の<baseNameString>子要素は，暗黙的，tノードの存在を要求する。そのtノードの主題を構成する資源は，その<baseNameString>要素の内容とする。XTM 1.0のための処理モデルでは，それらtノードを，"baseNameString tノード"と呼ぶ。
<baseName>要素の取扱い<topic>要素の子の<baseName>要素の各々は，その関連テンプレートがXTMで定義された"topic-basename"関連テンプレートであるaノード("トピック及び基底名のaノード")の存在を暗黙的に要求する。(そのテンプレートの公開主題指示子は，http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-topic-basenameとして，利用可能である。) このaノードにおいて，親の<topic>要素によってその存在が明示的に要求されるtノードは，"トピック"の役割を演じ，baseNameString tノードは，"基底名"の役割を演じる。トピック及び基底名のaノードの有効範囲は，<baseName>要素の子の<scope>要素を介して指定されるトピックの集合に，あらゆる適用可能な<mergeMap>要素によってその有効範囲に追加されることが要求されるあらゆるトピックを加えたものとする。<scope>要素が指定されず，<mergeMap>要素によって有効範囲となるトピックが有効範囲に追加されない場合，その有効範囲は，制約なしの有効範囲(空集合の有効範囲)とする。(トピックマップグラフにおいて常にそうであるとおりに，有効範囲は，"関連有効範囲"弧によってaノードに結び付けられたsノードによって表現される。）
<baseName>要素の中の<variant>要素及び<variantName>要素の取扱い同一の<baseName>要素内の<variantName>要素を介して指定される異形名は，グラフの中で基底名にはならず，トピック名前付け制約は，異形名には適用されない。
<variantName>要素の各々は，主題識別子がその<variantName>要素であるtノードの存在を暗黙的に要求し，それは資源と考えられる。(すなわち，それが意味すると解釈されるかもしれない主題としては考えられない。) XTM 1.0のための処理モデルにおいて，それらノードを，"異形名tノード"と呼ぶ。
すべてのaノードと同様に，"トピック及び基底名"aノードは，他のaノードが表現する関係の中で役割を演じる(すなわち，その中で所属関係をもつ)ことができる。トピックマップグラフにおいて，各々の異形名tノードは，その中で"トピック及び基底名"aノードが"基底名"役割を演じている"基底名及び異形名"クラスのaノードの中で，"異形名"の役割を演じる。すべてのaノードを用いた場合と同様に，各々のそれら"基底名及び異形名"aノード有効範囲は，グラフの中で，"関連有効範囲"弧を介してaノードに結び付けられたsノードとして表現される。sノードは，含む側の<baseName>要素によってその存在が暗黙的に要求される"トピック及び基底名"aノードの有効範囲の中に，トピックのすべてを含む有効範囲を表現する。さらに，その有効範囲は，異形名tノードに対応する<variantName>要素が直接の子孫として出現する<variant>要素の，そのすべての内部に現れる<parameters>要素すべてに含まれた参照する側の要素が存在を要求するtノード及びaノードのすべても含む。
<topic>要素の中の<occurrence>要素の取扱い<occurrence>要素の中の<resourceRef>要素及び<resourceData>要素の取扱い<occurrence>要素の子の<resourceRef>及び<resourceData>の各々は，tノードの存在を暗黙的に要求する。<resourceRef>要素については，その存在が暗黙的に要求されるtノードは，その主題構成資源としてその要素によって参照される資源をもつ。<resourceData>要素については，その存在が暗黙的に要求されるtノードは，その主題構成資源として<resourceData>要素の内容をもつ(<baseNameString>要素の取扱いについての議論を参照)。
<occurrence>要素の取扱い<topic>要素の子の<occurrence>要素の各々は，"トピック及び出現"クラスのaノードの存在を暗黙的に要求する。この関連の中で，親の<topic>要素によってその存在が明示的に要求されるtノードは，"トピック"の役割を演じる。"出現"役割は，<occurrence>要素の子どもである<resourceRef>及び/又は<resourceData>によってその存在が暗黙的に要求されるtノードによって演じられる。"トピック及び出現"aノードの有効範囲は，<occurrence>要素の子の<scope>要素によって指定される有効範囲に，あらゆる適用可能な<mergeMap>要素が指定するあらゆるトピックを加えたものとする。
<occurrence>要素の中の<instanceOf>要素の取扱い<occurrence>要素の子である<instanceOf>要素は，存在する場合には，"クラス及びインスタンス"というクラスのaノードの存在を暗黙的に要求する。このクラス及びインスタンスの関連において，親の<occurrence>要素によってその存在が暗黙的に要求される"トピック及び出現"aノードは，"インスタンス"の役割を演じる。"クラス"の役割は，<instanceOf>要素の子によってその存在が暗黙的に要求されるtノードによって演じられる。"クラス及びインスタンス"aノードの有効範囲は，制約なしの有効範囲(空集合の有効範囲)に，あらゆる適用可能な<mergeMap>要素が指定するあらゆるトピックを加えたものとする。
<association>要素及びその子孫各々の<association>要素は，aノードの存在を明示的に要求する。aノードの有効範囲は，<association>の子として出現する有効範囲要素が指定する有効範囲に，あらゆる適用可能な<mergeMap>要素によって有効範囲に追加されるあらゆるトピックを加えたものとする。
<association>要素の中の<instanceOf>要素の取扱い次の二つの可能性がある。
<instanceOf>は，関連テンプレートトピックへの<topicRef>又は<subjectIndicatorRef>を含む。参照されるトピックが一つ以上の"template-role-rpc"関連の中で"テンプレート"役割を演じる場合及びその場合に限り，これは真になる。
この場合，グラフの中に"関連テンプレート"弧が存在しなければならない。この弧において，関連テンプレートtノードは，"テンプレート"端として振る舞わなければならず，<instanceOf>要素を含む<association>要素によってその存在が要求されるaノードは，"関連"端として振る舞わなければならない。
<instanceOf>内で参照されるトピックは，関連テンプレートトピックではない。
この場合，"クラス及びインスタンス"aノードは，"インスタンス"役割が，含む側の<association>要素によってその存在が明示的に要求されるaノードによって演じられ，"クラス"役割が，<instanceOf>の内容の中に作られた参照によってその存在が要求されるtノードによって演じられる，グラフの中に生成されなければならない。"クラス"役割がaノードによって演じられる場合には，それは，報告可能な誤りとする。
<association>要素の中の<member>要素の取扱い<member>要素の子である参照する側の要素(<topicRef>，<resourceRef>又は<subjectIndicatorRef>)は，"関連メンバ"弧の存在を要求する。その"関連メンバ"弧において，含む側の<association>要素によってその存在が明示的に要求されるaノードは，"関連"端として振る舞い，"メンバ"端は，<member>要素の子である参照する側の要素によってその存在が要求されるtノード又はaノードとする。
<resourceRef>要素の場合，"関連メンバ"弧の"メンバ"端として振る舞うtノードは，その主題構成資源として参照される資源をもつ。
<subjectIndicatorRef>要素の場合，"関連メンバ"弧の"メンバ"端として振る舞うtノード又はaノードは，その主題指示資源の一つとして参照される資源をもつ。<subjectIndicatorRef>要素が<topic>要素を参照する場合，<topic>要素によってその存在が明示的に要求されるtノードは，"関連メンバ"弧の"メンバ"端として振る舞う。
<topicRef>要素の場合，<subjectIndicatorRef>要素の場合と同じように，<topic>要素によってその存在が明示的に要求されるtノードが，"関連メンバ"弧の"メンバ"端として振る舞う。
<topicRef>要素が，<topic>要素でない資源であって，その資源がグラフの中でtノードの存在を明示的に要求するようなトピックマップ処理に従う資源を参照する場合，それは，報告可能な誤りとする。(言い換えれば，<topicRef>要素は，トピックマップグラフ構築処理への入力として使用される<topicMap>要素の中に現れる<topic>要素を参照しなければならない。)
<member>要素の内容によってその存在が要求される"関連メンバ"弧のラベルは，親が<member>要素である<roleSpec>要素の子になる参照する側の要素(<topicRef>又は<subjectIndicatorRef>)によってその存在が暗黙的に要求されtノード("役割tノード")とする。参照されるトピックの主題は，"関連メンバ"弧の"メンバ"として振る舞うtノード又はaノードが演じる役割とする。<roleSpec>要素の子である<subjectIndicatorRef>要素の場合，役割tノードは，主題指示資源の少なくとも一つとして参照される資源をもつ。<subjectIndicatorRef>が<topic>要素を参照する場合，<topic>要素によってその存在が明示的に要求されるtノードは，役割tノードになる。<topicRef>要素の場合は，<subjectIndicatorRef>要素の場合と同様に，参照される<topic>要素によってその存在が明示的に要求されるtノードが，役割tノードになる。
<association>要素によってその存在が明示的に要求されるaノードが，"関連テンプレート"弧の"関連"端となる場合(すなわち，関連テンプレートが有効な場合)であって，次のいずれかである場合，それは，報告可能な誤りとする。
<association>要素に含まれる<member>要素が，<roleSpec>要素によって，そのメンバがそのテンプレートにおいてどの役割に対応するかを指定するのに失敗している。
<roleSpec>要素が，そのテンプレートが役割として指定するトピックの一つを参照していない。
<roleSpec>要素が，そのテンプレートが役割として指定するトピック以外の何らかのトピックを参照している。
関連のメンバが，演じるものとして指定された役割を演じるメンバのための，テンプレート指定の制約を満たしていない。