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

DSpace Webユーザインターフェース（Web UI）は、アプリケーション層でもっとも大規模かつ利用頻度の高いコンポーネントです。 JavaサーブレットとJavaServer Pageテクノロジーを使って構築されているで、エンドユーザはWebブラウザを使ってDSpaceにアクセスすることができます。 DSpace 1.3.2から、ユーザインターフェースはXHMTL 1.0規格およびWeb Accessibility Initiative（WAI）のレベル2の基準を満たしています。

管理者の使用を想定したページで構成されている管理用のUIも用意されています。ただし、このWeb UIは、現在のところ、あまり洗練されていません。それゆえ、管理用UIのユーザは自分のしていることを知っている必要があります。このUIの一部はコレクションにも使用することができる。[要修正: 管理者か?、それとも編集者か?]

Web UIに関するファイル

Web UIに関するファイルは、DSpaceソースツリーの様々なディレクトリに置かれています。DSpaceバージョン1.2から配備の方法が変更されたことに注意してください。ビルトプロセスは配備が容易なWebアプリケーションアーカイブ（.warファイル）を作成します。

Web UIソースファイルの配置場所
配置場所	説明
`org.dspace.app.webui`	Web UIのソースファイル
`org.dspace.app.webui.filter`	サーブレットフィルター（Servlet 2.3仕様）
`org.dspace.app.webui.jsptag`	JSPカスタムタグクラスファイル
`org.dspace.app.webui.servlet`	主たるWeb UIのサーブレット（コントローラ）
`org.dspace.app.webui.servlet.admin`	管理用Web UIを構成するサーブレット
`org.dspace.app.webui.util`	サーブレットとフィルターで使用される様々なクラス
`[dspace-source]/jsp`	JSPファイル
`[dspace-source]/jsp/local`	カスタマイズしたJSPファイルを置く場所。設定とカスタマイズを参照のこと。
`[dspace-source]/jsp/classesWEB-INF/dspace-tags.tld`	DSpace用Javaカスタムタグ記述子
`[dspace/jsp/lib-source]/etc/dspace-web.xml`	Webアプリケーション配置記述子。`.war`ファイルにインクルードされる前に、テキスト`@@dspace.dir@@`はDSpaceのインストールディレクトリ（この文書では[dspace]で示されている）に置き換えられる。このファイルによりWebアプリケーションはDSpaceの設定と環境を知ることができる。

ビルドプロセス

DSpaceのビルドプロセスによりWebアプリケーションアーカイブが作成され、[dspace-source]/build/dspace.warに置かれる。この処理は、Antのbuild_warsターゲットにより、次のように実行される。

DSpaceの全てのソースコードがコンパイルされる。
[dspace-source]/etc/dspace-web.xmlが[dspace-source]/buildにコピーされ、その中にある@@dspace.dir@@トークンがDSpaceのインストールディレクトリ（dspace.cfgのdspace.dirプロパティの値）で置き換えられる。
JSPファイルが全て[dspace-source]/build/jspにコピーされる。
[dspace-source]/jsp/localからカスタマイズされたJSPが上と同じディレクトリにコピーされ、デフォルトのJSPファイルを「上書き」する。
[dspace-source]/build/dspace.warが作成される。

dspace.warの内容は次の通りです。

（最上位）-- JSPファイル（[dspace-source]/jsp/localに作成したカスタマイズ版のJSPファイルで、DSpaceのソースディストリビューションにあったデフォルトのJSPファイルは置き換えられている）
WEB-INF/classes -- コンパイルされたDSpaceのクラスファイル
WEB-INF/lib -- [dspace-source]/libからコピーしたサードパーティ製のライブラリJARファイル。ただし、Tomcat（あるいはその他のサーブレットエンジン）の一部として利用可能なservlet.jarは除く。
WEB-INF/web.xml -- Web配備記述子。[dspace-source]/build/dspace-web.xmlからコピー。
WEB-INF/dspace-tags.tld -- タグ記述子

これから分かるように、システムにはコンパイルされたDSpaceプログラムやサードパーティ製ライブラリのコピーが複数存在します。したがって、これらすべてが常に同期するよう注意する必要があります（これに伴うストレージ上のオーバーヘッドは数メガバイトであり、今日ではまったく無視できる大きさです）。一般に、DSpaceのプログラムやJSPを変更した際には、[dspace-source]で以下のコマンドを実行して、インストールディレクトリ（[dspace]）の全面的更新と、Web UIおよびOAIの.warファイルの再構築と再配備を行うことがベストです。

ant -D[dspace]/config/dspace.cfg update

実行後は、コンソールに現れる指示に従ってください。

サーブレットとJSP

Web UIはおおよそMVC（モデル、ビュー、コントローラ）モデルに基づいています。コンテンツ管理APIがモデルに、Javaサーブレットがコントローラに、JSPがビューに、それぞれ相当します。相互の関係は次の基本的な形をとります。

