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. A Resource can be anything at all, including an aggregation of other 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.
• Relationsips 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 type semantics 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, both humans and machines.  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. 
• 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 makes it possible to associate an identity with aggregations of Resources and  provide descriptions of their structure and semantics.  It introduces the Resource Map (ReM), which is a Resource that, in the manner of a Named Graph [Named Graph], encapsulates a set of RDF [RDF Concepts] triples.  These triples instantiate an aggregation as a Resource with a URI, express metadata about the aggregation, enumerate the constituents of the aggregation and the relationships among those constituents, and describe the relationships of the aggregation to other Resources on the Web.  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. Architecture foundations

2.1 Web Architecture

A full description of Web Architecture concepts is contained in [Web Architecture].  For the remainder of this document, the use of the following terms from the Web Architecture SHOULD be interpreted as briefly summarized below:

• Resource - an item of interest.
• URI - a uniform global identifier for a Resource [URI].  This document specializes this with the notion of a Protocol-Based URI, which is a URI that can be de-referenced via a common protocol to provide access to a Representation.  The most common example of this in the current implementation of the Web is HTTP [RFC2616]
• Representation - a data stream corresponding to the state of a Resource at the time of a dereference of its protocol-based URI.  The Web Architecture allows for multiple Representations of a Resource with access mediated by Content Negotiation.
• Link - a directed connection between two Resources.  In most common usage, a link is expressed via link or anchor tags (a hyperlink) in an HTML Representation of the originating Resource to the URI of another Resource.  An extension of this, where links are typed relationships, is explained below.

The combination of these concepts forms what is commonly referred to as the Web Graph, with nodes that are URIs (which identify Resources), from which Representations are made available, and edges that are Links. An example of a Web graph is shown below.  Note that this example shows that the Web graph is not necessarily connected - nodes O  and  P link to each other but not to other nodes in the graph.

2.2 Semantic Web and RDF

This specification also leverages Semantic Web concepts from RDF [RDF Concepts]. In RDF, Resources are described using sets of triples, each made up of three parts: a subject, a predicate and an object. The subject is a URI that identifies the described Resource; the object is either the URI of a second Resource or a literal that identifies values such as numbers and dates by means of a lexical representation; and the Predicate is a URI that identifies a type of relationship. Each triple states that a relationship of the type indicated by the Predicate (a URI) holds between the Resource identified by the subject (a URI) and the object (a URI or a Literal).

A set of RDF triples is referred to as an RDF Graph because it can be represented as a node and directed-arc diagram, in which each triple is represented as a node-arc-node link. The nodes of an RDF Graph are the subjects and objects of the constituent triples. In an RDF Graph each node is connected to at least one other node in the graph.

Note: this is a slight simplification of the RDF model because it ignores the concept of "blank nodes". The ORE model does not make use of "blank nodes" and they are not discussed further in this document

An example of an RDF Graph is shown in the figure below. As shown, the subject and Predicate of a triple are always URIs (the URI is indicated by the text in the yellow circle and shown with bracketed syntax <A> in the table) and the object may be a URI or a literal (shown as a blue rounded rectangle in the graph and in quotations in the table).

Another tool from the Semantic Web, the RDF Vocabulary Description Language [RDFS], provides the mechanisms to define vocabularies for defining the types of these relationships.  In combination with the RDF-defined relationship rdf:type this vocabulary makes it possible to express types for Resources. The figure below shows an example of this.  As shown, the objects of the triples with rdf:type Predicates are URIs, that denote classes or types.

2.3 Named Graphs

Finally, this specification builds on the notion of a Named Graph [Named Graph], which extends RDF to allow the association of a name - a URI - with a set of triples - a graph.  A number of aspects of Named Graphs are shown in the figure below.

• The Named Graph is a Resource, identified by a URI. That URI can be the subject or object of triples. These triples can, for example, express a type for the Named Graph, or associate metadata properties (e.g., dc:creator) with the Named Graph. The figure shows a graph that represents three triples in which the URI of the Named Graph NG-A occurs as subject or object 
• The Named Graph is NOT the RDF Graph itself.  Instead it is a Resource with a Representation that encodes a set of triples that form the graph.  The relationship between the Named Graph and the RDF Graph that its Representations encode is defined via a function rdfgraph. The semantics of a Named Graph are similar to RDF reification [RDF Semantics], in the manner that they allow the assertion of relationships between other Resources and the set of triples. This provides the basis for signing, authority, and trust.  This is relevant in this specification where Named Graphs are being used to provide descriptions of citable intellectual objects.

