CIDOC Conceptual Reference Model (CRM) の開発を行なっている Special Interest Group のミーティングに参加してきました。 このページでは、ミーティングの内容を報告します。 文中の (Issue ??) という表記は、CIDOC CRM Issue リストの中の、 該当する Issue の番号です。
内容は以下のとおり。
新しい参加者のために Martin Doerr による CRM の一般的な紹介がなされました。
デジタルデータのメタデータの記述方式としてアメリカで開発が進められている METS (Metadata Encoding & Transmission Standard) についてのプレゼンテーションが Merrilee Proffitt によって行なわれました。 これは、多様なデジタルデータの保存・収集などの目的で開発されているもので、 ファイルのメタデータだけでなく、複数ファイルを組み合わせた情報のメタデータ (Web Site など) も表現できるように工夫されています。 しかし現在のところ、あまり複雑な構造については充分サポートできていない ようです。
将来的にはアメリカで新しい標準になるかもしれないので、CRM との マッピングが将来行われるかもしれません。
これまでに要望が取りこまれていなかった分野は、自然史博物館が最後になる ということでした。まず自然史博物館でのデータモデリングに特徴的な点について、 Karl-Hainz Lampe から説明があり、続いてディスカッションが行なわれました。
特に問題になるのが動物・植物の分類方法と、特徴の記述だそうです。 (分類用語そのものはシソーラスの問題なので CRM の範囲外です。) まず、種による分類というのは、ある意見にすぎず、分類木は複数 存在しえます。このとき、ある分類 (Taxon) はその分類について 書かれた論文によって同定されます。また、Taxon を作るときには 標本が必要なのですが、これは Biological Object が使えます。
分類が作られるのであれば、Taxon Creation というエンティティを Event のサブクラスとして考え、それが Taxon を作ると 見ればよいのではないか、という提案がなされました。Taxon は Type (Genus や Spieces) を持ち、note (protologue) を 持ち、Authority Document (当該論文) で定義されます。 また Taxon 同士は上位分類・下位分類の関係を持ちます。 標本である Biological Object は Taxon Creation で 使われ、その使われかたによって had original element のサブプロパティ として designated holotype や designated paratype ... などを用意してはどうか、というのが提案です。
また、特徴の記述については、Physical Object から Type へ exhibits general feature を、Physical Feature へ exhibits feature をプロパティとして加えることが提案されました。
Physical Feature が指すのは、例えば「穴があいている」というような 特徴です。ある特定の Physical Object に穴があいている場合は exhibits feature でモデル化し、その種の Physical Object は どの個体であれ穴があいてる、という場合には exhibits general feature でモデル化します。
また Conceptual Creation のサブクラスとして Type Creation を 用意する必要があるかどうかについても議論されることになりました。 また、知的所有権の問題として Conceptual Creation が作る Type が Legal Object のサブクラスとなるべきかどうかについても 議論されることになりました。
実装ガイドライン
(Issue 22)
実装のためのガイドラインの作成が予定されていますが、
これは FAQ リストに組みこまれることになります。
内容は、おおきく分けて次のとおり。
また FAQ リストを作るために、メンバーから質問を集める必要が確認されました。
使い方を教える
(Issue 57)
Martin Doerr と Steve Stead がワークショップを行う予定があるので、
その資料を使って教育用のドキュメントを作ることになりました。
また、その他のワークショップ等の経験も集められるでしょう。
現在の仕様にはエンティティのスコープノートはありますが、プロパティに関する 記述はメモ程度です。現在 108 個あるそれぞれのプロパティにも スコープノートがつけられることになっています。すべてのプロパティについて 一つずつ草稿を検討したので、今回のミーティングで最も時間がかかった部分です。
プロパティのスコープノートの書式が決まりました。
また、E55. Type がわかりにくいので、これについての章を設けること (Issue 50)、 Property の Property に番号をつけ、記述を作ること (New Issue)、 ショートカット機構についての言及を入れること、 などが決まりました。
また、プロパティのスコープノートを検討している間にも、新しいプロパティや 定義の変更、削除などが提案されました。これらの議論をふまえて、 形式を整えたプロパティのスコープノートは次回のミーティングの 3 週間前まで にはまとめられることになっています。
エンティティのスコープノート等について、必要な修正が行われました。 数が多いので、ここでは特に目立った変更のみについて記します。 詳しくは Issue List を参照して下さい。
Transformation
(Issue 12)
物の本質的な性質が変化してしまうような場合のために
(例: ツタンカーメンがミイラに変わる)、
新しいエンティティ Transformation が導入されます。分類の変更が必要でない
ような変化の場合は Modification を使います。Transformation は
Beginning of Existantce と End of Existance のサブクラスです。
イベントのエンティティ名を変える
(Issue 37)
Event のサブクラスのエンティティ名が名詞だと誤解しやすいという意見です。
例えば Production ではあいまいなので、Producing または Production Event
のような名前に変更することが決まりました。
Appellation の値
(Issue 63)
Appellation には文字列の「値」があるべきかどうかという議論について、
Appellation はそれ自体文字列なのだから必要ない、という結論に達しました。
ただし、Alternative Name ではない Name Alternative を記述するために
(日本語の「読み仮名」はまさにこれです)、also represented by という
プロパティが提案されました。
FAQ リスト
(Issue 54)
FAQ リストが作られます。今回のミーティングでも議論の最中に
「これは FAQ になりそうだ」というものが随時挙げられました。
Gender 削除
(Issue 38)
E76. Gender の削除が決まりました。Gender は Type で
カバーすべきものだという判断によるものです。似たような議論として
E33. Linguistic Object に対する E56. Language も削除できるのではないか、
というものがありますが、こちらは合意に達していません。
イベント同士の因果関係
(Issue 45)
イベント同士の因果関係をモデル化するために、いくつかのプロパティの定義を
広げるべきではないか、という意見に対し、因果関係のような恣意的な
情報をモデル化すべきでない、という意見が議論されました。
これについての決定は次回に持ち越しになりました。
used general object
(Issue 47)
E7 Activity から E19 Physical Object を指す P16. used specific object は、
一般的な物体が使われた場合をモデル化できないので、
E55. Type を指す used general object が導入されます。
employed
(Issue 48)
E11 Modification から E57 Material を指すプロパティ
employed (was employed by) の導入が決まりました。
多重インスタンス化の制限
(Issue 66)
CRM ではあるインスタンスが複数のエンティティのインスタンスであることが
許容されますが、Stuff と Temporal Entity のような無意味な組み合わせが
ありえます。そこで、多重インスタンス化に関する制限事項を仕様のエンティティの
記述に書きくわえることになりました。
Type 間の関係
(Issue 68)
Type 同士の階層関係を表現するためのプロパティとして、
ISO 2788 (Monolingual Thesaurus) でいうところの BTG と同じ意味を持つ
has broader term (has narrower term) というプロパティが導入されます。
ISO 2788 で使われている他の関連は CRM の Type には必要ないと判断されました。
Information Carrier
(Issue 7)
Conceptual Object とそれを含む Physical Object (例えば本) との関係を
どうモデル化するか、という議論について、Information Carrier で
Iconographic Object を置きかえてはどうか、と提案されました。
拡張ガイドライン
(Issue 23)
CRM は必要に応じて拡張できるよう設計されていますが、拡張のための
ガイドラインを作ることが予定されています。
MPEG7 と FRBR について、CRM とのマッピングのレビューが行われました。
MPEG-7
マルチメディアデータの内容を記述するために MPEG が開発している
MPEG-7 "Multimedia Content Description Interface" との
マッピングについて、Jane Hunter の論文がざっと紹介されました。
FRBR
IFLA (International Federation of Library Associations and Institutions)
が開発した FRBR と CRM とのマッピングを Patrick le Boeuf が行ったので、
それについてレビューがありました。
これらのマッピング作業一般について、Martin Doerr は以下のような コメントをしました。
デモンストレーション用のデータを集めて、データマッチングのデモを作ること。 デモ用データは、Anne Hume、Karl-Heinz Lampe、Cristial-Emil Ore、 Matthew Stiff がそれぞれ提出することになりました。
次回のミーティングまでに、これまでの議論をとりこんだ新しいバージョンの仕様 (Version 3.3) がまとめられます。
次のミーティングは 7月上旬にコペンハーゲンで行われる予定です。 これまでで、すべての種類の博物館に必要なモデルを取り込んだので、 次回のミーティングでは CRM の論理構造が最終的に決定されます。 それ以降は原則として仕様の変更はされません。 また CRM の解説や利用法についてのさらなる文書が用意されることになっています。
