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

Back to contents
目次に戻る

Back to architecture overview
アーキテクチャ概要に戻る

Web User Interface
Webユーザインターフェース

The DSpace Web UI is the largest and most-used component in the application layer. Built on Java Servlet and JavaServer Page technology, it allows end-users to access DSpace over the Web via their Web browsers. As of Dspace 1.3.2 the UI meets both XHTML 1.0 standards and Web Accessibility Initiative (WAI) level-2 standard.
DSpace Webユーザインターフェース（Web UI）は、アプリケーション層でもっとも大規模かつ利用頻度の高いコンポーネントです。 JavaサーブレットとJavaServer Pageテクノロジーを使って構築されているので、エンドユーザはWebブラウザを使ってDSpaceにアクセスすることができます。 DSpace 1.3.2から、ユーザインターフェースはXHMTL 1.0規格およびWeb Accessibility Initiative（WAI）のレベル2の基準を満たしています。

It also features an administration section, consisting of pages intended for use by central administrators. Presently, this part of the Web UI is not particularly sophisticated; users of the administration section need to know what they are doing! Selected parts of this may also be used by collection administrators.
管理者の使用を想定したページで構成されている管理用のUIも用意されています。ただし、このWeb UIは、現在のところ、あまり洗練されていません。それゆえ、管理用UIのユーザは自分のしていることを知っている必要があります。このUIの一部はコレクションの管理者にも使用することができます。

Web UI Files
Web UIに関するファイル

The Web UI-related files are located in a variety of directories in the DSpace source tree. Note that as of DSpace version 1.2, the deployment mechanism has changed; the build process creates easy-to-deploy Web application archives (.war files).
Web UIに関するファイルは、DSpaceソースツリーの様々なディレクトリに置かれています。DSpaceバージョン1.2から配備の方法が変更されたことに注意してください。ビルトプロセスは配備が容易なWebアプリケーションアーカイブ（.warファイル）を作成します。

Locations of Web UI Source Files
Web UIソースファイルの配置場所
Location
配置場所		 Description
説明
org.dspace.app.webui Web UI source files
Web UIのソースファイル
org.dspace.app.webui.filter Servlet Filters (Servlet 2.3 spec)
サーブレットフィルター（Servlet 2.3仕様）
org.dspace.app.webui.jsptag Custom JSP tag class files
JSPカスタムタグクラスファイル
org.dspace.app.webui.servlet Servlets for main Web UI (controllers)
主たるWeb UIのサーブレット（コントローラ）
org.dspace.app.webui.servlet.admin Servlets that comprise the administration part of the Web UI
管理用Web UIを構成するサーブレット
org.dspace.app.webui.util Miscellaneous classes used by the servlets and filters
サーブレットとフィルターで使用される様々なクラス
[dspace-source]/jsp The JSP files
JSPファイル
[dspace-source]/jsp/local This is where you can place customized versions of JSPs -- see the configuration section
カスタマイズしたJSPファイルを置く場所。設定とカスタマイズを参照のこと。
[dspace-source]/jsp/WEB-INF/dspace-tags.tld Custom DSpace JSP tag descriptor
DSpace用Javaカスタムタグ記述子
[dspace-source]/etc/dspace-web.xml The Web application deployment descriptor. Before including in the .war file, the text @@dspace.dir@@ will be replaced with the DSpace installation directory (referred to as [dspace] elsewhere in this system documentation). This allows the Web application to pick up the DSpace configuration and environment.
Webアプリケーション配置記述子。.warファイルにインクルードされる前に、テキスト@@dspace.dir@@はDSpaceのインストールディレクトリ（この文書では[dspace]で示されている）に置き換えられる。このファイルによりWebアプリケーションはDSpaceの設定と環境を知ることができる。

The Build Process
ビルドプロセス

The DSpace build process constructs a Web application archive, which is placed in [dspace-source]/build/dspace.war. The build_wars Ant target does the work. The process works as follows:
DSpaceのビルドプロセスによりWebアプリケーションアーカイブが作成され、[dspace-source]/build/dspace.warに置かれる。この処理は、Antのbuild_warsターゲットにより、次のように実行される。

The contents of dspace.war are:
dspace.war の内容は次の通りです。

Note that this does mean there are multiple copies of the compiled DSpace code and third-party libraries in the system, so care must be taken to ensure that they are all in sync. (The storage overhead is a few megabytes, totally insignificant these days.) In general, when you change any DSpace code or JSP, it's best to do a complete update of both the installation ([dspace]), and to rebuild and redeploy the Web UI and OAI .war files, by running this in [dspace-source]:
これから分かるように、システムにはコンパイルされたDSpaceプログラムやサードパーティ製ライブラリのコピーが複数存在します。したがって、これらすべてが常に同期するよう注意する必要があります（これに伴うストレージ上のオーバーヘッドは数メガバイトであり、今日ではまったく無視できる大きさです）。一般に、DSpaceのプログラムやJSPを変更した際には、[dspace-source]で以下のコマンドを実行して、インストールディレクトリ（[dspace]）の全面的更新と、Web UIおよびOAIの.warファイルの再構築と再配備を行うことがベストです。 

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

and then following the instructions that command writes to the console.
実行後は、コンソールに現れる指示に従ってください。

Servlets and JSPs
サーブレットとJSP

The Web UI is loosely based around the MVC (model, view, controller) model. The content management API corresponds to the model, the Java Servlets are the controllers, and the JSPs are the views. Interactions take the following basic form:
Web UIはおおよそMVC（モデル、ビュー、コントローラ）モデルに基づいています。コンテンツ管理APIがモデルに、Javaサーブレットがコントローラに、JSPがビューに、それぞれ相当します。相互の関係は次の基本的な形をとります。

  1. An HTTP request is received from a browser
    ブラウザからHTTPリクエストを受け取る
  2. The appropriate servlet is invoked, and processes the request by invoking the DSpace business logic layer public API
    適当なサーブレットが呼び出され、サーブレットはビジネスロジック層の公開APIを呼び出してリクエストを処理する
  3. Depending on the outcome of the processing, the servlet invokes the appropriate JSP
    処理結果に基づいて、サーブレットは適当なJSPを呼び出す
  4. The JSP is processed and sent to the browser
    JSPが処理され、ブラウザに送信する

The reasons for this approach are:
このアプローチは次の理由で採用しました。

The org.dspace.app.webui.servlet.LoadDSpaceConfig servlet is always loaded first. This is a very simple servlet that checks the dspace-config context parameter from the DSpace deployment descriptor, and uses it to locate dspace.cfg. It also loads up the Log4j configuration. It's important that this servlet is loaded first, since if another servlet is loaded up, it will cause the system to try and load DSpace and Log4j configurations, neither of which would be found.
org.dspace.app.webui.servlet.LoadDSpaceConfigサーブレットが常に最初にロードされます。これは非常に簡単なサーブレットであり、DSpace配備記述子のdspace-configコンテキストパラメタをチェックし、dspace.cfgを見つけます。 さらに、Log4j設定ファイルをロードします。このサーブレットが最初にロードされることは重要です。そうでないと、他のサーブレットがロードされた場合、システムはDSpaceとLog4jの設定ファイルをロードしようと試みますが、どちらも見つけることができないからです。

All DSpace servlets are subclasses of the DSpaceServlet class. The DSpaceServlet class handles some basic operations such as creating a DSpace Context object (opening a database connection etc.), authentication and error handling. Instead of overriding the doGet and doPost methods as one normally would for a servlet, DSpace servlets implement doDSGet or doDSPost which have an extra context parameter, and allow the servlet to throw various exceptions that can be handled in a standard way.
すべてのDSpaceサーブレットは、DSpaceServletクラスのサブクラスです。 DSpaceServletクラスは、DSpaceのContextオブジェクトの作成（データベースコネクションのオープンなど）や、ユーザ認証、エラー処理などの基本的な操作を担当します。通常のサーブレットのようにdoGet メソッドとdoPostメソッドをオーバライドするのではなく、DSpaceサーブレットではdoDSGetメソッドとdoDSPostメソッドを実装しています。これらのメソッドは、コンテキストオブジェクトを追加パラメタとして持ち、かつ、標準的な方法で扱うことのできる様々な例外をサーブレットが投げられるようにしています。

The DSpace servlet processes the contents of the HTTP request. This might involve retrieving the results of a search with a query term, accessing the current user's eperson record, or updating a submission in progress. According to the results of this processing, the servlet must decide which JSP should be displayed. The servlet then fills out the appropriate attributes in the HttpRequest object that represents the HTTP request being processed. This is done by invoking the setAttribute method of the javax.servlet.http.HttpServletRequest object that is passed into the servlet from Tomcat. The servlet then forwards control of the request to the appropriate JSP using the JSPManager.showJSP method.
DSpaceサーブレットは、HTTPリクエストの要求を処理します。その要求には、クエリ条件を指定した検索結果の取り込みや、カレントユーザのEpersonレコードのアクセス、処理中の投稿の更新などがあります。この処理の結果に基づいて、サーブレットはどのJSPを表示するべきかを決定しなければなりません。次に、サーブレットは処理したHTTPリクエストを表すHttpRequestオブジェクトに適当な属性を設定します。これは、Tomacatからサーブレットに渡されるjavax.servlet.http.HttpServletRequestオブジェクトの setAttributeメソッドを呼び出すことで実行されます。サーブレットは次に、JSPManager.showJSPメソッドを使って、適当なJSPにリクエストの制御を渡します。

The JSPManager.showJSP method uses the standard Java servlet forwarding mechanism is then used to forward the HTTP request to the JSP. The JSP is processed by Tomcat and the results sent back to the user's browser.
JSPManager.showJSPメソッドは標準的なJavaサーブレット転送メカニズムを使って、HTTPリクエストをJSPに転送します。 JSPはTomcatにより処理され、結果をユーザのブラウザに返します。

There is an exception to this servlet/JSP style: index.jsp, the 'home page', receives the HTTP request directly from Tomcat without a servlet being invoked first. This is because in the servlet 2.3 specification, there is no way to map a servlet to handle only requests made to '/'; such a mapping results in every request being directed to that servlet. By default, Tomcat forwards requests to '/' to index.jsp. To try and make things as clean as possible, index.jsp contains some simple code that would normally go in a servlet, and then forwards to home.jsp using the JSPManager.showJSP method. This means localized versions of the 'home page' can be created by placing a customized home.jsp in [dspace-source]/jsp/local, in the same manner as other JSPs.
このサーブレット/JSP方式には例外が存在します。「ホームページ」であるindex.jspは、最初にサーブレットが呼び出されることなく、Tomcatから直接HTTPリクエストを受け取ります。これは、サーブレット2.3の仕様では、単なる'/'というリクエストに対する処理にサーブレットをマッピングする方法がないからです。通常は、そのようなマッピングによりすべてのリクエストはサーブレットに渡されています。 Tomcatはデフォルトでは'/'へのリクエストをindex.jspに転送します。そこで、処理をできるだけ簡潔にするために、index.jspに通常はサーブレットで処理される簡単なプログラムを持たせ、JSPManager.showJSP メソッドを使ってhome.jspにリクエストを転送しています。これは、カスタマイズしたhome.jspを他のJSPファイルと同じように[dspace-source]/jsp/localに置くことで、のローカライズ版の「ホームページ」を作成することができることを意味しています。

