c4ljp_2014_enju_ir

5f34c4c6e5d9cb955c1552d3cb444b6c?s=47 Kosuke Tanabe
September 07, 2014

 c4ljp_2014_enju_ir

5f34c4c6e5d9cb955c1552d3cb444b6c?s=128

Kosuke Tanabe

September 07, 2014
Tweet

Transcript

  1. Next-­‐L  Enju   機関リポジトリモジュール 2014年9月8日   Code4Lib  JAPAN  Conference  2014

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

  3. Next-­‐L  Enjuとは?(1) •  Project  Next-­‐Lの開発する図書館システムの 総称   – enju_leaf  (図書館業務管理システム)  

    – enju_root  (FRBRモデルによる書誌管理システム)   – enju_erms  (電子リソース管理システム)  
  4. Next-­‐L  Enjuとは?(2) •  Ruby  on  Rails  を中心に、Apache  Solr,   PostgreSQL/MySQLなどのフリーソフトウェアを

    用いて構築   •  Next-­‐L  Enju自体もフリーソフトウェアとして   公開   – hSps://github.com/next-­‐l/enju_leaf
  5. Next-­‐L  Enjuの特徴(1) •  広く利用されているWebアプリケーション   フレームワークやミドルウェアを用いて構築   – クラウド環境での動作を前提とする   • 

    RESTfulなインターフェース   – すべてのレコードがURLを持つ  
  6. Next-­‐L  Enjuの特徴(2) •  機能ごとのモジュール化により、新機能の   追加やテストを行いやすくなっている   – enju_biblio  (書誌管理)  

    – enju_library  (施設管理)   – enju_circulaYon  (貸出管理)   – enju_ndl  (NDL接続)   – enju_ir  (new!)  
  7. enju_ir  モジュールとは? •  Next-­‐L  Enjuに機関リポジトリの機能を追加   するためのモジュール   – ファイルのアップロードと保存  

    – OAI-­‐PMHのサポート   •  現時点ではenju_leafに組み込んでの動作を サポート   – enju_ir単体での動作も可能とする予定  
  8. なぜ今ごろ、   機関リポジトリモジュール?

  9. enju_ir開発の理由 •  学術情報を扱うWebサービスの変化   – 論文ID,  研究者ID,  研究助成ID,  …   – 文献管理サービス,

     研究者SNS,  altmetrics…   – これらがすべてつながる   •  扱う資料そのものの変化   – 論文だけでなく、研究データも   – データの公開が成果として扱われるようになると、 公開作業にも迅速さを求められる  
  10. 開発の背景 •  自分の組織で生まれたデータを提供する   重要なシステムとして拡張を行いたい   – DOI自動付与、Linked  Data対応   – 組織内イントラネット上のサービスとの連携

        •  ところが、手頃に改変できそうなソフトウェア がない  
  11. 他のソフトウェアの検討 •  WEKO(JAIRO  Cloud)…ユーザインターフェース がAJAXを多用しており、変更が困難   •  Dspace…広く利用されているが、Javaなのが 面倒  

    •  Hydra…ユーザインターフェースを担当する blacklightが意外に複雑な構造をしており、   思い通りに作ろうとするとほぼ全面的に作り 直すのと変わらなかった  
  12. enju_irの特徴 •  データ保存用ミドルウェアにFedoraCommons を使用   – Dspace,  Hydra,  Islandora,  eSciDocなどで広く採用  

    •  データ検索用ミドルウェアにElasYcSearchを   使用   – Apache  Solrと並んで人気のある検索エンジン   •  単純な構造のHTML  
  13. FedoraCommonsの利点 •  柔軟なデータ構造を提供   •  メタデータを持つオブジェクトとコンテンツを   持つオブジェクトを関連づけて資料を表す   – 関連をRDFを用いて表現することが可能

      – トリプルストアとしても動作   •  世界中で広く利用されており、活発なユーザ コミュニティが存在する   – 検索エンジンで容易にトラブル対応策が見つかる  
  14. hSp://fedora-­‐commons.org/   documentaYon/3.0b1/userdocs/   digitalobjects/objectModel.html FedoraCommonsの   オブジェクトの構成 •  メタデータを持つ

      オブジェクトに   複数のファイルを   関連づけられる  
  15. ElasYcSearchの利点 •  高速・高機能   – Apache  Solrと同じLuceneベースの検索クエリを   使用できる   – ファセット検索,

     代替検索語の提示   •  JSONを用いて検索やインデックスの作成・   更新を行うことができる   – 扱いがXMLよりも容易   – JavaScriptから直接検索を実行できる
  16. 具体的な実装 •  acYve_fedoraを改造   – hydra(Ruby  on  Railsで実装された機関リポジトリ 構築ソフトウェア)で使用されているライブラリ   – FedoraCommonsへのアクセスとSolrでの検索を

      担当   •  Solrに接続する部分の処理を   ElaYcSearchに接続するように書き換えた  
  17. Ruby  on  Rails Apache  Solr acYve_fedora rsolr FedoraCommons blacklight Hydraの構成図(簡略化)

  18. Ruby  on  Rails ElasYcSearch acYve_fedora elasYcsearch-­‐ model FedoraCommons enju_ir Next-­‐L

     Enju  +  enju_irの   構成図(簡略化) enju_leaf
  19. 動作デモ

  20. Next-­‐L  Enjuとの連携による利点 •  紙ベースの資料と機関リポジトリ上の資料の 管理の統合   – DOI/CrossRefを用いた書誌データの流用   – 冊子体・電子資料の統合検索  

    – 各館の資料コレクションに対する独自の   メタデータの作成と付与   – 運用サーバ数の削減  
  21. おわりに •  MLAでも情報技術は重要、とは言われるが…   •  実体は逆行していないか?   – 一極集中、外部依存への危機感 例:  JAIRO

     Cloud   – 開発も運用も他人が勝手にやればよい?   – 大規模大学でなければ構築の機会がない?   – 職員がシステム構築を行う機会を逆につぶして いないか、自分で工夫する機会を奪っていないか   •  状況を固定化させない手段としてのOSS  
  22. 試してみよう! •  デモサーバ   – hSp://enju.next-­‐l.jp   •  ソースコード   – hSps://github.com/nabeta/enju_ir

      •  連絡先   – @nabeta  (github,  twiSer)