1. はじめに

World Wide Webのアーキテクチャ [Web Architecture] では対象となる任意のアイテムに言及する際にリソースという用語を使用する。単体のHTMLドキュメントなど、ある種のWebコンテンツは1つのリソースに含まれる。しかし、Web情報の論理単位は、実際はリソースの集合物であることが多い。集合物の例には次のようなものがある。

• 順序を特定しない単純なリソースの集合、すなわち、RDFでいうところのバッグ。たとえば、様々なWebサイトから集めたお気に入りの画像コレクションなど。
• 「前ページ」、「次ページ」アクセスリンクにより互いにリンク付けられている複数ページからなるHTML文書。
• コンテンツとコンテンツに関連する社会的活動を含む「ソーシャルネットワーキング」で公開されている情報。その一例はflickrである。各参加者はエントリページを持っており、このページからセットやコレクションとして組織化された多様なサイズや解像度の画像へのアクセスを提供する。これらの画像はすべて独立したリソースであり、画像に関するコメントや注釈である別のリソースにリンクされている。
• arXivなどの電子文書リポジトリや、DSpace、EPrints、Fedoraなどの機関リポジトリに保管されている学術出版物。これらの出版物は、各々が独自のURIを持つ複数のリソースの集合としてWeb上に登場する。通常、これらリソースの集合は人間が読むことのできる「スプラッシュページ」から成り、LaTeXやPDF、HTMLなど様々なフォーマットの出版物本体へリンクしている。さらに、他の出版物への引用リンクを持つ場合もあるが、これも各々が1つまたは複数のリソースである。
• 前項で述べた複数の学術出版物を本体は保管元リポジトリに置いたまま1つの号として集めたオーバーレイジャーナルの号。号は巻として、巻はさらに雑誌として再帰的にまとめられる。
• ImageWebプロジェクトが実装した方法で意味的にリンク付けされた細胞画像のグループ。各画像は、研究室や博物館、図書館などのリポジトリに存在するリソースとして公開されている。
• [Lynch CTWatch] で構想されたような公開科学成果。上で述べた学術出版物の特徴に加えて、データとデータを視覚化･分析するツールが組み込まれている。

これらの集合物は次のような特徴を示す。

• 1つまたは複数のリソースから成り、全てのリソースが1つのWebサーバにある場合もあれば、Web上に分散している場合もある。
• 集合物のリソース間に、あるリソースが別のリソースと包含関係にある、あるリソースが別のリソースの別バージョンまたは別フォーマットである、といったセマンティクスを表現する関係が存在する場合がある。
• 集合物の1つまたは複数のリソースは、様々な語彙で定義される型（type）を持つ場合がある。そのような型の非公式な例としては「スプラッシュページ」「参考文献」「目次」がある。
• 集合物または集合物の個々のリソースと集合物の外部に存在する情報単位の間に関係がある場合がある。これらの外部リソースは単一のリソースである場合もあれば、それ自身集合物である場合もある。このような関係の例には、引用、ミラー、翻訳などがある。

これらの集合物に実体を関連付け、機械可読な方法で記述するメカニズムにより、ブラウザやクローラなどのWebエージェントは集合物が見えるようになるだろう。そして、この機械可読な記述は、ユーザに集合物のナビゲートや操作を可能とするユーザインターフェースの基礎となる可能性がある。「集合物の認識」が役に立つと思われるアプリケーションやコンテキストの例としては次のようなものが挙げられる。

• クローラベースのサーチエンジンは、この記述を使って、個々のパーツレベルだけでなく集合レベルの粒度でも情報を索引化して検索結果を提供できるだろう。
• ブラウザは、これを活用することにより、機械可読のサイトマップがクローラにナビゲーション情報を提供するように、ユーザに収集リソースに対するナビゲーションツールを提供することができるだろう。
• 保存システムなどの他の自動化エージェントは、この記述を「文書全体」を理解するためのガイドとして使用して、文書の最適な保存戦略を決定することができるだろう [Compound Object]。
• ネットワーク上の情報を採掘・分析して引用分析や書誌計量を行うシステムは、この記述に含まれている集合物の構造に関する知識を使用してより精密に処理を行うことができるだろう。
• 機関リポジトリアプリケーションは、他の機関リポジトリとデータの交換や相互サービスを行うための相互運用性の基礎としてこれを使用することができるだろう。
• この機械可読な記述は、豊富な学術成果とその構成要素の柔軟な再利用やリファクタリングを可能とする高度な学術コミュニケーションシステムの基礎を提供できるだろう [Value Chains][SCOPE]。

