ウェブ・技術

Mendeleyが来た日。

  Mendeley。いわゆる文献管理ツール。去年の今頃はそう思っていた。ところが。それはとんでもなく違う認識だったとしたら。

  話は今年、2011年2月に遡る。Bloomington, IN で開催されたCode4lib ConferenceでのIan Mulvanyさんの発表、"Mendeley's API and University Libraries: Three Examples to Create Value"で語られたのは、「MendeleyからOAuthで認証してリポジトリにアクセス」「MendeleyのMy Libraryから自分の文献をSWORDでリポジトリに投入」というAPIをバリバリ使った実装例の紹介と、APIコンテスト - "Binary Battle"。賞金は $10001
「なにこれすごい」と気づき、実はひっそりと動向をチェイス。情報源はMyOpenArchiveでおなじみ、@keitabandoさんのブログなわけですが。いつもありがとうございます。@keitabandoさんはMendeleyのAdvisor(日本には7名)でもあります。すてき。

  そして来る Dr. Victor Henning, Co-Founder & CEO, Mendeley Ltd. 来日の報。折しもWIRED日本版にMendeleyの記事「知のシェア – 学術論文における理論と実践」の掲載。なんというタイミングの良さ。第2回 SPARC Japan セミナー2011「今時の文献管理ツール」ワークショップでの講演のほか、別途に懇談の機会をいただきました。この場をお借りして、機会をいただきました関係各位、特に@keitabandoさんに心からお礼申し上げます。 

ワークショップの模様はtogetterにまとめておきましたので、こちらをご覧ください

 (超イケメンの)Dr. Victor Henning との2日間に渡る会談で明らかになった事項はこんな感じ。

これまでと現状:

  • 2008年に3人の学生のアイディアとSkypeアカウントからMendeleyは始まった。今では195カ国3万の大学・研究機関で、140万人(うち有償アカウント数千)が1億4千万近い文献をアップロードするまでになった。論文の重複はできるだけ除去している(たまに同定に失敗して重複している場合もあるそうです)。
  • Fundingと有償ユーザからの収益はあるが、まだ黒字にはなっていない。
  • 競合他社との最大のアドバンテージは「無償」であること。
  • 実は専任のサポート担当は1名。ただし、staff全員が定期的にサポート業務を行っている。CEOも例外ではない。ユーザの気持ちを掴むことが重要。我々はcrowdサービス。サポートもまたcrowd。advisorと一体になってサポートを行っている。
  • 大事なのでは機能ではなく、使っていて楽しいかどうか。Mendeleyは若いResearcherにとって使って楽しいツールとなっている。情報共有を簡単にするのが目的。
  • TogoDocのように、学際的論文を見つける必要性は高くなっている。どのような分野の研究者が使っているかがポイントになる。自分ならまず心理学を検索し、文献を登録する。時間とともに、生物学の人もその論文を見ることもあるだろう。その時は、学際的領域として心理学が求められている、ということになる。容易に探し出せるよう、厳密なカテゴリ分けはあえてしない。

近日リリースの機能など:

  • QuickSend。Mendeley Desktopから文献をDrag and Dropでメール送信。
  • Mendeley Suggest。ユーザが文献につけたタグ、Annotationなどを利用して、ドキュメント同士のsemanticなリンク生成とレコメンドを行う。amazonライクな手法に加え、MeSHも使用。
  • 図書館向けプログラム。Swetsと提携し、2012年1月に発表する。図書館向けの機能として、自機関のユーザの文献の利用動向などを把握できるツールなどを用意する。

今後の展開:

  • これまで蓄積した情報をもとに、iTunesのように論文をMendeley経由で購入するビジネスモデルを検討している。出版社からのメタデータや本文提供のオファーもあり、交渉を進めている。PubMedからは全文アーカイブの許諾は出ている。
  • 論文提供では PaperC DeepDyve と(Google Trendで)比較しても Mendeley の伸びは明らか。レコメンド用に、オープンソースのOCRを導入した。これでPDFの全文解析も行う予定。
  • 名寄せの問題。Mendeleyでも解決はしていないが、ResearcherIDORCIDとの連携により対応したい。

