DSpace システム説明書: アプリケーション層

目次に戻る
アーキテクチャ概要に戻る

ウェブユーザインターフェース

DSpaceウェブユーザインターフェースは、アプリケーション層のコンポーネンツのうち、もっとも大規模で、もっともよく使用されるものです。 JavaサーブレットとJavaServer Pageテクノロジーを使って構築されていますので、エンドユーザはウェブブラウザーを使ってDSpaceにアクセスすることができます。

管理者の使用を想定したページからなる管理用ユーザインターフェースも用意されています。 ただし、現在のところ、管理用ウェブユーザインターフェースはあまり洗練されていません。 それゆえ、管理用ユーザインターフェースのユーザは自分のしていることを知っている必要があります。 将来のバージョンでは、管理用ユーザインターフェースはもっと改善されますので、各コミュニティにより多くの管理責任を託すことができるようになるでしょう。

ウェブユーザインターフェースに関するファイル

ウェブユーザインターフェースに関するファイルは、DSpaceソースツリーの様々なディレクトリに置かれています。

ウェブユーザインターフェースに関するファイルの配置場所
配置場所 説明
org.dspace.app.webui ウェブユーザインターフェースのソースファイル
org.dspace.app.webui.filter サーブレットフィルタ（Servlet 2.3仕様）
org.dspace.app.webui.jsptag JSPカスタムタグクラスファイル
org.dspace.app.webui.servlet 主たるウェブユーザインターフェースのサーブレット（コントローラ）
org.dspace.app.webui.servlet.admin 管理用ウェブユーザインターフェースを構成するサーブレット
org.dspace.app.webui.util サーブレットおよびフィルタで使用される様々なクラス
dspace/jsp JSPファイル
dspace/jsp/WEB-INF ウェブアプリケーション配置記述子およびタグライブラリ記述子ファイル
dspace/jsp/classes DSpaceインストール環境では、これは、/dspace/configへのシンボリックリンクである。 これにより、（Tomcatを通して）「ウェブアプリケーション」として稼働している間、DSpaceのメイン設定ファイル（dspace.cfg）をフルパスで指定することなく、Javaリソースとしてアクセスできるようになる。 このシンポリックリンクは、ソースディレクトリには存在せず、Antによるビルドプロセスで作成される。
dspace/jsp/lib DSpaceインストール環境では、これは、/dspace/libへのシンボリックリンクである。 DSpaceが「ウェブアプリケーション」として稼働している間、しかるべきJARファイルをすべてJVMのクラスパスに配置する。 このシンポリックリンクは、ソースディレクトリには存在せず、Antによるビルドプロセスで作成される。

このように、/dspace/jspは、Tomcat（あるいは他のサーブレットエンジン）が理解できる標準的な「ウェブアプリケーション」レイアウトになっています。

サーブレットとJSP

ウェブユーザインターフェースはおおざっぱにいってMVC（モデル、ビュー、コントローラ）モデルに基づいています。 コンテンツ管理APIがモデルに、Javaサーブレットがコントローラに、JSPがビューに相当します。 相互の関係は次の基本的な形をとります。

  1. ブラウザからHTTPリクエストを受け取る
  2. 適当なサーブレットが呼び出され、DSpaceビジネスロジック層公開APIを実行することでリクエストを処理する
  3. 処理結果にもとづいて、サーブレットは適当なJSPを呼び出す
  4. JSPは処理を行い、ブラウザに送信する

このアプローチは次の理由で採用しました。

すべてのDSpaceサーブレットは、DSpaceServletクラスのサブクラスです。 DSpaceServletクラスは、Contextオブジェクトの作成（データベースコネクションのオープンなど）や、権限付与、エラー処理などの基本的な操作を扱います。 通常のサーブレットのようにdoGetメソッドとdoPostメソッドをオーバライドするのではなく、DSpaceサーブレットではdoDSGetメソッドとdoDSPostメソッドを実装しています。これらのメソッドは、コンテキストオブジェクトを追加パラメタとして持ち、かつ、標準的な方法で扱うことのできる様々な例外をサーブレットが投げられるようにしています。

