 |
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 a beta 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
1.3 Note about Examples
2. ORE Vocabulary Definition
2.1 ORE Classes
2.1.1 ore:Aggregation
2.1.2 ore:AggregatedResource
2.1.3 ore:Proxy
2.1.4 ore:ResourceMap
2.2 ORE Relationships
2.2.1 ore:aggregates
2.2.2 ore:isAggregatedBy
2.2.3 ore:describes
2.2.4 ore:isDescribedBy
2.2.5 ore:lineage
2.2.6 ore:proxyFor
2.2.7 ore:proxyIn
2.2.8 ore:similarTo
3. Recommended Vocabularies
3.1 Classes
3.2 Relationships
3.2.1 Dublin Core Elements
3.2.2 Dublin Core Terms
3.2.3 Friend of a Friend Terms
3.2.4 RDF Terms
3.2.5 RDF Schema Terms
4. 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.
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 two types of vocabulary entries described in this document:
A guiding principle is to reuse existing vocabularies when possible for terms which are not specific and fundamental to the ORE model. As such, many of the terms in this document that are required or desirable for describing objects of interest have been taken from other sources. These recommended vocabularies are described in Section 3 along with examples of how the terms can be used within the ORE context. These entries should not be considered comprehensive, 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.
For concepts not described in this document or other existing vocabularies, domain specific vocabularies should be created and maintained by their respective communities. Community best practice recommendations may be integrated into this document in the future, however at the present it contains only the vocabulary needed for a full mapping of the Atom serialisation and aspects which are considered important across all domains.
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] |
foaf |
http://xmlns.com/foaf/0.1/ |
Friend of a Friend vocabulary terms [FOAF] |
ore |
http://www.openarchives.org/ore/terms/ |
ORE vocabulary terms [this document] |
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] |
The examples below are presented in the Turtle [Turtle] format for RDF. The prefixes in the
table above are assumed, along with the fictitious prefixes
'my' (representing the prefix for the Aggregation's URIs)
and 'your' (representing external URIs). Illustrative rather than
recommended URIs are used for the example such that
my:aggregation is an aggregation, and so forth. The
example used is a fictitious collection of photographs of frogs.
http://www.openarchives.org/ore/terms/ and are used
to construct ORE Resource Maps.
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. 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. As such, this class is mostly informative and there is no need to assert that aggregated resources are instances of the ore:AggregatedResource class.
A Proxy represents an Aggregated Resource as it exists in a specific Aggregation. All assertions made about an entity are globally true, not 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, a Proxy object is required. For example, one might want to cite an article as it appears in a specific journal, or assign aggregation-specific metadata to a Resource. Aggregations should not aggregate Proxy resources, instead the resource itself should be aggregated and the lineage of the inclusion of the resource in the aggregation should be expressed with the ore:lineage relationship.
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.
rdf:type relationship.
Example:
my:resource-map rdf:type ore:ResourceMap . my:aggregation rdf:type ore:Aggregation . my:proxy-1 rdf:type ore:Proxy .
Aggregations, by definition, aggregate resources.
The ore:aggregates relationship expresses that the object
resource is a member of the set of Aggregated
Resources of the subject (the Aggregation). 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:
my:aggregation ore:aggregates my:photo-1 ,
my:description-of-photo-1,
my:photo-2 .
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:
my:photo-1 ore:isAggregatedBy my:aggregation ,
your:aggregation-of-frogs .
This relationship asserts that the subject (a Resource Map) describes the object (an Aggregation).
Example:
my:resource-map ore:describes my:aggregation .
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 itself an Aggregated Resource, so that a harvester will know where to find a Resource Map which describes it. Also, note that ore:isDescribedBy can be used to point from a single Aggregation to multiple Resource Maps in different formats, each of which describes the Aggregation.
Example:
my:aggregation ore:isDescribedBy my:resource-map ,
my:resource-map-rdf .
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, a Proxy object which represents an Aggregated 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:
my:proxy-1 ore:lineage your:proxy-1 .
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 Aggregated Resource it is a proxy for. The subject of the relationship is a Proxy object, and the object of the relationship is the Aggregated Resource.
Example:
my:proxy-1 ore:proxyFor my:photo-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:
my:proxy-1 ore:proxyIn my:aggregation .
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:
my:aggregation ore:similarTo <http://www.flickr.com/photos/carl/sets/12345/> .
Many other vocabularies exist and contain domain useful terms. Using other vocabularies is necessary to comprehensively describe a Resource Map, Aggregation or Aggregated Resource. The following vocabularies and terms are recommended in order to promote interoperability and ease of reuse.
It is important to assign a semantic class to resources described using ORE in order for applications to understand what the aggregation contains and represents. For example, an aggregation of journal articles could be typed as a journal, a journal issue, a journal volume, an overlay journal, a special issue of a journal, a reading list, a citations list, and so on.
Given the broad scope of ORE and specificity required, it is not possible to list recommended classes as they are very context dependent. However, there are some general vocabularies of classes which will be summarized as to their importance. Secondly, vocabularies typically include both classes and relationships, so the classes in the recommended vocabularies will briefly be described.
Relationships fall into two categories, those which refer to another object, and those where the object of the relation is a literal value rather than another resource. Some abstract concepts can fall under both, for example the rights statement could be inline as a string or a reference to an external resource. The discussion is ordered by vocabulary, rather than any distinction as to the subject or object of the relationship.
If recommended subjects and objects are expressed for an entry below, this should not be construed as the official domain and range of the property, just a recommendation concerning the ORE use of that property. For example, if an entity is listed under the Recommended Subjects heading, this means that it is worth considering including a triple with an instance of that class as the subject, and the relationship as the predicate. If a subject is listed in bold then it is REQUIRED for this entity to participate in the relationship in the Resource Map's graph. Other entities MAY participate in any of these relationships, if appropriate. The Atom serialisation mapping for the main classes is also given for each relationship in order to have all of the relevant information about the term in one location.
A free-text description of the resource, or other short descriptive text. It might include intended use or a summary of the resource. This could be used to provide information about the Aggregation such as why it was created and what it contains. See also dcterms:abstract for a more specific relationship for how to encode content summaries.
Example:
my:aggregation dc:description "A collection of photographs of frogs" .
The file format of the resource. It is RECOMMENDED that this be a mime type. This relationship should be used for Aggregated Resources such that resource map consuming applications know what sort of resource is being referenced, or for Resource Maps so that preferred formats can be used in preference to searching through all of the ones available (if more than one) for the best.
Example:
my:resource-map dc:format "text/atom+xml" . my:photo-1 dc:format "image/jpeg" .
The language in which the resource's text is written. It is RECOMMENDED to use an established vocabulary for the value such as ISO 639-1 [ISO 639-1]. This can be used to allow consuming applications to display the aggregated resource in the preferred language of the user, if there are multiple translations.
Example:
my:description-of-photo-1 dc:language "en" .
Information about rights held in and over the resource. This is a free
text property and is not expected to be understood by machines. It is RECOMMENDED that, if appropriate, it contain a reference to a Creative Commons [Creative Commons] licence somewhere in the text. Please see dcterms:rights for how to just reference an external resource containing rights information.
Example:
my:resource-map dc:rights """This resource map is free for non-commercial use
and attribution of its authorship must be maintained
(http://creativecommons.org/licenses/by-nc-sa/2.5/)""" .
A name given to the resource. Examples include the title of a journal, book, article, image, dataset or other resource mentioned somewhere in the resource map, typically as the Aggregation or an Aggregated Resource.
Example:
my:aggregation dc:title "Carl's Collection of Frogs" . my:photo-1 dc:title "Photo of a Green Frog" .
A summary of the resource. This could be used to describe the contents of the Aggregation, or a short description of an Aggregated Resource.
Example:
my:photo-1 dcterms:abstract "A green frog" .
The class of entity for whom the resource is intended or useful. This could be a class of person (student, educator, developer, etc) or software for machine readable resources such as datasets or metadata files. For example, an image or text would be intended for human viewing, however a description of the technical metadata about the image in XML would be intended for a software agent.
Example:
my:photo-1 dcterms:audience foaf:Person .
An agent that has contributed to the creation or subsequent modification of the resource. This MUST be a URI which identifies the agent. If no identifying URI is known for the agent (for example, when describing someone else's aggregation) then a URI MUST be created. It is RECOMMENDED that in this case a UUID URN be used following the urn:uuid scheme [RFC 4122].
Example:
my:aggregation dcterms:contributor <http://www.csc.liv.ac.uk/~azaroth/self> .
A reference to an established standard or profile to which the resource conforms. The object of the relationship must be a Resource which is a standard, rather than a literal name for a standard. A Resource Map might conform to one or more community specified application or domain profiles, which have descriptive or structural requirements. Aggregated Resources might conform to any number of standards
Example:
my:aggregation dcterms:conformsTo <http://www.openarchives.org/ore/communities/images/imageProfile.xml> .
The agent responsible for the creation of the entity. This MUST be a URI which identifies the agent. If no identifying URI is known for the agent (for example, when describing someone else's aggregation) then a URI MUST be created. It is RECOMMENDED that in this case a UUID URN be used following the urn:uuid scheme [RFC 4122].
The agent which is designated as the creator of a Resource Map MUST be a human, and it is this person who is assumed to be making the assertions expressed in the Resource Map.
Example:
my:aggregation dc:creator <http://frogs.org/people/carl> .
The point of time at which the Creator created the entity. This MUST be a string literal in ISO8601 format, for example "2007-10-11T11:30:00Z".
Example:
my:resource-map dcterms:created "2007-10-11T11:30:00Z" .
The file size of the resource. This relationship could be used to allow consuming applications to decide if they should retrieve a particular resource, and to give a hint as to how long this might take.
Example:
my:photo-1 dcterms:extent "534K" .
The point of time at which the entity was most recently modified. This MUST be a string literal in ISO8601 format, for example "2007-10-11T11:30:00Z"
Example:
my:resource-map dcterms:modified "2007-10-12T14:00:00Z" .
A related resource which is referenced, cited or otherwise pointed to by the described entity. This relationship could be used for linking between aggregations or resources representing documents with citations, or if the aggregation describes a web site, it could be used to represent the important hypertext links between pages.
Example:
my:aggregation dcterms:references your:aggregation-of-frogs .
A resource which was replaced or superseded by the described resource. The replaces relationship could be used to point to the previous version of a resource map, aggregation or aggregated resource, for example. This could be used when new resources are added to an aggregation but it is desirable to also maintain the previous version.
Example:
my:aggregation dcterms:replaces my:previous-aggregation .
Information about rights held in and over the resource, identified by a URI. It is RECOMMENDED that, if appropriate, it should be a Creative Commons [Creative Commons] licence URI.
Example:
my:aggregation dcterms:rights <http://creativecommons.org/licenses/by-nc-sa/2.5/> .
A small image used to represent a resource, also sometimes called an icon. The image can be displayed as a visual identifier or mnemonic for the resource, or the type of the resource.
Example:
my:aggregation foaf:logo <http://frogs.org/people/carl/frog-logo.jpg> . my:resource-map foaf:logo <http://www.openarchives.org/ore/logos/ore_icon.png> .
The email address, in mailto URI format [RFC 2368], of the subject. This could be used to provide the email address for the creator or maintainer of the resource map so that they could be notified of any errors or omissions.
Example:
<http://www.csc.liv.ac.uk/~azaroth/self> foaf:mbox <mailto:azaroth@liverpool.ac.uk> .
The personal name of an Agent. This should be used for associating the name of the person with the URI that is used to identify them for creators and contributors, amongst other roles.
Example:
<http://www.csc.liv.ac.uk/~azaroth/self> foaf:name "Rob Sanderson" .
The RDF class which the resource is an instance of. This could be used to assign a semantic class to the resource, such as journal, text, image, person and so on.
Example:
my:aggregation rdf:type ore:Aggregation .
Indicates the resource which defines the subject resource. This relationship can be used in ORE to specify the thesaurus or vocabularly which category terms or types are drawn from, as given using the rdf:type relationship.
Example:
dcmitype:Image rdfs:isDefinedBy dcmitype: .
Provides a human readable version of a name of the resource. This is used to give a display label for the types or categories assign to a resource using rdf:type.
Example:
ore:Aggregation rdfs:label "Aggregation" .
The rdfs:seeAlso relationship specifies a resource which might provide additional information about the subject. For example, it could be used to include a reference to an XML metadata record concerning the resource map or aggregated resource that contains information which is not practical to include in the resource map directly.
Example:
my:photo-1 rdfs:seeAlso my:description-of-photo-1 .
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.