図書館退屈男

今夜もConnotea Codeのインストールにチャレンジ。mod_perlの問題でもう３～４日ははまっているのですが。しかも動いたところでデモ用以外に使途は（たぶん）なし。

「今日本中でこんな作業しているのは自分だけ…かも。」漂う寂寥感。

　Apache2.0.54+mod_perl2.xでは動かない。connoteaのPerlモジュールが必要としているモジュールがmod_perl2の中に無い。mod_perl1のモジュールが呼ばれている。マニュアルには推奨されるmod_perlのバージョンなんか書いてない。理由が分からない。理不尽。

　開発者用メーリングリストを見ると、「mod_perl_1.99なら動く」との神託が。
…そういう大事なことは普通マニュアルに書くべきものではないのか。＞nature publishingの中の人。

　naoyaのはてなダイアリーの今年１月のエントリ、mod_perl 2.0.2 へのマイグレーションによれば、

現在、mod_perl には互換性のない三つのバージョンが存在してます。

• mod_perl 1.0 (1.29)
• mod_perl 1.99
• mod_perl 2.0 (2.0.2)

（略）
1.99 というのは、mod_perl 2.0 が Stable リリースされる直前までのバージョンで、言うなればベータ版。ベータが取れるときにいくつかの API が変更になったり、名前空間が Apache から Apache2 に変更されたりといった経緯があって、その両者はだいたい同じなんだけど互換性がありません。

とのこと。仕方がないので 2.0 と 1.99 をそれぞれyum installやCPAN shellからインストールしたり、rpmでパッケージから入れてみたりと試行錯誤を続け、結局ソースから以下のオプションでビルド。

$ cd mod_perl-1.99_12
$ perl Makefile.PL MP_INST_APACHE2=1 \
  MP_APXS=/usr/sbin/apxs \
  MP_APR_CONFIG=/usr/local/apache2/bin/apr-config \
  MP_GENERATE_XS \
  MP_USE_DSO \
  MP_STATIC_EXTS \
  MP_COMPAT_1X=1
$ make
# make install

　ちなみに、/usr/sbin/apxs はもともとのFedoraCoreのパッケージ版、/usr/local/apache2/bin/apr-config はソースからビルドしたもの。どちらもApacheのバージョンは2.0.54。

　mod_perlがらみのエラーはなくなり何とか動きそう。しかしマニュアルにあった以外のPerlモジュールを入れろと言ってくる。（指定のモジュールをインストール中にPerlを5.6.0->5.8.8にさせられたりもしましたが。しかもインストール場所を間違えてpathが混乱して２回もインストール。）
　で、

HTTP::OAI::UserAgent
Cache::Memcached
DBI-1.50.tar.gz

　などを投入。これでPerlモジュール依存のエラーは解消。

　httpdも起動するようになったし、さてブラウザからアクセスすると…Error 500。
logを見るとデータベースに接続できていないようだ。おかしいな。マニュアル通りにDBアクセス用のユーザを作って /etc/bibliotech.conf にも書き込んだのに。

　よーくマニュアルを見て気がついた。DBのテーブルを作るSQLは作成しているのに、CREATE DATABASE していない。そうですか。方法は書かないけどそれぐらいは暗黙の了解。空気読めよと。イギリス人らしいスタイルだな。ペルーから単身渡英して駅で暮らしていたクマを受け入れる余裕があるだけのことはある。（本文とはまったく関係ないが、「老くまホーム」があるくらいペルーのクマ福祉政策は充実しているのになぜ渡英。謎だ。）

　そしてテーブルを作るためSQLを食わせるとエラーを吐くMysql。どうしたものか。明日も続くのか。もう意地だ。

2006/05/24 追記

そんな苦労をしなくても、開発用メーリングリストからの最近の情報では、perl5.0.8+mod_perl2でもコードをちょっといじれば動作するようだ。

あと、MySQLの件はこちらのポカ。catとかechoしないとテキストファイル中のSQLは出力されないじゃないか。超初心者なミス。

で、とりあえず動いてはいますが…機能を何も設定していないからユーザ登録しかできない寂しい状態。時間があったらなんとかしよう。