3. Aggregation

The introduction to this document introduced the concept of an aggregation in informal terms in order to outline the sort of problems the ORE Model seeks to address. The purpose of this section is to define more formally a class of Resources calledl Aggregations.

An Aggregation is a set of Resources which together form a "logical unit". Each of the individual Resources that compose an Aggregation is referred to as an Aggregated Resource. A Relationship of type ore:aggregates exists between an Aggregation and each Aggregated Resource.

In some cases, Relationships may be asserted to exist between the Aggregated Resources that constitute an Aggregation; in other cases, no Relationships are asserted to exist between the Aggregated Resources.

In some cases, Relationships may be asserted to exist between the Aggregated Resources and other Resources; in other cases, no such Relationships are asserted to exist.

Each Aggregation is described by a single Resource Map. The concept of the Resource Map is defined in the following section.

4. Resource Map (ReM)

A Resource Map (ReM) is a Resource that specifies a URI for an Aggregation and describes its composition, properties, and relationships to other Resources. It does this via a set of triples, an RDF Graph, in the same manner as a Named Graph.  This Graph has a well-defined structure.

A Relationship of type ore:describes exists between a Resource Map and an Aggregation. For each Aggregation, there exists exactly one Resource Map that describes the Aggregation; and for each Resource Map, there exists exactly one Aggregation that is described by that Resource Map. In other words, the ore:describes Relationship is an owl:InverseFunctional [OWL] Property.

4.1 Identification of a Resource Map (URI-R)

Because a Resource Map is a Resource, it is uniquely identified by a URI. This specification uses URI-R to denote URIs that identify Resource Maps.  A Resource Map MAY have multiple Representations, each of which is referred to as a Resource Map Document. These Representations MAY differ by character encoding, expressiveness, compression, and other characteristics. The syntax of these Representations is particular to each serialization format, each of which is defined in companion ORE specifications. Each serialization format MUST have well-defined rules for deterministically mapping to triples that conform to the well-defined structure of a Resource Map. Some serialization formats MAY have reduced expressiveness and therefore MAY not include all features of the data model described here.

4.2 Identification of an Aggregation (URI-A)

As noted above, this specification uses URI-A to denote URIs that identify Aggregations.  A URI-A MUST be unique relative to the one Resource Map that describes the respective Aggregation.  In this sense each Aggregation only exists due to its assertion and description in a single Resource Map. Correspondingly, the Aggregations asserted and described by two Resource Maps can not, by definition, be equivalent, since the triples asserted in the two Resource Maps MUST at a minimum be different in the URI-A that denotes the respective Aggregation.

Enforcement of this one-to-one relationship between a URI-R and its corresponding URI-A is dependent on the architecture in which the ORE Data Model is implemented. One mechanism, whereby each URA-A is contructed by appending a fragment identifier to the corresponding URI-R, is described in the OAI-ORE specification and user guide. The advantage of this syntactic linkage between the two URIs is that, when implemented within HTTP, URI-R is directly discoverable from URI-A. As defined in [URI], resolution of a fragment identifier is left to the client, after resolution of the URI - stripped of the fragment - by the server. Therefore, any request to a server to dereference URI-A results in a dereference of URI-R.

The fragment identifier mechanism is used in the remainder of the examples of this specification.

4.3 Semantics of URI-A and URI-R

Note that a URI-A denotes an Aggregation, and the corresponding URI-R denotes a Resource Map that describes that Aggregation.  Clients SHOULD recognize this distinction when linking to or expressing relationships with a URI-R or URI-A.  Notably, a relationship, such as a citation link, to the "intellectual object"  SHOULD use URI-A rather than URI-R, since the latter denotes a citation of the Resource Map, which is usually not the intended target of a citation.

5. 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 (5.1).
• It MUST express basic metadata about the Resource Map and MAY express additional metadata about the Resource Map (5.2).
• It MAY express identifiers of the Aggregation other than URI-A (5.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) (5.4). 
• It MAY express relationships among Resources identified by nodes in the Aggregation Graph (5.5).
• It MAY express any relationships between any other Resources with the restriction the complete RDF graph expressed by the triples in the Resource Map MUST be connected. (5.6).
• It MAY express the inclusion of an Aggregated Resource in another Aggregation described by another Resource Map (5.7).

