図書館退屈男

迫撃！twitter！

twitterをはじめて半年ぐらいが経過しました。

なんとなく思いつきで、そう本当に思いつきで上司とか「twitterってなに？」という人向けのマニュアルを作ってみようと思い、

日本で3番目ぐらいにわかりやすいtwitterのおはなし
(リンク先が誤っていたので修正しました)

をつくり、7月2日(木)00:04にtwitterで「資料つくりました」とつぶやいて見ました。
驚愕したのがその後の経過。

• 00:07 発言が最初にRT(ReTweet：引用して再投稿)される
• 00:11 「わかりやすい資料ありがとうございます」とおそらく最初のダウンロードと感想をいただく
• 00:20 通りすがりの方からコメントをいただく
• 00:25 最初にRTしていただいた方からコメントをいただく
• 00:32 さらにRT

ということで、わずか数分の間に次々と引用され、資料がダウンロードされてゆきました。
その数。朝8時の時点で約300と推測(ResearchMapのアクセスカウンタによる)。疾風怒濤。このように、発言がリアルタイムに広がってゆくことも資料には書き加えました。

その後、コメントいただいた箇所の修正や、PDF版の作成などしたりしていましたが、本日午後のダウンロード数はおおよそ＋200と見ています。また、followしていただいた方も新たに16人。

情報が瞬く間に広がる、というのはtwitterの特徴として聞きかじりで知ってはいましたが、自分が体験するとは思っても見ませんでした。おそらく、知らない場所でも引用されているのかもしれません。
特徴としては、一度にバースト的に情報が広がりますがある点からその広がりが収束してゆくように思います。詳しいログが取得できておらず、この点を解析できなかったのが残念です。

twitter。甘く見ていましたが、なかなかイケル奴のようです。

---

「情報管理」7月号(52(4), 2009.7)「この本！おすすめします」に寄稿した書評、「その情報サービスは仮想？　実体？」。PDFでダウンロード可能になりました。掲載していただいた編集ご担当各位には心から御礼申し上げます。
最初は手堅く「戦闘妖精・雪風」あたりにしようかとも考えておりましたが、オチを書かないと人間と機械の関係については触れられないので、「魂の駆動体」にしたところです。

以前のエントリ、「レゴで図書館を作ってみた」でご紹介した図書館もしっかり写っています。そこで。実はこの図書館のパンフレット、というものも存在します。（Microsoft Publisherでそれらしくでっち上げました。当然自作です。）
PDFでおいておきますので、よろしければお持ち帰りください。印刷後は、三つ折にしていただくとパンフレットの出来上がりです。

• Library Information, Branch of Bayside, B.F.T. Public Library (0.5M)
• Library Information, Branch of Bayside, B.F.T. Public Library (2.2M, 高画質版)
• 街全体の案内図もあります。Guide of the BRICK FAN TOWN (0.7M)

PSPがDNSを引かなくなる件について

今日は「セカンダリDNSは伊達じゃない」話。

画質に惹かれて新型PSPを発売日に買いました。初代のPSP-1000も家にはあるのですが、画質が！明るい！きれい！なので満足です。しかも軽い！薄い！ でも作りは初代のほうがきれいかなあ。

まずはPlayStation Storeにサインアップ。「まいにちいっしょ」を早速ダウンロード。目当ては今までPS3(持ってない)でしか配信されていなかった「トロ･ステーション」！
ああ、これでトロとクロの掛け合いが視られるよ。なんて心なごむコンテンツだろう。

いそいそとシステムソフトウェアをver5.0、そして5.01にアップデート。Skypeもあるので電話もできるよ（チャットはない）。すごいぜPSP。

そして週末。「トロ･ステーション」は毎日更新なので欠かさずダウンロード…あれ、エラーだって。

接続エラーが発生しました。
(805F0005)

それなに。何のエラーなの。エラーコードだけじゃ障害の切り分けもできないよ。
無線LANのアクセスポイントには接続できているものの、サインアップで失敗した模様。同一設定のPSP-1000も接続できず。個体の問題ではなさそう。そもそもパケットはサーバに届いているのかいないのか。

DHCPサーバというかルータのログを確認。IPアドレスは正常に割り当てられている。
”805F0005”でgoogleに聞いてみても、いまひとつ。

再度ネットワーク設定をやりおしてみた。IPアドレスもDNSサーバも取得できているのに、接続に失敗。
またアップデートでもあったのか。ネットワークアップデートを試行。

