D-Lib Magazine
2004年2月

10巻2号

ISSN 1082-9873

ロスアラモス国立研究所デジタルライブラリにおいて複合デジタルオブジェクトの動的配布のためにMPEG-21 DIPとNISO OpenURLを使用する

Jeroen Bekaert
ロスアラモス国立研究所研究図書館およびゲント大学工学部
<jbekaert@lanl.gov>

Lyudmila Balakireva
ロスアラモス国立研究所研究図書館
<ludab@lanl.gov>

Patrick Hochstenbach
ロスアラモス国立研究所研究図書館
<hochsten@lanl.gov>

Herbert Van de Sompel
ロスアラモス国立研究所研究図書館
<herbertv@lanl.gov>

摘要

本稿は、ロスアラモス国立研究所研究図書館のために設計されたリポジトリアーキテクチャで採用した複合オブジェクトおよびそれに含まれる資産を配布するためのNISO OpenURLとMPEG-21デジタルアイテム処理（DIP）の使用について取り上げる。本アーキテクチャでは、複合デジタルオブジェクトを表現するためのXMLベースのフォーマットとしてMPEG-21デジタルアイテム宣言言語（DIDL）が使用されている。受入プロセスにおいて、これらのオブジェクトは多数の自立OAI-PMHリポジトリに格納される。これらすべてのリポジトリの生成と配置場所はOAI-PMH準拠のリポジトリインデックスが把握しており、一方、個々の複合オブジェクトやそれに含まれる資産は識別子リゾルバが把握している。MPEG-21 DIPエンジンとOpenURLリゾルバは、保管されているオブジェクトの様々な形態による配布を容易にする。本アーキテクチャのこれらの側面はロスアラモス国立研究所研究図書館の文脈で説明されるが、本稿ではそのより一般的な応用性についても簡単に触れることにする。

1.   はじめに

ロスアラモス国立研究所研究図書館(以下、LANL図書館と呼ぶ）は、デジタル学術情報へのアクセスの提供方法について、多くの学術図書館や研究図書館と比べてやや独特な戦略を採用している。サードパーティが提供するサービスを利用し、自館で運用するWebポータルを通じて、外部で保管されている資料を利用者が統合的にアクセスできるようにすることがデジタルライブラリーサービスの一般的な傾向である。LANL図書館は、研究に不可欠な学術情報に関して独自に対応するために、大量のデジタル学術資産コレクションを購入あるいはライセンスを取得し、これらの資産をローカルで管理運用し、独自に開発した利用者サービスを通じてアクセスを提供している。ローカルで管理している資産には、ISIやBIOSIS、Inspecが提供する二次情報やElsevierやWiley、IOP、APSなどの主要な学術出版社が提供する一次資料がある。

本稿執筆時点で、研究所が管理している資産のコレクションは生データでおおよそ5テラバイトにのぼる。これに加えて、LANL図書館ではテクニカルレポートやデータセット、ビデオテープに記録されたプレゼンテーションなど研究所で作成された資料を管理するための機関リポジトリを構築する可能性を鋭意調査中である。また、集中的なWebクロールで資料を収集してローカルで管理するコレクションを増やしたり、リポジトリ資産の利用実績を詳細に示すログを独立した資産として含めたりする研究も行われている [1,2]。このように様々な種類の膨大な学術資産のコレクションを整合的かつ持続的に保管・管理して、アクセスを提供することは、デジタルライブラリの実践や研究の多くの分野―資産の識別、資産間の関係の表現、複合オブジェクトモデルによる資産の表現、資産の受入とアクセスの方法など―に関わる挑戦である。

昨年から、LANL研究図書館のデジタルライブラリ研究およびプロトタイプ作成チームは、ますます増加を続ける様々な種類のデジタルコレクションを受入・保管し、下流アプリケーションにアクセスを提供することを目的とするLANLリポジトリのアーキテクチャの設計に取り組んできた。また、実用レベルの設計試作システムが実装された。LANLリポジトリのアーキテクチャや実装は、たとえば、DSpace[3]やFedora[4, 5]プロジェクトの成果物と比較すべき性質のものではないが、このアーキテクチャがLANL研究図書館の範囲を超えて、リポジトリに関連するプロジェクトにとっても魅力的であるに違いない次のような興味深い性質を持っていると筆者は考えている。

1. 先のD-Libマガジンの論文で述べたように、複合オブジェクトを表現するためにMPEG-21デジタルアイテム宣言言語（DIDL）を使用[6]。本稿の議論を十分理解するには先の論文を読むことを勧める。
2. アーキテクチャが最初から分散型の性格を持つ。
3. 複合オブジェクトの静的コレクションの格納とアクセス提供のために特別な手法―XMLtape―を使用。
4. 増分バッチ処理において保管コンテンツにアクセスするためにOAI-PMHを多面的に使用
5. 保管コンテンツとその様々な配布形態にアクセスするためにNISO OpenURLを使用。
6. 保管コンテンツに対して配布方法を動的に結合。
7. エージェントからの要求に応じてDIDに結合する様々なサービスを実行するためにMPEG-21デジタルアイテム処理（DIP）を使用。

図 1はLANLリポジトリアーキテクチャの主要なコンポーネントを紹介している。図からわかるように、LANLリポジトリは数多くの自立OAI-PMH[7] リポジトリを運営している。各リポジトリはMPEG-21 DIDL[8]フォーマットを使って表現された複合デジタルオブジェクトを保管している。リポジトリインデックス（Repository Index）は、自立OAI-PMHリポジトリの生成とその配置場所を把握している。リポジトリインデックスは、独立したOAI-PMHリポジトリとして公開される。OAI-PMHフェデレータ（OAI-PMH Federator）は、全てのLANLリポジトリを1つのOAI-PMHリポジトリとして公開する。OAI-PMHフェデレータはアーキテクチャの他のコンポーネントと主としてOAI-PMHを使って相互作用している。OAI-PMHフェデレータは下流ハーベスタからLANL環境の複雑さが見えないようにし、LANLリポジトリからハーベストする際の唯一のアクセスポイントとなっている。LANLリポジトリアーキテクチャの各コンポーネントについては、3章で簡単に紹介するだけであるが、上記の(2)、(3)、(4)項に焦点をあわせた近々発表する論文で詳細に記述する予定である。本稿では、保管されている複合オブジェクトとそれに含まれる資産を動的に配布するためにMPEG-21 DIP [9]とNISO OpenURL[10] が使用されていることを説明することにより、LANLリポジトリアーキテクチャの性質の(2)、(5)、(6)、(7)項について詳述する。そのために、4章では保管コンテンツの識別子とコンテンツを保管しているOAI-PMHの配置場所を保持している識別子リゾルバ（Identifier Resolver）を説明する。識別子リゾルバは、OAI-PMHハーベスティングによりレコードが追加され、ハンドルプロトコル [11]など様々な方法で問い合わせを行うことができる。保管コンテンツを様々な形態で配布できるようにするために、MPEG-21の原則に従って動作するDIPエンジン（DIP Engine）が導入された。DIPエンジンの動作の詳細な仕組みについては5章で説明される。5章では、LANLリポジトリへのフロントエンドを提供するOpenURLリゾルバ（OpenURL Resolver)も説明される。このフロントエンドにより、やがて制定されるNISO OpenURL標準に準拠したリクエストを使ってLANLリポジトリに含まれる個々の資産を様々な形態で得ることが可能となる。

