OAI-Rights White Paper

September 26, 2003


Carl Lagoze (lagoze@cs.cornell.edu) - Cornell University Information Science

Herbert Van de Sompel (herbertv@lanl.gov) - Los Alamos National Laboratory
Michael Nelson (mln@cs.odu.edu) - Old Dominion University Computer Science

SImeon Warner (simeon@cs.cornell.edu) - Cornell University Information Science


The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)[1] has become an important foundation for interoperability among networked information systems.  It is widely used in a variety of domains including libraries, museums, government, and research. 


Like any vehicle for exchanging information, the OAI-PMH exists in a context where information holders have concerns about rights to the use of their information.  Although the OAI-PMH is nominally about the exchange of metadata, this does not lessen the complexities of rights-related issues:


  1. The distinction between content (data) and metadata is fuzzy at best, especially vis-à-vis intellectual property, and many providers are justifiably wary about uncontrolled reuse of rich metadata that represents a significant intellectual effort. 
  2. Since the only technical restriction on data exchanged via OAI-PMH is that it must use XML encoding, it is entirely feasible to use the protocol for transmission of content itself. 
  3. Since the primary reason for making metadata available via OAI-PMH is usually eventual access to the resource described by the metadata, guidelines and frameworks for expressing rights to that resource are in the scope of the protocol. 


As a result of these issues, discussion of rights and their relationship to the OAI-PMH have been frequent throughout work on the protocol.


This paper is intended as a foundation for work aimed at incorporating structured rights expressions into the OAI-PMH.  This work will be undertaken by a technical group called oai-rights, and will result in a set of OAI-PMH guidelines scheduled for release in second quarter 2004.  A copy of the letter of invitation to this group is included as Appendix A in this document.  In the tradition of OAI-related work, this effort is tightly scoped and intended to produce results that are both simple and extensible.  As such, two items are out-of-scope for the oai-rights effort:


  1. oai-rights will not define any new rights expression language or semantics.  There is a wealth of work in rights expression languages with buy-in from industry and other organizations.  These include XrML[2], ODRL[3], and the Creative Commons[4] initiative. 
  2. oai-rights will avoid restriction to any single rights expression language.  The goal is to permit any type of rights expressions expressible as XML.  We will work on including Creative Commons licenses in OAI-PMH responses, but only as a proof-of-concept of the general approach.


This paper examines issues and suggests alternatives for the incorporation of rights expressions in the OAI-PMH along three dimensions:


  1. Entity association, which covers the association of rights expression with metadata and data (resources).
  2. Aggregation association, which covers whether rights expressions can be associated with entities in the OAI-PMH that group other entities.
  3. Binding, which covers where rights expressions are placed in protocol responses.

Entity association

 Experience with the OAI-PMH thus far indicates that the oai-rights effort should focus on both rights expressions for metadata and associated resources:



We therefore suggest  that oai-rights proceed on the assumption that the handling of rights expressions for both metadata and resources will be covered by any specification.

Aggregation association

The OAI-PMH data model includes a number of entities, some of which aggregate other entities.  These entities are listed below, with the aggregating entities in bold-face, and illustrated in the figure below:



oai-rights will need to decide if rights expressions can be associated with the aggregating entities, independent of whether the expression concerns the content (Resource) or the metadata (Record).  For example, the ability to associate a rights statement with a Repository might provide a shortcut for expressing that statement about all Records disseminated via that Repository and/or all Resources for which those Records are metadata.  Similar semantics might exist for associating rights statements for Items – applicability for all Records (metadata formats) that are grouped by that Item – and Sets – applicability for all Items (disseminating Records) that are aggregated by that Set.

While this may be a convenient shortcut, we foresee a number of complications in such shortcuts that may make them complicated to implement:



At first glance, therefore, it may make sense for the oai-rights specification to only allow rights statements associations with the non-aggregating entities Record and Resource.  However, another solution may be possible.


Because some metadata formats already have means of expressing rights statements, for example the rights element[6] in Dublin Core, oai-rights will need to consider whether to employ these mechanisms in metadata formats, to restrict the rights statements to some more specific protocol mechanism, or to allow some mixture of these methods.  Two issues need to be considered to make a decision in this area:



o       The existing Dublin Core requirement in the OAI-PMH is now under discussion.  The most compelling argument for loosening this requirement is that Dublin Core semantics (resource discovery) are not appropriate for a variety of applications of the OAI-PMH that are not oriented towards resource discovery or “document-like objects”.  Perhaps the utility of the DC rights element is a convincing argument, but this needs to be considered.

o       As described earlier, the resulting specification should allow expression of rights statements defined by various external efforts such as XrML and ODRL.  Both of these use XML areas their encoding mechanism.  However, qualified and unqualified Dublin Core, qualified and unqualified, currently restricts element values to text literals and not arbitrary XML sub-structure.  Thus, it would not be appropriate to embed an XrML statement in a DC rights element.

o       As noted earlier, the oai-rights effort begins with an assumption that rights statements should apply to Resources and metadata  Records.  The semantics of the DC rights element is specifically “a rights management statement for the resource, or reference a service providing such information.”[7]  Thus, simply exploiting the rights element within the oai_dc metadata format will not provide a comprehensive solution.


An alternative and somewhat simpler solution to consider is to define within OAI-PMH two mechanisms:

  1. An “about” container[8] that permits packaging of a single rights statement encoded in XML (conforming to any schema such as XrML) that addresses rights concerns about the associated metadata Record.
  2. A designated metadataPrefix, such as oai_rights, that is a package for including a rights statement about the Resource in XML (conforming to any schema such as XrML).  The schema for such metadataPrefix might just be enclosing tags, and then allowing sub-tags for any rights specification language.


While this solution might duplicate some effort by existing metadata initiatives, such as DCMI, it does present a relatively easy solution for harvesters.


oai-rights is intended as a relatively short-term (less than one year) and well-scoped effort to define how rights statements should be carried in OAI-PMH.  As such, the effort needs to follow the spirit of previous OAI activities; simple solutions that cover a broad class of uses.  This paper has described a number of issues in approaching this problem and, hopefully, laid the foundation for a solution that reflects this spirit.


[1] http://www.openarchives.org.

[2] http://www.xrml.org/.

[3] http://odrl.net/.

[4] http://www.creativecommons.org/.

[5] http://www.nsdl.org.

[6] http://dublincore.org/2003/03/24/dces#rights.

[7] http://www.dublincore.org/documents/dces/.

[8] http://www.openarchives.org/OAI/openarchivesprotocol.html#Record.