1. はじめに

リソースマップの発見は、利用の前提条件である。リソースマップを発見するただ1つのベストな方法は存在しない。本書は、提案されている様々なリソースマップ発見メカニズムを取り上げるが、これらは、一括発見、リソース埋め込み、プロキシURIの3種類にまとめられる。その各々について例をあげて検討する。今後さらに別の種類や例が登場することが期待される。

1.1 表記法

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

1.2 集合体とリソースマップにリンクする

本書のタイトルはリソースマップの発見と謳っているが、集合体に利用可能なすべてのリソースマップが含まれているので集合体（[OREモデル] におけるURI-A）にリンクした方が自然なシナリオもある。同様に、特定のリソースマップ（URI-R）にリンクした方が自然な場合もある（下の3.1節を参照）。発見と記述は独立しているので、（両者の組み合わせを含む）いずれの方法も採ることができる。両方法が以下の例で示される。しかし、集合体は（[クールなURI] に記述されている意味において）「Web文書」ではないので、URI-Aにリンクする際、作者はMIMEタイプ情報を含めてはいけない。実際、URI-Aの逆参照により複数のMIMEタイプ文書にリダイレクトすることができる。URI-AとURI-Rの関係、およびこれらの値の選択方法については、[ORE HTTP] を参照されたい。

2. 一括発見

一括発見は、エージェントがリソースマップをまとめて発見できるようにするものである。リソースマップのURIの所有者が、そのリソースマップで記述されている集合体のURIの所有者であるとは限らないことに注意されたい。たとえば、サイトYやサイトZにある集合体を記述しているリソースマップをサイトXが公開することができる。リソースマップは数多くのフォーマットでシリアル化することができるが、人気の高いシリアライゼーションは、Atom リソースマップシリアライゼーション [ORE Atom] とAtom配信フォーマット [RFC4287] で定義されているエントリ文書である。したがって、各節には（必要に応じて）転送プロトコル/フォーマットであるAtomと抽象データモデル [ORE Model] における識別および日付スタンプの概念に対する明確な対応付けが表で示されている。

2.1 Atomフィード

サイトがAtomエントリ文書としてシリアル化されたリソースマップを持っている場合、最も簡単で素直な一括公開の方法はそれらをAtomフィードで配信することである [ORE Atom]。Atomフィードと関連するフィードレベルのメタデータはOREのセマンティクスを持っておらず、（Atomエントリ文書である）リソースマップの発見と配信を容易にするためにのみ存在していることを思い出すことが重要である。例えば、次のAtomフィード

http://www.foo.edu/all-rems.atom

を逆参照すると以下を与えることになる。

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

 <title>ReMs at www.foo.edu</title>
 <link href="http://www.foo.edu/" />
 <link href="http://www.foo.edu/all-rems.atom" rel="self"/>
 <updated>2007-08-15T18:30:02Z</updated>
 <author>
   <name>John Doe</name>
   <email>johndoe@foo.edu</email>
 </author>
 <id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>

 <entry>
   <!-- Object1のリソースマップ -->
   ...
 </entry>

 <entry>
   <!-- Object2のリソースマップ -->
   ...
 </entry>

 <entry>
   <!-- Object3のリソースマップ -->
   ...
 </entry>

</feed>

[ Atom ]

上の例は、最も一般的な一括発見方法になると予想しているシナリオを示している。すなわち、一括発見をサポートするために、リソースマップ（Atomエントリ文書）をAtomフィードで配信するというシナリオである。ただし、Atomの link 要素は、リソースマップへのリンクを「正規の」Atomフィードに組み込むことも許している。最新受入学術電子文書を次のAtomフィードで公開している機関リポジトリを考える。

http://library.foo.edu/repository/latest.atom

