DO NOT USE, SEE CURRENT ORE SPECIFICATIONS

ORE Specification - Vocabulary

2 June 2008

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

This document was part of a beta release and has been superseded.

This version:
http://www.openarchives.org/ore/0.9/vocabulary
Latest version:
http://www.openarchives.org/ore/vocabulary
Previous version:
http://www.openarchives.org/ore/0.3/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
     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

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.

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:

Classes
The core objects or entities of interest within the OAI-ORE context
Relationships
Relationships that exist between entities or from an entity to a literal value

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.

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

1.3 Note about Examples

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.

2. ORE Vocabulary Definition

The following section defines and describes the ORE specific terms such as Aggregation, Proxy, isDescribedBy and lineage. These terms are within the ORE namespace http://www.openarchives.org/ore/terms/ and are used to construct ORE Resource Maps.

2.1 ORE Classes

2.1.1 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
  • URI: http://www.openarchives.org/ore/terms/Aggregation
2.1.2 Aggregated Resource

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.

  • Name: ore:AggregatedResource
  • SubClass Of: rdfs:Resource
  • URI: http://www.openarchives.org/ore/terms/AggregatedResource
2.1.3 Proxy

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.

  • Name: ore:Proxy
  • URI: http://www.openarchives.org/ore/terms/Proxy
2.1.4 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.

  • Name: ore:ResourceMap
  • URI: http://www.openarchives.org/ore/terms/ResourceMap
  • SubClass Of: rdfg:Graph
Classes should be given in RDF with the rdf:type relationship.

Example:

my:resource-map rdf:type ore:ResourceMap .
my:aggregation rdf:type ore:Aggregation .
my:proxy-1 rdf:type ore:Proxy .

2.2 ORE Relationships

These relationships, or predicates, are defined in order to describe the relationships between entities in the ORE model.
2.2.1 Aggregates

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.

  • Name: ore:aggregates
  • URI: http://www.openarchives.org/ore/terms/aggregates
  • SubProperty Of: dcterms:hasPart
  • Domain: Aggregation
  • Range: AggregatedResource

Example:

my:aggregation ore:aggregates my:photo-1 ,
                              my:description-of-photo-1,
                              my:photo-2 .

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

  • Name: ore:isAggregatedBy
  • URI: http://www.openarchives.org/ore/terms/isAggregatedBy
  • SubProperty Of: dcterms:isPartOf
  • Inverse Of: ore:aggregates
  • Domain: AggregatedResource
  • Range: Aggregation

Example:

my:photo-1 ore:isAggregatedBy my:aggregation ,
                              your:aggregation-of-frogs .

2.2.3 Describes

This relationship asserts that the subject (a Resource Map) describes the object (an Aggregation).

  • Name: ore:describes
  • URI: http://www.openarchives.org/ore/terms/describes
  • Domain: Resource Map
  • Range: Aggregation

Example:

my:resource-map ore:describes my:aggregation .

2.2.4 Is Described By

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.

  • Name: ore:isDescribedBy
  • URI: http://www.openarchives.org/ore/terms/isDescribedBy
  • Inverse Of: ore:describes
  • Domain: Aggregation
  • Range: Resource Map

Example:

my:aggregation ore:isDescribedBy my:resource-map ,
                                 my:resource-map-rdf .

2.2.5 Lineage

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.

  • Name: ore:lineage
  • URI: http://www.openarchives.org/ore/terms/lineage
  • Domain: Proxy
  • Range: Proxy

Example:

my:proxy-1 ore:lineage your:proxy-1 .

2.2.6 Proxy For

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.

  • Name: ore:proxyFor
  • URI: http://www.openarchives.org/ore/terms/proxyFor
  • Domain: Proxy
  • Range: AggregatedResource

Example:

my:proxy-1 ore:proxyFor my:photo-1 .

2.2.7 Proxy In

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.

  • Name: ore:proxyIn
  • URI: http://www.openarchives.org/ore/terms/proxyIn
  • Domain: Proxy
  • Range: Aggregation

Example:

my:proxy-1 ore:proxyIn my:aggregation .

2.2.8 Similar 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 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.

  • Name: ore:similarTo
  • URI: http://www.openarchives.org/ore/terms/similarTo
  • SubProperty Of: rdfs:seeAlso
  • Domain: Aggregation
  • Range: Resource

Example:

my:aggregation ore:similarTo <http://www.flickr.com/photos/carl/sets/12345/> .

3. Recommended Vocabularies

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.

3.1 Classes

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.

Sample Vocabularies