図 1: LANLリポジトリアーキテクチャ

2.   LANLリポジトリへの受け入れ

多くの場合、LANLリポジトリで管理されることになる配布資産は、全体で1つの論理ユニットを形成する複数のデータストームで構成されているという意味で「複合的なもの」である。たとえば、学術論文は、論文を記述するメタデータ、PDFやASCIIフォーマットの論文本体、XMLで表現される論文の参考文献から構成されるひとまとまりのもの（バンドル）として配布されるだろう。このように資産は複合的性格を持っているので、XMLラッパーを使って複合デジタルオブジェクトを表現する既存のアプローチを調査することになった。その結果、LANLリポジトリにデジタル資産を保管する唯一の方法としてMPEG-21デジタルアイテム宣言言語（DIDL: Digital Item Declaration Language）[8] を採用することになった。DIDLは、デジタルオブジェクトのための明確に定義された抽象モデルを形成する1組の抽象概念を導入している[注1]。DIDLは、これらの抽象概念に基づいて1つのW3C XMLスキーマを定義している 。このスキーマはこれに準拠した複合デジタルオブジェクトを実際に表現する際に大きな柔軟性と拡張性を提供する[注2]。DIDLデータモデルは次のエンティティを認識する。各エンティティは、DIDL XMLスキーマにおいて対応するXML要素を持っている。

• コンテナ(Container)は、コンテナ あるいはアイテムをグループ化したものである。
• アイテム(Item)は、アイテムあるいはコンポーネントをグループ化したものである。
• コンポーネント(Component)は、リソースをグループ化したものである。同一のコンポーネントに含まれる複数のリソースは等価であると考えられるので、エージェントはこれらの任意の1つを使用することができる。
• リソース(Resource)は、個々のデータストリームである。
• コンテナ、アイテムあるいはコンポーネントに関する二次情報は、記述子(Descriptor)を用いて伝達することができる。

LANLリポジトリで管理されるデジタル資産は、原則として、FTPやOAI-PMHハーベスティング、Webクローリング、物理媒体による配布など様々な方法で入手することができる。入手した資産を、それを構成するデータストリームをラップする独立のXML文書に変換するプロトタイプの受入プロセスが開発された。このXML文書はデジタルアイテム宣言（DID: Digital Item Declaration）と呼ばれている。全てのLANL DIDはMPEG-21 DIDL仕様に準拠している。したがって、たとえば、先に示した学術論文の各データストリームは1つのDIDに含まれることになる。DIDは、複合オブジェクトを構成する様々なデータストリームを物理的に、あるいは参照の形で収納する。DIDは、受入プロセスで追加される、たとえば、データストリーム間の関係やデータストリームの媒体種別などを表す情報も含んでいる。LANLリポジトリでのDIDLの実際の使用法やLANL DIDLのプロファイルは、[6]で詳しく説明されている[注3]。付録 Aは実際のDIDを示している。

本稿においては、LANL DIDで使用されている識別子が重要である。2つの種類の識別子が区別されている。なお、DIDにおけるこれらの伝達方法が先のD-Lib論文時に比べて多少変更されている[6]。

• DID識別子: DID識別子は、リポジトリ受入プロセスにより各DIDに付与されるグローバルで一意な識別子である。DID識別子は、MPEG-21 DII XML名前空間 [12]のdii:identifier要素を使用するコンテナレベルの記述子で伝達される。受入プロセスにおいて、DIDアイテムとDIDコンポーネントはXML ID[13]を付与され、MPEG-21 DIDL XML名前空間の各々didl:Item要素とdidl:Component要素の属性値として設定される。この結果、アイテムとコンポーネントは、これらを含むDIDのDID識別子と自身のXML IDの組み合わせで指定することが可能となる。DID識別子は、LANLリポジトリそれ自体の機能や、後ほど説明するMPEG-21 DIPエンジンなど、リポジトリに直接関係するプロセスにとって欠くことのできないものである。サンプルDIDのDID識別子と関連するXML IDを付録 Aに示した。
• 内容識別子: 内容識別子は、LANLリポジトリに受け入れられる前から元々データストリームに付与されていた識別子に直接関係する。通常、これは受け入れた資産から推測される。実際、多くの場合、これらの資産は作成あるいは出版された際に付与された識別子を持っている。たとえば、A&Iデータベースのレコードとしての受入番号や雑誌論文のDOI[注4]などが内容識別子となりうる。LANL DIDLプロファイル[6]に従うと、内容識別子はDIDのアイテムレベルにのみ記載される。内容識別子はアイテムに関する特別なメタデータと考えられるので、アイテムレベルの記述子においてDC XML名前空間[注5]のdc:identifier要素を使って伝達される。これは付録 AのサンプルDIDに例示されている。