ということで、図書館向けプログラムの存在、また「論文をMendeley経由で購入」という新たな学術情報入手のアプローチが明らかになりました。確かに、文献の書誌情報をSNS上で共有したとしても、「入手ができない」というのはストレスになるはず。そこに出版社も目を向け、協同を働きかけているという事実。同じように、Springerが買収したCiteULikeはDeepDyveと連携しています。

90の座席がほぼ満席のワークショップでは、MendeleyのほかEndNote、RefWorksといった既存の製品のほか、生命科学者のための文献管理トータルソリューションツールのフリーソフトウェア、TogoDocの紹介もありました。こちらはPubMedと連携し生命科学分野に特化しており、登録済みの論文の「全文から」PubMedを検索し文献をレコメンドする機能付き。協調フィルタリングではなく、論文の中身から推薦する文献を検索とのこと。用語の違いはMeSHを使って吸収、正規化。これには Dr. Victor Henning も大いに興味を示したようで、ワークショップの席上でMendeleyのAPIを使ってのレコメンドの強化など、製作者の岩崎さん(東京大学)とのコラボレーションの提案がありました。「開発担当とコンタクトできるよう準備する」など、動きの早さがさすがです。

対するEndNoteとRefWorks。EndNote(文献管理)はWeb of Science(検索と関連文献表示)とResearcherID(成果公開と研究者間での共有)の役割分担と必要に応じたカスタムメイドな文献リストの作成サービス、きめ細かいユーザサポートをアピール。
RefWorksはAPIによるCMS(Moodleの対応実績あり)をインターフェースとした時間サービスとの統合やDspaceなど機関リポジトリとの連携、また大学などではアカウントを失わないよう卒業生プログラムを提供する、などのサービスがあるとのこと。
それぞれが求めるサービスから来る機能や性格の違いが把握できるワークショップとなりました。

そして今日の懇談というか会談。Researchmapでの名寄せ問題のほか、CiNiiとの連携はどうすれば。
以下、自分のデータベースとMendeleyとの連携方法。

  • RIS、BibTex、EndNote XML、Zotero SQLファイルからのインポート。
  • COinS(ContextObjects in Spans, OpenURL(Z39.88-2004)をspanタグを使ってHTML中に記述する手法)で書誌情報を書くとBookmarkletを利用したWeb Importerでインポートできる(CiNii対応済み)。
  • 上によらないボタンクリックでのデータ転送はAPIを使うか応相談。

そうか、COinSに対応しているなら、弊社のシステムはこんなこともあろうかとあちこちで実装済みだから…おお、インポートできた!すごいぞ図書館退屈男。でもWebページ扱いでインポートしている…だめだこれ、不具合報告を送らないと…ああ、仕事が増えた…。

Mendeley。文献管理ツールからこれまでにない論文入手とコラボレーションツールへの進化の到来と、Web2.0でうたわれた「リッチなユーザ体験」を本当の意味で体現して築いた新たな世界。彼らは本当に学術情報の世界に革命を起こせるのか。「図書館向けパッケージ」の実力如何。やはりエッジの利いたサービスは「※但しイケメンに限る」しか作り得ないのか(それ関係ない)。

会談しながら検索して気づきました。Code4Lib Conferenceで発表したIanさん、もとはNatureでConnnoteaを開発していたのですね(スライドあり)。WIRED日本版によればヘッドハントされたそうです。過去に図書館退屈男もインストールに取り組みその秘密も明らかになりましたが、最近OSS版の開発が止まっていたのはそういうことだったのかと今更気づく始末で。


うわ、半年ぶりにblogを書きました。図書館総合展でも催促をいただいたのに。Twitterにかまけてないでもうちょっと記事を書くようにしないといけません。

とはいえ、今回の一連の懇談でかなりの刺激を受けました。こんなことができるなんて、という驚きと、自分の今後の仕事について。


Code4Lib JAPANへの誘い - デジタル情報の最前線に立つ覚悟はあるか

岡崎市立図書館の一件以来、司書のITへの対応力が問われている。

曰く、

  • 図書館の本業は蔵書の貸し出しであり管理、あるいは子どもへの本の読み聞かせ
  • システムに関する知識を個々の職員に求めるのは酷
  • 司書は文系が多いから仕方がない
  • 図書館では専門的な知識を有している人が乏しい

これらの発言に悪意は感じないし、仕方のないことだと思う。「本が好きだから」司書を目指し、職に就く者は多い。「ITがすきだから」「パソコンが好きだから」図書館で働く,という話は聞いたことがない。

