Next-­‐L  Enju   機関リポジトリモジュール 2014年9月8日   Code4Lib  JAPAN  Conference  2014   田辺 浩介  (@nabeta)

自己紹介 •  とある研究所のエンジニア   •  オープンソース図書館システム   “Next-­‐L  Enju”の主な開発者　

Next-­‐L  Enjuとは？(1) •  Project  Next-­‐Lの開発する図書館システムの 総称   – enju_leaf  （図書館業務管理システム）   – enju_root  （FRBRモデルによる書誌管理システム）   – enju_erms  （電子リソース管理システム）  

Next-­‐L  Enjuとは？(2) •  Ruby  on  Rails  を中心に、Apache  Solr,   PostgreSQL/MySQLなどのフリーソフトウェアを 用いて構築   •  Next-­‐L  Enju自体もフリーソフトウェアとして   公開   – hSps://github.com/next-­‐l/enju_leaf

Next-­‐L  Enjuの特徴(1) •  広く利用されているWebアプリケーション   フレームワークやミドルウェアを用いて構築   – クラウド環境での動作を前提とする   •  RESTfulなインターフェース   – すべてのレコードがURLを持つ  

Next-­‐L  Enjuの特徴(2) •  機能ごとのモジュール化により、新機能の   追加やテストを行いやすくなっている   – enju_biblio  （書誌管理）   – enju_library  （施設管理）   – enju_circulaYon  （貸出管理）   – enju_ndl  （NDL接続）   – enju_ir  (new!)  

enju_ir  モジュールとは？ •  Next-­‐L  Enjuに機関リポジトリの機能を追加   するためのモジュール   – ファイルのアップロードと保存   – OAI-­‐PMHのサポート   •  現時点ではenju_leafに組み込んでの動作を サポート   – enju_ir単体での動作も可能とする予定  

なぜ今ごろ、   機関リポジトリモジュール？

enju_ir開発の理由 •  学術情報を扱うWebサービスの変化   – 論文ID,  研究者ID,  研究助成ID,  …   – 文献管理サービス,  研究者SNS,  altmetrics…   – これらがすべてつながる   •  扱う資料そのものの変化   – 論文だけでなく、研究データも   – データの公開が成果として扱われるようになると、 公開作業にも迅速さを求められる  

開発の背景 •  自分の組織で生まれたデータを提供する   重要なシステムとして拡張を行いたい   – DOI自動付与、Linked  Data対応   – 組織内イントラネット上のサービスとの連携     •  ところが、手頃に改変できそうなソフトウェア がない  

他のソフトウェアの検討 •  WEKO(JAIRO  Cloud)…ユーザインターフェース がAJAXを多用しており、変更が困難   •  Dspace…広く利用されているが、Javaなのが 面倒   •  Hydra…ユーザインターフェースを担当する blacklightが意外に複雑な構造をしており、   思い通りに作ろうとするとほぼ全面的に作り 直すのと変わらなかった  

enju_irの特徴 •  データ保存用ミドルウェアにFedoraCommons を使用   – Dspace,  Hydra,  Islandora,  eSciDocなどで広く採用   •  データ検索用ミドルウェアにElasYcSearchを   使用   – Apache  Solrと並んで人気のある検索エンジン   •  単純な構造のHTML  

FedoraCommonsの利点 •  柔軟なデータ構造を提供   •  メタデータを持つオブジェクトとコンテンツを   持つオブジェクトを関連づけて資料を表す   – 関連をRDFを用いて表現することが可能   – トリプルストアとしても動作   •  世界中で広く利用されており、活発なユーザ コミュニティが存在する   – 検索エンジンで容易にトラブル対応策が見つかる  

hSp://fedora-­‐commons.org/   documentaYon/3.0b1/userdocs/   digitalobjects/objectModel.html FedoraCommonsの   オブジェクトの構成 •  メタデータを持つ   オブジェクトに   複数のファイルを   関連づけられる  

ElasYcSearchの利点 •  高速・高機能   – Apache  Solrと同じLuceneベースの検索クエリを   使用できる   – ファセット検索,  代替検索語の提示   •  JSONを用いて検索やインデックスの作成・   更新を行うことができる   – 扱いがXMLよりも容易   – JavaScriptから直接検索を実行できる

具体的な実装 •  acYve_fedoraを改造   – hydra（Ruby  on  Railsで実装された機関リポジトリ 構築ソフトウェア）で使用されているライブラリ   – FedoraCommonsへのアクセスとSolrでの検索を   担当   •  Solrに接続する部分の処理を   ElaYcSearchに接続するように書き換えた  

Ruby  on  Rails Apache  Solr acYve_fedora rsolr FedoraCommons blacklight Hydraの構成図（簡略化）

Ruby  on  Rails ElasYcSearch acYve_fedora elasYcsearch-­‐ model FedoraCommons enju_ir Next-­‐L  Enju  +  enju_irの   構成図（簡略化） enju_leaf

動作デモ

Next-­‐L  Enjuとの連携による利点 •  紙ベースの資料と機関リポジトリ上の資料の 管理の統合   – DOI/CrossRefを用いた書誌データの流用   – 冊子体・電子資料の統合検索   – 各館の資料コレクションに対する独自の   メタデータの作成と付与   – 運用サーバ数の削減  

おわりに •  MLAでも情報技術は重要、とは言われるが…   •  実体は逆行していないか？   – 一極集中、外部依存への危機感 例:  JAIRO  Cloud   – 開発も運用も他人が勝手にやればよい？   – 大規模大学でなければ構築の機会がない？   – 職員がシステム構築を行う機会を逆につぶして いないか、自分で工夫する機会を奪っていないか   •  状況を固定化させない手段としてのOSS  

試してみよう！ •  デモサーバ   – hSp://enju.next-­‐l.jp   •  ソースコード   – hSps://github.com/nabeta/enju_ir   •  連絡先   – @nabeta  (github,  twiSer)