DCMI Types Vocabulary
A high level vocabularly, useful for assigning resources into broad categories. Examples include Collection, Dataset, Image, Text
http://dublincore.org/documents/dcmi-type-vocabulary/

Dublin Core Terms
The dublin core terms vocabulary also defines some interesting and important classes, primarily to ensure the domain and range of the relationships is consistent. Example classes include Agent, FileFormat, Location, Standard.
http://dublincore.org/documents/dcmi-terms/

FOAF
FOAF defines classes useful for resources associated with people, such as Person, Organisation, and Project.
http://xmlns.com/foaf/spec/

3.2 Relationships

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.

3.2.1 Dublin Core Elements

Description

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.

  • Name: dc:description
  • URI: http://purl.org/dc/elements/1.1/description
  • Recommended Subjects: ore:Aggregation
  • Recommended Objects: String Literal
  • Atom Mapping:
    • Aggregation: /feed/subtitle
      (Note that the Atom definition of subtitle allows for a short description, not just the bibliographic concept of a subtitle)

Example:

my:aggregation dc:description "A collection of photographs of frogs" .

Format

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

Language

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.

  • Name: dc:language
  • URI: http://purl.org/dc/elements/1.1/language
  • Recommended Subjects: ore:AggregatedResource
  • Recommended Objects: String Literal
  • Atom Mapping:

Example:

my:description-of-photo-1 dc:language "en" .

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

  • Name: dc:rights
  • URI: http://purl.org/dc/elements/1.1/rights
  • Recommended Subjects: ore:ResourceMap
  • Recommended Objects: String Literal
  • Atom Mapping:

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

Title

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.

  • Name: dc:title
  • URI: http://purl.org/dc/elements/1.1/title
  • Recommended Subjects: ore:Aggregation, ore:AggregatedResource
  • Recommended Objects: String Literal
  • Atom Mapping:

Example:

my:aggregation dc:title "Carl's Collection of Frogs" .
my:photo-1 dc:title "Photo of a Green Frog" .

3.2.2 Dublin Core Terms

Abstract

A summary of the resource. This could be used to describe the contents of the Aggregation, or a short description of an Aggregated Resource.

  • Name: dcterms:abstract
  • URI: http://purl.org/dc/terms/abstract
  • Recommended Subjects: ore:AggregatedResource
  • Recommended Objects: String Literal
  • Atom Mapping:

Example:

my:photo-1 dcterms:abstract "A green frog" .

Audience

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.

  • Name: dcterms:audience
  • URI: http://purl.org/dc/terms/audience
  • Recommended Subjects: ore:AggregatedResource
  • Recommended Objects: dcterms:AgentClass

Example:

my:photo-1 dcterms:audience foaf:Person .

Contributor

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

  • Name: dcterms:contributor
  • URI: http://purl.org/dc/terms/contributor
  • Recommended Subjects: ore:Aggregation, ore:AggregatedResource
  • Recommended Objects: dcterms:Agent
  • Atom Mapping:

Example:

my:aggregation dcterms:contributor <http://www.csc.liv.ac.uk/~azaroth/self> .

Conforms To

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

  • Name: dcterms:conformsTo
  • URI: http://purl.org/dc/terms/conformsTo
  • Recommended Subjects: ore:ResourceMap, ore:Aggregation, ore:AggregatedResource
  • Recommended Objects: dcterms:Standard

Example:

my:aggregation dcterms:conformsTo <http://www.openarchives.org/ore/communities/images/imageProfile.xml> .

Creator

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.

  • Name: dcterms:creator
  • URI: http://purl.org/dc/terms/creator
  • Recommended Subjects: ore:ResourceMap, ore:Aggregation, ore:AggregatedResource
  • Recommended Objects: dcterms:Agent, foaf:Person
  • Atom Mapping:

Example:

my:aggregation dc:creator <http://frogs.org/people/carl> .

Created Time

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

  • Name: dcterms:created
  • URI: http://purl.org/dc/terms/created
  • Recommended Subjects: ore:ResourceMap, ore:Aggregation, ore:Proxy
  • Recommended Objects: Datetime Literal

Example:

my:resource-map dcterms:created "2007-10-11T11:30:00Z" .

Extent

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

Last Modified Time

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"

  • Name: dcterms:modified
  • URI: http://purl.org/dc/terms/modified
  • Recommended Subjects: ore:ResourceMap, ore:Aggregation
  • Recommended Objects: Datetime Literal
  • Atom Mapping:

Example:

my:resource-map dcterms:modified "2007-10-12T14:00:00Z" .

References

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.

  • Name: dcterms:references
  • URI: http://purl.org/dc/terms/references
  • Recommended Subjects: ore:Aggregation, ore:AggregatedResource
  • Recommended Objects: Resource