本書は、集合体と名付けた、Webリソースの集合物を記述･交換するためのOAI-ORE（オープン･アーカイブズ･イニシアティブ - オブジェクトの再利用と交換）データモデルを記述する。OAI-OREは集合体を記述するリソースマップという概念を導入する。1つのリソースマップは1つの集合体を記述する。すなわち、リソースマップは集合体を構成するリソース（集合リソース）の有限集合を表明する。また、リソースマップは集合体とその集合リソースに付随する型と関係を表現することができる。このデータモデルはWorld Wide Webのアーキテクチャ [Web Architecture] で定義された概念に準拠している。

OREモデルは様々なシリアライゼーションフォーマットで実装することができる。これらフォーマットの詳細は姉妹編のORE文書に記載されている。個別のシリアライゼーションフォーマットの性質とその表現力は、モデルを実装に対応付ける際の詳細に影響を与える場合がある。この対応付けについては各シリアライゼーションの仕様書に詳しく記述されている。

1.1 表記法

本書におけるキーワード「しなければならない（MUST）」「してはいけない（MUST NOT）」「必須とする（REQUIRED）」「とする（SHALL）」「とはしない（SHALL NOT）」「するべきである（SHOULD）」「するべきでない（SHOULD NOT）」「推奨する（RECOMMENDED）」「することができる（MAY）」「オプションである（OPTIONAL）」は、RFC 2119 [IETF RFC 2119] に記述されているように解釈されるものとする。

フォントは次のように使用する。

• クラスや述語を含む語彙用語は、等幅フォントで記載する。述語は、最初の文字は小文字で始め、以後はキャメルケースで単語の区切りを示す。クラスは、最初の文字は大文字で始め、以後はキャメルケースで単語の区切りを示す。
• モデルで使用する実体を定義のために初めて使用する際は太字の斜体で記載する。これらの実体の名前は、各語の先頭を大文字とする。

1.2 名前空間

本仕様書では、次の名前空間とそれを示す接頭辞を使用する。

2. 基盤技術

OREデータモデルは次の基盤技術とアーキテクチャの上に構築する。

• World Wide Webのアーキテクチャ [Web Architecture]。
• RDF [RDF Concepts] およびRDF語彙記述言語 [RDFS] を含むセマンティックWebの諸概念。
• クールなURI [Cool URIs] と Linked Data[Linked Data Tutorial]。

これらの技術に不案内な読者はそれぞれの参考文献にあたることを勧める。これらの技術のORE関連部分の手短な紹介はORE入門でも読むことができる。

3. データモデルの実体

ORE抽象データモデルは以下で記述される実体を含む。

3.1 集合体

集合体（Aggregation）とは、 ore:Aggregation 型のリソースであり、他のリソースの集合である。型 ore:Aggregation は、少なくとも1つの リソースマップによる表明を介して1つのリソースと結び付けられる。リソースマップと集合体の関係は4.1節で記述される。

本仕様書では、集合体を識別するURIをURI-Aで示す。URI-Aは集合体を識別するので、1つの論理単位としてリソース集合を指し示しているリンクの対象物として使用されるべきである。そのようなリンクの例には、引用、レビュー、注釈などがある。

URI-Aは集合体を識別するので、例えば、学術論文のPDFのような何らかのコンテンツを具体的に示すURIや人間が読むことができる「スプラッシュページ」のURI（これは実際にはそのページのみを識別するもので集合体を全体として識別するものではない）など、別の用途に使用されているURIであるべきでない。

URI-AはプロトコルベースのURIでなければならない。ただし、集合体は概念的な構造物であり、表示形（Representation）を持っていない。一方、集合体を表明するリソースマップは表示形を持ち、その中に含まれる表明がクライアントやエージェントに公開される。集合体のHTTP URIから集合体を表明しているリソースマップのHTTP URIを発見できるようにするためにセマンティックWebのためのクールなURIガイドラインが採用された。アクセスメカニズムの詳細については、OREユーザガイド - HTTPによる実装に記述されている。

3.2 集合リソース

集合リソース（Aggregated Resource）とは、これを含む集合体を記述するリソースマップの中で表明されることにより集合体の構成要素となっているリソースである。この表明が行われる方法は4.3節で記述される。

本仕様書では、集合リソースを識別するURIをURI-ARで示す。URI-ARはプロトコルベースのURIでなければならない。

3.3 リソースマップ（ReM）

