1. Introduction

The Architecture of the World Wide Web [Web Architecture] uses the term Resource to refer to any item of interest. Some web content, such as a stand-alone HTML document, is contained within one Resource. But frequently a logical unit of web information is actually an aggregation of Resources. Examples of these aggregations are:

• A simple unordered set, or bag, of Resources, such as a collection of favorite images from various Web sites.
• A multi-page, HTML document where the pages are linked together by hyperlinks that provide "previous page" and "next page" access.
• Information available from "social networking" sites, which contain content and related social activity around that content. An example is flickr, where each participant has an entry page providing access to images in multiple sizes and resolutions that are organized in sets and collections. All of these entities are separate Resources. These are then linked to additional Resources that are comments and annotations about the images.
• A scholarly publication stored in an ePrint repository such as arXiv or in a DSpace, ePrints, or Fedora repository. Such a publication may appear on the Web as multiple Resources, each with an individual URI. The set of Resources typically consists of a human readable "splash page", that links to the body of the publication in multiple formats such as LaTeX, PDF, and HTML. In addition, the publication may have citation links to other publications, each existing as one or more Resources.
• An overlay journal issue that aggregates multiple scholarly publications as described above, each located in their origin repository, into an issue. Issues may be recursively aggregated themselves into volumes, and then into the journal itself.
• A semantically-linked group of cellular images — each available as a Resource resident in repositories from research laboratories, museums, libraries, and the like — in the manner implemented in the ImageWeb Project.
• Published scientific results such as those envisioned by  [Lynch CTWatch] that, in addition to the features of the scholarly publication described above, incorporate data plus the tools to visualize and analyze that data.

These aggregations exhibit the following characteristics:

• They consist of one or more Resources, which all may be located on one web server, or may be distributed over the Web.
• Relationships may exist between Resources in the aggregation that express semantics indicating that one Resource has a containment relationship to another, one is an alternate version or format of another, and the like.
• One or more of the Resources in the aggregation may have types, where the types are defined by various vocabularies. Informal examples of such types are "splash page", "bibliography", or "table of contents".
• Relationships may exist between the aggregation and/or the individual Resources in the aggregation and information units external to the Aggregation. These external resources may be individual Resources or aggregations themselves. Examples of such relationships include citations, mirrors, and translations.

A mechanism to associate identities with these aggregations and describe them in a machine-readable manner would make them visible to Web agents including browsers and crawlers. These machine-readable descriptions could then be the basis of user interfaces, allowing users to navigate and manipulate the aggregations. Some example applications and contexts where "aggregation-awareness" might be useful include:

• Crawler-based search engines could use such descriptions to index information and provide search results sets at the granularity of the aggregations rather or in addition to their individual parts.
• Browsers could leverage them to provide users with navigation aids for the aggregated resources, in the same manner that machine-readable site maps provide navigation clues for crawlers.
• Other automated agents such as preservation systems could use these descriptions as guides to understand a "whole document" and determine the best preservation strategy for the document [Compound Object].
• Systems that mine and analyze networked information for citation analysis/bibliometrics could achieve better accuracy with the knowledge of aggregation structure contained in these descriptions.
• Institutional repository applications could use them as the basis of interoperability for exchange and service interaction with other institutional repositories.
• These machine-readable descriptions could provide the foundation for advanced scholarly communication systems that allow the flexible reuse and refactoring of rich scholarly artifacts and their components [Value Chains][SCOPE].

This document describes the Open Archives Initiative Object Reuse and Exchange (OAI-ORE) data model for the description and exchange of aggregations of Web resources, named Aggregations. OAI-ORE introduces the notion of Resource Maps that describe an Aggregation. A Resource Map describes an Aggregation: it asserts the finite set of constituent resources (the Aggregated Resources) of the Aggregation, and it can express types and relationships pertaining to the Aggregation and its Aggregated Resources. This data model conforms to the concepts defined in the Architecture of the World Wide Web [Web Architecture].

The ORE Model can be implemented in a variety of serialization formats. The details of these formats are described in companion ORE documents. The nature of a particular serialization format and its respective expressiveness may affect the details of the mapping from the model to the implementation. This mapping is described in detail in each serialization specification.

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

The use of fonts is as follows:

• Vocabulary terms, including classes and predicates, are written in this font. Predicates have a non-capitalized first-letter but are subsequently camel-cased to indicate word separation. Classes have a capitalized first letter and are then camel-cased to indicate word separation.
• The initial defining use of entities in the model appear in this font. The names of these entities are subsequently capitalized.

