PREMIS: To Be or Not To Be in My METS The Preservation Journey at the University of Connecticut Libraries ALA Annual 2013 ALCTS PARS Intellectual Access to Preservation Metadata

Digital Preservation “Digital preservation combines  Policies  Strategies, and  Actions that ensure access to digital content over time.” --ALA/ALCTS/PARS Short DefinitionALA/ALCTS/PARS Short Definition

TRAC & PREMIS  Policies:  Compliance (if not certification) with TRAC/CCSDS M-1 (“Magenta Book”)  Requires set of policies  Strategies:  Fixity checking:  “ : The repository shall actively monitor the integrity of AIPs.”  Remotely replicated copies  Actions:  Fixity checking, at ingest and over time  Record fixity “hashes” or “message digests” in PREMIS  Replace fixity failures with good copies

Current Landscape  Currently The University of Connecticut Libraries relies on a number of solutions that incorporate various “levels” of preservation  CONTENTdm  Digital Commons  Archivists’ Toolkit  Archivematica  UCL’s AMFS (Archival Master File Service)  In 2011, a new team, the Second Generation Digital Library Services Working Group (2G), was created to investigate alternatives to these solutions that incorporated a more consistent preservation mission over all its solutions for its digital collections.

Timeline of Events for 2G Fall 2011 Creation of the Second Generation Digital Library Services Working Group Initial Questions on Metadata Spring & Summer 2012 Metadata Standards & Normalization Metadata & Our Content Model: Where Does Metadata Live? Fall 2012 Islandora Role of Metadata & Islandora METS Profile Registration Spring & Summer 2013 Playing with metadata Re-conceptualize Islandora as a presentation layer Fall 2013 & Beyond Investigations into Handling PREMIS Events, RDF & Linked Open Data

Fall 2011  In the search for alternatives to our current solutions, selected Fedora Digital Repository  Began investigating ingest scenarios  How will content creators submit content and associated metadata?  How will metadata be structured and organized? Will content and metadata be in shareable formats and/or proprietary?  Where do content and associated metadata live in Fedora?  Do we work with SIPs and what would these SIPs look like?  Do we follow others and rely on METS? How do we use METS?

Spring & Summer 2012  UCL’s Content Model (CM) for Fedora  Needed to decide whether to “lump” or “split” our architecture  Decision was made to “split” our content model into 3 different levels of related Fedora Digital Objects  Grouping Object Level that acts as the highest level to group like objects  Container Object Level refers to the type of a specific resource, such as an image vs a letter  Media Object Level contains the actual digital content such as the jpg or pdf  UCL’s CM, Metadata and Content  Our “atomistic” CM means a more “atomistic” approach to metadata  Metadata can live at any of our 3 different levels (or metadata can live as a data stream in any Fedora Digital Object at the grouping, container, or media object level.)  Metadata Standards and Normalization (METS)  We wanted the ability to process a variety of metadata (technical, descriptive, preservation, administrative, structural) at ingest, we needed a way to “normalize” ingested metadata in order to create and/or update data streams in the appropriate Fedora Digital Objects  We chose METS

Fall 2012  METS, aka the Uberset  What is the Uberset?  The role of the METS Uberset file  Our ideal role for metadata and in particular preservation metadata  Islandora  Seen early on as an administrative model and presentation layer for our Fedora Digital Repository

Spring & Summer 2013  Development of the METS Uberset file  What are the minimal requirements for metadata?  How do these minimal requirements for across 3 different levels of related Fedora Digital Objects?  What is the role of METSRights in relation to the other rights statements in the descriptive metadata?  What do we do with the technical metadata?  Where do we get our initial PREMIS data and where does that go in the METS Uberset file?

Spring & Summer 2013 Issues Encountered  Development of Islandora  Encountered conflicting content models  Decision to use Islandora as a presentation layer but not as an administrative model  Metadata in the METS Uberset file  Problem with the technical metadata from Archivematica  Inconsistent  Problem with PREMIS as it was transformed from METS Uberset file to a data stream  Logical loop created  Other issues with METS Uberset files  Workarounds solutions to problems above necessitated that METS Uberset files be re-written over several times  Large METS Uberset files which caused transformation problems and slow transformation times  Too much repetition in METS Uberset files

Summer 2013  Decision to move away from the METS Uberset File as a tool to create and/or update data streams  From metadata “lumpers” to “splitters”  Notion of Metadata “Modules” as  Flexible  Re-usable  Interoperable  Ability to add directly into FOXML and Fedora data streams  Unique specifications (best practices, standards, policies, forms, etc.)  Parts that can be packaged a number of different ways including as our METS Uberset file if needed

Fall 2013 & Our Next Steps  Refine specifications for metadata modules  Descriptive metadata (Simple Dublin Core, MODS for now)  Rights metadata (METSRights for now)  Administrative metadata (Fedora)  Structural metadata (Fedora, rels-ext, rels-int)  Technical metadata (Via FITS)  Preservation metadata (Normalized from Technical metadata with the one event, “ingest” for now)  Investigate how to handle PREMIS beyond the ingest event  Investigate RDF and Linked Open Data

Thank you  Jennifer Eustis   David Lowe 