DO NOT USE, SEE CURRENT ORE SPECIFICATIONS

ORE Specification - Vocabulary

10 December 2007

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.1/vocabulary
Latest version:
http://www.openarchives.org/ore/vocabulary
Previous version:
none
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 Compound Information Objects.  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
owl http://www.w3.org/2002/07/owl# OWL vocabulary terms [OWL]
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, 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

Resource Map Document
The representation of a Resource Map, according to the implementation guidelines.
  • Name: ore:ResourceMapDocument
  • URI: http://www.openarchives.org/ore/terms/ResourceMapDocument
  • SubClass Of: rdfs:Resource

Aggregated Resource
A member of an Aggregation.
  • Name: ore:AggregatedResource
  • URI: http://www.openarchives.org/ore/terms/AggregatedResource
  • SubClass Of: rdfs:Resource

External Resource
A resource which is related to an Aggregated Resource, the Aggregation or the Resource Map, but not part of the Aggregation itself. External Resources are either the subject or object of relationships within the Resource Map
  • Name: ore:ExternalResource
  • URI: http://www.openarchives.org/ore/terms/ExternalResource
  • SubClass Of: rdfs:Resource

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

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"

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/"

4. Types

This version of 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.

Example: 
URI-R  rdf:type ore:ResourceMap
URI-A  rdf:type ore:Aggregation
URI-AR rdf:type ore:AggregatedResource

It is expected that later revisions of this document will include recommendations for the use of types outside the set of ORE entities.

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
The referenced resource is the Aggregation described by the described resource, which must be a Resource Map.
Example: 
URI-R ore:describes URI-R#aggregation

Is Described By
The inverse relationship of ore:describes, in this case the referenced resource is the Resource Map and the described resource 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 the Resource Map which describes it.
Example: 
URI-R#aggregation ore:isDescribedBy URI-R

Equivalency
The described resource is intellectually the same as the referenced resource. For example, the Aggregation may consist of various differently formatted versions of a journal article which has a DOI assigned to it. The article is not the Aggregation, but is equivalent to it in some manner. This relationship might also be used to refer to other non-Resource Map descriptions of an Aggregation or Aggregated Resource, such as another digital library's copy of the article and associated metadata.

There is debate over whether owl:sameAs is appropriate for this use. The arguments are as follows:

  • Pro: owl:sameAs asserts that two resources are the same thing. Just because we're coining a new term (an Aggregation) for the compound object, doesn't in any way change the object, we're just describing it with a different terminology. This is exactly what owl:sameAs was designed for.
  • Con: owl:sameAs allows you to replace any instance of the subject with the object in any triple asserted about the object. For example if A owl:sameAs B, and B dc:creator "Rob" then A dc:creator "Rob". However, the creator of the Aggregation is not necessarily the creator of the object being described by the aggregation. The creation time of the Aggregation is almost certainly different. So they are different resources and hence owl:sameAs isn't appropriate.

Current thought is towards defining a new relationship: ore:alsoKnownAs or ore:aka.


Example: 
URI-R#aggregation owl:sameAs info:doi/10.1045/february-2006-smith

Part/Whole
The described resource includes the referenced resource either physically or logically. For example, an Aggregated Resource which is a book, would have its chapters as parts. The referenced resources may be Aggregated or External Resources.
Example: 
URI-AR-1 dcterms:hasPart URI-AR-2

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.

An example of such a profile is available for the domain of scholarly communication, created as part of the definition process of the OAI-ORE standard. It may be used as a template for future profiles.

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
[OWL]
OWL Web Ontology Language Guide, Michael Smith, Chris Welty, Deborah McGuiness, Editors, W3C Recommendation 10 February 2004
[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
2007-12-10 sanderson public alpha 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.