DSpaceサーブレットは、HTTPリクエストの要求を処理します。 その要求には、クエリ条件を指定した検索結果の取り込みや、カレントユーザのe-パーソンレコードのアクセス、処理中の投稿の更新などがあります。 この処理の結果にもとづいて、サーブレットはどのJSPを表示するべきかを決定しなければなりません。 サーブレットは次に、処理すべきHTTPリクエストを表すHttpRequestオブジェクトに適当な属性を設定します。 これは、Tomacatからサーブレットに渡されるjavax.servlet.http.HttpServletRequestオブジェクトのsetAttrributeメソッドを呼び出すことで実行されます。 サーブレットは次に、JSPManager.showJSPメソッドを使って、適当なJSPにリクエストの制御を渡します。

システム設定の章で説明したように、JSPManager.showJSPメソッドは標準のJSPの代わりに使用される「ローカライズされた」JSPが/dspace/jsp/localディレクトリにないかチェックします。 （このメカニズムは、将来、複数言語をサポートするための拡張に使用できるでしょう。たとえば、フランス語バージョンを/dspace/jsp/lang/frに置くことなどが考えられます。） ついで、標準的なJavaサーブレット転送メカニズムを使って、HTTPリクエストをJSPに転送します。 JSPはTomcatにより処理され、ユーザのブラウザに結果を返します。

このサーブレット/JSP方式には例外が存在します。 「ホームページ」であるindex.jspは、Tomcatから直接HTTPリクエストを受け取り、最初にサーブレットが呼び出されることはありません。 これは、サーブレット2.3の仕様では、「/」に対するリクエストの処理にサーブレットをマッピングする方法がないからです。 通常は、そのようなマッピングによりすべてのリクエストはサーブレットに渡されます。 デフォルトではTomcatは「/」へのリクエストをindex.jspに転送します。 できるだけ簡潔にするために、index.jspは通常はサーブレットにある簡単なプログラムを持っており、JSPManager.showJSPメソッドを使ってhome.jspにリクエストを転送します。 これは、「ホームページ」のローカライズバージョンは、カスタマイズしたhome.jspを /dspace/jsp/localに置くことで作成することができることを意味しています。

同じ理由で、管理用ユーザインターフェースのホームページである/dspace/jsp/admin/index.jspもサーブレットを通らず、Tomcatにより直接呼び出されます。

JSPに転送する前にサーブレットが設定しなければならない属性については、各JSPファイルの先頭のライセンスとコピーライトヘッダの直後に説明されています。 システムでは検証しませんので、サーブレットが必要な属性を設定しない場合は、内部サーバエラーが発生することになります。

フォームフィールドを持つJSPの多くは、どのフォームが入力されたのかをサーブレットに知らせるhidden属性のパラメタを持っています。 投稿用ユーザインターフェースサーブレット（SubmitServlet）は、多くの異なるJSPからの入力を処理するサーブレットの最良の例です。 どのフォームが入力されたのか（どの投稿ステップをユーザは完了したか）をサーブレットに知らせるためにhidden属性のstepパラメタが使用されています。

以下は、1つのHTTPリクエストに対する処理と応答の全プロセスにおける制御の流れを示した詳細で、見るも恐ろしい図です。 権限付与メカニズムの詳細については、ほとんどシステム設定の章で説明されています。

ウェブユーザインターフェースの制御フロー

HTTP リクエスト処理中の制御の流れ

JSP カスタムタグ

DSpaceのJSPはすべて何らかのカスタムタグを使用しています。このカスタムタグは/dspace/jsp/WEB-INF/dspace-tags.tldで定義されており、対応するJavaクラスはorg.dspace.app.webui.jsptagにあります。 使用するタグを以下にリストアップしました。 dspace-tags.tldファイルにタグの使用法についての詳細な説明がありますので、ここでは繰り返しません。

layout

ほとんどすべてのJSPは、このタグを使用します。 このタグは標準的なHTMLヘッダと<BODY>タグを生成します。 従って、JSPの内容は、<dspace:layout>タグの中に置く必要があります。 このタグの（XMLスタイルの）属性は少し複雑ですので、dspace-tags.tldを参照してください。 ソースコードツリーに含まれているJSPファイルも多くの例を提供しています。

