| 目次 |
CIDOC Conceptual Reference Model (CRM) は、 国際博物館会議 (International Council of Museums, ICOM - 日本語ページ) の専門委員会である ドキュメンテーション委員会 (International Committee for Documentation, CIDOC) によって設けられた CIDOC CRM Special Interest Group が開発を進めているドキュメンテーション標準です。 CIDOC は、これまでにも 「博物館資料情報のための国際ガイドライン : CIDOC 情報カテゴリ」 (International Guidelines for Museum Object Information: The CIDOC Information Categories, 1995) や 「CIDOC リレーショナル・データモデル」 (CIDOC Relational Data Model,1994) を開発してきていますが、この CRM はそうした活動の上に連なるものです。
「ガイドライン」はコンピュータを前提としてはいませんし (紙ベースも範囲内になっている)、記録すべき情報の種類についての ガイドであるので、基本的には誰でも理解できるものだと思います。 また、博物館・美術館でデータベースを構築しようとした経験のある方なら、 おそらくリレーショナル・データベース (RDB) は馴染みのあるものでしょうから、 「リレーショナル・モデル」も (多少ややこしくはあるものの) 理解しやすいと思います。
しかし、CRM はおそらくずっと理解しにくいのではないでしょうか。 「オブジェクト指向」とか「オントロジー」とか、あるいは XML や RDF などという技術も関係ありそうだし、相当コンピュータの専門知識が ないとまともに理解できそうもない、と感じておられる方も多いかと思います。 そこで、このページでは自分なりに理解している範囲で、極力わかりやすく CRM を紹介したいと思います。目標は、これを読めばあとは仕様を眺めながら モデリングの作業を楽しめるようになる、ということです。
なお、このページの内容は CRM の仕様書の Version 3.2 (July 2001) に もとづいています。
CRM が「ガイドライン」や「リレーショナル・モデル」、あるいはその他の データ標準 (例えば Getty Research Institute の CDWA ) と根本的に違うのは、「どの情報が記録されるべきか」ということについては 直接は言及していないということでしょう。基本的に、CRM は「すでにデータベース が存在しており、ともかくそれが動いている」という事が前提になっています。 そして、それぞれのデータベースに入っているデータを交換したり、 統合したりするための枠組を提供することが、主な目的なのです。 確かに CRM の仕様を見ると、Title や Birth などという文字が 見えるので、これらを記録すべきだとしているかのように見えるかもしれませんが (そして「これでは項目が細かすぎて、とても対応できない」と思ってしまうかも しれませんが)、そうではありません。 ですから、これを元にしてデータベースと作るとか、RDB のテーブルの レイアウトの元にするとかいうものではないと理解した方が良いでしょう [1]。
世の中にはすでに様々な博物館向けの「データ標準」というものがありますが、 それらは世界中のデータを交換したり統合したりするほどには完全でもないし、 普及してもいません。それぞれの分野や個々の博物館には、独自のニーズが ありますし、どうしても個別に違ったものになってしまいます。 記録している項目の数や名前などが館ごとにばらばらになっているでしょう。 そのような状態でデータを交換したり統合したりするには、いくつかの方法が 考えられます。 一つの現実的な方法としては、最小限共通な情報を抽出するという考え方でしょう。 「この項目はどのデータベースでもだいたいフォローしているだろう」と 思われるもの (「作者」とか「タイトル」のようなごく基本的な情報) を共通項目として使うという考え方です。
しかし、CRM はこれとはまた別の方法を取っています。 「オントロジー Ontology」といわれるものがそれです。詳しくは後述しますが、 基本的なアイデアは、すでにあるデータベースからデータを取り出すときに、 オントロジーを利用した共通のデータ形式に変換すれば、データの統合・交換が 自動的に実行できる、というものです。しかも最大公約数的な方法と違って、 データ項目が減るようなことはありません。後でみるように、オントロジーは データ同士の関係を記述することで、元のデータ項目をいわば一旦「ほぐす」ため、 こういう中間形式に向いているといえます。また、必要があれば CRM 自体を 拡張することも可能です。このとき CRM の拡張されたバージョンは、 元の CRM と互換性を保つことができます。
オントロジーそのものは、データ間の関係を定義するだけですから、 特定の記述形式にとらわれません。 XML や RDF が関係してくるのは、これを実際に (図や文章でなく) データとして 記述する時にそれらが使えるからです。また同様に、CRM は データ入力や検索、通信の具体的な方法とは関係しません。 例えば CRM の応用として複数のデータベースを串刺し検索する ということが考えられますが、その際の問い合わせ言語に CRM を 組みこんで使うことはできるかもしれません。 しかし CRM そのものがそうした機能を持っているわけではありません。同様に、 通信プロトコルやその他の技術的な問題は、CRM とは別の話になるでしょう。 CRM はあくまでデータの (どちらかといえば抽象的なレベルの) モデルなのです。
また、CRM は博物館資料の情報を主な対象としています。 博物館の資料は非常に多様であるため、かなり一般的な目的にも適用できそうですが、 やはり博物館での資料管理などには重きがおかれています。他のデータ標準との 相互乗り入れにもかなり注力されていますが、これはやはり博物館情報を 他のデータでうまく補ったりするためでしょう。
実際にデータをマッチングさせることを考えると、用語の問題が必ずでてきますが、 これも CRM の直接の対象ではありません。しかし、ある用語が 「用語辞書やシソーラスに基づく情報」であることを示すことは可能です。 おそらく、現実的には Getty の Vocabulary Databases を使ったり、その他の似たようなツールを組み合わせて 使うことになるのではないでしょうか。
まず、哲学でいふところの「存在論」のことは忘れましょう (よく知らないし)。
ここでいうオントロジーは哲学用語ではなくて、人工知能や
「知識表現 Knowledge Representation」とか「知識工学 Knowledge Engineering」
とかいわれる分野で 90 年代以降注目されてるものです。
知識を記述するための基本概念のセットのこととされているのがオントロジーで、
大きくわけて手続きに関わる「タスク・オントロジー」と対象領域に関する知識に
関わる「ドメイン・オントロジー」とに分けられます。CRM は後者の
ドメイン・オントロジーであることが、仕様にも明記されています。
オントロジーの具体的な形にはいろいろな定義があるようなのですが、
ここでは CRM に沿って説明します。
ドメイン・オントロジー (以降、単にオントロジーと書きます) は、 対象領域 (ここでは博物館) で使われる概念と、その概念の属性や概念同士の関係、 さらにそれらの関係に対する制約で構成されます。 CRM では、対象領域で使われる概念をエンティティ (Entity)、 関係をプロパティ (Property) と呼んでいます [2]。 例えば、CRM のエンティティには Person や Man-Made Object や Production などがあります。また、プロパティには was produced by や carried out by などがあります。 エンティティは概念ですから、現実の世界には対応する具体的な対象があります。 例えば、私という個人は Person というエンティティの具体例です。 このような具体例のことを、インスタンス (Instance) と言います。
それでは、工芸作品を例に簡単なモデルを作ってみましょう。 「草花鳥獣文小手箱の作者は松田権六である」という情報を CRM のモデルにする ことを考えます。この文には Man-Made Object のインスタンスである 「草花鳥獣文小手箱」と Person のインスタンスである「松田権六」が 現われています。そして「作者」である、ということの背後には 「小手箱の制作」という Production のインスタンスがあります。 (表1)。
| エンティティ | インスタンス |
|---|---|
| Man-Made Object | 草花鳥獣文小手箱 |
| Production | <<草花鳥獣文小手箱の制作>> |
| Person | 松田権六 |
次に、これらのエンティティ同士を、その関係を意味するプロパティで 関連づけます。図式化すると、図1 のようになります。
was produced by (has produced) の括弧内は、そのプロパティ を逆から 辿った場合の名前です。CRM ではほとんどのプロパティ に 2 つの名前があります。 図1 の左部分は「草花鳥獣文小手箱 was produced by <<草花鳥獣文小手箱の制作>>」のように読み下せます。 逆に読めば、「<<草花鳥獣文小手箱の制作>> has produced 草花鳥獣文小手箱」となります。
このように、エンティティをプロパティ で結びあわせていくことで、 意味のネットワークを作っていくのです。 「作者」のようなストレートな表現でないので、 ちょっと奇妙に思われるかもしれません。普通、単に「作者」というとき、 その背後には「人物が制作という行為を実行し、その行為の結果物体ができた」 という関係が想定されています。「作者」を「製作者」や「生産者」と呼んでも、 この関係は同じです。このように一旦データ項目を「ほぐす」ことで、 個々のデータをそれぞれの概念の関係の網の目の中に配置するのです。 これによって、データが持つ意味を表現することができます。 「セマンティック・ネットワーク」などとも呼ばれますが、 データに意味表現が与えられれば、コンピュータは機械的な推論によって 情報に関する判断を行なえます。 多様なデータの統合を実現するための方法としては、的確な戦略といえるでしょう。
CRM のようなドメイン・オントロジーでは、意味表現に必要なエンティティと プロパティを定義します。仕様書の Version 3.2 では、77 のエンティティと 108 のプロパティが定められています。すべてのエンティティについて、 それぞれの定義や、エンティティがもちうるプロパティなどにが記述されています。
少し細かい話になりますが、「松田権六」という文字列は Person のインスタンスではなく、Appellation (呼称) という エンティティのインスタンスです。厳密には Person のインスタンスは 人間であって、文字列ではありません (図2)。
しかし、インスタンスをそれぞれ識別する必要がある場合 (他の Person と区別する必要がある場合) 、それぞれのインスタンスには識別用の文字列である 識別子 (Identifier) が必要です。 Appellation になる文字列は、しばしばインスタンスの識別子として 使われるので、そのような場合、図2 のように いちいち Appellation を記述するのは冗長なので、このページでは 省略して図1 のように記述します (ただし、実際の識別子の形式についてはソフトウェアの実装の問題になるので、 CRM では特に定めていません)。
また、Appellation はいわゆる名前である必要はなく、コンピュータの 内部コードや、RDB で使うようなインデックス (例えば「個人ID」) でも かまいません。 例えば RDB において、表2 のように一人の個人が 複数の名前をもっている場合は、 図3 のようにモデル化されるでしょう。 「00023」も「葛飾北斎」も「画狂人北斎」も「北斎宗理」も、すべてその人物の Appellation になりえます (図では識別子として「00023」を使っているので、 Appellation としての記述は省略しています)。
| 個人 ID | 名前 |
|---|---|
| 00023 | 葛飾北斎 |
| 00023 | 画狂人北斎 |
| 00023 | 北斎宗理 |
さて、松田権六の例に戻って、今度はこのモデルにもう少し情報を追加してみます。 図1 を元に情報を追加したのが 図4 です。
小手箱には 2 つの番号 (学生制作品番号と目録番号) が割りあてられており、 「大正八年三月卒業生 松田権六作」という銘が入っています。 制作年月日、金研出蒔絵という技法、卒業制作として 作られたことなどについても追加されています。このように、次々と 情報をエンティティとして追加し、プロパティでつないでいけば、 モデルができあがります。 この例でも、さらに松田権六の生没年や、小手箱の寸法、描写されている動物、 材料などについても、もちろん加えていくことができます。
図4 では Time-Span に識別子が ついていませんが、このような無名のインスタンスもありえます。また、ここにある 情報だけについても、さらに詳細化することも可能です。例えば、 Inscription には has language (is language of) というプロパティ があり、それは Language というエンティティを指します (この場合 Language のインスタンスは "ja" になりますね)。
ここでは一つの作品を例にしてモデル化しましたが、もしデータベースがあるなら、 そのデータベースのデータから CRM モデルに自動的に変換するような ソフトウェアを作ることになるでしょう。この時必要なのは、データベースからの 変換パターンですが、この変換パターンをマッピング (mapping)と言います。 どのエンティティやプロパティ を使うかは、仕様書その他の ドキュメントを読んで検討するのですが、すでに行われている マッピングに関するドキュメントも多いので、かなり参考になると思います。
マッピングはたいていの場合、表形式のリレーショナル・モデルから CRM モデルへ という形になるでしょう。例えば、小手箱は表3 のように なっているかもしません。
| 目録番号 | 学生制作品番号 | タイトル | 制作年月日 | 作者 | 技法 | 銘 |
|---|---|---|---|---|---|---|
| 487 | 3103 | 草花鳥獣文小手箱 | 1919/06/17 | 松田権六 | 金研出蒔絵 | 大正八年三月卒業生 松田権六作 |
表形式で 1 行になっているものを、1 列ずつ取りだして関係づけていくと 図4 のようなモデルになることが おわかりいただけると思います。
ここまでの説明に、すでにオブジェクト指向についての説明が含まれています。 オントロジーは、「オブジェクト指向」という考え方・方法論に強く 影響されています。別の言い方をすれば、オブジェクト指向的な考え方を使って 「知識」を表現するための方法がオントロジーなのです。
現在、一般に「オブジェクト指向」という言葉はプログラミングや ソフトウェア設計といったソフトウェア工学の用語として使われています。 ソフトウェア工学で言う「オブジェクト指向プログラミング」や 「オブジェクト指向設計」というのは、基本的にソフトウェアを作る ためのもので、動的な側面が大変重要になってきます。 一方、CRM のような知識表現においては、データ同士がどのような関係にあるのか、 という構造的な側面が中心です。ですから同じオブジェクト指向といっても、 微妙な違いがあります (オブジェクト指向プログラミングの経験がある方は、 これまでの説明でその違いに気づかれていると思います)。 それでも、両者には共通する点も非常に多くあります。 エンティティとプロパティ、インスタンスもそれぞれオブジェクト指向的な 概念なのですが、より「オブジェクト指向らしい」考え方に、 「階層」や「継承」があります。
エンティティは概念です。CRM のエンティティには Event、Stuff、 Actor、Person、Place、Birth、 Information Object などなど、Version 3.2 で 77 個あります。 これらが、博物館資料を記述するのに必要であろうと思われている概念なのです。 ところで、これらの概念の中には似たものがあります。例えば、 Actor と Group と Person は、どれも 「何らかの活動をする主体」という意味で似ているので、まとめることができます。
分類するだけでなく、同じ種類のエンティティがもつ共通の特徴を抽出することで、 「より一般的なエンティティ」を考えることができます。あるいは逆に、 あるエンティティから「より特殊なエンティティ」を考えることもできます。 例えば、Condition Assessment と Identifier Assignment と Measurement と Type Assignment は、それぞれ何かしら 資料の属性を記録するための活動です。そこで Attribute Assignment というより一般化されたエンティティを考えることができます。 これを汎化 (generalize) といいます。 逆に Condition Assessment は Attribute Assignment を特化 (specialize) したものと言えます。 あるエンティティを汎化したエンティティを、そのエンティティの スーパークラス (superclass)、特化したエンティティを サブクラス (subclass) と呼びます。
汎化と特化は次々と連鎖させることができます。Attribute Assignment は Measurement などのスーパークラスであると同時に、 活動一般を表わす Activity のサブクラスです。 Activity のスーパークラスは Event で、さらに そのスーパークラスは Period 、そのスーパークラスは Temporal Entity、という具合に階層化されて、木構造を作っていきます (図5)。 そして Temporal Entity のスーパークラスは CRM Entity という、 CRM のエンティティのうちで最も抽象的・一般的なものになっています。 CRM Entity は、そこからすべてのエンティティが派生する、 いわば木構造の「根」にあたるエンティティです。
エンティティとエンティティを関連づけるのがプロパティですが、 これは言いかえれば、プロパティはエンティティの属性だということです。 例えば Period には took place at や has time-span のようなプロパティがありますが、これは Period がある特定の場所と 期間に起きたということです。 それぞれのエンティティがもちうるプロパティは仕様で定義されています。
では Period のサブクラスである Event はどうでしょう。 「サブクラスである」ということは、Event は Period の一種であるということです。従って、Period が持ちうる属性はすべて Event も持ちうるはずです。Event には Period と 同様それが起きた場所と期間があるので、took place at も has time-span も持つことになります。 このように、サブクラスはスーパークラスのプロパティをすべて引き継いでいます。 これを継承 (inheritance) といいます。 逆に、Event は Period を特化したものですから、 Period にはなかったプロパティを持っています。例えば had participants は Event にあって Period にはない プロパティです。
Event のサブクラスである Activity は、 やはり Event のプロパティをすべて継承しています。ということは つまり、Period のプロパティもすべて継承しているのです。 表4 にこの関係をまとめてみます (ここに挙げたプロパティは一部です)。 スーパークラス - サブクラスという関係は、つまりはこのようなプロパティの 継承関係のことなのです。
| Period | Event | Activity |
|---|---|---|
| took place at has time-span |
took place at has time-span had participants |
took place at has time-span had participants has specific purpose |
継承の仕組みによって、例えば、より抽象的なレベルで検索したときに 下位のレベルものを含む答えを得ることなどができます。具体的には、 Mark を検索したときに、サブクラスである Inscription の インスタンスも取り出せる、というように。
あるエンティティがそのスーパークラスとなるエンティティのプロパティを すべて引き継ぐというのが継承のしくみですが、スーパークラスはつねに 一つしかないわけではありません。エンティティによっては、複数の スーパークラスを持つこともあります。
例えば Production は物の制作という出来事を指すエンティティです。 Production は物の加工を指す Modification のサブクラスですから、 Modification のプロパティを引き継いでいます。一方で、 Production は Beginning of Existence のサブクラスでもあります (図6)。 Beginning of Existence は名前の通り存在の始まりを指します (Beginning of Existence のサブクラスには他に Birth などが あります)。Production は従って、Beginning of Existence のプロパティも引き継ぎます。別の言い方をすれば、Production は Modification と Beginning of Existence の両方の特徴を 合わせもっている、とも言えます。
このように複数のエンティティをスーパークラスとするような継承関係を 多重継承 (multiple inheritance) と言います。これによって、 あるエンティティが複数の側面・特徴をもつような場合も うまくモデル化することができます。
エンティティが複数のスーパークラスを持つことができるのと似た機構として、 多重インスタンス化 (multiple instantiation) があります [3]。 これは、あるインスタンスが複数のエンティティのインスタンスでありうる、 というものです。例えば、ケースに入った蝶の標本は Man-Made Object であると同時に Biological Object でもあります。
多重継承と違って、多重インスンタンス化については、どのエンティティ同士が 多重インスタンス化を起こしうるのかについては定義されていません。 多重インスタンス化によって、あるインスタンスがどのエンティティの インスタンスなのかについて悩む必要はなくなりますが、実装は面倒になる ことが予想されます。それでも、CRM の目的は情報の取り出しや コミュニケーションなのだから、適切である可能性のある機構は取り入れるべきだ、 と考えられているようです。 (これは、「何も言わないくらいなら、間違ったことを言ったほうがまし」 という立場だと言えます。)
ここまではエンティティの階層について説明してきましたが、CRM では プロパティも階層化されています。あるプロパティを汎化したものを スーパープロパティ (superproperty)、特化したものを サブプロパティ (subproperty) といいます。 図7 に例を示します。図中の P1 や P47 は プロパティ番号で、仕様で定められています。
Appellation へのプロパティ P1:is identified by は、 最上位のエンティティ CRM Entity のプロパティなので、 すべてのエンティティに継承されています。Physical Stuff にも そのサブクラス Physical Object にも継承されています。 そして 図7 にある Object Identifier は Appellation のサブクラスで、資料を一意に識別するもの、例えば 資料番号のようなものです。Physical Object は、 この Object Identifier で識別されることがあるので、両者をつなぐ プロパティが必要です。図7 の P47:is identified by がそうです。そしてこの P47:is identified by は P1:is identified by のサブプロパティです。P47 は P1 の特別な場合、つまり特化したものになっているのです。どちらも "is identified by" というプロパティですが、別々のプロパティです。 このように、あるプロパティのサブプロパティは、典型的には それが指すエンティティのサブクラスへのプロパティという関係にあります。
Physical Object と Object Identifier をつなぐプロパティには もう一つ P48:preferred identifier is があります。 Object Identifier のうち、好ましいものを指すプロパティです。 これは、P47:is identified by のサブプロパティです。 従って P47 は P48 のスーパープロパティということになります。
プロパティは、それ自体さらにプロパティを持つことがあります。 例えば、carried out by (performed) は Activity と Actor を結ぶプロパティですが、それ自体 in the role of という プロパティを持ちます。in the role of が指すのは、Type です。 これを使って、ある Activity を実行した Actor の役割を モデルに組み込みます。
図8 では「Mies van der Rohe は バルセロナ・チェアの制作を実行したが、その役割は Designer である」という 情報をモデル化しています。
CRM でモデリングをする上で、是非とも理解しておきたい機構があと 2 つあります。 「ショートカット」と「Type」です。
CRM が「意味ネットワークを形成する」というとき、この「ネットワーク」が 意味するところは何でしょうか。まずは図9 を見てください。
Phisical Stuff を Condition Assessment で査定し、 その結果を Condition State として記録する、というのが Condition Assessment からのびている 2 つのプロパティの 意味するところです。このことは、Physical Stuff はこれこれの Condition State にある、ということと同じです。後者を示しているのが has condition です。
「標本の状態を査定した。査定の結果は良好。」≡「標本の状態は良好。」
エンティティ同士が他のエンティティやプロパティを経由して関連を もっているとき、その経路をパス (path) といい、 あるプロパティが別のパスと同じ意味を持つとき、そのパスの ショートカット (shortcut) であるといいます。 エンティティ同士の関連がこのようにして網の目状になっていくため、 「ネットワーク」と呼ばれるのです。
ショートカットの仕組みによって、同じ情報に対して複数の表現が可能になります。 またショートカットによって情報の詳細さの度合 (粒度などとも言うようです) を 変化させることができますから、データ交換に有益な重要な機構の一つと言えます。 例えば、博物館 A のデータ項目に「査定」がなくて「資料」と「状態」の 関連があるだけだとしましょう。博物館 B には「資料」と「査定」の関連、 「査定」と「状態」の関連があって「資料」と「状態」の関連がなかったとします。 このとき、ショートカットを使えば互いのデータを交換することができます。 (もちろん、博物館 A から博物館 B へデータを移す場合には、「査定」の項目を 何らかのデフォルト値で埋める必要があるでしょう。)
Type はエンティティの一つですが、ある意味でとても特殊な エンティティです。仕様の Types Hierachy の項には次のような記述があります。
This hierarchy does not belong to the CIDOC Entities in the proper sense, as its instances are names for aggregations, sets, or undefined masses of physical items or intellectual constructs.
(この階層は正式な意味では CIDOC エンティティに属していない。それは、 そのインスタンスが集合体、セットまたは未定義の物理的物品の集合、 あるいは知的な構成物、などの名前であるからである。)
CRM Entity には (つまり全てのエンティティには) has type というプロパティがあります。これが指すのは Type なのですが、エンティティごとに違う Type を指すことになっています。 Activity の has type が指すのは Activity Type であり、Title は Title Type、Person は Person Type … というように、エンティティは それぞれ固有の Type を持ちます。このような、それぞれの エンティティから導かれる Type は仕様には特に書かれていません。 それ以外の Type のサブクラス (Material など) だけが 仕様に明示的に書かれています。
Type の使い方の例を見てみます。 例えば測定された値を示す Dimension というエンティティがあります。 図10 は「長さ 1800 mm」をモデル化しています。 値を Number、単位を Measurement Unit で示すほかに、 この Dimension が長さであることを示す必要があるので、 Dimention Type で示しています。このように、 情報の内容をより正確に確定するために Type を使うことができるのです。 ちなみに Measurement Unit は仕様に明示されている Type のサブクラスの一つです。
見方によっては、Type は何でも入れてしまえる便利なエンティティです。 しかし Type に使われる言葉は、シソーラスなどで明確に定義されたものや、 特定の集団、領域で互いに承認されたものあるべきです。 そうでなければ、意味を正しく解釈することができません。
実は CRM のエンティティは、すべて Type なのだということもできます。 "length" が Dimention Type のインスタンスであるのならば、 例えば Production は Activity Type のインスタンスでも ありうるはずです。さらに Activity だって、Event Type の インスタンスだと考えていけない理由はないはずです。このように、 ある概念をエンティティとして導入するか、それとも Type で 扱うことにするか、という判断は実際かなり微妙です。 極端な話、CRM Entity と Type ですべて事足りてしまうではないか、 とも言えるからです。しかし CRM は理論的な考察の対象ではなく、 博物館で実用するために開発されているものですから、 「エンティティにしておいた方が便利だ」という判断しかないのではないでしょうか。
従って、シソーラスなどに現われる概念というのは、CRM でいうところの エンティティになりうるものです。CRM は、数千の可能なエンティティの中から、 慎重に百個程度を選び出したものだと言うこともできるのです。 ここから、Type とエンティティの間に互換性があるということがわかりますが、 この互換性は、おそらくオリジナルの CRM と CRM を拡張したバージョンとの 互換性の基礎にもなると思われます。
CRM は特定のデータ形式からは独立して定義されています。従って、実際に コンピュータでこれを運用するためには、何らかのデータ表現が必要になります。 この際、データ形式は CRM を十分うまく表現できるだけでなく、 広く普及したものが望ましいのは言うまでもありません。そう考えれば、 W3C の勧告になった RDF (Resource Description Framework) が最有力候補になるでしょう。
RDF は Web 上の情報資源のメタデータを記述するための標準的な 枠組みを提供します。 RDF Model and Syntax 仕様 は RDF で情報の記述を行なうためのモデルと構文を定めています。また RDF Schema 仕様 では RDF で使うボキャブラリを記述する方法を定めています。 RDF は Web 上の情報を計算機が理解可能なものにし、単なる全文検索以上の 情報資源の利用を可能にするものとして期待されています。
ここでは簡単な例を示すにとどめて、具体的な RDF の構文等については 他の文献を参照していただくことにします。 " XML to RDF translator program, an easy way to create CIDOC CRM compatible RDF " を参考に、図1 の情報を RDF 構文で記述すると [例1] のようになります [4]。
[例1]
<crm:E22.Man-Made_Object rdf:about="草花鳥獣文小手箱">
<crm:P108B.was_produced_by>
<crm:E12.Production rdf:about="草花鳥獣文小手箱の制作">
<crm:P14F.carried_out_by>
<crm:E21.Person rdf:about="松田権六" />
</crm:P14F.carried_out_by>
</crm:E12.Production>
</crm:P108B.was_produced_by>
</crm:E22.Man-Made_Object>
RDF の理論的背景は CRM と同様の意味ネットワークです。プレーンな XML と XML DTD では CRM モデルの表現には限界がありますが (特にプロパティの制約や エンティティ間の継承関係は DTD ではまったく表現できません)、 RDF と RDFS はずっとうまく CRM モデルを記述できます。 意味ネットワークを基礎にしたこの技術が W3C 勧告になったことは、 CRM の実用化と普及にとって非常に大きな進展であると言えます。
CRM のような意味ネットワークは、人間の直観によくマッチしており、 一旦理解してしまえばモデリングはそれ程難しくありません。しかし一方では だからこそ混乱が起きやすいという側面もあります。 博物館という特定の専門領域での実用が視野に入れられている CRM では、 論理的な整合性や情報表現の完全性もさることながら、 実用上最適なエンティティやプロパティの選択が慎重に行われなければならないので、 現在も盛んに議論が続けられています。
実装を視野に入れれば、まだまだ技術的な細部には面倒な問題が 潜んでいることが予想されます。しかも、CRM はそれ自体で完結したものではなく、 効果的な運用のためには関連技術やツールをフル活用しなければなりません。 特にシソーラス類の整備は、現実の運用には必須の前提となるでしょう。
このページでは、CRM を使ってモデリングをするために必要な知識について 説明しました。博物館の学芸員の方、情報管理担当の方、あるいは博物館向け パッケージの開発者の方は、それぞれのデータベースから CRM への マッピングを行うことになると思われますが、あとは仕様を見ながら 実際の作業を行なうだけでしょう。 ただ、地理情報や時代・時間に関するモデルなどは、CRM 独特の考え方が 必要になる部分ですので、別の機会に詳述できればと考えています。