[dspace-source]/jsp/dspace-admin/index.jsp, the administration UI index page, is invoked directly by Tomcat and not through a servlet for similar reasons.
管理用UIのホームページである[dspace-source]/jsp/dspace-admin/index.jspも同じ理由で、サーブレットを介さずTomcatにより直接呼び出されます。

At the top of each JSP file, right after the license and copyright header, is documented the appropriate attributes that a servlet must fill out prior to forwarding to that JSP. No validation is performed; if the servlet does not fill out the necessary attributes, it is likely that an internal server error will occur.
各JSPファイルの先頭のライセンスとコピーライトヘッダの直後に、JSPに転送する前にサーブレットが設定しなければならない属性が記載されています。システムではこれを検証しませんので、サーブレットが必要な属性を設定しない場合は、サーバ内部エラーが発生することになります。

Many JSPs containing forms will include hidden parameters that tell the servlets which form has been filled out. The submission UI servlet (SubmissionController is a prime example of a servlet that deals with the input from many different JSPs. The step and page hidden parameters (written out by the SubmissionController.getSubmissionParameters() method) are used to inform the servlet which page of which step has just been filled out (i.e. which page of the submission the user has just completed).
入力フォームを持つJSPの多くは、どのフォームに入力があったのかをサーブレットに知らせる隠されたパラメータを持っています。投稿ユーザーインターフェースのサーブレット（SubmissionController）は、多くの異なるJSPからの入力を処理するサーブレットの最良の例です。隠されたパラメータであるステップとページはどのステップのどのページが設定されているのかという情報(ユーザーが投稿のどの段階まで終了しているか)をサーブレットに知らせるために使用されています。

Below is a detailed, scary diagram depicting the flow of control during the whole process of processing and responding to an HTTP request. More information about the authentication mechanism is mostly described in the configuration section.
下の図は、HTTPリクエストに対する処理と応答の全プロセスにおける制御の流れを示した詳細な見るも恐ろしい図です。ユーザ認証機構の詳細については、ほとんど設定とカスタマイズで説明されています。

Web UI Control Flow

Flow of Control During HTTP Request Processing
HTTPリクエスト処理中の制御の流れ<

Custom JSP Tags
JSPカスタムタグ

The DSpace JSPs all use some custom tags defined in /dspace/jsp/WEB-INF/dspace-tags.tld, and the corresponding Java classes reside in org.dspace.app.webui.jsptag. The tags are listed below. The dspace-tags.tld file contains detailed comments about how to use the tags, so that information is not repeated here.
DSpaceのすべてのJSPは、/dspace/jsp/WEB-INF/dspace-tags.tldで定義されているカスタムタグを使用しています。このカスタムタグに対応するJavaクラスはorg.dspace.app.webui.jsptagにあります。使用されているタグを以下にリストアップしました。タグの使用法については、dspace-tags.tldファイルに詳細な記述がありますので、ここでは繰り返しません。

layout

Just about every JSP uses this tag. It produces the standard HTML header and <BODY>tag. Thus the content of each JSP is nested inside a <dspace:layout> tag. The (XML-style)attributes of this tag are slightly complicated--see dspace-tags.tld. The JSPs in the source code bundle also provide plenty of examples.
ほとんどすべてのJSPは、このタグを使用している。このタグは標準的なHTMLヘッダと<BODY>タグを生成する。従って、JSPの内容は、 <dspace:layout>タグの中に置かれる。このタグの（XMLスタイルの）属性は少し複雑である。dspace-tags.tldを参照のこと。ソースコードツリーに含まれているJSPファイルも多くの例を提供している。

sidebar

Can only be used inside a layout tag, and can only be used once per JSP. The content between the start and end sidebar tags is rendered in a column on the right-hand side of the HTML page. The contents can contain further JSP tags and Java 'scriptlets'.
layoutタグの内部でのみ使用可能で、また、各JSPで使用できるのは1回だけである。 sidebarの開始タグと終了タグの間の内容は、HTMLページの右側のカラムに表示される。内容には、JSPタグやJava「スクリプトレット」を含めることができる。

date

Displays the date represented by an org.dspace.content.DCDate object. Just the one representation of date is rendered currently, but this could use the user's browser preferences to display a localized date in the future.
org.dspace.content.DCDateオブジェクトで表される日付を表示する。現在のところ、日付形式は1種類だけである。将来は、ユーザのブラウザの設定を使ってローカライズされた日付を表示できるようになるかもしれない。

include

Obsolete, simple tag, similar to jsp:include. In versions prior to DSpace 1.2, this tag would use the locally modified version of a JSP if one was installed in jsp/local. As of 1.2, the build process now performs this function, however this tag is left in for backwards compatibility.
非推奨の簡単なタグで、jsp:includeに相当する。DSpace 1.2より前のバージョンでは、このタグによりjps/localに置かれたローカル修正版のJSPを使用していた。バージョン1.2以降は、ビルドプロセスがこの機能を果している。しかし、このタグは後方互換性のために残されている。

item

Displays an item record, including Dublin Core metadata and links to the bitstreams within it. Note that the displaying of the bitstream links is simplistic, and does not take into account any of the bundling structure. This is because DSpace does not have a fully-fledged dissemination architectural piece yet.
アイテムレコードを表示する。表示にはダブリンコアメタデータとビットストリームへのリンクが含まれる。ビットストリームリンクの表示はきわめて簡略なものであり、バンドル構造は考慮されていないことに注意すること。これは、DSpaceが完全な発信用コンポーネントをまだ持っていないからである。

Displaying an item record is done by a tag rather than a JSP for two reasons: Firstly, it happens in several places (when verifying an item record during submission or workflow review, as well as during standard item accesses), and secondly, displaying the item turns out to be mostly code-work rather than HTML anyway. Of course, the disadvantage of doing it this way is that it is slightly harder to customize exactly what is displayed from an item record; it is necessary to edit the tag code (org.dspace.app.webui.jsptag.ItemTag). Hopefully a better solution can be found in the future.
アイテムレコードの表示をJSPではなくタグで行っているのには、2つの理由がある。第1の理由は、アイテムの表示は数箇所（標準的なアイテムのアクセス時だけでなく、投稿やワークフロー査読の途中でアイテムレコードを確認する時）で行われるからである。第2の理由は、アイテムの表示は結局、HTMLというよりほとんどプログラムの仕事になるからである。この方法をとる欠点は、もちろん、アイテムレコードの表示を正しくカスタマイズすることが若干難しくなることである。タグ用のプログラム（org.dspace.app.webui.jsptag.ItemTag）を編集する必要があるからである。将来もっとよいソルーションが見つかることを期待している。

itemlist, collectionlist, communitylist

These tags display ordered sequences of items, collections and communities, showing minimal information but including a link to the page containing full details. These need to be used in HTML tables.
これらのタグは、ソート済のアイテム、コレクション、コミュニティのリストを表示する。表示される情報は非常に限られているが、すべての情報を表示するページへのリンクが含まれている。これらのタグはHTMLのtable要素の中で使用する必要がある。

popup

This tag is used to render a link to a pop-up page (typically a help page.) If Javascript is available, the link will either open or pop to the front any existing DSpace pop-up window. If Javascript is not available, a standard HTML link is displayed that renders the link destination in a window named 'dspace.popup'. In graphical browsers, this usually opens a new window or re-uses an existing window of that name, but if a window is re-used it is not 'raised' which might confuse the user. In text browsers, following this link will simply replace the current page with the destination of the link. This obviously means that Javascript offers the best functionality, but other browsers are still supported.
このタグは、ポップアップページ（たとえばヘルプページなど）へのリンクを処理するために使用される。 Javascriptが利用できる場合は、リンクをクリックするとポップアップページがオープンされるか、既存のDSpaceポップアップウィンドウが最前面に表示される。Javascriptが利用できない場合は、標準的なHTMLリンクが表示され、このリンクをクリックすると、'dspace.popup' という名前のウィンドウにリンク先を表示する。グラフィカルブラウザでは、これは一般に新しいウィンドウを開くか、その名前を持つ既存のウィンドウを再利用することになる。ただし、ウィンドウが再利用される場合、そのウィンドウは最前面に表示されないので、ユーザに混乱を与えるかもしれない。テキストブラウザでは、このリンクをクリックすると、単にリンク先の内容で現在のページを置き換えるだけである。つまり、このタグはJavascriptが利用できると最高の機能を提供するが、その他のブラウザもサポートしていることを意味している。

selecteperson

A tag which produces a widget analogous to HTML <SELECT>, that allows a user to select one or multiple e-people from a pop-up list.
このタグは、HTMLの<SELECT>相当のウィジェットを生成し、ポップアップリストから1人あるいは複数のe-personをユーザが選択できるようにする。

sfxlink

Using an item's Dublin Core metadata DSpace can display an SFX link, if an SFX server is available. This tag does so for a particular item if the sfx.server.url property is defined in dspace.cfg.
SFXサーバが利用できると、DSpaceはアイテムのダブリンコアメタデータを使ってSFXリンクを表示することができる。 dspace.cfgでsfx.server.url プロパティが定義されていると、このタグを特定のアイテムに機能させることができる。

Internationalisation
国際化

The Java Standard Tag Library v1.0 is used to specify messages in the JSPs like this:
Java Standard Tag Library v1.0を使って、次のように、JSP中のメッセージを指定する。

OLD:
古い方法：

<H1>Search Results</H1>


<H1>検索結果</H1>

NEW:
新しい方法：

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

This message can now be changed using the config/language-packs/Messages.properties file. (This must be done at build-time: Messages.properties is placed in the dspace.war Web application file.)
このメッセージはconfig/language-packs/Messages.propertiesファイルを使って変更することができる（ただし、システム構築時に行う必要がある。Messages.propertiesはdspace.warWebアプリケーションファイルに入れられる）。

jsp.search.results.title = Search Results

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

Phrases may have parameters to be passed in, to make the job of translating easier, reduce the number of 'keys' and to allow translators to make the translated text flow more appropriately for the target language.
翻訳作業を簡単にするために、数字の「キー」で渡されるパラメタをフレーズは持つことができ、これを使って対象となる言語によりふさわしい流れでテキストを翻訳することができます。

OLD:
古い方法：

<P>Results <%= r.getFirst() %> to <%= r.getLast() %> of <%= r.getTotal() %></P>

<P>結果 <%= r.getFirst() %> to <%= r.getLast() %> of <%= r.getTotal() %></P>

NEW:
新しい方法

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

(Note: JSTL 1.0 does not seem to allow JSP <%= %> expressions to be passed in as values of attribute in <fmt:param value=""/>)
（注: JSTL 1.0 は、 <fmt:param value=""/>の属性値としてJSPの<%= %>式を渡せないようです）

The above would appear in the Messages_xx.properties file as:
上の例は、Messages_xx.propertiesファイルでは、たとえば次のように記述されています。

jsp.search.results.text = Results {0}-{1} of {2}

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

Introducing number parameters that should be formatted according to the locale used makes no difference in the message key compared to atring parameters:
使用するロケールに従ってフォーマットされるよう導入された数値パラメタは、メッセージキーにおいては、文字列パラメタと違いはありません。

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

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

In the JSP using this key can be used in the way belov:
JSPではこのキーを次のように使用します。

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

(Note: JSTL offers a way to include numbers in the message keys as jsp.foo.key = {0,number} bytes. Setting the parameter as <fmt:param value="${variable}" /> workes when variable is a single variable name and doesn't work when trying to use a method's return value instead: bitstream.getSize(). Passing the number as string (or using the <%= %> expression) also does not work.)
（注: JSTL は、jsp.foo.key = {0,number} バイトという形で数値をメッセージキーに含める方法を提供しています。<fmt:param value="${variable}" />としてパラメタを設定することは、variableが変数名であれば動きますが、代わりにメソッドの戻り値: bitstream.getSize()を使おうとすると動きません。数値を文字列として渡しても（あるいは<%= %>式を使っても）動きません。

Multiple Messages.properties can be created for different languages. See ResourceBundle.getBundle. e.g. you can add German and Canadian French translations:
言語ごとに複数のMessages.propertiesを作成することができます。ResourceBundle.getBundleを参照してください。たとえば、ドイツ語とカナダのフランス語の翻訳を次のように追加することができます。

Messages_de.properties
Messages_fr_CA.properties

The end user's browser settings determine which language is used. The English language file Messages.properties (or the default server locale) will be used as a default if there's no language bundle for the end user's preferred language. (Note that the English file is not called Messages_en.properties -- this is so it is always available as a default, regardless of server configuration.)
どの言語が使用されるかは、エンドユーザのブラウズの設定により決められます。エンドユーザが望む言語のメッセージファイルがない場合は、英語のメッセージファイル Messages.properties（あるいは、サーバのデフォルトロケールのメッセージファイル）がデフォルトとして使用されます。（英語のメッセージファイルはMessages_en.propertiesではないことに注意してください。これは、サーバの設定にかかわらず、常にデフォルトとして使用できるようにするためです。）

The dspace:layout tag has been updated to allow dictionary keys to be passed in for the titles. It now has two new parameters: titlekey and parenttitlekey. So where before you'd do:
dspace:layoutタグは、辞書キーをタイトル に渡せるように変更されました。現在は、titlekeyとparenttitlekeyの2つのパラメタを持っています。従って、以前に次のようにしていたところは、

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

You now do:
以下のように修正してください。

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

And so the layout tag itself gets the relevant stuff out of the dictionary. title and parenttitle still work as before for backwards compatibility, and the odd spot where that's preferable.
こうすることで、layoutタグは辞書から関連するテキストを得ます。なお、titleとparenttitleも、こちらの方がふさわしい普通でない場所で使用するため、および後方互換性のために以前と同じように機能します。

Message Key Convention
メッセージキーの命名規約

When translating further pages, please follow the convention for naming message keys to avoid clashes.
他のページを翻訳する際には、名前の衝突を避けるためにメッセージキーの名前については以下の命名規約に従ってください。

For text in JSPs use the complete path + filename of the JSP, then a one-word name for the message. e.g. for the title of jsp/mydspace/main.jsp use:
JSP中のテキストには、「JSPのフルパス+ファイル名+1語のメッセージ名」を使ってください。たとえば、jsp/mydspace/main.jspのタイトルには、次の名前を使います。

jsp.mydspace.main.title

Some common words (e.g. "Help") can be brought out into keys starting jsp. for ease of translation, e.g.:
いくつの一般的な単語（"Help" など）は翻訳を簡単にするために、次のように、jsp.で始まるキーにくくり出すことができます。

jsp.admin = Administer

jsp.admin = 管理者

Other common words/phrases are brought out into 'general' parameters if they relate to a set (directory) of JSPs, e.g.
また、一般的な単語/フレーズが一連の（同一のディレクトリの）JSPに関連している場合は、次のように、"general" パラメタにくくり出します。

jsp.tools.general.delete = Delete

jsp.tools.general.delete = 消去

Phrases that relate strongly to a topic (eg. MyDSpace) but used in many JSPs outside the particular directory are more convenient to be cross-referenced. For example one could use the key below in jsp/submit/saved.jsp to provide a link back to the user's MyDSpace:
あるトピック（MyDSpaceなど）に密接にに関係しているが、特定のディレクトリ以外の多くのJSPで使われているフレーズは、キーを共有するとより便利です。たとえば、下記のキーをjsp/submit/saved.jspに使用して、ユーザのMyDSpaceに戻るリンクを提供することができるでしょう。

(Cross-referencing of keys in general is not a good idea as it may make maintenance more difficult. But in some cases it has more advantages as the meaning is obvious.)
（キーの共有はメンテナンスを難しくするので一般的には良い考えではありませんが、意味が明らかであれば利点の方が大きくなります。）

jsp.mydspace.general.goto-mydspace = Go to My DSpace

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

For text in servlet code, in custom JSP tags or wherever applicable use the fully qualified classname + a one-word name for the message. e.g.
サーブレットプログラム中のテキストには、JSPカスタムタグなど適用できるところはどこでも、「クラスの完全修飾名+1語のメッセージ名」を使用してください。たとえば、次のとおり。

org.dspace.app.webui.jsptag.ItemListTag.title = Title

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

Which Languages are currently supported?
現在サポートされている言語

To view translations currently being developed, please refer to the i18n page of the DSpace Wiki.
既に翻訳されているメッセージファイルは、DSpace Wikiのi18nサポートページを参照してください。

HTML Content in Items
アイテムのHTMLコンテンツ

For the most part, the DSpace item display just gives a link that allows an end-user to download a bitstream. However, if a bundle has a primary bitstream whose format is of MIME type text/html, instead a link to the HTML servlet is given.
通常、DSpaceのアイテム表示にはエンドユーザがビットストリームをダウンロードするためのリンクが表示されるだけです。しかし、バンドルの主たるビットストリームのフォーマットがMIMEタイプ text/html である場合は、HTMLサーブレットへのリンクが代わりに表示されます。

So if we had an HTML document like this:
次のようなHTML文書があるとします。

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

The Bundle's primary bitstream field would point to the contents.html Bitstream, which we know is HTML (check the format MIME type) and so we know which to serve up first.
バンドルの主たるビットストリームフィールドが contents.html ビットストリームを指しているとすると、（フォーマットのMIMEタイプを調べることで）それがHTMLだということが分かり、どのファイルを最初に提供すべきが分かります。

The HTML servlet employs a trick to serve up HTML documents without actually modifying the HTML or other files themselves. Say someone is looking at contents.html from the above example, the URL in their browser will look like this:
HTMLサーブレットはトリックを使って、HTMLファイルやその他のファイルそのものを実際に変更することなくHTML文書を提供します。 たとえば、上の例で、誰かがcontents.htmlを見ているとします。その人のブラウザには次のようなURLが見えるでしょう。

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

If there's an image called figure1.gif in that HTML page, the browser will do HTTP GET on this URL:
HTMLページにfigure1.gifという画像があった場合、ブラウザは次のURLに対してHTTPのGETリクエストを送ります。

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

The HTML document servlet can work out which item the user is looking at, and then which Bitstream in it is called figure1.gif, and serve up that bitstream. Similar for following links to other HTML pages. Of course all the links and image references have to be relative and not absolute.
HTMLドキュメントサーブレットは、まずユーザが今どのアイテムを見ているかを調べ、続いて、その中のどのビットストリームがfigure1.gifと呼ばれているかを調べます。その結果、該当するビットストリームを提供することができます。他のHTMLページへのリンクをたどる方法も同じです。もちろん、全てのリンクや画像への参照は相対である必要があり、絶対参照ではあってはいけません。

HTML documents must be "self-contained", as explained here. Provided that full path information is known by DSpace, any depth or complexity of HTML document can be served subject to those contraints. This is usually possible with some kind of batch import. If, however, the document has been uploaded one file at a time using the Web UI, the path information has been stripped. The system can cope with relative links that refer to a deeper path, e.g.
HTMLドキュメントは ここで説明しているように"自己完結した"ものでなければなりません。DSpaceで知られているすべてのパス情報の提供を受けて、どんな難解で複雑なHTMLドキュメントもそれらの制限事項に従って見ることができます。 これは大抵いくつかのバッチインポートによって可能です。しかし、もしドキュメントがwebユーザーインターフェースを使って、ひとつのファイルをアップロードされた場合、パス情報は取り除かれてしまいます。これにより、深いパスを参照する相対的なリンクに対処することができます。例えば、 

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

If the item has been uploaded via the Web submit UI, in the Bitstream table in the database we have the 'name' field, which will contain the filename with no path (figure1.gif). We can still work out what images/figure1.gif is by making the HTML document servlet strip any path that comes in from the URL, e.g.
アイテムがweb投稿インターフェースによってアップロードされた場合、データベースにあるビットストリームテーブルの中に、パスなしでファイル名が保管される'name'のフィールドを持ちます(figure1.gif)。HTMLドキュメント・サーブレットが URL に含まれているすべてのパスを取り除くことで、私たちは images/figure1.gif が何であるかを解決することが出来ます。例えば

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

BUT all the filenames (regardless of directory names) must be unique. For example, this wouldn't work:
ただし、（ディレクトリ名を無視した）ファイル名が全て異なる必要があります。以下の例では、うまくいきません。

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

since the HTML document servlet wouldn't know which bitstream to serve up for:
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

since it would just have figure.gif
figure.gifがあるだけだからです。

To prevent "infinite URL spaces" appearing (e.g. if a file foo.html linked to bar/foo.html, which would link to bar/bar/foo.html...) this behavior can be configured by setting the configuration property webui.html.max-depth-guess.
”無数のURLスペース”の出現（例：foo.htmlのファイルがbar/foo.htmlにリンクしていてそれがbar/bar/foo.htmlにリンクして…というように）を防ぐために、webui.html.max-depth-guessの環境設定プロパティを設定するという方法を用いることができます。

For example, if we receive a request for foo/bar/index.html, and we have a bitstream called just index.html, we will serve up that bitstream for the request if webui.html.max-depth-guess is 2 or greater. If webui.html.max-depth-guess is 1 or less, we would not serve that bitstream, as the depth of the file is greater. If webui.html.max-depth-guess is zero, the request filename and path must always exactly match the bitstream name. The default value (if that property is not present in dspace.cfg) is 3.
たとえば、もしfoo/bar/index.htmlに関するリクエストがあり、ただindex.htmlを呼ぶビットストリームを持っていた場合、webui.html.max-depth-guessが2以上であれば、私たちはそのリクエストに対してビットストリームを提供することができます。もし、webui.html.max-depth-guess が１か、それより少ないとき、そのファイルの深さが大きくなるにつれてそのビットストリームを提供しません。もしwebui.html.max-depth-guessが０であったら、リクエストのファイル名とパスは常にビットストリーム名と完全に一致しなければなりません。デフォルト値（もしプロパティがdspace.cfgになければ）は３です。

Thesis Blocking
学位論文のブロック

The submission UI has an optional feature that came about as a result of MIT Libraries policy. If the block.theses parameter in dspace.cfg is true, an extra checkbox is included in the first page of the submission UI. This asks the user if the submission is a thesis. If the user checks this box, the submission is halted (deleted) and an error message displayed, explaining that DSpace should not be used to submit theses. This feature can be turned off and on, and the message displayed (/dspace/jsp/submit/no-theses.jsp can be localized as necessary.
投稿UIは、MIT図書館の方針の結果として作成されたオプション機能を持っています。 dspace.cfgのblock.theses パラメタを trueにすると、投稿UIの最初のページにチェックボックスが1つ追加されます。これは、ユーザに投稿するものが学位論文であるか否かを尋ねるものです。ユーザがこのボックスをチェックすると、投稿は中止（削除）され、学位論文を投稿するためにDSpaceを使用してはならない旨のエラーメッセージが表示されます。この機能の使用の可否は設定できます。また、必要に応じて、表示するメッセージ（/dspace/jsp/submit/no-theses.jsp）を変更できます。

OAI-PMH Data Provider
OAI-PMH データプロバイダ

The DSpace platform supports the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) version 2.0 as a data provider. This is accomplished using the OAICat framework from OCLC.
DSpaceは、オープンアーカイブズイニシアティブ・メタデータハーベスティングプロトコル（OAI-PMH）バージョン2.0のデータプロバイダ機能をサポートしています。この機能は、OCLCのOAICatフレームワークを使って実現しています。

The DSpace build process builds a Web application archive, [dspace-source]/build/oai.war), in much the same way as the Web UI build process described above. The only differences are that the JSPs are not included, and [dspace-source]/etc/oai-web.xml is used as the deployment descriptor. This 'webapp' is deployed to receive and respond to OAI-PMH requests via HTTP. Note that typically it should not be deployed on SSL (https: protocol). In a typical configuration, this is deployed at oai, for example:
DSpaceのビルドプロセスにおいて、Webアプリケーションアーカイブ[dspace-source]/build/oai.warが、上で説明したWeb UIビルドプロセスとほぼ同じ方法で作成されます。違うのは、JSPが含まれないことと配備記述子として[dspace-source]/etc/oai-web.xmllが使われることだけです。この「Webアプリケーション」を配備して、HTTPを介したOAI-PMHリクエストを受け取り、応答します。通常、SSL（https:プロトコル）上には配備されないことに注意してください。一般的な設定では、このWebアプリケーションは oaiに配備され、たとえば、次のように呼び出します。

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

