Open Archives Initiative メタデータ・ハーベスティング・プロトコル実装ガイドライン

- リポジトリ実装者向けガイドライン

プロトコルバージョン 2.0 （2002-06-14）
ドキュメントバージョン（2002/06/09T16:43:00Z）
http://www.openarchives.org/OAI/2.0/guidelines-repository.htm

編集者

OAI 執行部 :
Carl Lagoze <lagoze@cs.cornell.edu> -- コーネル大学 - コンピュータサイエンス
 Herbert Van de Sompel <herbertv@lanl.gov> -- ロスアラモス国立研究所 - 研究図書館

OAI 技術委員会委員 :
Michael Nelson <m.l.nelson@larc.nasa.gov> -- NASA - ラングレー研究センタ
 Simeon Warner <simeon@cs.cornell.edu> -- コーネル大学 - コンピュータサイエンス

本ドキュメントは、 Open Archives Initiative メタデータハーベストプロトコル (OAI-PMH) の付録『実装ガイドライン』の一部です。

1. はじめに

OAI-PMH はリポジトリの実装が簡単にできるように設計されているため、コンセプトのオプションが多数あります。本ドキュメントでは最初に最小限のリポジトリ実装要件を紹介し、その後、リポジトリの実装と保守に関する最適要件について説明します。

2. 最小限のリポジトリ実装

OAI-PMH では多数のコンセプトが選択できることを強調することは重要です。その目的は、リポジトリとハーベスタとの通信精度を、必要に応じてできるだけ高めることにあります。ただし、これらのコンセプトが必要ない場合、または実装が難しすぎる場合は、状況に合わせて選択できるようになっています。機能オプションについては、以下で説明します。これらのオプションの選択は全部でも一部でも、あるいは全く選択しなくても構いません。

2.1 Dublin Core と他のメタデータフォーマット

Dublin Core (DC) は、リソースのメタデータを発見するための共通語です。DC フィールドはすべて任意かつ反復可能であるため、ほとんどのリポジトリが各自のメタデータを元のまま unqualified DC にマッピングすることについて、少なくとも最小限のレベルでは問題ありません。リポジトリは各自のメタデータを DC で保存する必要はありません。DC は "保存" の対象ではなく、一般的に "変換" される形式です。リポジトリの多くは各自のメタデータを別のフォーマットで保存し、ハーベスタの要求に応じて DC に動的に変換します。直接 DC で保存することが個々の実装にとって望ましい場合は、いうまでもなくそのようにして構いません (may)。

リポジトリではコミュニティ独自の充実したなメタデータフォーマットのエクスポートが強く推奨されますが、そのための要件はありません。リポジトリ実装にとって、DC のエクスポートは OAI-PMH の相互使用を行う上で最初の最も重要なステップです。別のフォーマットをエクスポートする機能は、その後で追加するとよいでしょう。

2.2 `<about>` コンテナ

OAI-PMH のレコードは、リポジトリのアイテムから抽出した個々のメタデータです。 <about> コンテナを使用すると、リポジトリにそのレコードそのものについての自己参照メタデータが含まれます。これは権利および出自表示を符号化するために大変役立ちますが、必須要件ではありません。実装者が <about> コンテナの使用法やその効果について不明な場合は、使用の延期をお勧めします。

2.3 セット

セットを使用すると、リポジトリの内容区分がハーベスタに伝わります。これによって高度なデータハーベストができるようになりますが、すべてのハーベスタでセットの機能が使用されるわけではありません。 DC 以外のメタデータフォーマットのように、セットは個々のコミュニティ内で有用であると思われます。したがってセットの実装は、コミュニティ独自の状況やセットを必要とする実装計画が整ってからにすることをお勧めします。セットの実装は任意ですから、リポジトリ実装の際にセットは実装しなくても構いません (may) (その場合、ハーベスタでもセットは無視されます)。

2.4 応答圧縮

