What types of metadata should be collected by a DPLA and what can be done to increase its interoperability
|DPLA Wiki Navigation|
|About the DPLA|
|Main Page • Berkman Center|
|Board of Directors|
|Audience and Participation • Content and Scope|
|Financial/Business Models • Governance|
|Legal Issues • Technical Aspects|
|Beta Sprint • Workshops • Events|
|Media and Blog Mentions|
|List of Models|
|Community Portal • Sign on|
|Join the listserv • Listserv archives|
|Weekly listserv recaps • Suggested Resources|
The DPLA will have to acquire a huge amount of metadata, and has the opportunity to generate much more. It needs that metadata in order to provide core services to its users, but it could also be made available for the development of applications by external developers, and to be mashed up with existing applications. For example, if given access to anonymized usage data and user ratings, a developer might create a highly tuned recommendation engine. Or, an existing application such as Wikipedia might want to link to books in the DPLA's collection.
Possible types of metatdata to collect
Potential types of metadata to collect.
- Catalog data: Title, creator, license, url, year, language, etc.
- Usage data about the DPLA site: Which works are played or checked out? Which links are clicked?
- Usage data about works: Which works are played all the way to the end?
- Marginalia, annotations
- Circulation data from physical libraries
- User ratings and reviews
- User-created links among the works
- Semantic relationships among objects (created by users, harvested from existing sites and collections, generated via analysis)
- Geographic data about the subject of works, their creation, and where they are physically held
- Data standards for interoperability
- Make the data available via bulk download and/or via APIs?
- Identifying works that are "the same" at the relevant levels of the FRBR standard
- Building a functional, useful API