DO NOT USE, SEE CURRENT ORE SPECIFICATIONS

ORE Specification - Vocabulary

29 February 2008

DO NOT USE THIS SPECIFICATION, see instead the CURRENT ORE SPECIFICATIONS.

This document was part of an alpha release and has been superseded.

This version:
http://www.openarchives.org/ore/0.2/vocabulary
Latest version:
http://www.openarchives.org/ore/vocabulary
Previous version:
http://www.openarchives.org/ore/0.1/vocabulary
Editors (OAI Executive)
Carl Lagoze, Cornell University Information Science
Herbert Van de Sompel, Los Alamos National Laboratory
Editors (ORE Technical Committee)
Pete Johnston, Eduserv Foundation
Michael Nelson, Old Dominion University
Robert Sanderson, University of Liverpool
Simeon Warner, Cornell University Information Science

Abstract

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.

Table of Contents

1. Introduction
     1.1 Notational Conventions
     1.2 Namespaces Used
2. ORE Entities
3. Properties
4. Types
5. Relationships
6. Other Vocabularies
7. References

Appendices

A. Acknowledgements
B. Change Log

1. Introduction

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:

Entities
The core objects of interest within the OAI-ORE context
Properties
Information describing the Entities
Types
The semantic or physical type of the Entities
Relationships
Relationships that exist between Entities

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.

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

1.1 Namespaces Used

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]

2. ORE Entities

Aggregation
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.
  • Name: ore:Aggregation
  • SubClass Of: dcmitype:Collection
  • Type URI: http://www.openarchives.org/ore/terms/Aggregation

Resource Map
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 MAY contain type information and MAY contain relationship information.
  • Name: ore:ResourceMap
  • URI: http://www.openarchives.org/ore/terms/ResourceMap
  • SubClass Of: rdfg:Graph

3. Properties

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.

Creator
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.
  • Name: dc:creator
  • URI: http://purl.org/dc/elements/1.1/creator

  • Resource Maps MUST have a creator. In terms of the graph based model, the creator is the agent which asserts the statements made in the Resource Map.
Example: 
URI-R dc:creator mailto:azaroth@liverpool.ac.uk
URI-R dc:creator "Rob Sanderson"

Created Time
The point of time at which the Creator created the entity. This MUST be a string literal in ISO8601 format.
  • Name: dcterms:created
  • URI: http://purl.org/dc/terms/created

  • Resource Maps SHOULD have a created time.
Example: 
URI-R dcterms:created "2007-10-11T11:30:00Z"

Last Modified Time
The point of time at which the entity was most recently modified. This MUST be a string literal in ISO8601 format.
  • Name: dcterms:modified
  • URI: http://purl.org/dc/terms/modified

  • Resource Maps MUST have a last modified time.
Example: 
URI-R dcterms:modified "2007-10-12T14:00:00Z"

Rights
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.
  • Name: dc:rights
  • URI: http://purl.org/dc/elements/1.1/rights

  • Resource Maps MAY have a rights statement.
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"

4. Types

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

5. Relationships

Aggregates
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-R#aggregation ore:aggregates URI-AR-1

Is Aggregated By
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 and provenance. Example: 
URI-AR-1 ore:isAggregatedBy  URI-R-2#aggregation

Describes
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 ore:describes URI-R#aggregation

Analogous To

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 proxy for it in some manner.

Semantically, this relationship falls between owl:sameAs and rdfs:seeAlso. 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.


Example: 
URI-R#aggregation ore:analogousTo info:doi/10.1045/february-2006-smith

Type
The nature or semantic class of the object. For example that the object is a journal article, or a piece of software. The object must be a Class, which will be domain dependent.
Example: 
URI-R rdf:type ore:ResourceMap

6. Other Vocabularies

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.

7. References

[DCMI]
Dublin Core Metadata Initiative
[DC Elements]
Dublin Core Metadata Elements, DCMI Recommendation, 18 December 2006
[DC Terms]
DCMI Metadata Terms, DCMI Usage Board, 18 December 2006
[DC Types]
DCMI Types, DCMI Usage Board, 18 December 2006
[RDF]
RDF Primer, F. Manola, E. Miller, Editors. W3C Recommendation, 10 February 2004
[RDFG]
Named Graphs, Jeremey Carroll, 29 November 2004
[RDF Vocabulary]
RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004
[RFC 2119]
IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997
[Web Architecture]
Architecture of the World Wide Web, Volume One, I. Jacobs and N. Walsh, Editors, World Wide Web Consortium, 15 January 2004.

A. Acknowledgements

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

B. Change Log

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

Creative Commons License
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.