しかし、図書館員はもうITの力なしでは業務はできない。カード式目録と膨大な冊子体の索引誌で文献を探す時代にはもう戻れない。書庫に眠る壁一面のChemical Abstracts(化学系文献の索引誌。年52冊+Index。1907-2009刊行)を繰る者はいない。我々はITがもたらした恩恵からは逃げられない。何より、利用者はそれを求めてはいない。図書館はもっと便利であれと言うだろう。

ならば立ってみようじゃないか。デジタル情報の最前線とやらに。そこに情報があり、利用者が欲するなら分類整理して提供するのが司書の仕事ではないのか。必要なツールがないのなら、自ら作ろうじゃないか。かつて様々な文献目録を編み、必要な書誌情報を一枚のカードに納めて見せたように。

何も一からプログラム言語を作り、基盤にチップを半田付けしてコンピュータを作れと言っているわけではない。インターネット上には自らの情報を好きなように見せ、共有できるさまざまなツールがある。まずは今そこにあるものを使おう。写真のアーカイブを公開したければFrickrがある。会議をライブ中継したければUSTREAMがある。自前でサーバを持たなくてもなんとかなる。

飽き足らなければサーバを用意して…余ったPCでかまわない…Wordpressを入れてblogを立ち上げる、Perlのモジュールを組み合わせて必要な情報を切り出すツールを作る。一台のサーバがあれば、どんなことでもできるような錯覚さえ覚えるだろう。

あとは誰に教えてもらうか、だ。新しいことを自分一人で続けるのはつらいことだ。他より先進的(と思われる)サービスを見つけ、立ち上げ、それを続けるのは孤独さえ感じる。こんな事をしているのは宇宙でたった一人だと。

今は違う。Code4Lib JAPANにそんな同志たちが結集する。一人じゃない。欧米より遅れているとか進んでいるとかじゃない。本家アメリカのcode4libと連携し、同じ夢を見て、ITで図書館サービスをよりよくするために肩を並べることができる。

図書館退屈男もアメリカの多くのsystem librarianの力を借りた。LibXを使いたいのでつたない英語で質問したら、快く答えてくれた。お礼に2.0の日本語表示を手伝った。統合検索用のインターフェースにxerxesを使いたくてメールを出したら、やはり親切にマルチバイトへの対応方法を教えてくれた。おかげでDatabase Quick Searchを立ち上げることができた。ソフトウェアに国境はない。仲間はどこにでもいる。

Code4Lib JAPAN Lift Off。デジタル情報の最前線へ。いよいよ8月28日(土)14時より品川にて開催。ご案内と参加申し込みは公式blogからどうぞ。

もちろんUSTREAMでも中継予定。アクセスは https://ustre.am/n2vL から。twitterハッシュタグは #c4ljp

品川から、手を携えて進まん。


MyOpenArchiveに目を見張った

https://www.myopenarchive.org/

オープン•アーカイブ•コンソーシアムは非営利組織の学術論文オープン化推進機構で、事務局を日本に置き、2007年夏に形成されました。
https://www.myopenarchive.org/blog/2007/09/open-archive-consortium.html

というサイトを発見。

  • 論文のアップロード
  • タグ付与
  • スターでの評価
  • トラックバック受付
  • 同著者の他の論文へのリンク
  • ブックマーク数の表示

などが主要な機能のようです。なるほど、登録された論文の「評価」もできますね。

興味津々でsignupしようとしたら「not invitation」と言われて。招待してもらわないとアカウントを作成できないようです。残念。

オープン•アーカイブ•コンソーシアムの中の方いわく、

通常、論文への「つっこみ」は、その研究者を取り巻く人のみで構成されていて、不特定多数によるコメントや評価付けってあまりない(最近は電子ジャーナル等が対応しつつあるが、やはり非常に限定的)。
ブログ慣れした人々なんかは特にこうした不特定多数により意見が反映される仕組みは皆必要性を感じてるだろう。そう、単なるオープンだけを追求するのではなく、共有し、そこからまた発展性を持たせる意味でのオープンさこそがこれから支持されていくと思う。
"[コラム] 論文サイトに対する皆の意見を聞いて"坂東慶太のブログ

ということで、ニーズとしても、