1.2 Namespaces

This specification uses the following namespaces and prefixes to indicate those namespaces:

2. Foundations

The ORE Data Model builds on the following foundation technologies and architectures.

• The architecture of the World Wide Web [Web Architecture].
• Semantic Web concepts including RDF [RDF Concepts] and the RDF Vocabulary Description Language [RDFS].
• Cool URIs [Cool URIs] and Linked Data [Linked Data Tutorial].

Readers unfamiliar with these technologies are encouraged to refer to reference documents for each. A brief introduction to the relevant aspects of these technologies is also available in the ORE Primer.

3. Data Model Entities

The ORE Abstract Data Model includes the entities that are described in the remainder of this section.

3.1 Aggregation

An Aggregation is a Resource of type ore:Aggregation that is a set of other Resources. The type ore:Aggregation is associated with a Resource via an assertion by at least one Resource Map. The association between a Resource Map and an Aggregation is described in a section 4.1.

This specification uses URI-A to denote URIs that identify Aggregations. Because URI-A identifies the Aggregation, it SHOULD be used as the target of links referring to the set of Resources as a logical unit. Examples of such links are citation, review, annotation, and the like.

Because a URI-A identifies the Aggregation, it SHOULD NOT be a URI used for another purpose, such as the URI of a specific manifestation of some content — for example, the PDF of some scholarly paper — or the URI of a human-readable "splash page", which really identifies only that page and not the Aggregation as a whole.

A URI-A MUST be a protocol-based URI. However, an Aggregation is a conceptual construct, and thus it does not have a Representation. In contrast, a Resource Map that asserts the Aggregation does have a Representation in which that assertion is made available to clients and agents. The Cool URIs for the Semantic Web guidlines are adopted to support discovery of the HTTP URI of the asserting Resource Map given the HTTP URI of an Aggregation. Details about the mechanisms of access are described in ORE User Guide - HTTP Implementation.

3.2 Aggregated Resource

An Aggregated Resource is a Resource that is a constituent of an Aggregation due to an assertion in a Resource Map that describes the containing Aggregation.The manner in which these assertions are made is described in section 4.3.

This specification uses URI-AR to denote URIs that identify Aggregated Resources. A URI-AR MUST be a protocol-based URI.

3.3 Resource Map (ReM)

A Resource Map (ReM) is a Resource, with type ore:ResourceMap, with information content consisting of assertions that:

• MUST describe a single Aggregation.
• MUST enumerate the constituent Aggregated Resources.
• MAY include additional properties about the Aggregation and Aggregated Resources, such as relationships among the Aggregated Resources, relationships from the Aggregated Resources to other Resources, and other properties.

The nature of these assertions are described in section 4.1.

Each Resource Map MUST be identified by a single protocol-based URI, which MUST be distinct from the Aggregation identified by the Resource Map. This specification uses URI-R to denote URIs that identify Resource Maps. There MAY be multiple Resource Maps for a single Aggregation. Each Resource Map MUST have a distinct URI (rather than forming multiple Representations from a single URI-R). A deference of a URI-R results in a serialization which the assertions described above can be extracted as a set of triples that when combined form an RDF Graph that MUST conform to a well-defined structure.

Multiple Resource Maps MAY contain assertions about the same Aggregation, identified in each with a single URI, URI-A. These Resource Maps fall into two classes:

• An Authoritative Resource Map is one that is accessible via a dereference of the URI-A of the Aggregation that it describes. Details about the mechanisms of access are described in ORE User Guide - HTTP Implementation. There MUST be at least one Authoritative Resource Map for each Aggregation. There MAY be many Authoritative Resource Maps for an Aggregation, each with a unique URI-R. As noted above each URI-R MUST dereference to one serialization. The serializations available from this set of URI-Rs SHOULD be in distinct formats (e.g., ATOM, RDF/XML). However, the RDF graph derivable from those serializations MUST express the same Aggregation Graph and define the same Proxies.
• A Non-Authoritative Resource Map is one that contains assertions about a URI-A, without reference from information obtained via a dereference of URI-A. Because of the nature of the Web, where agents may assert any information, multiple non-authoritative Resource Maps MAY exist. Clients SHOULD assume that the agent or authority responsible for the creation of a non-authoritative Resource Map is independent from and not recognized by the agent or authority responsible for the Aggregation. Note that because of their creation by independent agents, this specification expresses no rules about their composition. It is RECOMMENDED that Agents not create non-authoritative Resource Maps. Instead, an agent SHOULD define another URI-A (a distinct aggregation), define one or more Authoritative Resource Maps describing that Aggregation, and use the methods described below to assert a relationship between the two Aggregations.
  

