図書館退屈男

　昨日に引き続きIBM OmniFind Yahoo! Edition（以下「OmniFind」と略）。

　朝、出勤してテスト用のPCを見るとログイン画面が待っていた。早速ログイン。OmniFind上でログをチェックするも、不具合のあった形跡はなし。不意のWindowsUpdateでもあったのか。気を取り直して再起動。

　マニュアルによると、「CJKな国の人はインデックスにn-gramも使えるよ」とある。インデックスのサイズが大きくなるような気がしたが、これで再構築することにした。

　約4,800件のファイルを約1時間で収集、インデックス完了。この時点でインデックのサイズは37MB。ちなみに、n-gramなしだと17MB。日本語、特にひらがなの検索にはめっぽう弱いので、素直にn-gramで作ったほうがよいのかも。あと、同義語辞書(自分で設定できる。大量登録の際はXMLで)だけではなくて、まっとうな専門用語辞書を使わせて欲しい。

　そのほか検索機能の調整。[Manage Search Experience]-[Adjust Ranking]から、以下の3項目を優先して結果表示をするか否かを調整できる。

• 更新日
• ファイルパスの深さ（例：www.hogehoge.go.jp/ja/rss/boge.html よりhttp//www.hogehoge.go.jp/が優先される）
• 被リンク数の多さ

　どれも重要な項目で、譲歩してもファイルパス以外は優先させたほうがいい場合が多いような気もするがどうだろう。

　検索画面、結果表示画面も簡単だが編集できる。検索画面は、

• 背景色
• ロゴ（左右に設定できる。デフォルトは左がIBM、右がYahoo!）
• コピーライト

などの表示/非表示を、結果表示画面についてはタイトル、URL、サマリなどの表示/非表示、文字色、背景色を設定できる。このインターフェースがよくできていて、画面に結果を反映させながら調整できるのは便利だが、触れる項目は意外と少なかった。（titleタグ相当部分も変更できない。）Enterprise Edition だともうちょっと違うのだろうか。もっとも、出来合いのインターフェースが気に入らなければ、APIが返すXML(ATOM)をうまくハンドリングするという選択肢もあるが。

　あとは「おすすめリンク」（Featured Links）が面白い。あらかじめ設定した検索語で検索を行うと、指定したページの概要とURLが表示される。また、同義語(Synonyms)の設定で、例えば「図書館」「library」「図」を登録するといずれかのキーワードをもつレコードにヒットする。ただし、ちょっと検索時間はかかるようだ。
　その他、ログとして検索が行われた時間、キーワード、ヒット件数、検索に要した時間が記録される。ヒットしなかったキーワードについても同様。OpenTextとかNamazuでしみじみと「農林一号」などの検索エンジンを作っていた頃と比べると隔世の感がある。

　ということで、システムそのもののカスタマイズの自由度はGoogle Mini > IBM OmniFind Yahoo! Ed. = Google Co-op という印象を受けたが、先のFISHのようにAPIを駆使して検索のバックエンドとするには十分だと考えられる。何しろ手軽なのはありがたい。

　次はもうちょっとヘビーなデータで試そうかな。APIもさわろう。

　金曜日(1/5)の話。

　1月5日付けカレントアウェネス-Rの記事、「OPACから”FISH”へ」。企業向け無償検索エンジン“IBM OmniFind Yahoo! Edition”を利用した総合目録。

• Free
• Integrated
• Search
• Handler

でFISH。なるほど。で、ここまで読んだ3千万人ぐらいの方のご想像どおり、記事を読みながらIBM OmniFind Yahoo! Edition（以下「OmniFind」と略）のダウンロードを開始する図書館退屈男。83MBもあるんですが。ダウンロードがとても重いのですが。

　FISHの検索を試してみる。検索窓は１つ。シンプル。検索結果は書影とタイトル、あとは書誌事項のサマリ。ヒットしたキーワードにはハイライトあり。タイトルをクリックすると書誌事項と件名、排架場所を表示。件名はLCSHかな。あとWorldCatへのリンクあり。
　著者、件名からは再検索用のリンクが張られている。なかなかよさげな作り。でも、OmniFindは言ってしまえばよくある検索エンジン。RESTなインターフェースは実装されているけれども、クローラーで検索対象となるWebページや文書ファイルを収集してデータベースにしてくれるだけ。どうやってOPAC上のデータをOmniFindに食わせているのか。

　公式ブログに導入の経緯や仕様の概略も書かれていた。決めセリフは

The OPAC has left the building.

　カコイイ！まるでOPAC2.0のようだ。このくらい大口を叩けばよかったのか。