ブラウザからHTTPリクエストを受け取る
適当なサーブレットが呼び出され、サーブレットはビジネスロジック層の公開APIを呼び出してリクエストを処理する
処理結果に基づいて、サーブレットは適当なJSPを呼び出す
JSPが処理され、ブラウザに送信する

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

JSPが呼び出される前にすべての処理が行われるので、処理に伴うエラーや問題がHTMLのレンダリング中に発生しない。
JSPの中に含まれるプログラムが最小になるので、Javaプログラムをそれほど詳しく調べることなくJSPをカスタマイズすることができる。

org.dspace.app.webui.servlet.LoadDSpaceConfigサーブレットが常に最初にロードされます。これは非常に簡単なサーブレットであり、DSpace配備記述子のdspace-configコンテキストパラメタをチェックし、dspace.cfgを見つけます。さらに、Log4j設定ファイルをロードします。このサーブレットが最初にロードされることは重要です。そうでないと、他のサーブレットがロードされた場合、システムはDSpaceとLog4jの設定ファイルをロードしようと試みますが、どちらも見つけることができないからです。

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

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

JSPManager.showJSPメソッドは標準的なJavaサーブレット転送メカニズムを使って、HTTPリクエストをJSPに転送します。 JSPはTomcatにより処理され、結果をユーザのブラウザに返します。

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

管理用UIのホームページである[dspace-source]/jsp/dspace-admin/index.jspも同じ理由で、サーブレットを介さずTomcatにより直接呼び出されます。

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

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

下の図は、HTTPリクエストに対する処理と応答の全プロセスにおける制御の流れを示した詳細な見るも恐ろしい図です。ユーザ認証機構の詳細については、ほとんど設定とカスタマイズで説明されています。

Web UIの制御フロー

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に相当する。DSpace 1.2より前のバージョンでは、このタグによりjps/localに置かれたローカル修正版のJSPを使用していた。バージョン1.2以降は、ビルドプロセスがこの機能を果している。しかし、このタグは後方互換性のために残されている。

item

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

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

itemlist, collectionlist, communitylist

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

popup

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

selecteperson

このタグは、HTMLの<SELECT>相当のウィジェットを生成し、ポップアップリストから1人あるいは複数のe-personをユーザが選択できるようにする。

sfxlink

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

国際化

Java Standard Tag Library v1.0を使って、次のように、JSP中のメッセージを指定する。

古い方法:

<H1>検索結果</H1>

新しい方法:

<H1><fmt:message key="jsp.search.results.title" /></H1>

このメッセージはconfig/language-packs/Messages.propertiesファイルを使って変更することができる（ただし、システム構築時に行う必要がある。Messages.propertiesはdspace.warWebアプリケーションファイルに入れられる）。

jsp.search.results.title = 検索結果

翻訳作業を簡単にするために、数字の「キー」で渡されるパラメタをフレーズは持つことができ、これを使って対象となる言語によりふさわしい流れでテキストを翻訳することができます。

古い方法:

<P>結果: <%= r.getFirst() %> - <%= r.getLast() %> / <%= r.getTotal() %></P>

新しい方法:

<fmt:message key="jsp.search.results.text">
  <fmt:param><%= r.getFirst() %></fmt:param>
  <fmt:param><%= r.getLast() %></fmt:param>
  <fmt:param><%= r.getTotal() %></fmt:param>
</fmt:message>

（注: JSTL 1.0 は、<fmt:param value=""/>の属性値としてJSPの<%= %>式を渡せないようです）

上の例は、Messages_xx.propertiesファイルでは、たとえば次のように記述されています。

jsp.search.results.text = 結果: {0}-{1} / {2}

使用するロケールに従ってフォーマットされるよう導入された数値パラメタは、メッセージキーにおいては、文字列パラメタと違いはありません。

jsp.submit.show-uploaded-file.size-in-bytes = {0} バイト

JSPではこのキーを次のように使用します。

<fmt:message key="jsp.submit.show-uploaded-file.size-in-bytes">
  <fmt:param><fmt:formatNumber><%= bitstream.getSize() %></fmt:formatNumber></fmt:param>
</fmt:message>

（注: JSTL は、jsp.foo.key = {0,number} バイトという形で数値をメッセージキーに含める方法を提供しています。<fmt:param value="${variable}" />としてパラメタを設定することは、variableが変数名であれば動きますが、代わりにメソッドの戻り値: bitstream.getSize()を使おうとすると動きません。数値を文字列として渡しても（あるいは<%= %>式を使っても）動きません。

言語ごとに複数のMessages.propertiesを作成することができます。ResourceBundle.getBundleを参照してください。たとえば、ドイツ語とカナダのフランス語の翻訳を次のように追加することができます。

Messages_de.properties
Messages_fr_CA.properties

どの言語が使用されるかは、エンドユーザのブラウズの設定により決められます。エンドユーザが望む言語のメッセージファイルがない場合は、英語のメッセージファイル Messages.properties（あるいは、サーバのデフォルトロケールのメッセージファイル）がデフォルトとして使用されます。（英語のメッセージファイルはMessages_en.propertiesではないことに注意してください。これは、サーバの設定にかかわらず、常にデフォルトとして使用できるようにするためです。）