Unless specifically noted, the remainder of this specification will describe only authoritative Resource Maps. The qualifier "authoritative" will only be used for appropriate emphasis.

3.4 Proxy

A Proxy is a Resource, with type ore:Proxy, that indicates an Aggregated Resource in the context of a specific Aggregation. The type ore:Proxy is associated with a Resource via an assertion in a Resource Map that describes the Aggregation that is the context of the Proxy.The URI of a Proxy, indicated by URI-P throughout this specification, then can be used in assertions specific to the Aggregated Resource in the context of that aggregation. This contrasts with the URI-AR of the Aggregated Resource, which has no special meaning relative to the Aggregation. The use of Proxies, which are OPTIONAL, is described in section 5.3.

A Proxy URI (URI-P) MUST be unique to both an Aggregation (URI-A) and to a particular Aggregated Resource (URI-AR) of that Aggregation. Using the terminology described above this means that a URI-P asserted in an authoritative Resource Map for one URI-A MUST NOT be asserted in Resource Maps that describe another URI-A. When implemented using HTTP, Proxy URIs SHOULD conform to certain requirements.

4. RDF Graph of a Resource Map - Basics

A Resource Map asserts a set of RDF triples expressing information about an Aggregation, its constituent Aggregated Resources, metadata about the Aggregation and Resource Map, and other Relationships. The RDF Graph that is manifested by the triples asserted by a Resource Map MUST conform to a number of restrictions. The graph MUST be connected, with its structure defined as follows (and expanded upon in the numbered section accompanying each bullet):

• It MUST express the relationship between the Resource Map and the Aggregation described by the Resource Map (4.1).
• It MUST express basic metadata about the Resource Map and MAY express additional metadata about the Resource Map and Aggregation (4.2).
• It MUST express the relationships between the Aggregation and one or more Aggregated Resources that are constituents of the Aggregation. (The subgraph of the Resource Map resulting from these relationships is referred to as the Aggregation Graph) (4.3).
• It MAY express relationships between the Aggregation and similar resources (4.4).
• It MAY express relationships between Resources in the Aggregation Graph and other Resources and Types (4.5).

The remainder of this section explains the components of this graph in a step-by-step progression. The constraints on the graph are summarized in a table later in this document.

Later sections describe how to extend this RDF Graph to assert relationships between Aggregations and the use of Proxies to establish Aggregation-specific URIs for Aggregated Resources.

4.1 Relationship between a Resource Map and an Aggregation

A Resource Map MUST include one triple with an ore:describes predicate. The subject of this triple MUST be the URI-R of the Resource Map. The object is the URI-A of the Aggregation described by the Resource Map. The URI-A that is the object of this triple MUST NOT be the same as URI-R. A Resource Map MUST NOT include more than one triple with the ore:describes predicate.

The ore:describes relationship asserts that the Resource denoted by the subject is a resource of type ore:ResourceMap and the Resource denoted by the object is a resource of type ore:Aggregation. Therefore, the explicit inclusion in the Resource Map of triples asserting these types is OPTIONAL.

The figure below illustrates the RDF Graph expressing the relationship between a Resource Map and an Aggregation. The triples producing the graph are included below the graph. The table to the right of the triples shows the URIs used to identify the Resources and relationships. The syntax of the URIs in the triples table are illustrative only and the reader SHOULD NOT infer metadata about the identified resource from the form of the URIs. The ORE User Guide - HTTP Implementation describes implementation details on suggested syntax for URIs used in ORE.

As described earlier, multiple Resource Maps MAY assert an ore:describes relationship with the same URI-A as the object of the triple. In the case where there are multiple Resource Maps, each Resource Map SHOULD assert a triple with the ore:isDescribedBy predicate (the inverse of ore:describes) expressing a relationship with each other authoritative Resource Map. These triples make alternate serializations of a Resource Map visible to clients.

The figure below illustrates the existence of multiple Resource Maps and the use of the ore:isDescribedBy predicate. Note that the illustrated assertions are expressed by ReM-1 in the figure.