A complete example of the RDF Graph expressed by a Resource Map is shown in the following figure.  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.

5.1 Relationship between a Resource Map and an Aggregation

A Resource Map MUST establish a relationship to its respective Aggregation via a triple with an ore:describes Predicate, where the subject is URI-R and the object is the corresponding URI-A.  The ore:describes relationship defines 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 ore:isDescribedBy relationship is the inverse of ore:describes. Semantically, ore:isDescribedBy  has an owl:inverseOf [OWL] relationship to ore:describes.   This means that every triple of the form <ResourceMap> <ore:describes> <Aggregation> implies the inverse triple <Aggregation> <ore:isDescribedBy> <ResourceMap>,  and vice versa. A Resource Map SHOULD NOT include these implied ore:isDescribedBy triples.

The figure below illustrates the triples asserting the relationship between a Resource Map and an Aggregation and the resulting RDF graph.  The implied types for each Resource are also shown.  The table to the right of the triples shows the URIs used to identify the Resources and relationships.

5.2 Metadata about the Resource Map

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. 

The figure below shows an RDF Graph expressed by a Resource Map that includes metadata properties about Resource Map.  Note that aspects of the graph already described are grayed-out (this convention will be used for the remainder of this section). Note also that in this example, the objects of all the metadata relationships are literals.  Alternatively, the objects may be URIs denoting other Resources.

5.3 Other identifiers of the Aggregation

In some cases there may be other Resources, with other identifiers, that are equivalent or intellectually related to the Resource identified by URI-A. One example is a splash page for a document in an institutional repository that has an identifier that is a protocol-based URI. Another example is a DOI [DOI], which is a non-protocol-based URI.

In the case where there is exact equivalence between the Resource identified by URI-A and the other Resource, the Resource Map MAY express the relationship between these two Resources via triples with the owl:sameAs [OWL] Predicate, where the subject is the URI of the Aggregation and the object is the other identifier. Note that the semantics of owl:sameAs state that the two URIs serving as subject and object of the respective triple are interchangable and any node in a triple that matches one of the "sameAs" URIs can be replaced with a node that is the corresponding URI.

If the equivalence relationship between URI-A and the other resource is weaker, the Resource Map MAY express the relationship between these two Resources via triples with the ore:analogousTo Predicate, where the subject is the URI of the Aggregation and the object is the other identifier. A typical example of the use of this Predicate is the splash page example mentioned above: that Resource is not equivalent to the Aggregation, but intellectually they "stand for the same thing".

The addition of this information about other identifiers to the RDF Graph is shown below.

5.4 Aggregated Resources and Aggregation Graph

An Aggregation consists of one or more Aggregated Resources, which are logically the constituents of the Aggregation.  To enumerate these, the Resource Map MUST express one or more triples where the subject is the URI of the respective Aggregation, the Predicate is ore:aggregates, and the object is URI of a Resource that MUST NOT be the Resource Map or the Aggregation itself.  Note that a Resource MAY be expressed as an Aggregated Resource by multiple Resource Maps. 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  that results from the triples expressed by the Resource Map that have the Predicate ore:aggregates in color.  This subgraph of the RDF Graph is known as the Aggregation Graph.  The implied types for each Aggregated Resource are also shown. The remaining nodes are in grey.

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

5.5 Relationships among Aggregated Resources

As described in the previous sections, the minimal RDF Graph expressed by a Resource Map expressees properties of the Resource Map itself and expresses the relationship of the Resource Map to the corresponding Aggregation.  In addition, via the ore:aggregates Predicate, it expresses the Aggregation Graph that defines the Resources that are constituents of the Aggregation, the Aggregated Resources.

As defined thus far, there are no relationships among the Aggregated Resources, shown above as  AR-1, AR-2, and AR-3.   A Resource Map MAY express relationships among the Resources denoted by the nodes in the Aggregation Graph, in addition to the minimal ore:aggregates relationships.  These relationships may be useful for describing the structure of the aggregation with semantics such as containment, format variation, and the like.  The Predicates of triples that assert these Relationships MAY be defined by any vocabulary.