これを逆参照すると以下を与えることになる。

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

 <title>Latest Scholarly Eprints from Authors at www.foo.edu</title>
 <link href="http://library.foo.edu/repository/" />
 <link href="http://library.foo.edu/repository/latest.atom" rel="self"/>
 <updated>2008-08-15T18:30:02Z</updated>
 <author>
   <name>John Q. Librarian</name>
   <email>johnq@library.foo.edu</email>
 </author>
 <id>tag:library.foo.edu,2008:institutional:repository:latest</id>

 <entry>
   <title>The transformation of scholarly communication</title>
   <link rel="alternate" href="http://library.foo.org/repository/report-2008-13.html"/>
   <link rel="resourcemap" href="http://library.foo.org/repository/report-2008-13.atom"/>
   <id>tag:library.foo.edu,2008:institutional:repository:report-2008-13</id>
   <updated>2008-08-15T18:30:02Z</updated>
 </entry>

 <entry>
   <title>The arXiv: Fourteen Years of Open Access Scholarly Communication</title>
   <link rel="alternate" href="http://library.foo.org/repository/report-2008-12.html"/>
   <link rel="resourcemap" href="http://library.foo.org/repository/report-2008-12.atom"/>
   <id>tag:library.foo.edu,2008:institutional:repository:report-2008-12</id>
   <updated>2008-08-11T02:23:00Z</updated>
 </entry>

</feed>

[ Atom ]

上の例では、Atomエントリ文書はリソースマップではない。「スプラッシュ」ページが /feed/entry/link[@rel="alternate"]@href 要素でリンク付けられ、対応するリソースマップが /feed/entry/link[@rel="resourcemap"]@href 要素でリンク付けられている（relation属性 resourcemap は下の3.1節で導入される）。既に配信フィードを使用しているサイトは、この方法で既存のフィードにリソースマップへのリンクを追加する方法を選択することができる。

2.2 SiteMap

リソースマップと集合体へのリンクだけから成る、あるいは通常のリソースリストにリソースマップと集合体を含めたSiteMap [SiteMap] を作成することができる。例えば、次のSiteMap URI

http://www.foo.edu/sitemap-aggregations.xml

を逆参照すると、次のレスポンスを与えることになる。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
      <loc>http://www.foo.edu/objects/object1.atom#aggregation</loc>
      <lastmod>2007-01-06</lastmod>
   </url>
   <url>
      <loc>http://www.foo.edu/objects/object2.atom#aggregation</loc>
      <lastmod>2007-08-11</lastmod>
      <changefreq>weekly</changefreq>
   </url>
   <url>
      <loc>http://www.foo.edu/objects/object3.atom#aggregation</loc>
      <lastmod>2007-03-15T18:30:02Z</lastmod>
      <priority>0.3</priority>
   </url>
...
</urlset>

SiteMapには記述できるリソースのURIパス階層に制限があることに注意されたい。たとえば、次のSiteMap

http://www.foo.edu/a/b/sitemap-aggregations.xml

は、集合体

http://www.foo.edu/a/b/bar2.atom#aggregation

と

http://www.foo.edu/a/b/c/bar3.atom#aggregation

を記載できるが、

http://www.foo.edu/bar1.atom#aggregation

は記載できない。

2.3 OAI-PMH

リソースマップを含む OAI-PMH [OAI-PMH] の新規 metadataPrefix を定義することができる。例えば、次のOAI-PMHリクエスト

http://www.foo.edu/oai?verb=GetRecord&identifier=oai:foo.edu:object1&metadataPrefix=oai_rem_atom

は、次のレスポンスを与えることになる。

<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/
         http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2007-02-08T08:55:46Z</responseDate>
  <request verb="GetRecord" identifier="oai:foo.edu:object1"
           metadataPrefix="oai_rem_atom">http://foo.edu/oai2</request>
  <GetRecord>
   <record>
    <header>
      <identifier>oai:foo.edu:object1</identifier>
      <datestamp>2007-01-06</datestamp>
    </header>
    <metadata>
      <!-- Object1のリソースマップ -->
      <entry xmlns="http://www.w3.org/2005/Atom"
             xsi:schemaLocation="http://www.w3.org/2005/Atom
             http://www.openarchives.org/OAI/2.0/atom_entry.xsd">
       <title>ReM For Object1</title>
       ...
      </entry>
    </metadata>
  </record>
 </GetRecord>
