0. Note to Readers

This specification is one of several documents comprising the ORE specification and user guide. It describes the details of the ORE Model and may not be the appropriate for readers who are interested in a high-level overview, or who are mainly interested in implementing applications that make use of the model. The ORE User Guide - Resource Map Overview is a more appropriate starting point for those readers.

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, such as flickr, YouTube, and myspace.  Information in flickr, for example, consists of an entry page, a single Resource, that links to comments or annotations (each existing as a separate Resource), and  an image in  multiple sizes and resolutions, each also existing as a separate Resource. 
• 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 citation, 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, and tools could be created to make them visible in user interfaces.  This could be useful for a number of applications and contexts.  For example:

• 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 [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 specification describes the ORE Model that includes the notion of a Resource Map (ReM), a Resource that asserts an identity for an aggregation of Resources. It also asserts the constituents, structure, metadata, and external relationships to other Web Resources of that aggregation by encapsulating a set of RDF [RDF Concepts] triples, in the manner of a Named Graph [Named Graph]. 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.
• Definitions of entities used 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].
• Named Graphs [Named Graph]

Readers unfamiliar with these technologies are encouraged to refer to their reference documents. 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 (ADM) includes the entities that are described in the remainder of this section.

3.1 Aggregation

An Aggregation is a Resource with information content that is a set of Resources.

Each Aggregation is identified by a single URI. This specification uses URI-A to denote URIs that identify Aggregations.

Because URI-A identfies the Aggregation, it SHOULD be used as the target of links refering to the set of Resources as a logical unit. Examples of such links are citation, review, annotation, and the like.

It SHOULD be possible to unamibiguously infer from URI-A the URI of at least one of the Resource Map(s) that describe the Aggregation. To enable this inference it is RECOMMENDED that a URI-A is a protocol-based URI, and that the mechanism for dereferencing the URI-A returns information from which a client can access URI-R. Details about this are described in ORE implementation documents.

Furthermore, because a URI-A identifies the Aggregation, it SHOULD NOT be a URI used for another purpose, such as a URI of a specific manifestation of some content - for example, the PDF of some scholarly paper. It is important not to confuse the Aggregation with its possible representations provided using the HTTP protocol. A server may provide a human-readable "splash page" as a representation of an Aggregation when URI-A is dereferenced, but it remains the case that the resource
identified by URI-A is the Aggregation.

3.2 Aggregated Resource

An Aggregated Resource is a Resource that is a constituent of an Aggregation. Any Resource MAY be defined as an Aggregated Resource of one or more Aggregations, and such designation does not alter the nature of the Resource itself. The manner in which a Resource is defined as an Aggregated Resource in an Aggregation is described in a later section.

Each Aggregated Resource is identified by a single URI. This specification uses URI-AR to denote URIs that identify Aggregated Resources. It is recommended that URI-AR is a protocol-based URI.

3.3 Resource Map (ReM)

A Resource Map (ReM) is a Resource with information content that asserts that another Resource is an Aggregation and describes that Aggregation. The association between a Resource Map and an Aggregation is described in a later section. This description MUST include an enumeration of the Aggregated Resources. It MAY include addtional prosperities about the Aggregation and Aggregated Resources, such as relationships among the Aggregated Resources, relationships from the Aggregated Resources to other Resources, and other properties.

Each Resource Map MUST be identified by a single protocol-based URI. This specification uses URI-R to denote URIs that identify Resource Maps.

The relationship between Resource Maps and Aggregations is one-to-may. Each Resource Map MUST identify one Aggregation. Each Aggregation MUST be identified by one Resource Map, but MAY be identified by multiple Resource Maps.

A Resource Map identified by URI-R MUST NOT assert an Aggregation where URI-A = URI-R.

3.4 Resource Map Document

A dereference of a URI-R, which identifies a Resource Map, MUST return a Representation that is a Resource Map Document. This Representation is a serialization from which the information content of the corresponding Resource Map can be extracted as a set of triples, an RDF Graph.  The RDF Graph asserted by a Resource Map MUST conform to a well-defined structure. The syntax of a Resource Map Document is particular to a serialization format. Serialization formats are defined in companion ORE specifications.

3.5 Proxy

A Proxy is a Resource defined by one Resource Map that maps to a single Aggregated Resource defined by that same Resource Map. In this manner the URI of the Proxy can then be the subject or object of triples that assert relationships specific to the Aggregated Resource in the context of the respective Aggregation. The use of Proxies is described in a later section.

Each Proxy MUST be identified by a single URI that MUST be unique to the Aggregation described by Resource Map in which the Proxy is defined. This specification uses URI-P to denote URIs that identify Proxies.

3.6 Proxy Document

A dereference of a URI-P, which identifies a Proxy, MAY return a single Representation that is a Proxy Document. This is an implementation-specific serialization from which the triples that associate the Proxy with the respective Aggregated Resource and Aggregation may be derived.

