要旨

集合体が認識されるには、まず、それを記述するリソースマップ（ReM）をクローラやハーベスが発見しなければならない。ReMを発見できるようにするには多くの方法があるが、本文書ではいくつかの推奨される発見メカニズムを検討する。時が経つにつれ他のメカニズムが開発されたり、各コミュニティの実践に基づいて変化するかもしれない。本ユーザガイドは、OAI-ORE仕様書およびユーザガイドを構成する文書の1つである。

1. はじめに

リソースマップ（ReM）の発見は、利用の前提条件である。ReMを発見するただ1つの最良な方法は存在しない。本文書は、一括発見、リソース埋め込み、レスポンス埋め込みの3種類にまとめることができる、提案されている様々なReM発見メカニズムを扱い、各種類の例について検討する。今後さらに別の種類や例が登場することが期待される。

1.1 表記法

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

2. 一括発見

一括発見は、エージェントがReMを一括して発見できるようにするためのものである。ReMが記述しているのは自身が存在するサーバ上にある集合体に限らないことに注意されたい。ReMは数多くのフォーマットでシリアル化することが可能であるが、最初のシリアル化はAtom配信フォーマットによるものである [RFC4287]。したがって、各節には識別と日付スタンプの概念について、転送プロトコル/フォーマットとAtomリソースマッププロファイル [ReMProfileofAtom] 間の明確な対応付けが表の形で提供されている。

2.1 OAI-PMHによるReM

ReMを含むための新しいmetadataPrefix をOAI-PMH（Open Archives Initiative Protocol for Metadata Harvesting）[OAI-PMH] に定義することが可能である。たとえば、次のOAI-PMHリクエスト

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

は、次のレスポンスをもたらすことになるだろう。

<?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">http://foo.edu/oai2</request>
  <GetRecord>
   <record>
    <header>
      <identifier>oai:foo.edu:object1</identifier>
      <datestamp>2007-01-06</datestamp>
    </header>
    <metadata>
        <!-- Insert ReM here -->
    </metadata>
  </record>
 </GetRecord>
</OAI-PMH>

表 1: OAI-PMHにより発見されるAtom ReM
識別	OAI-PMHの `record/header/identifier` は、ReM Atomの `/feed/id` または `/feed/link[@rel="self"]/@href` のいずれかと同じであってはいけない。
日付スタンプ	OAI-PMHの `record/header/datestamp` は、ReM Atom の `/feed/updated` と同じでなければならない。

2.2 SiteMapによるReM

ReMだけから成る、あるいは通常のリソースリストにReMを含めたSiteMap [SiteMap] を作成することが可能である。たとえば、次のSiteMap URI

http://www.foo.edu/sitemap-rem.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</loc>
      <lastmod>2007-01-06</lastmod>
   </url>
   <url>
      <loc>http://www.foo.edu/objects/object2.atom</loc>
      <lastmod>2007-08-11</lastmod>
      <changefreq>weekly</changefreq>
   </url>
   <url>
      <loc>http://www.foo.edu/objects/object3.atom</loc>
      <lastmod>2007-03-15T18:30:02Z</lastmod>
      <priority>0.3</priority>
   </url>
...
</urlset>

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

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

は、ReM

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

と

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

はリストすることができるが、

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

をリストすることはできない。

表 2: SiteMapにより発見されるAtom ReM
識別	SiteMap の `/urlset/url/loc` は、対応するReMの `/feed/link[@rel="self"]/@href` と同じでなければならないが、`/feed/id` と同じであってはいけない。
日付スタンプ	存在する場合、SiteMapの `/urlset/url/lastmod` は、ReM Atomの`/feed/updated` と同じでなければならない

2.3 配信フィードによるReM

ReMの最初のシリアル化はAtom配信フォーマットによるものであったが、ReMの発見のためにAtomやRSS [RSS] のような配信フォーマットの使用を避ける理由はない。ただし、リソースマップとリソースマップを記載している配信ファイルを概念的に区別するよう注意が必要である。特に、リソースマップのURIを記載しているAtomエントリのIDは、リソースマップのURIでもリソースマップであるAtomフィードのIDであってもいけない。さらに、発見に使用されるAtomフィードとReMである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>
   <title>ReM For Object1</title>
   <link href="http://www.foo.org/objects/object1.atom"/>
   <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://www.foo.org/objects/object2.atom"/>
   <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://www.foo.org/objects/object3.atom"/>
   <id>urn:uuid:5225c895-cab8-8ebb-baaa-90da9d4efa6b</id>
   <updated>2007-03-15T18:30:02Z</updated>
 </entry>