</OAI-PMH>

[ Atomによる完全なレスポンス | RDF/XMLによる完全なレスポンス ]

OAI-PMHは厳格なスキーマ検証を規定しているので、スキーマ文書 http://www.openarchives.org/OAI/2.0/atom_entry.xsd （RDF/XMLの場合は http://www.openarchives.org/OAI/2.0/rdf.xsd）を含めて、Atomコンテンツを検証しないようにスキーマ検証器に伝える必要がある。

2.4 OAI-PMHリポジトリを活用したリソースマップ URIの提供

リソースマップ文書 [ORE Model] はOAI-PMHレスポンスの中にメタデータレコードとして含めることができる。しかし、リソースマップ表示形をリソースマップ表示形として使用できるようにするにはOAI-PMHのコンストラクトを削除する必要がある。これはリソースマップをリソースに埋め込んでいることに関係している（後で検討される）。OAI-PMHリポジトリは、MIMEタイプが text/xml または application/xml のOAI-PMHレスポンスを返す。このOAI-PMHレスポンスはリソースマップレスポンス（例えば、MIMEタイプが application/atom+xml のAtom配信フォーマット）に処理されなければならない。そのため、次のように OAI-PMH の GetRecord リクエストを引数として取り、OAI-PMHからリソースマップに変換するサービスを想定している。

http://some.gateway.org/pmh2ore?=http://foo.edu/oai2?verb=GetRecord&metadataPefix=oai_rem_atom&identifier=oai:foo.edu:object1

OCLCは既にそのようなサービスを構築している。このサービスは、OAI-PMHのGetRecord URIを引数に取り、OAI-PMH要素を取り去り、OAI-PMHの <metadata> 要素の子要素のみを返す。たとえば、OAI-PMH GetRecord リクエスト

http://alcme.oclc.org/oaicat/OAIHandler?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:oaicat.oclc.org:2002/ocm11992160

を、次のように、このOCLCサービスの引数として実行すると、<oai_dc> 要素のみが返される。

http://purl.org/OAIUtil?getRecordURL=http://alcme.oclc.org/oaicat/OAIHandler?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:oaicat.oclc.org:2002/ocm11992160

OAI-PMHの <responseDate> 要素と <request> 要素の値は、HTTPレスポンスヘッダとして保持される。上の例を配信フォーマットと組み合わせることもできるだろう。たとえば、リソースマップ を OAI-PMH で持っているリポジトリは、OAI-PMHに対応していないアプリケーションにはリソースマップをAtomフィードで公開できることになる。

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

 <title>ReMs at www.foo.edu</title>
 <link href="http://www.foo.edu/" />
 <link href="http://www.foo.edu/all-rems.atom" rel="self"/>
 <updated>2007-08-15T18:30:02Z</updated>
 <author>
   <name>John Doe</name>
   <email>johndoe@foo.edu</email>
 </author>
 <id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>

 <entry>
   <title>ReM For Object1</title>
   <link href="http://purl.org/OAIUtil?getRecordURL=http://foo.edu/oai2?verb=GetRecord&amp;metadataPefix=oai_rem_atom&amp;identifier=oai:foo.edu:object1"/>
   <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
   <updated>2007-01-06T00:00:00Z</updated>
 </entry>

 <entry>
   <title>ReM For Object2</title>
   <link href="http://purl.org/OAIUtil?getRecordURL=http://foo.edu/oai2?verb=GetRecord&amp;metadataPefix=oai_rem_atom&amp;identifier=oai:foo.edu:object1"/>
   <id>urn:uuid:9a2cc699-ccba-9e8b-132e-91da394e9a5c</id>
   <updated>2007-08-11T00:00:00Z</updated>
 </entry>

 <entry>
   <title>ReM For Object3</title>
   <link href="http://purl.org/OAIUtil?getRecordURL=http://foo.edu/oai2?verb=GetRecord&amp;metadataPefix=oai_rem_atom&amp;identifier=oai:foo.edu:object1"/>
   <id>urn:uuid:5225c895-cab8-8ebb-baaa-90da9d4efa6b</id>
   <updated>2007-03-15T18:30:02Z</updated>
 </entry>

