Everyday Electronic Materials (EEMs)

Stanford's EEMs support leverages a rich technical infrastructure developed internally by the Digital Library Systems and Services group (DLSS).

• EEMs resources are managed in the Digital Object Registry (DOR), built in Fedora (http://fedora-commons.org/). DOR supports the recording of metadata for an EEM, including the assignment of a unique identifier and tracking the resource throughout the collection and cataloging process.
• Stanford Library workflow coordinates the relationship between the EEMs tool and Symphony (http://www.sirsidynix.com/products/symphony), where traditional acquisitions and cataloging activities take place. A lightweight interface was developed to allow the EEMs processes to generate an initial MARC entry and pass it to Symphony, then to query Symphony for the status of that record as it passed through the Technical Services workflow.
• The workflow also automates the accessioning process for an EEM, generating MODS data from MARC for the Digital Object record, technical metadata based on JHOVE validation of files, appropriate rights metadata based on copyright status, and provenance information. The completed digital resource is then packaged for preservation using bagit, as well as prepared for online access.
• The EEMs dashboard is a Ruby on Rails front end using Active Fedora (http://projects.mediashelf.us/wiki/active-fedora) to interface with Fedora objects and Blacklight (http://projectblacklight.org/) over SOLR (http://lucene.apache.org/solr/) for discovery and display. It is an early prototype of a Hydra (https://wiki.duraspace.org/display/hydra/The+Hydra+Project) application.

A small development team created an EEMS tool to support the EEMS workflow on both front and back ends. The work of a prior planning grant had defined the needed functions. On project launch in September 2009, the business analysts, the user interface design specialist, and the developers on the EEMs project refined these requirements. The refined requirements were then checked against selectors’ workflow by observing selectors as they identified digital content they wished to select and include in SULAIR collections. In addition, Acquisitions staff demonstrated a process they used for linking to external content that would become an “EEM” when collected using the new workflow.

Based on a design by the user interface design specialist, the development team created a prototype interface, consisting of a web-browser bookmarklet “widget” that opens on a web page to capture basic metadata and a web-based “dashboard” for tracking uploaded objects through the workflow. The analysts previewed the prototype in February 2010, and the team tested the prototype of the widget and dashboard in March. Three selectors from different subject area were then recruited to help test the EEMs workflow and help design an introductory training session for other selectors in late April. The training covered rights issues as well as the EEMs tool and workflow.

For the next couple of months, a slightly larger group of selectors continued to test the software and the workflow. Based on feedback from this group of early testers, the development team added enhancements, fixed bugs, and prepared to release the software in production. All selectors were invited to attend one of two training sessions in mid-July to learn how to use the system in test or production mode. Following the July training, EEMs objects began to flow through the production system relatively smoothly. Upon ingest via the widget, notification is sent to technical services through a data stream from the Digital Object Registry (DOR) to the Symphony ILS system, indicating when objects are in a queue and ready for cataloging. Once the object is cataloged, DOR picks up the information that processing is completed and the object becomes available through SULAIR access and delivery systems, the Socrates and SearchWorks OPACs, and the “digital stacks.”

A September software release added the ability for the selector to upload documentation to support rights assertions, and to upload objects from the desktop as well as from the web. The ability to upload from the desktop became important when we discovered that many links on potential EEMs source sites, which appeared to the selector to be “pure” PDF links, led to scripts or other secondary file references that interfered with successful EEMs uploads. In the next release of the software, when an upload fails, the selector will be advised to download the object to the desktop and upload from there.