sidebar

layoutタグの内部でのみ使用可能で、また、各JSPで使用できるのは1度のみです。 sidebarの開始タグと終了タグの間の内容は、HTMLページの右側のカラムに表示されます。 内容には、JSPタグやJava「スクリプトレット」を含めることができます。

date

org.dspace.content.DCDateオブジェクトで表される日付を表示します。 現在のところ、1種類の日付しか表示できません。将来は、ユーザのブラウザの設定を使ってローカライズされた日付を表示できるようになるかもしれません。

include

おおざっぱにいって、標準の<jsp:include>タグに相当し、同じ機能を果たしますが、JSPManager.showJSPを通るので、ローカライズしたJSPを使用することができます。 ただし、パラメタの受け渡しはサポートしていません。

item

アイテムレコードを表示します。ダブリンコアメタデータとビットストリームへのリンクを含みます。 ビットストリームリンクの表示は非常に簡略化したもので、バンドル構造は考慮されていないことに注意が必要です。 DSpaceはまだ、完全な発信用コンポーネンツを持っていないからです。

アイテムレコードの表示をJSPではなくタグで行っているのには、2つの理由があります。 第1の理由は、それが様々な場所で行われるからです（標準的なアイテムアクセスの際だけでなく、投稿時のアイテムレコードの検証やワークフロー査読の際などにも表示が行われます）。 第2の理由は、アイテムの表示は結局、HTMLというよりほとんどプログラムの仕事になるからです。 もちろん、この方法をとる欠点は、アイテムレコードの表示を正しくカスタマイズすることが少し難しくなることです。 タグ用のプログラム（org.dspace.app.webui.jsptag.ItemTag）を修正する必要があるからです。 将来もっとよいソルーションが見つかると良いのですが。

itemlist, collectionlist, communitylist

これらのタグは、ソート済のアイテム、コレクション、コミュニティのリストを表示します。 表示される情報は非常に限られますが、すべての情報を表示するページへのリンクが含まれています。 これらのタグはHTMLの表中で使用する必要があります。

popup

このタグは、ポップアップページ（たとえばヘルプページなど）へのリンクを処理するために使用します。 Javascriptが利用できる場合は、リンクは既存のDSpaceポップアップウィンドウをオープンするか、前面にポップアップします。 Javascriptが利用できない場合は、標準的なHTMLリンクが表示され、このリンクをクリックすると、「dspace.pop」という名前のウィンドウにリンク先を表示します。 グラフィカルブラウザーでは、これは一般に新しいウィンドウを開くか、その名前を持つ既存のウィンドウを再利用することになります。しかし、ウィンドウが再利用される場合、そのウィンドウが最前面に表示されることはありませんので、ユーザに混乱を与えるかもしれません。 テキストブラウザでは、このリンクをたどることは、単にリンク先の内容で現在のページを置き換えるだけです。 つまりこれは、Javascriptが利用できると最良の機能が提供されますが、その他のブラウザもサポートされていることを意味しています。

sfxlink

SFXサーバが利用できると、DSpaceはアイテムのダブリンコアメタデータを使ってSFXリンクを表示することができます。 dspace.cfgにおいてsfx.server.urlを定義すると、このタグを特定のアイテムで機能させることができます。

学位論文のブロック

投稿用ユーザインターフェースにはMIT図書館の方針の結果として作成されたオプションの機能を持っています。 dspace.cfgのblock.thesesパラメタを trueにすると、投稿用ユーザインターフェースの最初の画面にチェックボックスが追加されます。 これは、ユーザに投稿するものが学位論文であるかどうかを尋ねるものです。 ユーザがこのチェックボックスをチェックすると、投稿は中断（削除）され、学位論文を投稿するためにDSpaceを使用してはならない旨を表すエラーメッセージが表示されます。 この機能の使用の可否は設定することができます。また、必要に応じて、表示するメッセージ（/dspace/jsp/submit/no-theses.jsp）をローカライズすることも可能です。

