1. Introduction

Resource Map (ReM) discovery is a precondition of use. There is no single, best method for discovering ReMs. This document covers a variety of suggested ReM discovery mechanisms, grouped into the categories of: Batch Discovery, Resource Embedding and Proxy URIs. Examples are explored for each category; additional categories and examples are expected to evolve over time.

1.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [IETF RFC 2119].

1.2 Linking to Aggregations and Resource Maps

Although this document's title speaks of discovering ReMs, there are scenarios where it is more natural to link to Aggregations (URI-A in [ORE Model]) thereby including all possible ReMs available from URI-A. Similarly, it is sometimes more natural to link to a specific Resource Map (URI-R) (see section 3.1 below). Because discovery is orthogonal to description, either strategy, including a combination of both, is acceptable. Both methods are illustrated in the examples below. However, because Aggregations are not "web documents" (in the sense described in [Cool URIs]), authors MUST NOT include MIME type information when linking to URI-A. In fact, it is possible for URI-A to redirect to documents of several MIME types when dereferenced. See [ORE HTTP] regarding the relationship between URI-A and URI-R and strategies for choosing their values.

2. Batch Discovery

Batch discovery exists so agents can discover ReMs en masse. Note that there is no restriction that the owner of the URI of a ReM is also the owner of the URI of the Aggregation described by the ReM: it is possible for site X to expose ReMs describing Aggregations at sites Y and Z. Although ReMs can be serialized in a number of formats, a popular serialization are entry documents as defined by the Atom ReM serialization [ORE Atom] and Atom Syndication Format [RFC4287]. Thus, in each section (where applicable) a table is provided to clearly map between concepts of identification and datestamps between the transport protocol/format, Atom, and the Abstract Data Model [ORE Model].

2.1 Atom Feeds

If a site has ReMs serialized as Atom entry documents, then the easiest and most straight-forward method of batch publication is to syndicate them in an Atom feed [ORE Atom]. It is important to remember that the Atom feed and associated feed-level metadata have no ORE semantics and exist only to facilitate the discovery and syndication of the ReMs (Atom entry documents). For example, this Atom Feed:

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

When dereferenced would yield:

<?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>
   <!-- ReM For Object1 -->
   ...
 </entry>

 <entry>
   <!-- ReM For Object2 -->
   ...
 </entry>

 <entry>
   <!-- ReM For Object3 -->
   ...
 </entry>

</feed>

[ Atom ]

The example above demonstrates the scenario we anticipate to be the most common method for batch discovery: ReMs (Atom entry documents) syndicated in an Atom feed to support batch disovery. However, Atom's link element allows links to ReMs to be incorporated in "regular" Atom feeds as well. Consider an institutional repository with the most recently accessioned scholarly eprints available at the following Atom feed:

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

When dereferenced would yield:

<?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 ]

In the above example, the Atom entry documents are not ReMs. The "splash" pages are linked in the /feed/entry/link[@rel="alternate"]@href elements and the corresponding ReMs are linked in the /feed/entry/link[@rel="resourcemap"]@href element (The resourcemap relation is introduced in section 3.1 below). Sites already using syndication feeds may choose to augment their existing feeds with links to ReMs in this manner.

2.2 SiteMaps

It is possible to construct a SiteMap [SiteMap] that consists of just links to ReMs and Aggregations or possibly includes ReMs and Aggregations mixed in with its list of regular resources. For example, dereferencing this SiteMap URI:

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

Would yield this response:

<?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>

Note that SiteMaps have a URI path hierarchy limitation for the resources for which they can describe. For example, this SiteMap:

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

Can list the Aggregations:

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

and

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

But not:

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

2.3 OAI-PMH

It is possible to define a new metadataPrefix in the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) [OAI-PMH] that contains ReMs. For example, this OAI-PMH request:

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

Would yield this response:

<?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>
      <!-- ReM for 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>

[ Complete response with Atom | Similar response with RDF/XML ]

OAI-PMH specifies strict schema validation so it is necessary to include the schema document http://www.openarchives.org/OAI/2.0/atom_entry.xsd to tell a schema validator not to validate the Atom content (and similarly http://www.openarchives.org/OAI/2.0/rdf.xsd for included RDF/XML).

2.4 Leveraging an OAI-PMH repository to provide URIs of ReMs

