どこまで、どのようにアクセスしたらシステムがダウンするか。それは機能要件を定義したベンダなり仕様を策定した図書館側しか知り得ない。ページスクレイピングされることを前提とした設計などまずあり得ない。それならRSSでのデータ配信やOpenSearchなりSRUなりz39.50などの横断検索用プロトコルを実装してそっちを使ってもらう方が話は早い。アクセス回数とシステムへの負荷状態は把握出来るのだから、どこまでなら機械的なアクセスを許容出来るという閾値を可能な範囲で公開すべきではないのだろうか。(あまり詳細だとセキュリティ的な弱点を公開しているのと同じなので問題ですが。)事実、全国の図書館の蔵書検索サービスを提供しているカーリルでは、「サービス開始直後、いくつかの図書館システムにおいて速度低下などの影響があり、その都度該当図書館との調整を図りました。」という対応を行っている。今回の事件についてもその見解を発表している。カーリルのような大規模なサービスなら、その影響は大きく調整の必要もあろう。個人レベルの利用においても開発者と図書館は個別に調整を行わないといけないのか?事前に許可を得ないといけないのものなのか?本当に許可は出るの?事務量増えるよ?APIの利用に当たって事前申請で発行されたtokenの利用を義務づけるサービスもあるが、それは利用状況の把握などのためであり、規制を意味するものではない。「事前に館長宛に書面で許可申請を出せ」というのは利用を萎縮させる効果しかないのではないか。蔵書検索サービスを提供する、ということをもうちょっと掘り下げて考える時期に来たのかもしれない。amazonもbk1もなかったインターネットの黎明期には、本来の蔵書検索に加え「本の情報自体を検索する」ことにも利用されていたが、現在では予約機能なども含め立派な図書館サービスの一つになっている。カーリルなどの公共図書館のインフラを利用した大規模な検索サービスの出現、またこのAPIを利用し現在位置周辺の図書館の蔵書検索ができるiPhoneアプリ「ライブラリアン」まで現れた。これらのほとんどは、図書館ではなく利用者が自らのニーズを合わせて独自に作ったものである。このような状況を多くの図書館員は理解しているのだろうか。「システムのことはわからない」と逃げてはいないだろうか。OPACは図書館サービスを超えて社会的インフラの一つになろうとしている、そのためのニーズもある、そうは考えられないだろうか。これは理想論かもしれない。ニーズがあり新たなサービスが生まれているのもまた事実だ。「そんなのは国立国会図書館やお金のある大規模な図書館の仕事」といわれるかもしれない。現実には、厳しい財政状況の中でシステムにばかり予算は回せない。声を大にして言いたい。できることからでかまわない。図書館員が自分で先の「ライブラリアン」のような高度なアプリケーションを作る技能そのものは必要ないが、それが作れるデータを提供できるシステムを、社会へ向けたインフラを作ろうよ。図書館サービスが貸本屋でなく公共的インフラを構成するサービスを目指すなら、新着受入情報のRSS配信や横断検索への対応など、新たなニーズに対応したシステム構築が必要だ。ぶりに戻って参りました。精神的にも余裕が少なかったのですが、夏に入ってからは物事が進むようになりblogにも戻ってきました。この夏でこのblogも5年目になりました。4年前に発表した記事の内容はどんどん現実になり、なんだかうれしい反面、今の自分が新しい何かを生み出せないのがちょっと寂しいです。Off"と題した記念式典でちょっとしゃべります。今回の事件に触れるかどうかはさておき、新しい流れを生み出すお手伝いができればいいなと思います。詳しいご案内とお申し込みは公式blogからどうぞ。成り立ちについてまとめてみました。(0)図書館サービスもSaaSですってよ、奥さん!ムフフ。Service)による図書館サービスの提供が、NEC発で行われている、との報がありました。以下はNECのプレスリリースからの抜粋です。エル)サービス」の4種をメニュー化しており、ニーズに応じて順次メニューを拡充していきます。この「GPRIME」自体は、「官民の情報システム連携、ワンストップサービスの促進など「地域情報プラットフォーム」をサポートし、経営という視点で資産や人材を活用する積極的な戦略を可能」とするソリューションで、そのサービスのひとつとして図書館サービスもある、というところでしょうか。総務省から出されている各種の資料を見る限りでは、「図書館の図書貸出予約のオンライン化」は住民からの要望もあり、オンライン利用の促進対象手続ともなっています。電子化やオンライン化のメリットが目に付きやすい、という点もあるのでしょう。システムをSaaSで、とは書かれていない。OPACも連携対象として絵に描かれているだけかもしれない。「(2)複数の図書館をまたがって」とは?別のセミナーでも、ベンダさんから「ASPやSaaSも不可能ではないが、顧客数や信頼性を考えると現時点では業務系システムはローカルに置きたい」との意見もありました。何だかんだ言ってカスタマイズが多く入ってしまう業務系システムをSaaSにするよりは、共通仕様と最小限のカスタマイズで運用できそうなWikiやSNS、ILLや横断検索(これは県立クラスがtarget?お値段から)であればデータセンターでまとめてサービスできる、と踏んだのでしょうか。ここにbXが位置する。2007のプロダクトレビューに紹介記事があります。さま、このblogをご紹介いただきありがとうございました。)この文脈で、「(2)複数の図書館をまたがって」を考えてみました。現在は、図書館同士の連携システムというとILLぐらいしか思いつきませんが、貸出履歴データの共有とレコメンド、また自治体を超えたILLやレファレンス記録の共有などを考えると、図書館の業務系システムも単館で存在するより、お互いに連携させることで新たなサービスを生み出す、そういう戦略が裏で存在するのではないでしょうか。(しかも同一ベンダで固めれば県下の市町村の図書館システムのシェアはアップ。Peerに連携するシステム、という発想は正直ありませんでした。うまくAPIが共通化されて、オープンな形での連携が可能なシステムを考える、というのも面白そうな話ではあります。いえ、先のbXやPrimoの動きを見ていると、統合検索や各種の仕様自体はオープンにはしているけれど標準化せず自社製品に特化させ、結果として「囲い込み」が始まっている、と見ることもできます。それとも事実上のスタンダードとなるのか。あとは開発する人=図書館員の努力しだい、ということでしょうか。「ムフフ」はJR東日本の割引サービス「トクだ値」のネコから頂戴しました。尻尾が「JR」な以外、何の他意もないです。bXセミナーに行ってきました。この手のセミナーに参加する、いや出張自体が久しぶりなので開放感にあふれています。うひゃっほう!今日の目玉はPrimoとbXの紹介。目指すものはレコメンドサービス。論文単位の要求に応えられる。準拠と相互運用性の確保。Librisの紹介から。図書館システム(Aleph)からリンクリゾリバ(SFX)、メタサーチ(MetaLib)、統合インターフェース(Primo)などトータルラインナップを用意している。Hi-endな顧客をターゲットとし、顧客とのコラボレーション、緊密な連携を保っている。76%のスタッフを研究開発に振り向けるなど、常に次世代への投資を怠らない。図書館以外への検索要求の増加というパラダイムシフトが背景にある。OpenURLなど標準策定への参画ユーザグループとの連携OpenPlatformとユーザコミュニティによる拡張OpenPlatformあたりの話題は、カレントアウェアネス-R(2008.7.11)でも報じられていたところです。Commonsと呼ばれるコミュニティサイト(ユーザのみ公開)で公開されています。「うちはOpenPlatformだから」という説明はこの後何度か出てきましたので、ポイントの一つかもしれません。次はPrimoの紹介。books、amazonなど他のアクセスポイントなどへのリンク、など一般的な機能は一通り抑えています。あたりでお試しください。(ソースはやっぱりカレントアウェアネス-R(2009.3.3)。いつもありがとうございます。Experience)の2階層構造で、先に紹介した機能がフロントエンドにあたります。XML(PNX)レコードを作製します(FRBR対応!)。このPNXを元に重複除去や元データの拡張(amazonから表紙画像をもらってくるとか)を行い、Primoのインデックスとなります。ハーベスト対象にはDigiTool、Dspace、Fedoraといった機関リポジトリにも対応とのこと。従来のMetaLibのようなメタサーチでも検索結果の重複除去などの機能はありましたが、Primoではデータをハーベストしてレコードの正規化までしてしまうのですね。ハーベストできないリソースについては最適化もできないので従来のメタサーチをするしかないのか、と考えてしまいましたが、レスポンスが早くないランキングやファセットの精度が上がらないことを解消するため、メタサーチの際に「Primo仕様の検索式を投げ、PNXでデータを返戻」するための仕様を公開しているそうです。Commonsにサンプルコードがあるから見て」とのことでした。)Primoは現在3500万レコードまでをサポート、160以上の顧客があり、現在は対応言語の拡大を図っているそうです。(日本語は対応準備中、でも日本語カタログは配られていました。)AquaBrowserなど競合他社製品との相違点を質問しましたが、「詳細は承知していない」ながらも「APIやSDK公開など、OpenPlatformである点は大きく異なる」としていました。Commonsではユーザが作った拡張アプリ、ユーティリティなどがあり、「ユーザ参加」型の開発姿勢が伺えます。Librarianがいて、それで始めてできる技だよなあ。)コーヒーブレイクの後はいよいよbXについて。ユーザがどのようなコンテンツを作成したか、またユーザが何をしたかがフォローされ、重要視されつつある。amazonのレビュー、taggingなどでのユーザ参加。今日のYouTube。Talent」の動画がアップされ、3000万回以上再生されている。日本語字幕版も)結果、図書館の利用データに価値が生じた。インパクトファクターでの評価には分野の限定やタイムラグなどの問題がある。学術論文の電子化は、単にPDFやHTMLに媒体が変わっただけでなく、メディアの多様化ももたらした。論文の評価手法は引用分析など、紙ペースの手法のまま。図書館の中で必要性が生まれたが、EBCSO、LibraryThingsなど今までのシステムではタイトルを表示する程度の機能しか持たない。学術分野に求められているのは「論文」レベルのレコメンド。「人気」に基づくものではなく、利用状況の分析に立脚したもの。Alamos研と独占的契約を結び、2007年からbXの研究開発に着手。ネットワーク化された研究コミュニティの力を利用して、論文の利用に応じたレコメンデーションを行う。複数の図書館での利用状況を統合、これを分析する。OAI-PMHの作成などに貢献)によって行われた。この研究の詳細は2人による次の論文を参照されたい。2009-04-20)1億件以上(!)のSFXのログデータを収集、これを元に分析を行った。リンクリゾルバはOpenURLを介して接続された各種のリソース間のハブと言える。Layer」の2階層と捉える。OpenURLは2001年にSFXが実装、2009年現在では3000以上(うち1800以上はSFX)のリンクリゾルバのみならず多くの学術情報同士のリンキングに利用されている。リンクリゾルバがリソース間のハブとなっている。bXはこのアーキテクチャの上に構築されている。ここにbXが位置する。データ取得は、欧米の各大学より協力を得た。