図書館

公務と理想

 NIIのCSIワークショップでのARGの岡本さんの発言、「能力のある方(図書館員)が、公的な形で表にあらわれてこないのは、大学図書館界の損失」問題について、時機を逸した感もあるが実例をひとつ。こちらは専門図書館なので多少事情が異なることもありますが。(ワークショップの資料はNIIのサイトで公開中。)

 当所でも研究所のごとく「年報」を毎年出しており、この時期になると昨年度の統計データや取り組みについて取りまとめて提出している。ちなみに、研究所や試験場の年報類にはたいていの場合名簿と人事異動記録、業績リストが掲載されているので、人の動きや業績を追いかけるには便利なレファレンスツールのひとつである。当所の場合は、個人情報保護の観点から今年から名簿類は削除になりましたが。

 で、発表実績なども業績として提出するので、とりまとめて持っていったところ、「あー、これは公務としての業績だから、出張扱いの分しか載らないよ。」と上司に言われ確認したところ、昨年度の発表実績全8回のうち出張扱いとなった3回分しか載せられないことが判明(ほか5回は年休で出席)。庶務担当係長に聞いても「年休での発表は公務ではないので載りません。」とのこと。発表すること自体は事前に「所外公表届」を提出し、いつ、どこで、どんな発表をすることについて申し出ているのに、記録にはならないとは。まあ、休日に自主トレしましたと思えばこれは仕方がないのかもしれないが、そういう小さいところで実績が公にならないこともある。もっとも、医図協のヘルスサイエンス情報専門員の認定用には全て使わせていただいた。

 自分の開発スタイルとしては、HVUDayの「いわゆる「能力のある方が、公的な形で表にあらわれてこないのは、大学図書館界の損失」問題について考えてみたよ。」で言及されている、

 勤務時間中にうっとうしい環境下にいるからこそ、そこから開放された深夜や土日に密度の濃い集中したもの造りができる、ということだってある。 (略)  予算も支援も職務権限もないからこそ、ゼロから自分の好きなように構築していけるのが楽しくてたまらない、ていうことだってある。

に近い。その成果は課内のメーリングリストで「こんなんできました。」と報告するが、ちょっと他人に触ってもらう程度。出来と反応がよければ自分の「持ちネタ」としておき、すぐ実施できそうなものは課内で諮った上で施行、大規模なものは次のシステム更新や改修の際までにブラッシュアップして仕様書に載せて実装する。無論、入札案件となれば調達委員会等で仕様書の内容などが問われるので、事前事後には新たな技術によるサービスについて周囲に理解してもらい、その意義と導入効果を認められる必要がある。RSS関係のコア部分はそんな感じで開発し、タグクラウドとかアプリ系は自分や同僚とで実装したり。事務方の仕事の基本は、「次の瞬間に担当者が消え去っても後任者により業務が恙無く継続できること。」だと思っているので、サービスとして完成すべきものはできるだけオフィシャルな文書の形で残し継承を図る。人事異動だってある。

 そうした試みを雑誌に掲載していただき、読んだ方から「ゼヒ詳しいお話を」ということであちこちから呼んでいただいた。今年も引き続いてお声がけをいただいている。一方で、庶務係はじめなど出張伺いを処理する事務方は、「講演での出張」の取り扱いについて検討、協議し、結果として「受託出張でOK」「悪いけど年休でGO」などの結論が出、それに粛々と従う。仕事とはいえ、結構苦労をかけていると思う。以前は担当が替わると考え方も変わってしまい困惑したが、今年度からは受託出張関連の社内規定が改正され、たいていの場合は旅費等先方払い謝金なしの受託出張扱いで赴けるようになった。ちなみに、旅費は当社規定に準じて積算した金額を伝え、先方から頂戴する形になる。旅費等は級号俸で変動するので、現在の職務に応じて妥当な金額が支払われるよう処理される。別に図書館退屈男が強く訴えたわけでも組合が何かしたわけでもなく、単に改正になっただけ。もちろん、講演の際の手続きや先方とのやり取りなど、面倒な処理の労を厭わず正しく判断してもらえることが一番ありがたいことである。原稿依頼についてもほぼ同様であるが、勤務時間外での執筆が基本。業務上のもの(所発行のニュースなど)でない限り、原稿執筆を理由に超過勤務を命ぜられることはない。

 実際に予稿を書いたり発表が近づくと課内のチェックが入る。講演であれば予定時間内に終わるか実演したり、また予稿などは内容が先方の依頼内容に合致しているか、などのほか、所としての公式のサービスか個人的な実験の成果による見解かは明確に切り分けを求められる。これらをクリアして予稿の提出、また発表に望む。

 ということで、一見自由に見える当所でも「公的な形で表に出る」ためにはそれなりの手続きが必要になる。また、他の事務方のサポートがないとどうにもならない。誰も邪魔をしようとしているわけではない。規定を柔軟に解釈しなんとかしようと努力しても無理なときもある。

 「講演依頼?そりゃいいことだ行って宣伝して来い。」という反応だけではない。「それほどのものならば内部の利用者にも広報しろ。むしろそっちが優先ではないか。」と言われる事もある。昨年度は目立って出張回数が多かったので、本業を疎かにしているのではないかとの疑念をもたれても仕方がない。そして、主たる顧客である農林水産関係研究者への広報も忘れてはならない。図書館関係の研究会等での発表も、これに間接的には寄与していると思っているが、直接的なアピールも時には必要と考えている。これは自分への課題。また、受託出張の規定上、受託可能な団体として「職務に密接に関係した」などさまざまな条件が課せられている。

 正直な気持ちを言えば、講演でも原稿でも頼まれれば(かつ無理なスケジュールでなければ)何者に阻まれることなく先方の希望に沿った形でまとめたい。ただ、組織の中の人として公務で出張する限り、いやそうでなくても、組織名+本名での発表は内容についてこちらがどう思っていようと組織としての考え方として捉えられることもある。よって発言を自重せざるを得ないこともある。

 近くは8月末に長崎で発表を予定。予稿は提出済み。業務と講演など対外活動の両立。公式のサービスと個人的見解の切り分け。年々状況は厳しくなるような気がする。そんなことを考える梅雨の午後。


