Previous month:
2006年3 月
Next month:
2006年5 月

2006年4 月

RSSとOAI-PMH

 OAI-PMH。Open Archives Initiative Protocol for Metadata Harvesting。

 今朝、昨日エントリした記事の論文の共著者から「OAI-PMHの方が高機能じゃないですか?」との指摘。さっそく「OPAC2.0で検索してこのページで言及されてましたよ」というblogを拝見してみる。おお、fj時代からのOPACリストのユーザとは。元管理者としてはありがたいことです。ということで、コメントに失敗したのでトラックバックさせていただきます。

 で、再考。確かにOAI-PMHの方が指定の更新期間/カテゴリ/データIDでデータを取得できるなど、データハーベスト時の自由度は高い。GETメソッドでリクエストしてXMLでデータを取得するわけだから、やっていることはRSSとはそれほど変わらない。というより機能的には上。中の名前空間もDublinCoreとかMARC21もOK。OAIsterみたいなアグリゲータは細かいメタデータをちゃんと理解してくれて検索サービスを提供してくれる。ただ、各機能の実装が大変そうなイメージが個人的には残るところ。

 RSS。適切にXMLで記述してWebサーバに置けばOK。超ラク。無理すればエディタで手書きでも何とかなる。でもDublinCoreのエレメント(ですら)をフルに使ってもほとんどのRSSリーダは全部を理解しない。データをいくらリッチにしても、処理はクライアント任せ。ちょっと寂しい。データの取得も、ただ一方的にもらうだけ。「何番目のデータ」とか「この分野のをちょいと一つ」みたいな指定は、やっぱりサーバにGETメソッドで細かくリクエストして動的にはき出させないと結局は無理。それともクライアント側が賢くなって、適切にフィルタしてくれるのか。
 簡単に利用できるところがRSSの普及の一因になったところもあると思うので、あまり無理難題は押しつけられないけれども、RSSで中のメタデータをどんどんリッチにして配信しようとすると、結局はOAI-PMHの方が便利だよというところに行き着いてしまうのかもしれない。

 さてどうしよう。

 折衷案的には、バックボーンになる大きなリポジトリ/アグリゲータ間で流通するメタデータはOAI-PMHで、個々のリポジトリ/アグリゲータからユーザへの配信はRSS、みたいに役割分担をすればいいのかな。詳しい(リッチな)データが欲しければ最寄りのアグリゲータに聞いてくれ、みたいな。ユーザのPC上のクライアントS/Wが専用の巨大なハーベスタを持っている、というのは現実的ではなさそう。無理ではないけれど。

 もうちょっと考えてみる。現状のOPACをOAI-PMHで流そうとすると、当然件名とか分類でハーベストするデータを選別できるようセット区分が必要になるだろう。実は弊社のOPACには件名などこれに適応できるデータを持ったレコードが少ない。どのデータでセットを仕分けるか、このあたりを適切に定義づけないとデータをハーベストする側が大変になりそうなので、ちゃんと考える必要がありそうだ。これも標準化が必要?

 すぐにできる話ではないけれども、こうやって考えてみればOAI-PMH対応も役に立ちそう。・・・やってみるか。今年度中に。まだ年度初めだけど。


RSSでOPACな原稿掲載

 INFOPRO2005の後依頼があり、年始から書いていたRSSでOPACな原稿がようやっと校正も終わり、4月1日からWebサイトで公開されていました。よろしければ、サンプルスクリプトとあわせてご覧ください。また、ご意見ご感想をお待ちしております。本当に。

 当初は、INFOPRO2005の予稿をベースに、「原稿を読んだ担当者がRSSでのサービスを始められるような内容を」ということで、RSSの利用事例やサービス提供のための how to 中心で書いていました。で、筆が滑って「もう少し進んだ内容を」と思い「amazon web serviceのようなAPIを持ったOPACの実現→OPAC2.0への進化」について書いたところ、主にスクリプトを書いてくれた共著者から「これは熱いコンセプトですよ!これで押しましょう!これで!」と熱く迫られ、文章のトーンも「XMLにすることで、ほーらこんなメリットが」というようなものに変化してゆきました。結果、予定枚数を大幅に超えてしまい、サンプルスクリプトも別にWebページに掲載するなど、編集ご担当の方にはご迷惑をおかけしました。

 OPAC2.0的に目指すところとしては、こんなことができるといいなと。なんとなくWeb2.0ライクに。あとは本文をご参照ください。

  • XMLでデータを取り出して入力インターフェースをリッチに(タグクラウドなど
  • RSS/XMLによる検索結果出力で
    • キーワードを登録して新着図書のアラートをRSS/ATOMで受信
    • 検索結果出力インターフェースも自由に設計可能
  • 他のXML化されたサービスとの連携(Web2.0的に言えばマッシュアップ)

 とりあえずはOpenSearch対応かな、ということで、これはこれで準備を進めています。また、RSS/ATOMだけでなく、これにMODSの記述要素を加えて詳細な書誌情報をあわせて配信すべく準備中です。言ったからにはやらないと。

 職場でも議論したのですが、何と連携させるか、「リッチなインターフェース」とは何か、まだまだ試行錯誤が続きそうです。

 今、気になっているのはMicroformatです。hReviewのようなclass属性で記述してゆくアレ。第3回FBSカンファレンス(資料こちら)でのNII(というよりglucoseの方)の大向さんの発表で概要を知ったのですが、図書館での書誌事項用の記述定義がMicroformatでできて、各社OPACの通常の検索結果出力がこれに対応するだけでも何かが変わるような気がします。

 OPAC。10数年前にtelnetでアメリカの大学図書館のOPACが引けることを知り感動を覚え、国内のOPACのリストを作り、とうとうOPAC2.0なんてたわごとを言い出し始めてしまった私。これからどうしましょう。