</feed>

3. リソース埋め込み

リソースマップ 発見の一般的なシナリオは、集合体の中の人間が読むことのできるページが、HTML link 要素 [HTML] を使って URI-A や URI-R にリンクするものである。これを HTTP Linkレスポンスヘッダを使って行うこともできる。さらに、人間エージェントがORE対応のユーティリティにペーストできるように URI-A をopaque文字列として公開することもできる。

対応するリソースマップがリソースに埋め込まれていると、その存在を発見して、ユーザに集合リソースの（再）利用を案内するMozillaプラグインのようなブラウザユーティリティが将来利用可能になることも想定している。

集合リソースが持つ特定の集合体に関する知識について、実際には3つの異なるシナリオが存在する。

1. 完全知識: すべての集合リソースが集合体へのリンクを持つ。
2. 限定知識:: 集合リソースの一部（例えば、スプラッシュページ）のみが集合体へのリンクを持つ。
3. ゼロ知識: すべての集合リソースが集合体へのリンクを持たない。

上のシナリオは特定の集合体に関するものであることに注意されたい。例えば、（通常、自身と同じ作者に作成された）ある集合体に関しては完全知識を持っている集合リソースが、一方で、同一のリソースを集めている第三者の集合体に関してはゼロ知識である可能性がある。

3.1 HTML Link 要素

エージェントをHTMLファイル（集合リソース）からURI-A、URI-R、リソースマップの所在場所を教える配信フィードのURIのすべて、または一部に導くために、HTML link 要素を使うことができる。本書は、URI-RとURI-Aの発見を容易にするために rel 属性の値として各々 "resourcemap" と "aggregation" を導入する。HTMLファイルの作者は、HTML仕様の勧告に従い、/head/[@profile="http://www.openarchives.org/ore/html/"] を使ってORE rel 属性値の名前空間を指定するべきである。

以下は、HTMLページが対応するリソースマップにリンクする方法を示した例である。HTMLページ（"hw.html"）と2つの画像（"hello.jpeg" と "world.jpeg"）から成る集合体を持っていると仮定する。HTMLファイルはリソースマップ（"hw.atom"）にリンクしているが、2つの画像はリンクしていないという、この集合体に対する限定知識シナリオを想定している。HTML以外の集合リソースがリソースマップにリンクする方法は、後ほど、3.2節で記述される。Atomエントリ文書のMIMEタイプは application/atom+xml;type=entry である。

<html>
<head profile="http://www.openarchives.org/ore/html/">
<title>Hello World.</title>
<link href="http://example.net/hw.atom" type="application/atom+xml;type=entry" rel="resourcemap" >
</head>
<body>
<img src="hello.jpeg">
<img src="world.jpeg">
</body>
</html>

リソースマップの直接リンクはエージェントが特定のリソースマップを発見するのに役立つが、関連するリソースマップを含むAtomフィードをユーザが簡単に購読できるようにすることにも役立つ。Atom自動発見のための規則 [AtomFeedAutodiscovery]を適用して、rel="alternate" と type="application/atom+xml" を持つ link 要素を追加する。以下では1つしか示されていないが、そのようなフィードを2つ以上HTMLページからリンクすることもできる。

<html>
<head profile="http://www.openarchives.org/ore/html/">
<title>Hello World.</title>
<link rel="resourcemap" type="application/atom+xml;type=entry" href="http://example.net/hw.atom" >
<link rel="alternate" type="application/atom+xml" href="http://example.net/feeds/salutations.atom" >
</head>
<body>
<img src="hello.jpeg">
<img src="world.jpeg">
</body>
</html>

上の例では、HTMLページは1つのリソースマップしかリンクしていない。1つの集合リソースが複数のリソースマップにリンクすることも可能である。下の例では、HTMLファイルはAtomベースとRDF/XMLベースの2つのリソースマップにリンクしている。リソースマップ間の関係の検証は（もしあれば）エージェントの責任である。HTMLファイルは上で紹介された自動発見技法を保持している。