うぇぶ2.0の器量を伏して

 前回のエントリが業界内に静かな波紋を起こしたようで、軽くどきどきしています。先日も、ILLのご依頼を頂いた大学図書館の方から、返信のメールで「考えさせられた」とのコメントを頂きました。お読み頂きお礼申し上げると共に、この辺境のblogが一助になれば幸いです。同時に、「ああ、あちこちで読まれているので悪いことは書けない」と思う次第です。

 さて、今日は内部の図書館システム担当者向けセミナー(ILLのみ)講師、明日は専図協全国研究集会、来週8日(金)はNIIのCSIワークショップと講師が続く今日この頃です。感想などコメント頂ければうれしいです。

 そんな業務の合間を縫って、「国立国会図書館月報」なども読んでいます。「平成18年度書誌調整連絡会議を終えて」(2007.3, No.552, p.14-18. 報告については平成18年度書誌調整連絡会議記録集(PDF, 1037kb)が詳しい)を見ると、調査研究目的で提供されているNDLSHのテキストファイルが、XML化や検索システムの組み込みの検討などに利用されるいるようです。今後のNDLSHの提供方式の検討につなげていきたい、とのことですが、Webサービスなどでの提供を期待したいところです。
 デジタルアーカイブポータルについては、ダブリンコアに基づくDC-NDLを拡張したndldapを定義、データ提供元に対して最大限のメタデータ項目を含む仕様を提示するほか、相手機関の仕様を受け入れられるよう柔軟に対応したい、とのことです。Opensearchも話せるようなので、うちのデータも受け入れてくれるといいなあ、と思ってみたりします。申請書とかいるのでしょうか。

 また、書誌コントロールに関連したコメントとして、

また昨今、現在のOPACは時代遅れとして、Web2.0を意識したOPACの改善提案がなされたりしている。しかし、連想検索機能を持つWebcat Plusよりも従前のWebcatの方が使われているとのアンケート結果に見るように、OPACを改善したり、新しい機能を加えたりする方向はさほど支持されていないと言える。
(国立国会図書館月報, 同号. p.18)

