ORE User Guide - Resource Map Implementation in Atom

Abstract

Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. OAI-ORE introduces the notion of a Resource Map, which is a specialization of a named graph that asserts a finite set of resources (the Aggregated Resources), their types, intra-relationships, and relationships with resources external to this finite set (the external resources). A Resource Map Document is a machine-readable representation of a Resource Map. Although multiple serializations of Resource Maps are possible, the initial serialization is done using the Atom Syndication Format [RFC4287]. A detailed examination of the mapping of ORE Data Model concepts to the Atom Syndication Format is known as the Resource Map Profile of Atom [ReMProfileofAtom]. The purpose of this document is to provide guidance to application developers on how to implement and interpret the Resource Map Profile of Atom. This user guide is one of several documents comprising the OAI-ORE specification and user guide.

1. Introduction

Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. OAI-ORE introduces the notion of a Resource Map, which is a specialization of a named graph that asserts a finite set of resources (the Aggregated Resources), their types, intra-relationships, and relationships with resources external to this finite set (the external resources). A Resource Map Document is a machine-readable representation of a Resource Map. Although multiple serializations of Resource Maps are possible, the initial serialization is done using the Atom Syndication Format [RFC4287]. A detailed examination of the mapping of ORE Data Model concepts to the Atom Syndication Format is known as the Resource Map Profile of Atom [ReMProfileofAtom]. The purpose of this document is to provide guidance to application developers on how to implement and interpret the Resource Map Profile of Atom. We anticipate that the contents and guidance given in this document to evolve over time to reflect the best practices of the community.

This document does not address ReM validation. Readers interested in validation are referred to Appendix C of [ReMProfileofAtom] for a Schematron Schema of the Resource Map Profile of Atom.

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

2. Populating Elements

The Atom Syndication Format defines many elements and the Resource Map Profile of Atom [ReMProfileofAtom] defines which elements have special meaning when a ReM is serialized as an Atom feed. In this section, the most common and potentially confusing elements are examined and best practices are put forward regarding their population. Throughout document, we will use the following arXiv eprint as the defining example:

http://arxiv.org/abs/astro-ph/0601007

This is an interesting example because it has multiple identifiers, versions, formats, mirrors and external relationships. Although arXiv does not yet support ReMs, we will assume in the examples below a hypothetical ReM available at the following URI ("URI-R" from [ORE Model]):

http://arxiv.org/rem/astro-ph/0601007

2.1 /feed/id and /feed/entry/id

The most important thing to address are the nature of the identifiers of Atom feeds and entries. To begin with, there is a conceptual difference between identifiers in Atom (/feed/id and /feed/entry/id) and the protocol-based URIs found in the /feed/link and /feed/entry/link elements in Atom:

The meaning of the Atom /feed/link and /feed/entry/link elements in a Resource Map is explained in the Resource Map Profile of Atom [ReMProfileofAtom]. For example, the href attribute of a /feed/entry/link with a rel attribute equal to "alternate" points at an Aggregated Resource. The URI that is used as the value the href attribute of the Atom /feed/link and /feed/entry/link elements must be protocol-based.
The identifiers from Atom (/feed/id and /feed/entry/id) have no meaning in the ORE Model, but must be provided to make Resource Maps that are valid Atom feeds. These Atom identifiers can be protocol-based URIs, or they can be non-protocol-based URIs (i.e., the URI scheme is not dereferencable). In the examples, to maintain this distinction, we will use non-protocol-based URIs for Atom identifiers. Good candidates for non-protocol-based URIs include uuids [RFC4122], tag URIs [RFC4151], and info URIs [RFC4452]. The tag and info schemes are good for conveying semantics in the identifier and uuids are good for opaque identifiers. Two considerations regarding the minting of these identifiers are important:
- The identifiers need to be globally unqiue and they need to persist. For example, once an Atom entry is created, that entry should always be served with the same Atom identifier.
- Systems that make the Atom feed accessible should consider how this persistence can be achieved. Obviously, storing the Atom identifiers is one approach. But sometimes doing so may cause unwanted overhead. As will be shown, in the case of ReMs, Atom entry identifiers can be generated based on metadata that is available to the system that makes the ReM available.

In summary, the URIs in /feed/entry/link elements identify the resource that is being aggregated and do not change based on who is doing the aggregating. The URIs in /feed/entry/id elements do change based on who is doing the aggregating.