Resource Map Documents [ORE Model] can be included as metadata records in an OAI-PMH response. However, the OAI-PMH constructs must be removed before the Resource Map representation can be used as such. This has implications with respect to embedding the Resource Map in a resource (discussed below). OAI-PMH repositories issue OAI-PMH responses of MIME type text/xml or application/xml. These OAI-PMH responses must be processed into ReM responses (e.g., Atom Syndication Format and of MIME type application/atom+xml). We envision these kinds of OAI-PMH to ReM services taking an OAI-PMH GetRecord request as an argument, such as:

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

OCLC has already developed one such service. It takes an OAI-PMH GetRecord URI as an argument and strips out out the OAI-PMH elements, leaving only the child element of the OAI-PMH's <metadata> element. For example, this OAI-PMH GetRecord request:

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

When submitted as an argument to the OCLC service, produces just the <oai_dc> element:

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

The values of the OAI-PMH <responseDate> and <request> elements are retained as HTTP response headers. The above example could also be combined with syndication formats. For example, if a repository has its ReMs in OAI-PMH, it could export the ReMs in an Atom Feed for applications that are not OAI-PMH aware:

<?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. Resource Embedding

A common scenario for ReM discovery is for a human readable page in an Aggregation to link to URI-A and/or URI-R using the HTML link element [HTML]. This can also be accomplished using the HTTP Link response header. Alternatively, URI-A can be exposed as an opaque string for human agents to paste into ORE-aware utilities.

We also envision the future availability of browser utilities such as Mozilla plugins that detect the presence of corresponding ReMs when embedded in resources and help guide the user in the (re)use of the Aggregated Resources.

There are actually three different scenarios regarding Aggregated Resources and knowledge about any particular Aggregation:

1. Full knowledge: All Aggregated Resources contain links.
2. Limited knowledge: only a subset of the Aggregated Resources (e.g., the splash page) contain links.
3. Zero knowledge: none of the Aggregated Resources contain links.

Note that the above scenarios are relative to a particular Aggregation; it is possible for Aggregated Resources to simultaneously have full knowledge regarding one Aggregation (typically authored by the same creators of the resources) and have zero knowledge about third party Aggregations that aggregate the same resources.

3.1 HTML Link Element

The HTML link element can be used to direct agents from the aggregated HTML file to all or some of URI-A, URI-R, or the URI of a syndication feed where the ReM can be located. This document introduces the values of "resourcemap" and "aggregation" for the rel attribute to facilitate discovery of URI-R and URI-A values, respectively. Following the recommendation of the HTML specification [HTML], authors SHOULD use /head/[@profile="http://www.openarchives.org/ore/html/"] to establish the namespace for the ORE rel values.

Below is an example of how an HTML page could link to a corresponding ReM. Assume we have an Aggregation of an HTML page ("hw.html") and two images ("hello.jpeg" and "world.jpeg"). A limited knowledge scenario for this Aggregation would be that the HTML file links to the ReM ("hw.atom") but the two images do not. The method for non-HTML Aggregated Resources linking to ReMs is described in section 3.2 below. The MIME type for the Atom entry document is 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>

While a direct link to the ReM is useful for agents to discover the particular ReM, it also useful to facilitate users subscribing to Atom feeds that contain the associated ReM. Using the rules for for Atom autodiscovery [AtomFeedAutodiscovery], a link with rel="alternate" and type="application/atom+xml" is inserted. Although only one is shown, there could be more than one such feed linked to from the HTML page.

<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>

In the above example, the HTML page links only to a single ReM. It is also possible for an Aggregated Resource to link to multiple Resource Maps. In the example below, the HTML file links to two Resource Maps, an Atom-based ReM and an RDF/XML-based ReM. It is up to the agent to verify the relationship (if any) between the Resource Maps. The HTML file retains the autodiscovery technique introduced above.

<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>

It is also possible for an Aggregated Resource to link to both Aggregations and Resource Maps. In the example below in addition to the link to the syndication feed, the HTML file links to the same two Resource Maps as above, and one Aggregation. Note that with the rel="aggregation" attribute, type MUST NOT be used. It is up to the agent to verify the relationship (if any) between the Resource Maps and Aggregations. Despite the lexigraphic similarity between URI-A and the two URI-R values, the agent MUST dereference all the URIs to establish if this Aggregated Resource is linking to 1, 2 or 3 different Aggregations. In other words, the URIs MUST be considered opaque and relationships MUST NOT be inferred from their values as strings.