3.   LANLリポジトリにおけるOAI-PMHの多面的使用

納入された資産が受入プロセスにおいてDIDに変換されると、DIDはOAI-PMHリポジトリに格納される。LANLリポジトリに格納される大部分のデータを納入する二次出版社や一次出版社は月1回あるいは年1回の頻度でデータを納入するので、通常、LANLはデータ資産を一括して大量に受け取ることになる。そのような場合、納入される一括データごとに1つ自立OAI-PMHリポジトリが作成される。これらのリポジトリで使用されるOAI-PMHのidentifierは、DID識別子であり、OAI-PMHのdatestampはDIDを作成・更新した日時である。これらのリポジトリはDIDしか保管していないので、サポートするmetadataPrefixはDIDLのみである。結果的に、LANLリポジトリには多くの自立OAI-PMHリポジトリが存在する。特別なコンポーネントであるリポジトリインデックスが、これらの自立OAI-PMHリポジトリの生成と配置場所を記録している。リポジトリインデックスは、それ自体OAI-PMHリポジトリである。リポジトリインデックスと自立OAI-PMHリポジトリとの連携を通じて、下流アプリケーションのために稼動しているハーベスタは、前回のハーベスト以降に追加・更新されたDIDをLANLリポジトリから選択的に収集し、それを使用してOAI-PMHサービスプロバイダとして何か意味のあることを行うことができる。

下流ハーベスタが全ての自立OAI-PMHリポジトリとやり取りしなければならないという負担やLANLリポジトリアーキテクチャのその他の詳細を理解しなければならないという負担を軽減するために、OAI-PMHフェデレータ（OAI-PMH Federator）が導入された。OAI-PMHフェデレータはLANLリポジトリ全体を1つのOAI-PMHリポジトリとして公開する。OAI-PMHフェデレータはハーベスタにとって全LANLリポジトリ―各リポジトリはLANLの内部にある―への唯一のアクセスポイントとなり、LANLリポジトリ環境の複雑さを隠蔽するものである。その結果、アプリケーションのために稼動するハーベスタは、統一的な技術であるOAI-PMHハーベスティングを使ってLANLリポジトリの状況に常に同期することが可能となる。本章で簡単に説明したLANLリポジトリにおけるOAI-PMHの多角的使用は近々発表する論文で詳細に説明する予定である。

4.   特別なサービスプロバイダ: 識別子リゾルバ

ハーベスタはサービスプロバイダのために稼動し、LANLリポジトリからDIDを収穫し、収穫した情報を使ってサービスを構築する。その結果、収穫したDIDに含まれている識別子は検索エンジンなどのアプリケーションで利用できるようになる。既に述べたように、これらの識別子は、DIDやDIDエンティティを識別するDID識別子か、DIDに含まれているコンテンツを識別する内容識別子のいずれかである。これらの識別子を下流アプリケーションが見つけた場合、該当するコンテンツをLANLリポジトリから入手できることが、明らかに重要である。この目的のために、識別子リゾルバ（Identifier Resolver）がLANLリポジトリ環境に導入された。識別子リゾルバは専用のサービスプロバイダであり、LANLリポジトリから再帰的にOAI-PMHハーベスティングすることにより必要な情報を収集する。識別子リゾルバは、収穫した情報のうち、DID識別子、内容識別子、これらを持つOAI-PMHリポジトリのベースURLのみを使用する。

識別子リゾルバは、保持する識別子の性格を反映した次の2つのモジュールからできている。

• DID識別子モジュール。表 1に示すように、DID識別子と識別されたDIDを保管している自立OAI−PMHリポジトリのベースURLのみを持っている
• 内容識別子モジュール。表 2に示すように、内容識別子とDID識別子を結びつける。

[表1]と [表2]に識別子リゾルバのコンテンツを示す。見てわかるように、全ての識別子は、'info' URIスキーム案を使って表現されている[14]、[注6]。表 1において、'info:lanl-repo/i/58f202ac'と'info:lanl-repo/i/002035b2'は、ベースURLが各々"BaseURL(3)"と"BaseURL(6)"であるOAI-PMHリポジトリに存在するDIDのDID識別子である。これらはDID識別子であるので、これらのリポジトリに存在するDIDのOAI-PMHのidentifierの値は、DID識別子の値と同じである。表 2において、内容識別子'info:lanl-repo/apsmeta/123456'、'info:lanl-repo/aps/1202252'、'info:lanl-repo/biosis/abcdef'は、DID識別子が各々'info:lanl-repo/i/58f202ac'と'info:lanl-repo/i/002035b2'であるDIDに含まれるコンテンツを識別する。これらのDIDにおいて、これらの内容識別子と結びついているアイテムは、各々'445998'、'899952'、'444940'というXML IDを持っている。 付録 AはDID識別子が'info:lanl-repo/i/58f202ac'のDIDを示している。

アプリケーションは、ハンドルプロトコルやSOAPベース[15]のアクセス法、Cライブラリなど多くの方法で識別子リゾルバにアクセスすることができる。識別子リゾルバに問い合わせることにより、アプリケーションは特定のDID識別子を持つDIDや特定の内容識別子を持つコンテンツを含むDIDをOAI-PMHを使って取り込むことができる。これは次のように行われる。

