OR2007 第2日 2007年1月24日速報版
分科会(続)
DSpace http://openrepositories.org/program/dspace
Session 5 DSpace
1.Faculty participation in IR (Cornell DSpace) Research project in
communication.
www.library.cornell.edu/mjc2/connolly_davis-IR2007.ppt
状況・教員からの聞き取り結果は日本と大差なし。他のリポジトリ担当者が自分の困った点を質問しているのが目立った。空collectionの少なさはリポジトリ比較のポイントとなっていた(「空」はよく見られるがユーザをがっかりさせるので、先にコレクションを設定しないほうがよいと意見が一致していた)。
2.DL preservation(NYU)
NYUが複数のデジタル保存経費を獲得したことから、保存方法が議論になり、単一のDSpaceリポジトリにファイル格納+ファイル登録とインタフェースはプロジェクトごと、というシステムを構成中。開発を各要素に分け、アップグレードと開発の効率向上。DSpace
ver1.3のSRB機能を使って130GBまでの巨大ファイル登録(プロジェクトによっては800GBのファイルもあり)。認証要素:Shibboleth+CASで認証ユーザがファイル操作が出来るように。OAI-PMHのほかSRW/Uを採用、extra
dataフィールドを使用してリアルタイムマッピング。
3.プラットフォームとしてのDSpace:DSpace1.4のプラグイン紹介 (Washington Research Library Consortium)
Session 6 DSpace
1.Manakin themes(Texas A&M)
MANAKIN themeはDRIをXHTMLフォーマットに変換し、結果をCSSのスタイルで表示。コレクションごとに見た目を設定できる。国際化(言語設定)もthemeからできる。
2.Manakin case study(Texas A&M): 時空間メタデータの可視化
ライブサイト:http://labs.di.tamu.edu:8080/geofolios/handle/123456789/2
#使ってもらえそう!時空間情報を付与できるアイテム(貴重画像)の発信に有効なUI。
これまでの方法では複雑なアイテムを扱えないし、ダブリンコアでは足りない。しかも、アイテムリストは良くないUI(たとえば、どこの地図なのかわからない)。
ケーススタディ:アメリカ地質図(Geologic Atlas of the United
States)。解説文も地質学情報を含む。1コレクション227アイテムとしてDSpaceにいれる。ビットストリーム+PDF(スクリーンビュー)。時空間メタデータとしてDCMI採用。UIにMANAKIN。アイテム構造を複雑に出来る。METSが含まれており、画像の相互関係を記述可能。
Yahoo Mapsをインタフェースにして、地図上に置かれたアイコンをクリックすると地図を出せるようにした。検索結果も地図上に置くようにカスタマイズ(このプロジェクトでは2日で開発!)。コレクションの価値が上がり、アクセスが増えた。
3.コンテンツ交換と見えないリポジトリ(ANU)
コンテンツ交換 最終報告書 www.apsr.edu.au/publications/presta
APSR 2007: NLA SIP/DIP profile, default content models(発表予定)
他のリポジトリとの交換だけではなく、システム変更の場合にも必要。
難しいところ:実装する側に便利で、かつさまざまな利用場面に応じたサポート提供。
Demo: DSpace-Fedora exchange, Open Journal System, Bidwern
Bidwern (="many fingers") project (2005-2006):
研究者のIR投稿を支援(filemaker等からDSpace METS
profileにエクスポート、そのままIRにメールなど経由で投稿、すぐに公開)。GoogleMaps/GoogleEarthと連携したポータル、MANAKIN利用。
#こういう方法で既存の画像等と論文等を結びつけられれば、利用価値は高まるはず。
anu.edu.au/bidwern
Session 7基調講演
事務局から:参加364人とのこと。
James L. Hilton (CIO, Virginia (formerly Michigan)) Open source for
open repositories---new models for software development and
sustainability
Research background: psychology.
オープンリポジトリは社会の進歩に貢献するが、現在のようにオープンソースで構築するのが唯一の持続可能な方法である。IT研究基盤への投資は根本的に学術活動を変容させる。巨額の投資が必要なため、競争しながらの共同作業が重要となる。
オープンソースをめぐる考え方。(1)オープンとフリーはちがう。フリーでは所有はできるがそれだけ。オープンではソースをいじれる。いずれも無料という意味ではない。(2)ライセンス。公正使用は利用者側で保護されている権利であるが、オープンソフトウェアも明文化された使用条件・契約のもとに利用されるものである。(3)copyleft
or viral vs open/open or
non-copyleft。これらは「オープン」の異なる解釈に基づく。ソースの変更は可能だが非公開は許されない。Viralとは同じ条件の伝播。open/open:
★ケーススタディ:Sakai@Michigan。古い授業管理システムを更新する必要があった。開発・教育・研究を活性化させるために、研究室と教室の区別をなくす戦略を採用(当時研究用にworktoolsがCMSとは別にあった)。NRC報告書・共同作業の必要があった。タイミング(メロン基金でMIT、スタンフォード、インディアナ、ミシガンが同時に導入)
共同作業という点で面白い(それぞれが独自性にこだわったが)。
方針:自力開発はしない。
2004年1月22日 Chronicle of Higher Education記事
July 04 Sakai 1.0 release, tools (CMS, Worktools…)
その後コミュニティ拡大、民間企業も加わった(サポート、ホスティングを販売)。6ヶ月ごとに会議。
その後、「卒業」。知的財産権がSAKAI foundation@CAに委譲されることになった。
得たもの:方向性コントロール、コミュニティ形成、ソフトウェア所有権とサポートを分離、共有に価値を置くようになった。
"pure property"という考え方は学術になじまない。知的所有権はアイディアを共有するための仕掛けであって、防衛するものではない(ぎちぎちに護ったら身動き取れなくなる)。
2006年9月16日Blackboard訴訟
共同作業の所有権は…例:移植医療のビデオを題材とした学生論文。学生の所有権となったが、教員は「もう学生を使って論文を書くのはやめた。雇う」と述べた。
問題:ソフトウェアのIPを完全に処理することは不可能。
機関所有のソフトウェアでは、誰がライセンス権を持つのかわからない。
SAKAIの場合、機関によって考え方が異なった。
どうやったらIP権侵害していないことが保障できるのか?
オープンソースソフトウェアは機関の知的所有権とセットにするというのは必ずしも正しいとは限らない。
ライセンスは大事。選択肢が多すぎてわけわからないので標準化が必要(Gandel-Wheeler 2005)
コミュニティ形成には目的の共有・共通理解とガバナンスが必要。協力と共同作業は違う。コミュニティはガバナンス否定ではない。開発者とは別に意思決定機関が必要。
実践と理想のバランスをとることが必要。パートナーを信頼しなければならない。
★リポジトリでは?
図書館・教室・研究室と世界を結ぶ役割をもち、21世紀の大学には必要なものである。コミュニティはeprints.org, fedora,
dspaceとそれぞれ異なるアプローチを取っている。DSpaceは(熱心な)ユーザと開発者のコミュニティである。Eprintsはベンダーとカスタマーの関係に似ている。Fedoraは過渡期で他の二つの間くらいだが、これはSAKAIのように機関レベルのコミュニティとなりそう(個人ではない)。
問題点:機関が投資するタイミングか?⇒Yes!個人が世界を変える時代だが、共同して意図的に世界を変えていくタイミング。
質疑応答
Q標準化は必要か?
A共同作業には必要。とくに、機関レベルでは常に必要。
Q金?
Aそれだけなら問題ない。短期の外部資金はあるかもしれないが、長期には機関のコミットメント・決定が必要。セキュリティ、資金、制度・システム上の限界が問題となる。サイバーインフラストラクチャは研究者のためというのが決め手。
Qどうやって?
A状況は常に変わっている。図書館・ITのコミュニティは融合するはず。
Q Sakaiのようなアプローチは訴訟リスクの問題は無いか?
Aわからない。
Q コンテンツの知的所有権は?
A 分離が必要。ソフトウェアの場合には機関は所有権を持とうとするが、コンテンツではリスクがある。
Session 8
1. Arrow project 2004-2006, extended to the end of 2007
機関リポジトリソフトウェアの比較:DSpace/Eprints
文献からマルチメディア・データセットへの移行
ARROW discovery service: search.arrow.edu.au
2003 fedoraを選択⇒「FedoraのFはflexibleのF」で、他にもいろいろ決定する羽目になった。andrew.trelor.net/research/publiations/ausweb04
反省:flexibleというのはうれしいけど大変だった。開発の遅れが問題を引き起こしたが、そんなにわるくなかった。
メタデータ決定:生のDCはあまりのも限定的。MARCXML,ETD-MSをOAI−PMHと内部仕様に適合したDCに変換。
反省:まだまだ問題がある。OCLCとの協力は時間がかかっている。
Identiferの決定:persistent identifiers⇒CNRIハンドルを採用。
反省:ハンドルソフトウェアは良かったが、もともとの期待にこたえるには時間がかかった。Dis/re-aggregationには未対応。PILINプロジェクト開発中。そもそもpersistent
identifierが必要なのかまだ議論がある。
コンテンツ・モデル決定:複合オブジェクトモデルを採用。
反省:ソフトウェア開発は簡単になったが、メタデータは複雑になった(各部分にメタデータを持たせるのは大変)。RELS-EXT,RELS-INTの併用で何とかなるかもしれないが、そもそも問題が解決可能なのかもよくわからない。
コンソーシアム決定:Monash (lead institution), National Library of Australia,
New South Wales, Swinburne U of Tech 各機関から2名ずつManagement
Committeeに出た。検索・インデクシングはNLAが担当。
反省:だいたいよかった。情報交換、作業分担、それぞれの長所を生かせた。パートナー間の優先順位の違い、時差・距離(なかなか会えない)は問題。
開発モデル:VTLS社(www.vtls.com)とパートナーに。VTLS社は開発スタッフと将来の開発・サポートのインフラを提供。ARROWでは知的所有権とデザイン仕様、「実世界」での例・テスト・フィードバックを提供。
理由:市場に出すことで開発速度が上がるかも。要件定義に集中できる。外部資金が尽きても継続可能。
開発を成功させるには:仕様をきっちり固める(作業定義、誤解を避ける、マイルストーンごとに完了したと合意が必要)。コミュニケーションを密に(メール、wiki、毎週テレビ会議、6ヶ月ごとにオフライン会議)。
反省:開発遅延(スタッフ変更、Fedora開発の遅れなど)。ARROWとVTLSで優先順位が違った。
2007年 Fedora上のオープンソース、VITALとOpenSourseの連携。
Contact:David.Groenewegen @ its.monash.edu.au (project manager)
2. How principles and activities of Digital curation to repository
management and operations(Virginia)
Fedoraリポジトリ。XPAT, Cocoon, Squid, CSS stylesheets. ImageViewer.
各ユーザが個人コレクションを作れる。
15年かけて学内電子化したコレクションを核に、ボーンデジタルの学術コンテンツもある。
Digital curation: digital preservationだけではなく、intellectual
curationも重要。将来にわたって研究活動に使える形で提供しなければならない。⇒学術活動支援・特色のある貴重アイテムへのアクセス振興の両方を基本的な考え方とした。これが電子化対象の決定要素の一部となる。さらに、電子化に付加価値が期待されるもの、物理対象の保存に電子化が役立つもの、という要素も加味する。さらに標準遵守の方針を採用。
リポジトリの中身を信頼がおけるものとするため、認証・権利管理・セキュリティが必要。
信頼の置けるリポジトリのために、OAISリファレンスモデル、persistent
identifiersを採用。ガバナンス・運用ポリシーの文書化・定期レビューも不可欠。
3. CURATOR: its development strategy (Chiba)
内容は高野さんから公開されることを期待しています。
発表はものすごく受けていました!特に難しい単語を一生懸命正しく発音した後「うちのボスがこう書けといって…」で爆笑を誘っていたのが印象的。
その他
事前にHUSCAPのスクリーンショットを用意していて、メタデータについて小坂さんに質問していた人がいました!