For the arXiv eprint described above, we will assume just 3 Aggregated Resources (http://arxiv.org/ps/astro-ph/0601007 ; http://arxiv.org/pdf/astro-ph/0601007 ; http://arxiv.org/e-print/astro-ph/0601007) and that the ReM is being authored by arXiv itself, thus putting the burden of minting Atom identifiers on the arXiv itself . If a third party were to create a Resource Map for the arXiv eprint, it would have to mint the Atom identifiers. In both cases, however, the Aggregated Resources would be the same 3 ones. The skeleton of the ReM is shown below (note the necessary category element that declares this Atom Feed Document conforms to the Resource Map Profile of Atom and the link element that establishes the "describes" relationship between this ReM and the Aggregation the ReM describes):

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

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
 </entry>

</feed>

As can be seen, arXiv minted Atom identifiers in the tag URI namespace, and using metadata that pertains to each of the Aggregated Resources of the ReM. It should be noted that for each Aggregated Resource of a ReM, there is a unique combination of values that could be used for the creation of an Atom entry identifier, namely the URI of the ReM itself and the URI of the Aggregated Resource conveyed by the Atom entry. This combination could be used as the seed to achieve a unique re-computable identifier, for example by concatenating the URIs and creating a hash over them.

2.2 /feed/link[@rel="self"] and /feed/entry/link[@rel="alternate"]

Now that Atom identifiers are populated, we turn to the values of the link elements. The ReM asserts its own URI by means of /feed/link[@rel="self"], and it asserts the URIs of the Aggregated Resources by means of /feed/entry/link[@rel="alternate"], for the remainder of this section referred to as the feed link and the entry links, respectively. The feed link, like the Atom identifiers described above is relative to the author of the ReM. In particular, it gives the URI where this particular ReM can be found.

Unlike the feed link and Atom identifiers described above which would change based on the author of the ReM (i.e., 1st or 3rd party ReMs), the URIs in the entry links do not change. They are the Aggregated Resources, regardless of who is doing the aggregation.

Expanding our skeleton ReM, we now have:

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

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
 </entry>

</feed>

2.3 /feed/title, /feed/entry/title, and /feed/author

The values for /feed/author, /feed/title and /feed/entry/title are not necessarily what one would first expect. These elements are not for encoding metadata about the the Atom feed (ReM) and Atom entries. This means the /feed/title is not "Parametrization of K-essence and Its Kinetic Term", and similarly the /feed/author/name is not "Hui Li, Zong-Kuan Guo, Yuan-Zhong Zhang". The section below addresses how to incorporate metadata about the Aggregation into the Resource Map Profile of Atom. We recommend listing the URI, prepended with the literal "Resource Map" or "Aggregated Resource" for /feed/title and /feed/entry/title, respectively. This gives meaningful values for the titles, but at the same time underscores that they are titles and not link elements. In this example, the author of the ReM is the arXiv repository itself. Note that the /feed/entry/author element MUST NOT be used in ReMs. Authorship is inherited from the /feed/author element or from the /feed/entry/source/authorelement if that exists. See section 4.2.1 of [ReMProfileofAtom] for a detailed explanation.

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

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
 </entry>

</feed>

2.4 /feed/updated and /feed/entry/updated

Whereas RFC-4287 allows updated to be changed "when an entry or feed was modified in a way the publisher considers significant", the Resource Map Profile of Atom is more strict. The /feed/updated value SHOULD match the "Last-Modified" HTTP response header [RFC2616], if that header exists. If the "Last-Modified" header does not exist (which can happen when a resource is dynamically generated), the /feed/updated MAY be the value in the "Date" HTTP response header (the date the HTTP response was generated). However, in this case of the "Last-Modified" HTTP response header not being available, it is RECOMMENDED that the ReM publisher keep track of what the correct value of /feed/updated should be and strictly update its value based on any modification, significant or not. See section 4.2.15 of [ReMProfileofAtom] for a detailed explanation.

Populating /feed/entry/updated is more subtle. Even in the case of 1st party ReMs (such as the arXiv example explored here), /feed/entry/updated is not "Last-Modified" HTTP response header of the Aggregated Resource, but rather the last time the Aggregation described by the ReM made an assertion about the Aggregated Resource. In other words, /feed/entry/updated is the datestamp of that particular Atom entry, not the Aggregated Resource described by that entry.

Finally, the value of /feed/updated MUST always be equal to or later in time than the values of all /feed/entry/updated elements.

In our example ReM, we have all the /feed/entry/updated values being the same (in the case of arXiv, all the resources were aggregated at the same time), but we show a different datestamp for /feed/updated to correspond with an edit of the ReM.

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

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>
  <updated>2007-10-10T18:30:02Z</updated>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>

</feed>

2.5 GRDDL crosswalk from Atom XML to RDF/XML

The up-to-date version of the GRDDL-compliant XSLT to transform an Atom-based serialization of a Resource Map into a serialization in RDF/XML is available at http://www.openarchives.org/ore/atom-grddl.xsl. In order to allow Atom-based Resource Maps to be readily transformed in this manner, it is RECOMMENDED to add GRDDL namespace and transformation information as attributes to the /feed element.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:grddl="http://www.w3.org/2003/g/data-view#" 
      grddl:transformation="http://www.openarchives.org/ore/atom-grddl.xsl">

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>
  <updated>2007-10-10T18:30:02Z</updated>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>

</feed>

3. Providing Metadata for the Aggregation

With few exceptions, typical bibliographic metadata about either the Aggregation or the Aggregated Resources is conveyed with elements outside the Atom namespace. In this section we look out how to handle common metadata requirements.

We show three ways to add metadata to and about the Aggregation. First, the aggregation can have additional identifiers such as DOIs or Handles. The arXiv example has an info URI associated with the aggregation and we encode it with the feed/link[@rel="related"] element. This element can be repeated for additional identifiers as well. Second, we provide some minimal bibliographic metadata (title, creator) by importing from another namespace, in this case from the Dublin Core namespace. To facilitate conversion to RDF, we encourage the use URIs instead of literal values (e.g., "Zong-Kuan Guo"), but we acknowledge that often these URIs are unavailable. As described in section 2.3, the /feed/title and /feed/author elements MUST NOT be used for this purpose. Finally, we add a fourth Aggregated Resource, which is the OAI-PMH metadata available from the arXiv E-print repository. Although not required, in this example, we modify the /feed/entry/title to add a human-readable hint that this Aggregated Resource is metadata. To unambiguously mark it as bibliographic metadata, we import an element from the RDF namespace (although in the example below, it uses an Info URI namespace (eu-repo) that is pending registration). We also show a different /feed/entry/updated value.

It is up to the author of the ReM to decide what best approach for including Aggregation metadata: importing from other namespaces, aggregating resources that are metadata, or some combination of both.

Providing bibliographic metadata for the Aggregated Resources is done similarly, but the elements in the imported namespaces are enclosed in the appropriate /feed/entry elements. In this example, we annotate the last Aggregated Resource with a free text description that the Aggregated Resource is LaTeX source files.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:grddl="http://www.w3.org/2003/g/data-view#" 
      grddl:transformation="http://www.openarchives.org/ore/atom-grddl.xsl"
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/">

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>
  <updated>2007-10-10T18:30:02Z</updated>
  <link href="info:arxiv/astro-ph/0601007v2" rel="related"/>
  <dc:title>Parametrization of K-essence and Its Kinetic Term</dc:title>
  <dc:creator>Hui Li</dc:creator>
  <dc:creator>Zong-Kuan Guo</dc:creator>
  <dc:creator>Yuan-Zhong Zhang</dc:creator>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:oai-opmh</id>
   <link href="http://export.arxiv.org/oai2?verb=GetRecord&amp;metadataPrefix=oai_dc&amp;identifier=astro-ph/0601007" 
   rel="alternate"/>
   <title>Aggregated Resource Dublin Core Metadata</title>
   <rdf:type>info:eu-repo/semantics/DescriptiveMetadata</rdf:type>
   <updated>2006-09-27T00:00:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
   <dc:description>LaTeX Source Files</dc:description>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>

</feed>

4. Common Scenarios

In this section we review the appropriate techniques within the Resource Map Profile of Atom for handling common scenarios for Aggregations.

4.1 Multiple Formats

In the example we have been working with, the PostScript, PDF and the page containing links to other formats are all considered separate Aggregated Resources and not simply the same Aggregated Resource realized in multiple MIME types. This differs from the typical Atom Syndication Format idiom, where multiple MIME types are often grouped in the same entry element.

We can also express that Aggregated Resources share a format relationship. In this example, we link the PostScript and PDF formats together by placing hasFormat elements (from the dcterms namespace) in each Atom entry, referencing each other.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:grddl="http://www.w3.org/2003/g/data-view#" 
      grddl:transformation="http://www.openarchives.org/ore/atom-grddl.xsl"
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/"
      xmlns:dcterms="http://purl.org/dc/terms/">

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>
  <updated>2007-10-10T18:30:02Z</updated>
  <link href="info:arxiv/astro-ph/0601007v2" rel="related"/>
  <dc:title>Parametrization of K-essence and Its Kinetic Term</dc:title>
  <dc:creator>Hui Li</dc:creator>
  <dc:creator>Zong-Kuan Guo</dc:creator>
  <dc:creator>Yuan-Zhong Zhang</dc:creator>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:oai-opmh</id>
   <link href="http://export.arxiv.org/oai2?verb=GetRecord&amp;metadataPrefix=oai_dc&amp;identifier=astro-ph/0601007" 
   rel="alternate"/>
   <title>Aggregated Resource Dublin Core Metadata</title>
   <rdf:type>info:eu-repo/semantics/DescriptiveMetadata</rdf:type>
   <updated>2006-09-27T00:00:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
   <dcterms:hasFormat>http://arxiv.org/pdf/astro-ph/0601007v1</dcterms:hasFormat>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
   <dcterms:hasFormat>http://arxiv.org/ps/astro-ph/0601007v1</dcterms:hasFormat>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
   <dc:description>LaTeX Source Files</dc:description>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>

</feed>

4.2 Mirror Copies

arXiv maintains many mirrors throughout the world. For example, the the same e-print can be accessed at the mirror repository in Japan with this URI:

http://jp.arxiv.org/abs/astro-ph/0601007

We treat this the same as adding an additional identifier (such as the arXiv info URI) and use the feed/link[@rel="related"] element.

<?xml version="1.0" encoding="utf-8"?> 
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:grddl="http://www.w3.org/2003/g/data-view#" 
      grddl:transformation="http://www.openarchives.org/ore/atom-grddl.xsl"
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/"
      xmlns:dcterms="http://purl.org/dc/terms/">

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>
  <updated>2007-10-10T18:30:02Z</updated>
  <link href="info:arxiv/astro-ph/0601007v2" rel="related"/>
  <link href="http://jp.arxiv.org/abs/astro-ph/0601007" rel="related"/>
  <dc:title>Parametrization of K-essence and Its Kinetic Term</dc:title>
  <dc:creator>Hui Li</dc:creator>
  <dc:creator>Zong-Kuan Guo</dc:creator>
  <dc:creator>Yuan-Zhong Zhang</dc:creator>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:oai-opmh</id>
   <link href="http://export.arxiv.org/oai2?verb=GetRecord&amp;metadataPrefix=oai_dc&amp;identifier=astro-ph/0601007" 
   rel="alternate"/>
   <title>Aggregated Resource Dublin Core Metadata</title>
   <rdf:type>info:eu-repo/semantics/DescriptiveMetadata</rdf:type>
   <updated>2006-09-27T00:00:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <dcterms:hasFormat>http://arxiv.org/ps/astro-ph/0601007v1</dcterms:hasFormat>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
   <dcterms:hasFormat>http://arxiv.org/ps/astro-ph/0601007v1</dcterms:hasFormat>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
   <dc:description>LaTeX Source Files</dc:description>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>

</feed>

4.3 Versions

The arXiv example we have been working with is actually version 2 of the e-print. Up until now, we have not distinguished the second (current) version vs. the first (older version). To do so, we import the hasVersion element from the dcterms namespace and place this new metadata element at the Aggregation level. The value of this element is the URI of the previous version. If we wanted to inform the agent that the older version should be considered deprecated, we would use the replaces element from the same namespace.

This example also has a DOI identifying a related (i.e., published) version of the e-print. We express this DOI with the feed/link[@rel="related"] element.

<?xml version="1.0" encoding="utf-8"?> 
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:grddl="http://www.w3.org/2003/g/data-view#" 
      grddl:transformation="http://www.openarchives.org/ore/atom-grddl.xsl"
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/"
      xmlns:dcterms="http://purl.org/dc/terms/">

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>
  <updated>2007-10-10T18:30:02Z</updated>
  <link href="info:doi/10.1142/S0217732306019475" rel="related"/>
  <link href="info:arxiv/astro-ph/0601007v2" rel="related"/>
  <link href="http://jp.arxiv.org/abs/astro-ph/0601007" rel="related"/>
  <dc:title>Parametrization of K-essence and Its Kinetic Term</dc:title>
  <dc:creator>Hui Li</dc:creator>
  <dc:creator>Zong-Kuan Guo</dc:creator>
  <dc:creator>Yuan-Zhong Zhang</dc:creator>
  <dcterms:hasVersion>http://arxiv.org/abs/astro-ph/0601007v1</dcterms:hasVersion>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:oai-opmh</id>
   <link href="http://export.arxiv.org/oai2?verb=GetRecord&amp;metadataPrefix=oai_dc&amp;identifier=astro-ph/0601007" 
   rel="alternate"/>
   <title>Aggregated Resource Dublin Core Metadata</title>
   <rdf:type>info:eu-repo/semantics/DescriptiveMetadata</rdf:type>
   <updated>2006-09-27T00:00:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <dcterms:hasFormat>http://arxiv.org/pdf/astro-ph/0601007v1</dcterms:hasFormat>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
   <dcterms:hasFormat>http://arxiv.org/ps/astro-ph/0601007v1</dcterms:hasFormat>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
   <dc:description>LaTeX Source Files</dc:description>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>

</feed>

4.4 Splash Pages

So-called "splash" pages that conventionally serve as a human-readable surrogate for an Aggregation other resources; they are the page that human agents "start" at. From the point of view of the ReM, they are just another Aggregated Resource, albeit with an element from the RDF namespace indicating to automated agents that one of the Aggregated Resources is distinguished and can serve as the entry point for humans navigating the Aggregation. This is done in the same manner as marking the bibliographic metadata above, using the values from the proposed info:eu-repo/ namespace. In our example, the arXiv "splash" page is added as an Aggregated Resource.

<?xml version="1.0" encoding="utf-8"?> 
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:grddl="http://www.w3.org/2003/g/data-view#" 
      grddl:transformation="http://www.openarchives.org/ore/atom-grddl.xsl"
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/"
      xmlns:dcterms="http://purl.org/dc/terms/">

  <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
  <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
  <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
  <author>
    <name>arXiv.org e-Print Repository</name>
    <uri>http://arxiv.org/</uri>
    <email>www-admin@arxiv.org</email>
  </author>
  <updated>2007-10-10T18:30:02Z</updated>
  <link href="info:doi/10.1142/S0217732306019475" rel="related"/>
  <link href="info:arxiv/astro-ph/0601007v2" rel="related"/>
  <link href="http://jp.arxiv.org/abs/astro-ph/0601007" rel="related"/>
  <dc:title>Parametrization of K-essence and Its Kinetic Term</dc:title>
  <dc:creator>Hui Li</dc:creator>
  <dc:creator>Zong-Kuan Guo</dc:creator>
  <dc:creator>Yuan-Zhong Zhang</dc:creator>
  <dcterms:hasVersion>http://arxiv.org/abs/astro-ph/0601007v1</dcterms:hasVersion>

 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:abs</id>
   <link href="http://arxiv.org/abs/astro-ph/0601007" rel="alternate" type="text/html"/>
   <title>Aggregated Resource http://arxiv.org/abs/astro-ph/0601007</title>
   <rdf:type>info:eu-repo/semantics/humanStartPage</rdf:type>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:oai-opmh</id>
   <link href="http://export.arxiv.org/oai2?verb=GetRecord&amp;metadataPrefix=oai_dc&amp;identifier=astro-ph/0601007" 
   rel="alternate"/>
   <title>Aggregated Resource Dublin Core Metadata</title>
   <rdf:type>info:eu-repo/semantics/DescriptiveMetadata</rdf:type>
   <updated>2006-09-27T00:00:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:ps</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <dcterms:hasFormat>http://arxiv.org/pdf/astro-ph/0601007v1</dcterms:hasFormat>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/pdf/astro-ph/0601007" rel="alternate" type="application/pdf"/>
   <title>Aggregated Resource http://arxiv.org/pdf/astro-ph/0601007</title>
   <dcterms:hasFormat>http://arxiv.org/ps/astro-ph/0601007v1</dcterms:hasFormat>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:e-print</id>
   <link href="http://arxiv.org/e-print/astro-ph/0601007" rel="alternate"/>
   <title>Aggregated Resource http://arxiv.org/e-print/astro-ph/0601007</title>
   <dc:description>LaTeX Source Files</dc:description>
   <updated>2006-05-31T12:52:00Z</updated>
 </entry>

</feed>

5. Linking to Other Aggregations

The Data Model Document [ORE Model] defines the notion of Aggregations linking to other Aggregations with two relationships: ore:aggregates and ore:isAggregatedBy. The latter allows a ReM to reference the origin of its Aggregated Resources in another ReM, providing a verifiable lineage of discovery and provenance. Atom provides two mechanisms for establishing the provenance of /feed/entry elements: /feed/entry/source (used to link to the initial occurence) and feed/entry/link[@rel="via"]/@href (used to link to the most recent occurence). The feed/entry/link[@rel="via"]/@href approach is used to implement the ore:isAggregatedBy relationship (for details, see Table 3 of the [ReM Profile of Atom]). Although /feed/entry/source has no direct correspondence in the ORE Abstract Data Model [ORE Model], it is covered here because it is part of the Atom idiom.

5.1 /feed/entry/source

Imagine our example arXiv e-print has been selected for inclusion in an overlay journal, and this overlay journal also uses ReMs to describe Aggregations (in this case, journal issues) at their site. The journal wishes to use only the PDF version of the e-print and not the entire arXiv Aggregation.

As described in section 4.2.11 of [ReM Profile of Atom], the overlay journal MUST copy and paste the entire entry element that conveys the PDF file as an Aggrgated Resource into the ReM of the overlay journal. In addition, they MUST populate the Atom /feed/entry/source element with metadata from the original (arXiv) ReM, specifically the /feed/id, /feed/link, /feed/title, /feed/rights, /feed/category, and /feed/updated elements MUST be copied. In the example below, we are looking at the ReM of the overlay journal, with only the entry element from the arXiv ReM shown.

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

  <id>tag:overlay-journal.org,2007:vol=12,number=5</id>
  <link href="http://www.overlay-journal.org/12/05/rem.atom" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://www.overlay-journal.org/12/05/rem.atom#aggregation" />
  <title>Resource Map http://www.overlay-journal.org/12/05/rem.atom</title>
  <author>
    <name>Overlay Journal for Frog &amp; Toad Studies</name>
    <uri>http://www.overlay-journal.org/</uri>
    <email>help@overlay-journal.org</email>
  </author>
  <updated>2007-12-12T15:30:02Z</updated>

<!--other entries of the overlay journal-->
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
   <source>
     <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
     <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
     <category scheme="http://www.openarchives.org/ore/terms/"
     term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
     <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
     <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
     <author>
       <name>arXiv.org e-Print Repository</name>
       <uri>http://arxiv.org/</uri>
       <email>www-admin@arxiv.org</email>
     </author>
     <updated>2007-10-10T18:30:02Z</updated>
     <link href="info:doi/10.1142/S0217732306019475" rel="related"/>
     <link href="info:arxiv/astro-ph/0601007v2" rel="related"/>
     <link href="http://jp.arxiv.org/abs/astro-ph/0601007" rel="related"/>
   </source>
 </entry>
 
<!--other entries of the overlay journal-->

</feed>

5.2 /feed/entry/link[@rel="via"]/@href

Now imagine this issue of the overlay journal becomes popular in the scientific blog community, and this particular arXiv PDF is linked to many times. If the arXiv ReM is the first occurrence and the overlay journal is the second occurrence, then the first blog to comment on it is the third occurrence, and if a second blog discovers the PDF from the first blog, that is then the fourth occurrence and so forth.

Now because the /feed/entry/source element is already present in the ReM of the overlay journal, each subsequent blog reference will be copied verbatim with the original arXiv information retained in each blog's /feed/entry/source element. That means the 98th, 99th and 100th blog will each have the a reference back to the original arXiv ReM. But we would also like to capture that blog 100 discovered the PDF from blog 99. This is accomplished using the /feed/entry/link[@rel="via"]/@href element. If /feed/entry/source always maintains a reference to the original ReM, /feed/entry/link[@rel="via"]/@href always maintains a reference to the previous (i.e., "n-1") ReM. In the example below, the ReM for blog 100 is shown with a /feed/entry/link[@rel="via"]/@href element establishing the lineage to the ReM of blog 99 and the arXiv ReM.

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

  <id>tag:blog100.blogsrus.org,2007:entry1322</id>
  <link href="http://blog100.blogsrus.org/entry/1322.atom" rel="self" type="application/atom+xml"/>
  <category scheme="http://www.openarchives.org/ore/terms/" 
  term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
  <link rel="describes" href="http://blog100.blogsrus.org/entry/1322.atom#aggregation" />
  <title>Resource Map http://blog100.blogsrus.org/entry/1322.atom</title>
  <author>
    <name>Blog100</name>
    <uri>http://blog100.blogsrus.org//</uri>
    <email>blog100@blogsrus.org</email>
  </author>
  <updated>2007-12-25T12:30:42Z</updated>

<!--other entries of the blog100-->
 
 <entry>
   <id>tag:arxiv.org,2007:astro-ph/0601007v2:pdf</id>
   <link href="http://arxiv.org/ps/astro-ph/0601007" rel="alternate" type="application/postscript"/>
   <title>Aggregated Resource http://arxiv.org/ps/astro-ph/0601007</title>
   <updated>2006-05-31T12:52:00Z</updated>
   <link href="http://blog99.toadscience.com/entry742.atom" rel="via" type="application/atom+xml"/>
   <source>
     <id>tag:arxiv.org,2007:astro-ph/0601007v2</id>
     <link href="http://arxiv.org/rem/astro-ph/0601007" rel="self" type="application/atom+xml"/>
     <category scheme="http://www.openarchives.org/ore/terms/"
     term="http://www.openarchives.org/ore/terms/ResourceMap" label="Resource Map" />
     <link rel="describes" href="http://arxiv.org/rem/astro-ph/0601007#aggregation" />
     <title>Resource Map http://arxiv.org/rem/astro-ph/0601007</title>
     <author>
       <name>arXiv.org e-Print Repository</name>
       <uri>http://arxiv.org/</uri>
       <email>www-admin@arxiv.org</email>
     </author>
     <updated>2007-10-10T18:30:02Z</updated>
     <link href="info:doi/10.1142/S0217732306019475" rel="related"/>
     <link href="info:arxiv/astro-ph/0601007v2" rel="related"/>
     <link href="http://jp.arxiv.org/abs/astro-ph/0601007" rel="related"/>
   </source>
 </entry>
 
<!--other entries of blog100-->

</feed>

Note that in section 5.1 above, the overlay journal could have used /feed/entry/link[@rel="via"]/@href element in addition to /feed/entry/source to reference the original arXiv ReM. However, this was omitted from section 5.1 for clarity because that is a special case where the original ReM and the previous ReM were the same (i.e., the arXiv ReM).

6. References

[ORE Model]: ORE Specification - Abstract Data Model, C. Lagoze, H. Van de Sompel, P. Johnston, M. Nelson, R. Sanderson, S. Warner, 2007, Available at http://www.openarchives.org/ore/datamodel.
[ReMProfileofAtom]: ORE Specification - Resource Map Profile of Atom, C. Lagoze, H. Van de Sompel, P. Johnston, M. Nelson, R. Sanderson, S. Warner, 2007, Available at http://www.openarchives.org/ore/atom.
[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, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.
[RFC4122]: IETF RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace, P. Leach, M. Mealling, R. Salz, July 2005. Available at http://www.ietf.org/rfc/rfc4122.txt.
[RFC4151]: IETF RFC 4151: The 'tag' URI Scheme, T. Kindberg, S. Hawke, October 2005. Available at http://www.ietf.org/rfc/rfc4151.txt.
[RFC4287]: IETF RFC 4287: The Atom Syndication Format, M. Nottingham, R. Sayre, December 2005. Available at http://www.ietf.org/rfc/rfc4287.txt.
[RFC4452]: IETF RFC 4452: The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces, H. Van de Sompel, T. Hammond, Manifest Solutions, S. Weibel, April 2006. Available at http://www.ietf.org/rfc/rfc4452.txt.

Date	Editor	Description
2008-02-29	mln	public alpha 0.2 release
2007-12-10	mln	public alpha 0.1 release
2007-10-15	mln	alpha release to ORE-TC