 |
Open Archives Initiative Object Reuse and Exchange |
 |
|
Open Archives Initiative Object Reuse and Exchange |
|
DO NOT USE THIS SPECIFICATION, see instead the CURRENT ORE SPECIFICATIONS.
This document was part of an alpha release and has been superseded.
Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. This document describes a glossary of terms and the vocabularies needed to describe items of interest and express the relationships between them within the OAI-ORE context. This specification is one of several documents comprising the OAI-ORE specification and user guide.
1. Introduction
1.1 Notational Conventions
1.2 Namespaces Used
2. ORE Entities
3. Properties
4. Types
5. Relationships
6. Other Vocabularies
7. References
A. Acknowledgements
B. Change Log
The purpose of this document is to describe the concepts used within the OAI-ORE context and to specify the technical vocabularies needed to consistently implement these concepts in a machine-understandable fashion.
A guiding principle is to re-use existing vocabularies when possible for terms which are not specific and fundamental to the ORE model. As such, many of the items in this document have been taken from other sources. Please see the references section for full details. In particular, the Dublin Core Metadata Initiative [DCMI] and the Resource Description Framework [RDF] have provided many core definitions.
Whereever possible the architecture and terminology of the World Wide Web [Web Architecture] has been adhered to, in order to ensure that the specifications are consistent with both existing and future work in this area.
There are four main types of vocabulary required:
As there are many overlapping vocabularies already available for many of the concepts that are required or desirable for describing objects within the ORE context, only the core vocabulary needed to implement the OAI-ORE data model is described below. It focuses primarily on the Resource Map and Aggregation, as these are the core objects within the ORE context. Domain specific vocabularies should be created by their respective communities, and through use and implementation, cross-domain terms and recommendations will be encorprated into this or related best practice documents in the future based on any emerging consensus. As such, at this stage the document contains only the essential terms.
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].
This specification uses the following namespaces and prefixes to indicate those namespaces:
| Prefix | Namespace URI | Description |
|---|---|---|
dc |
http://purl.org/dc/elements/1.1/ |
Dublin Core elements [DC Elements] |
dcterms |
http://purl.org/dc/terms/ |
Dublin Core terms [DC Terms] |
dcmitype |
http://purl.org/dc/dcmitype/ |
Dublin Core types [DC Types] |
ore |
http://www.openarchives.org/ore/terms/ |
ORE vocabulary terms |
rdf |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
RDF vocabulary terms [RDF Vocabulary] |
rdfg |
http://www.w3.org/2004/03/trix/rdfg-1/ |
Named RDF Graph vocabulary [RDFG] |
rdfs |
http://www.w3.org/2001/01/rdf-schema# |
RDF Schema vocabulary [RDF Vocabulary] |
A set of related resources (Aggregated Resources), grouped together such that the set can be treated as a single resource. This is the entity described within the ORE interoperability framework by a Resource Map.
A resource which is included in an Aggregation. Please note that asserting that a resource is a member of the class of Aggregated Resources does not imply anything other than that it is aggregated by at least one Aggregation.
A description of an Aggregation according to the OAI-ORE data model. Resource Maps are serialised to a machine readable format according to the implementation guidelines as a Resource Map Document. The Resource Map MUST contain certain property information, MAY contain type information and MAY contain relationship information.
A Proxy represents an Aggregated Resource as it exists in a specific Aggregation. All assertions made about an entity are globally true, not true only within the context of the Aggregation. As such, in order to make assertions which are only true of a resource as it exists in an Aggregation, we need a Proxy object. For example, one might want to cite an article as it appears in a specific journal, or assign aggregation-specific metadata to a Resource.
Essential properties for Entities. These may be expressed as relations, but the object of the relation will typically be a literal value rather than another resource.
The agent responsible for the creation of the entity. This may be a string literal or a URI which identifies the agent. The agent may be a piece of software (for example a Resource Map might be created automatically by repository system's transformation of metadata), or the person responsible for authorship. It is RECOMMENDED that a URI be used, but it is understood that this will not always be possible.
Example:
URI-R dc:creator mailto:azaroth@liverpool.ac.uk URI-R dc:creator "Rob Sanderson"
The point of time at which the Creator created the entity. This MUST be a string literal in ISO8601 format.
Example:
URI-R dcterms:created "2007-10-11T11:30:00Z"
The point of time at which the entity was most recently modified. This MUST be a string literal in ISO8601 format.
Example:
URI-R dcterms:modified "2007-10-12T14:00:00Z"
Information about rights held in and over the resource. This is a free text property and is not expected to be understood by machines, however it is recommended that, if appropriate, it should be a creative commons licence URI. It might be used for discussing the re-usability of the Aggregated Resources or of the Resource Map as a whole.
Example:
URI-R dc:rights http://creativecommons.org/licenses/by-nc-sa/2.5/ URI-R dc:rights "This resource map is free for non-commercial use"
The ORE Vocabulary specification describes only the typing essential
to the ORE Data Model. All such typing uses the ORE Entities defined above, and the rdf:type relationship.
Future documents will include recommendations for non ORE specific types.
Example:
URI-R rdf:type ore:ResourceMap URI-A rdf:type ore:Aggregation URI-P rdf:type ore:Proxy
Aggregations, by definition, aggregate resources. This relationship between the Aggregation and its Aggregated Resources is thus more specific than a simple part/whole relationship, as expressed by dcterms:hasPart for example.
Example:
URI-A-1 ore:aggregates URI-AR-1
The inverse relationship of ore:aggregates, ore:isAggregatedBy asserts that an Aggregated Resource is aggregated by an Aggregation. The intended use for this relationship is to allow one Resource Map to assert that a resource is also aggregated by a different Resource Map in order to promote discovery.
Example:
URI-AR-1 ore:isAggregatedBy URI-A-2
Resource Maps describe Aggregations in varying levels of detail. This relationship asserts that the subject (a Resource Map) describes the object (an Aggregation). This relationship is essential as it explicitly links the resource map (a graph) to the aggregation (a collection of resources).
Example:
URI-R-1 ore:describes URI-A-1
The inverse relationship of ore:describes, in this case the object of the relationship is the Resource Map and the subject is the Aggregation which it describes. In particular, this is available for use when the Aggregation is taking the role of an Aggregated Resource, such that a harvester will know where to find a Resource Map which describes it. Also, please note that isDescribedBy can be used to point from a single Aggregation to multiple Resource Maps in different formats, each of which describes the Aggregation.
Example:
URI-A-1 ore:isDescribedBy URI-R-1
The subject of this relationship MUST be an Aggregation. This Aggregation should be considered an expression of the object of the relationship within the ORE context, as it is broadly equivalent to the resource. For example, the Aggregation may consist of the resources which, together, make up a journal article which has a DOI assigned to it. The Aggregation is not the article to which the DOI was assigned, but is a representation of it in some manner.
Semantically, this relationship is more specific than rdfs:seeAlso, but less explicit than owl:sameAs. owl:sameAs has the property that the object and subject are interchangable in other relationships, and hence not appropriate as the creation time for the aggregation and the creation time for the article to which it is analogous are not the same. On the other hand rdfs:seeAlso "specifies a resource that might provide additional information about the subject" [emphasis added] and is too weak a relationship for these purposes. rdfs:seeAlso would be appropriate between a journal article and a review of that article, as they are related, but in no way implies that they are somehow representations of the same thing.
Example:
URI-A ore:similarTo info:doi/10.1045/february-2006-smith
Proxy objects are used to represent a Resource as it is aggregated in a particular Aggregation. The ore:proxyFor relationship is used to link the proxy to the resource it is a proxy for. The subject of the relationship is a Proxy object, and the object of the relationship is the Resource.
Example:
URI-P-1 ore:proxyFor URI-AR-1
Proxy objects must also link to the Aggregation in which the resource being proxied is aggregated. The ore:proxyIn relationship is used for this purpose. The subject of the relationship is a Proxy object, and the object of the relationship is the Aggregation.
Example:
URI-P-1 ore:proxyIn URI-A-1
It may be desirable to express a provenance chain of where resources in aggregations came from, in terms of other aggregations. In order to do this, we must use Proxy objects which represent a Resource in the context of an Aggregation. ore:lineage is, thus, a relationship between two Proxy objects, both of which must have the same Resource for which they are proxies. The meaning is that the Resource for which the subject of the relationship is a Proxy was discovered in the Aggregation in which the object Proxy's resource is aggregated.
Example:
URI-P-1 ore:lineage URI-P-2
Many other vocabularies exist and contain domain useful terms. In order to comprehensively describe an Aggregated Resource, it is almost certain that using other vocabularies will be necessary. For example, this vocabulary document does not prescribe or recommend a set of Classes for semantic typing via rdf:type, other than the OAI-ORE specific classes. Instead it is recommended that profile documents be created by interested communities specifying which additional properties, relationships and classes should be used in conjunction with the above in order to properly fulfil the community's requirements.
This document is the work of the Open Archives Initiative. Funding for Open Archives Initiative Object Reuse and Exchange is provided by the Andrew W. Mellon Foundation, Microsoft, and the National Science Foundation. Additional support is provided by the Coalition for Networked Information.
This document is based on meetings of the OAI-ORE Technical Committee (ORE-TC), with participation from the OAI-ORE Liaison Group (ORE-LG). Members of the ORE-TC are: Chris Bizer (Freie Universität Berlin), Les Carr (University of Southampton), Tim DiLauro (Johns Hopkins University), Leigh Dodds (Ingenta), David Fulker (UCAR), Tony Hammond (Nature Publishing Group), Pete Johnston (Eduserv Foundation), Richard Jones (Imperial College), Peter Murray (OhioLINK), Michael Nelson (Old Dominion University), Ray Plante (NCSA and National Virtual Observatory), Rob Sanderson (University of Liverpool), Simeon Warner (Cornell University), and Jeff Young (OCLC). Members of ORE-LG are: Leonardo Candela (DRIVER), Tim Cole (DLF Aquifer and UIUC Library), Julie Allinson (JISC), Jane Hunter (DEST), Savas Parastatidis (Microsoft), Sandy Payette (Fedora Commons), Thomas Place (DARE and University of Tilburg), Andy Powell (DCMI), and Robert Tansley (Google, Inc. and DSpace)
We also acknowledge comments from the OAI-ORE Advisory Committee (ORE-AC).
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Use of this page is tracked to collect anonymous traffic data. See OAI privacy policy.