4.2 Metadata about the Resource Map and Aggregation

A Resource Map MUST express minimal metadata properties about the Resource Map. Those metadata properties are:

• The identity of the authoring authority (human, organization, or agent) of the Resource Map, using the dcterms:creator predicate, with an object that MUST be a reference to a Resource of type http://purl.org/dc/terms/Agent. This MAY then be the subject of the following triples:
  • A triple with the predicate foaf:name and an object that is a text string containing some descriptive name of the authoring authority.
  • A triple with the predicate foaf:mbox and an object that is a URI that is the email address of the authoring authority.
• The last modification date-timestamp of the Resource Map, using the dcterms:modified term. This date-timestamp MUST be updated when the triples asserted within the Resource Map, and expressed in the serializations of that Resource Map, change so that consuming clients of the can determine appropriate actions.

A Resource Map MAY include additional metadata properties about the Resource Map. Examples of additional metadata properties are:

• Rights information related to the use of the Resource Map, using the dc:rights term. (Note rights information for the Resource Map is distinct from that for the Aggregation. The latter MAY be described separately as described below.) 
• The initial creation datetimestamp of the Resource Map, using the dcterms:created term.

A Resource Map MAY assert metadata properties about the Aggregation. These metadata properties MAY be defined by a variety of vocabularies. A common metadata property is the identity of the authoring authority (human, organization, or agent) of the Aggregation, using the dcterms:creator predicate.

The figure below shows an RDF Graph expressed by a Resource Map that includes metadata properties about Resource Map and Aggregation. Note that aspects of the graph already described are grayed-out to emphasize the concepts introduced by the figure. This convention will be used for the remainder of this document along with other simplifications to make the figures easier to read.

4.3 Aggregated Resources and the Aggregation Graph

A Resource Map MAY include one or more triples with the ore:aggregates predicate. Each asserts that the object of the predicate identified by URI-AR is an Aggregated Resource of the subject identified by URI-A. A URI-AR MUST NOT be the same as the URI-A of the Aggregation that is the subject of the ore:aggregates predicate.

The ore:aggregates relationship defines that the Resource denoted by the subject is a Resource of type ore:Aggregation. Therefore, the explicit inclusion in the Resource Map of a triple asserting the type is OPTIONAL.

A Resource Map MAY include one or more triples with the ore:isAggregatedBy predicate to assert that an Aggregated Resources is a constituent of other Aggregations.

The figure below shows the RDF Graph with the addition of triples with the ore:aggregates predicate. This subgraph of the RDF Graph, rooted in the Aggregation with one or more ore:aggregates relationships to Aggregated Resources, is known as the Aggregation Graph.As described earlier, all authoritative Resource Maps describing the same Aggregation MUST assert the same Aggregation Graph.

For a Resource Map http://example.org/ReM-1, the Aggregation Graph is defined by the following SPARQL query [SPARQL].

PREFIX ore: <http://www.openarchives.org/ore/terms/>
CONSTRUCT   { ?a ore:aggregates ?ar1 . }
WHERE       { <http://example.org/ReM-1> ore:describes ?a .
              ?a ore:aggregates ?ar1 . }

4.4 Relationships between the Aggregation and Similar Resources

A Resource Map MAY include one or more triples, with URI-A as the subject, which assert that the Aggregation is a Resource with content that is similar to another Resource. The predicate MAY be either rdfs:seeAlso or its sub-property ore:similarTo. The predicate actually used depends on the strength of the assertion of similarity.

The ore:similarTo relationship asserts that the Aggregation has similar intellectual content to the Resource identified by the object of the triple. An example of the use of ore:similarTo in the scholarly communication context is the relationship between an Aggregation and a Resource with non-protocol-based URI like a Digital Object Identifier [DOI] or an info URI [INFO].

An example of the use of the weaker rdfs:seeAlso in a Resource Map is the relationship between two Aggregations that have an ore:similarTo relationship to the same DOI.

The use of ore:similarTo and rdfs:seeAlso predicates in a Resource Map is shown in the figure below.

4.5 Relationships to other Resources and Types

A Resource Map MAY include additional triples that assert properties about the Resource Map, Aggregation, Aggregated Resources, or other related Resources or Literals. The RDF graph produced by the addition of these triples MUST be connected. Formally that means that all nodes in the graph MUST be reachable via a traversal that begins at the node denoting the Resource Map and follows the edges corresponding to the predicates expressed in the triples.