　図書館blog界のメインストリーム（ってなんだ）から遠く離れた話題がメインのこのblogでも、最近は「見てますよ」とご同業の方からコメントを頂くことが多くなりました。現状の月２回更新から頻度を上げてゆかないと、と思う午後。

　それはさておき。

　先日、あるメールマガジンの主催で初めて「ネット対談」というものに参加させていただきました。企画そのものは３月ぐらいからご提案いただいていたのですが、諸般の事情で４月末になったものです。ネタは「RSSの学術利用」です。バックナンバーも公開されておりますので、詳しい内容はそちらをご覧ください。
　メッセンジャーを使っての３人での対談でした。メッセンジャーを使い慣れていないこともあり、どのタイミングで返事を返せばいいのか、どのあたりで文節を区切ればいいのか、でもお二人とも初対面（メールでのやり取りだけで、お会いしたことはないのです）だし緊張、などと戸惑うばかりでしたが、編集された原稿を見るとちゃんとまとまっており、

Ａさん：図書館退屈男さんのところは進んでますよね。
Ｂさん：そうですね。すごい。
わたし：ありがとうございます。

という「お褒めにあずかる→同意→お礼」なシーンが何度かあり、なんだか持ち上げられてばかりなような。腰低いぞ＞自分。

　最初は１時間の予定でしたが話が盛り上がり気づけば２時間以上経過。さすがに最後の方はだいぶ打ち解けた会話ができました。OPACにまつわる懐かしい話題や今後の展開など、大分勉強させていただいたほか、あとから読み返すと新しいアイディアも思いつくものです。オフレコとした部分も大分あったので、編集された方にはご苦労をおかけしましたが、貴重な体験をさせていただきました。
　対談の最後やその後のメールでのやり取りでは、どこかの会合などでの再開を約束して締めとなりました。こうしてOffline→Onlineの関係ができてゆくのですね。楽しみです。

　掲載用原稿の校正やらそんなこんなをしているうちに、OPAC関係のネタでの発表依頼を頂きました。８月だそうです。それまでにまた皆様にお見せできるサンプルを作らないと。プレッシャーと発表させていただける喜び。本当にありがたいことです。

追記：2006/05/05

そのメールマガジンですが、本日朝に無事配信されました。記事はこちら(blog版)。

　某大の方から、メールで「うちの機関リポジトリに登録した雑誌のメタデータをハーベストしませんか？」というお申し出を頂いた。ありがたいお話。

　ということで、OAI-PMHなハーベスタと検索インターフェースぐらいは用意しないとまずいなあ、でも今あるプロトタイプだと検索がいまいちだし。仕様を書いたのは自分なので文句も言えず。

　で、先日慶應大のシンポジウムで発表があったXooNIpsに目をつけた。参加しておいてよかった。
XooNIpsはXoopsのモジュールとして構成され、

• MySQL
• PHP
• Apache

で動作する。当然であるがXOOPSのその他のモジュールも利用できる。開発は理化学研究所脳科学総合研究センターニューロインフォマティックス技術開発チーム。