<html>
<head profile="http://www.openarchives.org/ore/html/">
<title>Hello World.</title>
<link rel="resourcemap" type="application/atom+xml;type=entry" href="http://example.net/hw.atom" >
<link rel="resourcemap" type="application/rdf+xml" href="http://example.net/hw.rdf" >
<link rel="alternate" type="application/atom+xml" href="http://example.net/feeds/salutations.atom" >
</head>
<body>
<img src="hello.jpeg">
<img src="world.jpeg">
</body>
</html>

集合リソースが集合体とリソースマップの両者にリンクすることも可能である。下の例では、HTMLファイルは、配信フィードへのリンクに加えて、上と同じ2つのリソースマップと1つの集合体にリンクしている。rel="aggregation" 属性を持つ場合は type 属性を使用してはいけないことに注意されたい。リソースマップと集合体の間の関係の検証は（もしあれば）エージェントの責任である。URI-A と2つの URI-R の値は字句的には類似しているが、この集合リソースがいくつの異なる集合体（最大3つ）にリンクしているかを立証するために、エージェントはこれらすべてのURIを逆参照しなければならない。言い換えれば、URIはopaqueだと考えられなければならず、関係をその値から文字通りに推測してはいけない。

<html>
<head profile="http://www.openarchives.org/ore/html/">
<title>Hello World.</title>
<link rel="resourcemap" type="application/atom+xml;type=entry" href="http://example.net/hw.atom" >
<link rel="resourcemap" type="application/rdf+xml" href="http://example.net/hw.rdf" >
<link rel="aggregation" href="http://example.net/hw" >
<link rel="alternate" type="application/atom+xml" href="http://example.net/feeds/salutations.atom" >
</head>
<body>
<img src="hello.jpeg">
<img src="world.jpeg">
</body>
</html>

下の例では、rel="bookmark" という値が URI-A へのリンクに追加されている。この rel 属性値は、href 属性に設定されたURIが「パーマリンク」として処理されるべきであること、および、現在クライアントがアクセスしているURIの代わりにこのURIがブックマークやリンクに使用されるべきであることをクライアントに示すものである。この機能は URI-A からコンテントネゴシエーションを介して利用可能なHTMLページにおいてのみ使用されるべきである（詳細は [ORE HTTP] を参照）。下の例は、HTMLがrel属性の値として空白区切りの値のリストを許していることも示している。ただし、同じ目的で2つの独立したlink要素を使うこともできるだろう。

<html>
<head profile="http://www.openarchives.org/ore/html/">
<title>Hello World.</title>
<link rel="resourcemap" type="application/atom+xml;type=entry" href="http://example.net/hw.atom" >
<link rel="resourcemap" type="application/rdf+xml" href="http://example.net/hw.rdf" >
<link rel="bookmark aggregation" href="http://example.net/hw" >
<link rel="alternate" type="application/atom+xml" href="http://example.net/feeds/salutations.atom" >
</head>
<body>
<img src="hello.jpeg">
<img src="world.jpeg">
</body>
</html>

HTMLが付加的なセマンティクス（すなわち、マイクロフォーマット、eRDF、RDFa）を持っているというリソースマップシリアライゼーションでは、HTMLは自分自身へのリンクを持つ rel="resourcemap" を使用して、リソースマップが自分自身の中で見つけられることをクライアントに宣言することが推奨される。下の例は rel="aggregation" の link 要素も使用している。

<html>
<head profile="http://www.openarchives.org/ore/html/">
<title>There is a ReM in This HTML...</title>
<link rel="resourcemap" href="http://example.net/hw.html">
<link rel="aggregation" href="http://example.net/hw" >
</head>
<body>
<-- HTML + マイクロフォーマットの リソースマップ シリアライゼーション -->
</body>
</html>

3.2 HTTP Link ヘッダ

対応する URI-R や URI-A へのリンクをHTML以外のリソースに持たせたい場合、HTML link要素を使用することはできない。しかし、URIへのリンクをHTTPレスポンスに埋め込むことができる。