　システムとしては、MARCをMySQLに放り込み、ISBNなどで各書誌データを単一のページとしてアクセスできるように加工。これでOmniFindがクロールできる。
　このままだと検索結果はGoogleのような普通の検索エンジンと同じになってしまう。でも書影を出したりしたい。ということでインターフェースにはDrupalを使用。OmniFindはバックエンドのデータベースとして動作し、おそらくAPIを使ってATOMで結果をOmniFindに返させてDrupl側で整形、出力しているのだろう（想像）。賢い。

FISH will be released as a Drupal module in the not too distant future.

と書かれていたので、期待したい。

　ダウンロードが終わったので、とりあえずいつものFedoraCore4でインストール。コマンドラインから実行すると「グラフィカルモードで実行しろ。さもなければオプションを付けろ。」と言われるものの、その通りにしても途中でプロセスが落ちてる。
　FAQを読む。

When installing on Linux without a GUI, remotely for example via SSH, the user may encounter the following message:

   "The installer is unable to run in graphical mode.  Try running the installer with the -console or -silent flag."

However, console mode and silent install are actually not supported right now.  Instead you should install while inside a complete graphical desktop environment either on the server or remotely via VNC.

だそうだ。not supportedってなんだよそれ。もっとも対応OSは以下の通り。Linuxはディストリビューションも読んでいるのか。

• 32-bit Red Hat Enterprise Linux Version 4, Update 3
• 32-bit SUSE Linux Enterprise 10
• 32-bit Windows XP SP2
• 32-bit Windows 2003 Server SP1

　あいにく他の空きマシンはWindowsXPのノート（Pentium Mとちょっと非力）しかない。2万ドキュメントの処理に必要なスペック

• 1 Processor at 1.5GHz
• 1GB of RAM
• 80GB of Disk Space

を満たしていないけれどもまあいいや。2万件も処理しないし。しかしこの判断は甘かった。

　さて、クロールさせるデータを用意しよう。ここはやはりOPACにはOPACで対抗。こんなこともあろうかと、以前「トラックバック可能なOPAC」でMovableTypeに一書誌一エントリで出力したデータがあるではないか。これを使おう。FISHでも、WordPressを使用したOPAC、WOPAC(検索例)を参考にしたとあった。同じようなことを考えている図書館員はどこにでもいるようだ。

　OmniFindを起動。OmniFind自体にWebサーバが内蔵されているため、セットアップ時にサービスに使用するポート番号を聞かれる。とりあえず80で。
　その他、インストールやセットアップのスクリーンショットはMoonGift オープンソースのエントリ「IBM OmniFind Yahoo! Edition レビュー」を参考にされたい。

　クロール範囲には正規表現が使えるようだ。http://www.affrc.go.jp/blog/newbook/*.html を対象に指定し、新着図書情報をblogに出力した約4000件のデータを使う。

　あまり時間もかからずインデックス作成終了。検索速度も悪くない。
　ついでにMovableType側の表示テンプレートやNet::Mobaletypeに送り込むスクリプトも調整。タイトルにアイコンをつけていたのだが、これが検索結果表示時に"<img src=..."とタイトルより先にHTMLのコードが表示されてしまうのでこれを改修。

　金曜日はここまでにして帰宅。あとは土曜日朝にスクリプトが動き出し、新規データを追加するのを待つのみ。

　土曜の朝。OmniFindから応答が返らなくなっていた。職場に戻らないと状況が分からないが、新規データの追加時にOmniFindが落ちたようだ。

　ということで今日はここまで。週末の気分が一気に萎えたことは言うまでもない。
　設定画面などあれこれは次回以降にご紹介を予定。

　XooNIps library module v.1.0がリリース、ということで成果報告会に出席。

　バージョンアップされた点は、

• MODS対応スキーマを前提としてCiNiiへの対応を考慮
  JuNii、JuNii2にほぼ対応
• EXCELファイルからのデータ一括登録に対応
• 幅広いコンテンツに対応できるよう、アイテムタイプを変更、新設
  同時に入力項目も見直し
  アイテムタイプは以下の通り
  • Article (旧 Bulltin)
  • Book (旧 Rarebook)
  • Photo
  • Website(新設)
  • Video(新設)
  • Sound(新設)
  • Data(新設)
• MODS形式での出力をサポート

　など。スキーマをMODSにしたのは、通常の目録入力作業の一環としてメタデータの入力も考えており、元々はMARC21で入力しているため作業者の理解が容易、またタグも英語で分かりやすい、DCより表現力がある、目録との互換性の確保、などが理由。実運用を考えたら、確かに慣れているデータの入力手法のほうがよいのかも。
　ただし、最初からMODSでデータ入力をするのではなく、アイテムタイプごとに必要な情報を入力し、出力時にMODSを使用するとのこと。

