この章では、DSpaceシステムの様々な機能的側面を説明します。
データモデル関連図
DSpaceにおけるデータの組織法はDSpaceを使用する組織の構造を反映することを目的としています。各DSpaceサイトはコミュニティに分割されます。コミュニティは一般に、研究室や研究センター、学科に該当します。DSpaceバージョン1.2から、コミュニティに階層構造を持たせることができるようになりました。
コミュニティは、関連するコンテンツを集めたコレクションを持ちます。1つのコレクションが複数のコミュニティに属することができます。
各コレクションは、アーカイブの基本保管単位であるアイテムからなります。各アイテムは1つのコレクションにより保有されます。さらに、1つのアイテムが別のコレクションに属することも可能です。ただし、アイテムを保有するのはただ一つのコレクションです。
アイテムはさらに、1つ以上のビットストリームからなる名前付きバンドルに分割されます。ビットストリームは名前のとおりビットの流れですが、一般的には普通のコンピュータファイルです。たとえば、1つのHTML文書を構成するHTMLファイルと画像のように、何らかの形で密接に関連する1つ以上のビットストリームがバンドルを構成します。
実際、ほとんどのアイテムはたいてい次の名前付きバンドルを持っています。
各ビットストリームは1つのビットストリームフォーマットと結びついています。おそらく保存サービスはDSpaceの重要なサービスの1つですから、ユーザが投稿するファイルのフォーマットを記録しておくことは重要です。DSpaceにおいて、ビットストリームフォーマットはある特定のファイルフォーマットを参照するためのユニークかつ不変の方法です。
ビットストリームフォーマットには必ず、そのフォーマットの資料をどのように解釈するかを暗示的あるいは明示的に示す概念が含まれています。
たとえば、静止画像圧縮に関するJPEG規格で符号化されたビットストリームの解釈は、規格ISO/IEC10918-1において明示的に定義されています。一方、マイクロソフトWord2000フォーマットのビットストリームの解釈は、マイクロソフトWord 2000アプリケーションソフトを参照することで暗示的に定義されています。
ビットストリームフォーマットは、MIME型やファイル拡張子よりファイルを明確に特定することができます。たとえば、application/ms-wordや.docは、おそらく異なる意味のビットストリームを生み出す複数のバージョンのマイクロソフトWordを表しています。
各ビットストリームフォーマットはさらに、サポートレベルを持っています。これは、運営機関がそのフォーマットのコンテンツを将来にわたってどの程度保存できるかを示しています。運営機関が設定できるビットストリームフォーマットのサポートレベルには3つの選択肢があります。運営機関はその経費と要件について慎重に検討した上で各サポートレベルの正確な意味を決める必要があります。MIT図書館での解釈は次のとおりです。
| サポート （Supported） |
フォーマットを認識している。運営機関は必要に応じて適切な技術（データ移行やエミュレーションなど）を用いることで、このフォーマットのビットストリームを将来にわたって利用可能とする自信がある。 |
| 既知 （Known） |
ファーマットを認識している。運営機関はこのビットストリームをそのままの形で保存し、取り出せるようにすることを約束する。運営機関は、このフォーマットを「サポート」レベルに格上げするために十分な情報を得る努力をする。 |
| 未サポート （Unsupported） |
フォーマットを認識していない。しかし、運営機関はこのビットストリームをそのままの形で保存し、取り出せるようにすることを引き受ける。 |
各アイテムは1つの限定子付きのダブリンコアメタデータレコードを持ちます。その他のメタデータをシリアル化してビットストリームとしてアイテムに格納することもできますが、相互運用性を保ち、発見を容易にするために、DSpaceではダブリンコアをすべてのアイテムに格納しています。ダブリンコアメタデータは、エンドユーザがコンテンツを投稿する際に入力することもできますし、受入の過程で他のメタデータから作成することもできます。
アイテムは次の2つの方法でDSpaceから削除（remove）することができます。1つは「取り下げ（withdrawn）」で、これは、アイテムをアーカイブに残したまま、外部からは完全に見えなくすることを意味します。この場合、エンドユーザが取り下げられたアイテムへのアクセスを試みると、アイテムが取り除かれたことを示す「墓石」ページが表示されます。 理由は何であれ必要であればアイテムを「抹消（expunged）」することもできます。この場合、そのアイテムに関するすべての痕跡がアーカイブから取り除かれます。
| オブジェクト | オブジェクトの例 |
|---|---|
| コミュニティ | コンピュータ科学研究室; 海洋研究センター |
| コレクション | LCSテクニカルレポート; ORC統計データセット |
| アイテム | 1編のテクニカルレポート; 説明書付きのデータセット; 講演を記録したビデオ |
| バンドル | 1つのHTML文書を構成するHTMLファイルと画像ビットストリームの集合 |
| ビットストリーム | 1つのHTMLファイル; 1つの画像ファイル; 1つのソースコードファイル |
| ビットストリームフォーマット | マイクロソフトWord バージョン6.0; JPEGにより符号化された画像フォーマット |
大まかに言って、DSpaceは保管するコンテンツに関する次の3種類のメタデータを持っています。
各アイテムは、1つの限定子付きのダブリンコアメタデータレコードを持っています。 MIT図書館で使用している要素・限定子セットが、デフォルト設定として、DSpaceソースコードに含まれています。 これはいくつか異なるものもありますが、おおよそLAP（Library Application Profile）の要素・限定子セットに基づいています。
アイテムについてのその他の記述メタデータを、シリアル化したビットストリームとして持つことができます。 コミュニティとコレクションは簡単な記述メタデータ（名前といくつかの記述的文章）を持ち、DBMSに保管されます。
このメタデータには、保存メタデータ、来歴メタデータ、権限ポリシーメタデータが含まれます。これらのほとんどはDSpaceのRDBMSスキーマに含まれています。来歴メタデータ（文章）はダブリンコアレコードに格納されます。さらに、その他の管理メタデータのいくつか（たとえば、ビットストリームのバイト数やMIME型）はダブリンコアに複製されているので、DSpaceの外部から容易にアクセスすることができます。
このメタデータには、アイテムやアイテムに含まれるビットストリームをエンドユーザに対してどのように見せるかについての情報およびアイテムを構成するオブジェクトの間の関係が含まれます。 例として、数多くのTIFF画像からなる学位論文を考えます。各TIFF画像は論文の1ページ分を表わしているとします。 この場合、構造メタデータは、各画像が1ページを表わすという事実、および、TIFF画像（ページ）の順序を含むことになるでしょう。 DSpaceにおける構造メタデータは現在のところきわめて基本的なものです。なぜなら、上で述べたように、アイテムにおいて、ビットストリームをバンドルにまとめることができるからです。バンドルはオプションとして第一ビットストリームを持つことができます。これは現在、HTMLサポートにおいて、バンドルに含まれるビットストリームのうち、どのビットストリームを最初のHTMLファイルとしてブラウザに送信するかを示すために使用されています。
基本的な技術メタデータに加えて、ビットストリームはアイテムにおいてビットストリームを一意に識別する「シーケンスID」も持っています。これは各ビットストリームの「永続的」ビットストリーム識別子を作る際に使用されます。
さらなる構造メタデータをシリアル化してビットストリームとして格納することもできますが、現在のところ、プログラムを改造しないとDSpaceはこれを理解しません。
文書の発見や取り込みといったDSpaceの多くの機能は、匿名で利用できます。しかし、投稿や電子メールによる通知（「購読」）、運用管理といった機能を実行するにはユーザ認証が必要です。また、管理を容易にするためにユーザはグループ化されます。DSpaceでは、ユーザをe-personと呼びます。これは、ユーザが人間ではなく機械である場合もあることを反映しています。
DSpaceは各e-personについて以下の情報を持ちます。
e-personは、ユーザ名とパスワードの組、X509証明書（X509証明書認証モジュールを設定）、LDAPのいずれかで認証されます。e-personは、管理者による権限ポリシーの操作を容易するにするために何らかの「グループ」のメンバーになることができます。
DSpaceの権限付与システムは、オブジェクトに対するアクションとアクションを実行できるe-personのリストの関連付けに基づいています。 この関連付けのことをリソースポリシーと呼びます。また、e-personのリストをグループと呼びます。 2つの特別なグループがあります。サイト内のすべてのアクションを実行できる「管理者」グループと、すべてのユーザが含まれる「匿名」グループです。 あるオブジェクトに対するあるアクションを匿名グループに割り当てるというポリシーは、そのアクションをすべての人に許可することを意味します。 （たとえば、DSpaceのほとんどのオブジェクトは、「匿名」グループにREAD権限を与えるポリシーを持っています。） 許可は明示的に与える必要があります。明示的な許可がない場合は、デフォルトポリシーである「不許可」となります。 許可は「継承」もされません。たとえば、あるe-personがあるアイテムのREAD許可を持っていたとしても、必ずしもそのe-personがそのアイテムのバンドルやビットストリームに対するREAD許可を持っているとは限りません。 現在のところ、コレクション、コミュニティ、アイテムはREAD権限の保持の有無にかかわらず、ブラウズや検索システムで発見することができます。
以下のアクションが用意されています。
コミュニティ
| ADD/REMOVE | コレクション、あるい、はサブコレクション追加・削除 |
コレクション
| ADD/REMOVE | アイテムの追加・削除（ADDは、アイテムの投稿を許可） |
| DEFAULT_ITEM_READ | 全ての投稿アイテムにREADを継承 |
| DEFAULT_BITSTREAM_READ | 全ての投稿アイテムのビットストリームにREADを継承 |
| COLLECTION_ADMIN | コレクション管理者はコレクションアイテムの編集、取下げ、他のアイテムの当該コレクションへのマッピングが可能である |
アイテム
| ADD/REMOVE | バンドルの追加・削除 |
| READ | アイテムの閲覧が可能（アイテムのメタデータは常に閲覧可能） |
| WRITE | アイテムの変更が可能 |
バンドル
| ADD/REMOVE | バンドルへのビットストリームの追加・削除 |
ビットストリーム
| READ | ビットストリームの閲覧 |
| WRITE | ビットストリームの変更 |
"DELETE"アクションが存在しないことに注意してください。アーカイブからあるオブジェクト（たとえば、アイテム）を「消去（delete）」するためには、それを含むすべてのオブジェクト（この場合は、コレクション）に対するREMOVE許可を持つ必要があります。「親オブジェクトのなくなった」アイテムは自動的に消去されます。
ポリシーは個々のe-person、あるいはe-personのグループに適用することができます。
受入は、1つのサブシステムというよりむしろ複数のサブシステムにまたがるプロセスです。 下の図はDSpaceにおける現行の受入プロセスを簡単に示したものです。
DSpace受入プロセス
アイテム一括インポータ（Batch Item Importer）はアプリケーションプログラムであり、外部のSIP（提出用情報パッケージ: XMLで書かれたメタデータ文書とコンテンツファイルを持つ）を「投稿処理中（In Progress Submission）」オブジェクトに変換します。 同様に、エンドユーザが「投稿処理中」オブジェクトを作成するためにはWeb投稿ユーザインターフェース（Web Submit UI）が使用されます。
投稿の対象となるコレクションのポリシーに従って、あるワークフロープロセスが開始します。一般に、このプロセスにより、投稿されたものがコレクションにふさわしいものであるかどうかを人や「ゲートキーパ」プログラムがチェックすることが可能になります。
一括インポータや投稿ユーザインターフェースにより、投稿処理中オブジェクトが作成され、受入の次の段階（ワークフロー処理、もしくはアイテムの登録）に移行する際、投稿物のファイル名やコンテンツのチェックサムなどの来歴情報がダブリンコアに追加されます。 同様に、（査読者が投稿を承認したなど）ワークフローが状態を変化させるたびに来歴情報が追加されます。この来歴情報により、ユーザによる投稿以後にアイテムにどのような変化があったのかを追跡することができます。 （履歴システムも実行されていますが、現在のところ来歴情報の方がアクセスが容易です。）
ワークフロープロセスが投稿の承認で終了すると、投稿処理中オブジェクトは「アイテムインストーラ（item Installer）」に送られ、DSpaceのアーカイブアイテムにふさわしい形に変換されます。アイテムインストーラは以下の処理をします。
各コレクションは最大3ステップのワークフローを持つことができます。各コレクションは各ステップを実行するe-personグループを設定することができます。グループが設定されていないワークフローステップは省略されます。 コレクションの全ステップにe-personグループが設定されていない場合は、そのコレクションに投稿されたアイテムは直ちにアーカイブに登録されます。
言いかえると、処理の流れは次のようになります。コレクションが投稿を受け付けます。コレクションにワークフローステップ1に設定されたグループが存在する場合は、そのステップが呼び出され、グループに通知されます。グループが存在しない場合は、ステップ1は省略されます。同様に、ワークフローステップ2とステップ3が、そのステップにグループが設定されている場合に限り実行されます。
あるステップが呼び出されると、そのワークフローステップで行なうべきタスクがグループの「タスクプール」に置かれます。それと知らずにグループのメンバーが同じタスクを重複して実行しないように、グループの誰か1人がタスクプールからタスクを取得と、このタスクはタスクプールから取り除かれます。
タスクプールからタスクを取得したメンバーは次の3つのアクションの内の1つを実行します。
| ワークフローステップ | 実行できるアクション |
|---|---|
| 1 | 投稿の受入を承認、あるいは投稿を却下できる。 |
| 2 | 投稿時にユーザが提供したメタデータを修正できる。しかし、投稿されたファイルの変更はできない。投稿の受入を承認、あるいは投稿を却下できる。 |
| 3 | 投稿時にユーザが提供したメタデータを修正できる。しかし、投稿されたファイルの変更はできない。その後、アーカイブへ登録しなければならない。投稿の却下はできない。 |
DSpaceの投稿ワークフロー
投稿が却下されると、（ワークフロー担当者により記入された）却下の理由が電子メールで投稿者に送られ、投稿物は投稿者の "My DSpace" に戻されます。 投稿者は必要な変更を加えて再投稿することができます。そうするとふたたびワークフロープロセスが開始します。
投稿が「承認」されると、ワークフローの次のステップに送られます。グループにそれ以上ワークフローが設定されていない場合は、投稿物はアーカイブに登録されます。
DSpaceのサイト管理者はワークフローを中止することができます。これは管理用ユーザインターフェースで実行します。
この明らかに恣意的な設計の理由は、MITにおいて最初にこのシステムを採用したコミュニティの要件を満たす最も簡単な方法であったことによります。ワークフローシステムの機能は将来もちろん拡張されるでしょう。
学位論文の著者がe-thesis（電子版の学位論文）の作成中に指導を受けられるようにすることを第1の目的とする指導者設定システムが存在します。このシステムはある人の投稿用ワークスペースにあるアイテムを他の利用者グループ（学位論文の指導者）に結びつけるものです。アイテムに結び付けられたグループはアイテムに設定されたシステムポリシーを持つことが可能となり、指定されたレベルの操作を学生のアイテムに加えることが許可されます。デフォルトとして用意されているポリシーは次の3つです。
DSpaceの他のポリシーセットと同じように、システム管理者は設定されたこのデフォルトポリシーセットを変更することができます。
この機能は、複数の研究者がある投稿物に関して共同作業をしたい場合にも使用することができるでしょう。ただし、共同作業に用いる特別なワークスペース機能はありません。
研究者は自身の研究成果物に対する安定した参照ポイントを求めています。引用の共有から電子メールによるURLの送信といった単純な展開は消滅しました。サイトは予告なく消滅したり、設定が変えられてしまったりすることや、研究結果に対する重要なリンクを設定したブックマークは時間がたてば信用できなくなることをWebユーザが学んだからです。 この問題を解決するために、DSpaceは中心的機能としてDSpaceに保管するすべてのアイテム、コレクション、コミュニティに付与する永続的識別子を生成する機能を設けました。 識別子を永続化するために、DSpaceはストレージや保管場所に依存しないメカニズムで識別子を生成、維持する必要がありました。DSpaceではこの識別子を生成するために、CNRIハンドルシステムを使用しています。 なお、以下の説明ではハンドルシステムの概要については既知であることを前提にしています。
DSpaceではハンドルを主として世界中で一意になる識別子をオブジェクトに割り当てるために使用しています。 DSpaceを運用するサイトはCNRIからハンドル「プリフィックス」を得る必要があります。このプリフィックスを使って識別子を生成すれば、どこか他で生成された識別子と重複することはありません。
現在のところ、ハンドルはコミュニティ、コレクション、アイテムに割り当てられ、バンドルとビットストリームには割り当てられません。なぜなら、時間の経過と共に、その時々のテクノロジーや装置でアクセスできるように、アイテムをビットとして符号化する方法が変更されるかもしれないからです。 新しい規格がデファクトスタンダードになり、古い規格のファイルはオフラインストレージに移されるかもしれません。一般に保存されつづけるのはアイテムであり、特定のビットエンコーディングではありませんので、アイテムを永続的に識別してアクセスを提供すること、そして、そこから適当なビットエンコーディングを作成してユーザにアクセスを提供することだけが意味を持ちます。
もちろん、ファイルの特定のビットエンコーディングを明示的に保存することも可能です。 この場合、そのビットストリームをアイテムの唯一のオブジェクトとし、アイテムのハンドルが本質的にそのビットストリームを指すようにします。 同じビットストリームを他のアイテムに含めて、アイテムの一部としても、個別のビットストリームとしても引用できるようにすることもできます。
ハンドルシステムは、世界規模の名前解決インフラストラクチャとしても重要な役割を果たしています。 すなわち、エンドユーザはハンドルを解決できる任意のサービス（Webページなど）でハンドルを入力することができ、そのハンドルにより識別されるオブジェクト（DSpaceの場合は、コミュニティ、コレクション、アイテムのいずれか）にたどりつくことができます。 ハンドルシステムのこの機能を利用するためには、DSpace運営サイトは、名前解決の要求を受けて名前を解決する「ハンドルサーバ」を同時に稼働させる必要があります。 このためのプログラムはすべてDSpaceのソースコード配布物に含まれています。
ハンドルは次の2つの形で書くことができます。
hdl:1721.123/4567 http://hdl.handle.net/1721.123/4567
この2つの表記は同じハンドルを表わしています。最初の形は、識別子として使用するだけの手軽な形です。2番目の形を使用すれば、Webブラウザでハンドルを解決できるようになります。 エンドユーザは、他のURLと同じようにこの形のハンドルでアクセスするだけです。 CNRIハンドルリゾルバ・プラグインを使うことで、1番目の形のハンドルをあたかも標準的なURLとして解決することのできるブラウザもあります。 しかし、1番目の形は2番目の形からいつでも容易に得ることができますので、DSpaceでは、2番目の形のハンドルを表示しています。その方がエンドユーザにとっても便利だからです。
DSpaceはCNRIハンドルインフラストラクチャを「サイト」レベルにおいてのみ使用していることに注意してください。 たとえば上の例では、DSpaceサイトには"1721.123"というプリフィックスが割り当てられています。 （ローカルパートである"4567"を含む）完全なハンドルと対象となるコミュニティ、コレクション、アイテムの間の関係を維持することはDSpaceサイトの責任です。
DSpace 1.2からDSpaceのビットストリームはさらなる永続的識別子を持つようになりました。この識別子はハンドルより不安定なものです。というのも、この識別子はコンテンツが別のサーバーや組織に移動した場合に有効でなくなってしまうからです（だから、「永続的」という言葉をかぎ括弧で囲みました）。それでも、以前に使用していたデータベースの主キーを使った簡単なURLより容易に永続化を図ることができます。これは外部のシステムがDSpaceに格納されている特定のビットストリームをより確実に参照できることを意味しています。
各ビットストリームはアイテム内で一意のシーケンスIDを持っています。このシーケンスIDを使って次のような形の永続的IDが作成されます。
DSpaceのURL/bitstream/ハンドル/シーケンスID/ファイル名
たとえば次の通りです:
https://dspace.myu.edu/bitstream/123.456/789/24/foo.html
これは、ハンドルがhdl:123.456/789であるアイテムのシーケンスIDが24のビットストリームを参照します。foo.htmlは、ブラウザにヒントを与えるためにこの位置に置かれています。なぜなら、DSpaceは適切なMIME型を提供していますが、ブラウザの中にはファイルが期待する拡張子を持たないと正しく機能しないものがあるためです。
DSpaceはビットストリームを格納する2つの方法を提供しています。1つはサーバーー上のファイルシステムです。もう1つはSRB（Storage Resource Broker）を使用しています。両者は簡単で軽量なAPIを使って実装されています。
SRBの使用はまったくのオプションですが、サーバーー上のファイルシステムに代わって、あるいはファイルシステムと共に使用することができます。SRBについては詳しく説明しませんが、SRBはきわめて堅牢かつ高度なストレージ管理システムであり、基本的に無制限のストレージと、ローカルやリモートのストレージ・リソースにあるコンテンツを複製（簡単な言葉で言えば、バックアップ）するための簡単な方法を提供します。
DSpaceは次のようにたくさんの方法で、エンドユーザがコンテンツを発見できるようにしています。
検索はDSpaceにおける資料発見の基本的コンポーネントです。検索エンジンへのユーザの期待は非常に大きいので、できるだけ多くの検索機能を提供することをDSpaceは目標としています。 DSpaceのインデックス作成・検索モジュールは非常に簡単なAPIを持っています。このAPIにより、新規コンテンツのインデックス作成、インデックスの再作成、アーカイブ全体、あるいは、特定のコミュニティやコレクションを対象とする検索を実行することができます。 APIの背後には、Javaで書かれたフリーウェアの検索エンジンであるLuceneが存在します。 Luceneは、フィールド検索、ストップワード除去、ステミング、インデックス全体を再作成することなく新規コンテンツのインデックスをそのつど追加する機能を、DSpaceに提供しています。 DSpace 1.2.1からLuceneの検索インデックスが設定可能となり、各機関でインデックスを作成するメタデータフィールドをカスタマイズすることができるようになりました。
DSpaceにおける資料発見のためのもう1つの重要なメカニズムはブラウズです。 ブラウズは、ユーザがタイトル索引などの特定の索引を見ながら操作して必要なアイテムを捜し出すプロセスです。 ブラウズ・サブシステムは、ブラウズを実行する簡単なAPIを提供しています。このAPIを使って呼び出し側プログラムは索引や索引の下位区分を指定することができます。 すると、ブラウズ・サブシステムは対象となる索引の一部を表示します。ブラウズすることのできる索引は、アイテムのタイトル、発行日、著者です。 さらに、ブラウズの対象を、特定のコミュニティやコレクションのアイテムに限定することもできます。
現在、DSpaceはビットストリームをそのままの形でアップロード・ダウンロードする機能をサポートしているだけです。これは、PDFやマイクロソフトのワード文書、スプレットシートなど、一般に使用されているファイルフォーマットの大多数にとっては問題になりません。しかし、HTML文書（WebサイトやWebページ）はもっと複雑であり、デジタル保存をする際に大きな影響を与えます。
Webページは通常複数のファイルで構成される。すなわち、互いに参照しあう1つ以上のHTMLファイルと、HTMLファイルから参照されるスタイルシートや画像ファイルである。
Webページはまた、エンドユーザはたいてい気が付かないが、他のサイトのコンテンツにリンクをはったり、インクルードしていたりする。それで、何年か経って保存したWebサイトを見ると多くのリンクが切れていたり、関係のない他のサイトを参照していたりすることにおそらく気づくことになる。
実際、DSpaceに格納されているコンテンツを見ているのか、他のサイトからインクルードしたコンテンツを見ているのか、DSpaceには格納されていないページにナビゲートされているのか、エンドユーザにははっきりとは分からないだろう。この問題は投稿者がHTMLコンテンツをアップロードする際に明らかになる。たとえば、HTML文書は外部のWebサイトやローカルのハードディスクにある画像をインクルードしているかもしれない。投稿者がDSpaceにあるHTML文書を見るとき、彼が使用するブラウザはHTMLにある参照を使用して適切な画像を取り込むことができる。したがって、投稿者には全てのHTML文書が正しくデポジットされたように見える。しかし、その後に別のユーザがそのHTML文書を見ようとした際、インクルードされた画像が外部のサーバーから削除されていれば画像を取り込むことができないことになる。したがって、HTML文書は壊れているように見えることになる。
WebページがWebサーバ上で稼動するソフトウェアにより動的に作成され、変化するデータベースのある状況を表しているにすぎない場合が多い。
これらの問題への対応は非常に活発に研究されている課題です。現在のところ、DSpaceはこの問題の取り扱いやすいほんの一部に対応しているだけです。DSpaceができるのは自己完結した、非動的なHTML文書を保管し、オンラインブラウジング機能を提供することです。具体的に言えば、これは以下を意味します。
diagram.gifはOKimage/foo.gifはOK/stylesheet.cssは駄目http://somedomain.com/content.htmlは駄目http://somedomain.com/content.html）は「そのまま」で格納され、外部のコンテンツをリンクし続ける（DSpaceに格納されたコンテンツの複製へリンクする相対リンクとは対照的である）。したがって、時が経てば、絶対リンクにより参照されるコンテンツは変更あるいは消滅する可能性がある。オープン・アーカイブズ・イニシアティブはメタデータをハーベスとするためのプロトコルを策定しました。 このプロトコルを使うことにより、プログラム処理で複数の情報源からメタデータを抽出（「ハーベスト」）することができ、さらに、このメタデータを使って索引サービスやリンキングサービスなどのサービスを提供することが可能になります。 このようなサービスによりユーザは非常に多くのサイトの情報を1か所でアクセスできるようになります。
DSpaceはアイテムのダブリンコアメタデータを一般の人が（匿名で）アクセスできるように公開します。さらに、コレクションの構造もOAIプロトコルの「セット」を使って公開します。 この機能を提供するために、OCLCが作成したオープンソースのOAICatフレームワークを使用しています。
DSpaceのOAIサービスでは、取り下げたアイテムについての削除情報は提供しますが、「抹消」されたアイテムの情報は提供しません（データモデルの項を参照）。DSpaceはOAI-PMHのresumption tokenもサポートしています。
DSpaceはSFXのOpenURLプロトコルをいくぶん簡単な形でサポートしています。 あなたの機関がSFXサーバを持っていれば、DSpaceはダブリンコアメタデータを使って自動的にすべてのアイテムページにOpenURLリンクを表示します。 さらに、DSpaceは送られてきたOpenURLに応答することができます。 現在のところ、単にOpenURLの情報を検索サブシステムに転送するだけです。結果リストを表示する際、通常、関連するアイテムは（DSpaceにあれば）リストの先頭に表示します。
DSpaceはリポジトリに保管するアイテムにクリエイティブ・コモンズ・ライセンスを付与する機能をサポートしています。このライセンスは従来の著作権の代替物にあたります。クリエイティブ・コモンズについてさらに詳しく知りたい方は、クリエイティブ・コモンズのWebサイトをご覧下さい。このライセンスの使用はサイト全体の設定オプションで指定します。また、ライセンスの選択の際にクリエイティブ・コモンズのWebサイトを利用するので、プロキシサーバを使っている場合はもう1つパラメタを設定する必要があります。クリエイティブ・コモンズを使用するようオプションをセットした場合、ユーザは投稿の際、クリエイティブ・コモンズ・ライセンスを選択するか、これを回避するかを決めることになります。ライセンスが選択されると、ライセンス文のコピーとRDFメタデータがアイテムとともにリポジトリに格納されます。アイテムがクリエイティブ・コモンズでライセンスされていると、Web UIのアイテム表示画面においてライセンス文とクリエイティブ・コモンズのアイコンによりそれが示されます。
上で述べたように、エンドユーザ（e-person）は、コレクションに新規に登録されたアイテムを通知してもらうためにコレクションを「購読」することができます。 コレクションを購読しているユーザには、購読コレクションに前日追加されたアイテムを簡単に説明した電子メールが毎日届きます。 ただし、新しいアイテムが追加されなかった場合は、メールは送られません。ユーザはいつでも購読を止めることができます。
文章による来歴情報は非常に役にたちますが、プログラムで処理することは簡単ではありません。 履歴サブシステムはDSpaceで生じた重大な変更を、後日の「リファクタリング」や再利用に適した形で時間ベースの記録として補足します。
現在のところ、履歴サブシステムは、DSpaceに（アイテムをアーカイブに受け入れたなどの）重大なイベントが生じた際に明示的に呼び出されます。 履歴サブシステムはオブジェクトの現在の状況を記述するRDFデータを作成します。RDFデータは一時的データを記述するオントロジーであるHarmony/ABCを使ってモデル化されており、ファイルシステムに格納されます。 過去のデータに遡る簡単な索引を利用することができます。
DSpaceにはアイテムをインポート・エクスポートするバッチツールが附属しています。アイテムは単純なディレクトリ構造で表現され、ダブリンコアメタデータはXMLファイルに格納されます。このツールはDSpaceと他のシステムの間でコンテンツを移動するための基礎として使用することができるでしょう。
また、METSベースのエクスポートツールもあります。このツールは、アイテムをMETSベースのメタデータとMETSファイルから参照されている関連するビットストリームでエクスポートします。
登録機能は、ビットストリームがアクセス可能なコンピュータストレージにすでに存在することの利点を生かして、アイテムとそのメタデータ、ビットストリームをDSpaceに受け入れるもう一つの方法です。既存のデジタル資産のためのリポジトリ構築がその例になるでしょう。一般的な対話的な受け入れプロセス や一括インポートツールを使用して、DSpaceにメタデータを提供したり、ビットストリームをアップロードしたりするのではなく、登録機能ではメタデータと、ビットストリームの場所をDSpaceに提供します。登録機能を実現するためにDSpaceではインポートツールを変更したものを使用しています。
コンテンツやシステムの利用に関する様々な統計レポートをシステムにより自動的に作成することができます。レポートはDSpaceのログファイルを分析して作成されます。統計は月ごとに出力することができます。
レポートには以下のようなデータが含まれています。
統計分析の結果は月次レポートおよび全体レポートの形で作成でき、ユーザインターフェースを介して利用することができます。レポートは一般公開することも、管理者だけがアクセスできるように制限することもできます。