</feed>

表 3: Atomにより発見されるAtom ReM
識別	配信Atomの `/feed/entry/id` は、ReM Atomの `/feed/id` と同じであってはいけない。配信Atomの `/feed/entry/link/@href` は、ReM Atomの `/feed/link[@rel="self"]/@href` と同じでなければならない。
日付スタンプ	配信Atomの `/feed/entry/updated` は、ReM Atomの `/feed/updated` と同じでなければならない。

同じReMをRSS 2.0で公開することもできるだろう。たとえば、次のRSSフィード

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

は、逆参照すると次をもたらすことになるだろう。

<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>ReMs at www.foo.edu</title>
    <link>http://www.foo.edu/</link>
    <description>All of the Resource Maps for resources at www.foo.edu</description>
  
    <item>
      <title>ReM for Object 1</title>
      <link>http://www.foo.org/objects/object1.atom</link>
      <description>ReM for Object 1</description>
      <pubDate>Sat, 06 Jan 2007 00:00:00 GMT</pubDate>
    </item>
  
    <item>
      <title>ReM for Object 2</title>
      <link>http://www.foo.org/objects/object2.atom</link>
      <description>ReM for Object 2</description>
      <pubDate>Sat, 11 Aug 2007 00:00:00 GMT</pubDate>
    </item>

    <item>
      <title>ReM for Object 3</title>
      <link>http://www.foo.org/objects/object2.atom</link>
      <description>ReM for Object 3</description>
      <pubDate>Thu, 15 Mar 2007 08:30:02 GMT</pubDate>
    </item>
   
  </channel>
</rss>

表 4: RSSにより発見されるAtom ReM
識別	RSS 2.0の `/rss/item/link` は、ReM Atomの `/feed/id` と同じであってはいけない。 RSS 2.0の `/rss/item/link` は、ReM Atomの `/feed/link[@rel="self"]/@href` と同じであってはいけない。
日付スタンプ	RSS 2.0の `/rss/item/pubDate` は、（RFC-822形式からISO 8601形式に変換した）ReM Atomの `/feed/updated` と同じでなければならない。

2.4 OAI-PMHと他のアプローチの組み合わせ

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

http://some.gateway.org/pmh2ore?=http://foo.edu/oai2?verb=GetRecord&metadataPefix=oai_rem&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レスポンスヘッダとして保持される。上の例を配信フォーマットと組み合わせることもできる。たとえば、あるリポジトリがReMをOAI-PMHで持っているとすると、OAI-PMHに対応していないアプリケーションにはReMを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&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&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&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. リソース埋め込み

ReM発見の一般的なシナリオは、集合体の中の人間が読むことのできるページが対応するReMにリンクすることである。これは最も一般的にはHTMLのlink要素により達成される [HTML]。別の方法としては、HTMLのA要素やIMG要素でReMを指したり、人間エージェントがORE対応のユーティリティにペーストできるようにReMのURIをopaque文字列として公開することで達成することができる。

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

3.1 HTML の link 要素

HTMLのlink要素は、集合体の一部であるHTMLファイルからその集合体を記述している対応するReMにエージェントを導くことに使用できる。これは一般的な場合であるが、実際には、集合体のメンバと対応するReMに関する知識により4つの異なるシナリオが存在する。

完全な知識: ReMは、集合体のすべてのリソースからリンクされている。
間接的な知識: 集合体の1つを除いたすべてのリソースが、集合体のただ1つの特別なリソースにリンクしており、そのリソースがReMにリンクしている。
限定された知識: 集合体の一部のリソース（通常はただ1つのリソース）だけがReMにリンクしており、残りのリソースは一切リンクを持たない。
ゼロ知識: 集合体のすべてのリソースがReMにリンクしていない。

上のシナリオは、特定のReMに関するものであることに注意されたい。集合リソースが（通常、リソースと同じ作者により作成された）あるReMに関しては完全な知識を持っているが、同時に同じリソースを持つ集合体を記述した第三者のReMに関してはゼロ知識であることがありえる。以下は、HTMLページが対応するReMにリンクする方法の例である。JPEGファイルに関するこのHTMLが集合体を形成し、JPEGファイルはHTTPヘッダを使用して対応するReMにリンクしない（以下を参照）と仮定しており、このHTMLページだけがReMにリンクしているので、この例は限定された知識のシナリオの例である。

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