(前略)OPACをアイディアだけで「改善」したり,新しい機能を加える方向は利用者にはさほど支持されていないと言える。
(平成18年度書誌調整連絡会議記録集 p.41)

 と高所からばっさり断言されてしまいました。Webcat PlusがWeb2.0を意識しているかどうかは別として、そうですか。Web2.0なOPACは微妙に支持されていませんか。アイディアだけですか。そんな気もしているのは確かですが。明日Web2.0なセッションで話さないといけないのですが。テンション落ち気味です。

 Webcat Plusの連想検索は決して嫌いではないのですが、完全一致で書誌を同定できるWebcatとは検索の方向性が違うので、同列に論じるのはどうか、とも思います。業務で所蔵を調べるなら迷わずWebcatですが、知らない分野の資料を探したい場合はWebcat Plusですねえ。連想検索自体は例えば新聞記事全文などそれなりのボリュームの文章を入れないと効果が発揮できないですし。ただ、その違いを利用者に理解してもらうことが難しいのかもしれません。検索語をどう投入して検索をかければ、期待されている結果が表示されるのか、直感的にわかるようにする必要があるのでしょう。これは他のシステムでも同様です。

 OPACの改善や新機能追加などについてはどうなのでしょう。図書館業務上の利用であれば現状のように特定の書誌を確実に同定できる機能さえあれば十分ですが、例えば一般の利用者や書棚をブラウジングするごとく検索したい、という機能を提供するのであれば連想検索やタグクラウドといった実装は効果があるのではないか、と考えます。
 また、WebAPIの実装により、例えばデジタルアーカイブポータルの横断検索のターゲットとしやすい機能を持たせておく、などは有効かと思います。
 いずれにしても、海外等で進んでいるWeb2.0/Library2.0な機能の実装について、利用者による評価は知りたいところです。

 それとも、APIの実装やレコメンドや関連資料、書影を表示、なんていうのはamazonとかの本屋さんに任せておき、OPACは時流に流されることなくもっと図書館業務寄りで安定したシステムとして作るべし、ということなのかもしれません。開発者的には楽しくなさそうですが。

 図書館退屈男心得の条。我がしすてむ我が資料我が物と思わず、目録検索の儀、あく迄陰にて、うぇぶ2.0の器量伏し、ご下命、いかにても果たすべし。尚、死して屍拾う者無し。死して屍拾う者無し。


 九州方面の方、お待たせしました。(別に待っていなかったらごめんなさい)
 8月後半に長崎での講演のオファーを頂いておりますので、よろしくお願いします。


電子図書館のその先は(2)

承前

 今までの「効率的に必要な情報が入手できる」環境整備は、結局自分たちの首を絞めていたのか。情報源と利用者の間に、図書館屋が介在する余地はまだあるのか。集団自殺にはまだ早い。

 図書館退屈男の主観に基づき、図書館での資料の電子化と提供手法の変化、利用者がアクセスするインターフェースの変化と提供主体の認知を表にしてみた.

Userif_2
 ちょっと極端かもしれないが、OPACの利用あたりまでは電子化資料の提供は「図書館のサービス」として認知されていたが、近年では機関リポジトリへのアクセスの多くがGoogle等の検索エンジン経由であること、またNIIが「CiNii に格納された国内主要学術論文約 300 万件の論文データを、Google による情報の取り込み(クロール)の対象」としたことなどを考慮すると、利用者から見ればこれらが「図書館のサービス」とは見えにくいのではないだろうか。

 そしてJSTはJournal@rchiveによって国内で発行された学術雑誌のうち重要度の高いものを選んで創刊号から電子化する事業を巨費を投入して推進している。もちろん、現在のJ-STAGEのようにGoogleでのクロール対象となるはずだ。

 もちろん、検索の「入り口」を増やし、自組織で蓄積した学術論文の無料アクセスの道を広げることに異論はない。研究者から歓迎する声も高い

 しかし、これらのサービスのレイヤの中で、「図書館」の位置が中間に様様なサービスが介入することで最上位に位置する利用者インターフェースから相対的に低下する可能性はある。利用者との距離が開いてゆく、ということだ。

 例えば、リンクリゾルバにしても、アイコン等で上手にブランディングを確保していないと、

「文献データベースを使ったら[S.F.X]というアイコンがあったのでクリックしてみた。」
                 ↓
「オンラインジャーナルやILL申し込みのリンクが出てきたよ。」
                 ↓
「おお、論文全文が読めたよ。便利だなあ。」