• 識別子 'info:lanl-repo/i/58f202ac' を持つオブジェクトが要求されたとすると、識別子リゾルバを検索して、それがBaseURL(3)にあるDID識別子が'info:lanl-repo/i/58f202ac'のDIDにあることがわかる。このDIDはOAI-PMHリクエスト[BaseURL(3)?verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&metadataPrefix=DIDL]を発行することにより入手することができる。
• 識別子 'info:lanl-repo/i/58f202ac#445998' を持つオブジェクトが要求されたとすると、識別子リゾルバで'info:lanl-repo/i/58f202ac'を検索して、それがBaseURL(3)にあるDID識別子が'info:lanl-repo/i/58f202ac'のDIDにあることがわかる。このDIDはOAI-PMHリクエスト[BaseURL(3)?verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&metadataPrefix=DIDL]を発行することにより入手することができる。そして、このDIDからXML IDが'445998'であるアイテムを抽出することができる。
• 識別子 'info:lanl-repo/biosis/abcdef' を持つオブジェクトが要求されたとすると、識別子リゾルバを検索して、それがBaseURL(6)にあるDID識別子が'info:lanl-repo/i/002035b2'のDIDにあることと、このDIDにおいてそれが'444940'というXML IDを持っていることがわかる。この情報から、アプリケーションは要求されたオブジェクトがあるDIDに含まれている資産であると結論づけることができる。このDIDはOAI-PMHリクエスト[BaseURL(6)?verb=GetRecord&identifier=info:lanl-repo/i/002035b2&metadataPrefix=DIDL]を発行することにより入手することができる。そして、このDIDからXML IDが'444940'であるアイテムを抽出することができる。

内容識別子は識別子リゾルバを通じて常にDID識別子に対応付けることができるので、これ以後の議論においてはDID識別子のみを使用する。

表 2に示されている情報に加えて、識別子リゾルバは情報プロバイダが更新版を配布するための資産の場所も把握している。DIDにとっては、与えられたDID識別子に該当するのは常に1つの版のみであろう。しかし、DIDに含まれているコンテンツの更新版が配布されると、通常、新しいDIDが作成され、オリジナルDIDとは別のOAI-PMHリポジトリに格納される。その結果、そのコンテンツの所在情報は変更される。この変更は、関係する内容識別子の所在情報データを更新し、先に存在していた情報を履歴セクションに保存することにより識別子リゾルバに反映される。

5.   LANLリポジトリから資産を配布する

既に述べたように、下流アプリケーションはOAI-PMHハーベスティングによりLANLリポジトリからDIDを得る。これらのアプリケーションはDIDやDIDエンティティ、あるいはもっと普通にはDIDに含まれている資産を参照して、アプリケーションを使用するエージェントがLANLリポジトリから被参照エンティティを取り込めるようにするだろう。保管されている資産の―動的に生成される―様々な形態での配布を容易にするために、MPEG-21 DIP仕様とNISO OpenURLに基づいた解決策が設計された。最初の実装で開発されたこの解決策の様々な側面を本章で説明する。

5.1   DIDエンティティとサービスを結合する: MPEG-21デジタルアイテムメソッド

MPEG-21デジタルアイテム処理（DIP）はDIDの配布に関連するアーキテクチャを規定する。このMPEG-21パートは、未だ標準作業中であるが、DIDやそのエンティティとサービスを結合する方法としてデジタルアイテムメソッド（DIM: Digital Item Method）の概念を導入している。MPEG-21 DIM概念はFedoraの「行動（behavior)」概念 [4,5]と密接な関係があることは触れておく価値がある。DIMは関連するDIDLデータモデルのエンティティとして物理的に同じDIDに入れられる。現在の標準化前の実践において、DIMは通常DIDのコンポーネントエンティティに入れられ、少なくとも次の2つのDIDエンティティを持たねばならない。

• 実際のメソッド、またはその参照を含むリソース（Resource）。MPEG-21 DIPでは、DIMコードはECMAScript言語[16]と近縁関係にある言語を使って表現される。DIPエンジンに関する節で説明されるように、このECMAScriptはサービスを実装するために必要な実コードを全て含んでいるわけではない。むしろ、ECMAScriptはサービス実装プログラムをロードし、調整するために使用される。ECMAScriptは実際に処理を行うプログラムを呼び出すコードを含んでいる。
• DIP XML名前空間のdip:Argument要素の順序列を持つ記述子（Descriptor）。dip:Argument要素はDIMの引数毎に1つ存在する。dip:Argument要素の値は、常にDIDエンティティを識別する。

DIMは、dip:objectType/dip:Argument技法を使ってDIDエンティティと結合される。詳細については[6]で説明されている。

• 専用の記述子を使って、DIP XML名前空間のdip:ObjectType要素をDIDエンティティに与える。
• 前項とは異なる専用の記述子を使って、DIP XML名前空間のdip:Argument要素をDIMに与える。
• DIDにおいて、DIDエンティティのdip:ObjectType要素の値とDIMのdip:Argument要素の値が等しい場合、そのDIMをDIDエンティティに適用することができる。

これは付録AのDIDで示されている。ここでは、あるサービスが値'urn:uuid:8f64eabf-1dd2-11b2-a3f1-0800209a5b6b'により、あるコンポーネントに結合されている。この値は、コンポーネントのdip:ObjectType要素とDIMのdip:Argument要素の両者の値として使用されている。DIPの仕様ではエンティティが2つ以上のdip:ObjectTypeを持つことを認めている。また、DIMは複数のdip:Argument要素を使って2つ以上のエンティティに結合することができる。それぞれのdip:Argument要素はdip:ObjectTypeを経由してエンティティに接続する。先のD-Lib論文[6]発表以後にDIP仕様が変更されたことに言及しておく必要がある。DIDにおける処理方法は今や予約済みのdip:Arguments要素を使って知ることができる。処理方法を含めるために用意された特別なアイテム―処理アイテム―の概念は、もはやサポートされていない。

5.2   LANLリポジトリのDIDエンティティとサービスを動的に結合する: プレースホルダーとDIPテーブル