OAI-PMH データプロバイダ

DSpaceは、オープンアーカイブズイニシアティブ・メタデータハーベスティングプロトコル（OAI-PMH）バージョン2.0のデータプロバイダ機能をサポートしています。 この機能は、OCLCのOAICatフレームワークを使って実現しています。

Javaサーブレットによる「ウェブアプリケーション」を配備して、HTTPを介してOAI-PMHリクエストを受け取り、応答します。 デフォルトの設定では、このウェブアプリケーションは、/oaiに配備されます。 標準のサーブレットはOAICatサーブレットでオーバーライトされます。したがって、/oai配下のURLはすべてOAIリクエストとして解釈されます。たとえば、次のようなリクエストです。

http://dspace.myu.edu/oai/?verb=Identify

このDSpaceの「ベースURL」は、次のとおりです。

http://dspace.myu.edu/oai/

www.openarchives.orgに登録するのは、このURLです。

DSpaceは、OAICatの3つのインターフェース、AbstractCatalog、RecordFactory、Crosswalkを実装しており、これが、DSpaceのコンテンツ管理APIと（検索サブシステムの）ハーベスティングAPIとのインターフェースになります。

現在のところ、基本的なoai_dc、すなわち、限定子なしのダブリンコアメタデータセットのみがエクスポートされます。 すべてのアイテムは限定子付きのダブリンコメタデータを持っていますので、これは非常に簡単です。 このメタデータがハーベストされる際、限定子を単に剥ぎ取ります。 例えば、description.abstractは、限定子なしのdescriptionとして公開されます。 description.provenaceは、公開されません。なぜなら、このメタデータには、アイテムの投稿者やワークフロー査読者のメールアドレスなどの私的な情報が含まれているからです。

他のメタデータセットをサポートするには、そのためのCrosswalkを実装して、後で説明するoaicat.propertiesファイルに追加するだけです。

現行の限定子なしのダブリンコアの実装（org.dspace.app.oai.OAIDCCrosswalk）では、データ中に存在するかもしれない不正なXML文字を取り除いていないことに注意してください。 データベースに（フォームフィードなどの）ASCII制御文字を含むダブリンコア値がある場合、OAIハーベスタに問題を引き起こすかもしれません。 しかし、これが生じるのはまれなケースでしょう。

OAICatインターフェースの実装に加えて、OAIサポートに関連する2つの設定ファイルが提供されています。

oaicat.properties

これはテンプレートとして/dspace/config/templatesにあり、使用するファイルは/dspace/configに出力されます。 install-configsスクリプトが関連するサイト独自のパラメタを設定しますので、これを変更する必要はおそらくないと思われます。 ただし、システムのもっとも古い日付スタンプを正しく反映するために、earliestDatestampフィールドを修正する必要があるかもしれません。 （これは、Itemテーブルのlast_modifiedカラムの値であることに注意してください。）

oai-web.xml

これは標準的なJavaサーブレットの「配備記述子」であり、テンプレートとして/dspace/config/templatesにあります。使用するファイルは、install-configsスクリプトにより、/dspace/oai/WEB-INF/web.xmlに出力されます。 テンプレートにした理由は、oaicat.propertiesファイルの配置場所をこの中で指定しなければならないからです。 修正する必要はないはずです。

セット

OAI-PMH は、リポジトリがレコードを階層構造のセットとして公開できるように規定しています。レコドードは0個以上のセットに含まれることができます。

DSpaceのコミュニティとコレクションによる組織化は、これに自然と適合すると思われます。 OAI-PMHでは、階層の特定の場所を「setspec」により指定します。 setspecは、階層段階の各セットの識別子をコロンで繋げたリストです。 たとえば、次のようなものです。

set1:set2:set3

ここで、set3 が指定された配置場所であり、これはset2の中にあり、さらに、set2はset1の中にあります。 各セットの表示名は、OAI-PMHの「ListSets」リクエストへのレスポンスで指定することができます。

現在のところ、DSpaceではコミュニティとコレクションの内部IDを表示名に使用しています。したがって、コミュニティ103のコレクション145のsetspecは、次のようになります。