リソースマップ（Resource Map: ReM）とは、ore:ResourceMap 型で、複数の表明から成る情報コンテンツを持つリソースである。リソースマップは、

• ただ一つの集合体を記述しなければならない。
• 構成要素である集合リソースを列挙しなければならない。
• 集合リソース間の関係や集合リソースと他のリソースの関係、その他のプロパティなど、集合体と集合リソースに関する付加的なプロパティを含むことができる。

これら表明の本質については4.1節で記述される。

各リソースマップはプロトコルベースの1つのURIにより識別されなければならない。このURIは、リソースマップにより識別される集合体のURIとは異なるものでなければならない。本仕様書では、リソースマップを識別するURIをURI-Rで示す。1つの集合体に対して複数のリソースマップが存在することができる。（1つのURI-Rから複数の表示形を作成するのではなく）各リソースマップは異なるURIを持たなければならない。URI-Rを逆参照すると1つのシリアライゼーションが得られる。これから上で述べた表明をトリプルの集合として抽出することができる。このトリプルの集合は結合されるとRDFグラフを形成するが、このグラフは明確に定義された構造に準拠しなければならない。

複数のリソースマップが、1つのURI（URI-A）で識別される同一の集合体に関する表明を含むことができる。これらのリソースマップは次の2つのクラスに分類される。

• 正規リソースマップ（Authoritative Resource Map）とは、それが記述する集合体のURI-Aを逆参照することによりアクセスできるリソースマップである。アクセスメカニズムの詳細については、OREユーザガイド - HTTPによる実装に記述されている。各集合体には少なくとも1つ正規リソースマップが存在しなければならない。1つの集合体に各自がユニークなURI-Rを持つ複数の正規リソースマップが存在できる。上で注意したように、各URI-Rは1つのシリアライゼーションに逆参照されなければならない。このURI-Rの集合から利用できるシリアライゼーションは相異なるフォーマット（ATOMやRDF/XMLなど）であるべきである。ただし、これらのシリアライゼーションから抽出できるRDFグラフは同一の集合体グラフを表し、同一のプロキシを定義しなければならない。
• 非正規リソースマップ（Non-Authoritative Resource Map）とは、URI-Aに関する表明を含むリソースマップで、URI-Aの逆参照により得られる情報から参照できないものである。Webの性格上、エージェントは任意の情報を表明できるので、複数の非正規リソースマップが存在できる。クライアントは、非正規リソースマップを作成したエージェントまたは機関と集合体を作成したエージェントまたは機関は独立しており、後者は前者を認識していないと仮定するべきである。非正規リソースマップは独立したエージェントにより作成されるので、本仕様書ではその構成に関する規則は示さないことに注意されたい。エージェントは非正規リソースマップを作成しないことを推奨する。その代わり、エージェントは別のURI－A（別の集合体）を定義し、その集合体を記述する1つ以上の正規リソースマップを定義し、以下で述べる方法を使用して2つの集合体の関係を表明するべきである。

特に言及しない限り、本仕様書ではこれ以降、正規リソースマップについてのみ記述する。限定子「正規」は特に強調する場合にのみ使用する。

3.4 プロキシ

プロキシ（Proxy）とは、ore:Proxy 型のリソースであり、特定の集合体のコンテキストにある集合リソースを示すものである。型 ore:Proxy は、プロキシのコンテキストである集合体を記述するリソースマップに書かれた表明を介してリソースと関連付けられる。本仕様書では、プロキシのURIをURI-Pで示すが、これは該当する集合体のコンテキストにある集合リソースに特有な表明の中で使用することができる。これは、集合体に対して特別な意味を持たない集合リソースのURI-ARとは対照的である。プロキシの使用は、オプションであり、5.3節で記述される。

プロキシURI（URI-P）は、集合体（URI-A）とその集合体の特定の集合リソース（URI-AR）の両者に対してユニークなものでなければならない。上で述べた用語を使えば、これは、あるURI-Aの正規リソースマップで表明されているURI-Pは、別のURI-Aを記述するリソースマップで表明されていてはいけないことを意味する。HTTPを使って実装される場合、プロキシURIはしかるべき要件に準拠するべきである。

4. リソースマップのRDFグラフ - 基礎編

リソースマップは、集合体、その構成要素である集合リソース、集合体とリソースマップに関するメタデータ、およびその他の関係に関する情報を表しているRDFトリプルの集合を表明する。リソースマップで表明されているトリプルによって明示されるRDFグラフは、数多くの制約に従わなければならない。このグラフは以下で定義される（また、各項目に示されている番号の節で拡張されている）構造を持ち、接続されていなければならない。