という一連の流れの中で、「図書館が用意したリンクリゾルバやオンラインジャーナルへアクセスしている」という認知はされにくいように思う。

 一方で、機関リポジトリ系のメーリングリスト、DRFでも、

(真のユーザは外部のサービスシステムから直接アイテムに来る)
([DRF 0539],  SUGITA Shigeki)

アメリカの図書館員は、いまだに図書館のホームペー ジをユーザ(アメリカ流ですとパトロンでしょうか?)が見にくると思っている わけなのですね。
(中略)
同じ観点から、北大さんが中心のAIRwayにしても、千葉が始めてしまった Scirus連携にしても、研究者・学生の自然な情報探究作業のなかで、機関リポ ジトリ搭載の研究成果がひっかかってくるようにする試みだと考えています。
([DRF 0540], Syun Tutiya)

という意見が見られる。

 もはや図書館屋の主戦場は、今までのような図書館という「館」や自館のWebサイトでの籠城戦でなく、城から脱しGoogleや大手出版社/アグリゲータを上手に利用して各地にそのサービスを広げて形成されるものになろうとしている。

 電子化された環境下で発信者が見えにくくなる中で、自館のブランドと利用者の距離、認知度をいかに保つか、そこが問われるのだろうか。
 それとも、情報探求作業の支援に特化し、OSI参照モデルのうち一般ユーザには直接見えずにサービスのバックグラウンドを成すアプリケーション層の一サービスに移行してゆくのか。
ネットワーク技術者が、黎明期に表舞台で全レイヤに介在していた時代から、Web2.0で言われる「利用者が参加する」インターネットに変化してゆく過程の中で、次第に自らの専門である低位レイヤに特化して行ったように。
 ならば、図書館屋はどのレイヤで戦えばいい?

 それができるのなら、たとえ来館利用者が0になっても図書館屋の仕事は、まだ、ある、のか。あると信じたいが、図書館退屈男の心の底には「館」を捨てることへの抵抗がまだある。それは図書館屋の性なのか。


電子図書館のその先は

 仕事で落ち込むことがあったりちょっとした決断をしたり。そして一ヶ月ぶりのエントリ。
 でもOPACのXML出力WebAPIの説明を補記したり。今度はちゃんと使えます。きっと。

 本社での会議から戻ってきた課長から耳打ちされた。

「…図書館の来館者増に繋がるような施策を検討してほしい。」

 データベースとかじゃない。「図書館の来館者」だ。聞けば、上から年間の来館者数が少ないと判断され、来館者を増やすか「図書館機能の見直しを図る(閲覧機能の停止、と行間に書いてありそうだ)」の2択。来館者増 or die。

 当館の年間来館者数は4桁前半。周辺の各研究所にも図書室はあり、他館への依頼も含めて自機関で用は足りる。当館に来るのは「ここにしかない資料」を直接閲覧するか、各種データベースの検索支援が必要なユーザがほとんど。

 今までの取り組みを振り返る。

