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