サーバとの接続に失敗しました。
DNSエラーです。
(80410410)

ええええええ。DNSサーバはルータのアドレスになっているのに…なぜホスト名を引けない。
今度はインターネットブラウザにIPアドレス直打ちでgoogleに接続。これはうまくいった。http://www.google.com/ はエラー。なら悪いのはDNSだ。でもなぜ。

ルータにtelnetでログイン。これだからヤマハ製ルータはやめられない。DHCPの設定には特段DNSの設定はない。WAN側にプロバイダからDHCPでIPアドレスが割り当てられた時のDNSを使っている模様。ならプロバイダ側のDNSサーバを使うのみ。
ちょこちょことコマンドを叩く。コマンドが良くわからないけどとりあえず show ? だ。hackhackhack。…プロバイダのDNSサーバ判明。これだ。

今度はPSPのネットワーク設定で、手動でIPアドレスを割り当て、プライマリDNSはルータに、セカンダリDNSにWAN側DNSサーバを設定。

どうだろう…おお、接続できた！
2日分の「トロ･ステーション」をダウンロード。いやされた～。

さて原因はなんでだろう。うちのルータが悪いのか。応答が遅いのか。でも無線で接続している他の2つのPCは正常に接続できているので、何かPSPの無線LAN設定にはコツがあるのだろうか。

その後。プライマリDNSでも接続できることがある。なんでか不安定。SONYに言っても、「それは相性」とかで片付けられそうな気がするので、とりあえずこれで放置しよう。

---

その他のPSPの使途。

LocationFree LF-PK1で撮り貯めた番組とかDVD視聴。UMD VideoのMS Iglooその他動画を見たり、MACROSS ACE FRONTIER(ゲームはこれと「どこでもいっしょ」「talkman」しかない。)でINFORMATION HIGHをBGMにYF-21を駆ってみたり。やっぱPlusだよね。FはまだDVD2巻と最終話しか見てない。

---

来月の予告。

11月13日（木）～14日（金）のINFOPRO2008でリンクリゾルバネタで発表します。出番は14日のA会場、14：00-15：25のセッションA2です。

図書館総合展にも行きます。自社ブースのほか、11月27日（木）第6会場10:30-12:00のフォーラム、「もうOPACなんていらない!? －Google時代の文献検索と目録サービス－（仮題）」でNIIの高野先生とパネラーです。緊張です。
28日(金)は第2回ARGカフェでライトニングトークです。いつものマシンガントークを5～10分できれいに収められるかが見所だと思います。

さよなら、MitakeSearch。そしてAlpha。

　某日。日本HPの弊社担当SEがやってきた。

　弊社のシステムのいくつかは、旧DEC→旧COMPAQからの流れでHPのサーバなど各種プロダクトを利用している。MitakeSearchもその一つで、「検索システム農林一号」（旧、検索エンジン農林一号（仮称））など何気なく全文検索エンジンとして稼働中である。

　用件は以下の通り。当方で導入しているMitakeSearchのうち保守対象製品について、

• 2007年2月28日に製品の販売を終了する。
• 不具合対応など有償保守については2008年8月31日を持って終了する。
  （詳細は日本HPのサイトでどうぞ）

と文書で通知された。直接後継となる製品はなく、今後は各種DBMSに付属する全文検索機能で対応する、とのこと。以後も使う分にはサポートがないだけで大丈夫だそうだが、ちょっとさみしい。

　発売当初は「純国産全文検索エンジン」としてAlphaチップの力を遺憾なく発揮できる、と言う触れ込みであったような覚えもあるが、そのAlphaシステムも2006年9月30日で製品販売終了、オプション製品販売完了も2007年9月30日と間近い。
　開発の経緯はこのあたりから。

日本語全文検索ソフトウェア開発計画はDEC社（現HP）が開発した検索ソフトウェアであるAltaVistaの発表がきっかけとなっており、 AltaVistaが「高いところからの眺め」という意味であることから、日本語全文検索ソフト開発プロジェクトは開発部隊のあるコンパック多摩事業所の近くの御岳山より名前を借り、Mitakeプロジェクトと呼ばれました。そのプロジェクト名がそのまま製品名MitakeSearchとなっています。

　ということで、昔荻窪に研修に通っていた身としては懐かしい。