The 'base URL' of this DSpace deployment would be:
このDSpaceの「ベースURL」は、次のとおりです。

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

It is this URL that should be registered with www.openarchives.org. Note that you can easily change the 'request' portion of the URL by editing [dspace-source]/etc/oai-web.xml and rebuilding and deploying oai.war.
www.openarchives.orgに登録するのは、このURLです。URLの'request'の部分は、[dspace-source]/etc/oai-web.xmlを編集して、oai.warを再構築・再配備することで簡単に変更できることに注意してください。

DSpace provides implementations of the OAICat interfaces AbstractCatalog, RecordFactory and Crosswalk that interface with the DSpace content management API and harvesting API (in the search subsystem).
DSpaceは、OAICatの3つのインターフェースAbstractCatalog、RecordFactory、クロスウォークを実装しており、これが、DSpaceのコンテンツ管理APIと（検索サブシステムの）ハーベスティングAPIとのインターフェースになっています。

Only the basic oai_dc unqualified Dublin Core metadata set export is enabled by default; this is particularly easy since all items have qualified Dublin Core metadata. When this metadata is harvested, the qualifiers are simply stripped; for example, description.abstract is exposed as unqualified description. The description.provenance field is hidden, as this contains private information about the submitter and workflow reviewers of the item, including their e-mail addresses. Additionally, to keep in line with OAI community practices, values of contributor.author are exposed as creator values.
基本的な oai_dc の限定子なしのダブリンコア・メタデータ・セットだけがデフォルトでエクスポートされます。アイテムは限定子付きのダブリンコア・メタデータを持っているので、これは特に簡単です。このメタデータがハーベストされた場合、限定子は単に取り除かれます。例えば、description.abstractは限定子なしの description として公開されます。 description.provenanceに投稿者やアイテムのワークフローをレビューする人たちのe-mailアドレスを含む個人情報が含まれているとき、このフィールドは隠されます。更に OAI コミュニティの活動と歩調を合わせる為、 creator の値として、contributor.author が公開されます。