<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>

In the example below, the value of rel="bookmark" has been added for the link to URI-A. This rel value is a suggestion to clients that the URI in the href attribute should be treated as a "Permalink" and used for bookmarking and linking instead of the current URI in use by the client. This feature should only be used in HTML pages which are available via content negotiation from URI-A (see [ORE HTTP] for more information). The example below also demonstrates that HTML allows for a space separated list of values for the rel attribute; one could also use two separate link elements for the same purpose.

<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>

For Resource Maps serializations where the HTML carries additional semantics (i.e., microformats, eRDF, and RDFa), it is RECOMMENDED that the HTML use rel="resourcemap" with a link to itself to declare to clients that a ReM can be found within. The example below also uses a 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 + microformat ReM serialization -->
</body>
</html>

3.2 HTTP Link Header

If we wish to have non-HTML resources link to corresponding URI-R or URI-A values, we cannot use the HTML link element. However, we can embed link to the URI(s) in the HTTP response.

The concept of a link HTTP response header existed in earlier versions of the HTTP protocol [RFC2068], but the lack of a compelling use case probably led to it being removed from the current HTTP specification. A recent Internet Draft proposes a method for converting HTML link element semantics into HTTP Link response headers [HTTP Header Linking]. Although this draft has yet to be promoted to an RFC, the approach is straightforward. If we wanted to promote the hello world example above from limited knowledge to full knowledge, the JPEGs could link to their corresponding Aggregation or ReM with the HTTP link response header. The example below shows an HTTP request and response with both URI-A and URI-R in a link header.

(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;type=entry"; rel="resourcemap"
                Link: <http://example.net/hw>; rel="aggregation"
                Content-Type: image/jpeg
                Connection: close

3.3 Non-HTML Resources

It may be possible to embed links to URI-A in non-HTML resources, such as PDF (e.g., via [Adobe XMP]) or images, but linking to ReMs with these methods is considered too preliminary to discuss at this time.

3.4 Exposing in HTML Pages

We propose exposing Aggregation URIs as opaque strings to facilitate future usage scenarios in which people copy and paste Aggregation URIs into applications such as blogs, forums or repository systems. This is commonly done with sites such as YouTube and Photobucket, and classified listings where strings are provided to the user to facilitate reuse (i.e., copy-n-paste) of the components in email, instant messaging systems, forums and HTML pages. We provide an example of how this could look for using an arXiv pre-print as an example. In this example, URI-A is labeled as an "Aggregation Permalink".

4. Proxy URIs

The ORE Abstract Data Model [ORE Model] defines the concept of Proxies and Proxy URIs. The purpose of a Proxy is to unambiguously identify an Aggregated Resource in the context of a specific Aggregation. This is especially useful to identify a third party Aggregation for which an Aggregated Resource has zero knowledge. This is useful with regards to discovery because it links to a URI-A that the agent might not have previously discovered.

An HTTP Proxy URI (URI-P) consists of a "baseURL" of a resolver, URI-A and URI-AR of the Aggregated Resource. In the scenario below, we wish to include the images and PDF in the typical manner while at the same time informing ORE-aware clients of the particular Aggregation that the author wishes to convey. Instead of linking directly to URI-AR, we link to URI-P (note the required encoding of #aggregation as %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>.
<-- Instead of just 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">
<-- Instead of just 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">.
<-- Instead of just http://weluvfrogs.org/imgs/frog12.jpeg -->

...
</html>

When a URI-P is dereferenced, the resolver issues an HTTP 303 Redirection ("See Other") to URI-AR and creates a HTTP Link response header containing URI-A. User agents such as browsers will be redirected to URI-AR which will produce the desired result (e.g., obtaining the Aggregated Resource). ORE-aware applications can discover the URI of the specific Aggregation by examining the HTTP response header. Further information regarding constructing and using Proxy URIs is given in [ORE HTTP].

(request)       HEAD /r?what=http://weluvfrogs.org/imgs/frog12.jpeg&where=http://frogs.org/frogs.atom%23aggregation HTTP/1.1
                Host: oreproxy.org
                Connection: close

(response)      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. References

[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ö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/

[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 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 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-implementation .

[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/.