Thoughts on the final version of the Rights element

I originally viewed the Rights element purely in the context of basic Dublin Core. However, it turned out that Omeka could handle extended versions of the element.  This meant that the project could make use of the following choices:

• Rights: Simple Dublin Core
• Rights Holder: "A person or organization owning or managing rights over the resource.
• Access Rights: "Information about who can access the resource or an indication of its security status. Access Rights may include information regarding access or restrictions based on privacy, security, or other policies."

I considered the possible benefits of using the extended elements and checked to see what my own library and others have done in the context of the Online Archive of California. In the end, though, I decided that the rights situation of these images is best expressed through one simple statement, residing in the basic Rights element. This will help to ensure that the rights information comes through cleanly if the images are harvested or migrated to a different system and leaves the details regarding licensing and permission to be worked out by direct communication between the would-be user and the Bryant Museum.  It also allows for use of the Simple Vocab feature in Omeka, so data entry will be quick, easy, and uniform.

This is what I proposed for the Rights element (just approved by Dr. MacCall, hooray!):

1. Use the basic Rights element.
2. Simple vocab:  All rights reserved by the University of Alabama. Permission to reproduce in any format must be requested in writing by contacting the Paul W. Bryant Museum (http://bryantmuseum.com/).

Even though the link doesn't actually link, I thought it would be good to have it in there so users could just copy and paste it (or highlight and click "go to ...").  I chose the base URL rather than the contact page, as that is probably the least likely to change.

Can the Rights element be optional?

Dr. MacCall posed the following question in a comment on my previous post about the Rights element:  "One last question? In what circumstances would this element be optional?"

Obviously, in one sense the answer is "anytime someone wants it to be--this is Dublin Core, so naturally it's optional," but that doesn't really get to the heart of the question, which is really "when might it be appropriate or acceptable for this element to be absent?"

The Dublin Core Metadata Initiative has this to say:  "If the rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource." Based on this, I can think of various circumstances where one might leave it out:

1. Content that will never be made public.  However, in this circumstance someone still holds the rights. This element might also be a good place for a statement clarifying why the content must remain private.  If the content is merely embargoed, even if it's for a period of decades, that, too, is related to rights management and would be appropriately noted in Rights.
2. Content where the rights are in dispute.  It is understandable that a library would not want to take sides or state inaccurate information about this content.  However, rather than leaving it blank, it might be better to simply state "Rights under review" so that anyone wanting to use the image would not either assume it is freely available or expect to be able to license the rights easily.
3. Orphan works.  In the case of works where it can be assumed that copyright applies but the rightsholder is impossible to identify or contact, it would seem simplest to just leave off the rights information.  However, that does no favors to would-be users. Better to state that the item is an orphan work or use a phrase like "additional research required."
4. Content where the rights are unknown.  Again there would be the temptation to simply say nothing, but again it would be better to warn users that the rights situation is murky.  "Usage rights undetermined; users are advised to conduct further research" might work in this case.
5. Open access content.  There is a temptation here to think that there are no rights to worry about. However, even open access content frequently comes with restrictions related to attribution or non-commercial use that should be firmly stated.
6. Freely available or public domain content.  You could probably leave off the rights statement here, but why make your users do the copyright math or guess at the status when you could just tell them?
7. A rushed or understaffed project, or cases where content has been migrated from a different system.  In this situation, it might be acceptable to not have the Rights information listed immediately.  However, it would still be important to make addition of that element part of a planned later phase of the project.
8. The exact same rights information applies to everything in the library.  In this case, the digital library could probably get away with a blanket rights statement that is prominently displayed. However, the moment the content is harvested into another system, that blanket statement is lost.  A further problem could be a blanket statement on the front page that doesn't show on individual pages, so users coming directly to a content page from a search engine wouldn't see it.

To me, the Rights element has two important purposes.  One is to help protect the rightsholder from infringing uses of their content.  The other is to inform the user of the rights status of the content and, if possible, make it easy for them to request permission to use it.  By always clearly explaining the intellectual property rights of items in digital collections, even if that status is unknown, libraries can help make their patrons aware that not all content is freely available to use in any way they like, and guide them toward ethical habits of use.  The constant reminder also serves to highlight the issue of copyright extensions and how changes in the law can have a real effect on how everyone is allowed to use and re-use creative content.

In the end, although I can think of lots of situations in which the Rights element could be left out, but none in which it doesn't seem to me that it would be better to have it in there.  However, perhaps I am overthinking this and there is an obvious situation I'm overlooking.  What does everyone else think? Dr. MacCall, would you care to weigh in?

Rights: Your new favorite element

Why will this be your new favorite?  Because as long as the client approves this language, it will be the easiest required element in this project!  I think I've got this down to one statement that you can copy and paste into the "Rights" box for every image.  My only question is whether there should be a second (also easy!) Rights entry with a link to the Museum's contact page.  Dr. MacCall implied in an email that we could just say "by contacting the Paul W. Bryant Museum," but I'm worried that it's not enough.

What do you all think?  Is it enough?  Should we also link to the museum? Is there a significant risk that the museum will someday make changes to its site that break that URL? Is it worse to provide less information up front or to risk having potentially outdated information in our records that we'd have to contend with later (if this was a professional project)?

I'll note here that there is a variation where we just embed the link into the Rights statement. However, when I did this I noticed that the linked text was noticeably lighter than the rest of the statement. I'll paste snips of the two variations below so you can all judge the aesthetics.

Label
Rights

Element Description
This element states the various property rights associated with the resource, including intellectual property rights.

Required?
Yes

Repeatable?
Maybe

Guidelines for Creation of Content
Use the following statement:  
All rights reserved by the University of Alabama. Permission to reproduce in any format must be requested in writing by contacting the Paul W. Bryant Museum.

This is the HTML that could go in the second Rights field:  
<a href="http://bryantmuseum.ua.edu/direction.cfm?dir=contact" target="_blank">Contact the Paul W. Bryant Museum</a>

Examples
All images use the exact wording and HTML code above.

Notes
The Rights statement may be pasted directly into Omeka. To make the second Rights field, you need to paste in the HTML code and check the "Use HTML" box.

---

More Thoughts on the Rights Element

The Rights Element is one of the most straightforward of the elements in terms of what it should contain and why it is there.  By definition, it simply "includes a statement about various property rights associated with the resource, including intellectual property rights." Operationally, it establishes who the rightsholder is and frequently offers contact information for prospective users.

I looked over the guidelines linked from our wiki and I think the CARLI version is probably the most straightforward and applicable to our project.  The left side is simply labeled "Rights" and the right side is both non-threatening in tone and clear in its intent and directions.  I particularly like the second example:

All rights held by William Rainey Harper College Archives. For permission to reproduce, distribute, or otherwise use this image, please contact Firstname Lastname at xxx@harpercollege.edu.

Here is an actual example from the Great Lakes Digital Collection (Newberry Library):

Rights All rights reserved by the Newberry Library. Permission to reproduce in any format must be requested in writing. Contact Photoduplication Department, Newberry Library, 60 W. Walton St., Chicago, IL 60610. Phone: 312-255-3566. E-mail: photoduplication@newberry.org

I think this would translate into one simple statement that could be used for every image, something like:

Rights All rights reserved by the University of Alabama. Permission to reproduce in any format must be requested in writing. Contact [appropriate department at UA, phone: ____, email:____ ]

Right now I'm trying to find out what department that will actually be.  Several departments seem to hold licensing rights to images and trademarks:  Office of University Advancement, University Athletics, Hoole Library, even the Office of Archaeological Research. I've requested clarification on ownership from the client.

In the meantime, how is this looking to everyone?  Feedback welcome!

Rights Vocabulary: the publisher situation

While I was already thinking about Rights vocabulary, the Copyright Clearance Center conveniently tweeted a link to this post about the massive scale of rights and royalties that publishers must deal with, and ways they are considering to automate or at least improve the process. Rights and royalty data, it turns out, are a bit of a Wild West situation, with practically no standardization, and publishers "still receiving royalty statements from their licensees in all imaginable formats — PDFs, Excel documents, and even paper printouts."

Although the issue of ultimately funding the initiative is still up in the air, the Book Industry Study Group's (BISG) Rights Committee has begun work associated with three major themes:  the value of standardization and how it will provide return on investment, development of a standard vocabulary of rights terminology, and ways to improve the visibility and discoverability of rights. 

As the publishing industry continues to consolidate, with the resulting need to combine massively varied licensing data and control ever larger numbers of assets, the need to automate this process and create interoperability will become increasingly pressing.  While publishers have been getting along without standardization and automation thus far, it seems likely that the industry as a whole will become convinced that enough return can be made on the investment, and will move forward on this issue.

Rights Vocabulary for Digital Libraries

Since the Rights Element is my responsibility for our class project, I have been thinking about the appropriate language to use to make sure the information is both understandable and reasonably aligned with rights language in other digital libraries. I checked to see if there is a controlled vocabulary that we might use, but found that while much attention has been paid to structure and rules, actual right-hand-side standard terms don't seem to have one standard list. This list of licensing vocabulary from Center for Research Libraries has some useful terms, but it is mostly intended for licensing electronic resources such as databases, journals, and books. PRISM offers a very minimal list of right terms.  Creative Commons provides a clearer set of terminology, adapted for RDF, and several linked data licensing vocabularies are rounded up on this handy site.

For our project, keeping it simple will probably be the best course of action, but it is interesting to see how this might be handled in a linked data environment--and to realize how important proper encoding of rights data could be in an environment where the images in your digital library could be linked to outside resources in unexpected or imagined ways.

Rights Element: Firm but friendly

Now that the Rights Element has safely retained its place on the island, I'm starting to think about what it should contain.  Dr. MacCall made a very interesting point in class, that the Rights Element needs to be carefully balanced.  There's an inherent conflict in placing images in a digital library, available to the world--if we didn't want people to enjoy and use the images, we wouldn't go to the time, effort, and expense of making them available; on the other hand, we have to protect the copyright of the images, the wishes of the rightsholder, and the possible revenue stream use of the images might generate.  Therefore, the language in the Rights Element needs to be firm and clear, yet welcoming.

In thinking about this element, I can see that repeatability probably aids clarity.  A simple copyright statement stands alone, and is clear and neutral. Information for actually contacting the Bryant Museum or the University of Alabama regarding permission is best handled through a link to the contact page for easier maintenance.  But what about that welcoming part?

Tonya helpfully provided a link to the Minnesota Digital Library guidelines in this post, and they are clear and simple.  However, I found their Rights example to be a little off-putting from the user perspective: "This image may not be reproduced for any reason without the express written consent...." It's clear, it's firm, but it's not very friendly. I wonder if it would be better to phrase it more like "Interested in using this image? Express written permission is required for all uses. Please contact ... "

What do you all think?  Is it more important to invite usage or to discourage unauthorized usage? Can both be accomplished?

The Rights Element connected to the Source Element

(Edited now that I think I have a better grip on Source, "the most ambiguous, misunderstood, and misused of the 15 core elements.")

Last night I was discussing our assigned project elements with my course group, which includes Adam, Amy, and Katie.  I find it interesting how our different elements interact.  In particular, I think my element, Rights, could be related to Katie's element, Source.

Over in her blog, Katie wonders whether Source will be useful for this project, primarily because we don't yet know if all images will have an identifiable source, or if we'll be given more detailed information regarding the original images our images are derived from (our 2009 images were likely born digital, but the images from 1975 would have an original somewhere).  Her question has a lot of bearing on my element, too, because the Rights for each image may be based on whatever rules govern use of the Source.

Our textbook defines the Rights element quite simply as "'Information about rights held in and over the resource' ... [including] intellectual property rights."  Depending on circumstances, the Rights element might hold a very simple statement like "Copyright (c)2009 Paul W. Bryant Museum" but it could also include restrictions on use, such as "Written permission required" or "Noncommercial reuse only."

Importantly, the Rights may vary depending on whether someone wants to use the digital surrogate or needs to use a higher-resolution copy or get access to the original photograph or slide.  Alternatively, the Rights may not vary from original to digital copy, but whatever Rights govern the original may also govern the copy. The Rights element, like many Dublin Core elements, may also contain information pertaining to the original image as well as to the digital version.  In any of these cases, the data in the Source element would help to both clarify and validate the Rights information.

Rights metadata

The publication "Rights Metadata Made Simple" offers solid, easy-to-follow, no-excuses advice on incorporating rights metadata into a digital library.  Basing her recommendations on copyrightMD, "an XML schema for rights metadata developed by the California Digital Library (CDL)," author Maureen Whalen includes the following suggestions:

1. Capture fields such as title, that would normally be included in basic descriptive metadata anyway, in an automated manner if possible.
2. Capture author information, including nationality, birth and death dates, from an authority file if possible.
3. If the institution holds both the original work and a digital surrogate, separate rights metadata should be created and the two works should be clearly differentiated.
4. Use controlled vocabulary to describe copyright status and publication status to ensure that data entry is consistent and conforms if possible to legal definitions.
5. Recording the following set of data: creator information, year of creation, copyright status, publication status, and date(s) rights research was conducted, allows both internal and external users of the works "to make thoughtful judgments about how the law may affect use of the work."
6. Researching and recording the rights information for the contents of a digital collection allows libraries, archives and museums to be more "responsible stewards of the works in our collections and the digital surrogates of those works that we create."
7. Rights information is not static--it may need to be added to or updated periodically; all staff involved in digitization efforts should know who is in charge of maintaining rights information and how to contact them when new information is learned.

As a final piece of advice, Whalen reminds libraries that, while determining consistent local policies for situations where little copyright or publication is known are important, this should not be used as an excuse for delaying--institutions can start by recording the rights information that is already known and deal with the rest over time.