「全国どんな場所にいても、同じ環境で研究ができること。」
- Anytime, anywhere, anyhow, Collaborative Research Environment

 それを目標につくばから北は北海道の紋別から南は石垣島の山の向こうまで、全国に順次ネットワークを張り巡らした。
 10年かけて各研究所共用の図書館システムの導入と図書館業務の共通化、遡及入力による書誌データの整備、研修を行い、システム面でも人的資源の面でも向上を図ってきた。また、ネットワーク経由で文献複写も依頼でき、ILLは目に見えて高速化された。
 各種商用データベースも、MTでの購入と汎用機上での毎週の構築作業、従量課金からインターネット経由での商用サービスの定額利用に切り替え、そしてオンラインジャーナルの増加やSFXの導入により文献検索から原報入手までがほぼワンストップで行える環境が整った。
 それは全て研究者のため。

 そして現在。文献や必要な情報は研究室に居ながらにして入手できる。一方で、図書室の人影は目に見えて減った。「Google ScholarやPubMedがあるのに、本当に高価な商用データベースが必要なのか。」そんな声さえ聞こえる。

 ふと、「魂の駆動体」(神林長平、1995)を思い出した。「集中し続ける人間を詰め込むための現実空間が足りなくなったから、仮想の場へ人間存在をコンパクト化して送り込む」仮想空間、「HIタンク」。入ってしまえば仮想も現実も区別はつかないという不死の世界。今で言うSecondLifeのようなものか。ただし、HIタンクは片道切符。戻ってはこれない。そして描かれる主人公の「実体」への拘り。その拘りが、仲間と自ら設計し駆る「クルマ」の設計に没頭させる。90ページ(文庫版)近くに及ぶボディやサスペンション、エンジン設計を語り合い設計図に起こしてゆく描写には愛さえ感じられる。

 おかしいな。

 コンテンツサービスや既存の研究論文、ILLの手続きなど電子化が可能なものは、それが研究者を助けると信じてあらゆる手段で電子化を図ってきた。しまいには、OPACすらAPIの整備やWebブラウザ組み込みの検索ツールの実装により「OPACを提供するサーバ上の検索インターフェース以外でも」(HTTP的にはデータを"GET"しているので、「Webサイトを訪問」や「サーバ上で検索」という表現を使うのはあまり好きではないのですが)検索結果を得られるまでになった。RSSによるデータ配信に至っては、情報源となるサーバがデータをデスクトップに届けてくれる(ように見える。やっぱりGETメソッドだし。)。

 それらを手がけてきた自分が、なぜいまさら図書館という「館」や「物理空間」になぜ拘るのだろう。オンラインでの利用者さえ多ければ、それでよかったのではないのか。「電子図書館の構築」とは、究極的には全ての物理媒体を捨てて電子化し、ネットに完全に溶け込んだ図書館屋になることだったのか。そしてその仮想空間には、図書館屋は必要なのか。その中で何をサービスするのか。

 うまい答えが出せない。
 課長の宿題にも答えが出せそうにない。やはり自分は「実体」を軽視してきたのだろうか。

 「魂の駆動体」では、HIタンクの開発に関わった友人にこう語らせている。

HIプロジェクトは一種の集団自殺計画だ、そう思った。(文庫版 p.91)

 今までの「効率的に必要な情報が入手できる」環境整備は、結局自分たちの首を絞めていたのか。情報源と利用者の間に、図書館屋が介在する余地はまだあるのか。集団自殺にはまだ早い。


 明日は当所や周辺研究所の一般公開。当所はサイエンスカフェでお待ちしています。

 晴れるといいな。

[追記]

 「戦闘妖精・雪風」は(改)ではなく横山宏さんの表紙のほうがすき。OVA? メイヴちゃん? あれは自分の中ではジャムが作り出しだ幻影ということにになっています。


ちいさな図書館でできること

鳥取からつくば目指して移動中。

川蝉さんの「図書館員もどきのひとり言」のエントリ、「情報管理2007年2月号より」でこんな文章を発見。

最後のほうに林さんとこの農林水産研究センターがかなりWeb2.0を実現してて、小さいところができるから、大きいところもできるはずといったことがあるのけど、小さいからできた、という面はないんだろうか?あと、実現できる担当者がいたということと。いや、実現できる担当者がいること自体が、その組織の才覚か?
まぁ、NIIや国会にそんな担当者がいないわけもないか。

引用元は

岡本 真. “「Web2.0」時代に対応する学術情報発信へ : 真のユーザー参加拡大のためのデータ開放の提案”.
情報管理. Vol. 49, No. 11, (2007), 632-643 .
http://dx.doi.org/10.1241/johokanri.49.632

このように組織や職員の規模もはるかに小さい農林水産研究情報センターでさえ、ここまでのことが実現できている。当然、真っ先にデータを開放すべき組織として挙げた国立情報学研究所(NII)や科学技術振興機構(JST)、国立国会図書館(NDL)に技術や労力の面で実現できない理由はない。