先の論文[6]で説明したように、著者はLANLリポジトリに保管されるDIDにDIMを静的に埋め込むことには全般的な不安を感じた。それゆえ、保管DIDに実際のDIMの代わりにDIMを指定するプレースホルダーを埋め込むことにした。保管DIDの配布が要求されると、DIDに含まれるプレースホルダーの値に基づいて、DIMインサータ（DIM Inserter）モジュールがDIDにDIMを動的に追加する。その結果、資産と関連するメソッドを含む完成DIDとなる。

プレースホルダーはDIDのコンテナ、アイテム、コンポーネントレベルに置くことができる。コンテナレベルでは、プレースホルダーはDIDが所属する「ファミリー」を伝達する。たとえば、表3に示されているプレースホルダー値 'container:ai' は、DIDがメタデータのみを含んでいることを伝達するために使用されている。この「ファミリー」情報は受入プロセスに密接に関係している。コンポーネントレベルでは、プレースホルダーは含まれるデータストリームのデジタルフォーマットを指定する。デジタルフォーマットのためのグローバルで一意な識別子が出現するのを待って、現在のところは表3の3番目のエントリーに示されているような値が使用されている。この値は、データストリームのメディアタイプとそのフォーマットの性質のおおまかな分類を伝達する。後者は、デジタルフォーマットレジストリー（Digital Format Registry）プロジェクト[17]で開発中のオントロジーに基づいている。アイテムレベルのプレースホルダーの厳密な性格については現在研究中である。プレースホルダー値は、独自に定義したXML名前空間のdiph:PlaceHolder要素を通じてDIDにより伝達される。

DIDへのDIMの実際の挿入は、専用のレジストリであるDIPテーブル（DIP Table）を検索することにより実行される。DIPテーブルはLANLリポジトリにあるDIDエンティティに結合できる全てのサービスをリストアップしている。DIPテーブルにおいて、各サービスはサービス識別子（Service Identifier）を持っている。また、DIPテーブルはサービス毎に―DIDで使われたように―プレースホルダー値を持っており、これを使ってサービスが結合される。たとえば、[表3]の最初のエントリーはサービス識別子'info:lanl-repo/service/table_of_contents'を持つサービスが、プレースホルダー値として'container:ai'または'container:aps'を持つ全てのDIDエンティティと結合されることを示している。DIPテーブルはまた、サービス毎に実際にそれを実装しているDIMコードへのポインタをリストアップしている。

LANLリポジトリのDIMインサータモジュールにより実行されるDIDへのDIMの動的挿入を次の例を使って説明する。これは、[図2]の左側にも図解されている。コンポーネントレベルのプレースホルダー値として'component:content-stream:text:structured-text:mark-up-language:xml#application/marc+xml'を持つDIDを考える。このプレースホルダー値をDIPテーブルで検索すると、サービス識別子が'info:lanl-repo/service/marc_2_mods'で、DIMコードへのポインタが'gov.lanl.library.dip.marctomods'であるサービスが、このDIDに結合していることがわかる。このサービスをDIDに追加しなければならない。これには次の処理が必要である。

• DIMコードへのポインタを参照して、実際のコードをDIDのコンポーネントとして挿入する。これにより、サービス識別子'info:lanl-repo/service/marc_2_mods'もコンポーネントの識別子として挿入される。
• 挿入されたDIMとプレースホルダー値として'component:content-stream:text:structured-text:mark-up-language:xml#application/marc+xml'を持つコンポーネントを結合する。これは、dip:objectType要素を挿入し、それを上で述べたMPEG-21 DIPのdip:ObjectType/dip:Argument技法を使ってDIMと結合することにより行われる。

配布にあたって、DIDに関連する全てのDIMを埋め込むために、上で説明した処理が、DIDに見られる全てのプレースホルダーについて繰り返される。付録 AのDIDでは実際に上の処理をプレースホルダー値'container:aps'と'component:content-stream:text:structured-text:mark-up-language:xml#application/marc+xml'に適用した結果を示している。

図 2: 保管DIDの動的配布

5.3   DIDへのサービスリクエストを処理するためにMPEG-21 DIPエンジンを使用する

MPEG-21 DIPは、エージェントの要求に応えてDIDを処理することができるDIPエンジン（DIP Engine）と呼ばれるコンポーネントを導入している。DIPエンジンは次の情報が含まれているサービスリクエストに応答することができる。

• 実際のDID。
• サービスを要求されたDIDのエンティティの識別。
• DIDに含まれているサービスを実装するメソッド（DIM）の識別。

LANL DIPエンジンの実際の機能を図2に示した。サービスリクエストを受け付けると、DIPエンジンは指定されたDIDエンティティとDIMを抽出する。既に述べたように、DIMはECMAScriptを規範とする言語を使って表現されている。このECMAScriptは要求されたサービスを実装するために必要なコードを全て含んでいるわけではない。実際は、ECMAScriptはDIPエンジンで使用され、要求されたサービスの実装プログラムをロードし、それを調整する。この目的のために、ECMAScriptはいわゆるデジタルアイテムオペレーション（DIO: Digital Item Operations）を呼び出すコードを含んでいる。MPEG-21 DIPでは2つの種類のデジタルアイテムオペレーションを区別している。

• デジタルアイテム基本オペレーション（DIBO: Digital Item Base Operation）: DIBOは、DIOに準拠する全てのDIPエンジンがサポートしなければならないDIOである。現在定義されているDIBOには、XMLレベルでDIDを操作するオペレーション―たとえば、GetDIDLNode―や、幅広い領域、アプリケーション、メディアタイプにおいて一般的に適用できるオペレーション―たとえば、PlayResource―などがある。
• デジタルアイテム拡張オペレーション（DIxO: Digital Item extension Operation）: DIxOは、MPEG-21 DIPでは定義されておらず、特定のコミュニティやアプリケーションレベルで定義されるDIOである。DIxOはDIPエンジンに組み込まれた拡張機構である。