Other metadata formats are supported as well, using other Crosswalk implementations; consult the oaicat.properties file described below. To enable a format, simply uncomment the lines beginning with Crosswalks.*. Multiple formats are allowed, and the current list includes, in addition to unqualified DC: MPEG DIDL, METS, MODS. There is also an incomplete, experimental qualified DC.
他のメタデータフォーマットもクロスウォーク を実装することによって同様にサポートされます。以下に説明されたoaicat.propertiesファイルを参照します。フォーマットを動作可能にするためには、Crosswalks.*のから始まる行のコメントアウトを解除します。多数のフォーマットが許可され、限定子なしのDC(MPEG DIDL, METS, MODS)に加えてカレントリストに含まれます。また不完全で実験的な限定子なしのDCもあります。

Note that the current simple DC implementation (org.dspace.app.oai.OAIDCCrosswalk) does not currently strip out any invalid XML characters that may be lying around in the data. If your database contains a DC value with, for example, some ASCII control codes (form feed etc.) this may cause OAI harvesters problems. This should rarely occur, however. XML entities (such as >) are encoded (e.g. to &gt;)
現行の簡単なダブリンコアの実装（org.dspace.app.oai.OAIDCCrosswalk）では、データに存在するかもしれない不正なXML文字を取り除いていないことに注意してください。データベースに（フォームフィードなどの）ASCII制御文字を含むダブリンコア値がある場合、OAIハーベスタに問題を引き起こすかもしれません。しかし、これが生じるのはまれなケースでしょう。（>などの）XMLエンティティは（&gt;などに）エンコードされます。

In addition to the implementations of the OAICat interfaces, there are two configuration files relevant to OAI support:
OAICatインターフェースの実装に加えて、OAIサポートに関連する2つの設定ファイルが提供されています。

oaicat.properties

This resides as a template in [dspace]/config/templates, and the live version is written to [dspace]/config. You probably won't need to edit this; the install-configs script fills out the relevant deployment-specific parameters. You might want to change the earliestDatestamp field to accurately reflect the oldest datestamp in the system. (Note that this is the value of the last_modified column in the Item database table.)
これはテンプレートとして[dspace]/config/templatesにあり、実際に使用されるファイルは[dspace]/configに出力される。install-configsスクリプトが関連するサイト独自のパラメタを設定するので、これを変更する必要はおそらくないと思われる。ただし、システムのもっとも古い日付スタンプを正しく反映するために、earliestDatestampフィールドを修正する必要があるかもしれない。（これは、Itemテーブルの last_modified カラムの値であることに注意のこと。）

oai-web.xml

This standard Java Servlet 'deployment descriptor' is stored in the source as [dspace-source]/etc/oai-web.xml, and is written to /dspace/oai/WEB-INF/web.xml.
この標準的なJavaサーブレット「配備記述子」は、そのソースファイルが[dspace-source]/etc/oai-web.xmlにあり、/dspace/oai/WEB-INF/web.xmlに出力される。

Sets
セット

OAI-PMH allows repositories to expose an hierarchy of sets in which records may be placed. A record can be in zero or more sets.
OAI-PMH は、リポジトリがレコードを階層構造のセットとして公開できるように規定しています。レコードは0個以上のセットに入ることができます。

DSpace exposes collections as sets. The organization of communities is likely to change over time, and is therefore a less stable basis for selective harvesting.
DSpaceはコレクションをセットとして公開します。コミュニティの構成は時間とともに変化すると思われるので、選択的ハーベスティングの対象としては安定性に欠けます。

Each collection has a corresponding OAI set, discoverable by harvesters via the ListSets verb. The setSpec is the Handle of the collection, with the ':' and '/' converted to underscores so that the Handle is a legal setSpec, for example:
各コレクションは対応するOAIセットを持ちます。ハーベスタはListSetsコマンドを使ってこれを知ることができます。setSpecは、コレクションのハンドルですが、setSpecの規格に合うよう、":" と "/" は "_"（下線）で置き換えられています。たとえば次のようになります。

hdl_1721.1_1234

Naturally enough, the collection name is also the name of the corresponding set.
当然ですが、コレクション名は対応するセットの名前でもあります。

Unique Identifier
ユニークな識別子

Every item in OAI-PMH data repository must have an unique identifier, which must conform to the URI syntax. As of DSpace 1.2, Handles are not used; this is because in OAI-PMH, the OAI identifier identifies the metadata record associated with the resource. The resource is the DSpace item, whose resource identifier is the Handle. In practical terms, using the Handle for the OAI identifier may cause problems in the future if DSpace instances share items with the same Handles; the OAI metadata record identifiers should be different as the different DSpace instances would need to be harvested separately and may have different metadata for the item.
OAI-PMHデータリポジトリの全てのアイテムは、URIシンタックスに準拠するユニークな識別子を持たなければなりません。DSpace 1.2以降は、識別子としてハンドルを使用しなくなりました。OAI-PMHでは、OAI識別子がリソースに関するメタデータレコードを識別するからです。DSpaceにおいてリソースはアイテムであり、そのリソース識別子はハンドルです。実際問題として、OAI識別子としてハンドルを使用すると、将来、複数のDSpaceシステムが同じハンドルを持つアイテムを共有する場合に問題を引き起こす可能性があります。したがって、OAIメタデータレコード識別子はハンドルとは異なる識別子であるべきです。異なるDSpaceシステムは独立にハーベストされる必要があり、異なるDSpaceシステムが同じアイテムに異なるメタデータを持つかもしれないからです。

The OAI identifiers that DSpace uses are of the form:
DSpaceが使用するOAI識別子は次の形をとります。

oai:host name:handle

For example:
たとえば、次のとおり。

oai:dspace.myu.edu:123456789/345

If you wish to use a different scheme, this can easily be changed by editing the value of OAI_ID_PREFIX at the top of the org.dspace.app.oai.DSpaceOAICatalog class. (You do not need to change the code if the above scheme works for you; the code picks up the host name and Handles automatically from the DSpace configuration.)
別のスキームを使いたい場合は、org.dspace.app.oai.DSpaceOAICatalogクラスの先頭にあるOAI_ID_PREFIXの値を編集することにより簡単に変更できます。（上のスキームでよければプログラムを変更する必要はありません。ホスト名とハンドルはプログラムがDSpaceの設定ファイルから自動的に持ってくるからです。）

Access control
アクセスコントロール

OAI provides no authentication/authorisation details, although these could be implemented using standard HTTP methods. It is assumed that all access will be anonymous for the time being.
OAIはユーザ認証/権限付与の詳細については規定していませんが、これらは標準的なHTTPメソッドを使って実装することができるでしょう。とりあえず今のところは、すべてのアクセスは匿名であると仮定しています。

A question is, "is all metadata public?" Presently the answer to this is yes; all metadata is exposed via OAI-PMH, even if the item has restricted access policies. The reasoning behind this is that people who do actually have permission to read a restricted item should still be able to use OAI-based services to discover the content.
「すべてのメタデータが公開されるのか」という疑問があるでしょう。現在のところ、答えはイエスです。たとえアイテムがアクセス制限ポリシーを持っていたとしても、全てのメタデータはOAI-PMHを通して公開されます。アクセス制限されたアイテムを読むための権限を実際に持っている人は、コンテンツを発見するためのOAIベースのサービスを使うこともできるべきであるという理由です。