dspace:layoutタグは、辞書キーをタイトルに渡せるように変更されました。現在は、titlekeyとparenttitlekeyの2つのパラメタを持っています。従って、以前に次のようにしていたところは、

<dspace:layout title="Here"
               parentlink="/mydspace"
               parenttitle="My DSpace">

以下のように修正してください。

<dspace:layout titlekey="jsp.page.title"
               parentlink="/mydspace"
               parenttitlekey="jsp.mydspace">

こうすることで、layoutタグは辞書から関連するテキストを得ます。なお、titleとparenttitleも、こちらの方がふさわしい普通でない場所で使用するため、および後方互換性のために以前と同じように機能します。

メッセージキーの命名規約

他のページを翻訳する際には、名前の衝突を避けるためにメッセージキーの名前については以下の命名規約に従ってください。

JSP中のテキストには、「JSPのフルパス+ファイル名+1語のメッセージ名」を使ってください。たとえば、jsp/mydspace/main.jspのタイトルには、次の名前を使います。

jsp.mydspace.main.title

いくつの一般的な単語（"Help" など）は翻訳を簡単にするために、次のように、jsp.で始まるキーにくくり出すことができます。

jsp.admin = 管理者

また、一般的な単語/フレーズが一連の（同一のディレクトリの）JSPに関連している場合は、次のように、"general" パラメタにくくり出します。

jsp.tools.general.delete = 消去

あるトピック（MyDSpaceなど）に密接にに関係しているが、特定のディレクトリ以外の多くのJSPで使われているフレーズは、キーを共有するとより便利です。たとえば、下記のキーをjsp/submit/saved.jspに使用して、ユーザのMyDSpaceに戻るリンクを提供することができるでしょう。

（キーの共有はメンテナンスを難しくするので一般的には良い考えではありませんが、意味が明らかであれば利点の方が大きくなります。）

jsp.mydspace.general.goto-mydspace = MyDSpaceに戻る

サーブレットプログラム中のテキストには、JSPカスタムタグなど適用できるところはどこでも、「クラスの完全修飾名+1語のメッセージ名」を使用してください。たとえば、次のとおり。

org.dspace.app.webui.jsptag.ItemListTag.title = タイトル

現在サポートされてい言語

既に翻訳されているメッセージファイルは、DSpace Wikiのi18nサポートページを参照してください。

アイテムのHTMLコンテンツ

通常、DSpaceのアイテム表示にはエンドユーザがビットストリームをダウンロードするためのリンクが表示されるだけです。しかし、バンドルの主たるビットストリームのフォーマットがMIMEタイプ text/html である場合は、HTMLサーブレットへのリンクが代わりに表示されます。

次のようなHTML文書があるとします。

contents.html
chapter1.html
chapter2.html
chapter3.html
figure1.gif
figure2.jpg
figure3.gif
figure4.jpg
figure5.gif
figure6.gif

バンドルの主たるビットストリームフィールドが contents.html ビットストリームを指しているとすると、（フォーマットのMIMEタイプを調べることで）それがHTMLだということが分かり、どのファイルを最初に提供すべきが分かります。

HTMLサーブレットはトリックを使って、HTMLファイルやその他のファイルそのものを実際に変更することなくHTML文書を提供します。たとえば、上の例で、誰かがcontents.htmlを見ているとします。その人のブラウザには次のようなURLが見えるでしょう。

https://dspace.mit.edu/html/1721.1/12345/contents.html

HTMLページにfigure1.gifという画像があった場合、ブラウザは次のURLに対してHTTPのGETリクエストを送ります。

https://dspace.mit.edu/html/1721.1/12345/figure1.gif

HTMLドキュメントサーブレットは、まずユーザが今どのアイテムを見ているかを調べ、続いて、その中のどのビットストリームがfigure1.gifと呼ばれているかを調べます。その結果、該当するビットストリームを提供することができます。他のHTMLページへのリンクをたどる方法も同じです。もちろん、全てのリンクや画像への参照は相対である必要があり、絶対参照ではあってはいけません。

これは、次のような、さらに深いパスを参照する相対リンクにも対応できます。

<IMG SRC="images/figure1.gif">

データベースのBitstreamテーブルには "name" フィールドがありますが、このフィールドは常にパスを付けないファイル名（figure1.gif）を持っていることを思い出してください。テーブルにはsourceフィールドもあり、投稿者のハードディスク上にあった時のファイルの完全パス名を持つことができますが、これはブラウザやOSに依存しているので、信頼することはできません。信頼できるのはファイル名だけです。

次のように、URLに含まれているパスをHTMLドキュメントサーブレットに剥ぎ取らせることで、images/figure1.gifが何であるかを調べることができます。

https://dspace.mit.edu/html/1721.1/12345/images/figure1.gif
                                         ^^^^^^^
                                        これを剥ぎ取る

ただし、（ディレクトリ名を無視した）ファイル名が全て異なる必要があります。以下の例では、うまくいきません。

contents.html
chapter1.html
chapter2.html
chapter1_images/figure.gif
chapter2_images/figure.gif

