「Dublin Coreとメタデータに関する研修」報告

日時：平成13(2001)年10月25日(木) 9:30〜18:00
場所：国立情報学研究所 一橋記念講堂(学術総合センター２階)

内容：	10:45〜12:15	Tutrial1:Introduction to Dublin Core Metadata / Eric Jul (OCLC, USA) (チュートリアル１：Doblin Core メタデータの紹介）
	13:30〜14:40	Keynote Speech:Metadata for Multimedia information / Nagao, Makoto (President, Kyoto University) (基調講演：マルチメディア情報のためのメタデータ）
	14:30〜16:00	Tutrial2:Introduction to Resource Description / Eric Jul (OCLC, USA) (チュートリアル２：リソースデスクリプションの紹介)
	16:30〜18:00	Tutrial3:Introduction to Application Profile : Namespaces,schemas, and application profiles / Andy Powell and Rachel Heery (UKOLN, UK) (チュートリアル３：アプリケーションプロファイルの紹介）

今回の研修の目的は，国立情報学研究所の説明によれば，DC-2001 Dublin Core and Metadata Applications （Dublin Coreとメタデータの応用に関する国際会議）の中に設けられた，メタデータに関する学習の場（チュートリアル）を，国内の大学図書館等の担当者に受講してもらい，今後図書館などが取り組む必要のあるメタデータデータベース構築のための知識を習得するとともに，メタデータ整備における諸問題の解決策を見出す場とするとのことです。

実際，内容を見てもわかるように，Dublin Core を中心とするメタデータの概念を理解するための主要な３つの概念に関するチュートリアルが設けらています。以下，簡単に内容を記し，最後に個人的な感想を付します。なお，基調講演については，特筆すべきことがないため，ここでは割愛させていただきます。

Dublin Coreメタデータについて

・メタデータとは？

定義は様々で「データのためのデータ」「データについての構造化された データ」などと呼ばれる。またメタデータのタイプ（作成する意義）にも、管理するため，記録するため，アクセスするため，保存するため，使うため，などさまざまなものがある。Dublin Coreもこうしたメタデータの一つである。

・Dublin Coreの特徴

- Doblin Coreでは，データを記述するために15の要素(elements)を定義した。
- これらの要素に必須なものはなく，全てオプショナルなものである。
- 全ての要素はリピータブルであり，またどのような順番で記述してもかまわない。
- Dublin Coreは文字コードにUnicodeを採用していることから，インターナショナルであるといえる。


・Dublin Coreの拡張性

Dublin Coreは次の２つの方法で拡張できる。

(1)要素に修飾子(qualifier)を加えることで拡張する方法
(2)メタデータの要素自体を新しく作ることで拡張する方法


・スキーマ(scheme)について

要素(elements), 修飾子(qualifier)に加えて，もう一つ重要な概念がスキー マ(scheme)である。これは，例えば日付など，03/01/01 とあった場合に，どれが年，月，日であるかというような，その記述規則を明示するものを（ここでは）スキーマと呼ぶ。

・Dublin Coreの各要素および使用できる修飾子，スキーマの説明

(省略。興味のある方はWebサイトをご覧ください。
element については http://dublincore.org/documents/dces/
qualifier と scheme については http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/
日本語による解説は例えば http://www.kanzaki.com/docs/sw/dublin-core.html ）

リソースデスクリプションフレームワークについて

・リソースデスクリプションとは？

情報資源，サービス，サイト，あるいは人に関する，構造化された情報。例えば書誌レコードもこの一つであるが，カード目録にせよＭＡＲＣにせよ，それに関する教育を受けた人でなければ，そこに書かれた情報に，どのような 意味があるのかを読み取ることは難しい。例えば目録カードの左下に書かれた Z674.82.015016 という情報だけから，シロウトが何かの情報を得ることは 難しい。それにひきかえ，マークアップシステムを用いると，それぞれがどのような情報であるか，誰でもわかるように情報を記述することができる。マークアップシステムの例としては，SGMLやHTML，XMLなどがあげられる。

・リソースデスクリプションフレームワーク(RDF)

こうしたリソースデスクリプションを記述するための方法として，W3Cの 勧告であるリソースデスクリプションフレームワーク(RDF)がある。これは， ネットワーク上のあちこちにあるメタデータを扱う上で，相互運用性を保つ ための申し合わせ(convention)である。また，これはXML上で使うことを前提としている。

・RDFモデル

RDFモデルは基本的にResource, Property Type, Valueの３つで表現される。例えば www.page.html にある John's Home Page を，Dublin Coreメタデータを使ってRDFで表現すると，

Resource : www.page.html
Property Type : Title
Value : John's Home Page


ということになる。 (RDFについてのW3Cの勧告は http://www.w3.org/TR/REC-rdf-syntaxに、その日本語訳は、>http://www.nmda.or.jp/enc/w3c/rec-rdf-syntaxj.htmlにあります。）

アプリケーションプロファイル(Application Profile)の紹介

・ネームスペーススキーマ(Name space Schema)とは？

ネームスペースとは，定義された要素のセットであり，ネームスペーススキーマとは，ネームスペースで表される(メタデータ)スキーマの種類の一つである。これはWeb上に置かれ，URIによって示される。

・アプリケーションプロファイルとは？

アプリケーションプロファイルは，メタデータスキーマの種類の一つである。これは一つ以上のすでに存在するネームスペースから成る。また，特定のアプリケーションのために最適化されたものである。

・なぜRDFではなく，アプリケーションプロファイルが必要か？

- RDFは，メタデータレコードを評価するには便利だが，ネストされた構造が，(要素の)マージを困難にしてしまう。

- 特定のドキュメントタイプそれぞれに，ソフトウェアを手作りしなければならない。

・アプリケーションプロファイルの特徴

- ネットワーク上に様々なメタデータが存在するようになった場合，メタデータ間の整合性がとれなくなる。これはRDFを用いて解決されるが，こうして各所に存在するRDFを用いて，新たなメタデータを作成し，かつ整合性も保つことが出来るようになる。
- 複数のネームスペースから成る場合，要素名が同じでも，参照されるネーム スペースが異なるため，問題なく使用することができる。

・アプリケーションプロファイルの問題点

これはまだ研究段階であり，実際に各ネームスペースで指定されたURIからスキーマに関する情報を取得し，アプリケーションで問題なく動作させられるかどうかは，検証されていない（らしい）。（アプリケーションプロファイルについては，いまひとつよく理解できませんでした。講演者による論文がhttp://www.ariadne.ac.uk/issue25/app-profiles/にあります。またDCMIのThomas Baker他との共著論文が http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Baker/にもありますので，興味のある方は，そちらもご覧ください。）

メタデータ，RDFについては仕組みの紹介，アプリケーションプロファイルはメタデータの活用方法の一つの案の紹介といった感じでした。講演者の力量の差もあるのでしょうが，前の２つはわかりやすかったのですが，最後のものはいまひとつ要領を得ない感じです。

ただ，Dublin Coreをはじめとするメタデータは，作成者が自由にスキーマを設定できるため，複数のメタデータをまとめて扱うといった場合に，それぞれのメタデータで使われている用語に重複があったり，同じ用語で意味が異なるなどの理由から，混乱が生じる可能性がある。これを解決するのがRDFということになるわけですが，逆にそうして作成されたRDFを包括的に扱い，ひとつのスキーマとして活用していこうというのがアプリケーションプロファイルなのかな，という感じを受けました。

自分があまりメタデータについて，マジメに勉強していなかったので，Dublin Coreに基づいてメタデータを記述しておきさえすればインターネット上での情報共有が簡単に実現するような印象があったのですが，実際にはスキーマを独自に作成することから，interoperability の保証は意外と難しいのではないかという感じです。そのためのRDFであり，アプリケーションプロファイルなのでしょう。

ところでRDFにせよ，アプリケーションプロファイルにせよ，メタデータ中の個々のデータに明示的な意味づけを行うものです。その理由は，そのメタデータ内だけで，書かれたデータの意味がわかるようにしておくことで，その意味を読み取ることができるようにシステムを組みさえすれば，どのようなアプリケーションでもメタデータを処理できるようにするためです。

その将来像をわかりやすく説明したものが，T. BERNERS-LEE らが提唱するセマンティックウェブということになるようです。（セマンティックウェブについては，例えば日経サイエンス 2001年8月号 p.54-65 (原論文は Scientific American 2001年5月号 )。

もう一つ，図書館情報学の分野でも，昨今 Knowledge Management という言葉がもてはやされているようです。knouwledge というのは最近の流行言葉のようで，インターネットの活用によりナレッジを云々，というような表現をよく見かけますが，これがメタデータを抜きにして語れないこともわかってきました。これからの図書館員は，インターネット上の情報についても精通していないとやっていけないと世の中＝メタデータにも強くなければいけないということになるわけで，今回の研修の主旨に戻ってくるわけです。とはいえ、まだまだ紙媒体の資料をベースにした業務が中心の中で，入江さんも指摘しているようにMARCとメタデータが別物であるとすれば，メタデータがライブラリアンに浸透するには，まだまだ時間がかかるように思いました。