　帰ったら早速XooNIps XSAS版をインストールして試してわくわく…と思ってよく話を聞いたら、まだJuNii2対応の部分がfixされていないので、テストは待って欲しいとのこと。なので試験はちょっとお預け。

　そのほか、独自の試みとして、検索エンジンをMySQLではなくGoogle MiniやGoogle Custom Search(Google Co-op)を利用した事例が紹介された。XooNIpsでもPDFファイルの全文検索はサポートしているが、機関リポジトリのように大量のファイルとページ数が相手となると検索速度が低下するため、Google Mini等を試用しているという。管理画面も見せていただいたが、検索インターフェースはかなりカスタマイズ可能。検索結果は基本的にはXMLで出力され、これをXSLTで変換して表示しているため、Googleライクにもそうでない結果表示にもできる。カスタマイズの自由度はGoogle Miniの方が高いとのこと。

　また、今後の展開としては、SFX/Metalibとの連携の計画が上げられた。
　まずは、SFXのナレッジベースに慶應のリポジトリKoaraの掲載誌名等を一括でアップロード、Metalibの検索結果からこのSFX経由でKoaraの誘導させる（フェーズ１）、またMetalibはOAI-PMHを話せるので、Koaraからメタデータをハーベストした上で、Koara側でOpenURL対応を行い、SFX/MetalibのFull Textターゲットとして誘導させる（フェーズ２）、などが計画されている。

　弊社でもSFXを導入しているので、このあたりも興味深い。
　この界隈の動向は、「機関リポジトリをどうやって構築するか」から「どこからアクセスしてもらうか」「どうやって収載論文の可視性を上げるか」にシフトしているようだ。弊社としては、「周回遅れ」にならないよう、先端の動向を収集しつつ最適解にトライ、というところか。

　説明会の後は例によって懇親会。夏に顔見知りになった方々を含め情報交換。
　うちでも早くリポジトリのプロトタイプぐらいは作りたいのですが。

　帰宅の途上、時間があったのでヨドバシAKIBA店へ。いつもより店外に人が多い。そういえば入り口付近に「何かを待っている」風情の人が着々と増えていた。ぼーっと電光掲示板を見る人、携帯をいじる人、何かしらPDAで入力している人。一様に「俺は待ってるぜ」なオーラが見える。

　そうだ、11日はPS3の発売日だ！ 某ニュースサイトの記事は、ネタではなく本当だったんだ！　外は冷えるし炊き出しとかあったらどうしようといらぬ心配をしてしまったが、とりあえずは地下駐車場に収容されて並んでいる模様。そうか、それなら冷えないね。並んでいたら買えたかも。（←無理）

　その後、ニュースで「購入希望者数千人、アキバに集結」の報道も。数千、というのはサバ読みとの情報もあったが、新宿では、午後11時に「完売」の報も。恐るべしPS3。

　実現したい機能は多々ありますが、まず基本から。

　今日は勇気を出してソースも載せて見ました。先達の方々には笑止千万かもしれませんが、ご助言などいただければ幸いです。 　

　まず、今回RSS化を試みた図書館の新着図書案内ページでの新着図書の記載は、HTMLでは以下のように記述されている。

<img alt="New" src="/opac-image/new.gif" align="right" />
<td></td><a href="(詳細情報、排架場所表示のURL)">書名 / 著者

　これを以下のCustomFeed-Config用YAML設定ファイルで

• 詳細情報、排架場所表示のURL : link要素へ
• 書名 / 著者 : title要素へ
• - 出版地 : 出版社, 発行年 -(シリーズ名) : decsription要素へ

  と３つに切り分ける。

# /usr/local/share/Plagger/assets/plugins/CustomFeed-Config/lib.yaml
# 
author: toshokan taikutsu otoko
match: http://opac\.lib\.prikuma\.ac\.jp/opac-new/book/new.html
extract: <img alt="New" src="/opac-image/new.gif" align="right" /><td>
　　　　　</td><a href="(.*?)">(.*?)</a>.*?<br />
extract_capture: link title body
extract_after_hook: $data->{link} = "http://opac\.lib\.prikuma\.ac\.jp" . $data->{link}