Some appropriate uses for additional relationships are:

• They MAY define the semantic types of the nodes in the Aggregation Graph. In this case, the subject is a node in the Aggregation Graph (the URI of either the Aggregation or an Aggregated Resource), a predicate that is rdf:type, and an object that is the URI of a Class defined by any vocabulary.
• They MAY define the relationships of the Aggregation or an Aggregated Resource to other Resources. The predicate of these relationships MAY be defined in any vocabulary. These relationships are useful for metadata properties of the Aggregation Graph and/or the Aggregation, citation linkages, mirrors, and the like.

The scope of these additional assertions corresponds to the global manner in which RDF statements are interpreted. That is, the meaning of these additional triples are not constrained or altered by their "assertion context" in a Resource Map. Each assertion is essentially independent, and therefore a triple with subject URI-AR is a statement about that Resource without reference to its existence in the respective Aggregation. Assertions about Resources contextualized by the Aggregation via the use of Proxies are described in section 5.3.1.

The figure below shows the RDF Graph with the addition of triples expressing type semantics and other relationships to the Aggregation Graph.

5. RDF Graph of a Resource Map - Advanced

This specification has thus far included the mechanisms for describing an individual Aggregation. This section describes mechanisms by which one Resource Map MAY assert relationships between Aggregated Resources and other Resource Maps or Aggregations.

5.1 Asserting that an Aggregated Resource is a constituent of another Aggregation

A Resource Map MAY include one or more triples with the ore:isAggregatedBy predicate to assert that an Aggregated Resources is a constituent of other Aggregations.

A use case is flickr, in which it is possible for a picture to be a member of multiple sets. The Resource Map describing a set might include information about other set memberships of its constituent pictures. The figure below shows three Aggregations, A-1, A-2, and A-3, corresponding to the three sets in flickr. All include some image, AR-3, as an Aggregated Resource. The Resource Map ReM-3, which describes the flickr set A-3, includes triples with the predicate ore:isAggregatedBy, asserting that AR-3 is constituent of the sets denoted by the Aggregations A-1 and A-2.

5.2 Nesting Aggregations

As stated earlier, any Resource can be an Aggregated Resource in some Aggregation. Because an Aggregation is itself a Resource, it can be an Aggregated Resource in some other Aggregation. The result is then recursive nesting of Aggregations. Note that this nesting MUST be expressed in multiple Resource Maps, since one Resource Map MUST describe only one Aggregation.

A Resource Map that asserts another Aggregation as an Aggregated Resource MAY assert an ore:isDescribedBy relationship between this Aggregated Resource and a Resource Map describing the other Aggregation. This informs clients of the Resource Map of the nesting.

Note that this use of the ore:isDescribedBy predicate has the same semantics as described earlier. The predicate asserts that the subject of the triple, which is an Aggregation, is described by the object of the triple, which is a Resource Map.

An example of a nested Aggregation is a journal consisting of multiple issues, each of which is an Aggregation of multiple articles, each of which may be an Aggregation in its own right. The figure below illustrates nested Aggregations, omitting some details of previous figures (e.g. metadata, typing). Aggregation A-1, described by ReM-1, has constituents AR-1, AR-2 and AR-3, which are themselves Aggregations. Each of these "aggregated Aggregations" is described by a corresponding Resource Map (ReM-2, ReM-3, and ReM-4) which describes the Aggregated Resources and other aspects of these Aggregations. The sub-graphs associated with these other Resource Maps are intentionally grayed out to emphasize the fact that the triples relevant to this example are exclusive to ReM-1.

5.3.Proxies for Aggregated Resources

This specification has thus far used the URI-AR of an Aggregated Resource as the subject or object of triples. As described earlier, a URI-AR is not specific to the Aggregation — an individual URI-AR MAY be asserted within multiple Aggregations and MAY be used independent of any Aggregation. Thus, the use of URI-AR as the subject or object of triples does not imply any association with one Aggregation, or even with any Aggregation at all.

In some cases it is useful to assert relationships to Aggregated Resources in a manner specific to the Aggregation context. These relationships may be among Aggregated Resources or between Aggregated Resources and Resources external to the Aggregation. A URI distinct from the URI-AR is then necessary.

This section describes the notion of a Proxy, which is a Resource that "stands for" an Aggregated Resource in a manner that is specific to one Aggregation. The URI-P of this Proxy is then available for use in triples where the intended semantics is a relationship specific to the Aggregated Resource in the context of the respective Aggregation. Note that the assertion of Proxies is OPTIONAL and unnecessary if context-specific assertions are not needed.

