Herbert Van de Sompel, Jeroen Bekaert, Xiaoming Liu, Luda Balakireva, Thorsten Schwander
ロスアラモス国立研究所研究図書館
{herbertv, jbekaert, liu_x, ludab, schwander}@lanl.gov
本稿は、ロスアラモス国立研究所研究図書館において、デジタルオブジェクトの膨大なコレクションを受入・保管・アクセス提供を行うために設計・実装されたaDOReリポジトリのアーキテクチャを説明する。aDOReアーキテクチャは高度にモジュール化されており、各種標準をベースとしている。本アーキテクチャでは、XMLベースのフォーマットとしてMPEG-21デジタルアイテム宣言言語(Digital Item Declaration Language)を使用して、複数のデータストリームを持つことができるデジタルオブジェクトを開放型アーカイブ情報システム(OAIS: Open Archival Information System)保管用情報パッケージ(AIP: Archival Information Package)として表現している。このOAIS AIPは、受入プロセスにおいて複数の自立リポジトリに格納される。リポジトリインデックス(Repository Index)は、全ての自立リポジトリの生成と配置場所を把握しており、識別子ロケータ(Identifier Locator)は、任意のデジタルオブジェクトやOAIS AIPがどの自立リポジトリに存在するかを記録している。OAIS配布用情報パッケージ(DIP: Dissemination Information Package)を要求するための全システム環境へのフロントエンドとして、OAI-PMHフェデレータ(OAI-PMH Federator)が導入された。このOAIS DIPは、保管されているOAIS AIP自体、あるいはそれを変換したものである。このフロントエンドは、OAI-PMHハーベスタがaDOReから大量のOAIS DIPを反復的・選択的に収集して、収集したオブジェクトを使って多様なサービスを開発することを可能とする。OAIS結果セット(OAIS Result Sets)を要求するために、もう一つのフロントエンド、OpenURLリゾルバ(OpenURL Resolver)が導入された。OAIS結果セットとは、個々のデジタルオブジェクトやそれを構成するデータストリームの配布形態である。両フロントエンドは、MPEG-21デジタルアイテム処理エンジン(MPEG-21 Digital Item Processing Engine)を使用して、OAIS AIPやデジタルオブジェクト、構成データストリームに配布リクエストで指定されたサービスを適用する。
ロスアラモス国立研究所(LANL)研究図書館は、デジタル学術情報へのアクセスの提供方法について、多くの学術図書館や研究図書館と比べてやや独特な戦略を採用している。サードパーティが提供するサービスを利用し、自館で運用するWebポータルを通じて、外部で保管されている資料を利用者が統合的にアクセスできるようにすることがデジタルライブラリサービスの一般的な傾向である。LANL図書館は、研究に不可欠な学術情報に関して独自に対応するために、大量のデジタル学術資産コレクションを購入あるいはライセンスを取得し、これらの資産をローカルで管理し、独自に開発した利用者サービスを通じてアクセスを提供している。ローカルで管理している資産には、BIOSISやInspec、Thomson Scientificが提供する二次情報や、米国物理学会や英国物理学会出版局、Elsevier、Wileyなどの主要な学術出版社が提供する一次資料がある。
本稿執筆時点で、研究所が管理している資産のコレクションはおおよそ8千万件にのぼる。多くの場合、これらの資産は、全体で1つの論理ユニットを形成する複数のデータストリームで構成されているという意味で複合的なものである。そのような論理ユニットとしては、たとえば、次の要素からなる学術出版物が挙げられる。
話を明確にするために、本稿では、資産をデジタルオブジェクト、資産を構成する個々のデータストリームを構成データストリームと呼ぶことにする。
このように様々な種類の膨大なデジタルオブジェクトのコレクションを整合的かつ持続的に管理・保管して、アクセスを提供することは、デジタルライブラリの実践や研究の多くの分野―デジタルオブジェクトや構成データストリームの識別、デジタルオブジェクト間の関係の表現、オブジェクトモデルによるデジタルオブジェクトの表現、デジタルオブジェクトを受入・保管・アクセスする方法など―に関わる挑戦である。
過去2年間、LANL研究図書館のデジタルライブラリ研究およびプロトタイプ作成チームは、ますます増加を続ける様々な種類のデジタルコレクションを受入・保管し、下流アプリケーションにアクセスを提供することを目的とするaDOReリポジトリのアーキテクチャの設計に取り組んできた。第1バージョンの設計が実装され、本番運用に供されているが、現在、より堅牢な第2バージョンの実装作業が進められている。
aDOReの設計は、LANL研究図書館の要求から着想されたものであったが、このアーキテクチャはリポジトリに関する他のプロジェクトにとっても魅力的であるに違いない次のような性質を持っていると著者は考えている。
aDOReアーキテクチャの主要コンポーネントを図1に示した。全てのコンポーネントは後ほど詳細に説明するが、以下にその概要を示す。
この図において、受入プロセスは右端に、リポジトリを使用する下流アプリケーションは左端に、それぞれ示されている。
図 1. aDOReアーキテクチャ
aDOReに受け入れられる資産は複合的性質を持っているので、開放型アーカイブ情報システム[21]保管用情報パッケージ(OAIS AIP)として機能する1つのラッパー構造に構成データストリームをラップする既存のアプローチを研究する必要があった。そしてすぐにXMLラッパーにより資産を表現することに興味を持つようになり、その結果、aDOReの資産をデジタルオブジェクトとして表現する唯一の方法としてMPEG-21デジタルアイテム宣言(MPEG-21 DID[17, 43])を選択することになった。競合する仕様の中からMPEG-21 DIDを選択した理由はいくつか存在する。他の仕様とは異なり、MPEG-21 DIDは様々な技術を使ってインスタンス化が可能なデータモデルを定義している。現在のところ、バイナリインスタンス化とXMLスキーマに基づくインスタンス化の2つの方法が存在するだけであるが、将来には、たとえば、RDFベースのインスタンス化の定義が登場することを想像できるだろう。このアプローチは、アーキテクチャの基本的概念を保ったまま、様々に進化する技術環境に対応して実装を行うことを可能とする。また、MPEG-21 DIDは、コミュニティを横断する相互運用性を強いるアプローチを採用する一方で、標準に準拠したコミュニティ独自のプロファイルの存在にも柔軟に対応する。XMLスキーマによるインスタンス化は驚くほど洗練され単純であり、ツールの開発を非常に簡単にしている。さらに、MPEG-21 DIDはMPEG-21デジタルアイテム識別(MPEG-21 DII)と組み合わせることで識別子を処理する一義的な方法を提供するが、これは他の仕様には明らかに欠けている主要な機能となっている。そして、重要なことであるが、MPEG-21 DIDはコンテンツ産業やテクノロジ産業の中心人物により制定されたISO標準であり、このことは標準の採用や準拠ツールの登場に関して大きな保証を与えるものである。
MPEG-21 DIDは、デジタルオブジェクトのための明確に定義された抽象モデルを形成する1組の抽象概念を導入している。この抽象概念に基づいて、MPEG-21 DIDはデジタルアイテム宣言言語(MPEG-21 DIDL: Digital Item Declaration Language)を定義している。これは、MPEG-21 DID抽象モデルをXMLで表現したものであり、デジタルオブジェクトをXMLベースで表現する際に大きな柔軟性と拡張性を提供する。MPEG-21 DIDL XML構文に従って表現されたデジタルオブジェクトはDIDLドキュメントと呼ばれる。MPEG-21 DIDに関してより詳しい情報に興味のある読者は[4]を参照されたい。MPEG-21 DID抽象モデルについて、以下に簡単に説明する。また、図2にも示した。モデルではいくつかのMPEG-21 DIDエンティティ(太字で示した)を認識する。各エンティティはDIDL XMLスキーマ[43]において該当するXML要素を持っている。XML要素は<>で示している。
図 2. MPEG-21 DID仕様に準拠するドキュメント構造の例
LANLでは、aDOReに保管されるデジタルオブジェクトを、FTPやOAI-PMHリソースハーベスティング[42]、Webクローリング、物理媒体による配布など、原則として様々な方法で入手している。そのため、各デジタルオブジェクトをMPEG-21 DID仕様に従って表現する受入プロセスが開発された。これにより、デジタルオブジェクトを表現するOAIS AIPとして機能するDIDL XMLドキュメントが作成される。
OAISからヒントを受けたaDORe環境の重要な特徴は、受入済みのデジタルオブジェクトの新しい版を受け入れる必要がある場合には常に新版用の新しいDIDLドキュメントが作成されることである。既存のDIDLドキュメントは更新も編集も決してされることはない。デジタルオブジェクトの新版が生じるのは、たとえば、情報プロバイダが更新版を配布した場合や、デジタル保存戦略によりデジタルオブジェクトに使用するファイルフォーマットの移行が必要な場合などである。後で説明するように、識別子ロケータがデジタルオブジェクトの全ての版を把握している。
DIDLドキュメントがそのデジタルオブジェクトの構成データストリームを持つ方法には、物理的に持つ方法と参照で持つ方法がある。DIDLドキュメントは識別子を持つと同時に、所属するコレクションやXML署名構造体、構成データストリームに関するメディアフォーマット情報、履歴情報などの情報も持っている。LANLリポジトリにおけるMPEG-21 DIDLの実際の使用法やLANL DIDLプロファイルについては、少し古い[1]やもう少し新しい[4]にいくらか詳しく説明されている。
表1に示したデジタルオブジェクトのサンプル(学術論文)を表現するDIDLドキュメントを付録Aに示した。
種類 | MIME | 識別子 | |
---|---|---|---|
デジタルオブジェクト | 学術論文 | 該当なし | DOI |
構成データストリーム1 | メタデータレコード | application/xml | PMID |
構成データストリーム2 | フルテキストファイル | application/pdf | - |
表1. デジタルオブジェクトのサンプルの構成要素
aDORe環境で使用される識別子の意味と使用法を十分に理解するには、その設計から理解することが重要である。aDOReは、以下に述べる2つの識別メカニズムを並行して使用している。この識別アプローチを上で示したデジタルオブジェクトのサンプルを使って示したのが図3である。
内容識別子(Content Identifier)。内容識別子は、OAIS[15]が内容情報識別子として分類しているものに対応する。内容識別子は、aDOReに受け入れられる前からデジタルオブジェクトに元々付けられていた識別子に直接関係するものである。多くの場合、デジタルオブジェクトやその構成データストリームは、それが作成あるいは出版された際に付与された識別子を持っている。内容識別子はaDOReではURIで表現される。上のデジタルオブジェクトのサンプルでは、次の内容識別子が存在する。
受入プロセスにおいて、トップレベルの<Item>要素に<Descriptor/Statement>構造体が付けられ、この中で、MPEG-21 DII XML名前空間[3, 18]の<Identifier>要素を使ってデジタルオブジェクトの内容識別子が伝達される。付録Aのデジタルオブジェクトのサンプルでこれを見ることができる。この例では、トップレベルの<Item>要素は内容識別子‘info:doi/10.123/44455’を持っている。先に述べたように、受入プロセスでは、内容識別子を持つ全てのデジタルオブジェクト構成データストリームのためにサブ<Item>要素が作成される。付録Aのデジタルオブジェクトのサンプルでこれを見ることができる。この例では、サブ<Item>要素は学術論文を記述するメタデータを含み、メタデータの内容識別子‘info:pmid/2225887’は、これもMPEG-21 DII XML名前空間の<Identifier>要素を使って伝達されている。PDFファイルは内容識別子を持っていないので受入プロセスではこれを、<Identifier>要素を持たない<Component>要素にマップしている。<Component>要素はトップレベル<Item>の子要素である。
パッケージ識別子(Package Identifier)。デジタルオブジェクトを表すDIDLドキュメントは、aDOReにおいてはOAIS AIPの役割を果たしている。受入プロセスにおいて、このDIDLドキュメント自体に、OAISでは保管用情報パッケージ識別子と分類されるグローバルに一意な識別子が与えられる。このパッケージ識別子は、LANL DIEXT名前空間の<DIDid>属性を<DIDL>ルート要素に付けることで伝達される。その値は、UUIDアルゴリズム[22]を使って構成され、LANL研究図書館がinfo URIスキーム[40]に登録した予約済みの副名前空間‘info:lanl-repo/’名前空間を使ったURIで表現される。また、受入プロセスにおいて、<Container>、<Item>、<Component>の各要素には、これもUUIDアルゴリズムを使って作成されるグローバルに一意なXML IDが与えられる。その結果、これらのXML要素は、それが含まれるDIDLドキュメントのパッケージ識別子と自身のXML IDの組み合わせで、グローバルに指定することが可能となる。上で示したデジタルオブジェクトのサンプルにおけるこの指定メカニズムは次のとおりである(読みやすいように、UUID値は短縮してある)。
図 3. 並行した識別メカニズムを提供する内容識別子とパッケージ識別子
受入プロセスでは、配布された各デジタルオブジェクトをDIDLドキュメントに変換する。通常、これらのDIDLドキュメントは、デジタルオブジェクトのメタデータデータをXMLで表現した構成ストリームを物理的にインラインで持っている。DIDLドキュメントのサイズを小さく保つために、また、処理をしやすくするために、デジタルオブジェクトのその他の構成データストリームは参照で提供され、物理的にはインターネットアーカイブのARCファイル[5]に格納される。各DIDLドキュメント自体は、aDORe環境に存在する多くの自立OAI-PMHリポジトリの1つに保管される。
OAI-PMH(Open Archives Protocol for Metadata Harvesting)は、障壁の低い、HTTPベースのプロトコルである。このプロトコルは、XMLメタデータを増分ハーベストできるように仕様が定められている。OAI-PMHリポジトリは、プロトコル仕様書に規定されている方法で6つのOAI-PMHリクエストを処理して応答することができるネットワークアクセス可能なサーバである。ハーベスタは、OAI-PMHリクエストを発行してXMLメタデータを収穫するアプリケーションである。OAI-PMHは、6つのリクエストの動作を明確に指定できるデータモデルに基づいている。OAI-PMHリポジトリがメタデータを公開する対象であるリソースがデジタルコンテンツの場合の、データモデルを図4に示した。以下では、OAI-PMHエンティティは太字で、OAI-PMHリクエストはcourierフォントで示す。
図 4. OAI-PMHデータモデル
OAI-PMHは、ハーベスタがOAI-PMHリポジトリの性格を理解できるようにするために次の3つのリクエストを定義している。
OAI-PMHは、XMLメタデータを実際に収穫するためにさらに次の3つのリクエストを定義している。
OAI-PMHはその起源がリソース発見の分野にあったので、ダブリンコア[30]メタデータフォーマットのサポートを必須としているが、より表現力に富むフォーマットのサポートも強く奨励されている。その結果、XMLスキーマ[10]を使って定義されている限り任意のメタデータフォーマットを使用することができる。代表的な利用例では、公開されているメタデータは記述的メタデータであり、シンプルダブリンコアやMARCXML[24]など複雑性が異なる様々なメタデータフォーマットで表現されている。しかし、aDOReにおける自立OAI-PMHリポジトリは、メタデータフォーマットとしてMPEG-21 DIDLを使用し、DIDLドキュメントをメタデータとしてハーベスタに公開することにより、デジタルオブジェクトをより詳しく正確に記述するメタデータをサポートしている。
各自立OAI-PMHリポジトリは次のような特徴を持つ。
従って、インデックスエンジンのような下流のサービスプロバイダにより運用されるハーベスタは、OAI-PMHの選択的ハーベスティング機能(日付スタンプとセット)を使って、自立OAI-PMHリポジトリからOAIS AIPを反復的に収集することができる。OAIS AIPは決して更新されないので、増分ハーベスティングでは新しく追加されたOAIS AIPだけを提供することになる。
通常、情報プロバイダは定期的にかなりの量の追加情報や更新情報をLANLに一括して納入する。この場合、一括納入毎に1つの自立OAI-PMHリポジトリが作成され、専用のストレージメカニズムであるXMLtapeが使用される。XMLtapeとは、大量のDIDLドキュメントを連結した妥当な整形式のXMLファイルである。XMLtapeをOAI-PMHリポジトリに変換する専用のソフトウェアが開発された[44]。受け入れたデジタルオブジェクトを格納する方法としてXMLtapeとインターネットアーカイブのARCファイルを組み合わせて使用する方法については[37]で説明されている。
既に示したように、更新データは自立OAI-PMHリポジトリから収穫することができる。しかしながら、自立OAI-PMHリポジトリの存在、追加、場所をハーベスタはどのようにして知るのかといった疑問にはまだ解答が示されていない。この重要な情報を提供するためにリポジトリインデックス(Repository Index)が導入された。
リポジトリインデックスは、aDORe環境にある各自立OAI-PMHをエントリーとして持ち、次の情報を保持している。
このうち最初の2つの情報要素が、各々OAI-PMHのidentifierとdatestampの概念に直接対応することは見落とすことはできない。実際、aDOReでは、リポジトリインデックス自体も次の属性を持つOAI-PMHリポジトリとして公開されている。
サービスプロバイダのために働くハーベスタは、aDORe環境からDIDLドキュメントを収集して、それに含まれるデジタルオブジェクトを使ってサービスを構築する。その結果、収穫されたDIDLドキュメントに含まれている識別子は、検索エンジンなどのアプリケーションで利用できるようになる。2.2節で説明したように、これらの識別子は、DIDLドキュメントやそれに含まれているDIDL XML要素を識別するパッケージ識別子か、デジタルオブジェクトや構成データストリームを識別する内容識別子のいずれかである。最も重要なことは、そのような識別子を下流アプリケーションが見つけた場合に、その識別されたリソースがaDORe環境から入手できることである。この目的を果たすために、識別子ロケータ(Identifier Locator)が導入された。識別子ロケータは、aDORe環境から次のような識別子関連情報を収集する。
パッケージ識別子 | OAI-PMHリポジトリ |
---|---|
info:lanl-repo/i/58f202ac | BaseURL(3) |
info:lanl-repo/i/002035b2 | BaseURL(6) |
表2. 識別子ロケータのパッケージ識別子モジュール
内容識別子 | パッケージ識別子 | XML ID |
---|---|---|
info:doi/10.123/44455 | info:lanl-repo/i/58f202ac | uuid-00005e90 |
info:pmid/2225887 | info:lanl-repo/i/58f202ac | uuid-8881b35e |
info:lanl-repo/biosis/abcdef | info:lanl-repo/i/002035b2 | uuid-00007y55 |
info:pmid/2225887 | info:lanl-repo/i/12e303be | uuid-875646ae |
表3. 識別子ロケータの内情識別子モジュール
初期設定では、識別子ロケータは自立OAI-PMHリポジトリから反復的にOAI-PMHハーベスティングを行うことによりレコードを収集するが、大量のデジタルオブジェクトを受け入れる場合に備えて、より高速な一括ロードメカニズムが実装された。下流アプリケーションは、識別子ロケータにハンドルプロトコル[36]を通じてアクセスすることができる。今後、SOAPベース[12]のSRW[27]インターフェースが実装される予定である。アプリケーションは識別子ロケータに問い合わせることで、特定のパッケージ識別子を持つDIDLドキュメントあるいは特定の内容識別子を持つリソースを持つDIDLドキュメントをOAI-PMHで入手するために必要な情報を得ることができる。これは、次の手順で処理される。
[BaseURL(3)?verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&metadataPrefix=DIDL]
を発行することにより得ることができる。[BaseURL(3)?verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&metadataPrefix=DIDL]
を発行することにより得ることができ、入手したDIDLドキュメントからXML IDが‘uuid-00005e90’のXML要素を抽出することができる。[BaseURL(6)?verb=GetRecord&identifier=info:lanl-repo/i/002035b2&metadataPrefix=DIDL]
を発行することにより得ることができ、入手したDIDLドキュメントからXML IDが‘uuid-00007y55’のXML要素を抽出することができる。このアプローチは内容識別子からパッケージ識別子へのマッピングを可能とする。保管DIDLドキュメント、デジタルオブジェクト、構成データストリームの様々な形態での配布を容易にするために、独立したコンポーネントがaDORe環境に導入された。このコンポーネント、デジタルアイテム処理エンジン(Digital Item Processing Engine)は、現在標準化作業中であるMPEG-21デジタルアイテム処理(MPEG-21 DIP: MPEG-21 Digital Item Processing)仕様[8]の最新版に従って動作する。MPEG-21の定義により、MPEG-21 DIPエンジンは、デジタルオブジェクトやその構成データストリームにサービスを適用することができる。本稿執筆の時点では、MPEG-21 DIP仕様はDIDLドキュメント全体に対するサービス適用方法については規定していない。aDORe環境ではこの機能が必要であるので、MPEG-21 DIP仕様の次版あるいは修正条項による標準化された解決策が現れるまでの間、5.2節で説明する実用的な解決策を導入した。
MPEG-21デジタルアイテム処理(MPEG-21 DIP)は、MPEG-21 DID抽象化モデルのコンテナ、アイテム、コンポーネントの配布に関連するアーキテクチャを規定する。この目的のために、MPEG-21パート10は、デジタルアイテムメソッド(DIM: Digital Item Method)という概念を導入した。これは、概念上、Fedoraの「行動(behavior)」概念[34, 35]と密接な関係があるものである。DIMは、関連するMPEG-21 DID抽象化モデルのエンティティとして、物理的に同じDIDLドキュメントの中に入れられる。現行の標準化前の実践において、DIMは通常<Component>要素に入れられ、少なくとも次の2つの子構造体を持たねばならない。
少し古くなったが[1]で説明されているように、DIMは、<Descriptor/Statement>技法を使って、DIDLドキュメントのXML要素と結合される。
この方法は付録Bに示されているDIDLドキュメントにおいて強調表示されている。この例では、サービスは値‘urn:uuid:8f64eabf’を経由して<Component>要素に結合されている。この値は、<Component>の<ObjectType>要素の内容とDIMの<Argument>要素の内容の両者に使用されている。MPEG-21 DIP仕様では、エンティティが2つ以上の<ObjectType>を持つことを認めている。また、DIMは複数の<Argument>要素を使って2つ以上のエンティティに結合することができる。それぞれの<Argument>要素は<ObjectType>を経由してエンティティに接続する。
これまでの説明からわかるように、MPEG-21 DIPエンジンは、aDORe環境に保管されているデジタルオブジェクトやその構成データストリームを様々な形態で配布する機能を導入する。残念ながら、本稿執筆時点において、MPEG-21 DIPエンジン仕様にはDIDLドキュメント自体にサービスを適用する方法が含まれていない。保管DIDLドキュメントを変換して配布するために、aDORe環境ではそのようなサービスが重要である。実用的な変換には、DIDLからMETS[25]やIMS-CP[13]など他の複合オブジェクトフォーマットへのマッピングや、識別子ロケータへのレコードの追加を容易にする、保管DIDLドキュメントから識別子関連情報のみを含むXML文書への変換などがある。DIDLドキュメント全体へのサービス適用機能がMPEG-21 DIP仕様に追加されるまでの間、aDORe環境には実用的な解決策が導入された。それは、受入プロセスにおいて全てのDIDLドキュメントに人工的に追加される<Container>要素のレベルにそのようなサービスを全て埋め込むという方法である。
aDOReでは、自立OAI-PMHリポジトリに保管されているDIDLドキュメントにDIMは埋め込まれていない。DIMを埋め込むと、新しいメソッドが登場したり、既存のメソッドが更新されるたびに、新しいDIMを追加したり、既存のDIMを編集したりするために、保管DIDLドキュメントを頻繁に更新する必要が生じるだろう。aDOReの予想される規模を考えると、実行するとすればその管理経費は莫大なものになるだろう。また、aDOReに現在保管されているコンテンツの静的な性格や、何らかの形の編集が行われた際に既存のDIDLドキュメントを更新する代わりに新しいDIDLドキュメントを作成するという先に説明した戦略にとって、定期的に保管DIDLドキュメントに「触れる」ことはふさわしいものではない。それゆえ、aDOReでは、DIDLドキュメントの内容に基づいてDIMを動的に挿入する処理を行っている。このアプローチの現行の実装では、受入プロセスにおいて、実際のDIMの代わりにDIMを指定する「プレースホルダー」を保管DIDLドキュメントに埋め込んでいる。保管DIDLドキュメントの配布を要求されると、DIDLドキュメントに含まれているプレースホルダーの値に基づいて、DIMインサータ(DIM Inserter)モジュールがDIDLドキュメントにDIMを動的に追加する。その結果、保管DIDLドキュメントに現れる全てのリソースと関係する全てのメソッドを含む、いわゆる完成DIDLドキュメントとなる(付録B参照)。DIMインサータは、[9]で説明されている「コンテキスト・ブローカー(context broker)」メカニズムにある程度似ていることに注意するべきである。
プレースホルダー値はダブリンコア要素セット[29]の<format>要素によりDIDLドキュメントに組み込まれる。プレースホルダーはDIDLドキュメントのコンテナ、アイテム、コンポーネントレベルに置くことができる。
DIDLドキュメントへのDIMの実際の挿入は、専用のレジストリであるDIPテーブル(DIP Table)を検索することにより実行される。DIPテーブルはaDORe環境に保管されているDIDLドキュメント、デジタルオブジェクト、構成データストリームに結合できる全てのサービスをリストアップしている。DIPテーブルにおいて、各サービスはサービス識別子(Service Identifier)を持っている。また、DIPテーブルはサービス毎に(DIDLドキュメントで使われたように)プレースホルダー値を持っており、これを使ってサービスが結合される。たとえば、表4の最初の2つのエントリーは、サービス識別子‘info:lanl-repo/service/table_of_contents’を持つサービスが、プレースホルダー値として‘info:lanl-repo/pro/ai’あるいは‘info:lanl-repo/pro/paper’を持つ全てのMPEG-21 DIDエンティティと結合されることを示している。 DIPテーブルはまた、サービス毎に実際にそれを実装しているDIMコードへのポインタをリストアップしている。
サービス識別子 | info:lanl-repo/service/table_of_contents |
プレースホルダー値 | info:lanl-repo/pro/ai |
DIMコードへのポインタ | http://purl.lanl.gov/dip/methods/toc.js |
説明 | 全ての構成データストリームとそれが利用できるサービスをリストアップするデジタルオブジェクトの内容一覧をXHTMLページとして表示するサービス。 |
サービス識別子 | info:lanl-repo/service/table_of_contents |
プレースホルダー値 | info:lanl-repo/pro/paper |
DIMコードへのポインタ | http://purl.lanl.gov/dip/methods/toc.js |
説明 | 全ての構成データストリームとそれが利用できるサービスをリストアップするデジタルオブジェクトの内容一覧をXHTMLページとして表示するサービス。 |
サービス識別子 | info:lanl-repo/service/marc_2_mods |
プレースホルダー値 | info:lanl-repo/fmt/3 |
DIMコードへのポインタ | http://purl.lanl.gov/dip/methods/marctomods.js |
説明 | 保管されているMARCXMLデータストリームをMODSデータストリームとして配布するサービス |
表4. DIPテーブルの3エントリー
DIMインサータモジュールにより実行されるDIDLドキュメントへのDIMの動的挿入を付録AとBに示した例を使って説明する。aDOReにあるデジタルオブジェクトのサンプル(付録A参照)を表現するDIDLドキュメント、特に、MARCXML[18]メタデータデータストリームの入手に焦点を絞って考える。このデータストリームは、値が‘info:lanl-repo/fmt/3’のプレースホルダーを持っている。このプレースホルダー値をサンプルDIPテーブル(表4)で検索すると、このプレースホルダー値がサービス識別子‘info:lanlrepo/service/marc_2_mods’のサービスに結合しており、そのDIMコードは‘http://purl.lanl.gov/dip/methods/marctomods.js’で利用できることがわかる。したがって、このサービスをDIDLドキュメントに追加しなければならない。これには以下の処理が必要である。
DIMの動的挿入処理をサンプルデジタルオブジェクトのMARCXMLメタデータデータストリームに適用した結果を付録Bに示した。この処理に関係する全てのエンティティは強調表示されている。
配布にあたって、DIDLドキュメントに関連する全てのDIMを埋め込むために、上で説明した処理が、DIDLドキュメントに見られる全てのプレースホルダーについて繰り返される。図5の左側はこの処理の概念図を提供している。
図 5. DIDLドキュメントの動的配布
MPEG-21 DIPエンジンはエージェントのリクエストに応えてデジタルオブジェクトを処理する機能を持っている。MPEG-21 DIPエンジンは次の情報が含まれている処理リクエストに応答することができる。
LANL MPEG-21 DIPエンジンの実際の機能を図5の右側に示した。サービスリクエストを受け付けると、MPEG-21 DIPエンジンは、DIDLドキュメントの指定されたXML要素と指定されたDIMを抽出する。既に述べたように、DIMはECMAScriptを規範とする言語を使って表現されている。このECMAScriptは、要求されたサービスを実装するために必要なコードを全て含んでいるわけではない。実際は、ECMAScriptはMPEG-21 DIPエンジンで使用され、要求されたサービスの実装プログラムをロードし、それを調整する。この目的のために、ECMAScriptはいわゆるデジタルアイテムオペレーション(DIO: Digital Item Operations)を呼び出すコードを含んでいる。MPEG-21 DIPでは次の2つの種類のデジタルアイテムオペレーションを区別している。
通常、MPEG-21 DIPエンジンは利用者端末で動くクライアント側のソフトウェアコンポーネントであると考えられている。aDOReでは、サーバ側で動くMPEG-21 DIPエンジンのプロトタイプ実装が開発された。現在のところ、このプロトタイプはMPEG-21で定義されているDIBOの少数をサポートしているだけである。しかし、aDOReに保管されているコレクションの性格に関連した、あるいは、特定したサービスを実装する様々なDIXOが開発されている。実は、表4に挙げた全てのサービスはDIXOを使って実装されている。また、より多くのDIXOを簡単に作成するためにJavaベースのテンプレートも開発されている。たとえば、あるテンプレートはXSL変換を使用する全てのDIXOの基礎として使うことができる。別のテンプレートは外部アプリケーションを呼び出す必要があるDIXOの基礎として、また別のテンプレートはWebサービスとの連携に使用することができる。aDOReはMPEG-21参照ソフトウェア[7]と完全互換であることが期待されている。MPEG-21 DIPエンジンの参照実装が利用可能になったら、それをaDORe環境に統合して、現在のプロトタイプ実装を置き換える予定である。
保管されている資料を入手しやすくするために、aDOReは2つのフロントエンドを導入した。2つのフロントエンドは、aDORe環境の複雑さをクライアントアプリケーションから隠し、表5にまとめたように個別の機能を果たしている。
aDORe フロントエンド | インターフェース 標準 | 識別子 | OAIS アクセス種別 | レスポンスの アイテム数 |
---|---|---|---|---|
OAI-PMH フェデレータ | OAI-PMH | パッケージ識別子 | OAIS DIP | 1あるいはそれ以上 |
OpenURL リゾルバ | NISO OpenURL | 内容識別子、(XML ID片を持つ)パッケージ識別子 | OAIS結果セット | 1 |
表 5. aDOReフロントエンドの特徴
OAI-PMHフェデレータは以下の理由によりaDORe環境に導入された。
OAI-PMHフェデレータはこの2つの問題に対処するものである。
OAI-PMHフェデレータは次の特徴を持つOAI-PMHリポジトリである。
既製のOAI-PMHハーベスタとOAI-PMHフェデレータを介したaDORe環境との対話を、次のGetRecordリクエストを使って説明する。
[BaseURL(Federator)?
verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&
metadataPrefix=DIDL
および
[BaseURL(Federator)?
verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&
metadataPrefix=IMS-CP]
適切なレスポンスを生成するために次の処理が順に行われる。
[BaseURL(3)?
verb=GetRecord&identifier=info:lanl-repo/i/58f202ac&
metadataPrefix=DIDL]
OAI-PMHハーベスティングにより、下流アプリケーションはDIDLドキュメントを入手し、それに含まれているデジタルオブジェクトや構成データストリームを使ってサービスを構築する。たとえば、検索エンジンは収穫したDIDLドキュメントからテキスト情報を全て抽出して、利用者が検索できるようにする。この場合、簡略な検索結果には、aDOReに保管されている該当リソースへのリンクを示すことになるだろう。明らかに、そのようなリンクにおいて、リソースの識別は重要な役割を果たすことになる。これにはパッケージ識別子(関連するXML ID片を含む)と内容識別子の両者を使用することができる。また、既に説明したように、aDORe環境では、保管しているリソースにサービスを適用することにより様々な形で配布することを可能にしている。従って、リソースを入手するためのリクエストには、要求するリソースだけでなく、それに適用する必要のあるサービスも特定する必要がある。後者は、表4に示したように、配布リクエストにサービス識別子を含めることに相当する。
NISO OpenURL標準[30]は、このような配布リクエストを伝達する完璧なフレームワークを提供する。当初のOpenURL仕様[41]は、参照リンキングの目的に特化して導入されたものであり、雑誌論文や図書などのよく知られた種類の学術資料に対する文脈依存のリンクサービスの提供を容易にすることを目的としていた[39]。そのため、資料を記述する識別子やメタデータは制限語彙を使用してHTTP GETリクエストでユーザ指定のリンキングサーバに伝達される。リンキングサーバは、ルールに基づいたアプローチを使って、その資料に付随する適切なサービスを利用者に提供する。最初のOpenURLソルーション[38]における基本的な要素の一般化が、NISO OpenURL標準[30]の性格を着想させた。この標準は、ネットワーク環境において参照されるあらゆる種類のリソースに関連する文脈依存のサービスを提供するための汎用的なフレームワークを提供するものである。この目的のために、OpenURL標準は、文脈依存のサービスを提供するプロセスに含まれる様々なエンティティの記述を含む情報構造体であるContextObjectの概念を導入している。エンティティを表6に示す。
エンティティ | 説明 |
---|---|
被参照体(Referent) | ContextObjectの作成対象となるエンティティ―参照されるリソース |
参照体(ReferringEntity) | 被参照体を参照するエンティティ |
リクエスタ(Requester) | 被参照体に付随するサービスを要求するエンティティ |
サービス種別(ServiceType) | 要求されるサービスの種類を定義するエンティティ |
リゾルバ(Resolver) | サービス要求の送付対象となるエンティティ |
リファラ(Referrer) | ContextObjectを作成したエンティティ |
表6. NISO OpenURL ContextObject
ContextObjextの各エンティティは、識別子、メタデータ、私的データのいずれかで記述することができる。ContextObjectは多くの方法で表現できるが、現在のところ、キー/符号化値(KEV: Key/Encoded-Value)表現とXML表現が定義され、OpenURLレジストリ(http://www.openurl.info/registry/参照)に登録されている。ContextObjectのいずれかの表現を、そこに記述されている被参照体に付随するサービスを要求するために、リゾルバと名付けられているネットワーク上のシステムに転送することができる。そのようなサービスの内容を決定するために、リゾルバは被参照体以外のエンティティを考慮することもできる。ContextObjectの転送は様々なネットワークプロトコルを使って行うことができるが、現在のところ、HTTPとHTTPSを使った転送が定義されている。
上記のことから、次の2つの対応は容易である。
保管デジタルオブジェクトや構成データストリームに対する全ての配布リクエストの送信先となるOpenURLリゾルバがaDOReのBaseURL(OpenURL Resolver)に導入された。本稿で先に示した例(表 1-3)について、OpenURL標準のHTTP転送とContextObjectのKEV表現を使うと、以下が、このOpenURLリゾルバへ配布リクエストを送る正しいOpenURLである。
[BaseURL(OpenURL Resolver)?
url_ver=Z39.88-2004 &
rft_id=info:doi/10.123/44455 &
svc_id=info:lanl-repo/service/table_of_contents]
パッケージ識別子を使って、このリクエストは次のように指定することもできる。
[BaseURL(OpenURL Resolver)?
url_ver=Z39.88-2004 &
rft_id=info:lanl-repo/i/58f202ac#uuid-00005e90 &
svc_id=info:lanl-repo/service/table_of_contents]
[BaseURL(OpenURL Resolver)?
url_ver=Z39.88-2004 &
rft_id=info:pmid/2225887 &
svc_id=info:lanl-repo/service/marc_2_mods]
このレコードもパッケージ識別子を使って指定することもできる。
[BaseURL(OpenURL Resolver)?
url_ver=Z39.88-2004 &
rft_id=info:lanl-repo/i/58f202ac#uuid-00004a42
現在のところ、aDOReへのOpenURLリクエストで使用されるContextObjextエンティティは被参照体とサービス種別のみである。しかし、NISO OpenURLでは、文脈依存の配布リクエストに応答する際に考慮することができるその他のエンティティを表現することも可能である。たとえば、リクエスタ情報の伝達は特に興味深いだろう。これにより、リクエストするエージェントに合せて実際の配布を変更することができるからである。リクエスタ情報でその身元を伝達することができれば、リクエストしているエージェントが人間であるか機械であるかにより、同じサービスリクエストに対して、異なるレスポンスをすることが可能になるだろう。また、記録された設定やアクセス権限に基づいて各人に異なる配布を提供することも可能であろう。NISO OpenURL仕様は、意図して非常に汎用的かつ拡張性に富むようにしてあるので、リクエスタエンティティを通じて利用者端末の特性や利用者の所在場所を伝達することもサポートするかもしれない。そうなれば、このような情報をMPEG-21 DIPエンジンに渡すことにより、実際に配布するものを決める際に考慮することができるだろう。実際のところ、NISO OpenURLの表現力は、リクエスト端末の特性やネットワーク条件、その他のコンテキスト情報など、利用環境の特徴を記述することに焦点を合わせているMPEG-21デジタルアイテムの適応変換(DIA: Digital Item Adaptation)[19]の性格にうまく共鳴するものと思われる。
この節では、既に示した次のOpenURLリクエストに応答する際の処理を逐次的に説明する。
[BaseURL(OpenURL Resolver)?
url_ver=Z39.88-2004 &
rft_id=info:pmid/2225887 &
svc_id=info:lanl-repo/service/marc_2_mods]
[BaseURL(3)?
verb=GetRecord&
identifier=info:lanl-repo/i/58f202ac&
metadataPrefix=DIDL].
本稿では、ロスアラモス国立研究所研究図書館のデジタルライブラリ研究およびプロトタイプ作成チームが過去2年間に亘って定義してきたaDOReデジタルオブジェクトリポジトリのアーキテクチャを説明した。aDORe環境で選択した中核的設計方針は次のような魅力的な特徴をリポジトリに与えている。
最初のaDORe実装は本番稼動に入り、現在ではおよそ3千万件のDIDLドキュメントを保管している。この数値は、来年には少なくとも2倍になると予想される。現行のaDOReシステムは、JavaとPerlで開発されており、LinuxとSolarisで検証されている。システムの至るところで既製のソフトウェアパッケージが使用されている。使用しているパッケージには、デンマークのネットアーカイブプロジェクトで開発されたインターネットアーカイブのARCファイルを出力するユーティリティ、XMLTapeを出力する標準的なXMLツール、XMLTapeをOAI-PMHでアクセスできるようにするためにインデックス化するBerkely DBなどが含まれる。OAI-PMHフェデレータとリポジトリインデックスはOCLCのOAICatを、下流アプリケーションで使用されるOAI-PMHハーベスタはOCLCのOAIHarvesterを各々ベースにしている。設計はモジュール化されプロトコルベースであるので、aDOReコンポーネントを複数の機械に分散させることが可能である。実際、自立OAI-PMHリポジトリ、OAI-PMHフェデレータ、OpenURLリゾルバ、リポジトリインデックス、識別子ロケータは、すべて別の機械で稼動させることが可能である。
識別子ロケータの性能と拡張性がaDORe環境では重要である。現行のシステムは、重要な情報をRAM上にロードした1つのMySQLデータベースに基づいている。このシステムは、現在のデジタルオブジェクトの保管量では問題なく稼動している。しかし、保管するデジタルオブジェクトの量がさらに増加した場合、また、システムへのアクセスがもっと激しくなった場合には、最適化が必要となることが予想される。最適化には、識別子ロケータで処理されるデータをブレード環境で稼動する複数のMySQLサーバに分散させることが考えられる。
様々な下流アプリケーションがaDOReから定期的にハーベストを行っている。2つのハーベスタが、受け入れた資料の発見をサポートする検索エンジン(VerityとLucene)のために稼動している。また、書誌情報の重複を動的に削除するためにNetricsファジー検索エンジンを使って構築されたアプリケーションのために、もう1つ別のハーベスタが稼動している。一次出版社や二次出版社から入手する学術資産の継続的な受入に加えて、LANLの構成員により書かれたテクニカルレポートやデータセット、ビデオテープに録画されたプレゼンテーション、集中的なWebクロールで収集する資料など、多様な資料を受け入れるための作業が進行中である。また、本稿で説明したコンポーネントの中にはさらに堅牢なバージョンの実装が進行中のものもある。さらに、関心のある人々とaDOReコードベースを共有することも検討されている。
著者一同は、報告書作成に対する貢献について、以前チームメンバーであったPartick Hochstenbash(現在はゲント大学)とHenry Jerez(現在はCNRI)に感謝いたします。また、LANL図書館長Rick Luceの報告書作成についての変わらぬ支援に感謝いたします。aDORe環境の構築作業について、Miriam Blake、Mariella Di Giacomo、Beth Goldsmith(LANL研究図書館開発チーム)に感謝いたします。本稿の草稿を校正していただいたMichael L. Nelsonに感謝いたします。
Jeroen Bekaertは、Ph.Dスカラーシップを与えていただいた科学研究財団(フランダース、ベルギー)にも感謝したいと思います。本研究は一部、米国議会図書館のNational Digital Information Infrastructure and Preservation Programの助成を受けました。
<?xml version="1.0" encoding="UTF-8"?>
<!--DIDL document is Archival Information Package -->
<!--Package Identifier provided as value of DIDid attribute -->
<didl:DIDL diext:DIDid="info:lanl-repo/i/58f202ac"
diext:DIDcreated="2004-06-22T18:07:18Z" xmlns:didl="urn:mpeg:mpeg21:2002:02-DIDL-NS"
xmlns:diext="http://library.lanl.gov/2004-04/STB-RL/DIEXT"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!--Container element representing a container entity -->
<didl:Container id="uuid-73d2247e">
<!-- Container-level Placeholder -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM">
<dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">info:lanl-repo/pro/DIDL</dc:format>
</diadm:Admin>
</didl:Statement>
</didl:Descriptor>
<!-- Top-level Item representing the Digital Object -->
<didl:Item id="uuid-00005e90">
<!-- Content Identifier of the Digital Object -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<dii:Identifier xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
info:doi/10.123/44455</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<!-- Item-level Placeholder -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM">
<dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">info:lanl-repo/pro/paper</dc:format>
</diadm:Admin>
</didl:Statement>
</didl:Descriptor>
<!. Sub-Item containing a MARCXML metadata record -->
<didl:Item id="uuid-8881b35e">
<!--Content Identifier of the MARCXML metadata record -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<dii:Identifier xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
info:pmid/2225887</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<!--Sub-Item-level Placeholder -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM">
<dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">
info:lanl-repo/pro/metadata</dc:format>
</diadm:Admin>
</didl:Statement>
</didl:Descriptor>
<!-- Component containing the MARCXML datastream -->
<didl:Component id="uuid-0000a01c">
<!-- Component-level Placeholder / Format -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM">
<dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">
info:lanl-repo/fmt/3</dc:format>
</diadm:Admin>
</didl:Statement>
</didl:Descriptor>
<!-- The actual MARCXML datastream -->
<didl:Resource mimeType="text/xml; charset=UTF-8">
<record xmlns="http://www.loc.gov/MARC21/slim">
<leader>01748cam 220036101 45Y0</leader>
<controlfield tag="001">LANLb10012252</controlfield>
<controlfield tag="003">LANL</controlfield>
<controlfield tag="005">20030527112640.0</controlfield>
<controlfield tag="008">840202s1983 nmua tb 00010 eng d</controlfield>
<datafield tag="035" ind1=" " ind2=" ">
<subfield code="a">GLIS00012252</subfield>
</datafield>
...
</record>
</didl:Resource>
</didl:Component>
</didl:Item>
<!-- Component containing the PDF paper -->
<didl:component id="uuid-00004a42">
<!-- </didl:Descriptor> 訳者削除 -->
<!-- Component-level Placeholder / Format -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM">
<dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">
info:lanl-repo/fmt/5</dc:format>
</diadm:Admin>
</didl:Statement>
</didl:Descriptor>
<!-- The actual PDF datastream -->
<didl:Resource mimeType="application/pdf" encoding="base64">
PSJjIj5jMTk5My48L3N1YmZpZWxkPg0KICAgIDw9uIHhtbG5zSJodHgKICAgIDxk
dGFnPSIzMDAiIGluZDE9IiAiIGluZDI9IiOAIS AIPg0KICAgICAgPHN1YmZpZWxkIGNv
cmVzdG9yZWQgdG8g…
</didl:Resource>
</didl:Component>
</didl:Item>
</didl:Container>
</didl:DIDL>
<?xml version="1.0" encoding="UTF-8"?> <!--DIDL document is Archival Information Package --> <!--Package Identifier provided as value of DIDid attribute --> <didl:DIDL diext:DIDid="info:lanl-repo/i/58f202ac" diext:DIDcreated="2004-06-22T18:07:18Z" xmlns:didl="urn:mpeg:mpeg21:2002:02-DIDL-NS" xmlns:diext="http://library.lanl.gov/2004-04/STB-RL/DIEXT" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <!--Container element representing a container entity --> <didl:Container id="uuid-73d2247e"> <!-- Container-level Placeholder --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM"> <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">info:lanl-repo/pro/DIDL</dc:format> </diadm:Admin> </didl:Statement> </didl:Descriptor> <!-- Top-level Item representing the Digital Object --> <didl:Item id="uuid-00005e90"> <!-- Content Identifier of the Digital Object --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <dii:Identifier xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS"> info:doi/10.123/44455</dii:Identifier> </didl:Statement> </didl:Descriptor> <!-- Item-level Placeholder --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM"> <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">info:lanl-repo/pro/paper</dc:format> </diadm:Admin> </didl:Statement> </didl:Descriptor> <!. Sub-Item containing a MARCXML metadata record --> <didl:Item id="uuid-8881b35e"> <!--Content Identifier of the MARCXML metadata record --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <dii:Identifier xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS"> info:pmid/2225887</dii:Identifier> </didl:Statement> </didl:Descriptor> <!--Sub-Item-level Placeholder --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM"> <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/"> info:lanl-repo/pro/metadata</dc:format> </diadm:Admin> </didl:Statement> </didl:Descriptor> ... <!-- Component containing the MARCXML datastream --> <didl:Component id="uuid-0000a01c"> <!-- Component-level Placeholder / Format --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM"> <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/"> info:lanl-repo/fmt/3</dc:format> </diadm:Admin> </didl:Statement> </didl:Descriptor> <!-- ObjectType of the MARCXML datastream, added by DIM Inserter --> <!--Corresponds with Argument of DIM (MARCXML to MODS) below --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <dip:ObjectType xmlns:dip="urn:mpeg:mpeg21:2002:01-DIP-NS"> urn:uuid:8f64eabf</dip:ObjectType> </didl:Statement> </didl:Descriptor> ... <!-- The actual MARCXML datastream --> <didl:Resource mimeType="text/xml; charset=UTF-8"> <record xmlns="http://www.loc.gov/MARC21/slim"> <leader>01748cam 220036101 45Y0</leader> <controlfield tag="001">LANLb10012252</controlfield> <controlfield tag="003">LANL</controlfield> <controlfield tag="005">20030527112640.0</controlfield> <controlfield tag="008">840202s1983 nmua tb 00010 eng d</controlfield> <datafield tag="035" ind1=" " ind2=" "> <subfield code="a">GLIS00012252</subfield> </datafield> ... </record> </didl:Resource> </didl:Component> </didl:Item> <!-- Component containing the PDF paper --> <didl:Component id="uuid-00004a42"> <!-- </didl:Descriptor> 訳者削除 --> <!-- Component-level Placeholder / Format --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <diadm:Admin xmlns:diadm="http://library.lanl.gov/2004-01/STB-RL/DIADM"> <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/"> info:lanl-repo/fmt/5</dc:format> </diadm:Admin> </didl:Statement> </didl:Descriptor> ... <!-- The actual PDF datastream --> <didl:Resource mimeType="application/pdf" encoding="base64"> PSJjIj5jMTk5My48L3N1YmZpZWxkPg0KICAgIDw9uIHhtbG5zSJodHgKICAgIDxk dGFnPSIzMDAiIGluZDE9IiAiIGluZDI9IiOAIS AIPg0KICAgICAgPHN1YmZpZWxkIGNv cmVzdG9yZWQgdG8g… </didl:Resource> </didl:Component> </didl:Item> <!-- Item containing the DIM that implements the MARCXML to MODS service --> <!-- Inserted by the DIM Inserter after lookup of Placeholder/Format value info:lanl-repo/fmt/3 in the DIP Table --> <didl:Item id="uuid-6b479d14"> <!-- Content Identifier of the DIM --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <dii:Identifier xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS"> info:lanl-repo/service/marc_2_mods</dii:Identifier> </didl:Statement> </didl:Descriptor> <didl:Component id="uuid-3886920b"> <!-- Argument of the DIM. Corresponds with ObjectType attached to MARCXML datastream --> <didl:Descriptor> <didl:Statement mimeType="text/xml; charset=UTF-8"> <dip:MethodInfo xmlns:dip="urn:mpeg:mpeg21:2002:01-DIP-NS"> <dip:Argument>urn:uuid:8f64eabf</dip:Argument> </dip:MethodInfo> </didl:Statement> </didl:Descriptor> <!-- DIM ECMAScript --> <didl:Resource mimeType="application/mp21-method" ref="http://purl.lanl.gov/dip/methods/marctomods.js"/> </didl:Component> </didl:Item> </didl:Container> </didl:DIDL>