HTTP Linkレスポンスヘッダという概念はHTTPプロトコルの初期バージョン [RFC2068] には存在していたが、切実なユースケースがなかったためか、現在のHTTP仕様からは削除されている。最近のインターネット･ドラフトで、HTML link要素のセマンティクスをHTTP Linkレスポンスヘッダに変換する方法が提案されている [HTTP Header Linking]。このドラフトはまだRFCには昇格していないが、そのアプローチは単純である。上で示した「Hello World」の例を限定知識から完全知識に昇格させたい場合、JPEGファイルはHTTP Linkレスポンスヘッダを持つことで対応する集合体やリソースマップへリンクできるようになる。以下の例は、HTTPリクエストと、LinkヘッダにURI-AとURI-Rの両者を持つレスポンスを示している。

（リクエスト）  HEAD http://www.example.net/hello.jpeg HTTP/1.1
                Host: www.example.net
                Connection: close

（レスポンス）  HTTP/1.1 200 OK
                Date: Sat, 26 May 2007 22:43:10 GMT
                Server: Apache/2.2.0
                Last-Modified: Sat, 26 May 2007 19:32:04 GMT
                ETag: "c3596-816-92123500"
                Accept-Ranges: bytes
                Content-Length: 2070
                Link: <http://example.net/hw.atom>; type="application/atom+xml;type=entry"; rel="resourcemap"
                Link: <http://example.net/hw>; rel="aggregation"
                Content-Type: image/jpeg
                Connection: close

3.3 HTML以外のリソース

PDF（例えば、[Adobe XMP] を介して）や画像といったHTML以外のリソースにリンクを埋め込むことも可能だろうが、この方法でリソースマップにリンクすることを現段階で議論することは時期尚早であると思われる。

3.4 HTMLページ内での公開

ブログや掲示板、リポジトリシステムなどのアプリケーションに集合体のURIをコピー&ペーストするという将来の利用シナリオを容易にするために、集合体のURIをopaque文字列として公開することを提案する。これは、YouTube や Photobucket、Hemmingsといったサイトで普通に行われており、メールやインスタントメッセンジャーシステム、掲示板、HTMLページなどの構成要素としてユーザが容易に再利用（すなわち、コピー&ペースト）できるような文字列が提供されている。これがどのようなものであるかを、arXivのプレプリントが例を示している。この例では、URI-Aは "Aggregation Permalink" と名付けられている。

4. プロキシURI

ORE抽象データモデル [ORE Model] は、プロキシとプロキシURIという概念を定義している。プロキシの目的は特定の集合体のコンテキストにある集合リソースを明確に識別することにある。これは特に集合リソースにとってゼロ知識である第三者の集合体の識別に役立つ。また、エージェントが以前には発見できなかったかもしれないURI-Aにリンクしているので、発見という観点からも役に立つ。

HTTPプロキシURI（URI-P）は、リゾルバの "baseURL" 、URI-A、集合リソースのURI-ARの3者から成る。下のシナリオは、PDFと画像を通常の方法で含めたいが、同時に、著者が伝えたいと考える特定の集合体をORE対応のクライアントに知らせたい場合である。URI-ARに直接リンクする代わりに、URI-Pにリンクしている（#aggregation は %23aggregation とエンコーディングする必要があることに注意されたい）。

<html>
...
Here is a helpful reference for distinguishing
<a href="http://oreproxy.org/r?what=http://example.org/pics/f-t.pdf&where=http://example.org/amphibians.atom%23aggregation">
frogs vs. toads</a>.
<-- 単なる http://example.org/pics/f-t.pdf の代わりに -->
<p>
Here is a frog

<img src="http://oreproxy.org/r?what=http://weluvfrogs.org/imgs/frog12.jpeg&where=http://frogs.org/frogs.atom%23aggregation">
<-- 単なる http://weluvfrogs.org/imgs/frog12.jpeg の代わりに -->
and here is a toad
<img src="http://oreproxy.org/r?what=http://toadsrule.org/toad.gif&where=http://toadsrule.org/toads.atom%23aggregation">.
<-- 単なる http://weluvfrogs.org/imgs/frog12.jpeg の代わりに -->