上の例では、HTMLページは1つのReMだけにリンクしているが、複数のReMにリンクすることも可能であり、その場合、2つの集合体を区別することはエージェントの責任である。次に、HTMLページが集められたことは知っているが、そのReMの場所を知らない例を考える。この場合は、ReMの場所を知っているページにリンクすることになる。このようなリダイレクションは任意の数存在することが可能である。利用形態に最も合ったシナリオを選択することは、リソースやReMの作者やメンテナの責任である。

<html>
<head>
<title>Chapter Twelve.</title>
<link href="http://mybook.com/toc.html" type="text/html" rel="indirectresourcemap" >
</head>
<body>
Welcome to chapter twelve... 
</body>
</html>

HTMLの仕様は、rel属性の値がCDATAであると定義しているので、 "resourcemap" や "indirectresourcemap" という値を使用することができ、これは依然として妥当なXHTMLである。

3.2 HTMLのA要素とIMG要素

HTMLは、リソースマップや対象リソースにリンクするための適当な属性をA要素やIMG要素に提供していない。この節では、A要素とIMG要素に新しい属性を追加する（これはその他の点では妥当なHTML文書を不正なものにする）か、既存の属性を別の目的で使用することを提案する。

似てはいるが違うシナリオが、他の集合体 [ORE Model] との関係を知らせることが望ましい場合である。このシナリオでは、このHTMLページを含んでいる集合体を記述するReMについて言及したいのではなく、むしろ（A要素やIMG要素で）リンクしようとしているリソースが最初に発見された集合体を記述するReMを言及したいと考える。これは、A要素やIMG要素に独立した属性を使用することにより達成される。以下の例は、HTMLページが個々のサンプル画像だけでなくカエルやヒキガエルに関するPDF文書を発見するのに使用されるReMを引用する方法を示している。

<html> 
...   
Here is a helpful reference for distinquishing 
<a href="http://example.org/pics/f-t.pdf" 
resourcemap="http://example.org/amphibians.atom">frogs vs. toads</a>.  
<p> 
Here is a frog
<img src="http://weluvfrogs.org/imgs/frog12.jpeg"
resourcemap="http://frogs.org/frogs.atom"> 
and here is a toad <img src="http://toadsrule.org/toad.gif"
resourcemap="http://toadsrule.org/toads.atom">.  
...  
</html>

この方法は非標準の属性 resourcemap を使用する。これはORE対応のユーザエージェントにヒントを与えるのに使用することができるが、認識される保証はなく、妥当なXHTMLではない。他の集合体またはReMにあいまいなくリンクする唯一の方法は、新しいReMを作成することである。これを行う方法については [ORE User Guide Resource Map] を参照されたい。

非標準のHTML属性を導入することなく適当なリソースマップを指定するもう1つの方法は、リソースマップのURIを既存のHTML属性に置くことだろう。以下は、空白区切りの値のリストをとる class 属性にリソースマップのURIを置く方法を示した例である。

<html> 
...   
Here is a helpful reference for distinguishing 
<a href="http://example.org/pics/f-t.pdf" 
class="resourcemap=http://example.org/amphibians.atom">frogs vs. toads</a>.  
<p> 
Here is a frog
<img src="http://weluvfrogs.org/imgs/frog12.jpeg"
class="resourcemap=http://frogs.org/frogs.atom">
and here is a toad 
<img src="http://toadsrule.org/toad.gif" 
class="resourcemap=http://toadsrule.org/toads.atom">.
...  
</html>

3.3 HTML以外のリソース

ReMへのリンクをPDFや画像などのHTML以外のリソースに埋め込むことも可能だろうが、この方法を現段階で議論することは時期尚早であると考えられる。

3.4 ReMをHTMLページで示す

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

4. レスポンス埋め込み

対応するReMへのリンクをリソースに持たせたいが、集合リソースがすべてHTMLでなくHTMLのlink要素を使うことができない場合は、ReMへのリンクをレスポンスに埋め込むことができる。今のところこれはReMのURIをHTTPのレスポンスヘッダに置くことを意味する。

4.1 HTTPのLinkヘッダ

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

(request)  HEAD http://www.example.net/hello.jpeg HTTP/1.1
                Host: www.example.net
                Connection: close

