「OAI-PMHと図書館サービス」


1.OAIとは

まずOAIとは何かというお話から始めたいと思いますが,正式名称は,Open Archives Initiativeと言います。ここで注意していただきたいのが,Openという意味合いですが,たとえば最近Open Access Journalという言葉をよく耳にします。ここでいうOpenとは「無償の」とか「無料でアクセスできる」雑誌といった意味で使われているわけですが,Open Archives InitiativeのOpenの方は,アクセス料金に関わる意味ではなく,システム的に「開かれた」システムであるという意味で使われています。同じように,Archiveについても厳密な意味での「アーカイブ」,「保管庫」というよりもむしろ,広い意味での電子コンテンツを格納したサーバを意味する言葉として使われている。つまり,全体として「さまざまな電子サーバのための開かれたシステムを推進する運動」と考えてまちがいないと思います。

で,このイニシャティブの使命というかミッションですが,さまざまな電子コンテンツの効果的配信を促すために,相互運用性に関する標準を策定し,それを普及させることを使命としております。そして,CNI(Coalition for Networked Information),DLF(Digital Library Federation),NSF(National Science Foundation)といった組織,団体の支援を受けている。

OAIの歴史は,1999年10月にアメリカのサンタフェで開催された会議にまでさかのぼることができます。この会議からOAIが正式な活動を開始することになります。サンタフェ会議はそもそもeプリントアーカイブの間の相互運用性の確立を目的として開催された会議でありまして,ここで,メタデータのハーベスティング,収集によって複数のアーカイブの相互運用性を確立しようという基本的なフレームワークが合意されます。その後,2000年6月の第2回会議において,eプリントアーカイブから各種電子コンテンツのリポジトリに対象を拡大することが決定され,2001年1月に,メタデータ収集プロトコル,OAI-PMHと呼ばれるプロトコルの第1版が制定されることになる。さらに2002年の6月には,OAI-PMHの第2版が発表されております。これが今のところ最新のバージョンということになります。

2.OAI-PMHとは

というわけで,OAI-PMHそのものの話に進んで行きたいと思いますが,かなり先ほどのJewelさんのお話と重複する点があるかと思いますが,復習ということでもう一度聞いてください。まずこのプロトコルの基本的な概念と定義について確認していくことにします。

まずOAI-PMHの構成者はデータプロバイダとサービスプロバイダという2つの種類に分けることができる。データプロバイダは,リポジトリを維持し,OAI-PMHによりメタデータを開示する。一方,サービスプロバイダは何をするかといいますと,OAI-PMHを使って,データプロバイダが提供するリポジトリから収集したメタデータに基づき,付加価値のあるサービスを提供する。

次にリポジトリとハーベスタ。リポジトリは,OAI-PMHの要求,リクエストに対して応答できるサーバ。これはさきほどのデータプロバイダが管理する。これに対して,ハーベスタの方は,OAI-PMHの要求を発行するクライアント・アプリケーションということになる。ハーベスタはサービスプロバイダがリポジトリからメタデータを刈り取ってくる手段として使うことになります。OAIではサーバクライアントという言い方はあまりしないのですが,リポジトリがサーバでハーベスタがクライアントであると理解してもらっても間違いないと思います。

リポジトリとハーベスタの間のやりとりを図にしてみますと,サービスプロバイダが,ハーベスタを使って,データプロバイダが管理するリポジトリに対して要求を投げる。どういう要求が投げられるかは後でお話します。それに対して,リポジトリは応答するという形になります。

ここで,ここまでの話をまとめておきますと,OAIのプロトコルの根底にある考え方は,データ層,プロトコル層,そしてサービス層という3層のモデルで表すことができる。まずデータとサービスをはっきりと分けてしまう。データ層にはデータプロバイダが管理する各種のリポジトリが存在する。サービス層にはサービスプロバイダがいて,メタデータ収集プロトコルを使って必要なメタデータをリポジトリから刈り取ってくる。刈り取ってきたメタデータに基づいて,いろいろな付加価値サービスを,サービス層で展開する。これがOAIの基本的なモデルであります。