　match:で記述されている http://opac.lib.prikuma.ac.jp/opac-new/book/new.html が実際に新着情報が掲載されているURLで、extract: でこの内容を正規表現で切り出している。(.*?)が順に、extract_capture: で指定したlink, title, bodyの順に格納される。
　さらに、ここでのURLの記述にはサーバ名が含まれていないため、extract_after_hook: で $data->{link} に補記している。extract_after_hook: ではperl互換の文字列操作が可能であるため、文字列の追加・削除・置換等も可能である。
　このファイルは CustomFeed-Config から参照できるよう、assetsディレクトリの下、plugins/CustomFeed-Config あたりで保存する。

　次は実際にサーバにアクセスしデータを取得、RSSに変換する命令を記述した config.yaml である。
　plagger -c config.yaml として実行すると、

1. module: Subscription::Config : 指定したURLのファイルを取得
2. module: CustomFeed::Config : 先のlib.yamlに従い、必要なデータを取得
3. module: SmartFeed : feedのタイトル設定
4. module: Publish::Feed : RSS出力

　の順に処理が行われ、/var/www/html/kuma.xml として保存される。
　もちろん、Publish::Gmailなどを利用すればメールでの送信も可能である。

#
# config.yaml
#
global:
  assets_path: /usr/local/share/Plagger/assets
  timezone: Asia/Tokyo
  log:
    level: debug

plugins:
  - module: Subscription::Config
    config:
      feed:
        - http://opac.lib.prikuma.ac.jp/opac-new/book/new.html

  - module: CustomFeed::Config

  - module: Filter::Rule
    rule:
      module: Deduped

  - module: SmartFeed
    rule:
      module: Fresh
      mtime:
        path: /tmp/foo.tmp
        autoupdate: 1
    config:
      title: Pri-Kuma Library New Books

#  - module: Filter::EntryFullText

  - module: Publish::Feed
    config:
      dir: /var/www/html/
      format: RSS
      filename: kuma.xml

　Filter::EntryFullText ではデータ中のリンク先のファイルを取得してくれるのだが、これが通常のテキストに変換されとdescription要素に収められる。できれば <content:encoded> を使ってHTMLのままCDATAとして入れ込み詳細な情報を配信したいところではあるが、「新着を知らせる」用途であれば  Filter::EntryFullText でファイルを取得しなくてもこのページのURLを併せて配信しているので十分であろう。詳細な書誌情報をも配信、となるとこのデータが必要となる。別途プラグインとして切り出す手段を考えるべきだろうか。

　国内の図書館システムベンダは星の数ほどあるわけではなく、それなりの数にまとまっている。当然、システムが同一であれば（特別にカスタマイズをしていない限り）検索その他のインターフェースも同一であるため、この例であれば lib.xml を新着情報を出力可能な図書館システムの数だけ作成すれば、とりあえず新着情報をRSSで提供するサービスが可能となるだろう。今回の例も、実はいくつかの図書館で共通のフォーマットが使われている。

　ここで Plagger を利用したのは、出力についてRSSだけでなく電子メール等での送信などをサポートできること、また今回は一つのみであったが複数のFeed（学部図書館や分野毎に新着情報を出力している館もある）をまとめるなど、利用者のニーズに合わせて柔軟に対応可能な入出力機能を有している点にある。また、各図書館システムに特有の出力形態にあわせて個別に設定ファイルを作成すれば、RSSフィード作成など残りの作業はPlagger本体とそのモジュール群に任せることができ、開発にかかる労力も低減されると思われる。
　
　あとは「図書館の新着情報を（時にパーソナライズして）RSS等で配信」というサービススタイルがどこまで支持を集めるか、というところだろう。

　これがNature, Science, Cell等といった学術雑誌であれば、すでに各出版社から配信されているRSSフィードを一本にして取得、（是非はともかく）Plaggerを使い著者名等でフィルタしたり自館で利用しているSFXなどのリンクリゾルバへのリンクを加え、論文の全文アクセスや所在情報検索、複写依頼等へのリンクへとサービスを連携させてゆくこともできるだろう。

　なんとか実装したいなあ。

　８月の大図研大会のあたりから話題に出ていた、

今ある図書館の新着案内からRSSを生成するスクリプトを考えている。これらをゲリラ的に提供した後で、「便利だ」ということを広め、そして必要性を訴えるのでよいのでは。

　について、ゲリラ的な戦術が適切かどうかはともかく、ツールの汎用化に向けた自分なりのアプローチとして、Plaggerを使えないかと考えるだけでとどまっていたが、ようやく手を付けてみた。
　Plaggerは、Perlモジュール群からなるツールで、

HTMLやRSSを何かしら切ったり張ったり加工して、gmailへの送信やRSSその他様々な形式で出力するツール

　と言える。「人力検索はてな」の最近の質問、「Plaggerって何ですか？」 に事例や上手な回答が出ているのでご参照ください。

