Implementing the CIDOC Conceptual Reference Model in RDF_0.pdf
CIDOC CRM は 「プロパティのプロパティ」を許している。いわゆるロール概念に相当するようなサブプロパティの動的な生成である…という解釈も実は私の勝手なものであり、CIDOC としても RDF へのマッピングについては定まってはいない。ただ、「こうすればいいのではないか」と書いている文章があるので、それを翻訳する。
Properties of properties
As mentioned above, RDF does not support properties of properties. Therefore, users are recommended two ways to work around:
The current properties of properties in the CRM have all as range “E55 Type”. Therefore they correspond to subtyping of the respective property by a local vocabulary.
For the cases in which the local vocabulary is not fixed, there is a recommended form of reification via an auxiliary “property class”. This replaces the former recommendation to use E13 Attribute assignment in order to introduce user defined property types.
The two solutions have pros and cons with respect to query performance, user interface programming and flexibility to cater for a local, evolving terminology.
Solution A:
Users that have fixed vocabularies of property types for those properties foreseeing in the CRM a “type” or “Pxx.1” property, may transform these types into their own subproperties for the respective CRM properties, such a as "P3 has note":
Instead of P3 has note (P3.1 has type : parts description) declare
<rdf:Property rdf:about="P3_parts_description"> <rdfs:domain rdf:resource="E1_CRM_Entity"/> <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/> <rdfs:subPropertyOf rdf:resource="P3_has_note"/> </rdf:Property>
This ensures that a graph using these subproperties can consistently be retrieved via their superproperties. In other terms, a system using this solution a) is query compatible with the CIDOC CRM without using properties of properties in the query and b) it ensures that typing a property instantiates the base property and therefore the complete graph is contained in the respective query answer. It is the most efficient implementation, both in terms of query performance and storage overhead. User interface programmers should query these additional subproperties and create at run-time selection lists of them, rather than hard-coding the vocabularies. If such extensions are widely built, they can reveal an emerging good practice and become subject to a standardization of its own. The drawback is that the vocabulary must be loaded to database platform before-hand, and this mechanism only applies to types of properties. It is the preferred solution.
In case users have no other choice than to deal with open vocabularies of property types, or would need extensions with properties of properties other than types, they should resort to solution B. This solution uses “property classes”, i.e., representing an n-ary property by an auxiliary RDF class, which are provided together with the CRM RDF Schema[12]. This solution is logically adequate and further extensible, but is more complex with respect to query formulation, has considerably slower query response times in current knowledge base platforms than the above and more storage overhead. It is more obvious for user interface programmers to create the respective selection lists, and users may introduce new types at runtime.
プロパティのプロパティ
上述したように，RDFはプロパティのプロパティをサポートしていません。そのため、ユーザーには対処として以下の２つの方法が推奨されます。
- 現在、CRM のプロパティのプロパティは、レンジとしてすべて "E55 Type "を持っています。そのため、独自語彙によるプロパティのサブタイプ化に対応しているということができます。
- 独自語彙が規定できない場合には、補助的な"プロパティクラス"を介して具体化（reification）することを推奨します。これは、ユーザ定義のプロパティ型を導入するために
E13 Attribute assignmentの割り当てを使用するという以前の推奨に取って代わるものです。
2つの対処は、クエリの性能、ユーザインタフェースのプログラミング、個別に進化する用語に対応できる柔軟性に関して、長所と短所があります。
解決策 A：プロパティタイプの固定語彙（以下の例では parts description）を持っているユーザは、CRM 内で「type」または「Pxx.1」プロパティを想定しているプロパティ（以下の例では has note）のタイプを、そのサブプロパティであり独自のものに変換することができます。
P3 has note（P3.1 has type : parts description）という CIDOC の記法の代わりに、以下のように宣言します。
<rdf:Property rdf:about="P3_parts_description"> <rdfs:domain rdf:resource="E1_CRM_Entity"/> <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/> <rdfs:subPropertyOf rdf:resource="P3_has_note"/> </rdf:Property>
これにより、これらのサブプロパティを使用したグラフは、それらのスーパープロパティを介して一貫して検索することができます。言い換えれば、この対処法を使用するシステムは、a) クエリでプロパティのプロパティを使用せずにCIDOC CRMとクエリにおける互換性があり、b) プロパティをタイプ付けすると元のプロパティがインスタンス化されるため、完全なグラフがそれぞれのクエリの回答に含まれていることを保証します。これは、クエリのパフォーマンスとストレージの余分な消費の両方の観点から、最も効率的な実装です。ユーザインターフェースのプログラマーは、語彙をハードコーディングするのではなく、これらの追加のサブプロパティを検索して、実行時に選択リストを作成する必要があります。このような拡張機能が広く構築されれば、新たなグッドプラクティスを発見し、それ自体が標準化の対象となる可能性があります。欠点は、語彙を事前にデータベースプラットフォームにロ読み込まなければならないことと、このメカニズムはプロパティのタイプにのみ適用されるという点です。ともかく、基本的には、こちらが好ましい対処法です。
ユーザがまだ決まっていないプロパティタイプの語彙に対応する必要があるときや、タイプ以外のプロパティのプロパティを拡張する必要があるときには、対処法Bに頼る必要があります。この対処法では、CRM RDF スキーマと一緒に提供されている"プロパティクラス" PC0_Typed_CRM_Property 、つまり n-ary のプロパティを補助 RDF クラスで表現したものを利用しています。この対処法は論理的には適切であり、さらに拡張性もあるが、クエリの作成が複雑になり、現在の知識ベースプラットフォームでは対処法Aに比べてクエリの応答時間がかなり遅く、ストレージの余分な消費が大きい。ユーザインターフェースのプログラマーがそれぞれの選択リストを作成する必要性はより明白であり、ユーザーは実行時に新しいタイプを導入する可能性がある。
簡単に言うと、
A: サブプロパティとして新しいプロパティを定義する
- クエリ作りやすい
- クエリの実行速度は速い
- 余分なデータの発生無し
B: プロパティクラスのインスタンスとして新しいプロパティを定義する
- 事前にプロパティを詳細化する用語のリストを用意する必要が無いので作成できるプロパティの自由度が高い
- タイプ以外のレンジをもつプロパティのプロパティにも適用可能
- 論理的に正確な表現である
Aを使えるときはAを使え。ちなみに How to model Roles in the CIDOC‐CRM RDF encoding というスライドに対処法Cとして、主語となるエンティティの P2 has noteに説明として、そのプロパティの詳細を書いておくという手法が書かれている。その pros cons を私なりにまとめると、
C: 主語に説明としてプロパティの詳細を記述する
- 〇 クエリも簡単、プロパティの詳細も自由に書けるので自由度も高い
- × 説明文は自然言語なので「あるキーワードを含むようなプロパティの詳細」みたいなのを条件にクエリにしようとすると、クエリのパフォーマンスが悪い
- × 対象の主語に繋がっているプロパティが多いと、どのプロパティを詳細化しているのかは説明をよく読んでグラフと照らし合わせないと分からない
