Moving into MODS and beyond

Posted by laura on August 9, 2012 under Integrated Library Systems, Standards | 3 Comments to Read

I’m stoked about the work I’ve been doing lately.  I finally get to do some hands-on production work with metadata standards beyond AACR2/RDA/MARC, DC, and EAD.  I taught myself XML in the late 90s and I’ve spent about a decade of avidly following the progress of METS, MODS, PREMIS, without any practical application.  Learning in a vacuum sucks. Getting neck-deep into a project gives me a firmer grasp of concepts.

We’re currently re-vamping our Archives systems architecture.  This has involved a year of analyzing workflow and current system functions, scoping our the functional requirements of what we need our systems to do, and evaluating the various solutions available.  Our integrated archival management system is a bespoke FileMaker Pro database (well, actually several databases).  It ties together patron management, financial management, archival description/EAD generation, digital object management, and web/interface layer.   It worked well for us, but our system is 20 years old and won’t scale to handle more complex digital archiving.  Ideally a new system for Archives would be as “integrated,” as our custom developed system.  Unfortunately, no such Integrated Archival System exists.

We decided to go with ArchivesSpace for archival description, Aeon for patron/financial management, and Fedora/Islandora for our digital asset management system (DAMS).  A unified interface layer wasn’t a critical component for us in the near-term.  We figure we can do something after the other components are implemented.  The strategic goal for us was to create an architecture with what I call the four systems virtues: extensibility, interoperability, portability, and scalability.  We wanted to future-proof ourselves as much as possible.

We’re implementing Fedora/Islandora in our first phase.  We’re starting by migrating our small collection of 10,000 digitized images from FileMaker Pro to Islandora, with the help of the folks from Discovery Garden.  We’re in the metadata mapping stage, making decisions on schema structure and indexing/searching/display functions.  We’re considering using a modified MODS schema with some local and VRA Core elements.  I’ve need to quickly climb a relatively steep learning curve.  First, I don’t have a detailed knowledge of data content standards for cataloging images.  It’s not a medium one typically handles in science & engineering. I’ve been reacquainting myself with Cataloging Cultural Objects (CCO) so I can help our archivists with descriptive data entry.  A knowledge of data content should inform choices of data structure and format (i.e. which elements of MODS and VRA Core to have in our schema).   Second, I’m learning the Fedora “digital object” model and how it relates to Islandora functionality.   Digital objects in this context is not digital objects in the librarian sense, a label for born-digital/digitized content.   Third, I’m simultaneously considering the crosswalk between our legacy records and MODS while specifying our future image descriptive cataloging needs.

My biggest philosophical brain effort right now is figuring out how to implement best practice in image cataloging within Islandora/Fedora. Per CCO/VRA Core, there should be a clear distinction between the work and the image (analogous to FRBR work and expression/manifestation).  In theory, this is can be done by having two records and relating them via a wrapper metadata like METS, or by using “related item” elements within the descriptive metadata schema.  In practice, I simply don’t know how Islandora can manage it.  Fedora was made for this type of thing, fortunately, so I assume that it’s possible.  Obviously I’ll be looking at the work of others to inform our choices in the metadata structure.

Fortunately, I consider this fun.