103:145

セットについてもう1つ問題があります。OAI-PMHでは、セットは階層構造でなければなりません。 DSpaceは階層構造を実現していません。それで、コレクションXは、コミュニティBにも、コミュニティCにも存在することができます。 これをOAI-PMHで公開できるか、できるとしたらどのようにするかは、未解決の問題です。 しかし、これは今のところ問題にはならないと思われます。 なぜなら、そのような複数のコミュニティへの配置を確実に実現するには、この問題だけではなく、システムの多くの部分を同時に修正する必要があるからです。

固有識別子

OAI-PMHデータリポジトリのアイテムはすべて、URIシンタックスに合致した固有識別子を持たなければなりません。 この条件に完全に合致するので、ハンドルを固有識別子として使用しています。 別の方法として、ハンドルをOAI-PMH識別子スキーマにマップすることが考えられます。 しかし、ハンドルはすでにURI形式の世界規模でユニークなスキームを使用しており、また、両者に明らかな機能上の差もないので、この方法を取ることは時間の無駄だと思われます。

アクセスコントロール

OAIはユーザ認証/権限付与の詳細については規定していませんが、これらは標準的なHTTPメソッドを使って実装することができるでしょう。 とりあえず今のところは、すべてのアクセスは匿名であると仮定しています。

「すべてのメタデータは公開されるか」という疑問が存在します。 現在のところ、答えはイエスです。 たとえアイテムがアクセス制限ポリシーを持っていたとしても、メタデータはすべてOAI-PMHを通して公開されます。 その理由は、制限されたアイテムを読むための権限を実際に持っている人は、コンテンツを発見するためのOAIベースのサービスを使うこともできるべきであるというものです。

将来において、何らかの理由でこの「すべてのメタデータを公開する」というアプローチに問題があることが証明された場合、一部のメタデータだけを一般に公開することが可能だと思われます。 権限付与システムでは、アイテムを読むことができる権限と、それに含まれるコンテンツ（ビットストリーム）を読むことのできる権限を分けています。 これは、システムが、メタデータは公開するがコンテンツは公開しないアイテムと、メタデータもコンテンツも公開しないアイテムを区別することができることを意味しています。 この場合、OAIデータリポジトリは、匿名によるREADアクセス権限を持つアイテムのみを公開すべきです。そうすれば、レコードの存在を外部の世界から完全に隠すことが可能になります。 このシナリオでは、当初はアクセスを制限するが、しばらく後に公開するアイテムに注意する必要があるでしょう。 これが公開された場合、OAI-PMHの観点からはアイテムが「新規」に作成されたことになります。

更新日付（OAI日付スタンプ）

OAI-PMHハーベスタは、レコードがいつ作成・変更・削除されたかを知る必要があります。 DSpaceはシステムにある各アイテムの「最新更新」日を記録しており、この日付をOAI-PMHの日付スタンプに使用しています。 これは、メタデータに行った任意の変更（管理者によるフィールドの修正やアイテムの取り下げなど）がハーベスタに公開されることを意味しています。

「about」情報

ハーベスタに提供されるレコードの一部として、オプションで繰り返し可能な「about」セクションがあります。このセクションは、（XMLスキーマに合致する）任意の方法で使用することができますが、一般的には、出自情報や権利情報に使用します。また、OAIコミュニティで使用されているそのためのスキーマも存在します。 現在のところ、DSpaceはこの情報を提供しません。

削除

DSpace は、削除（取り下げ）を記録しています。 これはOAIにより公開されていますが、OAIはこれを処理するために特別なメカニズムを持っています。 DSpaceは取り下げたアイテムについても永続的にレコードを保持していますので、OAI-PMHの概念でいえば、DSpaceは、「永続的な」削除をサポートしていることになります。 これは、しばらくすると削除されたレコードを忘れてしまうことを意味する「一時的な」削除のサポートとは対照的です。

アイテムが取り下げられると、これが行われた日付を含む日付範囲を指定したOAI-PMHハーベストリクエストは、「削除済」レコードヘッダを見つけることになります。 取り下げが行われた日より前の日付範囲を指定したハーベストリクエストは、レコードはその時点では存在したにもかかわらず、このレコードを見つけることはありません。

