図書館退屈男

　19日になった。

　一次情報を提供するサーバと共に、負荷分散を図るためミラーサイトが有志の手で次々と立ち上がった。

　共同通信が配信している死亡者リストは「自由に利用してかまわない」とのアナウンスがあり、Niftyserve上の地震情報エリアへのアクセスは無償となった。

　被害情報サマリにも家族の安否や具体的な被害の情報、ライフラインの状況などを中心に順次情報が追加され、別の有志の手でHTML化されこれらも各サーバでのミラーの対象となり各所へ配布された。

　朝日新聞でも、「Internetで情報が提供されている」と掲載され、トラフィックは増える一方となり、NTTではミラー用のtarballの提供を始めた。また、それを理化学研究所がミラーする、という体制になる。
　翌20日には、NTTへの負荷を下げるため、

すでにwww.ntt.jpはindex-j.htmlにおけるミラーサイト一覧の提示と
ミラーサイトへのanonFTPによる源データ供給に徹した方がよい

との提案がなされた。
　しかしwww.ntt.jpへのアクセスは増加し、ミラーリングについては

Sun, 22 Jan 1995 13:54:03

  先週の17日から20日まで www.ntt.jp には地震情報はもちろん、通常提供しているその他の情報に対するアクセスも急激に増加し、日本国内向けにwww.ntt.jpが接続されている回線(64Kbps)は、昼間はほとんど真っ黒という状況が続いていました。

  現在(日曜日)は比較的スムースな状況ですが、 anonymous ftp で www.ntt.jp に対して地震情報のmirrorを実施している各サイトでは、是非 NTTではなく、理化学研究所に対して mirror するようにして下さい。

と理化学研究所の利用を促すアナウンスがなされた。
そして、

Sun, 22 Jan 1995 15:22:12

各サーバを
1. １次情報を発信している サーバ群
2. 1. のカテゴリのサーバをミラーしているサーバ
3. これらのサーバのインデックスを作成しているサーバ
に整理しては。

との提案と同時にIIJが加わることで、

Sun, 22 Jan 1995 15:25:45

IIJ、anonymous ftpでミラー用データ公開、以下のアナウンス発出。

  www.ntt.jpの地震情報を mirrorする方へ 

  anonymous ftp で www.ntt.jp に対して地震情報のmirrorを実施している各
サイトでは、NTTからではなく以下のサイトを利用して下さい。

商用 Internet 方面
  ftp://ftp.iij.ad.jp/pub/QUAKE/
研究用 Internet 方面
  ftp://ftp.riken.go.jp/QUAKE/ntt/mirror/

と、www.ntt.jpをマスターとして、経路別にミラー用サーバが用意された。

以下、19日の主な経過を示す。

Thu, 19 Jan 1995 02:19:36

http://www.med.kyushu-u.ac.jpが負荷分散のため

http://itcw3.aist-nara.ac.jp/earthquake/ の下のいくつかのファイル、
http://www.ntt.jp/QUAKE/ntt-j.html の下のいくつかのファイル、
[email protected] へのメールの結果、
http://www.mmjp.or.jp/mmjp/ の下のいくつかのファイル
http://www.cfi.waseda.ac.jp/users/g2b178/index-j.html、
http://athena3.cent.saitama-u.ac.jp/spool/ の下のメール群

をミラーして提供。

Thu, 19 Jan 1995 09:32:02

http://www.phys.s.u-tokyo.ac.jp/index-j.html
にも、地震関連サーバへのリンクのまとめ。

Thu, 19 Jan 95 09:45:12

1/18 PM 7:30にniftyserve上で共同通信が配信している死亡者リストが無償公開になったとの情報。

Thu, 19 Jan 1995 12:34:07

Nifty の地震情報エリアは、基本接続料金含めてすべて無料になりました。
との情報。

Thu, 19 Jan 1995 14:24:46