から。

 はい、その通りだと思います。小さい組織だからこそ職員のアイディアと企画も通りやすく、こういったことも実現できているのでしょう。それが目録やデータベース担当でなく、レファレンス担当という別部署の職員による試作を通じた提案であっても。当然、周囲への説得と理解と協力は必要ですが、その範囲が小さい、ということで。
 もちろん、「NIIや国会にそんな担当者がいないわけ」ではなく、彼らが本気になればもっと気合の入った、隙のないシステムを見せてくれるでしょう。その片鱗はデジタルアーカイブポータルでも見られます。

 では、「総合目録」を名乗ってはいるものの、専門図書館の集まりゆえに蔵書(灰色文献多数です)がかなり偏っている所蔵目録のAPIを公開して書誌が自由に取得できることに何の意味があるのか、Myrmecoleonさんご指摘の通り「ほとんどがNACSIS-CATにも加盟してるはずなのに,そっちではほとんど引っ掛からない」のはどういうことか、ちゃんとデータを提供すればWebCATだけで検索できるぞ、一箇所のサイトで統合的に検索できたほうが便利、などと言われそうです。また、「どこからリンクをたどって行ったらよいか分からない」という意見も頂きました。
 それでも、(たびたび取り上げさせていただき申し訳ないのですが)Myrmecoleonさんの「蔵書マップ」のように、APIを利用して横断検索を実現していただいているサイトもあるわけです。

 狙っていたのはまさにこれなのです。

 Webサイトの構造はよく「書籍」のメタファで語られ、設計されます。「表紙」から入って「目次」をみて「本文」を読む。しかし、それは検索エンジンにより「本文」に直接アクセスができるようになり、利用者は必ずしも「表紙」からリンクをたどる必要がなくなりました。
 検索サービスも同様だと考えています。「xxxxとyyyyが同時に検索できるのはhogehogeサービスだけ!」ではなく、必ずしも入り口が一つのWebサイトのみである必要はないと思います。あちこちのWebサイトから自由にデータベースにアクセスできるようにし、データベースへの入り口を遍在化させるのです。
 そのために件の総合目録にXMLで書誌データを返すAPIを実装しました。これは詳細な書誌データの開放のみでなく、先の「蔵書マップ」のようにさまざまなインターフェースからアクセスができるようにするための布石です。

 たった一つのインターフェースを利用者に押し付けることなく、利用者にマッチしたユーザインターフェースを自由に選択でき、それでも納得いかなければ自分で作ることもできます。昔の汎用機に接続されたダム端末経由の検索のイメージではなく、「インターネットらしい」検索サービスを提供したい、と考えています。

ああ、もう新幹線の発車時刻が近づきました。このエントリはここまでで。


[追記]

やっとつくばに着いたので追記です.

件のAPIですが、サーバの調整の関係で解説ページとは異なるURLで提供中です.
例としては

http://opac1.cc.affrc.go.jp/alis/xmlout.csp?ISBN={isbn}&DB=T&format={RSS10|RSS20|R2MODS|MODS}
http://opac1.cc.affrc.go.jp/alis/xmlout.csp?ISSN={issn}&DB=Z&format={RSS10|RSS20|R2MODS|MODS}

のようにして、RSS(1.0, 2.0)、MODS、RSS2.0+MODSで出力できます.
パラメータDBは T=図書、Z=雑誌です.


名古屋行ってきました

行ってきました平成18年度第2回東海地区大学図書館協議会研修会(3/7) 。「台湾ラーメン」が大学生協内のローカルメニュー(と後輩に聞いた)でなく、名古屋ワイドなソウルフードであることが確認できた出張でした。

ARGの岡本さんの基調講演はWeb2.0の様々なイメージを類別して解説いただいたと共に図書館が抱えるデータの開放についての提案あり。これはディスカッションで大きな話題に。

附属図書館研究開発室の寺井さんの講演は興味を引きました。利用者の情報探索活動について認知科学の手法を用いて実験した結果についての講演で、結果としては、探索の目的が明確になっているグループが探索課程の中で情報源をバランスよく利用する者が多く、問題の捉え方自体が大きく変化してゆくこと、また検索キーワードも増加かつ変化しより深い情報ニーズが発生するとのこと。

レファレンスにおいては調査の課程で情報ニーズが変化すること、また探索対象が寄り明確になることが経験的には理解していたが、実証的な実験でこれが明らかできる、ということに驚きと新たな視点を発見。

で、自分の講演。
つかみに、myrmecoleon氏謹製の「所蔵館マップ」(Google  MAPとWebCAT Plusを組み合わせ、ISBNを入力するとGoogle MAPで所蔵館を表示するシステム。今日見たらNDLの「ゆにかねっと」が追加されていてびっくり。)を紹介。まず「Web2.0はハッタリじゃない。図書館員の手の届く技術だ。」ということを見ていただく。