HTMLドキュメントサーブレットは、次のどちらのビットストリームを提供したらよいか分かりません。

https://dspace.mit.edu/html/1721.1/12345/chapter1_images/figure.gif
https://dspace.mit.edu/html/1721.1/12345/chapter2_images/figure.gif

Bitstreamテーブルにはfigure.gifがあるだけだからです。したがって、次のような制限があります。

全てのリンクは相対参照で、かつ親ディレクトリを参照してはならない（たとえば、../images/foo.gifや/images/foo.gifは不可）
リンクがより深いディレクトリを参照している場合は、（上で説明したように）全てのファイル名は異なる必要がある）

学位論文のブロック

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

OAI-PMH データプロバイダ

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

DSpaceのビルドプロセスにおいて、Webアプリケーションアーカイブ[dspace-source]/build/dspace-oai.warが、上で説明したWeb UIビルドプロセスとほぼ同じ方法で作成されます。違うのは、JSPが含まれないことと配備記述子として[dspace-source]/etc/oai-web.xmlが使われることだけです。この「Webアプリケーション」を配備して、HTTPを介したOAI-PMHリクエストを受け取り、応答します。通常、SSL（https:プロトコル）上には配備されないことに注意してください。一般的な設定では、このWebアプリケーションは dspace-oai に配備され、たとえば、次のように呼び出します。

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

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

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

www.openarchives.orgに登録するのは、このURLです。URLの「request」の部分は、[dspace-source]/etc/oai-web.xmlを編集して、dspace-oai.warを再構築・再配備することで簡単に変更できることに注意してください。

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

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

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

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

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

oaicat.properties: これはテンプレートとして[dspace]/config/templatesにあり、実際に使用されるファイルは[dspace]/configに出力される。 install-configsスクリプトが関連するサイト独自のパラメタを設定するので、これを変更する必要はおそらくないと思われる。ただし、システムのもっとも古い日付スタンプを正しく反映するために、earliestDatestampフィールドを修正する必要があるかもしれない。（これは、Itemテーブルのlast_modifiedカラムの値であることに注意のこと。）
oai-web.xml: この標準的なJavaサーブレット「配備記述子」は、そのソースファイルが[dspace-source]/etc/oai-web.xmlにあり、/dspace/oai/WEB-INF/web.xmlに出力される。




    セット

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

    DSpaceはコレクションをセットとして公開します。コミュニティの構成は時間とともに変化すると思われるので、選択的ハーベスティングの対象としては安定性に欠けます。
    
    各コレクションは対応するOAIセットを持ちます。ハーベスタはListSetsコマンドを使ってこれを知ることができます。setSpecは、コレクションのハンドルですが、setSpecの規格に合うよう、":" と "/" は "_"（下線）で置き換えられています。たとえば次のようになります

hdl_1721.1_1234


  当然ですが、コレクション名は対応するセットの名前でもあります。

  ユニークな識別子

    OAI-PMHデータリポジトリの全てのアイテムは、URIシンタックスに準拠するユニークな識別子を持たなければなりません。DSpace 1.2以降は、識別子としてハンドルを使用しなくなりました。OAI-PMHでは、OAI識別子がリソースに関するメタデータレコードを識別するからです。DSpaceにおいてリソースはアイテムであり、そのリソース識別子はハンドルです。実際問題として、OAI識別子としてハンドルを使用すると、将来、複数のDSpaceシステムが同じハンドルを持つアイテムを共有する場合に問題を引き起こす可能性があります。したがって、OAIメタデータレコード識別子はハンドルとは異なる識別子であるべきです。異なるDSpaceシステムは独立にハーベストされる必要があり、異なるDSpaceシステムが同じアイテムに異なるメタデータを持つかもしれないからです。

    DSpaceが使用するOAI識別子は次の形をとります。

  oai:ホスト名:ハンドル
  
    たとえば、次のとおり。

  oai:dspace.myu.edu:123456789/345

  別のスキームを使いたい場合は、org.dspace.app.oai.DSpaceOAICatalogクラスの先頭にあるOAI_ID_PREFIXの値を編集することにより簡単に変更できます。（上のスキームでよければプログラムを変更する必要はありません。ホスト名とハンドルはプログラムがDSpaceの設定ファイルから自動的に持ってくるからです。）


    アクセスコントロール

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

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

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

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

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

    "about" 情報

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


    削除

    DSpace は、削除（取り下げ）を記録しています。
削除情報は、これを処理する特別なメカニズムを持っている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//hdl_1721_1_1234/300


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


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

    DSpaceは、DSpaceシンプルアーカイブフォーマットを使って、アイテムを一括してインポート、あるいは、エクスポートするコマンドラインツールを持っています。
このツールはそれほど堅牢ではありませんが、便利であり、変更も容易です。また、独自のアイテムインポータが必要な場合、このツールはその実装法についての良いお手本になります

    警告: テンプレートが適用される場合があります
    
    バージョン1.2ベータ2以降ではバグのため、コレクションがアイテムテンプレートを持っていると、そのデフォルト値がインポートするアイテムに追加される場合があります。これを避けたい場合は、テンプレートを削除してください。

    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つの属性を使用することができます。
     
        <element>- ダブリンコア要素
        