自分は学生でも学者でもないのですが論文を読んでいて、その論文に軽い気持ちで突っ込みたいって時はどうされているんでしょう?
「ここの図が間違っているよ」とか「この部分はユニークで好きだ」「ここは理解が難しい」とか。その論文を読んできた全ての人で共有されるようなものがあるのだろうか。
"論文に対するコメント" ひげぽん OSとか作っちゃうかMona-

や、

研究者として欲しい

  • 論文情報を簡単に手に入れられる(参考文献リストの作成を簡単にできる)
  • その論文がどこで手に入れられるかすぐにわかる
  • その論文の概要が読める
  • 参考文献、被参考文献間で自動的にリンクが張られている
  • 個人ビュー用として、勉強記録がつけられる(論文に対するメモは他人に知られたくないので)

"[発声練習] 学術文献を連接点とした学術情報のネットワーク". 発声練習

などの声が上がっています。

確かに、ゼミのレポートやちょっとしたデータを公開するのに適した場所、というのはないものです。いくらXooNIpsのように比較的敷居の低いアプリケーションがあっても、きちんと論文の蓄積と提供を、しかもそれを半永続的に運用するのはそれなりにコストがかかり、個人ベースでは難しい。かつ外部からのコメント付与などに対応したリポジトリシステムは聞いたこともなし。強いてあげれば、国立国会図書館デジタルアーカイブポータルが目録や雑誌記事索引の検索結果の一件一件にタグとコメントがつけられるぐらいでしょうか。近代デジタルライブラリーや青空文庫など、現物をアーカイブしているデータベースにも対応しているのでちょっと近いかも。

そこでオープンなアーカイブを用意する、というのはナイスな発想です。また、外から見ただけですがシステム自体もよくできていると思います。もうちょっと手を入れれば大規模なリポジトリにも対応できそうです。

個人的な希望を言えば、

などができるとよりgoodではないかと思います。

で、以下は参考になります。
図書館屋からみて「いまはこんな機能があるけど、今のシステムに加えてはどうだろうか。」という情報提供的な内容になってしまいました。
もうご存知の内容でしたら、失礼をお許しください。