圧縮された応答をハーベスタに送信すると、パフォーマンスをかなり最適化することができます。ただし、これは 1) ハーベスタが圧縮された応答を受け入れることができる、 2) リポジトリによる応答圧縮とハーベスタによる応答解凍に要する時間を確保するため十分長い応答が利用できる、場合に限られます。したがって、リポジトリに大きなコレクション（たとえば数千のレコード）がなければ、応答圧縮の実装はハーベスタに圧縮体系が広く採用されてからにすることをお勧めします。

リポジトリはすべて、要求のヘッダ Accept-Encoding から別途の符号化でパースされない限り、必ず identity (非圧縮)符号化をサポートし、これに応答します。

2.5 フロー制御

フロー制御は、不完全リスト応答と resumptionToken 要素を使用することで、リポジトリがハーベスタからの要求受信を抑制する強力な機構となります。ただしこれを行うと、リポジトリによっては OAI-PMH の実装が複雑になってしまいます。リスト応答が不完全リスト応答となるサイズについて明確なガイドラインはありませんが、帰属アイテムが 1000 未満のリポジトリは一つの完全リスト応答で返す（つまり resumptionToken 要素は使用しない）のが合理的です。

3. 単位、 `datestamp` と `responseDate` の値

OAI-PMH では、日と秒の2つの datestamp 単位が使用できます。日付はすべて UTC で表記することになっている (must) ので、日付変更時刻は通常、リポジトリのローカルな午前零時ではなく、 UTC 午前零時です。リポジトリの多くは秒の単位を使用すると思われますが、特定の更新スケジュールや既存の基本ソフトウェアが基底プロセスに影響を及ぼすリポジトリの場合、日の単位が使用されます (may)。

使用される単位に関わらず、新規または修正されたアイテムのメタデータは、そのアイテムの新しい datestamp の期間中は必ず利用できるものとします (must)。そうでないと、増分データハーベストの際、そのような更新内容が見落とされる場合があります (may)。たとえば、あるアイテムは datestamp 2002-03-01 のリポジトリに追加されても、 2002-04-01T02:00Z に作成されたインデックスに表示される場合があります。その後、2002-04-01T01:00Z に実行する増分データハーベストでは前日からの更新内容が反映されず、次のデータハーベストで from=2002-04-01 と指定してもその更新は見落とされます。

OAI で使用される datestamp 値は、増分データハーベストを目的とするものです。リポジトリの提供内容の変更を含むアイテムの変更があれば、それを反映します。たとえば、リポジトリ内の基底 master-record が変更されなかった場合でも、逐次変換でフォーマットを生成する方法に変更すると、そのフォーマットの元となりうるすべてのアイテムの日付が更新されます。これを datestamp インデックス生成時に内部実装する方法は以下のとおりです。

if (internalItemDatestamp > disseminationInterfaceDatestamp) {
  datestamp = internalItemDatestamp
} else {
  datestamp = disseminationInterfaceDatestamp
}

ハーベスタは増分データハーベストを実装する方法として、 responseDate を利用してリスト要求の開始と一致する時間（UTC 表記）をリポジトリの時間から取得しても構いません。リポジトリから返された時間を使用することで、ハーベスタは時間の不一致の問題を回避します。したがって、リスト要求への回答を要するデータベースのクエリや検索の場合、その出力時ではなく開始時に、 responseDate をリポジトリのクロックの時間に合わせることを推奨します。こうすればクエリにある程度の時間がかかっても、そのクエリの実行中に発生した更新内容は次の増分データハーベストで確実に捕捉されます。

4. セット

セットは、オプションで選別データハーベストをサポートします。リポジトリはセットを実装する必要はありません (need not) (セット：最小限の実装参照)。また、ハーベスタは抽出されるセット構造を無視しても構いません (may)。

4.1 セット階層

setSpec の値にコロン (:) 記号を使用すると、セット階層という意味になります。セット階層を実装しないリポジトリでは、setSpec の値にコロンを含めてはなりません (must not)。

Example ListSets response:

<ListSets ...>
  <set>
    <setSpec>A</setSpec>
    <setName>set A</setName>
  </set>
  <set>
    <setSpec>A:B</setSpec>
    <setName>set A:B</setName>
  </set>
  <set>
    <setSpec>B</setSpec>
    <setName>set B</setName>
  </set>
  <set>
    <setSpec>B:C</setSpec>
    <setName>set B:C</setName>
  </set>
  <set>
    <setSpec>B:D</setSpec>
    <setName>set B:D</setName>
  </set>
  <set>
    <setSpec>B:D:E</setSpec>
    <setName>set B:D:E</setName>
  </set>
</ListSets>

This response implies the following hierarchy of sets:

A
A:B
B
B:C
B:D
B:D:E

The sets A:B and B are distinct, however the repeated use of node name B is not recommended because it may lead to confusion. If the header for item1 is:

  <header>
    <identifier>item1</identifier>
    <setSpec>A:B</setSpec>
    ...
  </header>

then item1 is organized in sets A and A:B. If the header for item2 is:

  <header>
    <identifier>item2</identifier>
    <setSpec>A</setSpec>
    <setSpec>B:D:E</setSpec>
    ...
  </header>

then item2 is organized in sets A, B, B:D and B:D:E.

4.2 コレクションとセット記述内容

セット記述内容は、 ListSets 応答の setDescription に含めることができます (may)。セットが "コレクション" の概念に一致する場合、コレクション記述を行うことができます。リポジトリ全体が一つのコレクションを表す場合、 Identify 応答の description コンテナを使用してコレクションを記述する方が適切な場合もあります。

コミュニティは、 description コンテナや setDescription 要素の中で使用するため、コレクション記述 XML スキーマを各自で決めることができます。非構造化テキスト記述だけで構わない場合は、リポジトリでは　Dublin Core description 要素の使用を推奨します。既存スキームは以下の7つです。

Dublin Core	15 DCMES 要素 (unqualified)	http://www.dublincore.org/documents/dces/ OAI-PMH: Dubin Core, `oai_dc`
Encoded Archival Description (EAD)	符号化アーカイブ探索支援の標準。この目的で有用なEAD インスタンスは、コレクションの全体またはかなり上位のコンポーネントについての情報に限られると思われます。	http://www.loc.gov/ead/
`eprints` スキーマ	eprint アーカイブを記述するためのスキーマ	OAI-PMH Guidelines: `eprints`
RSLP コレクション記述スキーマ	コレクションとその内容記述の基底モデルに組み込まれた qualified Dublin Core のアプリケーション	http://www.ukoln.ac.uk/metadata/rslp/schema/
UDDI/WSDL	UDDI (Universal Description Discovery and Integration) 仕様は、インターネット上のサービスを記述するための機能を提供します。	http://www.uddi.org/
MARC21	1つのレコードにあるコレクション全体を記述するため、図書館目録で一般に使用されています。	http://www.loc.gov/marc/ OAI-PMH Guidelines: `marcxml`
`branding` スキーマ	ブランディング情報（アイコン、リンクなど）を追加するためのスキーマ	OAI-PMH Guidelines: `branding`

なお、EAD、RSLP、UDDI に対応する XML はまだありません。また、 DC、EAD、RSLP、MARC21 の各スキーマ間のマッピングは利用できます。

OAI コミュニティには、qualified DC に基づくシンプルなコレクション記述スキーマの策定を計画している DCMI Collection Description 作業グループの成果を調べてみることを推奨します。

5. 不完全リスト応答と `resumptionToken` 要素の用法

OAI-PMH は構文を指定せずに、resumptionToken 要素の実装方法を示唆することはありません。それは各リポジトリができるだけ柔軟に、各自の実装プロファイルに OAI-PMH の機能を採り入れられるようにするためです。ハーベスタは resumptionToken の値を不明瞭なデータオブジェクトとして扱う必要があります。リポジトリは以下のように、 resumptionToken の構文を明確化することができます
(may)。

  <resumptionToken>resultSet=157&nextRange=1001-2000</resumptionToken>

または、 resumptionToken を符号化しても構いません。そうすると以下のように構文が分からなくなります。

  <resumptionToken>9023A210CD007</resumptionToken>