If in the future, this 'expose all metadata' approach proves unsatisfactory for any reason, it should be possible to expose only publicly readable metadata. The authorisation system has separate permissions for READing and item and READing the content (bitstreams) within it. This means the system can differentiate between an item with public metadata and hidden content, and an item with hidden metadata as well as hidden content. In this case the OAI data repository should only expose items those with anonymous READ access, so it can hide the existence of records to the outside world completely. In this scenario, one should be wary of protected items that are made public after a time. When this happens, the items are "new" from the OAI-PMH perspective.
将来において、何らかの理由でこの「すべてのメタデータを公開する」というアプローチに問題があることが証明された場合、一部のメタデータだけを一般に公開することは可能だと思われます。権限付与システムでは、アイテムを読むことができる権限と、それに含まれているコンテンツ（ビットストリーム）を読むことができる権限を分けています。これは、システムが、メタデータは公開するがコンテンツは公開しないアイテムと、メタデータもコンテンツも公開しないアイテムを区別することができることを意味しています。この場合、OAIデータリポジトリは、匿名によるREADアクセス権限を持つアイテムのみを公開すべきです。そうすれば、レコードの存在を外部の世界から完全に隠すことが可能になります。このシナリオでは、当初はアクセスを制限するが、しばらく後に公開するアイテムに注意するべきです。これが実現した場合、OAI-PMHの観点からはアイテムが「新規」に作成されたことになります。

Modification Date (OAI Date Stamp)
更新日付（OAI日付スタンプ)

OAI-PMH harvesters need to know when a record has been created, changed or deleted. DSpace keeps track of a 'last modified' date for each item in the system, and this date is used for the OAI-PMH date stamp. This means that any changes to the metadata (e.g. admins correcting a field, or a withdrawal) will be exposed to harvesters.
OAI-PMHハーベスタは、レコードがいつ作成・変更・削除されたかを知る必要があります。 DSpaceはシステムにある各アイテムの「最新更新」日を記録しており、この日付をOAI-PMHの日付スタンプに使用しています。これは、メタデータに行ったあらゆる変更（管理者によるフィールドの修正やアイテムの取り下げなど）がハーベスタに公開されることを意味しています。

'About' Information
"about" 情報

As part of each record given out to a harvester, there is an optional, repeatable "about" section which can be filled out in any (XML-schema conformant) way. Common uses are for provenance and rights information, and there are schemas in use by OAI communities for this. Presently DSpace does not provide any of this information.
ハーベスタに提供されるレコードの一部として、オプションで繰り返し可能な "about" セクションがあります。このセクションは、（XMLスキーマに準拠する）任意の方法で使用することができますが、一般的には、出自情報や権利情報に使用します。また、OAIコミュニティで使用されているそのためのスキーマも存在します。現在のところ、DSpaceはこの情報を提供していません。

Deletions
削除

DSpace keeps track of deletions (withdrawals). These are exposed via OAI, which has a specific mechansim for dealing with this. Since DSpace keeps a permanent record of withdrawn items, in the OAI-PMH sense DSpace supports deletions 'persistently'. This is as opposed to 'transient' deletion support, which would mean that deleted records are forgotten after a time.
DSpace は、削除（取り下げ）を記録しています。削除情報は、これを処理する特別なメカニズムを持っているOAIにより公開されます。 DSpaceは取り下げたアイテムについてのレコードを永続的に保持しているので、OAI-PMHの概念でいえば、DSpaceは、「永続的な」削除をサポートしていることになります。これは、しばらくすると削除されたレコードを忘れてしまうことを意味する「一時的な」削除のサポートとは対照的です。

Once an item has been withdrawn, OAI-PMH harvests of the date range in which the withdrawal occurred will find the 'deleted' record header. Harvests of a date range prior to the withdrawal will not find the record, despite the fact that the record did exist at that time.
アイテムが取り下げられると、これが行われた日付を含む日付範囲を指定したOAI-PMHハーベストリクエストは、「削除済」レコードヘッダを見つけることになります。取り下げが行われた日より前の日付範囲を指定したハーベストリクエストは、レコードはその時点では存在したにもかかわらず、このレコードを見つけることはありません。

As an example of this, consider an item that was created on 2002-05-02 and withdrawn on 2002-10-06. A request to harvest the month 2002-10 will yield the 'record deleted' header. However, a harvest of the month 2002-05 will not yield the original record.
この例として、2002年5月2日に作成され、2002年10月6日に取り下げられたアイテムを考えます。 2002年10月を指定したハーベストリクエストは、「削除済レコード」ヘッダをハーベストします。しかし、2002年5月を指定したハーベストリクエストは、取り下げられる前のレコードをハーベストしません。

Note that presently, the deletion of 'expunged' items is not exposed through OAI.
現在のところ、「抹消された」アイテムはOAIでは公開されないことに注意してください。

Flow Control (Resumption Tokens)
フロー制御（Resumption Tokens）

An OAI data provider can prevent any performance impact caused by harvesting by forcing a harvester to receive data in time-separated chunks. If the data provider receives a request for a lot of data, it can send part of the data with a resumption token. The harvester can then return later with the resumption token and continue.
OAIデータプロバイダは、ハーベスティングによるパフォーマンスの低下を防ぐために、データを時分割のかたまりで受け取るようハーベスタに強制することができます。データプロバイダは大量データの取得リクエストを受け付けた場合、resumptin tokenをつけて、一部のデータだけを送信することができます。こうすれば、ハーベスタはその後resumption tokenを付けて返すことでハーベストを継続することができます。

DSpace supports resumption tokens for 'ListRecords' OAI-PMH requests. ListIdentifiers and ListSets requests do not produce a particularly high load on the system, so resumption tokens are not used for those requests.
DSpaceは、OAI-PMHの "ListRecords" リクエストについてのみ、resumption tokenをサポートしています。ListIdentifiersリクエストとListSetsリクエストについては、システムへの負荷がそれほど大きくないので、resumption tokenは使用しません。

Each OAI-PMH ListRecords request will return at most 100 records. This limit is set at the top of org.dspace.app.oai.DSpaceOAICatalog.java (MAX_RECORDS). A potential issue here is that if a harvest yields an exact multiple of MAX_RECORDS, the last operation will result in a harvest with no records in it. It is unclear from the OAI-PMH specification if this is acceptable.
OAI-PMH ListRecordsリクエストには、1回当たり最大100レコードが返されます。この件数は、org.dspace.app.oai.DSpaceOAICatalog.javaの先頭（MAX_RECORDS）で設定しています。MAX_RECORDSのちょうど倍数のレコードをハーベストする場合、最後の操作で0個のレコードをハーベストすることになるという潜在的な問題があります。これが仕様にあっているのかどうかはOAI-PMHの仕様からははっきりしません。

When a resumption token is issued, the optional completeListSize and cursor attributes are not included. OAICat sets the expirationDate of the resumption token to one hour after it was issued, though in fact since DSpace resumption tokens contain all the information required to continue a request they do not actually expire.
resumption tokenを発行する際、オプションのcompleteListSize属性と cursor属性は設定しません。 OAICatは、resumption tokenのexpirationDate を発行後1時間に設定しますが、DSpaceのresumption tokenにはリクエストの継続に必要なすべての情報が含まれているので、実際はresumption tokenは失効しません。

Resumption tokens contain all the state information required to continue a request. The format is:
DSpaceのresumption tokensには、リクエストの継続に必要なすべての状態情報を含んでいます。その形式は次のとおりです。

from/until/setSpec/offset

from and until are the ISO 8601 dates passed in as part of the original request, and setSpec is also taken from the original request. offset is the number of records that have already been sent to the harvester. For example:
from とuntilは、ISO8601形式の日付で、オリジナルのリクエストから取られたものです。setSpecもオリジナルのリクエストから取られたものです。offsetは、すでにハーベスタに送付済みのレコード数です。たとえば、次のとおりです。

2003-01-01//hdl_1721_1_1234/300

This means the harvest is 'from' 2003-01-01, has no 'until' date, is for collection hdl:1721.1/1234, and 300 records have already been sent to the harvester. (Actually, if the original OAI-PMH request doesn't specify a 'from' or 'until, OAICat fills them out automatically to '0000-00-00T00:00:00Z' and '9999-12-31T23:59:59Z' respectively. This means DSpace resumption tokens will always have from and until dates in them.)
この例では、ハーベストの「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日付を持っていることになります。）

Community and Collection Structure Importer
コミュニティとコレクションの構造インポータ

This command-line tool gives you the ability to import a community and collection structure directly from a source XML file. It is executed as follows:
このコマンドラインのツールによってXMLファイルのソースからコミュニティとコレクションの構造をダイレクトにインポートすることができます。それは次の通りに実行されます

[dspace]/bin/structure-builder -f [source xml] -o [output xml file] -e [administrator email]

This will examine the contents of [source xml], import the structure into DSpace while logged in as the supplied administrator, and then output the same structure to the output file, but including the handle for each imported community and collection as an attribute.
これは[source xml]の中身を調査し、提供された管理者でログインしている間はこの構造をDSpaceにインポートします。そして、同一の構造をアウトプットファイルに出力します。しかし、それぞれインポートしたコミュニティとコレクションをひとつの属性として処理することも含まれています。

The source xml document needs to be in the following format:
xmlのドキュメントソースは以下のフォーマットのなかにある必要があります。

<import_structure>
 	<community>
  		<name>Community Name</name>
  		<description>Descriptive text</description>
  		<intro>Introductory text</intro>
  		<copyright>Special copyright notice</copyright>
  		<sidebar>Sidebar text</sidebar>
  		<community>
 			<name>Sub Community Name</name>
 			<community> ...[ad infinitum]... </community>
 		</community>
 		<collection>
 			<name>Collection Name</name>
  			<description>Descriptive text</description>
  			<intro>Introductory text</intro>
  			<copyright>Special copyright notice</copyright>
  			<sidebar>Sidebar text</sidebar>
  			<license>Special licence</license>
  			<provenance>Provenance information</provenance>
 		</collection>
   	</community>
</import_structure>

The resulting output document will be as follows:
アウトプットドキュメントの結果表示は以下の通りです：

<import_structure>
 	<community identifier="123456789/1">
  		<name>Community Name</name>
  		<description>Descriptive text</description>
  		<intro>Introductory text</intro>
  		<copyright>Special copyright notice</copyright>
  		<sidebar>Sidebar text</sidebar>
  		<community identifier="123456789/2">
 			<name>Sub Community Name</name>
 			<community identifier="123456789/3"> ...[ad infinitum]... </community>
 		</community>
 		<collection identifier="123456789/4">
 			<name>Collection Name</name>
  			<description>Descriptive text</description>
  			<intro>Introductory text</intro>
  			<copyright>Special copyright notice</copyright>
  			<sidebar>Sidebar text</sidebar>
  			<license>Special licence</license>
  			<provenance>Provenance information</provenance>
 		</collection>
   	</community>
</import_structure>

Limitation
制限

Package Importer and Exporter
パッケージ・インポータ/エクスポータ

This command-line tool gives you access to the Packager plugins. It can ingest a package to create a new DSpace Item, or disseminate an Item as a package.
このコマンドラインツールはPackagerプラグインへのアクセスを可能にします。それは新しいDSpaceアイテムを作成するためにパッケージを取り込み（ingest）、またはひとつのアイテムをパッケージとして配布（disseminate）することができます。

To see all the options, invoke it as:
すべてのオプションをご覧になるには以下のように起動します。 

[dspace]/bin/packager --help
This mode also displays a list of the names of package ingesters and disseminators that are available.
このモードは有効であるingestersとdisseminatorsのパッケージ名のリストも表示されます。

Ingesting
受入

To ingest a package from a file, give the command:
ファイルからパッケージの受入をするためには、次のコマンドを使います。 