　思い起こせば、文献検索システムの試験用としてDEC3000/600を導入、試験の後はMTからのデータロード用として数年前まで稼動(ホスト名はtom。相方はAlphaStationのjery。)していたが、いまは日当たりのよい部屋で余生を過ごしている。ていうか誰もVMSを触れない。（研修は受けたけど忘れました。すみません。そういえばMultiaもWindowsNT3.51のクライアントとして使っていた。）

　最初の公式WebサーバはAlphaServer2100。OSはDEC OSF/1(後のDigitalUNIX)。この上でapacheもNNTPサーバもanonymous FTPも動かしていたから恐ろしい。ネットニュース用には別のマシンが用意されていたのだが、クラッシュしたためこちらに運用を切り替えた。担当SEからは、「DEC以外で組織トップドメインのニュースサーバにAlphaを使っているのはここだけ」とも言われた。確かに、何かしらインストールしようとするとconfigureで大抵こけて苦労した覚えが。

　ホスト名はsary。相方に文献検索サーバのtitiがあり、打合せ等では「saryがdiskfullです。」とか「titiが落ちました。復旧作業中。」など心和む会話が飛び交った。今はそういう愛のある名前付けは流行らないのだろうか。rms1とか無味乾燥なホスト名はちょっとつまらない。saryの名はさながら伝統のように別サーバに引き継がれ、今は3代目のマシンのCNAMEになっている。

Connotea Code

今夜も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は出力されないじゃないか。超初心者なミス。

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

救出

　３月の夜、ハードディスクの異音とPCが沈黙した。昨日の夜、土浦の町にメモリとディスクを追っていた。そして、masterではなくslaveのディスクが死んでいた。明日の朝、新品未開封の120GBハードディスクが、玄箱の中でDebianと唸りを上げる。K'sデンキつくばセンター店はつくばに残されたパンドラの箱。質と量を問わなきゃ何でもある。

　明後日、そんな先の事はわからない。（続く）

---

必要なユーザIDとパスワード。それは toshokan と taikutu 。

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もＯＫ。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な原稿がようやっと校正も終わり、４月１日から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なんてたわごとを言い出し始めてしまった私。これからどうしましょう。

お風呂でPSPでTV

　LocationFree LF-PK1の導入により無線LAN環境下での音声及び映像視聴環境を強化しつつある当家において、新規デバイスの投入によりさらなる利便性の向上が図られた。

　それはパイオニア製携帯電話ハンズフリー対応お風呂用ポータブルスピーカーHAPPY AQUA PHONE。防沫設計された本体に携帯電話やポータブルプレーヤーを収め、音楽再生や携帯電話の自動着信、通話が行なえる。防水ではないので当然ながらバスタブには沈められない。これでお風呂やプール付マンションのプールサイドでも安心して連れ合いが耽溺して現世に帰ってこれなくなっているミュージカル「エリザベート」とやら「プラネテス」を堪能できることだろう。

　名前は携帯電話での使用を連想させる（Webページの写真でも携帯が中に見える）が、http://www.pioneer.co.jp/happystyle/phone/spec.htmlの図をご覧頂くとわかるとおり、携帯フォルダの部分にはPSPがぴったり入る。まるで計算されたようだ。ちょうど窓の部分にPSPのディスプレイが当るので、映像を見るにはちょうどよい。

　ただし、本体標準のステレオミニプラグにPSPを接続すると、コネクタ部分が内部のアンプ部と干渉しPSPの位置が斜めになり不安定な状態となる。こちらでは、0.5mの延長用ケーブルを使用し、図の上部（フロントケース上側）のスペースまでケーブルを引き、こちら側でPSPと接続することで安定した状態を確保している。また、本体内にPSPを収納するとPSPの操作は行えない。チャンネル等の設定は事前に行う必要がある。
　なお、収納可能な機器のサイズは 167(W) x 210(H) x 26(D) mmとされている。これは本体裏側での収納を考慮しての数値であろう。内部にACアダプタ等はない。

　ということでお風呂に持ち込んで視聴。これでGUNDAM0083でのデラーズフリートの勇姿オリンピックでの日本勢の活躍も優雅でリラックスした環境で見られること請け合いだ。くつろぎ感３倍にアップ。なお、本来の使い方と異なり、本体を横置きにするので不安定ではある。そこは各自の創意工夫で乗り切ってほしい。

　大きさであるが、割と大きい。面積はB5サイズ、厚さはこぶし大。
　購入はヨドバシAKIBA。8,190円(税込)。ただのステレオスピーカと箱のくせに高いように思えるが、それはきっと気のせいだ。