The URI-P of the Proxy MUST be unique to the Aggregation. A Resource Map MUST assert two triples to associate the Proxy with the Aggregation and Aggregated Resource.

• The first has the URI of the Proxy as the subject, the predicate ore:proxyFor, and the URI of the associated Aggregated Resource as the object.
• The second has the URI of the Proxy as the subject, the predicate ore:proxyIn, and the URI of the associated Aggregation as the object.

A Resource Map MUST assert only one of each of these pairs of triples for each Proxy. All authoritative Resource Maps for an Aggregation MUST assert the same Proxies.

The remainder of this section describes use cases for Proxies and how to express them in the Resource Map

5.3.1 Proxies: Relationships among Aggregated Resources

An example of the use of Proxies for relationships among Aggregated Resources is the assertion of sequencing between Aggregated Resources, expressing an ordered list where AR-1 follows AR-2 which follows AR-3. Without any sequencing information, the order of Aggregated Resources can not be inferred — they form an unordered set. It would not be legitimate for the Resource Map to express this sequencing by asserting a triple of the sort <AR-1> <hasNext> <AR-2>, since this fact is only true in the context of the specific Aggregation, and is not a "global" fact. As noted earlier, in RDF the meaning of triples are not constrained or altered by their "assertion context" in a Resource Map. Each assertion is essentially independent, and therefore a triple with subject or object URI-AR is a statement about that Aggregated Resource without reference to its existence in the respective Aggregation. Therefore, a relationship such as the previously mentioned "sequence" must be expressed in terms of Proxies that denote Aggregated Resources contextualized by a specific Aggregation

The following figure illustrates how to express this Aggregation-specific sequencing via the definition of proxies and assertion of related triples in a Resource Map. The hypothetical predicate xyz:hasNext used in the figure indicates a sequencing relationship between the two Aggregated Resources. The Resource Map ReM-1 defines two Proxies P-1 and P-2. It also asserts triples with the ore:proxyFor and ore:proxyIn predicates that associate the Proxies with the respective Aggregated Resource and with the Aggregation. These Proxies are then the subject and object of the xyz:hasNext predicate, asserting the sequencing relationship in the context of the Aggregation.

5.3.2. Proxies: Externally asserted relationships to Aggregated Resources

A Proxy can be the subject or object of triples asserted elsewhere, with semantics that the relationship asserted by the triples are specific to the Aggregated Resources contextualized by the Aggregation.

The figure below illustrates an example of this use of a Proxy. In the example, the Aggregation A-1 may be a collection of best scholarly papers found on the web about some selected topic. AR-1 is one of these selected papers. A citation to that paper, asserted by the triple <URI-2> <xyz:cites> <AR-1>, carries no semantics about the selection of the paper in the "best papers" collection, because the URI AR-1 is simply the identity of the paper. However, the triple <URI-1> <xyz:cites> <P-1>, where P-1 is asserted by the Resource Map to be the Proxy for AR-1, is semantically a citation to that paper as a constituent of the "best papers" collection.

The assertion of Proxies is OPTIONAL. This example demonstrates that it MAY make sense for an agency creating Resource Maps to assert these Proxies to provide appropriate link targets for outside clients.

5.3.3. Proxies: Lineage of an Aggregated Resource

As described earlier, the ore:isAggregatedBy predicate asserts that an Aggregated Resource in one Aggregation is also an Aggregated Resource in another Aggregation. In fact, one Aggregated Resource MAY be in multiple Aggregations, and therefore it MAY be the subject of multiple ore:isAggregatedBy triples. In applications such as scholarly communication there is a need for a stronger relationship indicating lineage, which indicates that an Aggregated Resource originated or was sourced from another Aggregation. Lineage or provenance is one basis of integrity in scholarly communication.

A Resource Map MAY assert triples with the predicate ore:lineage to express this notion. The subject of ore:lineage MUST be a Proxy specific to the Aggregation and the object MUST be a Proxy specific to another Aggregation. Both the subject and object Proxy Resource MUST be proxies for the same Aggregated Resource. In other words, the Resource Map for subject Proxy MUST contain a triple <P-1> <ore:proxyFor> <AR-1> and the Resource Map for object Proxy MUST contain a triple <P-2> <ore:proxyFor> <AR-1> where AR-1 is the same in both triples. One Proxy MUST NOT be the subject of more than one ore:lineage relationships expressed in a Resource Map.