通常、MPEG-21 DIPエンジンは利用者端末で動くクライアント側のソフトウェアコンポーネントであると考えられている。LANLでは、サーバ側で動くDIPエンジンのプロトタイプ実装が開発された。現在のところ、このプロトタイプはMPEG-21で定義されているDIBOの少数をサポートしているだけである。しかし、LANLリポジトリに保管されるコレクションの性格に関連した、あるいは、特有のサービスを実装する様々なDIxOが開発されている。実は、表3に挙げた全てのサービスはDIxOを使って実装されている。また、より多くのDIxOを簡単に作成するためにJavaベースのテンプレートも開発されている。たとえば、あるテンプレートはXSL変換を使用する全てのDIxOの基礎として使うことができる。別のテンプレートは外部アプリケーションを呼び出す必要があるDIxOの基礎として、また別のテンプレートはWebサービスとの連携に使用することができる。

5.4   サービスリクエストを伝達するためにNISO OpenURLを使用する

OAI-PMHハーベスティングにより、下流アプリケーションはDIDを入手し、それに含まれている資産をサービスに利用している。たとえば、検索エンジンは収穫したDIDからテキスト情報を全て抽出して、利用者が検索できるようにするだろう。この場合、簡略な検索結果はLANLリポジトリに保管されている該当の資産へのリンクを示すことになるだろう。明らかに、そのようなリンクにおいて、DID識別子、それに付随するXML ID、内容識別子は決定的な役割を果たすだろう。また、すでに示したように、本アーキテクチャでは、コンテンツを様々な形態で配布することを目的とするいくつかのサービスを定義することも可能にしている。したがって、コンテンツを入手するためのリクエストでは、指定したコンテンツについてどの形態での配布を要求するのかも伝達可能でなければならない。実際のところ、これは、表3で示したように、必要な配布形態を実装するサービスのサービス識別子を伝達することに相当する。多くの下流アプリケーションはWebベースであるので、ここでの議論は、LANLリポジトリへの配布リクエストはHTTPベースのプロセスであると仮定する。

まもなく登場するNISO OpenURL標準[10]は、このような配布リクエストを伝達する完璧なフレームワークを提供することがわかっている。最初のOpenURL仕様[18]は、参照リンキングの目的に特化して導入されたものであり、雑誌論文や図書などのよく知られた種類の学術資料に対する文脈依存の参照リンクの提供を容易にすることを目的としていた[19]。そのため、資料を記述する識別子やメタデータは制限語彙を使用してHTTP GETリクエストでユーザ指定のリンキングサーバに伝達される。リンキングサーバは、知識ベースと送られた情報を使って、その資料に付随する適当なサービスを利用者に提供する。最初のOpenURLソルーション[20]における基本的な要素の一般化がまもなく登場するNISO OpenURL標準の性格を着想させた。この標準は、ネットワーク環境において参照されるあらゆる種類のリソースに関連する文脈依存のサービスを提供するための汎用的なフレームワークを提供するものである。この目的のために、OpenURL標準は、文脈依存のサービスを提供するプロセスに含まれる様々なエンティティの記述を含む情報建築物であるContextObjectの概念を導入している。エンティティを表4に示す。

ContextObjextの各エンティティは、識別子、メタデータ、私的データのいずれかで記述することができる。ContextObjectは多くの方法で表現できるが、現在のところ、キー／符号化値（KEV: Key/Encoded-Value）表現とXML表現が定義されている。ContextObjectの表現を、そこに記述されている被参照体に付随するサービスを要求するために、リゾルバと名付けられているネットワーク上のシステムに転送することができる。そのようなサービスの内容を決定するために、リゾルバは被参照体以外のエンティティを考慮することもできる。ネットワーク上の転送は様々なネットワークプロトコルを使って行うことができるが、現在のところ、HTTPとHTTPSを使った転送が定義されている。

上記のことから、次の2つのマッピングは容易である。

• 配布が要求されたLANLリポジトリの資産 〜 OpenURL ContextObjectの被参照体
• 要求された資産の配布種別 〜 OpenURL ContextObjectのサービス種別

下流アプリケーションから発せられる全ての配布リクエストの送信先となるOpenURLリゾルバがLANLリポジトリに導入された。本稿で先に示した例（表1-3）について、OpenURL標準のHTTP転送とContextObjectのKEV表現を使うと、以下が、このOpenURLリゾルバへ配布リクエストを送る正しいOpenURLである。

• DID識別子が'info:lanl-repo/i/58f202ac'であるDIDの内容一覧を表示する:
      BaseURL(OpenURL Resolver)?
          url_ver=Z39.88-2004&
          rft_id=info:lanl-repo/i/58f202ac&
          svc_id=info:lanl-repo/service/table_of_contents
• DID識別子が'info:lanl-repo/i/58f202ac#445998C1'であるMARCXML [注 7] レコードをMODS[注 8]として表示する:
      BaseURL(OpenURL Resolver)?
          url_ver=Z39.88-2004&
          rft_id=info:lanl-repo/i/58f202ac#445998C1&
          svc_id=info:lanl-repo/service/marc_2_mods

内容識別子もOpenURLリクエストで使用することができる。ただし、内容識別子は常にDID識別子に対応付けることができる（4章参照）ので、ここではDID識別子のみを考える。現在のところ、OpenURLリクエストで使用されるContextObjextエンティティは被参照体とサービス種別のみである。しかし、NISO OpenURLでは配布リクエストに応答する際に考慮することができるその他のエンティティを表現することも可能である。リクエスタ情報の伝達は特に興味深いだろう。これにより、リクエストするエージェントに合せて実際の配布を変更することができるからである。リクエスタ情報でその身元を伝達することができれば、リクエストしているエージェントが人間であるか機械であるかにより、同じ資産に対する同じサービスリクエストに対して、異なるレスポンスをすることが可能になるだろう。また、記録された設定に基づいて各人に異なる配布を提供することも可能であろう。NISO OpenURL仕様は、意図して非常に汎用的かつ拡張性に富むようにしてあるので、リクエスタエンティティを通じて利用者端末の特性や利用者の所在場所を伝達することもサポートするかもしれない。そうなれば、このような情報をDIPエンジンに渡すことにより、実際に配布するものを決める際に考慮することができるだろう。実際のところ、NISO OpenURLの表現力は、リクエスト端末の特性やネットワーク条件、その他のコンテクスト情報を考慮することにより配布の際に資産を変換することを目的とするMPEG-21デジタルアイテムの適応変換（DIA: Digital Item Adaptation）の性格にうまく共鳴するものと思われる。