• グラフは、リソースマップとリソースマップで記述されている集合体の関係を表現しなければならない（4.1）。
• グラフは、リソースマップに関する基本的なメタデータを表現しなければならない。また、リソースマップと集合体に関する付加的なメタデータを表現することができる（4.2）。
• グラフは、集合体とその集合体を構成している1つ以上の集合リソースとの関係を表現しなければならない（これらの関係から生じるリソースマップのサブグラフは集合体グラフと呼ばれる）（4.3）。
• グラフは、集合体と類似リソースの関係を表現することができる（4.4）。
• グラフは、集合体グラフのリソースと他のリソースや型との関係を表現することができる（4.5）。

以後、本節ではこのグラフの構成要素について順を追って説明する。グラフに対する制約は本書の最後に表の形でまとめている。

第5節では、このRDFグラフを拡張して、複数の集合体の間の関係や集合体特有のURIを集合リソースに指定するプロキシの使用を表明する方法について説明する。

4.1 リソースマップと集合体の関係

リソースマップは、述語 ore:describes を持つトリプルを1つ含んでいなければなければならない。このトリプルの主語はリソースマップのURI-Rでなければならない。目的語はリソースマップにより記述される集合体のURI-Aである。このトリプルの目的語であるURI-Aは、URI-Rと同じであってはいけない。リソースマップは、述語 ore:describes を持つトリプルを2つ以上含んでいてはいけない。

関係 ore:describes は、主語で示されるリソースが ore:ResourceMap 型のリソースであり、目的語で示されるリソースが ore:Aggregation 型のリソースであることを表明する。したがって、これらの型を表明するトリプルをリソースマップに明示的に含めることはオプションである。

下の図は、リソースマップと集合体の関係を表現しているRDFグラフを示している。グラフを作出するトリプルがグラフの下に示されている。トリプルの右側の表はリソースと関係の識別に使用されているURIを示している。トリプル表におけるURIの構文は説明用のものに過ぎないので、読者は識別されるリソースに関するメタデータをこのURIの形から推測するべきでない。OREユーザガイド - HTTPによる実装は、OREで使用されるURIの推奨構文に関する実装上の詳細を説明している。

先に述べたように、複数のリソースマップがトリプルの目的語として同一のURI-Aを持つ ore:describes 関係を表明することができる。複数のリソースマップが存在する場合、各リソースマップは、互いに正規リソースマップの関係であることを表現する述語 ore:isDescribedBy （ore:describes の反対）を持つトリプルを表明するべきである。これらのトリプルは、代替となるリソースマップのシリアライゼーションをクライアントに見えるようにする。

下の図は、複数のリソースマップの存在と述語 ore:isDescribedBy の使用を示している。表に示されている表明は、図では ReM-1 で表現されていることに注意されたい。

4.2 リソースマップと集合体に関するメタデータ

リソースマップは、リソースマップに関する最低限のメタデータプロパティを表現しなければならない。そのメタデータプロパティは次のとおりである。

• リソースマップの著作者たる実体（人間、組織、または、エージェント）。述語 dcterms:creator を使用し、その目的語は http://purl.org/dc/terms/Agent 型のリソースへの参照でなければならない。これは、次のトリプルの主語になることができる。
  • 述語が foaf:name で、その目的語が著作者を記述する何らかの名前を含むテキスト文字列であるトリプル。
  • 述語が foaf:mbox で、その目的語が著作者のメールアドレスのURIであるトリプル。
• リソースマップの最新更新日付タイムスタンプ。用語 dcterms:modified を使用する。この日付タイムスタンプは、これを利用するクライントが適切なアクションを決定できるように、リソースマップで表明され、そのリソースマップのシリアライゼーションで表現されているトリプルが変更された際は更新されなければならない。

リソースマップは、リソースマップに関する付加的なメタデータプロパティを含むことができる。付加的メタデータプロパティの例には次のものがある。

• リソースマップの使用に関する権利情報。用語 dc:rights を使用する。（リソースマップに関する権利情報は集合体のそれとは異なることに注意されたい。後者については下で述べるように別に記述することができる。）
• リソースマップを最初に作成した日付タイムスタンプ。用語 dcterms:created を使用する。

リソースマップは、集合体に関するメタデータプロパティを表明することができる。これらのメタデータプロパティは様々な語彙で定義することができる。一般的なメタデータプロパティは集合体の著作者たる実体（人間、組織、またはエージェント）であり、述語 dcterms:creator を使用する。

