1. 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

2. 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.

3. 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

4. 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.

5. 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

6. 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)

7. 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.

8. 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

9. 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.

10. 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

11. 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.

12. 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