5.5   MPEG-21 DID、MPEG-21 DIP、NISO OpenURL、OAI-PMHを統合する

この節では上で示した2つのOpenURLリクエストに応答するプロセスを順に説明する。

内容一覧のリクエストは次のステップを踏む。

1. 識別子リゾルバとOpenURLリゾルバの連携により、識別子が'info:lanl-repo/i/58f202ac'の被参照体はbaseURLが"BaseURL(3)"であるOAI-PMHリポジトリにあるDIDであることがわかる（表1参照）。
2. OpenURLリゾルバは該当するOAI-PMHリポジトリにOAI-PMHのGetRecordリクエスト [BaseURL(3)?verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&metadataPrefix=DIDL]を発行して、このDIDを入手する。
3. OpenURLリゾルバは入手したDIDをDIMインサータへ渡す。DIMインサータは、DIDに含まれているプレースホルダー値に基づいてDIPテーブルを検索して、DIDにDIMを動的に追加する。
4. DIMインサータは完成DID（付録A参照）をOpenURLリゾルバに返す。
5. OpenURLリゾルバは、完全DID、被参照体の識別子、サービス種別の識別子をDIPエンジンに渡す。実際は、これらの識別子はDIDにおけるそれぞれの識別子の位置を表すXPathの形でDIPエンジンに渡される。しかし、簡単のため、この例では実際の識別子を使って説明を続ける。
6. DIDを検査して、DIPエンジンは識別子'info:lanl-repo/service/table_of_contents'を持つ要求されたサービスが、識別子が'info:lanl-repo/i/58f202ac'のDIDエンティティに適用できるか否かを決定する。これは、dip:ObjectType/dip:Argumentの対応をチェックすることで実行される。
7. サービスが実際に適用可能だと仮定すると、適当なDIMがDIDから抽出され、DIPエンジンにより実行される。このDIMは実際にXML DIDからXHTML形式の内容一覧に変換するDIxOを呼び出す。
8. DIPエンジンはXHTML形式の内容一覧をOpenURLリゾルバに返す。

MARCXMLからMODSへの変換リクエストに関しては、このOpenURLリクエストへの応答プロセスは、次のような微妙な差異を除いて、上で述べたものと同じである。

1. 被参照体の識別子である'info:lanl-repo/i/58f202ac#445998C1'から、OpenURLリゾルバは、被参照体が、DID識別子が'info:lanl-repo/i/58f202ac'であるDIDに含まれているXML IDが'445998C1'であるDIDエンティティであることがわかる。このDIDは上で説明したステップ1と2で入手することができる。
2. 残りのプロセスは上のステップ3から8で説明したものである。この例は、DID全体ではなく、特定のDIDエンティティに関するものであるので、使用されるDIxOはDID全体ではなく該当するDIDの抽出に関する操作を行うことになる。

6.   結論

本稿では、LANLリポジトリのアーキテクチャのうち、複合オブジェクトとそれに含まれる資産の配布に関係する側面を説明した。このアーキテクチャでは、NISO OpenURLは配布リクエストを符号化するために使用されている。これは、これまでとはレベルの異なる新しいOpenURLの実用的使用法である。実際、OpenURLは現在のところ、被参照リソースを記述するメタデータに基づいてサービスを提供するためにしか使われていない。本アーキテクチャでは、サービスはリソース自身に基づいている。NISO OpenURLは汎用的で拡張性に富むので、文脈依存の配布リクエストを表現するための柔軟なフレームワークを提供する。著者は、本アーキテクチャにおいてNISO OpenURLの使用法のほんの一例を示しただけであるが、MPEG-21 DIPおよび潜在的にはMPEG-21 DIAと非常に相性が良いと述べることは正当であると思われる。

NISO OpenURLは別の意味でも魅力的である。OpenURLフレームワークは、OpenURLリクエストに応答する際に独自の処理をすることができるOpenURLリゾルバが数多く存在することを、重要な前提の1つとしている。通常、この処理はリゾルバを稼動するコミュニティの性格や好みに基づいている。本アーキテクチャは最初から分散指向かつプロトコルベースであるという性格から、これをWeb環境に配備した場合を想像することができる。すると、LANLリポジトリとして説明してきたものは、Web上に分散して存在するOAI-PMHリポジトリの連合となる。そのような連合において、リポジトリインデックスや識別子リゾルバ、OAI-PMHフェデレータなどのコンポーネントはLANLリポジトリの環境で説明したものと非常に似た役割を果たすことができる。この連合内の機関ごとにOpenURLリゾルバが設置されることは容易に想像することができるだろう。学術コミュニティにおいて参照リンキングとして成功裏に配備されたOpenURLフレームワークの例のように、利用者は所属機関のOpenURLリゾルバに配布リクエストを送ることになるだろう。機関のリゾルバは、連合内の適当なOAI-PMHリポジトリから保管複合オブジェクトを得ることにより、そのようなリクエストに応答することになるだろう。そして、本稿で説明したDIMインサータにより実行されるものと同じプロセスにより、ローカルで定義したサービスをオブジェクトに付加することができるだろう。実際、デジタルフォーマットのためのグローバルで一意な識別子の存在を仮定すると、デジタルフォーマットに基づくそのようなサービスの追加を想像することはそれほど難しくない。その結果、同じコンテンツに対して連合の機関がそれぞれの好みで異なる配布方法を実装することができる1つのフレームワークを作り出すことになる。

謝辞