この例として、2002年5月2日に作成され、2002年10月6日に取り下げられたアイテムを考えます。 2002年10月を指定したハーベストリクエストは、「削除済レコード」ヘッダをハーベストします。しかし、2002年5月を指定したハーベストリクエストは、取り下げられる前のレコードをハーベストしません。

現在のところ、「抹消された」アイテムはOAIでは公開されないことに注意してください。

フロー制御（Resumption Tokens）

OAIデータプロバイダは、ハーベスティングによるパフォーマンスの低下を防ぐために、データを時分割のかたまりで受け取るようハーベスタに強制することができます。 データプロバイダが大量データの取得リクエストを受け付けた場合、resumptin tokenをつけて、一部のデータだけを送付することができます。 すると、ハーベスタは後でresumption tokenを付けて返すことでハーベストを継続することができます。

DSpaceは、OAI-PMHの「ListRecords」リクエストについてのみ、resumption tokenをサポートしています。ListIdentifiersリクエストとListSetsリクエストについては、システムへの負荷がそれほど大きくないので、resumption tokenは使用しません。

OAI-PMH ListRecordsリクエストには、1回当たり最大100レコードが返されます。この件数は、org.dspace.app.oai.DSpaceOAICatalog.javaの先頭で設定（MAX_RECORDS）しています。 ちょうどMAX_RECORDSの倍数のレコードをハーベストする場合、最後の操作で0個のレコードをハーベストすることになるという潜在的な問題があります。 これが仕様にあっているのかどうかはOAI-PMHの仕様からは不明です。

resumption tokenを発行する際、オプションのcompleteListSize属性と cursor属性は設定しません。 OAICatは、resumption tokenのexpirationDateを発行後1時間に設定しますが、DSpaceのresumption tokenにはリクエストの継続に必要なすべての情報が含まれているので、実際はresumption tokenは失効しません。

DSpaceのresumption tokensには、リクエストの継続に必要なすべての状態情報を含んでいます。その形式は次のとおりです。

from/until/setSpec/offset

fromとuntilは、ISO8601形式の日付で、オリジナルのリクエストから取られたものです。setSpecもオリジナルのリクエストから取られたものです。offsetは、すでにハーベスタに送付済みのレコード数です。

2003-01-01//56:78/300

上の例では、ハーベストの「from」日付は2003-01-01、「until」日付はなし、コニュティ56のコレクション78を対象とし、すでに300レコードがハーベスタに送付済みであることを意味しています。 （実際は、オリジナルのOAI-PMHリクエストが「from」あるいは「until」を指定していない場合、OAICatは、自動的に各々「0000-00-00T00:00:00Z」と「9999-12-31T23:59:59Z」を設定しますので、DSpaceのresumption tokenは常にfrom日付とuntil日付を持っています。）

アイテム・インポータ/エクスポータ

DSpaceは、DSpaceシンプルアーカイブフォーマットを使って、アイテムを一括してインポート、あるいは、エクスポートするツールを持っています。 ツールはまったく頑健ではなく、また、1つの巨大なトランザクションとして処理されることが多いので、一括処理は全体として成功するか失敗するかのいずれかです。 しかし、ツールはそのままでも便利なものですし、容易に改造することもできます。 また、独自のアイテムインポータが必要な場合、このツールはその実装法についての良いお手本になるでしょう。

DSpaceシンプルアーカイブフォーマット

DSpaceシンプルアーカイブフォーマットの基本的なコンセプトは、アイテムごとにサブディレクトリを持つアイテムからなるディレクトリとしてアーカイブを作成することです。 各アイテムディレクトリは、アイテムを記述するメタデータファイルとアイテムを構成するファイルからなります。

archive_directory/
    item_000/
        dublin_core.xml -- 限定子付きダブリンコアメタデータ
        contents        -- 1行に1ファイル名を記したテキストファイル
        file_1.doc      -- アイテムにビットストリームとして追加されたファイル
        file_2.pdf
    item_001/
        dublin_core.xml
        contents
        file_1.png
        ...