4. Basic RDF Graph of a Resource Map

A Resource Map is a specialization of a Named Graph.  Like any Named Graph it is a Resource - a first-class object in the Web Architecture - that expresses an RDF Graph via the triples it encodes.  In a general Named Graph, the structure and composition of  the RDF Graph expressed by the triples  are not defined, and there are no restrictions on the Resources identified by nodes in the graph.

The RDF Graph expressed 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 Aggregation (4.1).
• It MUST express basic metadata about the Resource Map and MAY express additional metadata about the Resource Map (4.2).
• It MAY express relationships between the Aggregation and Similar Resources (4.3).
• 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.4). 

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

Later sections describe how to extend this RDF Graph to assert relationships between Aggregations and establish Aggregation-specfic 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 triples defined 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.

A Resource Map MAY assert one or more triples with the ore:isDescribedBy predicate, which is the inverse of ore:describes. Note that because of the nature of owl:inverseOf [OWL], the triple <URI-R> <ore:describes> <URI-A>, which MUST be asserted in the Resource Map, implies <URI-A> <ore:isDescribedBy> <URI-R>.Therefore, the explicit assertion in a Resource Map of this inverse triple is OPTIONAL, but its implied existance makes it possible for clients to access to a Resource Map corresponding to an Aggregation. Implementation documents described protocol-specific mechanisms for deriving this inverse relation upon access to URI-A.

A Resource Map MAY assert one or more triples with the ore:isDescribedBy predicate where the URI-R defined as the object is different from the Resource Map asserting thte triple. This makes it possible for a Resource Map to provide clients with access points to other serializations, in other formats, of a Resource Map.

The figure below illustrates the RDF Graph showing 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. Additional details on this figure are as follows:

• As shown in this figure, an individual Aggregation can be the object of numerous ore:describes relationships, each asserted by a different Resource Map, with those Resource Maps possibly produced by different agents or authorities. In the model, no one of these has precedence above the others. The graying out of two of the triples with the ore:describes predicate in the figure, and in the triples table, is done only to increase readability. The remainder of this section will show only one <URI-R> <ore:describes> <URI-A> triple.
• The syntax of the URIs in the triples table are illustrative only and do not denote any meaning from the syntax. A companion document describes implementation details on suggested syntax for URIs used in ORE.
• An assertion in a Resource Map does not imply any authority or implication that the Resource Map is the definitive description of the Resource identified by URI-A. Other trust mechanisms or heuristics should be used by clients as they process these assertions. The Resource Map Discovery Document specifies a number of mechanisms for validating these assertions against protocol or implementation specific information associated with access to the respective URI-A.

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:

• Some identity of the authoring authority (human, organization, or agent) of the Resource Map, using the dc:creator term.  This SHOULD be used by consuming clients as one means of establishing trustworthiness of the information in the Resource Map.  The exact mechanisms for author identification and digital signing of that identification are out of scope of this specification.
• The last modification date-timestamp of the Resource Map, using the dcterms:modified term.  This date-timestamp MUST accurately reflect when the Resource Map was last changed 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. 
• The initial creation datetimestamp of the Resource Map, using the dcterms:created term. 

A Resource Map MAY assert metadata properities about the Aggregation. These metadata properties MAY be defined by a variety of vocabularies.

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. Note also that in this example, the objects of all the metadata relationships are literals.  Alternatively, the objects may be URIs denoting other Resources.

4.3 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 ore:similarTo or rdfs:seeAlso, depending on the strength of the assertion of similarity. Formally, ore:similarTo is defined as a subproperty of rdfs:seeAlso.

The ore:similarTo relationship asserts that the Aggregation has similar intellectual content to the Resource identified by the object of the triple. This form of similarity resembles the notion of "bibliographic similarity" among works, expressions, manifestations, and items in the Functional Requirements for Bibliographic Records [FRBR]. An example of of the use of ore:similarTo in the scholarly communication context is to define a relationship between an aggregation and a Resource with non-protocol-based URI like a Digital Object Identifier [DOI] or an INFO URI [INFO].

The weaker rdfs:seeAlso relationship MAY also be included in the Resource Map. One example of the use of rdfs:seeAlso in a Resource Map is to express a relationship between an Aggregation that is a journal article and a Resource that is a review of that article.

The use of ore:similarTo in the RDF Graph is shown in the figure below.

4.4 Aggregated Resources and Aggregation Graph

A Resource Map MUST include one or more triples with the ore:aggregates predicate to assert that the Resource identified by the URI-A that is the subject has the constituent Aggregated Resource identified by the URI-AR that is the object. A URI-AR MUST NOT be the same as the URI-A of the Aggregation or the URI-R that describes that Aggregation.

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.

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. 

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.5 Relationships to other Resources and Types