...
</html>

URI-Pを逆参照すると、リゾルバはURI-ARへのHTTP 303 リダイレクション（"See Other"）を返し、URI-Aを含むHTTP Linkレスポンスヘッダを作成する。ブラウザなどのユーザエージェントはURI-ARにリダイレクトされ、望みの結果（例えば、集合リソースの取得）が得られる。ORE対応のアプリケーションはHTTPレスポンスヘッダを調べることにより特定の集合体のURIを発見することができる。プロキシURIの作成と使用に関するさらなる情報は [ORE HTTP] で提供されている。

（リクエスト）  HEAD /r?what=http://weluvfrogs.org/imgs/frog12.jpeg&where=http://frogs.org/frogs.atom%23aggregation HTTP/1.1
                Host: oreproxy.org
                Connection: close

（レスポンス）  HTTP/1.1 303 See Other
                Date: Sat, 31 May 2007 20:40:11 GMT
                Server: Apache/2.2.0
                Location: http://weluvfrogs.org/imgs/frog12.jpeg
                Link: <http://frogs.org/frogs.atom#aggregation>; rel="aggregation"
                Connection: close
                Content-Type: text/html
                Content-Length: 534

5. 参考文献

[Adobe XMP]

Adobe Extensible Metadata Platform (XMP) , 2008. Available at http://en.wikipedia.org/wiki/Extensible_Metadata_Platform.

[AtomFeedAutodiscovery]

Atom Feed Autodiscovery, M. Pilgrim, P. Ringnalda, IETF Draft, 2005. Available at http://xml.coverpages.org/draft-ietf-atompub-autodiscovery-01.txt.

[Cool URIs]

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

[HTML]

HTML 4.01 Specification, D. Raggett, A. Le Hors, I. Jacobs (eds.), W3C Recommendation 24 December 1999. Available at http://www.w3.org/TR/html4/.

[HTTP Header Linking]

HTTP Header Linking, M. Nottingham, IETF Draft, 2008. Available at http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt.

[OAI-PMH]

The Open Archives Initiative Protocol for Metadata Harvesting, C. Lagoze, H. Van de Sompel, M. Nelson, S. Warner, 2002. Available at http://www.openarchives.org/OAI/openarchivesprotocol.html.

[ORE HTTP]

ORE User Guide - HTTP Implementation, C. Lagoze, H. Van de Sompel, P. Johnston, M. Nelson, R. Sanderson, S. Warner, 2008-10-17. Available at http://www.openarchives.org/ore/1.0/http .
翻訳版: OREユーザガイド - HTTPによる実装

[ORE Model]

ORE Specification - Abstract Data Model, C. Lagoze, H. Van de Sompel, M. Nelson, R. Sanderson, S. Warner, 2008-10-17. Available at http://www.openarchives.org/ore/1.0/datamodel .
翻訳版: ORE仕様書 - 抽象データモデル

[ORE Atom]

ORE User Guide - Resource Map Implementation in Atom, C. Lagoze, H. Van de Sompel, M. Nelson, R. Sanderson, S. Warner, 2008-10-17. Available at http://www.openarchives.org/ore/1.0/atom .
翻訳版: OREユーザガイド - Atomによるリソースマップの実装

[RFC2068]

IETF RFC 2068: Hypertext Transfer Protocol - HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, January 1997. Available at http://www.ietf.org/rfc/rfc2068.txt.

[RFC2119]

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

[RFC4287]

IETF RFC 4287: The Atom Syndication Format, M. Nottingham, R. Sayre, December 2005. Available at http://www.ietf.org/rfc/rfc4287.txt.

[RSS]

RSS, 2007. Available at http://en.wikipedia.org/wiki/RSS_(file_format).

[SiteMap]

Sitemaps XML format, 2007. Available at http://http://www.sitemaps.org/.