1. Introduction

Resource Map (ReMs) 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; and 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 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 despite the ORE Model not providing a relationship between Aggregated Resources and Resource Maps. However, because Aggregations are non-information resources, authors MUST NOT include MIME type information when linking to URI-A. In fact, it is possible for URI-A to return one 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 ReMs are not limited to describing Aggregations on the server where the ReMs reside. Although ReMs can be serialized in a number of formats, a popular serialization is the Atom Syndication Format [RFC4287]. Thus, in each section a table is provided to clearly map between concepts of identification and datestamps between the transport protocol/format, Atom ReM serialization [ReMs Using Atom], and the Abstract Data Model [ORE Model].

2.1 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>
        <!-- Insert ReM here -->
    </metadata>
  </record>
 </GetRecord>
</OAI-PMH>

2.2 SiteMaps

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

http://www.foo.edu/sitemap-rem.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-rem.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 Syndication Feeds

Even though ReMs can be serialized in the Atom Syndication Format, there is no reason preventing the use of syndication formats such as Atom or RSS [RSS] for ReM discovery. However, care must be taken to separate conceptually the Resource Map from the syndication file listing the Resource Maps. In particular, the id of an Atom entry listing the URI of a Resource Map MUST NOT be either URI-R or URI-A of the ReM or Aggregation the syndication file is making available for discovery. In other words, an explicit difference must be made between the Atom feed used for discovery and the Atom feed that is the ReM. 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>
   <title>ReM For Object1</title>
   <link href="http://www.foo.org/objects/object1.atom#aggregation"/>
   <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#aggregation"/>
   <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#aggregation"/>
   <id>urn:uuid:5225c895-cab8-8ebb-baaa-90da9d4efa6b</id>
   <updated>2007-03-15T18:30:02Z</updated>
 </entry>

</feed>

The same ReMs could be exposed via RSS 2.0. For example, this RSS feed:

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

When dereferenced would yield:

<?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#aggregation</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#aggregation</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#aggregation</link>
      <description>ReM for Object 3</description>
      <pubDate>Thu, 15 Mar 2007 08:30:02 GMT</pubDate>
    </item>

  </channel>
</rss>

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>

2.4 Combining OAI-PMH with Other Approaches

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 its corresponding URI-A. This is most commonly accomplished using the HTML link element [HTML]. This can also be accomplished using the HTTP Link response header. Alternatively, the 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 their corresponding Aggregations:

1. Full knowledge: the Aggregations is linked to by all resources in the Aggregation.
2. Limited knowledge: only a subset of the resources in the Aggregation (typically just a single resource) link to the Aggregations, and the remainder of the resources have no links at all.
3. Zero knowledge: none of the resources in the Aggregation link to a Aggregations.

Note that the above scenarios are relative to a particular ReM. It is possible for aggregated resources to simultaneously have full knowledge about 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 a corresponding URI-A which identifies the Aggregation that is aggregating the HTML file. This document introduces the value of "resourcemap" for the rel attribute to facilitate discovery of URI-R and URI-A 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.

<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">
</body>
</html>

In the above example, the HTML page links only to a single Aggregation. It could link to multiple Aggregations, in which case it is the responsibility of the agent to differentiate between the two Aggregations.

If you wish to facilitate users subscribing to an Atom-based Resource Map in the same manner as a typical Atom syndication feed, it is possible to use a single HTML link element with the rules for Atom autodiscovery [AtomFeedAutodiscovery]. Since the rel attribute takes a space separated list of values, the necessary value of "alternate" can be combined with "resourcemap" to inform the agent that the URI in the href attribute is both a Resource Map and may be desirable for user subscription. Note that type attribute is required to be "application/atom+xml", which requires linking to a Resource Map and not an Aggregation.

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

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. It is up to the agent to verify the relationship (if any) between the Resource Maps. The Atom-based ReM retains the autodiscovery technique introduced above, but now an RDF/XML-based ReM is linked as well.

<html>
<head>
<title>Hello World.</title>
<link rel="resourcemap alternate" type="application/atom+xml" href="http://example.net/hw.atom" >
<link rel="resourcemap" type="application/rdf+xml" href="http://example.net/hw.rdf" >
</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, the HTML file links to the same two Resource Maps as above, and one Aggregation. Note that rel="resourcemap" is used regardless if it is linking to URI-A or URI-R. It is up to the agent to verify the relationship (if any) between the Resource Maps and Aggregations. Even though in the example below it appears that URI-A is a "Cool URI" for the two URI-R values, the agent in this example 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>
<title>Hello World.</title>
<link rel="resourcemap alternate" type="application/atom+xml" href="http://example.net/hw.atom" >
<link rel="resourcemap" type="application/rdf+xml" href="http://example.net/hw.rdf" >
<link rel="resourcemap" href="http://example.net/hw" >
</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 carry the following values in the rel attribute to facilitate discovery techniques that are similar to the above examples:

<html>
<head>
<title>There is a ReM in This HTML...</title>
<link rel="resourcemap self" href="">
</head>
<body>
<-- HTML + microformat ReM serialization -->
</body>
</html>

3.2 HTTP Link Header

If we wish to have non-HTML resources link to their corresponding Aggregations, we cannot use the HTML link element. However, we can embed link to the URI(s) of the Aggregation(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 with the HTTP link response header. The example below shows an HTTP request and response with the Aggregation 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"; rel="resourcemap"
                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.

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

[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 and Multiple Serializations,C. Lagoze, H. Van de Sompel, P. Johnston, M. Nelson, R. Sanderson, S. Warner, 2008-06-02, Available at http://www.openarchives.org/ore/0.9/http .

[ORE Model]

ORE Specification - Abstract Data Model, C. Lagoze, H. Van de Sompel, M. Nelson, R. Sanderson, S. Warner, 2008-06-02. Available at http://www.openarchives.org/ore/0.9/datamodel .

[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, 2008-06-02. Available at http://www.openarchives.org/ore/0.9/atom-implementation .

[ReMs Using Atom]

ORE Specification - Representing Resource Maps Using the Atom Syndication Format, C. Lagoze, H. Van de Sompel, P. Johnston, M. Nelson, R. Sanderson, S. Warner, 2008-06-02. Available at http://www.openarchives.org/ore/0.9/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/.