A Resource 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 global scope of these additional assertions corresponds to the usual 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 Aggregated Resource without reference to its existence in the respective Aggregation. Assertions about Resources local to the Aggregation are described in a later section.

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

5.Extending a Resource Map to express Relationships between Aggregations

This specification has thus far described 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.1Asserting 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 a scholalry overlay journal (a virtual journal that includes papers by reference in contrast to creating local copiees of them). One paper might be included in multiple overlay journals. The editor of one journal would like to make clients aware of the presence of the paper in those other journals.

The figure below shows three Aggregations, A-1, A-2, and A-3, corresponding to the three journals. All include AR-3 as an Aggregated Resource. The Resource Map ReM-3, which describeds A-3, includes triples with the predicate ore:isAggregatedBy, asserting that AR-3 is an Aggregated Resource of A-1 and A-2.

5.2 Nested Aggregations

As stated earlier, a Resource Map can assert any Resource as an Aggregated Resource. And, because an Aggregation is a Resource, a Resource Map can assert that a Resource, which is described as an Aggregation by another Resource Map, is itself an Aggregated Resource. The result is then recursive nesting of Aggregations. Note that this nesting MUST involve information from 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 the 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 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.

6. Aggregation-Specific Identities 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. This section describes the notion of a Proxy, which is a Resource that "stands for" an Aggregated Resouce in a manner that is specific to one Aggregation.

The URI-P of the Proxy MUST be unique to the Aggregation. This URI MAY then be used by the ReM as the subject and object of triples that express relationships specific to the Aggregation. A Resource Map MUST assert two triples to associate the Proxy with the Aggregation and Aggregated Resource. The first has the Proxy as the subject, the predicate ore:proxyFor, and the associated Aggregated Resource as the Object. The second has the Proxy as the subject, the predicate ore:proxyIn, and the associated Aggregation as the Object. A Resource Map MUST assert only one of each of these triples for each Proxy.

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

6.1 Using Proxies for Relationships among Aggregated Resources

In some cases the relationships among Aggregated Resources that are asserted within a Resource Map have meaning only within the context of the Aggregation itself. An example is the assertion of Aggregation-specific 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.

The following figure illustrates how to express this Aggregation-specific sequencing through the use of proxies and their assertion in a Resource Map. As illustrated, the hypothetical predicate xyz:hasNext indicates a sequencing relationship between the two Aggregated Resources. The assertion of the Proxies P-1 and P-2, which are associated with the respective Aggregated Resource via the ore:proxyFor predicate and with the Aggregation via the ore:proxyIn predicate, makes it possible to assert this relationship in the context of the Aggregation.

6.2 Using Proxies as the Target of other Relationships

As described above, the assertion of a Proxy within a Resource Map establishes an Aggregation-specific URI-P for one of the Aggregated Resources. Triples asserted external to the Aggregation MAY establish links to this Proxy, with semantics that the asserted Relationship is specific to the Aggregated Resource in the context of the Aggregation.

The figure below illustrates an example of this use of a Proxy. In the example, the Aggregation A-1 may be an overlay journal, which composes virtual issues by asserting Aggregations consisting of selected papers distributed over the Web. AR-1 is one of these selected papers. Note however that the URI AR-1 is simply the identity of the paper, which may be located on the authors own web pages or in some institutional repository. Thus, the triple <URI-2> <xyz:cites> <AR-1> implies no semantics about the selection of the paper for inclusion in the overlay journal. On the other hand, the triple <URI-1> <xyz:cites> <P-1>, where P-1 is asserted by the Resource Map to be the Proxy for AR-1, does imply these semantics.

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.

6.3 Expressing the Lineage of an Aggregated Resource

As described earlier, the ore:isAggregatedBy predicate asserts that an Aggregated Resource in one Resource Map is also an Aggregated Resource in another Resource Map. Also, as stated one Aggregated Resource 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 a 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. One Proxy MUST NOT be the subject of more than one ore:lineage relationships.

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.

7.Structural Constraints on 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
• AR-j is the URI of a resource which is aggregated into that Aggregation A-1
• URI-S is the URI of a Resource
• URI-P is the URI of a type of Relationship
• URI-O 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

8. References

[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 Terms]

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

[DOI]

The DOI System, The International DOI Foundation.

[FRBR]

Functional Requirements for Bibliographic Records, International Federation of Library Associations and Institutions, 1998.

[INFO]

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

[Linked]

How to Publish Linked Data on the Web, C. Bizer, R. Cyganiak, T. Heath, version: 2007-07-27.

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

[Named Graph]

Named graphs, provenance and trust, J. Carroll, C. Bizer, P. Hayes, P. Stickler, Proceedings of the 14th international conference on World Wide Web, 2005.

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