OAI-PMH モニタリングのアルゴリズム（考えてみた）

こんなことしてる場合じゃないんだけど考えを吐きだしておかないと。

OAI-PMH は HTTP ベースで XML の情報を伝送するためのプロトコルです。
http://www.openarchives.org/OAI/openarchivesprotocol.html

元来が図書館・アーカイブの世界でメタデータ（ここでは書誌目録）を共有するためのものであるわけですが、プロトコル自体にはドメイン依存性はそれほどありません。すごく乱暴に言うと RSS 全文フィードに時間範囲
指定機能をつけたようなものです。XML でシリアライズされるレコードにそれぞれ
identifier がついたものが逐次に発生するならば、新しく発生したものを取得することができます。

蛇足ですが、他に、セット（フォルダみたいなもの）とフォーマット変換の機能があって、WMO 情報システム（WIS）のデータカタログではセットが多用される
（http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=oai-pmh-docu&structure=WIS+up）のですが、それは今回は捨象できます。

さて、差分取得に話を戻します。CGIみたいなクエリパラメタ from と until が指定出来て（どちらもオプショナル）、時間範囲（片方または両方の端が未指定でありうる）の取得ができるわけです。

ふつうは、from に前回実行時刻を指定して、差分だけを取得します。ところが、これを長期間運用すると色々の事情で抜けが生じる。そこをモニターするのが課題です。

一番素朴には、モニターが定期的に過去一切のレコード（識別子だけ取得可能）を取得して、手持ちと見比べるということが考えられます。シンプルなのはいいですが、レコード数に比例して取得時間がかかり、モニター取得間隔が延びていってしまいます。また、エラーレートとと掛け算すると、あるていど多数のレコードを扱う場合には成功率が無限に小さくなってしまいます。

次は、再取得を区分的に行うことが考えられます。このとき、どこからどこまでを再取得したかを保存しておかなければなりません。素朴に考えると

CREATE TABLE harvest(
tfrom DATETIME -- 開始日時 --,
tuntil DATETIME -- 終了日時 --,
tdone DATETIME -- 再取得日時 --,
count DATETIME -- レコード数 --)

みたいなことになりますが、あるレコードの tfrom は前のレコードの tuntil と同じ、という制約を考えると邪魔くさいので、tfrom はヤメにして、

CREATE TABLE harvest(
tuntil DATETIME -- 終了日時 --,
tdone DATETIME -- 再取得日時 --,
count DATETIME -- レコード数 --)

だけあればいいことになります。

再取得は、一定速度でやるのがいいでしょう。定期的にトリガーすると、いつか全数取得の間隔がトリガー間隔を超えたときに二重起動になってしまいます。手前の負荷は耐えられるかもしれませんが、サーバ側で二重アクセスするとエラーレートが増えることが疑われます。

あるいは、WIS では ListSets メソッドでレコード総数を通知する慣例があるので、それがトリガに使えるかもしれません。
（ http://www.wis-jma.go.jp/meta/oaiprovider.jsp?verb=ListSets の
ListSets/set/setDescription/dc/description 要素が "This set contains 161
records" のようなテキストになっている

このへんは、実経験でもんでないので、ちゃんと考えられていません。