「研究論文系ソーシャルブックマーク」としては、Nature Publishing Group が運営している Connotea などがありますが、こちらは論文自体のブックマークはできてもアーカイブまではサポートしていないので、ちょっと違うかもしれません。
ただ、機能としては、上記に加え

  • 登録は自由
  • 自分のwikiページを持てる
  • 内部に Community Page が作れる
  • ブックマークした内容は公開/非公開が選択できる
    「公開」の場合はログインなしでも閲覧可能→サンプル
  • RIS, EndNote, BibTeX, MODS, Word2007, Textで引用文献リストを出力可能
  • ユーザごとに公開されたブックマーク、タグの更新をRSS1.0で取得可能
    もれなくDublinCoreで出力も付きます。
  • (利用できるリンクリゾルバがあれば)設定可能
  • APIあり(要認証)(APIについての過去記事
  • コードはGNU GPLで公開(でも本物とはちょっと仕様が違うみたい)

などがあります。関連の記事にConnoteaについての言及がなかったようなので書いてみましたが、参考になるでしょうか。

大学の機関リポジトリでは論文の参照回数を執筆者にお知らせして好評を得ていると聞いています。そういう機能があったりするとうれしいですね。

あとは細かいところで言えば、

となると、すべての媒体(紙の論文、電子的な論文、本、記事、などなど)に一意に名前付けをしなければならないので厳しいかも。著者、署名、出版年月でたいてい一意になると思うけど。
"[メモ][研究] 論文感想共有の仕組み". 発声練習

については、商用ベースに乗っている論文にはDOIが、機関リポジトリ搭載の論文にはCNRI Handleがつけられていることが多いです。

いずれも、「外国のサービスに依存して、止まったらどうするんだ。国内でも同様のシステムを立ち上げるべきだ。」という意見もあるので、自分たちで作ってしまってもいいのかもしれません。それこそ維持が大変そうですが。

論文にこのような識別子を付与することで、アクセスの保障と一意の識別ができますが、この識別を代行し、論文本体へのリンクを提供してくれる機能がリンクリゾルバになります。OpenArchiveの場合は本文が配置されているURLでアクセスすることになるので不要かもしれませんが、外部からAPI経由で探しに来た場合にうまく対応してもらえるとうれしいです。

動作としては、とても概略すると以下のようになります。もうちょっと詳しい動作などは、増田豊, "OpenURLとSFX". カレントアウェアネス, 2002, No.274(CA1482)が参考になります。

  1. リンクリゾルバのURLにDOI、PubMed IDなどの一意のID、または論題、著者名、掲載誌など特定できる情報を投げる。(手法はOpenURL(ANSI/NISO Z39.88-2004)として標準化されています。)
  2. リンクリゾルバがCrossrefにDOIで照会し、論文の書誌事項を取得するほか、電子媒体のURLをユーザに表示。
  3. これを元に電子媒体にアクセス。
  4. 電子媒体がない場合は、ドキュメントデリバリサービスや他の図書館の目録検索へ誘導。この場合にも、取得した書誌情報を使用するので再入力は不要。

商用製品のリンクリゾルバとしてはEx LibrisのS.F.XOvid LinkSolverなどが多数ありますが、ソースが公開されているOpenResolverというリンクリゾルバもあります。(動作サンプルもあります。なお、ソースのあるftpサイトにはこの記事執筆時点ではtimeoutとなりアクセスできませんでした。)

長々と書いてしまいましたが、折角だれでもデータを溜め込める場所ができたのだから、そこも検索の対象としてお客様に提供できる情報を増やすことができれば、という図書館屋の思いが伝われば幸いです。

陰ながら応援しています。


サービスを終了させる、ということ。

 Webサーバのコアとなるシステムの3回目のリプレースが行われた。このシステムは1995年に稼動を開始し、当時はWeb、gopherからanonymous FTP、netnews、proxyサーバとして、またWeb/Telnetによる文献検索サービスなど多くのサービスを運用し、後のサービス拡大のためのテスト環境ともなっていた。1999年のリプレースからWebに特化したシステムとなり、2003年からはこれにRSSによる新着情報配信サービスなどを加え、現在に至っている。今回のリプレースでは、外部から利用可能なAPIとしてOpenSearch、OAI-PMHの実装とデータ提供環境が加わった。こちらは調整が予定より遅れており、来年には公開できるだろう。
 
 その一方で、前システムの運用終了を持って停止したサービスもある。「検索システム農林一号(旧名:サーチエンジン農林一号(仮称))」と「農林水産研究関係インターネット資源への道」の2つである。詳細はこれらのページに発表資料へのリンクがあるので、そちらを参照されたい。
 前者は農林水産研究関連のWebサイトに特化した検索エンジン、また後者はディレクトリサービスで、弊社が提供する農学分野におけるサブジェクトゲートウェイサービスの一翼を成すものであった。今回のリプレースでの継続運用も検討されたが、Googleなど他の検索エンジンとの競合、これらの運用やディレクトリ作成に必要な人的リソースの不足などから、やむなくサービスの停止に至った。

 「サーチエンジン農林一号(仮称)」は、自分がWebの主担当係であった時にテスト環境の構築から運用までを手がけたサービスでもあり、またおそらく弊社のコンテンツの中で唯一Yahoo! Japanでcoolマークを付与されたもので、個人的な思い入れもあったが、状況を考えると停止もやむなしと思う。
 他のサービスとの差別化に失敗した、という面もある。Vivisimoで実装されている検索結果の自動クラスタリングや、流行のファセット検索なども持たない旧態依然の検索エンジンでは、「農林水産研究に特化した検索エンジン」というコンテンツだけでの差別化には限界があったのかもしれない。また、ロードマップ上には「検索結果として表示したWebページをクリックすると、次回はそのページを取得してデータベースに加える」自動成長型検索エンジンを「サーチエンジン農林二号(仮称)」としてロールアウトさせるプランも存在したが、諸般の事情でこれは実験のみで終わってしまった。そして、自分自身、今回リプレースとなったシステムの主担当ではなく、新規機能の提案をしたのみで設計と構築にはほとんど携わっていない。

 実験ではなく、公式に提供しているサービスを停止する、ということは現在の担当者にとって軽い選択ではなく、おそらく限られた開発期間や資源をどう配分するか、という中での苦渋の決断ではなかったかと思う。
 弊社のサービスはどんどん枝葉を生やし、拡大していった。図書館総合展などではスタッフの人数を問われ「よくこの人数でこれだけのサービスが」と言われることもある。正直その通りで、もう余裕はなくなりつつある。新しい手法をテストすることはできても、運用フェーズに持ち込むためには定常的なリソースを確保することが必要になる。それは周囲の協力や合意であったり、予算であったり、人であったりさまさまであるが、個人の力に頼らず、組織として、業務として運用しなくてはならない。特に人的リソースは減少している。時には枝葉を剪定して、全体のバランスを取ってゆくことも必要なのかもしれない。理想論かもしれないが。

 いくつかの個別のサービスを終わらせても、全体としてより有益なサービスを提供する。難しいが、正しい評価に基づき、続けるべきこと、止めるべきこと、そして新たに始めることを考える時期に来てしまった。個人的にも、トライしたいことは山のようにある。だが、どれだけのアイディアや試験したサービスを運用まで持ち込めるだろう。全部は不可能でも、何かに書き残しておけば、誰かがどこかで実現してくれるかもしれないとも思う。
 幸いにも、今回終了したサービスは発表の機会に恵まれた。得られた知見などを書き残せた、それだけでも有益だった、と取り合えずは考えることにしよう。前向きに。


 発表をさせていただきました11月17日(土)開催の整理技術研究グループ2007年11月月例研究会の記録資料(PDF, 3.4Mb)が公開されました。機会を与えていただきました関係各位に、この場をお借りしてお礼申し上げます。


MidNight Hack

 「[drf:50] OPACにJuNii+をマッシュアップ」という記事が流れた。

 宮崎大学で、先週からOPACの書誌詳細画面に「関連する学術成果」を表示するようにしたとのこと。サイトはここ。書誌詳細画面からタイトルやキーワードを抽出し、JavaScriptでjunii+をRS検索してXMLで返ってきたデータをパースし表示している。カコイイ。

 日曜日にネタをもって長崎講演の予定ではあるのですが、ネタがだんだんマンネリ化していている気がするこのごろ。

 ここで負けてはいけない。(誰に?)

 昔UNIX Userを読みながら作成した、OpenSearchのアグリゲータを引っ張り出し、クライアントとしてデモできるよう実装を開始。知らないうちにWWW::OpenSearchが0.12まで上がっていて、ATOM対応になった。ここで狙うのはOPACと農林水産研究文献解題とのマッシュアップ。この文献解題は、毎年一冊程度ではあるが、農林水産業に関する主要な技術的課題をとりあげてこれに関する研究文献を解題しその内容を紹介するほか、主要な関係文献について体系的に整理し解説を加えている。つまり農林水産研究に関するレファレンスブックといえよう。

 急ごしらえなので無理はできない。文献解題はHyper Estraierでインデックスを作成。OpenSearch対応APIを標準で備えているのがありがたい。

 OpenSearchでのアグリゲートを最終目標とし、今回はOPACの検索結果のうちタイトルから文献解題を引き、関連の情報が入手できるサービスを目指して実装を開始。
 WWW::OpenSearchをアップグレード……そして動かなくなった。

 例によってPerl使いの後輩に無理を言って解析を依頼する。いくつか改良点を指摘されたので、ぽちぽちと直して……とりあえずOPACは検索できるようになったが、ヒット件数の多い単語を入れると速度がガタ落ち。何とかしたいのだが次期システム待ちか。

 OPACの検索結果からHyper EstraierへOpenSearchを使ってタイトルを検索語として投げるようにしたのだが、こちらはうまく行かず。

 ああもう時間がない。まだ一日あるし、寝坊して飛行機に乗り遅れないよう、寝よう。 


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

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

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

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

引用元は

岡本 真. “「Web2.0」時代に対応する学術情報発信へ : 真のユーザー参加拡大のためのデータ開放の提案”.
情報管理. Vol. 49, No. 11, (2007), 632-643 .
https://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で提供中です.
例としては

https://opac1.cc.affrc.go.jp/alis/xmlout.csp?ISBN={isbn}&DB=T&format={RSS10|RSS20|R2MODS|MODS}
https://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=雑誌です.


図書館タグクラウド再び

 明日(もう今日だけど)は名古屋で追加公演講演。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を叩いてはどうか、とのこと。いいこともあるものだ。明日はこれで試そう。