口頭でどこかで答えたりしたことをメモっておいてツッコミ可能にしておく。
ResourceSyncって何？（ツイッター的140字）
ResourceSyncとは：OAI-PMHの後継と目されている静的連携のためのプロトコルで、sitemapsを拡張したもの。メタデータだけじゃなくてコンテンツも同期の対象にしうるとこと、情報発信側からのプッシュが可能なことが特徴。まだ普及していないが幾つか実装はある。詳しくは http://current.ndl.go.jp/ca1845 参照
ライブラリとかソフトウェアの実装状況は？
は上の記事にも載ってるけど、一番使いやすそう。他、時期的に上に漏れてる話として僕が把握しているのは
（こういうのは Scrapbox とかで Wiki 的にupdateすべきだ…）
resumptionToken の代替は？
OAI-PMHでは、3.5の Flow Control に resumptionTokenを使ってちょっとずつリソースを取ってくる実装がmust指定されている 。今こういうのは必要なくなっているのかというと、確かに回線は安定したし、太くなったし、必要は薄れているんだけれど、ResourceSync は zip で固めたコンテンツも流すんだから、その分ダウンロードが途中で切れるとかいう問題も発生しうると思う。最も大事なのは、ResourceList も複数に分けることができるのだから、ある程度は適切なサイズになるように設計すること。そして、適切なサイズのダウンロードに失敗するようなら、もう一度取りに行けばいい話。
一応、巨大ファイルの断続的ダウンロードについての解決策も、もう一つ低レイヤーの解決策が普及してきていて、HTTP range requests を使えばよいと思う。
増分同期で from で指定したいのはこっちが前回いつとりに行ったかじゃない？
ResourceSync にも Resource List の at や Change List の from といった情報があるがこれは情報を出す側の視点であって、取りに行く側からはどれを取りに行ったらいいかが OAI-PMH より複雑、というのはそれはそう。差分を処理したいときには、Change List Index から順に辿っていって、ダウンロードが必要か必要じゃないかを１つ１つ判別しつつクロールしていくことになる。resync/resync at master · resync/resync にも from オプションがあったりして、そういう利便性はライブラリレベルで解決されるべきだし、そういう方向性になっている。基本的にコストをハーベストする側に載せているので、ハーベストする側が実装を工夫する必要があるケースは他にもあると思う。
PubSubHubbub の実装は必須なの？
まず、PubSubHubbub (PuSH)じゃなくて、今は WebSub に名前変わってる。それを使う Change Notification と Framework Notification が "Additional" Specifications になっているので、必須じゃないです。Hub になるとこをどこが担うの？とか組織連携的な課題があるので、研究実験や必要性を検討した上で必須だという結論に至った実装でない限り、実装は後回しで良いんじゃないかな。
だったら OAI-PMH から移行する動機は？
- 十分な大きさの画像サムネイルを同期したいでしょ？
- 「アーカイブ」ならEADが大事だったりするし、メタデータの構造やファイルフォーマットはもっと自由に書きたいでしょ？
- もう、グーグルに拾われないとそもそも流入が望まれないのでSEOも運営上大事で、sitemaps 互換なのでSEOにもなる。
（僕はデジタルアーカイブや研究資源データベースに関する相談で聞かれるので、そういう偏りのある回答ではある）
sitemaps から、連携の必要性に応じて増築していって、ある時点で整理するという形でもよいかも。
ジャパンサーチがOAI-PMHでデータ取るって聞いてるんだけど
tl;dr OAI-PMHは必須じゃないし、ResourceSync ベースでもなんとかなりそうだよ。
僕も、OAI-PMHとウェブサイトから手動でアップロードの２つだって聞いてる。でも、ジャパンサーチ（仮称）の連携フォーマット（案） の冒頭の方に、「連携を容易にするため、原則、ファイルベースでの連携を行う（OAI-PMH は必須としない）」と強調されているように、ファイルベースになるなら ResourceSync も親和性が高いのではと期待はできる。「複数のファイルをzip形式で圧縮したファイルにも対応する。」となっているが、余計なファイルが含まれているとエラーになるようなので、ジャパンサーチ専用にファイルを生成する必要はでてきそう。それが特定の Resource List Index から自動生成できるだろうから、Resource List Index の URL を入れると、必要なファイルが返ってくるというものを誰かが作れば済む話ではある。「連携機関のメタデータモデルをそのままの形で受け入れる。メタデータモデルは原則として自由であるが、最低限の必須項目（①オリジナル（ソース）データの一意の ID、②名称/タイトルの 2 項目）がある等の制約を設ける。」というのも先ほどの自由なメタデータ記述を阻害しないように設計されている。
