What are RightsStatements About?
Richard J. Urban, Ph.D., Digital Asset Manager & Strategist, Corning Museum Of Glass
The previous post discussed how the rights statements provided by RightsStatements.org may apply to different kinds of digital or original works. While these rights statements were designed primarily for use in the context of digitization of material culture (for example, Europeana and DPLA), this post outlines the complexities of the relationships between an original artifact and its digital surrogate.
In the Requirements for the Technical Infrastructure for Standardized International Rights Statements the RightsStatements.org Technical Working Group has outlined an answer to the question of what a rights statement is “about” by providing examples of how statements may be used within specific metadata standards. Each of these standards and best practices have different ways of resolving the “aboutness” of statements.
In order to provide a technical infrastructure for the rights statements, the Technical Working Group choose to model the statements as a Simple Knowledge Organization (SKOS) vocabulary. SKOS is commonly used for representing knowledge organization structures, such as thesauri, taxonomies, and subject headings. We felt that the purpose of the rights statements was to perform a similar function within the information systems provided by DPLA and Europeana. Just as the “subject” of a book requires analysis by a cataloger, we felt the myriad ways cultural heritage organizations expressed rights over cultural resources could be classified by a well organized vocabulary of terms. The purpose of the statements was not to provide a legally binding license. Rather, a rights statement represents a judgment about a complex and interwoven legal state-of-affairs in order to facilitate finding, identifying, and obtaining cultural resources online.
Further, our Technical Working Group has declared each rights statement to also be a kind of dcterms:RightsStatement. The Dublin Core Metadata Standard defines a rights statement as:
A statement about the intellectual property rights (IPR) held in or over a Resource, a legal document giving official permission to do something with a resource, or a statement about access rights.
However, this does not directly answer what a rights statement is about. If we understand metadata to make assertions about resources (“Anything can be a resource, including physical things, documents, abstract concepts…”), a property like dc:rights can be used to describe any identified resource. So for a simple Dublin Core example of an In Copyright resource:
Figure 1: The grammar of a Dublin Core rights statement.
It is the responsibility of your metadata model to define what kinds of resources an assertion may be about (in the context of the Resource Description Framework (RDF), this is called the “domain” of a metadata property) [1]
For example, both Europeana and DPLA use fairly general-purpose metadata properties for expressing rights (dc:rights or its specialization edm:rights, for more details see specifications of the Europeana Data Model and the DPLA Metadata Application Profile). Their metadata models allow many elements to be attributed to resources that represent the original work (edm:ProvidedCHO or dpla:SourceResource) or belong to the level of digital representations (edm:WebResource, ore:Aggregation). But when using a rights statement in the context of an Europeana Data Model (EDM) metadata, the edm:rights property expects the subject of an assertion to be an edm:WebResource or an Aggregation of such resources. In this context, the rights statement will thus always be about the rights status of a digital representation. (Because DPLA’s Metadata Application Profile is based on EDM, it also associates edm:rights with a edm:WebResource).
Figure 2: In Copyright rights statement classification of a Europeana WebResource.
However, just because this is a recommended practice for partners in DPLA and Europeana, does not mean that rights statements cannot be applied to other kinds of resources in the appropriate contexts. One of the use cases we are currently following is the use of rights statements within the Structured Data on Wikimedia Commons Project. Because technical documentation has focused on Europeana/DPLA use cases, there has been some confusion about the use of the statements provided by RightsStatements.org in other contexts [2] [3]. Discussion especially occurred in the context of a new Wikidata property for the domain of Creative Works that can be used to organize them with a Wikidata item for rights statements [4] [5] [6] (we will soon publish a blog post about that).
Figure 3: Wikimedia Commons/Wikidata example of rights statements for both original CreativeWorks and a digital surrogate.
Example
Aspects of Negro Life (Q50086916) → No Copyright - United States (Q47530911)
In this example the creative works are the murals currently held by The Schomburg Center for Research in Black Culture. In the context of Wikimedia Commons metadata model, we could express a different assertion about the digital image that Depicts (P180) this creative work:
https://digitalcollections.nypl.org/items/634c59a4-6f99-3618-e040-e00a180633b0 → No Copyright - United States (Q47530911)
Although there is a relationship between the original creative work and the file that depicts it, the Depicts (P180) property is insufficient for us to infer any of the complex possibilities of how the copyright status of the original and the depiction are related. Because each assertion uses the Wikidata Rights Statements Status property to refer to a different entity (the creative work vs. its depiction in a digital file) it is possible to use the same kind of rights statement for both. This flexibility reinforces the need to handle rights statements with precision in the metadata about the source work and its digital surrogate. In particular, we call on implementers of RightsStatements.org to make sure that statements are used with metadata elements that clearly pertain to one of the levels of description (original object or digital representation). Again, here the name of a metadata element matters less than its usage with specific metadata resources.