「NTT が提供している日本文字放送からの情報は自由に使用してくださって結構です」とアナウンス。各所でミラー可能に。

Thu, 19 Jan 1995 16:22:18

現地からの情報として神戸市外国語大学のページが紹介された。
http://www.kobe-cufs.ac.jp/kobe-city/whatsnew/disaster.html
「独自取材の情報がいっぱいある」とのこと。

Thu, 19 Jan 1995 17:20:48

NTT の地震のデータのミラー用に、anonymous ftp で /QUAKE/quake.tar.gz が公開される。

Thu, 19 Jan 1995 20:17:45

www.iij.ad.jp で地震情報のページが公開。NTTのミラーを含む。

Thu, 19 Jan 1995 20:18:39

東洋エンジニアリングでもNTTのミラー公開
英語  : http://www.toyo-eng.co.jp/NewHome/QUAKE/index.html
日本語: http://www.toyo-eng.co.jp/NewHome/QUAKE/index-j.html

Thu, 19 Jan 1995 22:22:35

東洋エンジニアリングで被害情報サマリのHTML公開

Thu, 19 Jan 1995 23:10:57

中部大でもミラー開始。

Thu, 19 Jan 1995 23:32:26

理化学研究所、毎時４０分に

     ftp://www.ntt.jp/QUAKE  を
     ftp://ftpriken.go.jp:/pub/QUAKE/ntt　 以下に

ミラーする設定

　当時、NTTより発信されていた情報のスナップショットを以下に示す。なお、このファイルは当時www.ntt.jpの管理に携わっていたNTTの高田氏よりご寄贈頂いた。本文を持って謝辞としたい。

　被害情報サマリに掲載すべき情報は日々増加していった。ネットニュース上の記事だけでなく、ネットニュースに投稿できないサイトか ら電子メールでも情報を頂き、これらも追加していった。
　ありがたいことにHTML化は東洋エンジニアリングの方にしていただき、webにも載せられるようになった。
　また、サマリをプリントアウトし、インターネットに接続されていない地域や海外に送信し大変感謝された、との情報も頂いた。FAXまでは想定していなかった。

　正直、どのくらいの人があのサマリを必要としていたのか、どこまで配布されたのかはわからない。もしかすると、デマも混じっていたのかもしれない。
しかし、当時のネットニュースでは実名＠所属での投稿が普通のことであったし、信頼するほかなかった。

　図書館員の仕事は、媒体はともかく利用者が必要とする情報を集め、整理・分類、提供・保存すること。
　件のサマリを作り配布すること。それはまさにこのような状況下で図書館員が行うべき仕事であったのではないかと思う。たとえ藁のような情報でも、それを必要とする人がいるのならいくらでもかき集めてきて海に投げるだろう。それが図書館屋の矜持。

　残念なのは、当時は「保存」がこの中から抜けていたことだった。インターネットで生まれしものはインターネットの中に消えるのか。自分の手元にさえ、もうサマリは残っていない。

（注：このエントリ中のURLは、多くがアクセスできなくなっています。あらかじめご了承ください。）

　昔、infotalkというメーリングリストがあった。

　入社して1年目、上司から「勉強になるから入っておけ」といわれて緊張しながらエントリのメールを出した。
　ちょうど、MOSAICがL10N化されたり、DeleGateができた頃だったと思う。当時流れた記事は、ここで垣間見ることができる。話題が高度でついてゆけなかった。

　そして1995年1月17日。兵庫県淡路島北部を震源とする平成7年（1995年）兵庫県南部地震発生。(概要は神戸市消防局ページから引用)
　その日の夜、20:05に奈良先端大で http://shika.aist-nara.ac.jp/earthquake が立ち上がったほか、翌18日には神戸市広報課と神戸市外国語大の協力でWebサイトの情報が震災関連の情報に切り替わった。また、奈良先端大のサーバは負荷に耐え切れず、より強力なマシンでの情報提供に切り替えた。

