Rights Issues and Crowdsourcing: Digital Public Library of America

Rachel Frick, Digital Public Library of America

There were some really great conversations this morning and I’m taking a pause to just acknowledge the great ideas that were put up there. There is a question someone brought up, and it is something I was thinking about before coming here: Who owns what? Who owns what part of the process? Who owns what  part of the product? And how do we communicate in a way that facilitates uptake and reuse? I don’t think we express very transparently what pieces or parts are reusable, and if we did find something that was proprietary or there is something that is locked down, why? If we do express that, we tend to express it in human ways, and we don’t do things that are for machines. An example at DPLA is that we are going to announce tomorrow some white papers around rights. As boring as that sounds, the biggest hurdle for collection release for cultural heritage organizations is being able to express rights in other ways besides licenses because cultural heritage organizations don’t feel they have the right to express a license because they might not own that intellectual property on the items in their collections. They might own the item, but not the intellectual property.

We are recommending rights statements that are machine-actionable. For example, if you wanted to come to the DPLA and run a computational query on 10 million records and find everything that is in the public domain, you can’t. We did an analysis of eight million records, and of those eight million records we have over 78,000 unique expressions of rights. Right now in our metadata analysis, over 25% of the content in our metadata records describe rights, access and reuse rights, and it is not consistent. That is a big hurdle for reuse and it is not glamorous, it’s that functional and operational thing. So are we building up things that we think we are sharing, but if somebody from another domain comes in and tries to use your system and your tools, there might be things that you’ve programmed in that are causing some friction. We need to really enable flow.

The last piece I have is: How can we check for ego? I think a lot of times we have organizations or groups that want to own the whole problem and the whole solution instead of saying, “I do step two really awesomely.” Or, “I built this part of the widget that is excellent, but step one and step three are a little shaky. I saw somebody else’s step one that was really great.” And we need to document this really clearly. How are we building for the best interoperability of the best pieces of the best projects?

This presentation was a part of the workshop Engaging the Public: Best Practices for Crowdsourcing Across the Disciplines. See the full report here.