LibraryCloud

Project to get item-level descriptive metadata from EAD finding aids into Library Cloud to enable discovery and access with descriptive metadata from other sources

Encoded Archival Description (EAD)  is the standard for describing archival collections. It mimics the analog practice of “finding aids” which describe content at the collection-level, providing background information and an inventory, which typically lists, and briefly describes, boxes and folders (and sometimes items within folders). In the online environment EADs do not play well with most other standard descriptive metadata for collections, which usually have descriptive metadata at the item level (e.g., a MARC record, an FGDC record or a VRA record for a book, a map or an image).  Within a finding aid, the contextual information required to adequately describe an item is not found in the item-level label alone. Rather, it is found in the information above the item (in sequence and hierarchy), such as the collection title, date and description as well as labels for the series, box and folder.

To enable discovery and access of these archival collections with items from other sources, we need to free the item-level metadata from EAD finding aids.

Current work by Michael Vandermillen to free item-level metadata described in EAD finding aids includes:

• Automatically assigning item-level identifiers within EAD finding aids (Underway, done in OASIS QA for Link-o-matic)
• Extracting item-level metadata along with other related metadata in finding aids such as series-level and collection-level descriptions (Underway, done in OASIS QA for harvesting, including Virtual Collections, CNA and CANA)
• Creating crosswalks for converting EAD metadata to formats more amenable to transfer and display for sharing and aggregation with other collections. (Not yet started, needed for Library Cloud, DPLA sharing, CNA and CANA)

Other related activities include:

• Andy Silva developed a method to parse EAD finding aids and merge them with DRS load reports to create 3D records with links to DRS files (with manual code tuning for each EAD) for the Law Library’s Suite Spot app.
• ArchivesSpace, an open-source web application to manage descriptive information for archives, will be a central service to the libraries sometime after the production rollout in Fall 2013. Harvard users of the Archivist’s Toolkit and others will be likely adopters. AchivesSpace may become the source for component-level archival data once adopted (replacing MVs interim process described above). 

Michael, Robin, Wendy

EADComponentsProjectOverview.docx

Wendy, Michael

Paul

project overview

The base syntax is:

http://webservices.lib.harvard.edu/
rest/hollis/avail/{HOLLIS_number}

There is a PRESTO API to retrieve VIA record data in MODS. There is no search API for VIA, although image records can be located through the existing PRESTO HOLLIS search API

HGL is based on OpenGeoportal, which support solr search and retrieval of metadata records. I'm nor sure if an API exists to retrieve the native FGDC schema metadata record.

Collection building in Library Cloud

For curators, one of the benefits of the web is the ability to unite physically dispersed material through online digital collections. For web-based presentations, Harvard curators often create “virtual collections” by drawing together related content from multiple catalogs and/or collections. In addition, collaborations can also include non-Harvard content (e.g, Emily Dickinson Archive and Colonial Archive of North America). To do this, they need to be able to identify related content, select it and mark it as a collection (or “set”). Then, they need to be able to confine a search to retrieve a set and display it in a web-based collection presentation UI.   

To support this, the following collections functionality is needed in Library Cloud:

• a search API to discover and select items for inclusion in a collection
• the ability to mark records as part of a named set (or “collection”)
• a search API that can confine results to the named set (i.e., qualify by collection facet or filter)
• a default UI presentation driven by the Library Cloud API confined to a named set (this allows collection building through a simple centrally-supported presentation system to replace the aging “Virtual Collections" application (see status) 
•  an OAI-PMH data provider (DC and MODS) for named sets (this allows harvesting for collection-building in systems such as OMEKA, see Library Cloud project #10)

 Harvard’s web-based collection-building application, Virtual Collection (VC) currently supplies the following functionality, but is in need of an upgrade:

• harvests records from Aleph, VIA, HGL, into defined collections
• ability to add topics
• OAI-PMH data provider (DC and MODS, supports sets)
• Customizable (LTS staff required) discovery UI, supporting search, browse, brief and full record display
• no public search api for Virtual Collections

Michael, Wendy

proposal

Michael, Wendy

Harvard’s special collections, archives, libraries, and museums are looking for web-based solutions to providing information about, and seamless delivery of, static images, textual works, sound recordings, and moving image materials in one place. Project would aim to offer special collections, libraries, archives, faculty, and students their own installation of Omeka on an LTS server using a “Harvard install” of Omeka.   The packaged version would include a a plugin (or plugins) for importing metadata from Library Cloud (OAI harvest, CSV import plugin, or potentially a new import plugin if needed); in addition a wide variety of plugins available to Omeka users would be bundled. Future development may include a single portal to Harvard’s Omeka content, facilitating a number of interesting projects, such as time lining across repositories or doing geospatial work.  The packaged version could be bundled with a set of data entry guidelines/recommended ways to enter content (and in which fields) to promote consistency of data across instances, as well as a plugin to get data back in to LibraryCloud.

Omeka is in use by, or has been experimented with, a number of Harvard repositories (such as the Center for the History of Medicine, which has a robust system, is planning additional development this summer, and could lend expertise).This has required local development for improved functionality, something many repositories, students, and faculty do not have access to.

With promotion, the University could build a substantial amount of content currently hidden to users and encourage the use of a system that could be centrally harvested and disseminated. Because the data is OAI-PMH compliant (Dublin Core, MODS, CDWA Lite), it could be harvested for display in a central system, such as Hollis, to bump up collection visibility.

Related Omeka plugins: OAI-PMH Harvester, OAI-PMH Repository, Catalog Search

Emily, Michael, Jonathan

• The content and metadata are archival manuscripts described in EAD finding aids that need to be represented at the component level for discoverability, display and delivery (project #3, work underway)
• The Harvard CNA and the federation CANA each require web-based collection presentations (project #10-ish, but also aligns with collection platform evaluation work)  
• The federation CANA includes metadata for both Harvard and the external partners (project #9)

In addition, the CNA and CANA project workflows need to support both retrospective and prospective work, which may be a good test of 2 data transfer workflows.

Jim, Wendy

Proposal