　18日の動きは早かった。infotalkでアナウンスされた情報の概要を以下に示す。

Tue, 17 Jan 1995 23:37:02 +0900

niftyserveにお亡くなりになられた方の名簿があるとの情報。
共同通信が配信しているリストが有料ページに存在。

(この間に、有志の交渉により日本文字放送が配付している文字放送の死亡者名簿のインターネットでの再配付の許可が下り、サイトに掲載）

Wed, 18 Jan 1995 18:06:03

www.ntt.jp が大量のトラフィックで不調、[email protected] にmail を送ると，死亡者名簿が送り返されるようになる。

(この間に、www.ntt.jpやathena3.cent.saitama-u.ac.jpで地震情報が流れ始める)

Wed, 18 Jan 1995 19:09:24

fj.misc上の地震の被害に関する情報を地域ごとにまとめたものが公開される
（以後、一日数回更新される。以下、「被害情報サマリ」と標記）

Wed, 18 Jan 1995 19:25:10

NTT広報発表の「兵庫県南部地震による電話等への被害について」がインターネット経由でも配布。 <http://www.ntt.jp/QUAKE/ntt-j.html>

Wed, 18 Jan 1995 20:07:48

奈良先端大学院大学で地震情報を提供していたSHiKAが高負荷のため
URL  http://itcw3.aist-nara.ac.jp/earthquake に交代。(SHiKAは黒NeXTでNeXTSTEP3.0J)

Wed, 18 Jan 1995 20:17:10

地震関連情報リストが
http://www.csl.sony.co.jp/earthquake/index.html  (英語)
http://www.csl.sony.co.jp/earthquake/index.j.html
で提供開始。

Wec, 18 Jan 1995 20:23:23

朝日新聞社の協力で、亡くなられた方・行方の分からない方のお名前を朝日ネット内の掲示板 LIST で公開するとともに、

  (1) http://www.asahi-net.or.jp
  (2) http://www.mmjp.or.jp

で公開。

Wed, 18 Jan 1995 20:33:51

ニュースに流れた地震による被害状況報告の項目別まとめが
http://www.cfi.waseda.ac.jp/users/g2b178/index-j.html
で公開。

（日時はすべてinfotalkのアーカイブ上のメールのタイムスタンプです。実際とは異なる場合があります。）

　当時はまだWebはインターネットの主役足りえず、各所のサーバは「実験中」「試験中」として個人の裁量で情報の公開が行えた。また、infotalkに集う主なネットワーク管理者も、メールやその他で顔見知り、といういわば村社会に近いものだった。

　誰に強制されることもなく、各所で、それぞれができる方法で情報を集め、発信することに奔走した。そして被災地にとっては「命綱」となる神戸周辺やNTTなど主要なノードのネットワークトラフィックを軽減させるために、自然とWebサイトの情報のコピーは各所にミラーリングされ、分散管理されていった。まだP2Pなど夢だったインターネットの上で。

　弊社でも、17日に課長から特命が下った。「インターネットには震災に関する情報はないのか。できるだけ集めて、公開せよ。」と。
　当時の自分にできたこと。課に1台しかないX端末（他にGUIを持つマシンはMacintoshぐらいだった）上でmnewsを開き、ネットワークニュースに次々と流れてくる現地の、マスコミでは報道されないような地域レベルの被災情報を集め、サマリとして公開することだった。

　当時の係長には、「野次馬根性を満足させるだけだ」と揶揄された。それでも、情報を必要としている人々がいることを信じて作業を続けた。入社して2年目が終わろうとしている何の技術も、プログラミングの知識もない自分にできるのはウインドウ間のコピー＆ペースト、そしてそれをinfotalkやネットニュースに流すことだった。

　眼前にあるはIBM OmniFind Yahoo! Editionの再インストールができないWindowsXPマシン。どうしたものか。

　気を取り直して、公式Fourmにあった手法でFedoraCore4へのインストールを試みる。

　まずはセットアップファイルを -is:extract をつけて実行、構成されているファイルを展開。同梱されているJRE(J2SE Java Runtime Environment)ではなく、自前で入っているJREで java -cp setup.jar run として実行。エラーで落ちた。JREが古いのか。ver.1.5.0で試す。今度はインストールに無事成功。続いて setup.sh を実行して設定を開始…設定画面は表示されるものの、またエラーで落ちた。続いてver1.6で。これもエラーで落ちる。何が正しいのか分からない。javaの環境を作り直したほうがよさそうだ。

　仕方ない。今日は撤退を決める。Uninstall.sh を起動。これもエラーだ！
　当然のように再インストールもできない。アンインストールもできない。手詰まり。

　落ち着こう。Linuxだからレジストリなどという面倒なものはない。rootで作業していたのだが、/home/root にInstallShieldというフォルダ発見。これを削除。再インストールはできるようになった。

　そうか、それならWindowsXPの方も。再度探すと、C:\Program Files\Common Files\InstallShield\Universal に「IBM」フォルダが。これを削除すると、再インストールができるようになった。これでチェックしていたのか。盲点。

　OPAC構築再開。Linuxマシン側にSambaを立てWindowXPからマウント、ローカルファイルとしてDBを構築することにした。

　そして約1時間が経過。750page/min で鋭意クロール＆インデックス中。明日の朝には終わるかな。ディスク足りるかな。

　さて、OmniFindでOPACかな。データどうしよう。うちの図書システムのクライアントソフトからでもデータは落とせるけれども、数千～数万件規模のダウンロードは想定していないのでちょっと面倒。
　そういえば、現システム導入時のベンチマーク用にテキストに落としたCD-Rが…あった。これを拝借。

　OmniFindは検索に専念させ、詳細な結果表示はOPACに飛ばすので、書誌ID（これがないとOPACにリンクが張れない）、書誌名、責任表示、ISBNなど必要最小限の項目だけをHTMLにして個別のファイルに変換、これをクロールさせることに。
　件数にして約60万件。変換を始めて8時間。まだだ、まだ終わらんよ！ orz

　暇なのでクロールの基点となるindex.htmlを作成。60万ファイルへリンク。ファイルサイズは20MBを超えていた。で、ここからクロールを始めるようOmniFindで設定するのだが、どうもうまくいかない。フォルダをあけてみたら、COREファイルができていた。やっぱり無理があったか。小分けにindex.htmlを作ったほうがよさそうだ。

　なんだかOmniFind自体の動きが怪しくなってきた。エラーも出始めている。間違いはここから始まった。勢いでOmniFindの入っているフォルダごと削除してしまったのだ！

　「まあ、もう一度setupを起動すればOKOKOK。」と思っていたが、起動して出るのは「インストール済みだからSetup中止。」のメッセージ。regedit起動。レジストリから関連のありそうな値をザクザク削って再起動。でも同じ。それらしきファイルを検索しては削除。再起動。やっぱりインストールができない。どこになにが残っているのか。もうだめなのか。素直にアンインストーラで削除すべきだった。すごく反省。

　途方にくれつつ公式サイトのForumで同様の輩がいないか検索。そんな間抜けはいないようだが、FedoraCore4でのインストールについてのアイディアが。ファイルを展開して、JVMからsetup.jarを叩いてはどうか、とのこと。いいこともあるものだ。明日はこれで試そう。

　昨日に引き続き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が落ちたようだ。

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

松の内も過ぎてしまったのですが、新しい年になりました。

先週は仕事始め＋1日と半端だったせいか、いまひとつ休みな気分が抜けませんでしたが、明日から本格始動というところです。

当面は対外的な講演も原稿もないので、ネタの仕込など充電に勤めたいと思います。

では、今年もよろしくお願いします。