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.

  • Thanks Managing Metadata | Celeripedean said,

    [...] have to give a shout out to Laura Smart at Caltech libraries and her recent post on her blog Managing Metadata. She writes about her current experience of moving beyond AACR2/RDA/MARC, DC and EAD. What is [...]

  • Jennifer said,

    Thanks for your post Laura. I enjoyed your description of what you’re doing and how you’re moving beyond AACR2/RDA/MARC, DC and EAD. It’s very similar to the work I’m doing at my institution. We’re implementing a Fedora digital repository. We’re moving away from Islandora however since our content model architecture is more atomistic. I would love to hear more on your progress.

  • laura said,

    Thanks Jennifer – I’d love to learn more about how Islandora can’t deal with METS as a wrapper and suspect I’ll be calling you at some point to pick your brain. I think we’ll be ok with flat record structure in MODS which has elements for both work & image. My plan at this point is to use a label attribute to distinguish which fields belong with which layer of description so I can parse the metadata if/when I need to work with it in some future context. I suspect that in the long term we’ll take advantage of other means of accessing the Fedora architecture like Hydra. For us, Islandora and working with consultants seemed like a good way for us to get started with Fedora but we won’t be wedded to it long term if other middle layer solutions work better. And really, Islandora developers should consider a “more atomistic content model architecture” given the state of cataloging theory and best practices. The notion of parent-child records isn’t new. FRBR has been around for a long time. Ditto CCO/VRA Core.

Add A Comment