続いて,プロトコルに従って実際にやりとりされるメタデータに関する概念と定義についてですが,まずアイテムというのがあって,これがちょっとわかりにくい。これはリポジトリの構成要素のひとつでありまして,あるひとつのリソースに関するメタデータを複数のフォーマットで蓄積する概念的な容れ物(コンテナ)であると定義されています。そして,アイテムという概念的な容れ物の中に含まれるさまざまなフォーマットのメタデータが,OAI-PMHを通じてレコードして収集されることになる。アイテムにはリポジトリのなかで一意になる識別子を持つ。アイテムと対になる概念としてレコードというのがありまして,こちらはあるひとつのフォーマットで表現されたメタデータ。OAI-PMHのリクエストに対して,XMLでエンコードされて返戻される。

言葉で表現すると非常にわかりにくいので,アイテムとレコードの関係を図にしてみますと,アイテムというのはあくまで概念的なものであって,実際にはダブリンコアとかその他のメタデータフォーマットで表現されて,それがレコードとなる。ハーベスタはリポジトリからメタデータを刈り取ってくるときに,必ずメタデータフォーマットを指定する。例えば,ダブリンコア形式のレコードを要求すると,リポジトリはダブリンコアのメタデータをレコードとして返戻する。別のフォーマットでほしい時は,そのフォーマットを指定してリクエストを発行する。

それから,リポジトリにはセットという概念を導入することができる。セットによって複数のアイテムをグループにまとめることができるわけです。例えば,主題で分けたり,学位論文や雑誌論文といった種別でセットを作ることもできる。但し,セットというのは必須の要素ではなく,あくまでオプションとして設定することができる。一方,ハーベスタの方は,日付とセットがあればセットを指定して,リポジトリのなかから選択的にメタデータを収集することができるというわけです。以上がOAI-PMHを理解する上での基本的な概念とその定義の話でありました。

次に,OAI-PMHの特徴をいくつか挙げておきたいと思いますが,まずリクエストはすべてHTTPのGETもしくはPOSTを使って送信するという決まりになっています。それから逆にレスポンスの方ですが,すべてXMLで文字コードはUTF-8を使って返戻する。あと,メタデータのフォーマットについてですが,これはさきほど見たように,複数のメタデータフォーマットでのレコードの送信をサポートしている。但し,限定詞,qualifierなしのダブリンコア,いわゆるシンプルダブリンコアでの送信は必須とされている。これがないと相互運用性が保証されなくなってしまいますから,全てのリポジトリは最低限シンプルダブリンコアをサポートしなければならないという約束になっているわけです。

それでは実際にOAI-PMHの要求にはどんなものがあるか。全部で6つの動詞しかない。順番に見ていきますと,GetRecordというのがありまして,これはリポジトリから個々のメタデータ・レコードを取得せよという要求です。Identifyというのがリポジトリに関する情報,具体的にはリポジトリの名称ですとか,ベースURLとか,サポートしているプロトコルのバージョンなどの情報を得るために使う。ListIdentifiers。これはリポジトリの中からヘッダー情報のみを取ってくるための要求ですね。ListMetadataFormatsというのは,リポジトリで利用できるメタデータのフォーマットの一覧を取得するための要求。ListRecords。これはリポジトリから条件に合致するレコードを全てとってくるための要求。そして最後が,ListSetsで,さきほどお話したリポジトリのセット構造を得るためのリクエストということになります。

OAI-PMHの要求の実際のサンプルですが,ここにはHTTP GETを使ったOAI-PMHのGetRecordの例を挙げておきました。最初にベースURLを指定する。ベースURLというのは,OAIのリポジトリとして機能するHTTPサーバのURLですね。ここに例としてあげてあるのは,後でご紹介しますが,千葉大のOAIリポジトリのURLです。次にverb=に続けて,6つの要求のうちのひとつを指定する。そして,要求に応じて必要な引数を設定する。これでGetRecordのリクエストが出来上がったということになります。これを解釈すると,このURLのリポジトリから,識別子がこのレコードをoai_dc,これはシンプルダブリンコアですね,このフォーマットで取得せよ,という要求になるわけです。

次にOAI-PMHによる要求,応答の実際をRepository Explorerというツールを使って見てみたいと思います。これは元々リポジトリがOAIのプロトコルに準拠しているかどうかを検証するためのツールなんですが,これを使うとプロトコルによるリクエストとレスポンスを眺めることができるので非常に便利なツールです。(Repository Explorerのデモ)

