注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
インターフェースリンクタイプは、インターフェースを実装するすべてのオブジェクトタイプに共通するオブジェクト間の関係を定義します。ユーザーは、インターフェースリンクの説明と、コードでリファレンスとして使用するためのインターフェースリンクタイプのAPI名を指定できます。オブジェクトがインターフェースリンクタイプを持つインターフェースを実装する場合、インターフェース上のすべてのインターフェースリンクタイプは、オブジェクトタイプ上の具体的なリンクタイプを利用したものになります。オントロジーの変更は、関連するリンクタイプの制約で指定されたパラメーターに具体的なリンクタイプが一致していることを検証します。
上記の例に示されているように、施設とそれが提供する航空会社との関係をモデル化するには、Facility
インターフェースが、Facility
インターフェースを実装する任意のオブジェクトと Airline
オブジェクトタイプとの間に、オプションの1対多リンクタイプ制約を宣言します。これは、実装するオブジェクトタイプ(たとえば、Airport
)が Airlines
オブジェクトタイプに対して具体的なリンクタイプを持っている場合、そのリンクはインターフェースリンクタイプのAPI名を通じてアクセスできることを意味します。
リンクタイプ制約は、インターフェースリンクタイプのパラメーターを定義します。リンクタイプが必須である場合、すべての実装オブジェクトタイプはこれらの制約を満たすリンクを持たなければなりません。これらのパラメーターには以下が含まれます:
2つの抽象的なオブジェクトタイプ間の関係をモデル化したい場合、インターフェースリンクターゲットを使用するべきです。
たとえば、Facility
と、発生する Alert
の関係をモデル化するためにインターフェースリンクターゲットを使用できます。施設の種類や警報の種類が複数あるため、リンクの各端に単一のオブジェクトタイプしか使用できない場合、その接続をモデル化することは不可能です。代わりに、Facility
インターフェース、Alert
インターフェース、および Alert
インターフェースへのリンクを設定した Facility
上のインターフェースリンクを定義することにより、この関係をモデル化できます。その後、Facility
インターフェースを実装する Airport
オブジェクトタイプと、Alert
インターフェースを実装する Flight Alert
オブジェクトを定義できます。そこから、Airport
から Flight Alert
への具体的なリンクタイプを定義して、Facility
インターフェースのリンクタイプを満たすことができます。
インターフェースとターゲット間の関係が具体的であり、リンクタイプの制約によってその特異性が強制される場合、オブジェクトタイプリンクターゲットを使用するべきです。
たとえば、Facility
インターフェースを定義し、Airlines
オブジェクトタイプにリンクすることができます。このインターフェースリンクは、施設タイプが何であれ、提供する特定の航空会社へのリンクを持つことが期待されるという事実をモデル化します。
インターフェースリンクタイプは、さらに ONE
または MANY
のカーディナリティを指定できます。これらのカーディナリティはそれぞれ、インターフェースリンクタイプが関係の左側にある場合の1対1および1対多のモデリングに類似しています。ONE
のカーディナリティは、具体的なオブジェクト(オブジェクトタイプの行)が正確に1つの他の具体的なオブジェクトにリンクすることを示します。MANY
のカーディナリティは、具体的なオブジェクトが1つ以上の他の具体的なオブジェクトにリンクを持つことができることを示します。
ユーザーのオントロジーのモデリングニーズに基づいて、ONE
または MANY
のどちらを使用するかを決定する必要があります。場合によっては、リンクのカーディナリティを単一のオブジェクトに制限する方が理にかなっているかもしれません。たとえば、Driver's License
と Person
の関係を単一のカーディナリティリンクとしてモデル化したいかもしれません。なぜなら、任意のライセンスは単一の具体的な個人にしか属さないからです。関係がより柔軟であることを許可する場合、たとえば Company
とその Shareholders
のように、任意の会社が1つ以上の具体的な株主を持つことができることを示すために MANY
のカーディナリティリンクを使用したいかもしれません。