dublin_core.xmlファイルのフォーマットは次のとおりです。 各ダブリンコア要素は、<dcvalue>タグセットに自身のエンリトを持ちます。 現在のところ、<dcvalue>には以下の3つのタグ要素を使用することができます。

<dublin_core>
    <dcvalue element="title" qualifier="none">A Tale of Two Cities</dcvalue>
    <dcvalue element="date" qualifier="issued">1990</dcvalue></dublin_core>
    <dcvalue element="title" qualifier="alternate" language="fr" ">J'aime les Printemps</dcvalue>
</dublin_core>

（オプションの言語タグは、別タイトルがフランス語で書かれていることをシステムに知らせていることに注意してください。）

アイテムのインポート

アイテムインポータは、org.dspace.app.itemimport.ItemImportにあり、dspace/binディレクトリにあるdsrunユーティリティを使って実行されます。 このユーティリティを -h を付けて実行すると、使用できるコマンドライン引数を表示します。 引数として、利用者のデータベースIDまたはメールアドレス、e-パーソンIDのいずれか、また、コレクションのデータベースIDまたはハンドルのいずれかを使用することができます。 現在のところ、インポータを使って、コレクションに対してアイテムを追加・削除・置換することができます。あるe-パーソンを投稿者として、あるコレクションにアイテムを追加するには、次のように入力します。

dsrun org.dspace.app.itemimport.ItemImport --add --eperson=joe@user.com  --collection=collectionID --source=items_dir --mapfile=mapfile

（代わりに、次の短縮形を使用することもできます。）

dsrun org.dspace.app.itemimport.ItemImport -a -e joe@user.com  -c collectionID -s items_dir -m mapfile

このコマンドは、アーカイブディレクトリのアイテムを順番にたどって、アイテムをインポートします。 それから、アイテムディレクトリとアイテムハンドルのマッピングを格納するマップファイルを生成します。 このマップファイルは保存してください。 このマップファイルを使って、アイテムのインポートを次のコマンドで「取り消す」ことができます。

dsrun org.dspace.app.itemimport.ItemImport --remove --mapfile=mapfile

マップファイルにリストアップされたインポートアイテムが削除されます。 以前にインポートしたアイテムを置き換えたい場合は、次のコマンドを入力します。

dsrun org.dspace.app.itemimport.ItemImport --replace --eperson=joe@user.com --collection=collectID --source=items_dir --mapfile=mapfile

アイテムの置換は、古いアイテムの置換にマップファイルを使用し、そのハンドルはそのまま残します。 この場合、コレクションIDはコレクションのデータベースIDである必要があります。ハンドルではないことに注意してください。

インポータは通常コレクションに割り当てられたワークフローを迂回します。 しかし、--workflow オプションを指定すると、インポートアイテムはワークフローシステムを経由することになります。

アイテムのエクスポート

アイテムエクスポータは1アイテム、または、アイテムの集合をエクスポートし、エクスポートされる各アイテムについてのDSpaceシンプルアーカイブを作成することができます。 

dsrun org.dspace.app.itemexport.ItemExport --type=COLLECTION --id=collID --dest=dest_dir --number=seq_num

キーワードCOLLECTIONは、コレクション全体をエクスポートすることを意味します。 IDとしては、データベースIDかハンドルのいずれかを使用できます。 エクスポータは、--numberで指定した番号からシンプルアーカイブに付番します。 1つのアイテムをエクスポートする場合は、キーワードITEMを使い、引数としてアイテムIDを指定します。

dsrun org.dspace.app.itemexport.ItemExport --type=ITEM --id=itemID --dest=dest_dir --number=seq_num

エクスポートされたアイテムのディレクトリにはすべて、「handle」という名前のファイルが追加されます。 このファイルには、アイテムに割り当てられたハンドルが書かれています。 このファイルをインポータに入力することにより、エクスポートされたアイテムをオリジナルのハンドルを保持したまま、別のマシンにインポートすることができます。

Copyright © 2002 MIT and Hewlett Packard