OAI-PMH は、ハーベスタがリポジトリから増分データハーベストを行い、変更（追加、修正、deleted ステータスでレポートされた削除）を見落とさないようにする機能を提供します。不完全リスト応答と resumptionToken 要素を実装しても、これは変わりません。ある変更が個々のデータハーベストの実行中またはその後のデータハーベストの後にハーベストされるか否かは、データハーベストシーケンスで変更が見落とされることがない限り、決定的に重要な問題ではないと思われます。たとえば、 ListRecords 要求の完了が必要な要求シーケンスの実行中に修正されたアイテムの場合、新しい datestamp は要求シーケンスの開始後から終了前の時間と一致します。この変更内容が実行中のデータハーベストで選択されても、あるいは、次のデータハーベストまで選択されなくても全く適切な結果といえます。

リポジトリが不完全リスト応答や resumptionToken 要素を実装する際、選択できる実装方法は主に2つあります。 resumptionToken の状態を符号化すること、あるいは、結果セットをキャッシュすることです。これらの手法については、次のセクションで説明します。

5.1 `resumptionToken` の状態の符号化

resumptionToken のステートをすべて符号化することで、リポジトリをステートレスにしておくことができます。この実装方法を採用すると、次の応答に必要なステートの再生成における計算時間の増加分と、結果をキャッシュするのに必要な管理費とが相殺されます。次の例をご覧ください。

  http://an.oai.org/?verb=ListRecords&set=227&from=1999-02-03

resumptionToken は以下と同じで構いません (見やすいように改行)。

  <resumptionToken>set=227&from=1999-02-03&until=2002-04-01
    &range=751-1500&metadataPrefix=oai_dc</resumptionToken>

これは、 ListRecords 要求の例であり、 resumptionToken にはステートの一部として metadataPrefix が含まれています。
metadataPrefix 部は、 ListIdentifiers resumptionToken にとって必須ではありません (would not be required)。ハーベスタは、 from と until の各引数の一方または両方を省いて、 `最も古い日付から' や `最新の日付まで' としても構いません。このような要求から構成された resumptionToken には、少なくとも現行リポジトリの日付で記入された until の引数と一致する部分をもたせることを推奨します。これによって、until の値として同じ日付が付いた新規アイテムを含む不完全リスト要求は無効になりませんが（単位に日が使用されている場合は可能性が高い）、それより後の日付が付いた新規または修正されたアイテムを含む不完全リスト要求は無効になります。

resumptionToken のフォームを実装する方法の一つとして、リスト要求の最初の引数や resumptionToken のオフセット情報を符号化することがあります。リポジトリが後で resumptionToken を受け取ると、最初のクエリを反復してそのステートを再生成することができます (may)。このようにすると、コンピュータ処理においては高コストになる場合がありますが、resumptionToken の値に関するキャッシュ管理は不要となります。この理由のためだけに、実装者が快適にキャッシュやリポジトリを管理できないのであれば、 resumptionToken 値において必要なステートをすべて符号化するスキームの使用を推奨します (should)。

なお、リスト要求シーケンスが完了する前に、アイテムが最初の要求の datestamp の範囲から外れた場合に対処するため、 resumptionToken において追加情報の符号化が必要になる場合もあります (may need)。

5.2 結果セットのキャッシュ

リポジトリは、ハーベスタのリスト要求の結果をキャッシュして、そのセグメントを不完全リスト応答として返すことができます (may) (該当する resumptionToken 値を含めた追加要求でアクセス可能)。通常のソリューションであれば、resumptionToken におけるセッション識別子とカーソルの両方を符号化します。ハーベスタが以下のような要求を発行した場合:

  http://an.oai.org/?verb=ListRecords&set=227&from=1999-02-03

その応答の resumptionToken は以下と同様なものが考えられます。

  <resumptionToken>searchId=4234&range=751-1500</resumptionToken>

ハーベスタからのその後の要求は、リポジトリにキャッシュされた結果セットから（たとえば）次の 750 のレコードだけを送付させます。リポジトリは、重複検索の結果セットキャッシュのチェックも可能です。また、2つの別のハーベスタから同じ要求がきた場合、キャッシュされた同一の結果セットからサーブすることができます。リポジトリとリポジトリがサーブするコミュニティの様態しだいでは、このシナリオが一般的なものとなり、また、結果をキャッシュすることでリポジトリが著しく最適化されます。

