EAD (Extra)

Owned by Bill Branan
Jun 16, 2017
Why put EAD in Fedora
  • To enable discovery of materials via EAD metadata
Why put EAD in Solr
IU: Using Oxygen with templates and macros to do EAD creation and editing
  • Put EAD into Xubmit on top of RCS
  • Then goes to XTF for presentation and browsing of finding aid, and also goes into Fedora (entire EAD as collection level object), and MODS objects for components/items in finding aid
  • MODS records get pushed into Solr via Blacklight
UVa: Taking EAD produced by heterogeneous workflows due to evolving workflow or different sources (Special Collections vs Law) and breaking it into components to be stored in Fedora, then indexed by SOLR and disseminated through Blacklight. So you may ask, why break up EAD? Here is the response from our lead engineer working on this pilot project:

We have broken the EAD up (losslessly) to support appropriate linking to other objects in fedora.

One of the major challenges of EAD it represents an abstract view of the collection that is almost always incomplete with regards to actual real-world items.  For instance, even the most rigorous EADs do not go into details about the item that are needed to present a digital representation of that item, such as the individual scanned pages.  What's even more common are EADs that don't even describe the collection at the item level, but instead just refer to a series or some other logical grouping of items.  Our approach allows us to easily link digitized materials onto the logical components.  EAD isn't suited for this level of detail.

Furthermore, our approach allows us to represent the same resource in multiple contexts.  

It also allows us to link our finding aids with the MARC records used for accessioning and holdings information (as well as additional descriptive information).

We chose such an ambitious and complex representation of these finding aids in fedora in order to support a wider array of use cases.  It makes some of our work normalizing the current data more difficult, but because we embarked on this *before* there was a comprehensive effort to normalize the descriptive output of special collections (and other sources) we need our data model to be independent from the current data formats we have available.  (ie, we won't always be getting EAD XML files anything like the ones we have now, if we even get them at all)

Status: We are working on a pilot project to flexibly disseminate hierarchical content. Project will be discussed at DLF 2012.