(response)      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"; rel="resourcemap"
                Content-Type: image/jpeg
                Connection: close

5. 推奨されないReMの発見方法

5.1 単純なファイルによるReM

たとえば次のように、ReMから成るHTMLページを作成して、ロボットが発見できるようにWebサイトからそのページにリンクすることが可能である。

<a href="http://www.foo.edu/objects/object1.atom">ReM 1</a>
<a href="http://www.foo.edu/objects/object2.atom">ReM 2</a>
<a href="http://www.foo.edu/objects/object3.atom">ReM 3</a>
...

これは間違いではなく、WebクローラにReMを公開することにはなるが、たまたま人間エージェントがこのページをロードした場合、混乱をもたらすだろう。そのようなページを人間エージェントから隠し、クローラだけに提供するという試みは、リンクスパムとみなされるだろう。

5.2 URIの合成

データモデル文書 [ORE Model] は、ReMのURI（URI-R）がReM以外の何ものも返すことを明示的に禁止している。別言語や文字セット、圧縮方法でReMを返すためにコンテント･ネゴシエーションを使用するなど、データモデル文書はURI-Rに複数の表現を関連付けることを認めている。しかし、HTTPコンテント･ネゴシエーションやリダイレクトにより、人間が読むことのできる「スプラッシュページ」をURI-Rが返すことは認めていない。たとえば、クライアントはコンテント･ネゴシエーションにおいて、オブジェクトのReMと「スプラッシュページ」に対応する次のようなURIの組を1つにまとめてはいけない。

（ReM）                      http://www.foo.edu/objects/object1.atom
（スプラッシュページ）       http://www.foo.edu/objects/object1.html
（合成URI）                  http://www.foo.edu/objects/object1

同様に、クライアントは、HTTPの303リダイレクションの方法 [DFKI TM-07-01] で作成した合成URIを使ってReMを参照してはいけない。

（ReM）                      http://www.foo.edu/data/objects/object1
（スプラッシュページ）       http://www.foo.edu/page/objects/object1
（合成URI）                  http://www.foo.edu/resource/objects/object1

これらの制限の目的は、URI-RがReMの一義的な識別子であり、他のリソース（特に、人間が読むことのできるスプラッシュページのような、ReMで記述される集合体のメンバでありそうなリソース）の識別子と合成されないようにすることである。

これらの制限は、ReMをスプラッシュページの基礎または「材料」として使用することを妨げるものではないことに注意されたい。サーバは、ReMを人間エージェントの利用にふさわしい形に変換するスタイルシートを含めることを選択することができる。これはオプションであるが、ReMとスプラッシュページが互いに変換可能である必要はないことにクライアントは注意するべきである。ReMはスプラッシュページと同じURIを持たない場合があり、逆もまた真であるからである。

6. 参考文献

[DFKI TM-07-01]: Cool URIs for the Semantic Web, L. Sauermann, R. Cyganiak, M. Völkel, DFKI Technical Memo TM-07-01, 2007. Available at http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/tm-07-01.pdf.
[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, 2006. Available at http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.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.
翻訳版: Open Archives Initiative メタデータ・ハーベスティング・プロトコル
[ORE Model]: ORE Specification - Abstract Data Model, C. Lagoze, H. Van de Sompel, M. Nelson, R. Sanderson, S. Warner, 2007. Available at http://www.openarchives.org/ore/datamodel.
翻訳版: ORE仕様書 - 抽象データモデル
[ORE User Guide Resource Map]: ORE User Guide - Resource Map Implementation in Atom, C. Lagoze, H. Van de Sompel, M. Nelson, R. Sanderson, S. Warner, 2007. Available at http://www.openarchives.org/ore/atom-implementation.
翻訳版: OREユーザガイド - Atomによるリソースマップの実装
[ReMProfileofAtom]: ORE Specification - Resource Map Profile of Atom, C. Lagoze, H. Van de Sompel, M. Nelson, R. Sanderson, S. Warner, 2007. Available at http://www.openarchives.org/ore/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 Requirement Levels, 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/.

日付	編集者	記述
2008-02-27	mln	パブリックアルファ0.2のリリース
2007-12-10	mln	パブリックアルファ0.1のリリース
2007-10-15	mln	アルファ版をORE-TCに提出

OREユーザガイド - リソースマップの発見

2008年2月27日

要旨

目次

付録