リポジトリにとってこの方法の欠点は、キャッシュを保守、削除する負担が増えることです。 OAI コミュニティのプロファイルハーベストに関する現在の知識は限定的であるため、どのキャッシュ交換アルゴリズムが所定のリポジトリにとって最適であるかは分かりません。リポジトリの実装プロファイルは広範に及ぶため、全般的な推奨は不可能かもしれません (may)。

この種の resumptionToken を実装するリポジトリは、 expirationDate の属性を使用して resumptionToken の値の有効期間を表示するようにします (should)。また、識別子が ListRecords と ListIdentifers の各要求に備えてキャッシュされている場合、メタデータが実際に提供されるときまでに、そのアイテムが削除されていないか、あるいはその datestamps が要求の範囲から外れていないか、チェックが必要な場合もあります (may)。

5.3 リスト要求の等冪性

OAI-PMH は、resumptionToken の引数を使用する完全リスト要求と個々の不完全リスト要求のために、等冪性の弱いフォームを必要とします。

リポジトリ内に変更がない場合、2つの同じリスト要求は必ず同じ結果を返します（must）。
リポジトリ内に変更がない場合、 (期限切れでない同じ resumptionToken を使用して) 最新の不完全リスト要求を再発行すると、必ず同じ結果が返されます（must）。不完全リスト要求を再発行するために resumptionToken を再度使用する必要があるので、ステート情報を追加しなければ、セッション識別子を resumptionToken として使用することはできません。ただし、リポジトリが resumptionToken の値を期限切れにすることはできます。期限切れになる時間は、 expirationDate の属性で指定することができます。
レポジトリ内で2つの同じリストまたは不完全リスト要求の間に変更がある場合、両方の応答には変更されなかったすべての要素が必ず含まれます。これは、個々の不完全リスト要求は完全リスト要求と同程度の等冪性を有する必要があるということを意味します。
ハーベスタが最近受け取った resumptionToken だけが、再発行可能です。リポジトリにとって、最近回答された不完全リスト要求に対する上記の等冪性要件をサポートする必要があるということです (must)。リポジトリは、最近発行された resumptionToken と以前発行された resumptionToken の両方を受け入れる必要があります (must)。

前述の2つの実装方法で異なるセマンティクスが生じるシナリオもあります。ハーベスタが resumptionToken 引数が含まれた次の要求を発行するよりも早く、あるリポジトリが変更を行った場合、2つの実装の結果は異なる場合があります。レポジトリがハーベスタのセッション実行中に新規レコード N を追加し、このレコードが最初の要求で指定された基準 (set、 timestamp など.) に適合する場合、リポジトリに保存されたステートに依存する実装は、多くの場合、最初のデータハーベストの時間に関連した結果となります。 resumptionToken 値におけるステートの転送を行う実装は、多くの場合、最後の要求の時間に関連した結果となります。一方の高度な実装スキームはこの差に対応できますが、実装者にはリポジトリの増加率を予測して、 resumptionToken の任意属性 expirationDate の設定を推奨します。

resumptionTokens の等冪性は、大きなリポジトリをハーベストする場合に発生しうる不可避のエラー状況（たとえば応答の消失、ハーベスタのクラッシュなど）からハーベスタが回復する際に役立ちます。

5.4 期限切れと `expirationDate`

expirationDate 属性は、resumptionToken の有効期限を示すために使用することができます (may)。リポジトリには最低10分間は有効な resumptionToken 値の使用を推奨します。

リポジトリが期限切れでない resumptionToken 値を使用する場合、 expirationDate 属性は使用しないようにします (should not)。

なんらかの理由で、リポジトリが要求を完了できない場合、(人が判読可能なテキスト説明の付いた) badResumptionToken を発行して、要求シーケンスを停止しても構いません。ハーベスタは最初のリスト要求からやり直すことになります。