以上がOAI-PMHの概略でありますが,さらに詳しく知りたい方は,プロトコル自体の翻訳がNIIのサイトに掲載されておりますので,こちらをご覧ください。

3.OAI-PMHの適用事例

続いてOAI-PMHの適用事例についていくつか見ていきたいと思いますが,まず関連するプロジェクトですが,これはもう枚挙にいとまがない。たくさんある。代表的なものだけを拾っておきますと,まずNSDLというNSFがお金を出しているプロジェクトがありまして,これは科学,サイエンスに関するさまざまなデジタルコンテンツの提供をめざした電子図書館プロジェクトでありまして,このNSDLのシステムのアーキテクチャのなかでOAI-PMHは非常に重要な役割を果たしている。

次にメロン財団のメタデータ・ハーベスティング・イニシャティブというプロジェクトがあって,これには7つの機関が参加しておりまして,合計150万ドル,約1億8千万円くらいの助成金が出ている。

そのメロン財団のプロジェクトのひとつがミシガン大学のOAIster,これは「オイスター」と発音するそうですが,こういったプロジェクトがあります。これもメロン財団のプロジェクトに参加している機関のひとつであるイリノイ大学が開発したハーベスタを使って,5月1日現在,167機関から収集した100万件を越えるメタデータの検索サービスを提供しています。 試しに検索してみましょう。(OAIsterのデモ)

データプロバイダの例については,こちらのOAIのページを参照していただきたいと思いますが,現在,94のリポジトリがOAI-PMH(ver.2.0)に準拠したデータプロバイダとして登録されている。

一方,サービスプロバイダの方も,OAIのホームページにリストが掲載されております。

4.千葉大学におけるプロジェクト

OAI-PMHの適応事例として,もうひとつ千葉大学のプロジェクトを紹介したいと思います。 千葉大学では,昨年から学術情報リポジトリの構築プロジェクトにとりかかっておりますが,これは,いわゆる千葉大学版の学術機関リポジトリ,Institutional Repositoryでありまして,千葉大学内で生産された電子的な知的生産物(学術論文,学位論文,プレプリント,統計・実験データ,教材,ソフトウェアなどの学術情報)を蓄積,保存し,学内外に発信するためのインターネット上の保存書庫を構築しようという計画です。

仕組みとしては,そうむずかしいものではなくて,学内の先生方に自分で研究成果を投稿してもらう。そして,図書館員が投稿してもらった研究成果に書誌的なメタデータやいろいろな管理情報を付け加えてリポジトリに登録する。それをなんらかの検索インターフェイスから提供する。それでは,このリポジトリの中身をご覧になっていただきたいと思います。(千葉大学学術情報リポジトリのデモ)

この千葉大のリポジトリとNIIのメタデータデータベースの連携に,OAI-PMHを使おうと考えています。さきほど,OAIのRepository Explorerを使ってご覧になっていただきましたが,このリポジトリはOAIに準拠したリポジトリである。一方,NIIはメタデータを刈り取るためのハーベスタを用意して,千葉大のリポジトリから定期的にメタデータをハーベストして,それを自分のところのデータベースに格納する。こういったシステム間の連携を考えています。 実は,つい先週このハーベスティングの実験を行いまして,問題なく成功したとの報告を受けております。これが多分日本におけるOAI-PMHの適用事例の記念すべき第1号だと思います。今後は,おそらく1週間に1度という頻度で,千葉大のリポジトリに蓄えられたメタデータがNIIによって刈り取られていくことになると思います。

5.Z39.50とOAI-PMH

さて,ライブラリシステム研究会で話をするからには,Z39.50とOAI-PMHとの関係を整理しておかなければならない。

どちらのプロトコルも,分散サーバ,リポジトリの間の相互運用性を確立するための規格であるとみなされていますが,確かにそれはそうなんですが,そもそも目的が違う。Z39.50はあくまで情報検索用のプロトコルでありまして,一方,OAI-PMHはメタデータを収集するためのプロトコルである。土台,同じ次元で比較すること自体が無理なのではないかと思います。