　パイオニアのWebサイトからはこの商品にたどり着けないので、廃盤品なのかもしれない。（未確認）　スピーカのみの製品はあるが、窓付きのものはない。
　なお、"HAPPY AQUA PHONE"でGoogleに聞くといくつかのサイトでの販売が確認された。まだ在庫はあるようだ。（FAQでは「雑貨店を中心に販売しております。電器店では販売しておりません。」とあるのにヨドバシに店頭在庫があるところから何かを察する。）

---

　「DVDBox入手」と後輩に語ったところ、「それはオタですよ。危険ですよ。」と諭された。なんでも今週の「こち亀」でそういうセリフがあったとのこと。

　自宅に戻って確認すると、「DVDBoxを買うととまらなくなりますから」じゃないか。なんか違うぞ。引用は正確に。まあDVDBoxを買ったことには違いないが。0083。5.1ch再アフレコ版。ここには5.1chの再生環境はないが。

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。

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

LocationFree LF-PK1 + RDZ-D90 + PSP

後輩から「更新がない」（忙しいのとネタが少ないからだ）「内容が硬い」（もうちょっと勉強しろ）といわれ放題のこのblog。その後輩のような写真や絵文字しかないblog（面白いから許す）とは一線を画しているつもり。URLは晒さないでおきましょう。

ということで、今回は仕事以外のネタでお楽しみください。

• VAIO MSX2で頻発する録画エラー。ケロロ軍曹は一期一会。
• CATVの契約をデジタルに変更したばかりに、VAIOも含めたアナログ機器で録画できない地上波デジタル放送の数々。
• 買ったはいいけどソフトが「どこでもいっしょ」しかないPSP。だからといってnintendoDSを買うほどではない。
• 実はIEEE802.11bしか対応していなかった（要は最大11Mb）無線LAN。

を何とかすべく、週末は宇都宮に午後３時から繰り出し、

• LocationFree LF-PK1
• スゴ録 RDZ-D90

などを買い出して来ました。

宇都宮市内で餃子を食してから夜半に帰宅。即開封即セットアップ。

• どうもCATV側で周波数変調をしているらしく、ハイビジョンでも通常画質でしか録画できないみたい。（未確認）
• LF-PK1から伸びるリモコンケーブルは受信ではなくて操作する機器類への発信用。どう引き回そう。
• どうして連れ合いのPCは802.11gで接続できるのに自分のThinkPadは802.11b接続なんだ。

など、調整が必要な微細な設定は残るものの、概ね環境構築は完了。

早速PSPから接続。

• ちょっと絵は荒い。
  元の画質と動き（当然ながら動きの激しい映像だと粗くなる）依存か。
  DVDも問題なく視聴可能。
• ときどき音が飛ぶ。というか止まる。エンコードが間に合っていないのか。

使えそうなのでとりあえず出張に持っていった。例によってTX秋葉原駅ホームから接続。クリアに流れ出す"MONEY"。RDZ-D90にセットした浜田省吾ON THE ROAD "FILMS"は問題なく再生された。エンドロールの文字も何とか読める。これさえあれば、出張中(いや自宅でも)でもネットワークさえあれば、

• スタバで省吾
• ベットでドンペリニヨンで省吾
• 地下鉄の階段で省吾
• 路地裏で省吾
• 仕事場で省吾（それはちょっとまずい）
• 電車で省吾(早くTX全編成に無線LANを)
• バスで省吾(PHS用意しなきゃ)
• 国際線機内で省吾（機上からストリーミングする猛者がいるのだから不可能はない）
• プール付のマンションで省吾（要防水カバーだがな）

素晴らしい時代の到来だ。

あまり関係がないが文中の「省吾」を「王立宇宙軍」に置き換えても問題ないだろう。あの熱いセリフがどこでも聞けるというものだ。俺は一人でも十分立派に使いこなすぜ。秒読み戻せ。ブロードバンド万歳。

で、意気揚々と帰宅。連れ合いが月末に出張するというので、当然のようにこの組み合わせを勧めたが、彼女のノートPCはDVDPlayer標準装備（ThinkPad X41 Tabletにはそんなものはない。オプションだ）。リモートで視聴？わざわざ？ハア？な感じ。

なんだよブルジョアめ。「リモートで」「わざわざ」見るのが男のロマンなのだよ。

…ひっそり使いこなそう。