5.5 `completeListSize` と `cursor` の属性

resumptionToken 要素の completeListSize と cursor の各属性を追加して、結果セットのサイズに関する追加情報とこれまでに抽出された結果数を提供しても構いません。

cursor の属性は、完全リスト応答でこれまでに返された結果の数にすぎません。したがって、最初の不完全リスト応答では常に "0" です。この属性は、すべての応答で一貫して使用する場合にだけ指定します。

completeListSize の属性は、完全リスト要求の結果の推定数を知らせてもよい場所を提供します。これは主にソフトウェアの実装によって、ステータスモニタリングのために使用されます。特に多数のレコードが含まれる応答において実装が推奨されます。 completeListSize の値は、結果セットがキャッシュされるシステムの場合のみ正確になります。その他の場合、リポジトリがリスト要求シーケンス実行中に推定値を見直すことが許されます。

6. フロー制御と負荷分散

フロー制御 と 負荷分散 の関連・直交コンセプトにより、リポジトリは要求受信を抑制することができます。フロー制御は、不完全リストと resumptionToken 要素から利用可能な、 intra-repository 技術とみなすことができます。また、フロー制御のセマンティクスは OAI-PMH で定義されます。負荷分散は、 inter-repository 技術とみなされ、データハーベストロードをビジーなリポジトリから内容が同じで不可の軽いリポジトリへ転送することができます。負荷分散セマンティクスは、 OAI-PMH では扱われません。トランスポート層で処理するものとします。

両方のコンセプトとも任意で、別々もしくは一緒に使用できます。ハーベスタを負荷の軽い "ミラー" リポジトリに転送するシナリオは、用意に想定できます。また、リポジトリとハーベスタ間で発生する要求と応答は、 resumptionToken 要求を使用することで抑制されます。

6.1 フロー制御

resumptionToken 要素のセマンティクスは、 OAI-PMH で定義されます。実装方法は、前述のとおりです。次のセクションでは、トランスポートレベルのフロー制御の方法を説明します。

HTTP プロトコルはステータスコード 503 - "サービス不能" を定義します。リポジトリの負荷が重く、要求を処理しない (そして HTTP ステータスコード 200を返す) 場合、 "Retry-After" ヘッダの付いた HTTP 503 応答を発行することができます。場合によってはこの仕組みを利用して、データベースの更新またはその他の短時間の機能停止の間、要求を遅らせる場合もあります (might)。

要求シーケンスを減速したい場合、リポジトリから HTTP 503 要求を発行することができます。これによって要求が処理されなかったこと、また再試行の前に一定の時間待機することをハーベスタに知らせます。リポジトリは各自の裁量により、ハーベスタに対して、 503 応答の Retry-After ヘッダに指定された遅れに準拠しないという HTTP 403 "Forbidden" 応答を発行することができます (may)。 403 は 503 より懲罰的で、非常事態でのみ発行するようにします。

フロー制御のウォータフォールモデルを採用し、ハーベスタが現行レベルで応答がない場合のみ、リポジトリを次のレベルに移動することを推奨します。

HTTP ステータスコード 200; OAI-PMH 要求に対する応答、 resumptionToken が付随
HTTP ステータスコード 503; 次の要求が早く来すぎる場合、あるいはサーバの負荷が重い場合、該当する値に Retry-After ヘッダセットが付随
HTTP ステータスコード 403; 次の要求がRetry-After遅延に準拠していない場合、指定された適切な理由に付随

6.2 負荷分散

OAI-PMH では扱われませんが、協力するリポジトリの階層を構成することはできます。特に人気のある、あるいは負荷の重いリポジトリはミラーリポジトリをセットアップする場合があります。負荷分散は、 HTTP 302 または 303 ステータスコードを使用することで、あるいは DNS の CNAMES を使用しても、実行させることができます。負荷分散は強力ですが複雑です。リポジトリに負荷分散を実装することを推奨するのは、 1) 標準的リポジトリが明白にオーバーロードであり、かつ、 2) OAI-PMH の詳細に準拠している場合だけです。

6.2.1 HTTP-Based 負荷分散