[dspace]/bin/packager -e user -c handle -t packager path
Where user is the e-mail address of the E-Person under whose authority this runs; handle is the Handle of the collection into which the Item is added, packager is the plugin name of the package ingester to use, and path is the path to the file to ingest (or "-" to read from the standard input).
userが実行の権限を持つE-Personのe-mailアドレスである場合は、handleはアイテムが追加されるコレクションのハンドルであり、packagerはパッケージingesterが使用するプラグイン名になり、pathは読み込むファイルのパスになります。(もしくは、標準入力から読み込むために "-" と指定します。 )

Here is an example that loads a PDF file with internal metadata as a package:
内部のメタデータをパッケージとして使って、PDFファイルをロードする例があります。 

/dspace/bin/packager -e florey@mit.edu -c 1721.2/13  -t pdf thesis.pdf

This example takes the result of retrieving a URL and ingests it:
この例はURLの検索結果を捉え、受入れます。 

wget -O - http://alum.mit.edu/jarandom/my-thesis.pdf | \
/dspace/bin/packager -e florey@mit.edu -c 1721.2/13  -t pdf -

Disseminating
配布

To disseminate an Item as a package, give the command:
アイテムをパッケージとして配布するために次のコマンドを使います。 

[dspace]/bin/packager -e user -d -i handle -t   packager path
Where user is the e-mail address of the E-Person under whose authority this runs; handle is the Handle of the Item to disseminate; packager is the plugin name of the package disseminator to use; and path is the path to the file to create (or "-" to write to the standard output). This example writes an Item out as a METS package in the file "454.zip":
userはこれを実行する権限をもつE-personのe-mailアドレスです。handle は配布用アイテムのハンドルであり、packagerはパッケージを配布する人が使うプラグインネームであり、pathは作成するファイルのパス（もしくは標準出力に"-"を記入する）です。以下の例は、アイテムをMETSパッケージとして"454.zip"ファイルに書き出しています。

/dspace/bin/packager -e florey@mit.edu -d -i 1721.2/454 -t METS 454.zip

METS packages
METSパッケージ

DSpace 1.4 includes a package disseminator and matching ingester for the DSpace METS SIP (Submission Information Package) format. They were created to help end users prepare sets of digital resources and metadata for submission to the archive using well-defined standards such as METS, MODS, and PREMIS. The plugin name is METS by default, and it uses MODS for descriptive metadata.
DSpace１．４は（package disseminator）パッケージ配布者そしてDSpace METS SIP (Submission Information Package)のフォーマットに対する（matching ingester） matching投稿を含んでいます。エンドユーザーがデジタルリソースを設定する際の手助けのために作成されました。またMETS, MODS, PREMISなどの明確な基準を使ってアーカイブに対する投稿用メタデータの設定する際にも役立ちます。プラグイン名はデフォルトに基づきMETSであり、記述的なメタデータのためにMODSを使用します。

The DSpace METS SIP profile is available at:
DSpace METS SIPプロファイルは以下のURLにおいて有効です。

http://www.dspace.org/standards/METS/SIP/profilev1p0/metsipv1p0.pdf.

Item Importer and Exporter
アイテム・インポータ/エクスポータ

DSpace has a set of command line tools for importing and exporting items in batches, using the DSpace simple archive format. The tools are not terribly robust, but are useful and are easily modified. They also give a good demonstration of how to implement your own item importer if desired.
DSpaceは、DSpaceシンプルアーカイブフォーマットを使って、アイテムを一括してインポート、あるいは、エクスポートするコマンドラインツールを持っています。このツールはそれほど堅牢ではありませんが、便利であり、変更も容易です。また、独自のアイテムインポータが必要な場合、このツールはその実装法についての良いお手本になります。

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

The basic concept behind the DSpace's simple archive format is to create an archive, which is directory full of items, with a subdirectory per item. Each item directory contains a file for the item's descriptive metadata, and the files that make up the item.
DSpaceシンプルアーカイブフォーマットの基本的なコンセプトは、アイテムごとにサブディレクトリを持つアイテムからなるディレクトリとしてアーカイブを作成することです。各アイテムディレクトリは、アイテムを記述するメタデータファイルとアイテムを構成するファイルからなります。

archive_directory/
    item_000/
        dublin_core.xml -- qualified Dublin Core metadata限定子付きダブリンコアメタデータ

        contents        -- text file containing one line per filename1行に1ファイル名を記したテキストファイル
        file_1.doc      -- files to be added as bitstreams to the itemアイテムにビットストリームとして加えるファイル
        file_2.pdf
    item_001/
        dublin_core.xml
        contents
        file_1.png
        ...

The dublin_core.xml file has the following format, where each Dublin Core element has it's own entry within a <dcvalue> tagset. There are currently three tag attributes available in the <dcvalue> tagset:
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>

(Note the optional language tag attribute which notifies the system that the optional title is in French.)
（この例では、オプションのlanguage属性により、別タイトルがフランス語で書かれていることをシステムに知らせています。）

The contents file simply enumerates, one file per line, the bitstream file names. The bitstream name may optionally be followed by the sequence:
コンテンツファイルは単純にビットストリームファイル名を列挙します。1行につき１つのファイルです。ビットストリーム名は連続で任意に列挙されます。

\tbundle:bundlename

where '\t' is the tab character and 'bundlename' is replaced by the name of the bundle to which the bitstream should be added. If no bundle is specified, the bitstream will be added to the 'ORIGINAL' bundle.
'\t'はタブの文字で、バンドル名はビットストリームが追加されるべきバンドルに置換されます。もし何もバンドルが指定されなかった場合、ビットストリームがオリジナルのバンドルに追加されます。

Importing Items
アイテムのインポート

Note: Before running the item importer over items previously exported from a DSpace instance, please first refer to Transferring Items Between DSpace Instances.
注: 事前にDSpaceからエクスポートしたアイテムをインポートする場合は、まず、DSpaceシステム間のアイテムの移動を参照してください。

The item importer is in org.dspace.app.itemimport.ItemImport, and is run with the import utility in the dspace/bin directory. Running it with -h gets the current command-line arguments. Another very important flag is the --test flag, which you can use with any command to simulate all of the actions it will perform without actually making any changes to your DSpace instance - very useful for validating your item directories before doing an import. In the importer's arguments you can use either the user's database ID or email address and the eperson ID, and the collection's database ID or handle as arguments. Currently with the importer you can add, remove, and replace items in a collection. If you specify more than one collection argument then the items will be imported to multiple collections, and the first collection specified becomes the "owning" collection. If there is an error and the import is aborted, there is a --resume flag that you can try to resume the import where you left off after you fix the error.
アイテムインポータは、org.dspace.app.itemimport.ItemImportにありdspace/bin ディレクトリにあるimportユーティリティを使って実行します。 -hフラグを付けてこのユーティリティを実行すると、現在使用できるコマンドライン引数を表示します。--testフラグも重要なフラグです。このフラグは全てのコマンドに指定でき、DSpaceシステムに変更を加えることなく、そのコマンドが実行する全ての処理をシミュレートすることができます。インポートを行う前にアイテムディレクトリを検証するためにはこのフラグが非常に便利です。インポートの実行者引数（eperson引数）にはユーザのデータベースIDかメールアドレスのいずれかを、collection引数にはコレクションのデータベースIDかハンドルのいずれかを使用することができます。現在のところ、インポータを使って、コレクションに対してアイテムを追加・削除・置換することができます。collection引数を複数指定すると、アイテムは複数のコレクションにインポートされ、最初に指定したコレクションが「オーナー」コレクションになります。エラーが発生した場合やインポータが異常終了した場合に、エラーを修正後に中断した場所からインポートを再開することができる、--resumeフラグが存在します。

To add items to a collection with an EPerson as the submitter, type:
あるe-personを投稿者として、コレクションにアイテムを追加するには、次のように入力します。

[dspace]/bin/import --add --eperson=joe@user.com  --collection=collectionID --source=items_dir --mapfile=mapfile

(or by using the short form)
（次の短縮形を使用することもできます。）

[dspace]/bin/import -a -e joe@user.com  -c collectionID -s items_dir -m mapfile

which would then cycle through the archive directory's items, import them, and then generate a map file which stores the mapping of item directories to item handles. Save this map file! Using the map file you can then 'unimport' with the command:
このコマンドは、アーカイブディレクトリのアイテムを順番にたどって、アイテムをインポートし、アイテムディレクトリとアイテムハンドルのマッピングを格納するマップファイルを生成します。このマップファイルは保存してください。このマップファイルを使って、アイテムのインポートを次のコマンドで「取り消す」ことができます。

[dspace]/bin/import --delete --mapfile=mapfile

The imported items listed in the map file would then be deleted. If you wish to replace previously imported items, you can give the command:
マップファイルにリストされているインポートアイテムが削除されます。以前にインポートしたアイテムを置き換えたい場合は、次のコマンドを入力します。

[dspace]/bin/import --replace --eperson=joe@user.com --collection=collectID --source=items_dir --mapfile=mapfile

Replacing items uses the map file to replace the old items and still retain their handles.
マップファイルを使用して古いアイテムを置換しますが、ハンドルは変更しません。

The importer usually bypasses any workflow assigned to a collection, but adding the --workflow option will route the imported items through the workflow system.
インポータは通常コレクションに割り当てられたワークフローを迂回します。しかし、--workflow オプションを指定すると、インポートアイテムはワークフローシステムを通るようになります。

The importer also has a --test flag that will simulate the entire import process without actually doing the import. This is extremely useful for verifying your import files before doing the import step.
インポータには、--testフラグもあり、これを指定すると、実際のインポートをすることなく全てのインポート処理をシミュレートします。これは、インポートを行う前にインポートファイルを検証するために非常に役に立ちます。

Exporting Items
アイテムのエクスポート

The item exporter can export a single item or a collection of items, and creates a DSpace simple archive for each item to be exported. To export a collection's items you type:
アイテムエクスポータは1アイテム、または、コレクションの全アイテムをエクスポートすることができます。そして、エクスポートされる各アイテムについてのDSpaceシンプルアーカイブを作成します。

[dspace]/bin/export --type=COLLECTION --id=collID --dest=dest_dir --number=seq_num

The keyword COLLECTION means that you intend to export an entire collection. The ID can either be the database ID or the handle. The exporter will begin numbering the simple archives with the sequence number that you supply. To export a single item use the keyword ITEM and give the item ID as an argument:
キーワードCOLLECTIONは、コレクション全体をエクスポートすることを意味します。 id引数には、データベースIDかハンドルのいずれかを使用できます。エクスポータは、number引数で指定した番号からシンプルアーカイブに付番します。 1つのアイテムをエクスポートする場合は、キーワードITEMを使い、引数としてアイテムIDを指定します。

[dspace]/bin/export --type=ITEM --id=itemID --dest=dest_dir --number=seq_num

Each exported item will have an additional file in its directory, named 'handle'. This will contain the handle that was assigned to the item, and this file will be read by the importer so that items exported and then imported to another machine will retain the item's original handle.
エクスポートされた全てのアイテムのディレクトリには "handle" という名前のファイルが追加されます。このファイルには、アイテムに割り当てられたハンドルが書かれています。このファイルをインポータに入力することにより、エクスポートされたアイテムをオリジナルのハンドルを保持したまま、別のマシンにインポートすることができます。

Transferring Items Between DSpace Instances
DSpaceシステム間のアイテムの移動