　リポジトリに登録するデータの投稿→(査読→編集)Ｘn→掲載の流れをサポートするDspace等と違い、ラボや研究所単位での「従来のように論文などの紙を媒体とした書誌による情報だけでなく，実験データ，数理モデル，シミュレーションプログラム，結果のデータやグラフ，URLなど電子情報を含めた様々な研究資源をインターネットによって共有する」(http://xoonips.sourceforge.jp/modules/bwiki/index.php?intro-aboutより引用)システムで、論文、グラフ、URL等のアイテムタイプごとに入力項目を変えて対応できる。研究室や研究チーム内などで情報共有を図るにはよさそうなツール。

　データの公開レベルは

• Public（一般に公開。OAI-PMHでのハーベスト対象）
• Group（特定のグループ内でデータを共有）
• Private（個人用のフォルダ）

となっており、Publicにデータを上げるためにはmoderatorによる査読を通すこともできる。OAI-PMH対応リポジトリからのデータハーベストも可能。これだけあれば十分だ。

　やはり大きいのは検索も元々の使用言語が日本語であること。これだけでも大分敷居が低く安心だ。

　詳細は、

• オフィシャルサイト: http://xoonips.sourceforge.jp/
• XooNIpsデモサイト:　http://xoonips.brain.riken.jp

　を参照されたい。ダウンロードにはユーザ登録が必要。

　ということでインストール。当方ではFerodaCore4上で構築してみた。早速MySQLのダウングレード(4.1系から4.0.26へ)。あとはODBC系のドライバ、XOOPSのインストールと続く。
　ここまで終わるとXooNIps本体の導入になる。XooNIps構築の際に必要となるPHP拡張ライブラリ、Abstract Layerの構築でmake installすると

[root@cl3 AL]# make install
make[1]: Entering directory `/usr/local/src/xoonips/AL'
test -z "/usr/lib/php/modules" || mkdir -p -- "/usr/lib/php/modules"
/bin/sh ./libtool --mode=install /usr/bin/install -c 'XNPAL.la' '/usr/lib/php/modules/XNPAL.la'
/usr/bin/install -c .libs/XNPAL.so /usr/lib/php/modules/XNPAL.so
/usr/bin/install -c .libs/XNPAL.lai /usr/lib/php/modules/XNPAL.la
PATH="$PATH:/sbin" ldconfig -n /usr/lib/php/modules
----------------------------------------------------------------------
Libraries have been installed in:
/usr/lib/php/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
make[1]: `install-data-am' に対して行うべき事はありません。
make[1]: Leaving directory `/usr/local/src/xoonips/AL'

とwarning。XNPAL.soは生成されているが、何が悪いのか。ライブラリのパスを変更したりするなど試行錯誤したがここではまり、窮して公式Webサイトのフォーラムで質問。「それでＯＫ。インストールを続けてください。」との返事があり、安堵。ありがたい。
続いて、XOOPSのSYSTEM ADMIN->ModulesからXooNIpsや各種アイテムタイプをインストール。あとはFAQに従いphp.iniのmemory_limitを適当に増やしてapacheを再起動。おお動いたよ。PMIDから論文のメタデータを引いて登録できたりするよ。すばらしい。

　そのほか、ついでと思ってyum install perl-*とかしたらいつの間にかMySQLのバージョンが元に戻っていたりなど手戻りもあったが、安定して運用できそう。

　と、そんなこんなで休暇のうち1.5日程度費やされる。新しいソフトのインストールって楽しいよね。でもそれでいいのか。まあいいや。

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

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

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

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

　さてどうしよう。

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

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

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

　INFOPRO2005の後依頼があり、年始から書いていたRSSでOPACな原稿がようやっと校正も終わり、４月１日から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なんてたわごとを言い出し始めてしまった私。これからどうしましょう。

前回のエントリ、図書館タグクラウドに特にはてな方面から多くのアクセスを頂き、ありがとうございました。このblogを始めて以来のアクセスの多さに驚いています。

タグクラウド、人気ありますね。他のデータベースでも応用したいところです。

さて、その後ですが、ひどいソースを見た後輩が大幅に手を入れて、

• 専門用語の抽出には，東京大学・中川裕志教授，横浜国立大学・森辰則助教授，東京大学・前田朗らによる「専門用語自動抽出システム」を利用。
• 書誌名を日本語と英語に簡易分離。
• 日本語については，形態素解析器 MeCab を用いて形態素解析を行った後，専門用語自動抽出用 Perl モジュール TermExt::MeCab を用いて専門用語を抽出。
• 英語については，専門用語自動抽出用 Perl モジュール TermExtract::EnglishPlainText を用いて専門用語を抽出。
• 抽出した専門用語とその重要度を元に，HTML::TagCloud を用いて重み付け。

という「なんだよ俺のは噛ませ犬か」と思うくらいcoolなhackを施してくれました。ありがたいことです。

おかげさまで、単語についてもかなり真っ当に切り分けられるようになりました。安定して稼働するようになりましたら公開の予定ですが、とりあえずスナップショットでお楽しみ下さい。

あ、OpenSearch対応については実装作業中です。もうしばらくお待ち下さい。

　mixiの司書コミュでのOPACについての議論の中であった、「自分では選ばないような本との出会いができるOPAC」というご意見を参考に、また「はてラボ」（http://hatelabo.jp/）のプロジェクトの一つ、「はてなWordLin」(http://wordlink.hatelabo.jp/)にインスパイアされて、図書館の新着図書・雑誌情報のタグクラウドのようなものを作ってみました。
お試しはこちらから：

新着図書の海へ

　細かいところでは謎の単語があったり解析しきれていなかったりとβ版な状態ですが、頻出単語のフォントサイズを大きく見せるなど、それらしいものに仕上がりました。リンクは弊社OPACへの検索へと繋がります。

　プログラム言語にはPerlを使用していますが、リファクタリング必死な素人コーディングです。なのでコードは内緒。

以下、処理の概要です。

1. LWP::Simple::getで各拠点図書室56個所の新着図書/雑誌受入情報RSSフィード112を取得、XML::RSSでitem要素のうちtitle(書誌名)だけを抽出。
2. 抽出したtitleを形態素解析器 MeCab ( http://chasen.org/~taku/software/mecab/ )を使用して単語と品詞を解析。
   解析の例は上記のURLをご参照ください。
   出力パターンをカスタマイズして、このうち表層形(単語)と品詞のみを出力させています。
3. 解析した品詞のうち名詞だけを抽出し、重複している単語の数をカウント。
4. 使用している単語でこちらのOPACへの検索式が投げられるようURLを生成、単語からリンク。
   getメソッドでqueryを投げられるのはこういう時楽です。URLに埋め込む検索語はURLエンコードしています。
5. 単語の使用回数に応じて、スタイルシートで <span style="font-size : 3em">単語</span> のようにして各単語のフォントサイズを決定。
   いろいろ試行錯誤して調整してみましたが、見やすさを考え、4回以下、5～9回、10～20回、21回以上でそれぞれ1～4emにしています。
6. 単語とリンク部分をJavaScriptで書き出し、ocean.htmlから呼び出す方法を採用。
   この方法ですと、他のサーバのページからも自由に呼び出すことができます。（今回の場合はニーズは少なそうですが） JavaScript自体は毎朝cronで更新します。

　件名なりその他利用できそうなデータが入っていれば、もっと使い出があるとかもしれませんが、今回は新着図書/雑誌中の単語からOPAC全体を検索させることで、「意外な資料との出会い」の場のような感覚を持ってもらえるかもしれません。

　あとは、解析の基礎になる辞書の精度向上などの部分がまだ未完成ですかねえ。明らかに分かち書きしていない単語もありますし。英単語が「感動詞」扱いで拾えていなかったり。もうちょっと工夫する余地はありそうです。

　このデータのRSSフィードによる再配信も考えましたが、頻出単語ばかり送るのも飽きられそうですし、ここはやはりlongtail狙いであえて出現頻度の少ないキーワードを配信するのがGoodでしょうか。

　以前のエントリのOPAC2.0についても再考中ですが、今日はこんなところで。

　気がつくと、「原稿書きました」とか「発表終わりました」とかそういうエントリが多い自己顕示なこのblog。

　今日もつまりはそういう話なのですが、風呂敷を広げてみたので事前に世間様の反応を見てみるテスト。

　で、本題。OPAC2.0というものを考えてみました。次世代のOPAC。だから2.0。

　似たような名前で、次世代のネットワークの方向性を示す言葉として「Web2.0」というのもありますが、これはTim O’Reillyさんの論文「Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（前編）」(CNET JAPAN掲載の和訳版)や上原さんのblog近江商人 JINBLOGのエントリWeb2.0 とは　－7つの分類と要素MAPなどを見ていただくとして、このような考え方を図書館サービス、特にOPACに応用して考えてみました。

　まず現状のOPAC。従来のOPACは、自館の利用者に所蔵資料の機械検索サービスを館内で提供するところから、インターネット上にまでそのサービスを広げています。気の利いたところであれば、文献複写の依頼や貸し出し予約までできちゃいます。便利ですよね。

　しかし、キーワードを入力し検索結果として書誌データの一部が返ってくるというシステムそのものについてはOPACの導入当初からなんら変わっていません。新着図書の一覧や雑誌の到着状況を知るにも、お知らせの紙やOPAC経由でした。

　なぜいちいちOPACを経由して、あるいは検索して表示させる必要があるのでしょう？　利用者の時間は節約すべきです。そこで我々はRSSによる配信を始めました。これで利用者に直接新着情報を届けるのです。特に雑誌の新着号の受入状況といった情報は、大学図書館など学術雑誌を扱う図書館では重要な情報となるでしょう。
　電子メールというアイディアもありました。しかし、それでは文献複写の依頼や貸し出し予約といった複合的なサービスには不適でしょう。仮に100冊の新着図書案内がメールで届いても、検索機能なしに通読することはありえません。RSSであれば、RSSリーダでフィルタリングして必要な情報のみをピックアップすることも容易です。

　他の情報との連携についても試行を行っています。例えば雑誌の目次情報です。今まででしたら「OPACで検索あるいはリンク集から雑誌を特定→(目的の号があれば)→目次情報へのリンクをたどり出版社のサイトで目次またはオンラインジャーナル閲覧」という流れになるでしょう。これをRSSを使うことで「RSSで雑誌新着号の情報を配信→ここから目次情報などを閲覧」という流れに変えることができます。たとえその雑誌のWebサイトをブックマークしていても、変更があった＝新着号が発行されたという情報をウォッチするには、毎日でもアクセスする必要があるでしょう。これをRSSによる通知に代えることで、大幅な時間の節約になります。
　さらに、「雑誌新規発行号(図書室で受け入れたかどうかは不明)の情報」に「その号の目次情報へのリンク」さらに「複数機関の図書室での受入状況」をプラスしてRSSにより利用者に届けてはどうでしょう。Current Contentsなどのサービスでは、発行前の雑誌目次情報も検索することができますが、その論文を実際に読むには、その号が自分の研究所の図書館に届くかオンラインジャーナルの契約があればそれが読めるようになるまで待つ必要があります。その号が届いているかいないか。あるいは読みに行ける範囲にある他の研究所では届いているのか。それが分かるだけでもストレスを貯めずに済むのではないでしょうか。
　「図書室での受入状況」と「雑誌新規発行号の情報」については別々のRSSで提供していますが、XMLで連携させることによりこんなサービスも実際に行っています。データはOPACから出力させていますが、利用者はそれを意識していません。見ることができるのはRSSで配信されるこれらを組み合わせた情報です。

　こうして、今までのOPACというインターフェースにこだわらず、自由に他の情報を組み合わせて提供ができる、これも一つのあり方ではないでしょうか。

　もう一つ考えてみました。OPACで出力されるのは、大抵の場合データベースに収められている書誌情報の一部です。実はさまざまなコードやデータが出力されず隠れています。また、検索結果のダウンロードができても、構造化されていない場合が多いため、再利用するにはあまり適切ではありません。

　amazonを見てみましょう。通常のインターフェースの他にWebサービスが公開され，図書であれば書名，著者名，ISBN，表紙画像などの商品情報を取得し自分のblog等で自由に利用することができます。どうして図書館のOPAC上の書誌情報ではそれができないのでしょう？
　FireFox+Greasemonkeyの組み合わせで、インストールしたPCに限ってですがamazonの検索結果から自分の近くの図書館にその本があるかどうかを検索して結果をamazonの表示内に埋め込むスクリプトが公開されています。
　それなら、amazonとOPACを同時に検索させて結果を出すようにすればよいですよね。これはXMLで連携させることで、うまくいくかもしれません。しかし、現状のRSSの要素では、本の情報-書名、著者名、発行年など-をXMLで記述するには力不足です。今使われている書誌情報を詳細にXMLで記述する必要がありますが、MODSなどのメタデータ標準を使うことで解決できるでしょう。
　こうして詳細な書誌情報をインターネット上で流通可能な状態にすることは、図書館による公共サービスの提供の一つと考えられないでしょうか。

　共通した、あるいは近い構造を持つメタデータをXMLで流通させ、お互いに連携する。これにより、図書館間の横断検索や図書館以外のデータベースとの連携も容易になるかもしれません。また、構造化された書誌データを利用者が自由にダウンロード可能になれば、図書館屋が思いつかない新しいサービスが利用者の側から作られるかもしれません。GoogleMapsがよい例です。Googleが提供する地図情報をベースに、利用者が様々なサービスを自由に構築しています。

　図書館が持つ書誌情報を、今までのOPACから開放して利用者が自由に利用可能な環境を用意する。そして幅広く利用される。このような環境、考え方をOPAC2.0と呼びたいです。

　そんなことを考え、別の文章にまとめました。どうでしょう？ OPAC2.0。

　私の考えの甘さや、至らない点がありましたらご指摘ください。
　ご意見をお待ちしています。

もうじきblogを引越ししなければならないのにcybozu.netで書き続けています。

さて、某協会誌に共著で提出した原稿が査読から返って来ました。
査読者曰く、

• 表現が冗長。特に句点が多すぎる。重複表現も多い。
• 推敲して圧縮可能

ということで、返ってきた原稿も推敲されておりました。自分の文章力のなさに泣けてきます。特に、「冗長」という点は自分の癖なのかよく指摘されていて、気をつけているつもりなのですがどうしても出てしまうようです。

まあ、明日にでも元原稿と比べてじっくり直しましょう。

ああ、一ヶ月ぶりのエントリです。読者の方、お待たせしました。

長いこと予稿書きやスライド作成で苦しめられてきた、INFOPRO2005での弊社におけるRSS関連の取り組みについての発表が無事終わりました。参加された方がこのblogに気づいてもらえれば幸いです。

「自館OPACのRSS化なんてネタ、聞いてもらえるのかなあ」という不安は見事にはずれ、70人ぐらい収容の会議室に立ち見まで出るという盛況で、またいくつか質問や協同のお申し出も頂き感謝しております。スライドは追って予稿と併せJ-STAGEに載るらしいですが、事務局と交渉し弊社公式Webサイトへの掲載を考えております。その時はまたお知らせをします。

予稿を書いてから発表まで時間があったので、その間の情勢や発想の変化、新サービスの試行などができ、スライドにはそのあたりを反映できました。

2003年初頭のMovableTypeでRSS生成、XOOPSで閲覧というテストから、同年からの本格的なサービスのためのシステム仕様策定と構築、そして2004年にサービスのカットオーバ。2005年3月には雑誌個別の受入情報のRSS化など、RSSによるOPAC上の情報配信については、「使い物になるのか」「誰が使うのか」「どう使えばいいのか」など手探りの中で進めてきました。そして、色々考えたあげくにINFOPRO2005での発表に踏み切りました。業界内など周囲の反応も知りたいところでした。

結局、このサービスで実現したかったことは「OPACの外部向けAPI提供によるWebサービス化」に至るプロセスの一つだったのかなあ、と今になって考えています。国内では学術的な情報のRSS配信は、お知らせやサイトの更新情報的な物を除けば、国立国会図書館のCurrent Awarenessが提供されている「図書館に関する調査・研究」更新情報や、の一橋大学附属図書館の附属図書館新着図書RSS提供ぐらいで(書き手の情報不足なので他にありましたらお知らせ下さい)、まだまだ数が少ないのが現状ではないでしょうか。その中で小規模な図書室の集まりではありますが、関連研究所66拠点図書室の新着図書・雑誌受入情報の配信は事例として参考としていたければ幸いです。

将来は、弊社のデータベースだけでなく、他からも有用なリソースがAPIがオープンになったWebサービスで提供され、大きな情報プロバイダによる一極集中のポータルではなく、利用者自身が使いやすい情報を選択して自分のポータルサイトを提供できる環境構築が可能になれば、と考えています。このサービスも、ポータル構築のためのパーツを構成するための第一歩です。APIの提供とオープンなサービス。こういうサービスが、今ならWeb2.0的だとかいうのでしょうか。

小規模経営の弊社としては、競合他社に飲み込まれないよう地道にサービスを続けるしかありませんが、ユーザにちょっとでも近いところに有用な情報を送り続ける、そんなサービスを構築していきたいものです。