著者一同は、報告書作成に対する貢献に対してLANLデジタルライブラリ研究およびプロトタイプ作成チームの同僚であるHenry Jerez、Xiaoming Liu、Thorsten Schwanderの各氏に感謝いたします。また、LANL図書館長Rick Luceの変わらぬ支援に感謝いたします。Jeroen Bekaertはさらに、PhD奨学金を頂いた科学研究基金（フランダース、ベルギー）に感謝いたしたいと思います。

参考文献

1. Bollen, J. and Luce, R. "Evaluation of Digital Library Impact and User Communities by Analysis of Usage Patterns," D-Lib Magazine, Volume 8, Number 6, June 2002. http://dx.doi.org/ 10.1045/june2002-bollen

2. Van de Sompel, H., Young J. and Hickey T. "Using the OAI-PMH ... Differently," D-Lib Magazine, Volume 9, Number 7/8, July/August 2003. http://dx.doi.org/10.1045/july2003-young

3. Smith M. et al. "DSpace An Open Source Dynamic Digital Repository", D-Lib Magazine, Volume 9, Number 1, January 2003. http://dx.doi.org/10.1045/january2003-smith

4. Payette, S. and Lagoze, C. "Flexible and Extensible Digital Object and Repository Architecture," Second European Conference on Research and Advanced Technology for Digital Libraries, Heraklion, September 1998. http://www.cs.cornell.edu/payette/papers/ECDL98/FEDORA.html

5. Staples, T., Wayland, W. and Payette S. "The Fedora Project: An Open-Source Digital Object Repository System," D-Lib Magazine, April 2003. http://dx.doi.org/10.1045/april2003-staples

6. Bekaert, J., Hochstenbach, P. and Van de Sompel, H. "Using MPEG-21 DIDL to Represent Complex Digital Objects in the Los Alamos National Laboratory Digital Library," D-Lib Magazine, Volume 9, Number 11, November 2003. http://dx.doi.org/10.1045/november2003-bekaert.

7. Lagoze, C., Van de Sompel, H., Nelson, M. and Warner, S. "The Open Archives Initiative Protocol for Metadata Harvesting - Version 2.0," 2003. http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm

8. MPEG-21, Information Technology, Multimedia Framework, "Part 2: Digital Item Declaration," ISO/IEC 21000-2:2003, March 2003.

9. MPEG-21, Information Technology, Multimedia Framework, "Part 10: MPEG-21 Digital Item Processing," ISO/IEC JTC1/SC29/WG11, N6173, Hawaii, December 2003.

10. NISO committee AX. "The OpenURL Framework for Context-Sensitive Services," ANSI/NISO Z39.88-2004, November 2003. http://library.caltech.edu/openurl/StandardDocuments/Part1-Ballot-20031111.pdf （訳注: リンク切れ）

11. Sun, S., et al. "Handle System Overview. Internet Engineering Task Force (IETF) Request for Comments (RFC), RFC 3650", November 2003. http://hdl.handle.net/4263537/4069

12. MPEG-21, Information Technology, Multimedia Framework , "Part 3: Digital Item Identification," ISO/IEC 21000-3:2003, March 2003.

13. W3C, "Proposal for XML Fragment Identifier Syntax 0.9," Working Group Note, Sept 2003. http://www.w3.org/TR/xml-fragid/

14. Van de Sompel, H., Hammond, T., Neylon, E., and Weibel S.L. "The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces", December 2003. http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-01.txt （訳注: リンク切れ）
    （現在は、2004, July 9のhttp://info-uri.info/registry/docs/drafts/draft-vandesompel-info-uri-02.txtが利用可能）

15. W3C, "SOAP Version 1.2 Part 1: Messaging Framework", Recommendation, June 2003. http://www.w3.org/TR/SOAP/

16. ECMA-262, "ECMAScript Language Specification, 3rd Edition," December 1999. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

17. Abrams, S. L. and Seaman, D. "Towards a global digital format registry," World Library and Information Congress: 69th IFLA General Conference and Council, Berlin, August 1-9, 2003. http://www.ifla.org/IV/ifla69/papers/128e-Abrams_Seaman.pdf

18. Van de Sompel, H., Hochstenbach, P. and Beit-Arie, O. "OpenURL Syntax Description," 2000. http://www.openurl.info/registry/docs/pdf/openurl-01.pdf

19. Van de Sompel, H. and Beit-Arie, O. "Open Linking in the Scholarly Information Environment Using the OpenURL Framework," D-Lib Magazine, Volume 7, Number 3, March 2001. http://dx.doi.org/10.1045/march2001-vandesompel

20. Van de Sompel, H. and Beit-Arie, O. "Generalizing the OpenURL Framework beyond References to Scholarly Works," D-Lib Magazine, Volume 7, Number 3, March 2001. http://dx.doi.org/10.1045/july2001-vandesompel

21. MPEG-21, Information Technology, Multimedia Framework, "Part 2: Digital Item Adaptation," ISO/IEC JTC1/SC29/WG11, N5845, Trondheim, July 2003.

注

1. MPEG-21 DIDL Working Draft: http://xml.coverpages.org/MPEG21-WG-11-N3971-200103.pdf

2. MPEG-21 DIDL Working Draft Schema: http://download.webct.com/public/ims/2.0/MPEG21.xsd

3. LANL DID: http://lib-www.lanl.gov/proto/MPEG-21/

4. DOI: http://www.doi.org/

5. Dublin Core Metadata Initiative, Dublin Core, http://dublincore.org/

6. info URI Registry: http://info-uri.info/registry/

7. MARC 21 XML Schema, http://www.loc.gov/standards/marcxml/

8. Metadata Object Description Schema, http://www.loc.gov/standards/mods/

付録 A: DIDエンティティに結合するDIMを含むDIDの例

先頭 | 目次
検索 | 著者索引 | タイトル索引 | バックナンバー
意見 | 次の論文
ホーム | 編集者へのメール

D-Lib Magazine Access Terms and Conditions

DOI: 10.1045/february2004-bekaert