Genevieve podleski Federal reserve bank of St. Louis Shades of Grey: Integrating Metadata for Discovery in a Mixed-Content Single-Subject Library Good morning! … When I say “a mixed-content single-subject library” I mean… Genevieve podleski Federal reserve bank of St. Louis

Both a subject and an institutional repository Collection provides access to economic and banking data and to policy documents of the Federal Reserve and the government FRASER is unique within the Federal Reserve system – it’s the only online, publicly-accessible site that has items from all 12 regional Banks, the Board of Governors, and non-Fed materials. FRASER (fraser.stlouisfed.org) is a mixed subject and institutional repository that preserves and provides access to economic and banking data and policy documents.

FRASER is grey Federal Reserve publications make up approximately 30% of FRASER’s nearly 1200 titles, including economic datasets United States government publications make up more than 50% of FRASER titles Legislation Hearings Reports Data FRASER also holds more than two dozen digitized archival collections Note that the Fed publications are not part of the Federal Depository Library Program – although some Board of Governors publications are listed in the FDLP List of Classes, they don’t send out free paper copies, and all reports required by law are now just published online. Paper copies used to be available to public and university libraries that requested subscriptions, but that had to be done separately. If those librarians didn’t know or care to request things, they didn’t get them – there was no one way to get Fed documents. Grown to encompass more gov docs and Fed publications – FDIC annual reports, Bureau of Labor Statistics bulletins from the turn of the century, and more. The archival collections are institutional records of the Fed as well as individuals important to Fed history

Where did we start? Publications Archives Statistical Data FRASER FRASER began as in 2004 as a data preservation and accessibility project – not a “digital library” Metadata was developed ad-hoc Each section of the public website had its own metadata set in the database Entire site built in-house; No catalogers or metadata specialists were involved Each of those circles had their own data entry procedures; those procedures would often change project to project So when I talk about “integrating” metadata, we needed to bring all of these together using a single metadata standard.

Goals More attractive and browsable public site launched in conjunction with the Federal Reserve centennial Better interoperability with other collections and with DPLA Improved ability to share content, including dynamically-generated research citations COMMEMORATE the Fed centennial DPLA is the Digital Public Library of America, and it’s a Europeana-style portal that brings together (via metadata aggregation) digital resources from all over the US – launched in April 2013; we were working with other Missouri digital libraries to put together a service hub from scratch. Better citations hopefully = more use by researchers; core audience is economic historians, but we want more historians, economists, and also teachers and students

The process Draft Discuss Test Evaluate Revise Implement Team of five librarians, with backgrounds in, variously, cataloging, gov docs and law librarianship, metadata, and archives. Tenures with FRASER and the Federal Reserve varied from less than one year to more than ten years. DRAFT: Write a full, cross-walked standard, with application examples DISCUSS: Discuss anticipated problems. Define terms. TEST: Independently apply the standard to a sample of existing documents. Document holes in the description. EVALUATE: Discuss each example as a group. Is there consensus on how things should be applied? Do more usage guidelines need to be found or developed? REVISE: Revise application of the draft standard. Does that fix the problems? If so, document. If not, make changes in the next draft. IMPLEMENT: Once you’ve come to a consensus and begun to implement the standard, you’ll find new snags – in our case, we came back to the group with the problems so we could run this process on just those issues. (I’ll get back to the implementation step shortly)

Dublin Core Pros Cons commonly used easy crosswalk DPLA compliant simple and straightforward Cons broad instead of precise many element usage conventions didn’t fit FRASER collection poor representation of related items and series Rounds 1-3 were Dublin Core, simple and then modified. Biggest problems with Dublin Core were Source, Type – no standard vocabulary – Title – no usage rules for subtitle, alternate title, etc. Crucial: DC’s Creator/Contributor/Publisher distinction is REALLY hard to navigate when you’re dealing almost exclusively with grey lit.

Testing exposes pitfalls How much work will this take to implement? Can data entry be automated? Will you have to create vocabularies and best practices from scratch? How much of the collection will an ‘out of the box’ implementation describe accurately? What’s out of our control? Technological limitations Organization of special collections or collections from contributing institutions One of the biggest problems that Dublin Core posed was that a lot of information was going to have to go into the “description” field

MODS More ‘library-like’ – AACR2 and RDA compliant Avoids Dublin Core implementation issues Allows import/conversion of MARC records DPLA compliant But… Still isn’t a perfect fit for archival collections, some titles, multiple authors, or non-print items Fourth and the fifth and final round were MODS MODS distinguishes between “genre” and “type of resource” – so it can be a “government document” and “text” or it can be “legislation” and “text” etc. There are standard definitions for “genre” in MARC; FRASER uses a subset Does a great job of handling alternate- and sub-titles All of that information in the description field in our existing metadata and in Dublin Core could be broken out into public and private notes, administrative fields, the abstract field, etc. Information that had been stored in Access databases, Sharepoint, project notes could also be made part of the actual metadata record.

Implementation Once a standard is selected, you still have to implement it. Carefully document choices you make when implementing Make adjustments to the standard if necessary Automate what you can Resign yourself to doing the grunt work May need to change materials or practices and not the standard For instance, we had to change multiple PDFs per issue to one PDF per issue; may mean doing some manipulation of the content (ex. Budget of the US Government was only produced in PDF in parts by the OMB; previously we posted it as-is, with certification. To make it work with metadata, we compiled these parts to a non-certified PDF.) Our implementation of MODS was so successful that our Missouri DPLA hub ended up also choosing MODS for their metadata standard for ingest. The perfect is the enemy of the good. (Le mieux est l'ennemi du bien.) — Voltaire

Lessons learned Begin at the beginning, if possible Test, test, test, and then test again Even the best fit isn’t a perfect fit Sometimes you have to change your practice One step at a time… …even if you step backwards Document everything Just Do It.

Questions? Genevieve Podleski genevieve.m.podleski@stls.frb.org What is an example of how you had to change your practice? What is an example of how you had to modify the standard? What is the site built on? PostgreSQL and PHP Genevieve Podleski genevieve.m.podleski@stls.frb.org