The figure below shows an addition to the RDF Graph, defined by the Resource Map, of a triple asserting a Relationship between two Aggregated Resources.

For a Resource Map ReM-1, the RDF Graph containing the Triples which assert Internal Relationships is defined by the following SPARQL query [SPARQL]:

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

5.6 Additional Relationships in a Resource Map

The RDF Graph expressed by a Resource Map MAY contain additional triples where the subject and/or object reference Resources that are not denoted by nodes in the Aggregation Graph. It MAY also contain triples with an object that is a literal. However, the RDF graph expessed by a Resource Map 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 Resourse Map and follows the edges corresponding to the predicates expressed in the triples.

The RDF Graph expressed by a Resource Map MUST NOT describe more than one Aggregation. The methods for expressing relationships to additional Aggregations are described in the next section. It is RECOMMENDED that the extent of the RDF Graph be limited such that the graph distance from the Aggregation node to any other node is at most three. The intent of this is that the Resource Map not be used for more than the description of the Aggregation and its relationships.

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 properites of the Aggregation Graph and/or the Aggregation, citation linkages, lineage links, mirrors, and the like. 

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

5.7 Relationships to other Aggregations

Every triple of the form <Aggregation> <ore:aggregates> <Resource> implies the inverse triple <Resource> <ore:isAggregatedBy> <Aggregation>. Formally, ore:isAggregatedBy has an owl:inverseOf [OWL] relationship to ore:aggregates.

Triples of the form <Resource> <ore:isAggregatedBy> <Aggregation> MAY be included in a Resource Map to assert that an Aggregated Resource is also an Aggregated Resource of another Aggregation. The assertion in a Resource Map of ore:isAggregatedBy relationships is OPTIONAL and dependent on use case .   When appropriate for a use case (e.g. providing a scholarly citation, establishing lineage, or facilitating discovery), it is RECOMMENDED that a Resource Map include triples with ore:isAggregatedBy Predicates only when the Aggregation that is the object of the triple is described by another Resource Map.  Inclusion in a Resource Map of triples with ore:isAggregatedBy when the subject and object are members of the same Aggregation Graph is OPTIONAL, since these are implied by ore:aggregates relationships that are already asserted in that Resource Map.

Because the assertion of ore:isAggregatedBy is OPTIONAL, a  client MUST NOT assume that a triple with an ore:aggregates Predicate has a corresponding inverse triple with an ore:isAggregatedBy Predicate in the same or another Resource Map .

5.7.1 Aggregated Resources and external Aggregations

A use case demonstrating the use of ore:isAggregatedBy to make assertions about the relationship between Aggregated Resources and other Aggregations is illustrated in the figure below.  The Aggregation (A-3), described by the Resource Map ReM-3, is a journal, where the Aggregated Resources, AR-3 and AR-4, are selected scholarly papers. As shown, AR-3 is included in two other Aggregations, A-1 and A-2, which are themselves journals.  The authority managing AR-3 would like to make the inclusion in the other journals visible to clients accessing the journal.  Therefore, the Resource Map describing A-3 includes triples with the Predicate ore:isAggregatedBy, asserting such relationships between AR-3 and A-1 and between AR-3 and A-2.

5.7.2 Relationships among nested Aggregations

Another use case of the ore:isAggregatedBy relationship is nested Aggregations, where the Aggregated Resources of one Aggregation are themselves Aggregations described by other Resources Maps.  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 authority authoring and managing a nested Aggregation MAY choose to inform consuming clients of the "part/whole" nature of such nested Aggregations by including triples with the ore:isAggregatedBy Predicate in the Resource Maps that describe the nested Aggregations.  In this manner a client accessing one of the issues has direct access back to the aggregating journal. The figure below illustrates this use of the ore:isAggregated relationship for nested Aggregations.  This is the same "journal/issue" example shown above, but simplified to show only one "issue" AR-1, aggregated in the "journal" A-1.  As shown, ReM-2 expresses a ore:isAggregated relationship for its respective nested Aggregation, AR-1 thereby providing information about the "containment" of AR-1, the "issue", in A-1, the "journal".

5.8 Structural Constraints on Resource Map

The following table summarises 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 the Resource Map
• A-1 is the URI of the Aggregation described by the Resource Map
• AR-i is the URI of an Aggregated Resource which is aggregated into that Aggregation
• 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

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

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