下の図は、リソースマップと集合体に関するメタデータプロパティを含むリソースマップにより表現されるRDFグラフを示している。この図で導入された概念を強調するために既に説明済みのグラフの部分は灰色になっていることに注意されたい。図をより簡単に読めるようにするために、この方法を他の簡素化と共にこれ以降最後まで使用する。

4.3 集合リソースと集合体グラフ

リソースマップは、述語 ore:aggregates を持つトリプルを1つ以上含むことができる。各トリプルは、URI-ARで識別される述語の目的語が、URI-Aで識別される主語の集合リソースであることを表明する。URI-ARは、述語 ore:aggregates の主語である集合体のURI-Aと同じであってはいけない。

関係 ore:aggregates は、主語で示されるリソースが ore:Aggregation 型のリソースであることを定義する。したがって、この型を表明するトリプルをリソースマップに明示的に含めることはオプションである。

リソースマップは、集合リソースが別の集合体の構成要素であることを表明するために、述語 ore:isAggregatedBy を持つ1つ以上のトリプルを含むことができる。

下の図は、述語 ore:aggregates を持つトリプルを追加したRDFグラフを示している。集合体をルートとし、集合リソースとの ore:aggregates 関係を1つ以上持つ、このRDFグラフのサブグラフは集合体グラフ（Aggregation Graph）として知られている。先に述べたように、同一の集合体を記述するすべての正規リソースマップは同一の集合体グラフを表明しなければならない。

リソースマップ 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 . }

4.4 集合体と類似リソースの関係

リソースマップは、主語としてURI-Aを持ち、その集合体が別のリソースと類似のコンテンツを持つリソースであることを表明するトリプルを1つ以上含むことができる。その述語は、rdfs:seeAlso か ore:similarTo のいずれかであることができる。実際に使用される述語は類似度の表明の度合いによる。

関係 ore:similarTo は、集合体がトリプルの目的語で識別されるリソースと類似した知的内容を持っていることを表明する。学術コミュニケーションのコンテキストで ore:similarTo を使用する例は、デジタルオブジェクト識別子（DOI） [DOI] や info URI [INFO] などの非プロトコルベースのURIを持つリソースと集合体の関係である。

より類似度の低い rdfs:seeAlso をリソースマップで使用する例は、同一のDOIと ore:similarTo 関係を持つ2つの集合体の間の関係である。

リソースマップにおける述語 ore:similarTo と rdfs:seeAlso の使用を下の図に示した。

4.5 他のリソースや型との関係

リソースマップは、リソースマップ、集合体、集合リソース、または他の関連するリソースやリテラルに関するプロパティを表明する付加的なトリプルを含むことができる。これらトリプルの追加により作出されるRDFグラフは、接続されていなければならない。正式には、リソースマップを示すノードから始まってトリプルで表現されている述語に対応する辺に沿って移動することにより、グラフのすべてのノードに到達できなければならないことを意味する。

付加的関係の適切な使用法は次のようなものである。

• これらの関係は集合体グラフのノードのセマンティックな型を定義することができる。この場合、主語は集合体グラフのノード（集合体または集合リソースのURI）であり、述語は rdf:type、目的語は任意の語彙で定義されたクラスのURIである。
• これらの関係は集合体または集合リソースと他のリソースとの関係を定義することができる。これらの関係の述語は任意の語彙で定義することができる。これらの関係は集合体グラフや集合体に関するメタデータプロパティ、引用連鎖、ミラーなどを表現する際に役に立つ。

これら付加的な表明の適用範囲は、RDF表明文が解釈されるグローバルなものと同じである。すなわち、これら付加的なトリプルの意味は、リソープマップにおけるその「表明コンテキスト」により制約されたり、変更されたりはしない。各表明は基本的に独立である。したがって、主語にURI-ARを持つトリプルはそのリソースに関する表明文であり、そのリソースが特定の集合体に存在するということには関係がない。所属する集合体によりコンテキストを持たされたリソースのプロキシを使った表明は、5.3.1節で説明する。

下の図は型セマンティクスおよび集合体グラフとのその他の関係を表現するトリプルを追加したRDFグラフを示している。

5.リソースマップのRDFグラフ - 上級編

ここまで、本仕様書は個々の集合体を記述するメカニズムを記述してきた。この節では、1つのリソースマップで集合リソースと他のリソースマップや集合体との関係を表明することができるようにするメカニズムを記述する。