　これで普通の図書館Webサイトで提供されている新着情報をRSSに変えてしまおうと言う目論見。既存のツールはありがたく使おう。
　さらにid:toshi123さんのはてなダイアリー「Muibrog」のエントリ「いまさら聞けない？ 初心者向けPlagger設定覚え書き その1」が後押ししてくれた。感謝です。とても参考になりました。

　処理の流れは以下の通り。

1. 新着情報ページ上の書名、リンクなどを抽出
2. リンク先の詳細情報を取得、HTMLタグ削除
3. これらの情報を一件1itemのRSSとして出力

　まずは某図書館の新着図書案内ページのソースを解析。テーブルタグを使い、書名等はセルで区切られて入力されている。そこで、「いまさら聞けない？ 初心者向けPlagger設定覚え書き その2」で紹介されていた CustomFeed::Config を使い、正規表現を駆使して書名、リンク先などを抽出するyamlを記述。
　
　次に本体となる config.yaml で以下の処理を行うよう設定。

1. 指定したURLのファイルを取得、先の設定の通りフィルタして書名等を抽出
2. 重複データを削除
3. リンク先のファイルを取得(この場合資料の詳細表示)
4. 取得したファイルからHTMLタグを除去
5. RSS2.0でファイルに出力

　そして実行。　plagger -c ./config.yaml

　…おお、ちゃんとRSS2.0で出力してくれた。すごいぞPlagger。
　当座の問題点は、

• RSSフィード自体のtitle、linkを設定できない
• 取得した資料の詳細表示が、単にHTMLタグを削っただけで見難いので、整形して出力したい

　というところ。とりあえずPlaggerでいけそうなことが分かったので、この線で進みたい。
実際のyamlファイルは…もうちょっと心が落ち着いたら公開します。今しばらくお待ちを。願わくば、腕に覚えのあるシステムライブラリアン各位の協力を仰ぎたいところ。

　後半に入った自称「On the road 2006 "Road to the OPAC2.0"」。好評だったのかどうなのか、図書館総合展での公演のほか、追加公演が決定しました。11月末に名古屋です。詳細は追って広報されると思います。

　MS IGLOOとかサラリーマンNEOとかに気をとられているうちに、気がつくと前回のエントリから一ヶ月も経過。遅筆をご容赦ください。「サラリーマンNEO」で検索してこのサイトにこられた方、ここは図書館システムのネタが多く更新も遅いブログですが、こんな世界もあるのだと思ってソーシャルブックマークやRSSリーダに登録などしていただければ幸いです。

　で、セミナーなどで会う人ごとに「新ネタまだですか」とプレッシャーをかけられご要望を頂き、雑用に追われているうちに梅雨に入ってネタが腐りそうなので一部ですが出すことにしました。なので Preview Release1。別サーバ上に実装予定なので下記のリンクは変更を予定しています。

　とりあえず、以下のリンクをお試しください。認証が必要ですが、必要な情報は認証ダイアログに表示されるほか別エントリに書いておきましたのでそちらをどうぞ。

• ISSN 1
• ISSN 2
• ISBN 1
• ISBN 2
• 書誌ID(当館システムで付与している独自ID)

　いずれも、RSS1.0+MODSで書誌情報を出力。スクリーン用スタイルシートは準備中。なので生XMLでの出力ですがご容赦を。情報は十分あるので、ユーザの方でお好きに粋に表示画面を設計できる仕様です、というと何かフレンドリー。リッチなユーザ体験をあなたに。

　基本書式はシンプルに。

BASEURL/(ISSN|ISBN|書誌ID)

　mod_rewriteでISSN/ISBN/書誌IDを識別し、適切なqueryに変換しOPACサーバに送出しています。別サーバからURLをリダイレクトしているため、変換後のURLが見えてしまい今一なのでこれは次のリリースで改良予定。　

　デフォルトでは無駄にゴージャスに RSS1.0+MODS での出力ですが、RSS2.0やOpenSearch準拠での出力にもパラメータを指定して対応可能。
　また、ISSN等と同様にキーワードをURLに仕込んで検索可能な仕様にもなっていますが、「日本」とか「農業」のようなヒット件数の多い単語で検索すると切れそうなぐらい返事が遅いので、このあたりの詳細仕様をチューニング中。詳細は次リリースで。

　７月以降、東日本を中心に４箇所でライブツアーを敢行(講演とも言う)するので、ちょっとずつでも機能を増やしてネタとして使います。ご期待ください。というか感想やご意見などありましたらコメントなどお寄せください。

今夜も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対応も役に立ちそう。・・・やってみるか。今年度中に。まだ年度初めだけど。