原文: Stefano Mazzocchi,
"On the Quality of Metadata...,"
from Stefano's Linotype January 16, 2006
翻訳: 村田良二 (MURATA Ryoji)
- <ryoji@cc.rim.or.jp>
2006/04/04: 初版公開
ほとんどの環境では、メタデータ (データについてのデータ) を作成するのに時間費やすことは、あなたの上司によって経験させられる苦痛だというふうにかなりの程度考えられいる。例外はごく稀にしかない: みんなメタデータを書くのが好きで、情熱をもってそれを楽しんでいて、当然の結果として、普通彼らは良い/より良い仕事をする。
私はこうした環境の一つ (図書館) で働き、またそうでないところ (たとえば博物館やその他の教育機関) でも働いているのだが、いつも持ち上がるのが「メタデータの品質」の問題だ。
これは、私がこれまでに聞いた「図書館は博物館よりずっといいメタデータを持っていてうらやましいよ」とか (彼らのデータセットがいかに素晴らしいかを一時間も教えてくれた後で) 「君のコレクションに誤字を見つけたよ ― ああ、わかってる、まだまだたくさんクリーンアップをしなきゃならないね」というような、興味深い言葉につながってくる。
私はメタデータについて語る人々の間にあるパターンを見つけ出すことができずにいたが、心の奥では何かがみんなを繋いでいると感じていた。ごく最近ベン (ついに私たちのチームに加わった! やった!) と議論を始めるまでは。
しばらく前にわかったことの一つは、高品質なメタデータをもつ二つ (かそれ以上) のデータセットを結合すると、ずっと品質の低いメタデータをもつ新しいデータセットができるということだ。この品質の「ものさし」は主観的で感覚的なものだが、つねに一定している。私たちが書いているソフトウェアよりもデータのほうを心配している人々にこのことを示すたびに、彼らが期待しているよりあきらかに貧相なデータしかないそんなシステムのことで、私たちがなぜそんなに盛り上がるのか、彼らには理解できないのだ。
私たちはとにかく彼らを落ち着かせるために、よくある「これは単なるプロトタイプだし、データのマッピングはそれほど深く考えずにやったものですよ」とかなんとかいう言い訳を使う。しかしいざ「今回はもっとうまくやる」よう課せられてみると、データマッピングやオントロジー・クロスウォークについてどれだけ熟考するかといったこととは違った一般原則に行き当たってもおかしくないところなのに、と少し奇妙な感じがしはじめた。ベンとの会話は、そのわけを理解するのに役立った。
まず、浮かび上がってくるパターンは確かにあるものの、メタデータの品質についての実践的で客観的な定義が存在しないことに注目することから始めよう。例えば、もっとも表面的なレベルでは、一貫性はきちんとした手入れのしるしと考えられていて、(メタデータ愛好家たちはみんな同意するだろうが) きちんとした手入れはメタデータを良くするものだ。したがって、一貫性の欠如はきちんとした手入れの欠如を示し、そのまま自動的にだめなメタデータをもたらす。
これは確かに三段論法でしかないが、それが合理的であろうとなかろうと、いつも出てくるものだということに注意してほしい。
これはとても重要なことだ。なぜか? そう、たとえば音楽についての二つのメタデータセットがあって、それぞれはとても一貫していて洗練されていたとしよう。最初のものはアーティストの名前を「Beatles, The」とか「Lennon, John」とコード化していて、一方次のものは「The Beatles」や「John Lennon」とコード化している。どちらのデータセットも独立した状態ではとても一貫している: アーティスト/バンドの名前を綴る方法は一つしかない。だが二つが結合されて (明示的であれ暗黙的であれ) オントロジー・クロスウォーク/マップがなされると、ある曲は「Beatles, The」と、別の曲は「The Beatles」と関連付けられるという結果になる。
二つの高品質なデータセットの統合は、一般的に言って、より多くの「量」をもつけれどより低い「質」しか持たない別のデータセットという結果になる。そしてお分かりのように、オントロジー的クロスウォークやマッピングは正しく行われている。ここで「正しい」というのは、オントロジー的等式のどちらの側も「Beatles, The」や「The Beatles」がその歌に関連付けられたバンドの名前であるということを認めているという意味だ。
この点について、同僚のセマンティック・ウェブ開発者は「ふーん、確かにそれはまずいね。同じ URI を使わなかったんだから」と言い、同僚の司書は「ふーん、もちろん、アーティスト名の統制語彙にマップしなかったからだよ。当然でしょう?」と言うだろう…深い部分では、彼らの言っていることは同じだ: 「TheBeatles」や「Beatles, The」を参照するメタデータをさらに共通の、願わくばグローバルに一意な識別子にリンクする必要がある。司書はセマンティック・ウェブの支持者の手を握り、熱烈にうなずいて、彼らは満足するだろう。
残された私はタスクを実装するのだが、それは普通どこかの Web サービスに存在していて、特定の文字列に対して識別子を返すものだ。もちろん、これは眼に見えないプロセスだから (そしてほとんどは何らかの文字列の相違に基づいているので)、なにかまずいことが起きて「Yesterday」が結局「Beatles, The」によって書かれたということになったら、安心して文句をつけられる。もう考えるのをやめて仕事を進めることもできたのだが、しかしもしそういうシソーラスがなかったらどうなるだろう?
私はセマンティック・ウェブの帽子をかぶって、「著者 (author)」は曲に対する弱い逆関数型プロパティとして扱うことができる、と考えた。つまり、二つのデータセットの中の曲名にたまたま一つの重なりがあれば (「Yesterday」が「Beatles, The」と「The Beatles」の両方に書かれたとしよう) そこから他に何も知らなくても「Beatles, The」と「The Beatles」の間に「同一候補」を推論することができる。
この弱い逆関数型プロパティとその結果の「同一候補」は明らかに記述論理ではないので、OWL の一部でもないが、一歩前進ではある: 画面の前に人間を置いて、彼女にすべての「同一候補」を「yes/no」ボタンと一緒に見せれば、それが意味を成すかどうかを決めることができ、それでサイクルは完了する。ソフトウェアは残りの退屈で簡単に計算可能な仕事をやる。
なぜ弱い逆関数型プロパティなのか? それは主に、二つのグループが同じタイトルの曲を書くことが完全に可能だからだ。ほとんどの場合はそうならないとしても。
ここで再び、セマンティック・ウェブの人々はリテラルを URI として扱ってはいけない、したがって、たとえ二つの曲が同じ「タイトル」のリテラルをもつとしても必ずしも同じ曲であるとは限らない、と言うだろう。
だからここで、我々の知っている二つのデータセットは音楽の情報を含んでいて、それぞれ曲とアーティストに異なる識別子をもち、リテラルなラベルに異なる綴りを使い、音楽ファイルに異なるエンコーディング・フォーマットを使っている (だからファイルのハッシュコードを識別子にしてもうまくいかない)。[はい、メタデータ愛好家の皆さん、FRBR のことは知っていますし、それでさらにまずいことになるのも知っています。ただ例としてこれを使っているので、もうちょっと我慢してください]*1
単独では、二つのデータセットはそれぞれとても一貫しているし、そこに多くの時間と費用とエネルギーが注がれている。一緒にすると、たとえ二つのデータセットの持ち主が合意するようなオントロジー/スキーマ・クロスウォークがなされたと仮定しても (そんなものはないけれども、ともかく仮定して)、まるっきり混乱して見えてしまう (特に Longwell のようなファセット・ブラウザで見ると)。
図書館/博物館の世界での標準的な解決法は、混合物に秩序をもたらすような、より高次の分類法 (taxonomy) にマップすることだ。しかし特定のメタデータの分野にはそんなものは存在しないか、あったとしても作成と維持にものすごい費用がかかり、ほとんどその定義によって、そういうもののうちの一つに結びついてしまうと変更するのが非常に困難になる傾向にある。
制御のハブが変更困難であることに対して私は当然アレルギーがあるのだが、利用のライセンスがうまく働くのであれば、そのボキャブラリ/ Web サービスはとても魅力的なものになる。
だがデータセットの統合において認識されるメタデータの品質の下落をいつも高次の典拠 (authority) の助けをかりて解決することができるという考えは、ややナイーブだということに気がついた: これこそまさにプラトンのセマンティックな檻 (platonic semantic cage) であって、そのためにある人々はセマンティック・ウェブのことを聞くと怖がるのである。人々がそういったコントロールが必要だと気づき、また多少はそれに励まされて、それゆえ混合されたメタデータの品質を解決するために時間と費用をかけることが問題にならないような稀な環境ではうまくいくかもしれないが、しかし world-wide web のスケールではうまくいかない。
これにはすでに証拠もある!
まず少し背景を説明する必要があるだろう。何年か前オープン・アーカイブ・イニシアチブが PMH (protocol for metadata harvesting) と呼ばれるものを作った。Web サイトに対してそこにあるすべてのメタデータの内容をダンプさせるための軽量な方法だ。今では、ほとんどの人が同じことを RSS (メタデータの刈り取りのためのプロトコルはもたず、単にポーリングしつづけるだけだが) でやっているが、PMH はもう少し賢い (といってもそれほど複雑ではない)。DSpace は OAI-PMH を実装している。
すべての OAI-PMH アーカイブのレジストリがあって、その情報を使うインデクサ/クローラも存在する (Google Scholar もやっている)。OAI-PMH と DSpace のいずれも、元々は Dublin Core だけで動くよう設計されていたが、後に OAI-PMH はあらゆる種類のメタデータをサポートするよう拡張され、DSpace は他のメタデータをサポートするよう多くの機関によって改造された。
レジストリにはとても興味深いページがある: 現在レジストリに含まれる 898 のリポジトリが使っている、異なるメタデータスキーマのリストである (アイテム数は 600 万以上を数える)。[これはまだ XML の世界なので、スキーマは名前空間 URI によってではなく XMLSchema の置かれた URL によって識別されていてることに注意。]
注目に値することがいくつかある:
しかしこれらのリポジトリにあるメタデータの一貫性/品質についてはどうだろうか。個別には、おそらく非常に高いだろう。統合すると、おそらく Web そのものと変わらないように感じられるだろう。だから Google Scholar が Goole 自体より全然賢く感じられない (場合によってはむしろ逆) のだ。
この発見は少し皮肉なことだと気づいた: セマンティック・ウェブはモデルに構造を追加し、しかしオントロジー空間をより多様にすることで、現在の Web より「以上」に乱雑にするかもしれないのであって、「以下」ではない。Google はその帝国を <a> タグの上に築いたが、少なくともすべての HTML ページが含む <a> タグというものはあったのだ! RSS の世界はすでにバベル化を見はじめている: Apple、Yahoo、Google そして Microsoft が飛びついてきてそれぞれの RSS 拡張を加えており、私はサムのバリデータが RSS のバリエーションが指数法則に従うことをくい止めるとは思わないし、単にその流通の勾配を高くするだろう。それだけのことだ。
ということは、我々は Web を言語のバベルにしてしまう運命にあるのだろうか? そして純粋なデータの島々を混ぜ合わせることで薄めてしまう運命にあるのだろうか?
いや、幸運にも、そんなことはない。
欠けているのはフィードバック・ループだ: 人々がシステムを安定させておくためにシステムに情報を入れ戻すための方法である。高品質なメタデータの混合は低品質なメタデータを生むが、個々の品質は失われたわけではなく、薄まっただけなのだ。もとの (あるいはそれ以上の!) 品質レベルを取り戻すために、システムに追加の情報/労力を注入することが必要だ。このエネルギーはすでに統制語彙やマッピング・サービスを作るために払われた努力に凝縮されたものでも、ある共通の目標/関心や、システムを安定的で信頼できて社会-経済的に実現可能なものに保つという社会的慣習によって結びついた一群の人々に配分されたものでもよい。
オープンソース開発モデルと Wikipedia 開発モデルはともにそうした社会-経済的に実現可能なシステムの例だ。たとえセマンティック・ウェブ全体のために我々が必要とする/願うようなサイズにまでスケールしないとしても。
セマンティック・ウェブには技術的に大事なところで働いている人が数多くいるが、それを実現させるであろう社会的実践をしている人はごくわずかである。私は近いうちにどこか予期せぬところから変化が起こり、解決が訪れるかもしれないと思う。
訳注
というものですが、FRBR がなぜダメなのか訳者にはわかりません…。yes, dear metadata lover, I know FRBR and I know it gets way worse than this, I'm just using this as an example, so, please, bear with me