5.1集合リソースが別の集合体の構成要素であることを表明する

リソースマップは、集合リソースが別の集合体の構成要素であることを表明する述語 ore:isAggregatedBy を持つトリプルを1つ以上含むことができる。

ユースケースには flickr がある。flickrでは、1枚の写真は複数のセットのメンバーになることができる。あるセットを記述するリソースマップが、その構成要素である写真が別のセットのメンバーであることを示す情報を含むかもしれない。下の図は、flickrの3つのセットに対応した3つの集合体 A-1, A-2, A-3 を示している。すべての集合体は、ある画像 AR-3 を集合リソースとして含んでいる。flickrのセット A-3 を記述するリソースマップ ReM-3 は、AR-3 が集合体 A-1 と A-2 で示されるセットの構成要素であることを表明する述語 ore:isAggregatedBy を持つトリプルを含んでいる。

5.2 ネストした集合体

先に述べたように、すべてのリソースは何らかの集合体の集合リソースになることができる。集合体はそれ自体がリソースであるので、他の集合体の集合リソースになることができる。その結果、集合体が再帰的にネストされることになる。1つのリソースマップは唯1つの集合体を記述しなければならないので、このネストは複数のリソースマップで表現されなければならないことに注意されたい。

集合リソースとして別の集合体を表明するリソースマップは、この集合リソースとそれを記述しているリソースマップの関係 ore:isDescribedBy を表明することができる。これはネストしたリソースマップの情報をクライアントに与える。

この述語 ore:isDescribedBy の使用は、先に述べたものと同じセマンティクスを持つことに注意されたい。この述語は、トリプルの主語である集合体はトリプルの目的語であるリソースマップにより記述されていることを表明する。

ネストした集合体の例は、複数の巻号から成る雑誌である。各巻号は複数の論文の集合体であり、各論文もまたそれ自身集合体の場合がある。下の図はネストした集合体を示しており、先の図から若干細部を省略した（メタデータや型付けなど）ものである。ReM-1 により記述されている集合体 A-1 は、それ自体が集合体である AR-1, AR-2, AR-3 を構成要素として持っている。これらの「集合集合体（aggregated Aggregation）」は、その集合リソースとこれら集合体の他の側面を記述する各自のリソースマップ（ReM-2, ReM-3, ReM-4）で記述されている。図では、この例に関連するトリプルが ReM-1 に限定されるという事実を強調するために、ReM-1以外のリソースマップに関係するサブグラフをわざと灰色にしている。

5.3.集合リソースのプロキシ

本仕様書ではこれまで、集合リソースのURI-ARをトリプルの主語または目的語として使用してきた。先に述べたように、URI-ARは集合体に特有のものではない。すなわち、個々のURI-ARは複数の集合体の中で表明されることができ、また、どんな集合体とも独立に使用することができる。したがって、URI-ARをトリプルの主語または目的語として使用することが、特定の集合体、あるいは任意の集合体との間の何らかの関係を意味することは一切ない。

ある集合体のコンテキストに特有の形で集合リソースとの関係を表明することが役に立つ場合がある。このような関係は、集合リソース間、または集合リソースと集合体の外部にあるリソースとの間に存在する可能性がある。その場合、URI-ARとは異なるURIが必要になる。

この節では、プロキシ（Proxy）という概念を記述する。これは、ある集合体に特有の形で集合リソースを「代理する」リソースである。このプロキシのURI-Pは、対象とするセマンティクスが各自の集合体のコンテキストにある集合リソースに特有の関係であるトリプルで使用することができる。プロキシの表明はオプションであり、コンテキスト特有の表明は必ずしも必要ではないことに注意されたい。

プロキシのURI-Pは集合体に対してユニークでなければならない。リソースマップは、2つのトリプルを表明して、プロキシを集合体と集合リソースに結びつけなければならない。

• 1つ目のトリプルは、主語にはプロキシのURI、述語は ore:proxyFor、目的語には関連する集合リソースのURIを持つ。
• 2つ目のトリプルは、主語にはプロキシのURI、述語は ore:proxyIn、目的語には関連する集合体のURIを持つ。

リソースマップは、各プロキシについてこれらトリプルの対を1つだけ表明しなければならない。集合体のすべての正規リソースマップは同一のプロキシを表明しなければならない。

以後本節では、プロキシのユースケースとリソースマップにおけるプロキシの表現方法について記述する。

5.3.1 プロキシ: 集合リソース間の関係

