[Cache from http://dublincore.org/usage/meetings/2004/03/dc-rights-proposal.html; please refer to this canonical location if possible.]
Stuart Weibel
OCLC Office of Research
Andy Powell
UKOLN, University of Bath
Eric Miller
World Wide Web Consortium
February 11, 2004
The DC Rights element was added to the Dublin Core following DC-3, in recognition of the importance of terms and conditions of use for discovered resources. To date, it has been little utilized, owing to the lack of standard practice concerning rights declarations on the Internet.
The recent emergence of the Creative Commons as a clearinghouse for rights declarations affords an opportunity to improve this situation, particularly for resources that have been developed with the intention of cost-free distribution, but whose creators wish to formally declare various rights.
Creative Commons has defined several licenses from which content rights holders may choose. Each of these licenses is unambiguously identified with a URI that is managed as unchanging and persistent by Creative Commons. Thus, this namespace comprises a controlled, enumerated vocabulary of license declarations, open for use by any party for whom their terms and conditions are judged useful. Providing a clear method for embedding of CC license information within the Dublin Core will reinforce the impact of both protocols. Both CC proponents and DC adopters will benefit by having a clear approach to formal rights declaration in a widely adopted metadata framework on the Internet. Further, the model for such declarations has been defined so that it is broadly useful for declaring licenses from other sources as well, providing a general-purpose mechanism for intellectual property declarations.
This proposal outlines functional requirements, discusses alternative representations, and proposes a standard of practice.
DCMI metadata currently supports the following functional requirements, through the use of the DC Rights property:
By using appropriate conventions for the value string of dc:rights (e.g. "(c) Copyright University of Bath, 2002") it is possible to meet narrower functional requirements, such as "provide a simple human-readable statement of who holds copyright over a resource" and "support simple (i.e. potentially ambiguous) searches of the form 'find all resources where an entity that is named using a simple string is likely to be the copyright holder'". However, these narrower requirements can only be met using searches based on simple string comparisons (e.g. search for '"copyright" AND "University of Bath"'), which is not a very robust approach.
The two proposals for new DCMI properties below are intended to support the following additional functional requirements:
Furthermore, there may be additional requirements related to specific kinds of rights (copyright, patent rights, database rights, etc.). For example:
These more specific requirements are not met by the two proposals below. However, they could be met through the proposal of narrower sub-properties of dcterms:rightsHolder, for example dcterms:copyrightHolder.
There are two primary requirements for rights declaration addressed in this proposal:
This proposal recommends the adoption of the following terms to meet these requirements:
license
rightsHolder
The specifics of each proposed term are elucidated in the Proposal Requirements Tables below.
Anticipated values for the proposed elements remain useful when stripped of their qualifiers, however, as with all such "dumbed-down" metadata values, the results will not be interpretable with the same degree of confidence. This is particularly important in the treatment of rights metadata because of the potential legal implications. A "dumbed-down" rights statement may be incomplete, but should not mislead.
This proposal was motivated by the requirements for supporting declaration of Creative Commons licenses, but can be similarly applied to any set of licenses without future coordination with DCMI or changes to DCMI metadata terms. Any party desiring to specify and maintain licenses can take advantage of this infrastructure.
Terms proposed in this proposal are defined with a degree of specificity and constraint equal to, or greater than, other DCMI terms.
It is recommended that the value of license is denoted by a URI identifying an IPR license.
The rightsHolder term is defined in much the same manner as any of the agent elements of DC (creator, contributor, and publisher), with an additional constraint that the identified entity must be able to be associated with intellectual property rights (thereby ruling out instruments as valid values for this term).
Use of Creative Commons licenses represents a formal opportunity for right holders to declare terms and conditions outside the framework of commercial Digital Rights Management (DRM) systems, and as such has the potential to have an important impact on the development of best practice in communities managing digital assets. In addition, the proposal is written such that licenses other than Creative Commons licenses can be declared without retrofitting these terms, and without requiring other organizations or initiatives to adopt namespaces from competitive initiatives.
It is expected that much commercially managed content will increasingly be packaged within DRM systems. The current proposal is based on the declaration of digital rights, rather than management, and is more suitable for organizations and individuals that want to make their content widely available, often without compensation, but without foregoing specified rights.
Specifying license URIs is straightforward and unambiguous, taking advantage of the basic Web infrastructure, and relying on the commitment of organizations to support such infrastructure over time.
The proposed license term refines the Rights element, affording a degree of specificity and constraint that make it broadly useful for rights declaration applications. The proposed rightsHolder term is not a refinement of any existing DCMI terms. Declaring the new terms within the DCMI namespace will simplify their interpretation by metadata applications and provide sufficient generality to support any group that chooses to specify licenses. No coordination with DCMI would be necessary to expand the use of the terms by other organizations in the future, and DC will help to establish a consistent and useful deployment framework for the community at large.
An alternative to the proposed approach is to declare a Creative Commons encoding scheme and simply register it as such, leaving the semantics, structure, and syntax to the Creative Commons community. This would work, but is undesirable in that there would be little incentive for competing licensing schemes to use CC's encoding, possibly leading to divergence in the structure, encoding, and semantics of multiple rights declaration schemes.
Creative Commons is an organization that is focused on licenses, not on the structure and encoding of the metadata about those licenses. DCMI, in turn, has no expertise in licenses, but can facilitate rights declaration by promoting a consistent and flexible means for encoding declarations.
Examples of organizations using CC licenses can be found at http://creativecommons.org/learn/collaborators
Those participating include a variety of organizations that come from traditional DCMI constituent communities.