そして、Web2.0そのものは岡本さんに説明していただいたので、さらに印象付けるためにhttp://www.ark-web.jp/blog/archives/2006/04/clip_web_20_1.htmlを紹介、これでもう「リッチなユーザ体験」「ハッキングが可能」と聞いたらあのネコが浮かぶ人多数。
 
その他、いつものようにRSSによる書誌情報出力、これから派生したタグクラウド、blogへの自動投稿などについてデモと講演。タグクラウドは注目を集めていたように感じましたが、実装というか「見せ方」が難しいなあと職場に戻ってから再考。難しいなあ。

ディスカッション。やはり岡本さんの「図書館の利用履歴をうまく利用すべき。」との提案には、「図書館員の倫理綱領(1980/6/4 日本図書館協会総会決議)」中の「図書館員は利用者の秘密を漏らさない。」との整合性について議論となった。単館における貸出傾向等の把握は当該地域の読書傾向をも明らかにする可能性もあることから、複数館のデータを収集した方がよりより活用ができるのではないか、などの建設的な提案もあったが、「利用者履歴は活用すべきでない」という意見が多くを占めている印象を受ける。

岡本さんからは「ISPでは当然ながら利用者情報を多数持ち、それらは厳重に管理されている。民間企業にできて図書館でできない理由はない。」との発言があったが、正にそう感じる。
当方でも、貸出情報や文献複写依頼の記録が図書館システム上に、また利用者情報は全システム分が一括して管理されている。当然のことながら、利用者情報を管理するサーバ(他のサーバもそうですが)はアクセスできるマシン、人間、ネットワーク経路など様々な面で何重にもガードしている。「個人を特定できる情報」を切り離して取り出せば、とも思うが、どんな雑誌/文献が多く読まれているかを研究室単位で識別でき、それが公開されると研究分野によっては大きな影響があるだろう。TPOを考えてデータマイニングをすべきか。

RSS関連では、取得したRSSフィードの再利用について著作権の観点から問題はないか、との質問があった。
現状では、例えばThe University of Chicago PressのようにRSS Terms and Conditions of Use にて

2. Individuals may use the RSS Service for personal, non-commercial purposes only. All others must obtain our express prior written consent.

と明記している出版社もあれば、特段の記載がないところもある。
朝日新聞社でも

asahi.comのRSSは、個人でのご利用を前提としています。次のようなウェブサイトでのRSSのご利用については、有料にさせていただく場合がございます。詳しくはお問い合わせフォームからお問い合わせください。
(1)企業・官公庁など法人のウェブサイトやイントラネットでの利用
(2)宣伝PR・広告などが掲載されているウェブサイトでの利用
(3)asahi.comのRSSを利用したサービスの提供
(4)その他、営利を目的とすると判断される利用

と記載がある。
これに対しては、「利用制限について特段明記されていない場合については自由に利用できる、またその様な理解をデファクトスタンダードとして広める必要があるのではないか」と回答し、岡本さんからも同様の意見を頂いた。少なくとも、RSSでは発信者側でどこまで情報を載せるか、タイトルだけなのか全文を含むのかをコントロールできるので、そういう理解で進んで行くのがよい、という意見もあった。
Webページがいつのまにか「リンクしたらご一報ください」がマナーになってしまっていたようにならないよう、RSSの活用による様々な可能性が生かされるような方向で考えてもらえれば、と思う。組織的にデータベースを再構築されて販売、というのは避けたいけど。
ディスカッションも盛り上がり、大変勉強になった研修会でした。
お話の機会を頂き、ありがとうございました。関係各位にお礼申し上げます。


後から、講演要旨の作成用に当日の録音をmp3で頂いた。自分の声を聞くのは好きではないのですが、「つかみ」の部分で10分を要していたことが判明。それできっちり10分時間オーバ。やはり次回からはオチ重視で望むべきか。


図書館タグクラウド再び

 明日(もう今日だけど)は名古屋で追加公演講演。in 名古屋大学附属図書館。未来の首都だ。発表用のスライドや配布資料一式は送付済み。そしてデモ用のネタを仕込む。

 2月は資料作成→提出→手直し→提出...の無限ループに陥りつつ会議資料を作成、今日(もう昨日だ)で会議は一段落。あとは出張3連コンボ。名古屋の後は秋田と鳥取。3週連続。いずれも県立図書館等に赴き、行政部局と連携した施策についてお話を伺う予定。

 ということで新ネタに苦しみ、図書館タグクラウド(高機能プロトタイプ)の本番環境への実装を試みる。(今気づいた。1年も放置していたんだ。)
 多方面での利用を考慮し、JSONでの出力機能も実装されていたのだが、JSONのブラウザ側でのハンドリング、特にAJAXでカコヨク決めたかったのだが自分のスペック不足もあり叶わず。追って実装予定、ということにさせてください。

 とりあえずお見せできるものはできましたので、明日の研修会に参加される各位のご参考となれば幸いです。でもきっと基調講演のほうが人気出るだろうなあ。(といってみるテスト。他意はないです。はい。)