プロキシを使って集合リソース間の関係を表す例には集合リソースを順序付けする表明がある。これは、AR-1, AR-2, AR-3の順に順序付けされたリストを表現する。何らかの順序付け情報がなければ、集合リソースの順番を推測することは不可能であり、その結果、順序付けのない集合を形成することになる。この順序付けをリソースマップで <AR-1> <hasNext> <AR-2> のようなトリプルの表明で表現することは合理的でないだろう。なぜなら、この事実が真であるのは特定の集合体のコンテキストだけであり、「グローバルな」事実ではないからである。先に述べたように、RDFにおいてはトリプルの意味はリソースマップにおける「表明コンテキスト」により制約されたり、変更されたりはしない。各表明は基本的に独立である。したがって、主語または目的語にURI-ARを持つトリプルはそのリソースに関する表明文であり、そのリソースが特定の集合体に存在するということには関係がない。それ故、先に述べた「順序」のような関係は、特定の集合体によるコンテキストを持たされた集合リソースを示すプロキシを使って表現されなければならない。

次の図は、この集合体特有の順序付けをリソースマップにおけるプロキシの定義と関連トリプルの表明により表現する方法を示している。図で使用されている仮想的な述語 xyz:hasNext は2つの集合リソース間の順序関係を示す。リソースマップ ReM-1 は2つのプロキシ P-1 と P-2 を定義している。また、プロキシを対応する集合リソースと集合体に結び付ける述語 ore:proxyFor と ore:proxyIn を持つトリプルも表明している。そして、これらのプロキシは、この集合体のコンテキストにおける順序関係を表明している述語 xyz:hasNext の主語と目的語になっている。

5.3.2. プロキシ: 外部で表明された集合リソースの関係

プロキシは、そのトリプルで表明される関係が特定の集合体によるコンテキストを持たされた集合リソースに特有の意味を持つ、どこか別の場所で表明されるトリプルの主語または目的語になることができる。

下の図は、このプロキシの使用例を示している。この例では、集合体 A-1 はある選ばれたトピックに関するWeb上で見られる最高の学術論文のコレクションだとする。AR-1 はこれに選ばれた論文の1つである。トリプル <URI-2> <xyz:cites> <AR-1> で表明されているこの論文の引用は、この論文が「最高の論文」コレクションに選ばれたという意味を担っていない。なぜなら、URI AR-1 はこの論文の識別子にすぎないからである。一方、トリプル <URI-1> <xyz:cites> <P-1> は、P-1 が AR-1 のプロキシであることがリソースマップで表明されており、意味的に「最高の論文」コレクションの構成要素としてこの論文を引用していることになる。

プロキシの表明はオプションである。この例は、リソースマップを作成する機関がこれらのプロキシを表明して外部のクライアントに適切なリンクターゲットを提供することに意味がある場合があることを示している。

5.3.3. プロキシ: 集合リソースの由来

先に述べたように、述語 ore:isAggregatedBy は、ある集合体の集合リソースが別の集合体の集合リソースでもあることを表明する。実際、1つの集合リソースは複数の集合体に入ることができ、それ故、複数の ore:isAggregatedBy トリプルの主語になることができる。学術コミュニケーションなどの応用においては、集合リソースが別の集合体を起源としたり、別の集合体から供給されたことを示す由来（lineage） というより強い関係に対するニーズが存在する。由来または来歴は学術コミュニケーションにおける完全性の基礎の1つである。

リソースマップは、この概念を表現するために述語 ore:lineage を持つトリプルを表明することができる。ore:lineage の主語はその集合体特有のプロキシでなければならず、目的語は別の集合体特有のプロキシでなければならない。主語、目的語の両プロキシリソースは同一の集合リソースのためのプロキシでなければならない。言い換えれば、主語であるプロキシを定義するリソースマップはトリプル <P-1> <ore:proxyFor> <AR-1> を含んでいなければならず、目的語であるプロキシを定義するリソースマップはトリプル <P-2> <ore:proxyFor> <AR-1> を含んでいなければならない。ここで、AR-1 はどちらのトリプルにおいても同じものである。1つのプロキシは、1つのリソースマップで表現される2つ以上の ore:lineage 関係の主語であってはいけない。