Where items are to be moved between DSpace instances (for example from a test DSpace into a production DSpace) the item exporter and item importer can be used in conjunction with a script to assist in this process.
（たとえば、テストシステムから本番システムへの移行など）アイテムをDSpaceシステム間で移動させる場合、アイテムエクスポータとアイテムインポータを組み合わせたスクリプトを作成することで、この処理を簡単にすることができます。

After running the item exporter each dublin_core.xml file will contain metadata that was automatically added by DSpace. These fields are as follows:
アイテムエクスポータを実行すると、 dublin_core.xml ファイルにはDSpaceにより自動的にメタデータが追加されます。追加されるメタデータは次のとおりです。

In order to avoid duplication of this metadata, run
このメタデータの重複を避けるために、アイテムインポータを実行する前に次のコマンドを実行してください。

dspace_migrate <exported item directory>

prior to running the item importer. This will remove the above metadata items, except for date.issued - if the item has been published or publicly distributed before and identifier.uri - if it is not the handle, from the dublin_core.xml file and remove all handle files. It will then be safe to run the item exporter. Use
これはdata.issuedを除いた上記のメタデータアイテムを取り去ります。もしアイテムが出版されたもので、もしくは以前に公的に配布されたものであった場合、 dublin_core.xml ファイルからのidentifier.uriがハンドルではない時、すべてのハンドルファイルは削除されます。こうしてアイテムエクスポーターを安全に実行することができます。

dspace_migrate --help

for instructions on use of the script.
これはスクリプトの利用方法を参照するために使います。

Registering (Not Importing) Bitstreams
ビットストリームの登録（インポートではなく）

Registration is an alternate means of incorporating items, their metadata, and their bitstreams into DSpace by taking advantage of the bitstreams already being in storage accessible to DSpace. An example might be that there is a repository for existing digital assets. Rather than using the normal interactive ingest process or the batch import to furnish DSpace the metadata and to upload bitstreams, registration provides DSpace the metadata and the location of the bitstreams. DSpace uses a variation of the import tool to accomplish registration.
登録は、DSpaceにアイテムとそのメタデータ、ビットストリームを受け入れるもう一つの方法で、DSpaceがアクセス可能なストレージに既に存在するビットストリームをうまく利用します。たとえば、既存のデジタル資産のためのリポジトリが例に挙げられるでしょう。メタデータの登録やビットストリームのアップロードに通常の対話的な受入プロセスや一括インポートを使う代わりに、登録ではDSpaceにメタデータと、ビットストリームの配置場所を提供します。DSpaceはインポートツールを使って登録を実行します。

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

To register an item its bitstreams must reside on storage accessible to DSpace and therefore referenced by an asset store number in dspace.cfg. The configuration file dspace.cfg establishes one or more asset stores through the use of an integer asset store number. This number relates to a directory in the DSpace host's file system or a set of SRB account parameters. This asset store number is described in The dspace.cfg Configuration Properties File section and in the dspace.cfg file itself. The asset store number(s) used for registered items should generally not be the value of the assetstore.incoming property since it is unlikely that that you will want to mix the bitstreams of normally ingested and imported items and registered items.
アイテムを登録するには、ビットストリームがDSpaceにアクセス可能な、すなわち、dspace.cfgの情報資産格納番号で参照されるストレージに保管されている必要があります。設定ファイルdspace.cfgは整数の情報資産格納番号を使用して1つ以上の情報資産格納場所を指定します。この番号は、DSpaceのホスト上のファイルシステムのディレクトリ、あるいは1組のSRBアカウントパラメタと関連付けられています。この情報資産格納番号は、プロパティ設定ファイルdspace.cfgの解説ページ、あるいはdspace.cfgファイル自身の中で説明されています。通常の方法で受け入れられるアイテムやインポートされるアイテムと、登録されるアイテムを混在させたいとは思わないでしょうから、登録されるアイテムで使用される資産格納番号は、一般に、assetstore.incomingプロパティの値と同じにするべきではありません。

Registering Items Using the Item Importer
アイテムインポータを使ったアイテムの登録

DSpace uses the same import tool that is used for batch import except that several variations are employed to support registration. The discussion that follows assumes familiarity with the import tool.
DSpaceは、一括インポートに使用したものと同じインポートツールを使用しますが、登録をサポートするためにいくつか異なる点があります。以下の説明ではインポートツールについて熟知していることを前提とします。

The archive format for registration does not include the actual content files (bitstreams) being registered. The format is however a directory full of items to be registered, with a subdirectory per item. Each item directory contains a file for the item's descriptive metadata (dublin_core.xml) and a file listing the item's content files (contents), but not the actual content files themselves.
登録のためのアーカイブフォーマットは、登録される実際のコンテンツファイル（ビットストリーム）を含みません。しかし、そのフォーマットは登録するアイテムからなるディレクトリであり、アイテムごとにサブディレトリを持っています。各アイテムディレクトリは、アイテムの記述メタデータファイル（dublin_core.xml）と、アイテムのコンテンツをリストアップしたファイル（code>contents）を含みますが、実際のコンテンツファイル自体は持ちません。

The dublin_core.xml file for item registration is exactly the same as for regular item import.
アイテム登録のためのdublin_core.xmlファイルは、通常のアイテムインポート用のファイルとまったく同じです。

The contents file, like that for regular item import, lists the item's content files, one content file per line, but each line has the one of the following formats:
contentsファイルも、通常のアイテムインポートと同じく、アイテムのコンテンツファイルを1ファイル1行でリストアップしたものですが、リストの各行は次のような形式です。

-r -s n -f filepath
-r -s n -f filepath\tbundle:bundlename
-r -s n -f filepath\tbundle:bundlename\tpermissions: -[r|w] 'group name'
-r -s n -f filepath\tbundle:bundlename\tpermissions: -[r|w] 'group name'\tdescription: some text

where
ここで、

The bundle, that is everything after the filepath, is optional and is normally not used.
バンドル（ファイルパスの後ろにある全て）はオプションであり、通常は使用しません。

The command line for registration is just like the one for regular import:
バンドル（ファイルパスの後ろにある全て）はオプションであり、通常は使用しません。

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

(or by using the short form)
（次の短縮形も使えます）

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

The --workflow and --test flags will function as described in Importing Items.
--workflowフラグと--testフラグは、 アイテムのインポートで説明した機能を持ちます。

The --delete flag will function as described in Importing Items but the registered content files will not be removed from storage. See Deleting Registered Items.
--deleteフラグは、アイテムのインポートで説明した機能を持ちますが、登録されたコンテンツファイルはストレージから削除されません。 登録アイテムの削除を参照してください。

The --replace flag will function as described in Importing Items but care should be taken to consider different cases and implications. With old items and new items being registered or ingested normally, there are four combinations or cases to consider. Foremost, an old registered item deleted from DSpace using --replace will not be removed from the storage. See Deleting Registered Items. where is resides. A new item added to DSpace using --replace will be ingested normally or will be registered depending on whether or not it is marked in the contents files with the -r.
--replace フラグは、アイテムのインポートで説明した機能を持ちますが、場合により意味合いが異なることを考慮する必要があります。旧アイテムと新アイテムが登録アイテムか、通常の受入アイテムかにより、4つの組み合わせが考えられます。最も重要なのは、 --replace を使ってDSpaceから削除された旧登録アイテムは、ストレージからは削除されないことです。下の登録アイテムの削除を参照してください。 --replace を使ってDSpaceに追加された新アイテムは、それがcontentsで-rフラグが指定されていれば登録され、指定されていなければ通常の方法で受け入れられます。

Internal Identification and Retrieval of Registered Items
内部的識別と登録アイテムの検索

Once an item has been registered, superficially it is indistinguishable from items ingested interactively or by batch import. But internally there are some differences:
ひとたびアイテムが登録されれば、表面上、対話的に受け入れられたアイテムや一括インポートされたアイテムと区別はつきません。しかし、内部的にはいくつかの違いがあります。

First, the randomly generated internal ID is not used because DSpace does not control the file path and name of the bitstream. Instead, the file path and name are that specified in the contents file.
第1に、ランダムに生成される内部IDは使用されません。DSpaceはビットストリームのファイルパスやファイル名を管理しないからです。その代わりに、contentsファイルで指定したファイルパス名が使用されます。

Second, the store_number column of the bitstream database row contains the asset store number specified in the contents file.
第2に、Bitstreamテーブルのstore_numberカラムは、contentsファイルで指定した情報資産格納番号を持ちます。

Third, the internal_id column of the bitstream database row contains a leading flag (-R) followed by the registered file path and name. For example, -Rfilepath where filepath is the file path and name relative to the asset store corresponding to the asset store number. The asset store could be traditional storage in the DSpace server's file system or an SRB account.
第3に、Bitstreamテーブルのinternal_idカラムは、登録されたファイルパス名の前に（-R）フラグを付けたものを持ちます。たとえば、-Rfilepathです。ここで、filepathは情報資産格納番号に対応する格納場所における相対パス名です。格納場所は、DSpaceサーバ上のファイルシステムである従来型のストレージかSRBアカウントかのいずれかです。

Fourth, an MD5 checksum is calculated by reading the registered file if it is in local storage. If the registerd file is in remote storage (say, SRB) a checksum is calulated on just the file name! This is an efficiency choice since registering a large number of large files that are in SRB would consume substantial network resources and time. A future option could be to have an SRB proxy process calculate MD5s and store them in SRB's metadata catalog (MCAT) for rapid retrieval. SRB offers such an option but it's not yet in production release.
第4に、MD5チェックサムは、登録ファイルがローカルストレージにあればファイルを読んで計算しますが、リモートストレージ（SRB）にあれば単にファイル名で計算します。この選択は効率の問題です。SRBにある非常に多くの大きなファイルの登録には大量のネットワーク資源と時間を消費するからです。将来の選択肢として、SRBプロキシプロセスにMD5を計算させ、SRBのメタデータカタログ（MCAT）に保管する方法が考えられます。SRBはそのようなオプションを提供していますが、まだ製品リリースには含まれていません。

Registered items and their bitstreams can be retrieved transparently just like normally ingested items.
登録アイテムとそのビットストリームは、意識することなく通常の受入アイテムと同じように検索することができます。

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

Registered items may be exported as described in Exporting Items. If so, the export directory will contain actual copies of the files being exported but the lines in the contents file will flag the files as registered. This means that if DSpace items are "round tripped" (see Transferring Items Between DSpace Instances) using the exporter and importer, the registered files in the export directory will again registered in DSpace instead of being uploaded and ingested normally.
登録アイテムは アイテムのエクスポートで説明した方法でエクスポートできます。その場合、エクスポートディレクトリにはビットストリームファイルの実際のコピーが出力されます。ただし、contentsファイルのコンテンツファイル行にはファイルが登録されたものであることを示すフラグが付きます。これは、エクスポータとインポータを使ってDSpaceアイテムを「往復させる」（DSpaceシステム間のアイテムの移動参照）と、エクスポートディレクトリにある登録ファイルはアップロードされ通常の方法で受け入れられるのではなく、再びDSpaceに登録されることを意味します。

METS Export of Registered Items
登録アイテムのMETSエクスポート

The METS Export Tool can also be used but note the cautions described in that section and note that MD5 values for items in remote storage are actually MD5 values on just the file name.
METSエクスポートツールを使用することもできます。ただし、そこで説明されている注意書きに気をつけてください。また、リモートストレージのアイテムのMD5値は、実際は単なるファイル名によるMD5値であることにも注意してください。