The following figure illustrates the use of ore:lineage. Aggregation A-1 is an eScience result aggregating, with other Resources not shown, some data set, AR-1. Aggregation A-2 includes the same data set. Both Resource Maps establish proxies for that Aggregated Resource, P-1 in A-1 and P-2 in A-2, creating Aggregation-specific URIs for the data set. ReM-2 also asserts the triple <P-2> <ore-lineage> <P-1> to express the origin or provenance of the data set in Aggregation A-1.

6.Structural Constraints on a Resource Map

The following table summarizes the constraints on the structure of an RDF Graph that serves as a Resource Map by specifying the minimum and maximum expected occurrences of Triples of varying forms.

The convention used in the table is that

• ReM-1 is the URI of this Resource Map
• ReM-i is the URI of another Resource Map
• A-1 is the URI of the Aggregation described by the Resource Map ReM-1
• Agent is the URI of an Agent
• AR-j is the URI of a resource which is aggregated into Aggregation A-1
• URI-Subject is the URI of a Resource
• URI-Property is the URI of a type of Relationship
• URI-Object is the URI of a Resource
• A-k is the URI of an Aggregation other than the Aggregation described by the Resource Map ReM-1
• P-j is the URI of a Proxy for a resource AR-j aggregated into the Aggregation A-1
• P-m is the URI of a Proxy for a resource AR-m aggregated into an Aggregation other than the Aggregation described by the Resource Map ReM-1

The UML diagram below shows the relationships between the key entities in the ORE model.

7. References

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

[Compound Object]

Compound Information Object Archive Prototype Demonstration, H. Van de Sompel, 2007.

[Dereferencing]

Dereferencing HTTP URIs, R. Lewis, Draft Tag Finding 31 May 2007

[DC RDF]

Expressing Dublin Core metadata using the Resource Description Framework (RDF), Mikael Nilsson, Andy Powell, Pete Johnston, Ambjorn Naeve. DCMI Working Draft, 2006-05-30

[DC Terms]

DCMI Metadata Terms, DCMI Usage Board, 2006-12-18.

[DOI]

The DOI System, The International DOI Foundation.

[INFO]

The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces, H. Van de Sompel, et al., RFC 4552, IETF, 2006.

[Linked Data Tutorial]

How to Publish Linked Data on the Web, Chris Bizer, Richard Cyganiak, Tom Heath, 2007-07-27. Available at http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/20070727/ . Latest version available at http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ .

[OWL]

OWL Web Ontology Language Guide, Michael Smith, Chris Welty, Deborah McGuiness, Editors, W3C Recommendation 10 February 2004, Latest Version http://www.w3.org/TR/owl-guide/.

[RDF Concepts]

Resource Description Framework (RDF): Concepts and Abstract Syntax,, Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Latest version available at http://www.w3.org/TR/rdf-concepts/ .

[RDF Semantics]

RDF Semantics, Patrick Hayes and Brian McBride, Editors, W3C Recommendation 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/

[RDFS]

RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .
Latest version available at http://www.w3.org/TR/rdf-schema/ .

[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, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt .

[Lynch CTWatch]

The Shape of the Scientific Article in The Developing Cyberinfrastructure, C. Lynch, CTWatch Quarterly, August 2007.

[SCOPE]

SCOPE - A Scientific Compound Object Publishing and Editing System. K. Cheung, J. Hunger, A. Lashtabeg, J. Drennan, Proceedings of the 3rd International Digital Curation Conference, 2007.

[SPARQL]

SPARQL Query Language for RDF, E. Prud'hommeaux, A. Seaborne, Editors. W3C Proposed Recommendation, 12 November 2007.
http://www.w3.org/TR/2007/PR-rdf-sparql-query-20071112/
Latest Version available at http://www.w3.org/TR/rdf-sparql-query/

[URI]

Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, IETF RFC3986, January 2005.

[Value Chains]

An Interoperable Fabric for Scholarly Value Chains, H. Van de Sompel, C. Lagoze, J. Bekaert, X. Liu, S. Payette, S. Warner, D-Lib Magazine, 12(10), October 2006.

[Web Architecture]

Architecture of the World Wide Web, Volume One, I. Jacobs and N. Walsh, Editors, World Wide Web Consortium, 15 January 2004.