次の図は、ore:lineage の使用を示している。集合体 A-1 は、何らかのデータセット AR-1 とここには示されていない別のリソースを持つeサイエンスの成果を集めたものである。集合体 A-2 も同一のデータセットを含んでいる。両リソースマップは共に、このデータセットに集合体特有のURIを作成（A-1には P-1 と A-2 には P-2）して、この集合リソースにプロキシを設定している。ReM-2 はトリプル <P-2> <ore-lineage> <P-1> を表明して、データセットの出自または来歴が集合体 A-1 にあることを表現している。

6.リソースマップに関する構造上の制約

以下の表は、様々な形態のトリプルの想定出現数の最小値と最大値を示すことにより、リソースマップとして機能するRDFグラフの構造上の制約をまとめたものである。

この表では以下の記法を使用している。

• ReM-1 はこのリソースマップのURIである。
• ReM-i は別のリソースマップのURIである。
• A-1 はリソースマップ ReM-1 で記述される集合体のURIである。
• Agent はエージェントのURIである。
• AR-j は集合体 A-1 に集められたリソースのURIである。
• URI-Subject はリソースのURIである。
• URI-Property はある種の関係のURIである。
• URI-Object はリソースのURIである。
• A-k はリソースマップ ReM-1 で記述される集合体以外の集合体のURIである。
• P-j は集合体 A-1 に集められたリソース AR-j のためのプロキシのURIである。
• P-m はリソースマップ ReM-1 で記述される集合体以外の集合体に集められたリソース AR-m のためのプロキシのURIである。

下のUML図はOREモデルにおける主要な実体間の関係を示している。

7. 参考文献

[Cool URIs]

Cool URIs for the Semantic Web Leo Sauermann, Richard Cyganiak, Danny Ayers, Max Völkel, 2008-03-31. Available at http://www.w3.org/TR/2008/NOTE-cooluris-20080331/ and latest version at http://www.w3.org/TR/cooluris/ .

[Compound Object]

Compound Information Object Archive Prototype Demonstration, H. Van de Sompel, 2007.

[Dereferencing]

Dereferencing HTTP URIs, R. Lewis, Draft Tag Finding 31 May 2007

[DC RDF]

Expressing Dublin Core metadata using the Resource Description Framework (RDF), Mikael Nilsson, Andy Powell, Pete Johnston, Ambjorn Naeve. DCMI Working Draft, 2006-05-30

[DC Terms]

DCMI Metadata Terms, DCMI Usage Board, 2006-12-18.

[DOI]

The DOI System, The International DOI Foundation.

[INFO]

The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces, H. Van de Sompel, et al., RFC 4552, IETF, 2006.

[Linked Data Tutorial]

How to Publish Linked Data on the Web, Chris Bizer, Richard Cyganiak, Tom Heath, 2007-07-27. Available at http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/20070727/ . Latest version available at http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ .

[OWL]

OWL Web Ontology Language Guide, Michael Smith, Chris Welty, Deborah McGuiness, Editors, W3C Recommendation 10 February 2004, Latest Version http://www.w3.org/TR/owl-guide/.

[RDF Concepts]

Resource Description Framework (RDF): Concepts and Abstract Syntax,, Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Latest version available at http://www.w3.org/TR/rdf-concepts/ .

[RDF Semantics]

RDF Semantics, Patrick Hayes and Brian McBride, Editors, W3C Recommendation 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/

[RDFS]

RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .
Latest version available at http://www.w3.org/TR/rdf-schema/ .

[RFC2119]

IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.

[RFC2616]

IETF RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt .

[Lynch CTWatch]

The Shape of the Scientific Article in The Developing Cyberinfrastructure, C. Lynch, CTWatch Quarterly, August 2007.

[SCOPE]

SCOPE - A Scientific Compound Object Publishing and Editing System. K. Cheung, J. Hunger, A. Lashtabeg, J. Drennan, Proceedings of the 3rd International Digital Curation Conference, 2007.

[SPARQL]

SPARQL Query Language for RDF, E. Prud'hommeaux, A. Seaborne, Editors. W3C Proposed Recommendation, 12 November 2007.
http://www.w3.org/TR/2007/PR-rdf-sparql-query-20071112/
Latest Version available at http://www.w3.org/TR/rdf-sparql-query/

[URI]

Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, IETF RFC3986, January 2005.

[Value Chains]

An Interoperable Fabric for Scholarly Value Chains, H. Van de Sompel, C. Lagoze, J. Bekaert, X. Liu, S. Payette, S. Warner, D-Lib Magazine, 12(10), October 2006.

[Web Architecture]

Architecture of the World Wide Web, Volume One, I. Jacobs and N. Walsh, Editors, World Wide Web Consortium, 15 January 2004.