そういった点を踏まえた上で,例えば複数のサーバの横断検索システムを2つのプロトコルを利用して構築する際の長所短所というのをまとめてみましたが,このあたりはまだよく考えていないので,ちょっと的外れなことを言うかもしれませんが,Z39.50が完全に分散型のソリューションであるのに対して,OAI-PMHの方は集中型のシステムとなる。Z39.50はプロトコルが複雑で実装コストもそれなりにかかるのに対して,OAIの方は既にご覧になっていただいたように非常に単純なプロトコルなので,実装は楽。Z39.50はもともと情報検索のためのプロトコルですから検索機能が豊富であるのは当たり前なのですが,一方OAIには検索機能がない。これはサービスプロバイダが別途作り込まなければならない。Z39.50の方は,分散型ですから各サーバの性能やネットワークの渋滞や帯域の影響を受けざるをえない。OAIの方はこういった問題は少ない。それと,さきほどご紹介しましたOAIsterは167のサーバからあつめたメタデータを統合検索できるわけですが,これをZ39.50で実現しようとすると,167のターゲットを対象として検索を実行するわけですが,これはどう考えても現実的ではない。あと,Z39.50にはデータのタイムラグがない。OAI-PMHの方はハーベスティングの頻度に依存してタイムラグの問題が生じる。まあ,ざっと比較するとこのようになるのではないでしょうか。

結論を言うと,Z39.50とOAI-PMHは何も競合するプロトコルではなく,相互補完的に使うことができると考えればよいのではないか。例えば,イギリスのRDNというさまざまな分野のサブジェクト・ゲートウェイのネットワークがあるんですが,ここに参加しているサブジェクト・ゲートウェイからメタデータを収集してResourceFinderという統合データベースを作る。そしてそれにZ39.50のターゲット機能を実装して検索サービスを提供している。こういった形でZ39.50とOAI-PMHを相互補完的に組み合わせて使うこともできるという一例です。

6.NIIメタデータデータベースとOAI-PMH

あと,NIIのメタデータデータベースを中心とした,OAI-PMHの活用法についてですが,さきほど千葉大のリポジトリとNIIの連携のところでお話したように,各大学が構築したリポジトリをデータプロバイダとして位置づけて,それをサービスプロバイダとしてのNIIがハーベスタを使って刈り取ってきてメタデータデータベースの構築に利用する。こういった使い道がひとつ。

それともうひとつ,今度は逆にNIIのメタデータデータベースにたまったさまざまなメタデータを外部のサービスプロバイダ,これは例えば図書館でもいいんですが,サービスプロバイダが目的に応じて選択的にハーベストしてそれを元にして各種のポータルサービスを利用者に提供するなどということも可能になるのではないかと考えています。

というわけで,ここではNIIのメタデータデータベースをめぐるOAIの適用についてみてきたわけでありますが,勿論OAI-PMHは他にもさまざまな使い道があるはずです。例えば,図書館の書誌データの共有やOPACの統合検索のツールとして使うこともできる。図書館のコミュニティが例えばMARC21をメタデータフォーマットとして採用して,OAI-PMHを使ってMARC形式でのレコードのやりとりをするのももちろん可能なわけです。結局はひとつのプロトコルでありまして,要素技術に過ぎない,道具にすぎないわけです。この便利でしかもあまりお金のかからない道具を使って,いかにして図書館どうしの協調関係を発展させ,サービスの高度化をはかっていくかについては,われわれ図書館員が知恵を出し合っていかなければならないと考えます。

7.開発メーカーの皆さんへのお願い

さて,今日はメーカーの方もたくさんお見えになっているようですので,最後に開発メーカーの皆さんへのお願いを申し上げておきたいと思います。要は,OAI-PMHに関連するツールをオープンソース化して無料で誰もが使えるようにしてほしいということです。既に海外では,OAI準拠のリポジトリを作るツールや,ハーベスタが無料で配布されている。ですから,日本でもそうすることによって,まずOAI-PMHを世の中に広める。その上で,サービスプロバイダが付加価値サービスを展開するためのソフトウェアで競争して,収益をあげる。OAIをビジネスの材料としようと思ったらこれが最短の道である。ということでわたしのお話は終わりにしたいと思います。


問い合わせ:国立情報学研究所開発・事業部コンテンツ課文字情報係 <metadb@nii.ac.jp>