PDFファイルはこちら
カレントアウェアネス
No.323 2015年3月20日
CA1845
動向レビュー
ResourceSync：OAI-PMH の後継規格
九州大学附属図書館eリソースサービス室：林豊（はやし ゆたか）
1. はじめに
本稿では、米国情報標準化機構（NISO）とOpen Archives Initiative（OAI）によって策定が進められているResourceSync(1)の概要を紹介する。
ResourceSyncは、2つのウェブサーバの間でコンテンツの同期(2)を行うためのプロトコルである。2011年にOAI-PMH（CA1513参照）の後継規格として検討が始まった。ワーキンググループにはOAI-PMHの策定に深く関わったロスアラモス国立研究所のソンペル（Herbert van de Sompel）も名を連ねている。一連の規格のなかでコアとなるResourceSync Framework Specification（ANSI/NISO Z39.99-2014）(3)のバージョン1.0が2014年4月にリリースされた。
OAI-PMHは、機関リポジトリなどで使われているメタデータハーベスティング（収集）のためのプロトコルである。その歴史は1999年まで遡り、2001年にバージョン1.0が、2002年に現時点でも最新版となるバージョン2.0がリリースされている。図書館ではデジタルコンテンツの露出機会を増やすために外部のサービスにメタデータを提供することがしばしばある。外部との連携方法は一般に様々であり、何らかの標準的な方法が存在すれば連携が容易になる。OAI-PMHは現在でも国際標準規格にはなってないが、図書館界ではメタデータ収集の方法としてデファクトスタンダードであり、成功していると評価できるだろう。
それではなぜResourceSyncという新しい規格が必要となったのだろうか。
2. OAI-PMHの限界
その問いに答えるために、まず、OAI-PMHの問題点について説明したい。
2.1. 収集のプロセス
OAI-PMHでは、「サービスプロバイダ」が「データプロバイダ」のメタデータを収集するための方法を定めている(4)。サービスプロバイダがデータプロバイダ上の特定のURLにアクセスし、それに対してデータプロバイダがXML形式でメタデータを返す、というのが基本的なしくみである。
例えば、九州大学の機関リポジトリのメタデータを収集する際のURLは以下のようになる。
このうち「?」以前の部分はベースURLと呼ばれ、データプロバイダによって異なる。サービスプロバイダは収集したいデータプロバイダのベースURLを何らかの方法で事前に知っておく必要がある。
「?」以後の部分の書式はOAI-PMHの仕様で標準化されている。verbはデータプロバイダへの要求内容を指示するもので、ListRecords（指定した条件に合致するレコードを全て取得する）のほか、Identify、ListMetadataFormats、ListSets、ListIdentifiers、ListRecords、GetRecordの全6種類が用意されている。fromとuntilによって、特定の期間に作成・更新されたメタデータのみを抽出できる。
また、応答時のXMLでは、削除されたメタデータについてstatus=“deleted”という情報が出力される(5)。
2.2. 活用例
例えば、現在OAI-PMHは次のようなシーンで活用されている。
（1）デジタルリポジトリ
OAI-PMHは、DSpaceなどの主要なリポジトリソフトウェアで実装されている。機関リポジトリのメタデータを収集するサービスには、国立情報学研究所（NII）の学術機関リポジトリデータベース（IRDB）(6)、OAIster、RePEcなどがある。数物系のプレプリントサーバarXivはOAI-PMHによるメタデータ提供を行っている(7)。
（2）デジタルアーカイブ
国立国会図書館（NDL）東日本大震災アーカイブ「ひなぎく」、Europeana、米国デジタル公共図書館（DPLA）、米国議会図書館（LC）のAmerican Memoryなどのデジタルアーカイブが、メタデータの収集や提供の方法としてOAI-PMHを採用している(8) (9)。特にこのケースでは図書館界以外の機関・企業のサービスも収集対象になることがある点を注意しておきたい。
（3）ディスカバリーサービス
国立国会図書館サーチ（CA1762参照）では、メタデータの収集・提供の方法としてOAI-PMHが採用されている(10)。また、ウェブスケールディスカバリーサービス（CA1772参照）では図書館のOPACや出版社のデータベースからセントラルインデクスにメタデータを取り込む方法として使われている（E1604参照）。
2.3. 問題点
OAI-PMHは仕様の簡潔さもあって、図書館界で広く普及してきた。しかし、以下のようにいくつかの課題を抱えていることも事実である。
（1）収集対象がメタデータのみである
OAI-PMHはメタデータの記述対象であるコンテンツ自身の収集に対応していない。多様なアクセスポイントを提供するだけならば問題ないが、長期保存のためのバックアップや全文検索機能の提供を目的とする場合にはコンテンツ自身の収集が必要となる(11)。また、アクセス負荷分散のためにミラーサイトを設置したい場合にもOAI-PMHでは不十分である(12) (13)。
（2）図書館界以外では普及していない
例えば、Googleは利用の少なさを理由として2008年にGoogle SitemapsにおけるOAI-PMHのサポートを終了している(14)。図書館界に閉じた範囲で収集している分には問題ないが、震災アーカイブのように広く一般のサービスを対象とする場合には課題を感じることもあるだろう。策定から12年以上が経過したOAI-PMHは、現在のウェブでは標準的なスタイルといえない。
（3）収集がリアルタイムではない
OAI-PMHはプル型のしくみであり、収集の主導権はサービスプロバイダにある。データプロバイダ側でコンテンツが生成されたことをサービスプロバイダに通知（プッシュ）する手段を設けていないため、収集までにタイムラグが生じがちである。メタデータだけでなくコンテンツの収集をも行うならば、リアルタイム性は重要になるだろう。
3. ResourceSync Framework Specification
このようなOAI-PMHの限界を乗り越えるべく、ResourceSyncの開発が始まった(15)。本節では、そのコアであるResourceSync Framework Specification（バージョン1.0）の要点を紹介したい。
3.1. 特徴
ResourceSyncの同期の対象は、URIを持つあらゆるウェブ上のリソース(16)であり、OAI-PMHのようにメタデータには限定されない。
その仕様は、Googleなどの検索エンジンに対してクロールすべきURLを知らせるための標準的な仕様であるSitemapプロトコル(17)をベースにしている。つまり、検索エンジン最適化（SEO）として既にSitemapファイルを公開していれば、そこに多少の変更を加えることでResourceSyncによる同期が実現できる(18)。
ResourceSyncのコアの仕様は、OAI-PMHと同様にプル型である。ただし、関連規格のResourceSync Notificationがコンテンツの生成などを通知するプッシュ型のしくみを定めており、これによって同期のタイムラグを減らすことが可能になる。
ResourceSyncは、コンテンツ数が数百万件を超える大規模環境や、秒単位で頻繁に更新されるようなコンテンツを想定し、スケーラビリティに配慮した設計を目指している(19)。
3.2. 同期のプロセス
次にResourceSyncによる同期の基本的なプロセスを説明したい。詳しくは「仕様書」(20)の§5を参照いただきたい。
まず、同期の対象となるリソースを持つサーバは「ソース（Source）」、同期を行うシステムは「デスティネーション（Destination）」と呼ばれる。
同期を行うために必要なソースの機能（capability）として、Resource List、Resource Dump、Change List、Change Dumpの4種類が定められている(21)。いずれも何らかのXMLファイルを出力するもので、それらのファイルも同様の名称で呼ばれる。例えば、Resource Listは、ある時点におけるソースのリソースを全て列挙するものである。Resource Dumpは、ある時点におけるリソース全体をパッケージングしたZIPファイル(22)の場所を示すものである。Change ListおよびChange Dumpは、それぞれResource ListおよびResource Dumpに対応するもので、ある時点からの変化を記述するものである。
デスティネーションの取りうるプロセスには、ベースライン同期（Baseline Synchronization）、増分同期（Incremental Synchronization）、監査（Audit）の3種類がある。ベースライン同期は、初回同期時などに行われるもので、Resource ListやResource Dumpによって実現される。増分同期は、前回同期時から変化したリソースのみを収集するもので、Change ListやChange Dumpによって実現される。監査は、同期が正しく行われているかをチェックするもので、ソースが各機能にリソースのハッシュ値などの固定化情報（fixity）を含めることで可能となる。
図：各プロセスで必要となる機能
出典：仕様書Figure 3
実際に同期を開始する前に、ソースはこれらの機能が出力するXMLファイルのURIをデスティネーションに発見（discovery）してもらう必要がある。その方法として、ソースのrobots.txtに記述するなどの3種類が定められている(23)。
3.3. XMLの構文
ResourceSyncのXMLはSitemapプロトコルをベースに独自要素を追加したものである(24)。Resource List、Resource Dump、Change List、Change DumpはそれぞれSitemapファイルとして記述される。
以下、いくつかの記述例を紹介する。説明を簡単にするために<rs:ln>など一部の必須要素を省略している。詳しくは仕様書の§7、§10～§13を参照いただきたい。
●Resource List
Sitemapプロトコルと同様、<urlset>と<url>を基本構造とする。独自要素<rs:md>のcapability属性で機能の種類を、at属性でいつの時点の状態かを示している。リソースの数だけ<url>が繰り返され、<loc>でそのURI、<lastmod>で最終更新日時、<rs:md>でハッシュ値やファイル形式を記述している。
<?xml version=”1.0″ encoding=”UTF-8″?>
<urlset
xmlns=”http://www.sitemaps.org/schemas/sitemap/0.9″
xmlns:rs=”http://www.openarchives.org/rs/terms/”>
<rs:md capability=”resourcelist”
at=”2015-01-03T09:00:00Z”/>
<url>
<loc>http://ex.com/content.pdf</loc>
<lastmod>2015-01-02T13:00:00Z</lastmod>
<rs:md hash=”md5:1584abdf8ebdc9802ac0c6a7402c03b6″
type=”application/pdf”/>
</url>
<url>
……
</url>
……
</urlset>
●Resource Dump
<loc>でリソースをまとめたパッケージのURIを示している。独自要素<rs:ln>ではパッケージに含まれるファイルの一覧（Resource Dump Manifestと呼ばれる）の所在を表している。パッケージは複数に分割することもでき、必要ならば<url>を繰り返す。
<rs:md capability=”resourcedump”
at=”2015-01-03T09:00:00Z”/>
<url>
<loc>http://ex.com/package-1.zip</loc>
<rs:md type=”application/zip” length=”4765″
at=”2013-01-03T09:00:00Z”/>
<rs:ln rel=”contents”
href=”http://ex.com/manifest-1.xml”
type=”application/xml”/>
</url>
●Change List
<rs:md>のfrom属性で、いつの時点からの変化なのかを示している。変化のあったリソースを<url>で列挙し、それぞれの<rs:md>のchange属性で変化の種類（新規作成・更新・削除）を表している。
<rs:md capability=”changelist”
from=”2015-01-03T00:00:00Z”/>
<url>
<loc>http://ex.com/content1.html</loc>
<lastmod>2015-01-03T11:00:00Z</lastmod>
<rs:md change=”created”/>
</url>
<url>
<loc>http://ex.com/content2.pdf</loc>
<lastmod>2015-01-03T13:00:00Z</lastmod>
<rs:md change=”updated”/>
</url>
<url>
<loc>http://ex.com/content3.tiff</loc>
<lastmod>2015-01-03T18:00:00Z</lastmod>
<rs:md change=”deleted”/>
</url>
なお、Sitemapプロトコルでは、1つのSitemapファイルのサイズは5万URLまたは10MBまでという制限があり、それを超える場合は、複数のSitemapファイルに分割し、別途作成したSitemap indexファイルからリンクすることになっている(25)。このような階層構造によって1つのSitemap indexファイルで最大で25億URLのリソースを記述できる。ResourceSyncもこの方法に従っており、Resource ListやChange Listに対するSitemap indexファイルをResource List IndexやChange List Indexと呼んでいる(26)。
3.4. メタデータハーベスティング
もちろんResourceSyncはメタデータのみの収集にも対応している(27)。一般のリソースの同期と同様、Resource Listなどの機能で実現されるが、コンテンツと同じようにメタデータもURIを持ったひとつのリソースでなければならない点に注意が必要である。
コンテンツとメタデータの関係はrel属性で記述できる。コンテンツに対してはrel=“describedby”で、メタデータに対してはrel=“describes”で相手との関係を表現できる。
<url>
<loc>http://ex.com/content.pdf</loc>
<rs:ln rel=”describedby”
href=”http://ex.com/metadata.xml”>
</url>
4 関連する動向
4.1. 関連規格
現在、ResourceSync Framework Specificationの関連規格として、ResourceSync Archives(28)、Relation Types used in the ResourceSync Framework(29)、ResourceSync Notification(30)がドラフト段階にある。このうちResourceSync ArchivesとResourceSync Notificationはコアの拡張という位置づけである。
ResourceSync Archivesは、ソースから過去の時点におけるリソースのスナップショットを取得するためのしくみで、Resource Dump Archive、Change List Archive、Change Dump Archiveという3つの機能について定めている。この規格はソンペルらのウェブアーカイビングプロジェクトMemento（CA1733、E1573参照）と関わりが深い。
ResourceSync Notificationは、ソースにおけるリソースの生成などをデスティネーションに対して通知するプッシュ型のしくみについて定めている。一般にウェブでプッシュ通知を実現する方法はいくつかあるが、ここではPubSubHubbub(31)が採用されている。
4.2. 実装実験
管見のかぎりでは今のところResourceSyncを実運用として実装したサービスは見られないが、いくつかの実験は行われてきている。
例えば、コーネル大学図書館のワーナー（Simeon Warner）(32)によってarXivのデータを用いたシミュレーションが行われ、Resource ListやChange Listが公開されている。
ロスアラモス国立研究所のクライン（Martin Klein）ら(33)は、更新の激しいソースとしてWikipediaのLinked Data版サイトであるDBpedia Live(34)を取り上げ、プッシュ通知の実験を行っている。
また、ソンペルは、プッシュ通知を使ってリソース同期を行うデモ動画を公開している(35)。
4.3. ツール
ResourceSyncの普及のためには、DSpaceのような代表的ソフトウェアで実装されることが有効である。例えばCottage Labsは、ResourceSyncでメタデータハーベスティングを行うためのJavaライブラリとDSpaceモジュールを公開している(36)。現在はメタデータに留まり、Resource DumpやChange Dumpによるコンテンツの同期は今後の課題となっている。
また、resyncという、Pythonで開発されたクライアント（デスティネーション側）とライブラリ（ソース側、デスティネーション側）が公開されている(37)。合わせて動作するResourceSync Simulatorというソース側のシミュレータも公開されている(38)。
ResourceSync PuSHという、PythonによるResourceSync Notificationの実装も存在する(39)。
5. おわりに
以上、メタデータハーベスティングの規格として成功したOAI-PMHにもいくつかの課題があること、そして、それを乗り越えるために登場した標準規格ResourceSyncの概要について紹介してきた。
コア以外の仕様も固まりつつあるResourceSyncだが、実装は現時点では実験段階に留まり、今後実際に広く活用されていくかは未知数という印象である。しかしながら、電子コンテンツの長期的な保存など、リソース同期の標準的な方法が必要となる場面が存在することは疑いがないだろう。図書館界を超えて広く採用されるかどうか、注目したい。
（※参照URLの最終確認日はすべて2015年2月13日）
(1) ResourceSyncには関連規格も含めて現在4つの仕様が存在する。本稿ではそれらの総称として“ResourceSync”という表現を用いる。
“ResourceSync Framework Specification – Table of Contents”. NISO. 2014-07-02.
http://www.openarchives.org/rs/toc.
(2) 原語を尊重して「同期」と表現するが、ResourceSyncはOAI-PMHと同様に双方向的な同期を実現するものではない。
(3) “ResourceSync Framework Specification (ANSI/NISO Z39.99-2014)”. NISO. 2014-04-21.
http://www.openarchives.org/rs/resourcesync.
(4) 正確にはサービスプロバイダのハーベスタが、データプロバイダのリポジトリからメタデータを収集する。
(5) 仕様上は“may”とされ、出力は必須ではない。
(6) 国立情報学研究所. “IRDBハーベストについて”. 学術機関リポジトリ構築連携支援事業. 2015-01-23.
http://www.nii.ac.jp/irp/archive/system/irdb_harvest.html.
(7) “Open Archives Initiative (OAI)”. ArXiv.
http://arxiv.org/help/oa/index.
(8) “5 国立国会図書館東日本大震災アーカイブとの連携について”. 国立国会図書館東日本大震災アーカイブ.
http://kn.ndl.go.jp/static/renkei.
“Technical requirements”. Europeana.
http://pro.europeana.eu/technical-requirements.
“DPLA Participation Instructions”. DigitalNC.
http://www.digitalnc.org/about/dpla/dpla-instructions/.
“OAI-harvestable records for digitized historical collections”. Library of Congress. 2008-05-23.
http://memory.loc.gov/ammem/oamh/index.html.
(9) 国内公共図書館でも例がある。
“大阪府立図書館 Web-API 情報”. 大阪府立図書館. 2014-02-21.
http://www.library.pref.osaka.jp/site/e-service/webapi.html.
(10) “国立国会図書館サーチが提供するOAI-PMH”. 国立国会図書館サーチ.
http://iss.ndl.go.jp/information/api/oai-pmh_info/.
(11) Van de Sompel ，Herbert．et al． Resource Harvesting within the OAI-PMH Framework. D-Lib Magazine. 2004, 10(12).
http://www.dlib.org/dlib/december04/vandesompel/12vandesompel.html.
(12) arXivは1990年代から独自の方法でミラーリングを行っている。
Van de Sompel，Herbert． “ResourceSync: A Web-Based Resource Synchronization Framework”. 2013-06-19.
http://www.slideshare.net/hvdsomp/resourcesync-tutorial-oai8.
(13) OAI-PMHを用いてコンテンツを同期させる方法が2004年に提案されている。後年、普及には至らなかったと振り返られている。
Van de Sompel ，Herbert．et al． Resource Harvesting within the OAI-PMH Framework. D-Lib Magazine. 2004, 10(12).
http://www.dlib.org/dlib/december04/vandesompel/12vandesompel.html.
Van de Sompel ，Herbert．et al． A Perspective on Resource Synchronization. D-Lib Magazine. 2012, 18(9-10).
http://www.dlib.org/dlib/september12/vandesompel/09vandesompel.html.
(14) Mueller, John. “Retiring support for OAI-PMH in Sitemaps”. Google Webmaster Central Blog. 2008-04-23.
http://googlewebmastercentral.blogspot.jp/2008/04/retiring-support-for-oai-pmh-in.html.
(15) Van de Sompel，Herbert．et al． A Perspective on Resource Synchronization. D-Lib Magazine. 2012, 18(9-10).
http://www.dlib.org/dlib/september12/vandesompel/09vandesompel.html.
(16) Van de Sompel，Herbert． “ResourceSync: A Web-Based Resource Synchronization Framework”. 2014-01-24.
http://www.slideshare.net/OpenArchivesInitiative/resourcesync-tutorial.
(17) “What are Sitemaps?” Sitemaps.org.
http://www.sitemaps.org/.
なお、Sitemapの最初のバージョンである0.84が登場したのは2005年であり、OAI-PMHの策定後である。
Shivakumar, Shiva. “Webmaster-friendly”. Official Google Blog. 2005-06-25.
http://googleblog.blogspot.jp/2005/06/webmaster-friendly.html.
(18) 以下の論文は、Sitemapプロトコルを拡張することの懸念を3つ挙げ、実際にGoogleに処理させて問題が起こらないかを実験している。
Klein, Martin．et al． “Extending Sitemaps for ResourceSync”. 2013-05-21.
http://arxiv.org/abs/1305.4890.
(19) Van de Sompel， Herbert． “ResourceSync: A Web-Based Resource Synchronization Framework”. p. 10-11. 2013-06-19.
http://www.slideshare.net/hvdsomp/resourcesync-tutorial-oai8.
(20) “ResourceSync Framework Specification (ANSI/NISO Z39.99-2014)”. NISO. 2014-04-21.
http://www.openarchives.org/rs/resourcesync.
(21) ResourceSyncの仕様はモジュラー（modular）な設計になっており、例えばベースライン同期を行うだけであれば、Change ListやChange Dumpの実装は必要ない。
Van de Sompel，Herbert． “ResourceSync A Quick Overview”. 2014-09-30.
http://www.slideshare.net/hvdsomp/resourcesync-quick-overview.
(22) 仕様書ではZIP形式が使われているが、他の形式でも良いとされている。
(23) 仕様書§6.3を参照。デスティネーションがソースの機能を発見する方法には、Source Description、Capability List、Resource Listなど、の3種類がある。
(24) 記述方法としてSitemap、Atom、独自仕様を検討し、最終的にSitemapが採用された。§4に理由が述べられている。
Klein, Martin. et al. Technical Framework for Resource Synchronization. D-Lib Magazine. 2013, 19 (1-2).
http://www.dlib.org/dlib/january13/klein/01klein.html.
(25) “Frequently asked questions”. Sitemaps.org. 2008-02-27.
http://www.sitemaps.org/faq.html#faq_sitemap_size.
(26) 仕様書Figure 4を参照。
(27) 仕様書§14.5を参照。他にも§14ではリソース間の関係を記述する方法が定められており、OAI-PMHのセット（set）や、OAI-ORE（CA1690参照）の集合体（aggregation）についても言及されている。
(28) Klein, Martin. et al. “ResourceSync Framework Specification – Archives – Beta Draft”. 2013-08-21.
http://www.openarchives.org/rs/0.9.1/archives.
(29) Klein, Martin. et al. “Relation Types used in the ResourceSync Framework – Beta Draft”. NISO. 2013-09-27.
http://www.openarchives.org/rs/0.9.1/relationtypes.
(30) Klein, Martin. et al. “ResourceSync Framework Specification – Notification – Beta Draft”. NISO. 2014-03-24.
http://www.openarchives.org/rs/notification/0.9/notification.
(31) Fitzpatrick, Brad. et al. “PubSubHubbub Core 0.4 — Working Draft”.
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html.
(32) “ResourceSync experiments on resync.library.cornell.edu”.
http://resync.library.cornell.edu/.
(33) Klein, Martin. et al. “Real-Time Notification for Resource Synchronization”. 2014-02-11.
http://arxiv.org/abs/1402.3305.
(34) “DBpedia Live”.
http://live.dbpedia.org/.
“DBpedia Live”. DBpedia. 2015-01-08.
http://wiki.dbpedia.org/DBpediaLive.
(35) “ResourceSync Change Notification Demo”. 2014-04-07.
https://www.youtube.com/watch?v=H2Le9_Bbkdw.
(36) “ResourceSync Module for DSpace”. Cottage labs.
http://cottagelabs.com/news/resourcesync-module-for-dspace.
“ResourceSync”. Cottage labs.
http://cottagelabs.com/projects/resourcesync.
(37) “resync 1.0.0”. Python.org.
https://pypi.python.org/pypi/resync/1.0.0.
(38) “resync/resync-simulator”. GitHub.
https://github.com/resync/resync-simulator.
(39) “resync/resourcesync_push”. GitHub.
https://github.com/resync/resourcesync_push.
[受理：2015-02-13]
林豊. ResourceSync：OAI-PMH の後継規格. カレントアウェアネス. 2015, (323), CA1845, p. 17-21.
http://current.ndl.go.jp/ca1845
DOI：
http://doi.org/10.11501/9107589
Hayashi Yutaka.
ResourceSync: A successor of OAI-PMH.
本著作（CA1845）はクリエイティブ・コモンズ 表示 2.1 日本 ライセンスの下に提供されています。ライセンスの内容を知りたい方はhttp://creativecommons.org/licenses/ by/2.1/jp/ でご確認ください。