<qualifier>- 要素の限定子
        
<language>- 要素のISO言語コード（オプション）
     


<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>
    

    （この例では、オプションのlanguage属性により、別タイトルがフランス語で書かれていることをシステムに知らせています。）

    アイテムのインポート
    
     注: 事前にDSpaceからエクスポートしたアイテムをインポートする場合は、まず、DSpaceシステム間のアイテムの移動を参照してください。


    アイテムインポータは、org.dspace.app.itemimport.ItemImportにあり、dspace/binディレクトリにあるdsrunユーティリティを使って実行します。
 -hフラグを付けてこのユーティリティを実行すると、現在使用できるコマンドライン引数を表示します。--testフラグも重要なフラグです。このフラグは全てのコマンドに指定でき、DSpaceシステムに変更を加えることなく、そのコマンドが実行する全ての処理をシミュレートすることができます。インポートを行う前にアイテムディレクトリを検証するためにはこのフラグが非常に便利です。インポートの実行者引数（eperson引数）にはユーザのデータベースIDかメールアドレスのいずれかを、collection引数にはコレクションのデータベースIDかハンドルのいずれかを使用することができます。
現在のところ、インポータを使って、コレクションに対してアイテムを追加・削除・置換することができます。collection引数を複数指定すると、アイテムは複数のコレクションにインポートされ、最初に指定したコレクションが「オーナー」コレクションになります。エラーが発生した場合やインポータが異常終了した場合に、エラーを修正後に中断した場所からインポートを再開することができる、--resumeフラグが存在します。

あるe-personを投稿者として、コレクションにアイテムを追加するには、次のように入力します。

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 --delete --mapfile=mapfile


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

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


    マップファイルを使用して古いアイテムを置換しますが、ハンドルは変更しません。
 
    インポータは通常コレクションに割り当てられたワークフローを迂回します。
しかし、--workflow オプションを指定すると、インポートアイテムはワークフローシステムを通るようになります。
   
    インポータには、--testフラグもあり、これを指定すると、実際のインポートをすることなく全てのインポート処理をシミュレートします。これは、インポートを行う前にインポートファイルを検証するために非常に役に立ちます。

  アイテムのエクスポート

    アイテムエクスポータは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" という名前のファイルが追加されます。
このファイルには、アイテムに割り当てられたハンドルが書かれています。
このファイルをインポータに入力することにより、エクスポートされたアイテムをオリジナルのハンドルを保持したまま、別のマシンにインポートすることができます。

  DSpaceシステム間のアイテムの移動

  （たとえば、テストシステムから本番システムへの移行など）アイテムをDSpaceシステム間で移動させる場合、アイテムエクスポータとアイテムインポータを組み合わせたスクリプトを作成することで、この処理を簡単にすることができます。

  アイテムエクスポータを実行すると、dublin_core.xmlファイルにはDSpaceにより自動的にメタデータが追加されます。追加されるメタデータは次のとおりです。

  
    date.accessioned

    date.available

    date.issued

    description.provenance

    format.extent

    format.mimetype

    identifier.uri
  

  このメタデータの重複を避けるために、アイテムインポータを実行する前に次のコマンドを実行してください。

  dspace_migrate <エクスポートされたアイテムディレクトリ>

  これにより上記のメタデータがdublin_core.xmlファイルから削除され、同時にhandleファイルも全て削除されます。これで、アイテムインポータを安全に実行することができます。コマンドの使用法を知るには次のように入力してください。

  dspace_migrate --help

  登録

  登録は、DSpaceにアイテムとそのメタデータ、ビットストリームを受け入れるもう一つの方法で、DSpaceがアクセス可能なストレージに既に存在するビットストリームをうまく利用します。たとえば、既存のデジタル資産のためのリポジトリが例に挙げられるでしょう。メタデータの登録やビットストリームのアップロードに通常の対話的な受入プロセスや一括インポートを使う代わりに、登録ではDSpaceにメタデータと、ビットストリームの配置場所を提供します。DSpaceはインポートツールを使って登録を実行します。

  アクセス可能なストレージ

  アイテムを登録するには、ビットストリームがDSpaceにアクセス可能な、すなわち、dspace.cfgの情報資産格納番号で参照されるストレージに保管されている必要があります。設定ファイルdspace.cfgは整数の情報資産格納番号を使用して1つ以上の情報資産格納場所を指定します。この番号は、DSpaceのホスト上のファイルシステムのディレクトリ、あるいは1組のSRBアカウントパラメタと関連付けられています。この情報資産格納番号は、プロパティ設定ファイルdspace.cfgの解説ページ、あるいはdspace.cfgファイル自身の中で説明されています。通常の方法で受け入れられるアイテムやインポートされるアイテムと、登録されるアイテムを混在させたいとは思わないでしょうから、登録されるアイテムで使用される資産格納番号は、一般に、assetstore.incomingプロパティの値と同じにするべきではありません。

  アイテムインポータを使ったアイテムの登録

  DSpaceは、一括インポートに使用したものと同じインポートツールを使用しますが、登録をサポートするためにいくつか異なる点があります。以下の説明ではインポートツールについて熟知していることを前提とします。

  登録のためのアーカイブフォーマットは、登録される実際のコンテンツファイル（ビットストリーム）を含みません。しかし、そのフォーマットは登録するアイテムからなるディレクトリであり、アイテムごとにサブディレトリを持っています。各アイテムディレクトリは、アイテムの記述メタデータファイル（dublin_core.xml）と、アイテムのコンテンツをリストアップしたファイル（contents）を含みますが、実際のコンテンツファイル自体は持ちません。

  アイテム登録のためのdublin_core.xmlファイルは、通常のアイテムインポート用のファイルとまったく同じです。

  contentsファイルも、通常のアイテムインポートと同じく、アイテムのコンテンツファイルを1ファイル1行でリストアップしたものですが、リストの各行は次のような形式です。
  -r -s n -f filepath