たとえば、次の要求の場合:

  http://an.oai.org/?verb=ListRecords&set=227&from=1999-02-03

an.oai.org が特にビジーな場合、 302 に以下の Location ヘッダを付けて発行しても構いません。

http://another.oai.org/?verb=ListRecords&set=227&from=1999-02-03

これは another.oai.org が標準の an.oai.org のミラー（または "スレーブ" ）であることを含意します。この要求が不完全リストを生成する場合、次のデータハーベスト要求は another.oai.org に関連します。ただし、その後のデータハーベスト要求は必ず an.oai.org に転送されます (must)。このため、 Identify 要求が another.oai.org に対して発行されると、応答には必ず baseURL のan.oai.org が含まれます (must)。同様に、応答ヘッダの request 要素は内容が必ず baseURL (an.oai.org) になります (must)。

なお、 another.oai.org は自由にロードバランスを行うこともでき、 302 に以下の Location ヘッダを付けて発行します。

http://yetanother.oai.org/?verb=ListRecords&set=227&from=1999-02-03

ハーベスタに向けて循環転送がないようにするのは、実装者の判断によります。

6.2.2 DNS-Based 負荷分散

比較的シンプルでわずかに力の弱い負荷分散の方法は、 DNS ロータの使用です。この場合、 an.oai.org は a.oai.org、 b.oai.org、 c.oai.org のいずれかに変わります。これで物理的に別個のマシンにすべてマップすることになります。名前 an.oai.org を解決するハーベスタは、ランダムにアドレスの1つを受け取り、そのアドレスをデータハーベスト要求に使用します。このフォームの負荷分散を行う場合、リポジトリは要求に答えるマシン間で緊密な同期を確実に行う必要があります。また、 ( Identify 要求の) baseURL と (ヘッダの応答の) request には、必ず an.oai.org を使用します (must)。

7. 応答圧縮

OAI-PMH における圧縮は、リポジトリとハーベスタの両方が identity 符号化 (圧縮なし) をサポートするという制限付きで、 HTTP レベルで処理されます。リポジトリは各自が Identify 応答の compression 要素でサポートしている圧縮を通知します（should）。

Response from Identify:

<Identify ...>
  ...
  <compression>gzip</compression>
  ...
</Identify>

Next request includes:

Accept-encoding: gzip;q=1.0, identity;q=0.5

Response then gzip encoded with header:

Content-Encoding: gzip

圧縮は任意ですが、冗長なデータハーベストに関するネットワークトラフィックは最小化することが推奨されます。リポジトリは「HTTP: RFC 2616 セクション 3.5 "Content Codings": gzip、 compress、deflate 」に定められた圧縮タイプを最低1つ提供することが推奨されます。

8. エラー処理

エラーは、応答の error 要素を1つ以上使用してレポートされます。必須ではありませんが、リポジトリ実装に詳細で有用なエラーメッセージ（ error 要素のコンテンツ）を必須の code 属性とともに含めることを強く推奨します。

複数のエラー状況が特定されても、リポジトリに含めることのできる error 要素は1つだけです。ただし、デバッギングエイドのため、リポジトリは特定したエラーのすべてをレポートします。複数の error 要素を使用しても構いません。その場合、同じ code の複数エラーでもなるべく別々の error 要素に分けます。たとえば次の場合：

  <error code="badArgument">Illegal argument 'arg1'</error>
  <error code="badArgument">Illegal argument 'arg2'</error>

下記よりも上記の方がよいとされます。

  <error code="badArgument">Illegal arguments 'arg1', 'arg2'</error>

謝辞

OAI-PMH の策定およびその他の Open Archives Initiative の活動に対して、デジタル図書館連盟とネットワーク情報連合、そして全米科学財団（Grant No. IIS-9817416）からご支援をいただきました。 OAI-PMH バージョン 2.0 の策定で多大なご協力をいただいた個人の皆様に、プロトコルドキュメントにおいて感謝の意を表します。

ドキュメント履歴

2002-06-14: OAI-PMH バージョン 2.0 のリリースに合わせて本ドキュメントをリリース