Example:

my:aggregation dcterms:references your:aggregation-of-frogs .

Replaces

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.

  • Name: dcterms:replaces
  • URI: http://purl.org/dc/terms/replaces
  • Recommended Subjects: ore:ResourceMap, ore:Aggregation, ore:AggregatedResource
  • Recommended Objects: ore:ResourceMap, ore:Aggregation, rdf:Resource

Example:

my:aggregation dcterms:replaces my:previous-aggregation .

Rights

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.

  • Name: dcterms:rights
  • URI: http://purl.org/dc/terms/rights
  • Recommended Subjects: ore:ResourceMap, ore:Aggregation
  • Recommended Objects: dcterms:RightsStatement
  • Atom Mapping:

Example:

my:aggregation dcterms:rights <http://creativecommons.org/licenses/by-nc-sa/2.5/> .

3.2.3 Friend of a Friend Terms

Logo

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.

  • Name: foaf:logo
  • URI: http://xmlns.com/foaf/0.1/logo
  • Recommended Subjects: ore:Aggregation
  • Recommended Objects: Image
  • Atom Mapping:

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

Mbox (Email) Address

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

Name

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

3.2.4 RDF Terms

Type

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 .

3.2.5 RDF Schema Terms

Is Defined By

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.

  • Name: rdfs:isDefinedBy
  • URI: http://www.w3.org/2000/01/rdf-schema#isDefinedBy
  • Recommended Subjects: Class
  • Recommended Objects: Resource
  • Atom Mapping:

Example:

dcmitype:Image rdfs:isDefinedBy dcmitype: .

Label

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.

  • Name: rdfs:label
  • URI: http://www.w3.org/2000/01/rdf-schema#label
  • Recommended Subjects: Class
  • Recommended Objects: String Literal
  • Atom Mapping:

Example:

ore:Aggregation rdfs:label "Aggregation" .

See Also

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.

  • Name: rdfs:seeAlso
  • URI: http://www.w3.org/2000/01/rdf-schema#seeAlso
  • Recommended Subjects: ore:ResourceMap, ore:Aggregation, ore:AggregatedResource
  • Recommended Objects: Resource

Example:

my:photo-1 rdfs:seeAlso my:description-of-photo-1 .

4. References

[Creative Commons]
Creative Commons, Creative Commons, May 18 2008. Website http://creativecommons.org/
[DCMI]
Dublin Core Metadata Initiative. Website http://dublincore.org/
[DC Elements]
Dublin Core Metadata Elements, DCMI Recommendation, 18 December 2006. Available at http://dublincore.org/documents/dces/
[DC Terms]
DCMI Metadata Terms, DCMI Usage Board, 18 December 2006. Available at http://dublincore.org/documents/dcmi-terms/
[DC Types]
DCMI Types, DCMI Usage Board, 18 December 2006. Available at http://dublincore.org/documents/dcmi-terms/#H5
[FOAF]
FOAF Vocabulary Specification 0.91, D. Brickley, L. Miller. 2 November 2007. Available at http://xmlns.com/foaf/spec/
[ISO 639]
Codes for the Representation of Names of Languages, Library of Congress, November 26, 2007. Available at http://www.loc.gov/standards/iso639-2/php/code_list.php
[RDF]
RDF Primer, F. Manola, E. Miller, Editors. W3C Recommendation, 10 February 2004. Available at http://www.w3.org/TR/rdf-primer/
[RDFG]
Named Graphs, Jeremey Carroll, 29 November 2004. Available at http://www.w3.org/2004/03/trix/
[RDF Vocabulary]
RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004. Available at http://www.w3.org/TR/rdf-schema/
[RFC 2119]
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
[RFC 2368]
The mailto URL scheme, P. Hoffman, L. Masinter and J. Zawinski, July 1998. Available at http://www.ietf.org/rfc/rfc2368.txt
[RFC 4122]
A Universally Unique IDentifier (UUID) URN Namespace, P. Leach, M. Mealling and R. Salz, July 2005. Available at http://www.ietf.org/rfc/rfc4122.txt
[Turtle]
Turtle - Terse RDF Triple Language, David Beckett, 20 November 2007. Available at http://www.dajobe.org/2004/01/turtle/
[Web Architecture]
Architecture of the World Wide Web, Volume One, I. Jacobs and N. Walsh, Editors, World Wide Web Consortium, 15 January 2004. Available at http://www.w3.org/TR/webarch/

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-06-02 sanderson public beta 0.9 release
2008-03-27 sanderson public alpha 0.3 release
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.