public interface Association
extends RegistryObject

RegistryObject インスタンスは、0 個以上の RegistryObject インスタンスに関連付けることができます。情報モデルは、関連付けインターフェースを定義します。そのインスタンスを使用して、任意の 2 つの RegistryObject インスタンスを関連付けることができます。

関連付けの例

このような関連付けの一例として、2 つの ClassificationScheme インスタンスが挙げられます。図 1 に示すように、1 つの ClassificationScheme がもう 1 つの ClassificationScheme に取って代わります。これは、ClassificationScheme の新しいバージョンが送信された場合に発生する可能性があります。図 1 では、NAICS ClassificationScheme の新しいバージョンと NAICS ClassificationScheme の古いバージョンの間で関連付けがどのように定義されているかを示しています。
図 1. RegistryObject の関連付けの例

ソースオブジェクトとターゲットオブジェクト

関連インスタンスは、ソース RegistryObject とターゲット RegistryObject 間の関連を表します。これらは、関連インスタンスでは sourceObject および targetObject と呼ばれます。どのオブジェクトが sourceObject で、どのオブジェクトが targetObject であるかは、関連の方向セマンティクスを決定するため重要です。図 1 の例では、associationType は sourceObject が targetObject に取って代わることを意味するため (その逆ではありません)、NAICS ClassificationScheme の新しいバージョンを sourceObject にし、NAICS の古いバージョンを targetObject にすることが重要です。

関連タイプ

各 Association には、その Association の型を識別する associationType 属性が必要です。associationType 属性は、Jakarta XML Registries 仕様の定義済み associationType ClassificationScheme で定義されている列挙型 Concept への参照です。この例では、Supersedes という定義済み associationType Concept を使用しています。

学内協会

Association インターフェースの一般的な使用例は、ユーザー "u" が 2 つの RegistryObjects "o1" と "o2" の間に Association "a" を作成する場合です。ここで、Association "a" と RegistryObjects "o1" と "o2" は、同じユーザー "u" によって作成されたオブジェクトです。これは、Association を定義している同じユーザーが所有する 2 つのオブジェクト間の Association という最も単純な使用例です。このような Association は、intramural（内部）Association と呼ばれます。図 2 は、図 1 の例を intramural（内部）Association のケースに拡張したものです。
図 2. 学内協会の例

壁外協会

この情報モデルでは、より高度なユースケースも可能になります。たとえば、ユーザー "u1" が 2 つの RegistryObjects "o1" と "o2" の間に関連付け "a" を作成します。関連付け "a" はユーザー "u1" が所有しますが、RegistryObjects "o1" と "o2" はそれぞれユーザー "u2" とユーザー "u3" が所有します。このユースケースでは、関連付けられるオブジェクトのいずれか、両方が、関連付けを定義するユーザーとは異なるユーザーによって所有されている状態で関連付けが定義されます。このような関連付けは、外部関連付けと呼ばれます。Association インターフェースは、Association インスタンスが外部関連付けである場合に true を返す isExtramural という便利なメソッドを提供します。図 3 は、図 1 の例を外部関連付けのケースに拡張したものです。図 3 に示すように、外部関連付けには 3 つの異なるユーザーではなく、2 つの異なるユーザーが存在する可能性があることに注意してください。このような場合、2 人のユーザーのうちの 1 人が、関連する 3 つのオブジェクト（関連付け、sourceObject、targetObject）のうち 2 つを所有します。
図 3. 学外連携の例

協会の確認

関連付けは、その関連付けにオブジェクトが関与している当事者による確認が必要になる場合があります。このセクションでは、関係者による関連付けの確認のセマンティクスについて説明します。

学内関連の確認

学内の関連付けは、真実の宣言と見なすことができ、関連付けが真であることを確認するための明示的な手順は必要ありません。言い換えれば、壁内の関連付けは暗黙的に確認されたと見なされます。

壁外関連の確認

外部の関連付けは、他の (外部の) 当事者 (例ではユーザー "u2" と "u3" ) によって確認されるまで真実とは見なされない一方的な主張と見なすことができます。BusinessLifeCycleManager インターフェースの confirmAssociation メソッドは、sourceObject または targetObject を所有する外部の当事者によって呼び出される場合があります。

未確認の関連付けの可視性

壁外協会は、協会に関与していないサードパーティーに協会が見えるようになる前に、各壁外当事者が壁外協会によって行われた主張を確認することを要求します。これにより、未確認の関連付けがサードパーティのレジストリクライアントに表示されなくなります。

可能な確認状態

図 23 に示すように、外部関連付けに 3 つの異なるユーザーインスタンスがある最も一般的なケースを想定します。外部関連付けが完全に確認されるためには、他の (外部) 当事者 (例ではユーザー "u2" と "u3" ) の両方によって確認される必要があります。関連付け インターフェースのメソッド isConfirmedBySourceOwner と isConfiremedByTargetOwner は、sourceObject と targetObject の両方の確認状態へのアクセスを提供します。3 つ目の便利なメソッドである isConfirmed は、関連付けが完全に確認されているかどうかを判断するメソッドを提供します。外部関連付けの確認状態に関連する可能性は次の 4 つになります。

• 関連付けは、sourceObject の所有者によって確認されておらず、targetObject の所有者によっても確認されていません。
• 関連付けは sourceObject の所有者によって確認されていますが、targetObject の所有者によって確認されていません。
• 関連付けは sourceObject の所有者によって確認されていませんが、targetObject の所有者によって確認されています。
• 関連付けは sourceObject の所有者によって確認され、targetObject の所有者によって確認されています。これは、関連付けが完全に確認されている唯一の状態です。