 |
Open Archives Initiative Object Reuse and Exchange |
 |
|
Open Archives Initiative Object Reuse and Exchange |
|
オープン･アーカイブズ･イニシアティブのオブジェクトの再利用と交換（OAI-ORE）プロジェクトは、Webリソースの集合体を記述、交換するための標準を定義する。本文書はこれらの標準の基礎となる抽象的なデータモデルを記述する。このモデルはWorld Wide Webのアーキテクチャ [Web Architecture] に従っており、集合体に関するRDF記述 [RDF Concepts] をカプセル化するメカニズムとして名前付きグラフ [Named Graph] を活用する。本仕様書は、OAI-ORE仕様書およびユーザガイドを構成する文書の1つである。
1. はじめに
1.1 表記法
1.2 名前空間
2. アーキテクチャの基盤技術
2.1 Webアーキテクチャ
2.2 セマンティックWebとRDF
2.3 名前付きグラフ
3. 集合体
4. リソースマップ（ReM）
4.1 リソースマップの識別（URI-R）
4.2 集合体の識別（URI-A）
4.3 URI-AとURI-Rのセマンティクス
5. リソースマップのRDFグラフ
5.1 リソースマップと集合体の関係
5.2 リソースマップに関するメタデータ
5.3 集合体のその他の識別子
5.4 集合リソースと集合体グラフ
5.5 集合リソース間の関係
5.6 リソースマップにおける付加的関係
5.7 他の集合体との関係
5.7.1 集合リソースと外部の集合体
5.7.2 ネストした集合体の間の関係
5.8 リソースマップに関する構造上の制約
6. 参考文献
本仕様書は、ORE仕様書とユーザガイドを構成する文書の1つである。本文書は、OREモデルの詳細を記述するものであり、高度な説明に興味のない読者や主に本モデルを使用可能にするアプリケーションの実装に興味を持っている読者にはふさわしいものではないだろう。このような読者が最初に読む文書としては、OREユーザガイド - リソースマップ概要がより適している。
World Wide Webのアーキテクチャ [Web Architecture] は対象となる任意のアイテムに言及する際リソースという用語を使用する。リソースにはすべてのものが該当し、他のリソースの集合体（Aggregation）も含んでいる。これらの集合体には次のような例が考えられる。
これらの集合体は次のような特徴を示す。
これらの集合体に実体を関連付け、機械可読な方法で記述するメカニズムは、人間と機械の両Webエージェントに集合体が見えるようにする。これは多くのアプリケーションや状況で役に立つだろう。例えば、
本仕様書は、リソースの集合体に実体を関連付け、その構造とセマンティクスの記述を提供するOREモデルを記述する。OREモデルでは、リソースマップ（ReM）という概念を導入する。リソースマップとは1つのリソースであり、名前付きグラフ [Named Graph] により一連のRDF [RDF Concepts] トリブルをカプセル化したものである。これらのトリブルは、URIを持つ1つのリソースとして集合体を実体化し、集合体に関するメタデータを表現し、集合体の構成要素とこれら要素間の関係を列挙し、集合体とWeb上の他のリソースとの関係を記述する。OREデータモデルはWorld Wide Webのアーキテクチャ [Web Architecture] で定義された概念に準拠している。
OREモデルは様々なシリアル化フォーマットで実装できる。これらフォーマットの詳細は姉妹編のORE文書に記載されている。特定のシリアル化フォーマットの性質とその表現力は、モデルと実装の対応付けの詳細に影響を与える可能性がある。この対応付けについては各シリアル化の仕様書に、詳細に記述されている。
本文書におけるキーワード「しなければならない（MUST）」「してはいけない（MUST NOT）」「必須とする（REQUIRED）」「とする（SHALL）」「とはしない（SHALL NOT）」「べきである（SHOULD）」「べきでない（SHOULD NOT）」「推奨する（RECOMMENDED）」「できる（MAY）」「オプションである（OPTIONAL）」は、RFC 2119 [IETF RFC 2119] に記述されているように解釈されるものとする。
フォントは次のように使用する。
本仕様書では、次の名前空間とそれを示すプリフィックスを使用する。
| プリフィックス | 名前空間URI | 記述 |
|---|---|---|
dc |
http://purl.org/dc/elements/1.1/ |
ダブリンコア要素 |
dcterms |
http://purl.org/dc/terms/ |
ダブリンコア用語 |
ore |
http://www.openarchives.org/ore/terms/ |
ORE語彙用語 |
owl |
http://www.w3.org/2002/07/owl# |
OWL語彙用語 |
rdf |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
RDF語彙用語 |
Webアーキテクチャ概念の完全な記述は、別のサイト [Web Architecture] で見ることができる。以後本文書において、Webアーキテクチャの以下の用語が使用された場合は、簡潔にまとめられた次の意味に解釈されるべきである。
これらの概念の組み合わせは、一般にWebグラフと呼ばれるものを形成する。これは、表現が公開される（リソースを識別する）URIであるノードとリンクである辺を持つ。Webグラフの例を下に示す。ノードOとPは互いにリンクしているが、グラフの他のノードとリンクしていない。このように、この例はWebグラフがすべて接続されているわけではないことを示していることに注意されたい。
本仕様はまた、RDFからセマンティックWebの概念を活用する [RDF Concepts]。RDFでは、リソースは 主語、述語、目的語 の3つの部分から成るトリブル（triple）のセットを使って記述される。主語は記述されるリソースを識別するURIであり、目的語は2番目のリソースのURIまたは字句表現を使って数値や日付などの値を識別するリテラルであり、述語は関係の型を識別するURIである。各トリプルは、述語（URI）で示された型の関係が主語（URI）として識別されるリソースと目的語（URIまたはリテラル）の間に存在することを述べている。
RDFトリブルのセットは、ノードと有向の弧からなる図で表すことができるので、RDFグラフと呼ばれている。この中で各トリプルはノード―弧―ノードから成るリンクで表現される。RDFグラフのノードは、トリプルを構成する主語と目的語である。RDFグラフでは、各ノードはグラフ中の少なくとも1つの別のノードと接続されている。
注: これは「空白ノード」の概念を無視しているので、RDFモデルを若干簡略化したものである。OREモデルでは「空白ノード」を使用しないので、本文書ではこれ以上空白ノードについて言及しない。
RDFグラフの例を下の図に示した。見て分かるように、トリプルの主語と述語は常にURI（グラフでは黄色の丸で、表では山カッコ構文 <A> で示される）であり、目的語はURIかリテラル（グラフでは青色の角丸矩形で、表では引用符で示される）である。
セマンティックWebから借用したもう1つのツール、RDF語彙記述言語 [RDFS] はこれらの関係の型を定義するための語彙を定義するメカニズムを提供する。RDFで定義された関係 rdf:type と組み合わせることにより、この語彙はリソースの型を表現することを可能にする。下の図はこの例を示している。見て分かるように、rdf:type を述語に持つトリプルの目的語は、クラスまたは型を意味するURIである。
最後に、本仕様は名前付きグラフという概念 [Named Graph] 上に構築する。名前付きグラフは、RDFを拡張してトリプルのセット〈グラフ〉に名前〈URI〉を関連付けることを可能にしたものである。名前付きグラフの数多くの性質を以下の図に示した。
この文書のはじめにOREモデルが扱う問題の概略を示すために正式な定義なしに集合体という概念を紹介した。この節の目的は、集合体と呼ばれるリソースのクラスをより正式に定義することである。
集合体（Aggregation）とは、リソースの集合であり、全体として1つの「論理単位」を形成する。集合体を構成する個々のリソースは集合リソース（Aggregated Resource）と呼ばれる。集合体と各集合リソースの間には ore:aggregates 型の関係が存在する。
集合体を構成する集合リソースの間の関係は、存在することが表明されることもあれば、存在しないことが表明されることもある。
集合リソースと外部リソースの間の関係は、存在することが表明されることもあれば、存在しないことが表明されることもある。
各集合体は各々1つのリソースマップで記述される。リソースマップの概念は次の節で定義される。
リソースマップ（Resource Map: ReM）とは、集合体のURIを特定し、その構成、属性、他のリソースとの関係を記述するリソースである。リソースマップは、名前付きグラフと同じようにトリプルのセット〈RDFグラフ〉を通じてこれを行う。このグラフは明確な構造を持っている。
リソースマップと集合体の間には ore:describes 型の関係が存在する。各集合体にはその集合体を記述するちょうど1つのリソースマップが存在し、各リソースマップにはそのリソースマップで記述されるちょうど1つの集合体が存在する。言い換えれば、ore:describes 関係は owl:InverseFunctional [OWL] 型の属性である。
リソースマップはリソースであるので、URIにより一意に識別される。この仕様書では、リソースマップを識別するURIをURI-Rで示す。リソースマップは複数の表現を持つことができ、各表現はリソースマップ文書と呼ばれる。これらの表現は文字コード、表現力、圧縮、その他の特徴で区別することができる。これらの表現の構文は各シリアル化フォーマットに固有であり、ORE仕様書の姉妹編で定義される。各シリアル化フォーマットは、リソースマップの明確な構造に従うトリプルに確定的に対応付けるための明確な規則を持っていなければならない。表現力の劣るシリアル化フォーマットも存在することができる。すなわち、ここで述べるデータモデルの全ての機能を含まなくてもよい。
上で述べたように、この仕様書では集合体を識別するURIをURI-Aで示す。URI-Aは対象となる集合体を記述する1つのリソースマップに対して一意でなければならない。この意味で、各集合体はある1つのリソースマップに書かれた表明と記述によってのみ存在する。したがって、定義により2つのリソースマップで表明・記述される集合体は同じものではありえない。2つのリソースマップで表明されるトリプルは、最低でも対応する集合体を示すURI-Aが異なっていなければならないからである。
このURI-Rと対応するURI-Aとの一対一の関係の強制は、OREデータモデルが実装されるアーキテクチャに依存する。各URI-Aを対応するURI-Rにフラグメント識別子を付加することにより作成する方法がOAI-ORE仕様書とユーザガイドラインで記述されている。この2つのURIに構文上の系統関係があることの利点は、HTTPで実装した場合にURI-RをURI-Aから直接発見できることである。[URI] で定義されているように、フラグメント識別子の解決は、サーバにより（フラグメントがはずされた）URIが解決された後、クライアントに任せられている。したがって、サーバへのURI-Aの逆参照のリクエストはすべてURI-Rの逆参照に帰着する。
以後、本仕様書の例にはフラグメント識別子の方法を使用する。
URI-Aは集合体を示し、対応するURI-Rはその集合体を記述するリソースマップを示すことに注意されたい。クライアントは、URI-RまたはURI-Aへのリンク付けを行う際、またはこれらとの関係を表現する際、この区別を認識するべきである。特に、引用リンクのような「知的オブジェクト」との関係ではURI-RではなくURI-Aを使用するべきである。なぜなら、URI-Rの使用はリソースマップの引用になるが、通常これは引用の対象として意図したものではないからである。
リソースマップは名前付きグラフを特殊化したものである。一般的な名前付きグラフ同様、リソースマップも〈Webアーキテクチャにおける第一級オブジェクトである〉リソースであり、コード化しているトリプルによりRDFグラフを表現する。一般的な名前付きグラフでは、トリプルにより表現されるRDFグラフの構造と構成は定義されておらず、グラフのノードにより定義されるリソースに関する制約は存在しない。
リソースマップにより表現されるRDFグラフは多くの制約に従わなければならない。グラフは以下で定義される（また、各項目に示されている番号の節で拡張されている）構造を持ち、接続されていなければならない。
リソースマップにより表現されるRDFグラフの完全な例を以下の図に示した。以後、本節ではこのグラフの構成要素について順を追って説明する。グラフに対する制約は本文書の最後で表にまとめてある。
リソースマップは、述語 ore:describes を持つトリプルにより対応する集合体との関係を確立しなければならない。ここで、主語はURI-Rであり、目的語は対応するURI-Aである。ore:describes 関係は、主語で示されるリソースが ore:ResourceMap 型のリソースであり、目的語で示されるリソースが ore:Aggregation 型のリソースであることを定義する。したがって、これらの型を表明するトリプルをリソースマップに明示的に含めることはオプションである。
ore:isDescribedBy 関係は ore:describes とは反対の関係である。意味的には、ore:isDescribedBy は ore:describes と owl:inverseOf [OWL] の関係を持つ。これは <ResourceMap> <ore:describes> <Aggregation> という形を持つ全てのトリプルは、その反対の形のトリプル <Aggregation> <ore:isDescribedBy> <ResourceMap> を暗示しており、逆もまた真であることを意味する。リソースマップはこれらの暗示される ore:isDescribedBy トリプルを含めるべきではない。
下の図は、リソースマップと集合体の関係を表明するトリプルとその結果作成されるRDFグラフを示している。各リソースの暗黙の型も示されている。トリプルの右側の表はリソースと関係の識別に使用されているURIを示している。
リソースマップは、リソースマップに関する最低限のメタデータ属性を表現しなければならない。そのようなメタデータ属性は次のとおりである。
リソースマップは、リソースマップに関する追加のメタデータ属性を含めることができる。追加メタデータ属性の例としては次のようなものがある。
下の図は、リソースマップに関するメタデータ属性を含むリソースマップにより表現されているRDFグラフを示す。既に説明済みのグラフの部分は灰色になっていることに注意されたい（この節では最後までこの方法を使用する）。また、この例ではメタデータ関係の全ての目的語がリテラルであることにも注意されたい。ただし、目的語は他のリソースを表すURIの場合もある。
URI-Aで識別されるリソースと等価、または知的関連のある（違う識別子を持つ）別のリソースが存在する場合がある。その一例は、機関リポジトリが所有する文献のスプラッシュページであり、プロトコルベースのURIを識別子に持つ。もう1つの例は、DOI [DOI] であり、これは非プロトコルベースのURIである。
URI-Aで識別されるリソースと他のリソースの間に厳密な等価性が存在する場合、リソースマップはこれら2つのリソース間の関係を述語 owl:sameAs [OWL] を持つトリプルで表現することができる。ここで、主語は集合体のURIであり、目的語は他の識別子である。owl:sameAs が意味していることは、対象となるトリプルの主語と目的語の役目を果たしている2つのURIが交換可能であり、"sameAs" 関係の2つのURIのどちらかに一致するトリプル中の任意のノードは対応するURIのノードと交換可能であることに注意されたい。
URI-Aと他のリソース間の同等関係が弱い場合、リソースマップはこれら2つのリソース間の関係を述語 ore:analogousTo を持つトリプルで表現することができる。ここで、主語は集合体のURIであり、目的語は他の識別子である。この述語を使用する典型的な例は上で述べたスプラッシュページである。このリソースは集合体と等価ではないが、知的見地から言えば両者は「同じものを意味している」。
ここで述べたその他の識別子に関する情報を追加したRDFグラフを以下に示した。
集合体は1つ以上の集合リソースから成る。これらは当然、集合体の構成要素である。これらを列挙するためにリソースマップは1つ以上のトリプルを表現しなくてはならない。このトリプルの主語は対象となる集合体のURIであり、述語は ore:aggregates、目的語はリソースのURIである。ただしこのリソースはリソースマップまたは集合体自身であってはいけない。リソースは複数のリソースマップで集合リソースとして表現されることができることに注意されたい。ore:aggregates 関係は、主語で示されるリソースが ore:aggregation 型のリソースであると定義する。したがって、この型を表明するトリプルをリソースマップに明示的に含めることはオプションである。
下の図は、リソースマップで表現される述語 ore:aggregates を持つトリプルに由来するRDFグラフの部分を色付きで示している。このRDFグラフのサブグラフは集合体グラフとして知られている。各集合リソースの暗黙の型も示されている。その他のノードは灰色で示されている。
リソースマップ http://example.org/ReM-1 に関して、集合体グラフは次のSPARQLクエリで定義される [SPARQL]。
PREFIX ore: <http://www.openarchives.org/ore/terms/>
CONSTRUCT { ?a ore:aggregates ?ar1 . }
WHERE { <http://example.org/ReM-1> ore:describes ?a .
?a ore:aggregates ?ar1 . }
先の節で説明したように、リソースマップで表現される最小限のRDFグラフはリソースマップ自身の属性とリソースマップと対応する集合体の関係を表現する。さらに、ore:aggregates 関係を通して集合体の構成要素であるリソース、すわなち集合リソースを定義する集合体グラフを表現する。
これまでの定義では、上の図で AR-1、AR-2、AR-3 で示される集合リソースの間には何の関係も存在しない。リソースマップは最低限の ore:aggregates 関係に加えて、集合体グラフのノードで示されるリソース間の関係を表現することができる。これらの関係は、包含、フォーマットバリエーションなどの意味を持つ集合体の構造を記述する際に役に立つだろう。これらの関係を表明するトリプルの述語は任意の語彙で定義することができる。
下の図は、リソースマップで定義されたRDFグラフに2つの集合リソース間の関係を表明しているトリプルを追加したものを示している。
リソースマップ ReM-1 に関して、内的関係を表明するトリプルを含むRDFグラフは次のSPARQLクエリにより定義される [SPARQL]。
PREFIX ore: <http://www.openarchives.org/ore/terms/>
CONSTRUCT { ?ar1 ?p ?ar2 . }
WHERE { <http://example.org/ReM-1> ore:describes ?a .
?a ore:aggregates ?ar1 .
?a ore:aggregates ?ar2 .
?ar1 ?p ?ar2 . }
リソースマップで表現されるRDFグラフに、既に述べた接続性以外にもいくつか制約を加える必要がある。たとえば、述語 ore:describes と ore:aggregates の使用は、おそらくリソースマップを示しているノードに直接つながる1つのサブグラフに制限されるべきであり、それにより1つのリソースマップでネストした集合体を表現できないようにするべきであろう。
リソースマップで表現されるRDFグラフは、集合体グラフのノードでは示されないリソースを主語または目的語に持つさらなるトリプルを含むことができる。また、目的語がリテラルであるトリプルを含むこともできる。ただし、リソースマップで表現されるRDFグラフは接続されていなければならない。正式には、これはリソースマップを示すノードから始まってトリプルで表現される述語に対応する辺に沿って移動することによりグラフのすべてのノードに到達可能でなければならないことを意味する。
リソースマップで表現されるRDFグラフは、2つ以上の集合体を記述してはいけない。別の集合体との関係を表現する方法は次の節で説明される。RDFグラフの広がりは、集合体ノードから他の任意のノードまでのグラフ上の距離が最大でも3以内になるように制限することを推奨する。その意図はリソースマップが集合体とその関係の記述以外に使用されないようにすることである。
付加的関係の適切な使用法は次のようなものである。
下の図は、型セマンティクスなどの関係を表現している付加的なトリプルを集合体グラフへ追加したものを示している。
<Aggregation> <ore:aggregates> <Resource> の形の全てのトリプルは、逆の形のトリプル <Resource> <ore:isAggregatedBy> <Aggregation> を暗示する。正式には、ore:isAggregatedBy は、ore:aggregates に対して owl:inverseOf [OWL] の関係を持っている。
集合リソースが同時に別の集合体の集合リソースでもあることを表明するために <Resource> <ore:isAggregatedBy> <Aggregation> の形のトリプルをリソースマップに含めることができる。ore:isAggregatedBy 関係をリソースマップで表明することはオプションであり、ユースケースに依存する。（学術的引用の提供、系統の確立、発見の促進など）使用にふさわしいユースケースであり、トリプルの目的語である集合体が別のリソースマップで記述されている場合に限り、述語 ore:isAggregatedBy を持つトリプルをリソースマップに含めることを推奨する。主語と目的語が同じ集合体グラフのメンバである場合、 ore:isAggregatedBy を持つトリプルをリソースマップに含めることはオプションである。なぜなら、これらの関係はリソースマップで既に表明されている ore:aggregates 関係により暗示されるからである。
ore:isAggregatedBy の表明はオプションであるので、述語 ore:aggregates を持つトリプルがあっても、対応する逆の述語 ore:isAggregatedBy を持つトリプルが同一または別のリソースマップにあることをクライアントは仮定してはいけない。
集合リソースと他の集合体との関係を表明するために ore:isAggregatedBy を使用するユースケースを下の図に示した。リソースマップ ReM-3 で記述されている集合体（A-3）は雑誌であり、集合リソース AR-3 と AR-4 はその学術論文である。図からわかるように、AR-3 はこれも雑誌である他の2つの集合体 A-1 と A-2 にも含まれている。AR-3 の管理者は、この雑誌にアクセスしているクライアントにこのリソースが他の雑誌にも含まれていることを分かるようにしたいと考えた。そのために AR-3 と A-1 および AR-3 と A-2 にそのような関係があることを表明する述語 ore:isAggregatedBy を持つトリプルを A-3 を記述しているリソースマップに含める。
ore:isAggregatedBy 関係のもう1つのユースケースはネストした集合体である。これは、ある集合体の集合リソースがそれ自体別のリソースマップで記述される集合体の場合である。ネストした集合体の例は雑誌である。雑誌は複数の巻号からなるが、各巻号も複数の論文からなる集合体であり、また各論文もそれ自体集合体になりうるものである。下の図はネストした集合体を示したものである。ただし、先の図から（メタデータや型付けなど）細部を若干省略してある。ReM-1 で記述される集合体 A-1 は AR-1、AR-2、AR-3を構成要素として持つが、これらはそれ自体集合体である。これら「集合集合体」（Aggregated Aggregation）の各々は対応するリソースマップ（ReM-2、ReM-3、ReM-4）によりその集合リソースや集合体のその他の側面が記述される。
ネストした集合体を作成・管理する者はネストした集合体を記述するリソースマップに述語 ore:isAggregatedBy を持つトリプルを含めることにより、このようなネストした集合体の「部分かつ全体」という性格を消費クライアントに伝えることを選択できる。この方法により、巻号の1つにアクセスしているクライアントはこの巻号を含む雑誌に直接戻ることができることになる。下の図は、ネストした集合体にこの ore:isAggregated 関係を使用した例を示している。これは上で示した「雑誌と巻号」の例と同じであるが、簡単のために「雑誌」A-1に集められた「巻号」AR-1 を1つだけ示している。図に示されているように、ReM-2 は対象となるネストした集合体 AR-1 に ore:isAggregated 関係を表現することにより「巻号」AR-1が「雑誌」A-1 に「含まれている」という情報を提供している。
以下の表は、様々な形態のトリプルにおける最小と最大の出現数を指定することにより、リソースマップとして作用するRDFグラフの構造に関する制約をまとめたものである
表では以下の記法を使用している。
ReM-1 はりソースマップのURIである。A-1 はリソースマップで記述される集合体のURIである。AR-i は集合体にまとめられた集合リソースのURIである。URI-S はリソースのURIである。URI-P は関係の型のURIである。URI-O はリソースのURIである。A-k はリソースマップで記述される集合体以外の集合体のURIである。| 主語 | 述語 | 目的語 | 出現数（最小、最大） |
注記 |
|---|---|---|---|---|
| ReM-1 | ore:describes |
A-1 | (1, 1) |
リソースマップと集合体の関係（5.1） |
| ReM-1 | rdf:type |
ore:ResourceMap |
(0, 1) |
リソースマップの型付け（5.1） |
| ReM-1 | dc:creator |
リテラルまたはURI-O | (1, *) |
リソースマップに関するメタデータ（必須）（5.2） |
| ReM-1 | dcterms:modified |
リテラル | (1, 1) |
リソースマップに関するメタデータ（必須）（5.2） |
| ReM-1 | URI-P | リテラルまたはURI-O | (0, *) |
リソースマップに関するメタデータ（オプション）（5.2） |
| URI-S | URI-P | ReM-1 | (0, *) |
リソースマップに関するメタデータ（オプション）（5.2） |
| A-1 | ore:aggregates |
AR-i | (1, *) |
集合体と集合リソースの関係（5.4） |
| AR-i | ore:isAggregatedBy |
A-1 | (0, *) |
集合リソースと集合体の関係（5.4） |
| A-1 | rdf:type |
ore:Aggregation |
(0, 1) |
集合体の型付け（5.1） |
| A-1 | owl:sameAs |
URI-O |
(0, *) |
集合体のその他の識別子（5.3） |
| A-1 | ore:analogousTo |
URI-O |
(0, *) |
集合体のその他の識別子（5.3） |
| A-1 | URI-P | リテラルまたはURI-O | (0, *) |
集合体のその他の属性（5.3）/リソースマップにおける付加的関係（5.6） |
| URI-S | URI-P | A-1 | (0, *) |
集合体のその他の属性（5.3）/リソースマップにおける付加的関係（5.6） |
| AR-i | ore:isAggregatedBy |
A-k | (0, *) |
集合リソースと他の集合体の関係（5.7） |
| AR-i | URI-P | リテラル or URI-O | (0, *) |
リソースマップにおける付加的関係（5.6） |
| URI-S | URI-P | AR-i | (0, *) |
リソースマップにおける付加的関係（5.6） | URI-S | URI-P | URI-O | (0,*) |
リソースマップにおける付加的関係（5.6）
|
本文書は、オープン･アーカイブ･イニシアティブの成果です。OAIオブジェクトの再利用と交換プロジェクトへは、アンドリュー･Ｍ･メロン財団、Microsoft社、全米科学財団から資金をご提供いただいています。さらに、ネットワーク情報連合からもご支援をいただいています。
本文書は、OAI-ORE技術委員会（ORE-TC）の会議に基づいています。会議にはOAI-OREリエゾングループ（ORE-LG）も参加しています。ORE-TCの委員は、次のとおりです。Chris Bizer（ベルリン自由大学）、Les Carr（サウサンプトン大学）、Tim DiLauro（ジョンホプキンス大学）、Leigh Dodds（Ingenta）、David Fulker（UCAR）、Tony Hammond（Nature出版グループ）、Pete Johnston（Eduserv財団）、Richard Jones（インペリアル･カレッジ）、Peter Murray（OhioLINK）、Michael Nelson（オールドドミニオン大学）、Ray Plante（NCSAおよび国立仮想天文台）、Rob Sanderson（リバプール大学）、Simeon Warner（コーネル大学）、Jeff Young（OCLC）。ORE-LGの委員は次のとおりである。Leonardo Candela（DRIVER）、Tim Cole（DLF AquiferおよびUIUC図書館）、Julie Allinson（JISC）、Jane Hunter（DEST）、Savas Parastatidis（Microsoft）、Sandy Payette（Fedora Commons）、Thomas Place（DAREおよびティルブルグ大学）、Andy Powell（DCMI）、Robert Tansley（Google, Inc.およびDSpace）
また、OAI-ORE諮問委員会（ORE-AC）のご意見にも感謝いたします。
このページのリソースマップは、http://www.openarchives.org/ore/0.2/datamodel_remから入手できる。
本文書は、Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported Licenseによりライセンスされている。