Deleting Registered Items
登録アイテムの削除

If a registered item is deleted from DSpace, either interactively or by using the --delete or --replace flags described in Importing Items, the item will disappear from DSpace but it's registered content files will remain in place just as they were prior to registration. Bitstreams not registered but added by DSpace as part of registration, such as license.txt files, will be deleted.
登録アイテムを対話的に、あるいはアイテムのインポートで説明した--deleteフラグや--replaceフラグを使ってDSpaceから削除した場合、アイテムはDSpaceから消えますが、登録されたコンテンツファイルは登録される前からあった場所に残されます。license.txtファイルなどの、登録されたのではなく登録処理の過程でDSpaceにより追加されたビットストリームは削除されます。

METS Tools
METSツール

The experimental (incomplete) METS export tool writes DSpace items to a filesystem with the metadata held in a more standard format based on METS.
実験的な（不完全な）METSエクスポートツールは、METSに基づくより標準的なフォーマットのメタデータでDSpaceアイテムをファイルシステムに出力します。

The Export Tool
エクスポートツール

The METS export tool is invoked via the command line like this:
METSエクスポートツールは、次のようなコマンドで呼び出されます。

[dspace]/bin/dsrun org.dspace.app.mets.METSExport --help

The tool can export an individual item, the items within a given collection, or everything in the DSpace instance. To export an individual item, use:
このツールは、個々のアイテム、コレクションの全アイテム、DSpaceシステムの全アイテムをエクスポートできます。個々のアイテムをエクスポートするには、次のように指定します。

[dspace]/bin/dsrun org.dspace.app.mets.METSExport --item [handle]

To export the items in collection hdl:123.456/789, use:
コレクションhdl:123.456/789のアイテムをエクスポートするには、次のように指定します。

[dspace]/bin/dsrun org.dspace.app.mets.METSExport --collection hdl:123.456/789

To export all the items DSpace, use:
DSpaceの全アイテムをエクスポートするには、次のように指定します。

[dspace]/bin/dsrun org.dspace.app.mets.METSExport --all

With any of the above forms, you can specify the base directory into which the items will be exported, using --destination [directory]. If this parameter is omitted, the current directory is used.
上のいずれのコマンドにおいても、--destination [directory] フラグを使って、アイテムをエクスポートするベースディレクトリを指定することができます。この引数を省略すると、カレントディレクトリが使用されます。

The AIP Format
AIPフォーマット

Each exported item is written to a separate directory, created under the base directory specified in the command-line arguments, or in the current directory if --destination is omitted. The name of each directory is the Handle, URL-encoded so that the directory name is 'legal'.
エクスポートアイテムは、コマンドライン引数で指定したベースディレクトリ、--destinationが省略された場合はカレントディレクトリの下に、アイテムごとに別ディレクトリに出力されます。各ディレクトリの名前はハンドルですが、「正当な」ディレクトリ名にするためにURLエンコードされています。

Within each item directory is a mets.xml file which contains the METS-encoded metadata for the item. Bitstreams in the item are also stored in the directory. Their filenames are their MD5 checksums, firstly for easy integrity checking, and also to avoid any problems with 'special characters' in the filenames that were legal on the original filing system they came from but are illegal in the server filing system. The mets.xml file includes XLink pointers to these bitstream files.
各アイテムディレクトリには、アイテムのMETS形式のメタデータであるmets.xmlファイルがあります。アイテムのビットストリームも同じディレクトリに格納されます。ビットストリームのファイル名はMD5チェックサムです。その第1の理由は簡単にインテグリティを検査できることであり、もう1つの理由は、ファイルがもともとあったファイルシステムでは正当だがサーバのファイルシステムでは不正となるファイル名に含まれる「特殊文字」の問題を避けるためです。mets.xmlファイルにはこれらのビットストリームファイルへのXLinkポインターが含まれています。

An example AIP might look like this:
AIPの例は、以下のとおりです。

The contents of the METS in the mets.xml file are as follows:
mets.xmlファイルにおけるMETSの内容は次のとおりです。

Limitations
制限事項

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

DSpace can apply filters to content/bitstreams, creating new content. Filters are included that extract text for full-text searching, and create thumbnails for items that contain images. The media filters are controlled by the MediaFilterManager which traverses the asset store, invoking the MediaFilter or FormatFilter classes on bitstreams. The media filter plugin configuration filter.plugins in dspace.cfg contains a list of all enabled media/format filter plugins (see Configuring Media Filters for more information). The media filter system is intended to be run from the command line (or regularly as a cron task):
DSpaceはコンテンツ（ビットストリーム）にフィルターを適用して、新しいコンテンツを作成することができます。全文検索のためにテキストを抽出するフィルターと画像を含むアイテムのサムネイルを作成するフィルターが存在します。メディアフィルターは、情報資産格納場所を調べてビットストリームに対応するMediaFilterまたはFormatFilterサブクラスを呼び出すMediaFilterManagerにより制御されています。メディア・フィルター・プラグインdspace.cfgにあるfilter.pluginsの環境設定には動作可能なmedia/formatフィルタープラグインのリストがすべて含まれています(詳しくはConfiguring Media Filtersを参照)。メディア・フィルターシステムはコマンドラインから実行されるようになっています。

[dspace]/bin/filter-media

With no options, this traverses the asset store, applying media filters to bitstreams, and skipping bitstreams that have already been filtered.
オプションなしで実行すると、情報資産格納場所を走査してビットストリームにメディアフィルターを適用しますが、すでにフィルターを適用したことのあるビットストリームはスキップされます。

Available Command-Line Options:

Adding your own filters is done by creating a class which implements the org.dspace.app.mediafilter.FormatFilter interface. See the Creating a new Media Filter topic and comments in the source file FormatFilter.java for more information. In theory filters could be implemented in any programming language (C, Perl, etc.) However, they need to be invoked by the Java code in the Media Filter class that you create.
org.dspace.app.mediafilter.FormatFilterインタフェースを実行させるクラスを作成することにより、自分のフィルタを加えることができます。詳細はソース・ファイルFormatFilter.java にあるCreating a new Media Filterのトピック及びコメントを参照してください。理論上、フィルタは(C、Perlなど)任意のプログラミング言語で実装することができますが、あなたが作った MediaFilter クラスの Java コードによって、起動される必要があります。

Sub-Community Management
サブコミュニティの管理

DSpace provides an administrative tool - 'CommunityFiliator' - for managing community sub-structure. Normally this structure seldom changes, but prior to the 1.2 release sub-communities were not supported, so this tool could be used to place existing pre-1.2 communities into a hierarchy. It has two operations, either establishing a community to sub-community relationship, or dis-establishing an existing relationship.
DSpaceはコミュニティのサブ構造を管理するための管理ツール "CommunityFiliator" を提供しています。通常、この構造はめったに変わりません。しかし、1.2より前のバージョンではサブコミュニティがサポートされていなかったので、このツールを使って、バージョン1.2より前の既存のコミュニティに階層性を与えることができます。このツールには2つの操作があります。1つはコミュニティとサブコミュニティの関係を設定するもので、もう1つは既存の関係を解除するものです。

The familiar parent/child metaphor can be used to explain how it works. Every community in DSpace can be either a 'parent' community - meaning it has at least one sub-community, or a 'child' community - meaning it is a sub-community of another community, or both or neither. In these terms, an 'orphan' is a community that lacks a parent (although it can be a parent); 'orphans' are referred to as 'top-level' communities in the DSpace user-interface, since there is no parent community 'above' them. The first operation - establishing a parent/child relationship - can take place between any community and an orphan. The second operation - removing a parent/child relationship - will make the child an orphan.
よく知られている親/子のたとえを使って動作原理を説明することができます。DSpaceの各コミュニティは、少なくとも1つ以上のサブコミュニティを持つ「親」コミュニティか他のコミュニティのサブコミュニティである「子」コミュニティのどちらか、その両方、どちらでもないのいずれかです。この言葉を使うと、「孤児」は（親であるかもしれないが）親を持たないコミュニティです。「孤児」コミュニティは「上位」に親コミュニティを持たないので、DSpaceユーザインターフェースにおける「最上位」コミュニティとみなすことができます。親子関係を設定する第1の操作は、任意のコミュニティと孤児コミュニティとの間で行うことになります。また、親子関係を解除する第2の操作は子コミュニティを孤児にすることになります。

Using the dsrun utility in the dspace/bin directory, the establish operation looks like this:
dspace/binディレクトリにあるdsrunコマンドを使って、親子の設定は次のように行うことができます。

dsrun org.dspace.administer.CommunityFiliator --set --parent=parentID --child=childID

(or using the short form)
（短縮版も使用できます）

dsrun org.dspace.administer.CommunityFiliator -s -p parentID -c childID

where '-s' or '--set' means establish a relationship whereby the community identified by the '-p' parameter becomes the parent of the community identified by the '-c' parameter. Both the 'parentID' and 'childID' values may be handles or database IDs.
ここで、 -s あるいは --set 引数は、-p 引数で指定されるコミュニティが、-c 引数で指定されるコミュニティの親になるという関係を設定することを意味します。"parentID" と "childID" の値はどちらも、ハンドルかデータベースIDのいずれかです。

The reverse operation looks like this:
設定の解除は次のように実行します。

dsrun org.dspace.administer.CommunityFiliator --remove --parent=parentID --child=childID

(or using the short form)
（短縮版も使用できます）

dsrun org.dspace.administer.CommunityFiliator -r -p parentID -c childID

where '-r' or '--remove' means dis-establish the current relationship in which the community identified by 'parentID' is the parent of the community identified by 'childID'. The outcome will be that the 'childID' community will become an orphan, i.e. a top-level community.
ここで、-r あるいは --remove 引数は、"parentID" で指定されるコミュニティが、"childID" で指定されるコミュニティの親であるという現在の関係を解除することを意味します。その結果、"childID" コミュニティは孤児、すなわち、最上位コミュニティになります。

If the required constraints of operation are violated, an error message will appear explaining the problem, and no change will be made. An example in a removal operation, where the stated child community does not have the stated parent community as its parent: "Error, child community not a child of parent community".
指定した操作が不正な場合は、問題を説明するエラーメッセージが示され、変更は行われません。たとえば、解除操作において、指定した子コミュニティが指定した親コミュニティを持たない場合は、「Error, child community not a child of parent community（エラー、子コミュニティは親コミュニティの子ではありません）」というエラーが発生します。

It is possible to effect arbitrary changes to the community hierarchy by chaining the basic operations together. For example, to move a child community from one parent to another, simply perform a 'remove' from its current parent (which will leave it an orphan), followed by a 'set' to its new parent.
基本的な操作を組み合わせることにより、コミュニティの上下関係に任意の変更を加えることができます。たとえば、子コミュニティの親をあるコミュニティから別のコミュニティに移動するには、現在の親を「解除」し（子は孤児になる）、続いて、新しい親を「設定」するだけです。

It is important to understand that when any operation is performed, all the sub-structure of the child community follows it. Thus, if a child has itself children (sub-communities), or collections, they will all move with it to its new 'location' in the community tree.
任意の操作を行うと、子コミュニティのサブ構造の全てがそれに従うことを理解することが重要です。つまり、子が自身の子（サブコミュニティ）、あるいはコレクションを持つ場合は、それらはすべて一緒にコミュニティツリー上の新しい「位置」に移動することになります。

Copyright © 2002-2008 The DSpace Foundation