-r -s n -f filepath\tbundle:bundlename


  ここで、

  
    -r は、これが登録されるファイルであることを示す
    -s n は、情報資産格納番号（n）を示す
    -f filepath は、登録されるコンテンツファイルのパスとファイル名（ファイルパス）を示す
    \t は、タブ文字である
    bundle:bundlename は、オプションのバンドル名である
  

  バンドル（ファイルパスの後ろにある全て）はオプションであり、通常は使用しません。

  登録のためのコマンドは、通常のインポートとまったく同じです。
  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


  --workflowフラグと--testフラグは、アイテムのインポートで説明した機能を持ちます。

  --deleteフラグは、アイテムのインポートで説明した機能を持ちますが、登録されたコンテンツファイルはストレージから削除されません。 登録アイテムの削除を参照してください。

  --replaceフラグは、アイテムのインポートで説明した機能を持ちますが、場合により意味合いが異なることを考慮する必要があります。旧アイテムと新アイテムが登録アイテムか、通常の受入アイテムかにより、4つの組み合わせが考えられます。最も重要なのは、--replaceを使ってDSpaceから削除された旧登録アイテムは、ストレージからは削除されないことです。下の登録アイテムの削除を参照してください。--replaceを使ってDSpaceに追加された新アイテムは、それがcontentsで-rフラグが指定されていれば登録され、指定されていなければ通常の方法で受け入れられます。

  内部的識別と登録アイテムの検索

  ひとたびアイテムが登録されれば、表面上、対話的に受け入れられたアイテムや一括インポートされたアイテムと区別はつきません。しかし、内部的にはいくつかの違いがあります。

  第1に、ランダムに生成される内部IDは使用されません。DSpaceはビットストリームのファイルパスやファイル名を管理しないからです。その代わりに、contentsファイルで指定したファイルパス名が使用されます。

  第2に、Bitstreamテーブルのstore_numberカラムは、contentsファイルで指定した情報資産格納番号を持ちます。

  第3に、Bitstreamテーブルのinternal_idカラムは、登録されたファイルパス名の前に（-R）フラグを付けたものを持ちます。たとえば、-Rfilepathです。ここで、filepathは情報資産格納番号に対応する格納場所における相対パス名です。格納場所は、DSpaceサーバ上のファイルシステムである従来型のストレージかSRBアカウントかのいずれかです。

  第4に、MD5チェックサムは、登録ファイルがローカルストレージにあればファイルを読んで計算しますが、リモートストレージ（SRB）にあれば単にファイル名で計算します。この選択は効率の問題です。SRBにある非常に多くの大きなファイルの登録には大量のネットワーク資源と時間を消費するからです。将来の選択肢として、SRBプロキシプロセスにMD5を計算させ、SRBのメタデータカタログ（MCAT）に保管する方法が考えられます。SRBはそのようなオプションを提供していますが、まだ製品リリースには含まれていません。

  登録アイテムとそのビットストリームは、意識することなく通常の受入アイテムと同じように検索することができます。

  登録アイテムのエクスポート

  登録アイテムはアイテムのエクスポートで説明した方法でエクスポートできます。その場合、エクスポートディレクトリにはビットストリームファイルの実際のコピーが出力されます。ただし、contentsファイルのコンテンツファイル行にはファイルが登録されたものであることを示すフラグが付きます。これは、エクスポータとインポータを使ってDSpaceアイテムを「往復させる」（DSpaceシステム間のアイテムの移動参照）と、エクスポートディレクトリにある登録ファイルはアップロードされ通常の方法で受け入れられるのではなく、再びDSpaceに登録されることを意味します。

  登録アイテムのMETSエクスポート

  METSエクスポートツールを使用することもできます。ただし、そこで説明されている注意書きに気をつけてください。また、リモートストレージのアイテムのMD5値は、実際は単なるファイル名によるMD5値であることにも注意してください。 

  登録アイテムの削除

  登録アイテムを対話的に、あるいはで説明した--deleteフラグや--replaceフラグを使ってDSpaceから削除した場合、アイテムはDSpaceから消えますが、登録されたコンテンツファイルは登録される前からあった場所に残されます。license.txtファイルなどの、登録されたのではなく登録処理の過程でDSpaceにより追加されたビットストリームは削除されます。


  METSツール

  実験的な（不完全な）METSエクスポートツールは、METSに基づくより標準的なフォーマットのメタデータでDSpaceアイテムをファイルシステムに出力します。

  エクスポートツール

  METSエクスポートツールは、次のようなコマンドで呼び出されます。
  [dspace]/bin/dsrun org.dspace.app.mets.METSExport --help


  このツールは、個々のアイテム、コレクションの全アイテム、DSpaceシステムの全アイテムをエクスポートできます。個々のアイテムをエクスポートするには、次のように指定します。
  
  [dspace]/bin/dsrun org.dspace.app.mets.METSExport --item [ハンドル]


  コレクションhdl:123.456/789のアイテムをエクスポートするには、次のように指定します。
  [dspace]/bin/dsrun org.dspace.app.mets.METSExport --collection hdl:123.456/789


  DSpaceの全アイテムをエクスポートするには、次のように指定します。
  
  [dspace]/bin/dsrun org.dspace.app.mets.METSExport --all


  上のいずれのコマンドにおいても、--destination [directory]フラグを使って、アイテムをエクスポートするベースディレクトリを指定することができます。この引数を省略すると、カレントディレクトリが使用されます。

  AIPフォーマット

  エクスポートアイテムは、コマンドライン引数で指定したベースディレクトリ、これが省略された場合はカレントディレクトリの下に、アイテムごとに別ディレクトリに出力されます。各ディレクトリの名前はハンドルですが、「正当な」ディレクトリ名にするためにURLエンコードされています。

  各アイテムディレクトリには、アイテムのMETS形式のメタデータであるmets.xmlファイルがあります。アイテムのビットストリームも同じディレクトリに格納されます。ビットストリームのファイル名はMD5チェックサムです。その第1の理由は簡単にインテグリティを検査できることであり、もう1つの理由は、ファイルがもともとあったファイルシステムでは正当だがサーバのファイルシステムでは不正となるファイル名に含まれる「特殊文字」の問題を避けるためです。mets.xmlファイルにはこれらのビットストリームファイルへのXLinkポインターが含まれています。

  AIPの例は、以下のとおりです。

  
    
      hdl%3A123456789%2F8/

      
        mets.xml -- METSメタデータ

        184BE84F293342 -- ビットストリーム

        3F9AD0389CB821

        135FB82113C32D
      
    
  

  mets.xmlファイルにおけるMETSの内容は次のとおりです。

  
    
      dmdSec（記述メタデータ部）。メタデータオブジェクト記述スキーマ（MODS) XMLで書かれたアイテムのメタデータを含む。ダブリンコア記述メタデータはMODSにマッピングされている。これは、限定子付きダブリンコアのための正式なXMLスキーマが存在しないことと、DSpaceが使用しているDCのための図書館応用プロファイルがDCMIメタデータ用語にない限定子を使用していることによる。
    

    
      amdSec（管理メタデータ部）。権利関係のメタデータ要素を含む。これは、base64エンコードを施したデポジットライセンス（投稿者が投稿時に承諾したライセンス）である。
    

    
      fileSec。アイテムのビットストリームのリストを含む。各バンドルはfileGrpを構成する。各ビットストリームはfile要素で表され、この要素にはmets.xmlファイルと同じディレクトリにあるビットストリームへの簡単なXLinkを持つFLocat要素が含まれている。file要素の属性は、ビットストリームに関する基本的な技術メタデータで構成されている。さらに、アイテムのビットストリームから抽出したサムネイルやテキストなどの「生成された」ビットストリームは、抽出元のビットストリームと同じGROUPIDを持つ。これによりクライアントは両者に関係があることを知ることができる

      各file要素のOWNERID属性は、DSpaceにより付与された「永続的」ビットストリーム識別子である。ID属性とGROUPID属性はアイテムのハンドルとビットストリームの順序IDからなるが、ドットとスラッシュは下線に置き換えられている。たとえば、ハンドルがhdl:123.456/789であるアイテムの順序IDが24のビットストリームのID属性は、123_456_789_24になる。これは、ID属性とGROUPID属性は、xsd:id型でなければならないからである。
    
  

  制限事項

  
    今のところ、対応するインポートツールは存在しない

    structmap部はない

    出力されない技術メタデータもある。たとえば、バンドルの主となるビットストリームやオリジナルのファイル名、記述など

    出力されるのはMIMEタイプだけであり、（より粒度の高い）ビットストリームフォーマットは出力されない

    ダブリンコアのMODSへのマッピングはきわめて簡単なものであり、おそらく検証を必要とする
  

  メディアフィルター: DSpaceコンテンツの変換

  DSpaceはコンテンツ（ビットストリーム）にフィルターを適用して、新しいコンテンツを作成することができます。全文検索のためにテキストを抽出するフィルターと画像を含むアイテムのサムネイルを作成するフィルターが存在します。メディアフィルターは、情報資産格納場所を調べて、ビットストリームに対応するMediaFilterサブクラスを呼び出すMediaFilterManagerにより制御されています。config/mediafilter.cfgファイルには、ビットストリームフォーマットタイプとそのタイプのビットストリームを処理するフィルターのリストが含まれています。メディアフィルターシステムはコマンドラインで（あるいはcronタスクとして定期的に）実行されることを想定しています。
  
  dspace/bin/filter-media


  フラグなしで実行すると、情報資産格納場所を走査してビットストリームにメディアフィルターを適用しますが、すでにフィルターを行ったことのあるビットストリームは飛ばされます。
  
  dspace/bin/filter-media -f


  -f フラグを付けて実行すると、すでにフィルターが行われたことのあるビットストリームも含めて、全てのビットストリームにフィルターが適用されます。
  
  dspace/bin/filter-media -v


  -v フラグを付けて実行すると、冗長モードになり、抽出されたテキストとフィルター処理の詳細が標準出力（STDOUT）に出力されます。
  
  dspace/bin/filter-media -n


  -n フラグを付けて実行すると、インデックスの作成を行いません。デフォルトでは、全文検索のための検索インデックスが新規に作成されます。他でindex-allコマンドを実行する予定がある場合は、このオプションでインデックスの作成を抑制します。

  独自フィルターの追加は、MediaFilterのサブクラスを作成することで実現できます。詳しくは、ソースファイル MediaFilter.java のコメントを参照してください。フィルターは理論上、任意の言語（C、Perlなど）で実装することができます。作成するMediaFilterクラスの中にあるJavaコードにより呼び出される必要があるだけです。

  サブコミュニティの管理

  DSpaceはコミュニティのサブ構造を管理するための管理ツール "CommunityFiliator" を提供しています。通常、この構造はめったに変わりません。しかし、1.2より前のバージョンではサブコミュニティがサポートされていなかったので、このツールを使って、バージョン1.2より前の既存のコミュニティに階層性を与えることができます。このツールには2つの操作があります。1つはコミュニティとサブコミュニティの関係を設定するもので、もう1つは既存の関係を解除するものです。

  よく知られている親/子のたとえを使って動作原理を説明することができます。DSpaceの各コミュニティは、少なくとも1つ以上のサブコミュニティを持つ「親」コミュニティか他のコミュニティのサブコミュニティである「子」コミュニティのどちらか、その両方、どちらでもないのいずれかです。この言葉を使うと、「孤児」は（親であるかもしれないが）親を持たないコミュニティです。「孤児」コミュニティは「上位」に親コミュニティを持たないので、DSpaceユーザインターフェースにおける「最上位」コミュニティとみなすことができます。親子関係を設定する第1の操作は、任意のコミュニティと孤児コミュニティとの間で行うことになります。また、親子関係を解除する第2の操作は子コミュニティを孤児にすることになります。

  dspace/binディレクトリにあるdsrunコマンドを使って、親子の設定は次のように行うことができます。
  
  dsrun org.dspace.administer.CommunityFiliator --set --parent=parentID --child=childID


  （短縮版も使用できます）
  
  dsrun org.dspace.administer.CommunityFiliator -s -p parentID -c childID


  ここで、 -s あるいは --set 引数は、-p 引数で指定されるコミュニティが、-c 引数で指定されるコミュニティの親になるという関係を設定することを意味します。"parentID" と "childID" の値はどちらも、ハンドルかデータベースIDのいずれかです。

  設定の解除は次のように実行します。
  dsrun org.dspace.administer.CommunityFiliator --remove --parent=parentID --child=childID


  （短縮版も使用できます）
  dsrun org.dspace.administer.CommunityFiliator -r -p parentID -c childID


  ここで、-r あるいは --remove 引数は、"parentID" で指定されるコミュニティが、"childID" で指定されるコミュニティの親であるという現在の関係を解除することを意味します。その結果、"childID" コミュニティは孤児、すなわち、最上位コミュニティになります。

  指定した操作が不正な場合は、問題を説明するエラーメッセージが示され、変更は行われません。たとえば、解除操作において、指定した子コミュニティが指定した親コミュニティを持たない場合は、「Error, child community not a child of parent community（エラー、子コミュニティは親コミュニティの子ではありません）」というエラーが発生します。

  基本的な操作を組み合わせることにより、コミュニティの上下関係に任意の変更を加えることができます。たとえば、子コミュニティの親をあるコミュニティから別のコミュニティに移動するには、現在の親を「解除」し（子は孤児になる）、続いて、新しい親を「設定」するだけです。

  任意の操作を行うと、子コミュニティのサブ構造の全てがそれに従うことを理解することが重要です。つまり、子が自身の子（サブコミュニティ）、あるいはコレクションを持つ場合は、それらはすべて一緒にコミュニティツリー上の新しい「位置」に移動することになります。

  

  
    Copyright © 2002-2005 MIT and Hewlett Packard