[2007/03/09 追記]

タグクラウドの実装ですが、発表当日夜から課内で「ちょっと見にくい」「インターフェースにもうひと味必要」ということで公開を一旦止めています。


LibraryFindと戦ってみた

 2月は会議シーズン。中間評価や担当者会議やその他諸々で資料作成が続く。

 各地の図書担当者が参集する会議で機関リポジトリ構築計画の説明があるため、XooNIpsのLibrary Module用一括登録ツールを使ってデモデータのリポジトリ登録など、とりあえず見せられる形を整える。(報告するのは別の担当者。)

 で、「各所のXooNIpsから公開可能なデータをOAI-PMHで吸い上げる」計画であるため、メタデータの吸い上げと交換のフロントエンドになるシステムを検討。とりあえずEprints3.0をインストールしたものの、スキーマの変換で悩む。oai_dcでそのまま入れられないものかと。もうちょっと情報を集める必要がありそうだ。先行事例をご存知の方はご教示ください。

 そんな困ったときにカレントアウェアネス-Rから「オレゴン州立大学のLibraryFindプロジェクト進む」の報が。渡りに船か。敵か味方か。
 z39.50 target、OAI-PMHでハーベストしたメタデータ、オンラインジャーナルタイトル(serials solutions piped formatで書いてPHPでOpenURLを生成、DBに入れる)の横断検索が可能なようだ。OpenURLのリゾルバも登録できるので便利そう。

 ということでインストールだ。え、これRubyで書いてある。しかもRuby on the Ralisだ。gemって何ですか。cpanみたいなものですか。混乱しつつINSTALL.txtに従いセットアップ。動くかどうか不安に駆られてFedoraCore4→5にアップデート。データベースは手動でMySQLに作るのね。自動生成じゃないんだ。
 railsのバージョンが違う(1.6.6を使うそうだ)といっては怒られ、oai_dc.rbが見つからないと嘆かれ、Perlとは異なる世界に迷い込んだ自分に後悔。

 OAI-PMHのハーベスタは

/usr/lib/ruby/site_ruby/1.8/rubygems.rb:246:in `activate': can't activate activesupport (= 1.3.1), already activated activesupport-1.4.1] (Gem::Exception)

 と言われて動作しない。上位互換アリとかそういう親切設計ではないようだ。

 ハーベスタは華麗にスルーしてセットアップを切り上げる。そして ruby script/server。 起動。おお、動いた。リモートでオレゴン州立大のデータを検索に行っている。オレゴンから愛。

 日本語を入力してみた。スペルチェッカーが自動的に作動するのだが、当然エラーを吐く。その他マルチバイトには厳しいような予感がする。多言語化ってどうすれば。
 オンラインジャーナル検索ぐらいならできそうだ。SFXから出力できればだけど。日を改めて試そう。

 とはいえ、メタサーチの実装としてはいい感じだと思う。参考にしよう。


 IBM OmniFind Yahoo! Edition. もうちょっとマシなマシンを、ということで半分寝ていたExpress5800(Windows2000server, Xeon 1.5GHz x2)を叩き起こして実行。50万件のデータから「農業」で検索させて3000msぐらい。遅。数年前のワークステーションじゃこのくらいなのか。テストに使えるそこそこ速いマシンを確保したいなあ。

 Next-Lの方もコミットしないと。有志Welcomeです。


IBM OmniFind Yahoo! Editionを動かしてみた(3)

 眼前にあるは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 で鋭意クロール&インデックス中。明日の朝には終わるかな。ディスク足りるかな。


IBM OmniFind Yahoo! Editionを動かなくしてみた

 さて、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を叩いてはどうか、とのこと。いいこともあるものだ。明日はこれで試そう。