Atrium EAD Content Modelling

Overall Approach

Notre Dame's EAD modelling approach in Atrium is as follows:

1. Model an EAD based collection at the atomic level
a. Each object contains only a snippet of EAD from the entire EAD finding aid for a collection
b. The EAD is stored in the descMetadata datastream for each object
2. Generate the entire EAD finding aid from its atomic parts when necessary
3. Index atomic parts in solr so they are independently discoverable
4. Some parent metadata is indexed along with children so that children are discoverable via parent metadata.
5. If an EAD finding aid already exists, when ingesting into Fedora it is parsed and multiple atomic objects are generated from it.
6. EAD hierarchical relationships are maintained via RDF in the RELS-EXT datastream for each Fedora object.
7. If desired, an atomic object's EAD metadata may be edited directly in the Hydra head

Content Model for EAD objects

Object hierarchy:

   - Collection
       - Child Image(s)
       - Child Component(s)
           - Child Image(s)
           - Child Component(s)

Collection

There is one Collection object that contains the ead header for the finding aid. A collection can have one or more child component objects. RELS-EXT Links between Collection and immediate child component objects are maintained via the hasMember relationship.

Component

There is a component object for each c# (c01, c02, c03, etc.) elements. Nested component elements are represented by an object independent of any parent/ancestor. A Component can have any number of nested Child Component objects (the EAD spec allows for 12 possible levels), and can also have child Image objects. Even though the original EAD finding aid might contain numbered components such as c01, c02, c03, etc., those components are converted to unnumbered component elements at ingest time. The role a component plays in the hierarchy is then determined by its context through relationships (ie. is it a direct child of the Collection, does it have item level child components) and by its level attribute. The level attribute can have the following possible values:

    * collection
    * fonds
    * class
    * recordgrp
    * series
    * subfonds
    * subgrp
    * subseries
    * file
    * item
    * otherlevel

If a component has child components, the parent component's level value is used to determine how to map relationships to the children.

Image

An image object is based on Hydra's GenericImage model and can be a child of either a Collection or Component object. It also has (albeit small) portion of EAD xml represented in its own descMetadata datastream. It is mapped to a parent collection or component also via RELS-EXT.

EAD Fedora Object and xml Example

For example, if you have the following EAD xml:

<c01 level="series">
<did>
    <container type="box-folder" label="Box ">1 : 2-4</container>
    <unittitle>Dance programs</unittitle>
</did>
<c02 level="item">
    <did>
      <container type="box-folder" label="Box ">1 : 4</container>
      <unittitle>The Feast of Apollo, Brattle Hall, Massachusetts</unittitle>
      <unitdate normal="1925">1925</unitdate>
    </did>
    <daogrp>
      <daoloc href="CC_1775_05_10_$3.front"/>
      <daoloc href="CC_1775_05_10_$3.back"/>
    </daogrp>
</c02>
</c01>

This results in two Fedora objects, both converted to unnumbered components. The descMetadata for each object is below:

Component 1

<c level="series">
      <did>
        <container type="box-folder" label="Box ">1 : 2-4</container>
        <unittitle>Dance programs</unittitle>
      </did>
</c>

Component 2

<c level="item">
      <did>
        <container type="box-folder" label="Box ">1 : 4</container>
        <unittitle>The Feast of Apollo, Brattle Hall, Massachusetts</unittitle>
        <unitdate normal="1925">1925</unitdate>
      </did>
      <daogrp>
        <daoloc href="CC_1775_05_10_$3.front"/>
        <daoloc href="CC_1775_05_10_$3.back"/>
       </daogrp>
</c>

Component 1 RELS-EXT:

Because component 1 is the parent and has level value "series", a relationship is added to the RELS-EXT for Component 1 using the "hasSeriesMember" relationship. To simplify the example, we will give each the following pids: Component:1 and Component:2

<rdf:RDF>
<rdf:Description rdf:about="info:fedora/Component:1">
<hasModel rdf:resource="info:fedora/afmodel:Component"/>
<hasSeriesMember rdf:resource="info:fedora/Component:2"/>
</rdf:Description>
</rdf:RDF>

There are also two "daoloc" elements representing two images in Component two. So, we will create two Image objects as well with the following metadata:

Image 1:

Image 2:

Component 2 descMetadata (updated):

<c level="item">
      <did>
        <container type="box-folder" label="Box ">1 : 4</container>
        <unittitle>The Feast of Apollo, Brattle Hall, Massachusetts</unittitle>
        <unitdate normal="1925">1925</unitdate>
      </did>
      <daogrp/>
</c>

Component 2 RELS-EXT:

<rdf:RDF>
<rdf:Description rdf:about="info:fedora/Component:1">
    <hasModel rdf:resource="info:fedora/afmodel:Component"/>
    <hasImagePart rdf:resource="info:fedora/Image:1"/>
    <hasImagePart rdf:resource="info:fedora/Image:2"/>
</rdf:Description>
</rdf:RDF>

Hierarchical Relationship predicates

If Component 1 was level "subseries", the relationship used would be "hasSubseriesMember" instead. Using all possible level attributes the following custom predicates are added to the predicate mappings configuration for EAD hierarchical relationship linking:

    :has_component_collection_member: hasComponentCollectionMember
    :has_series_member: hasSeriesMember
    :has_class_member: hasClassMember
    :has_file_member: hasFileMember
    :has_fonds_member: hasFondsMember
    :has_item_member: hasItemMember
    :has_otherlevel_member: hasOtherlevelMember
    :has_recordgrp_member: hasRecordgrpMember
    :has_subfonds_member: hasSubfondsMember
    :has_subgrp_member: hasSubgrpMember
    :has_subseries_member: hasSubseriesMember
    :is_member_of_component_collection: isMemberOfComponentCollection
    :is_member_of_series: isMemberOfSeries
    :is_member_of_class: isMemberOfClass
    :is_member_of_file: isMemberOfFile
    :is_member_of_fonds: isMemberOfFonds
    :is_member_of_item: isMemberOfItem
    :is_member_of_otherlevel: isMemberOfOtherlevel
    :is_member_of_recordgrp: isMemberOfRecordgrp
    :is_member_of_subfonds: isMemberOfSubfonds
    :is_member_of_subgrp: isMemberOfSubgrp
    :is_member_of_subseries: isMemberOfSubseries

*Note: To distinguish an EAD component collection from the overall collection, the relationship is called "hasComponentCollectionMember" instead of "hasCollectionMember" for level value "collection".

For linking to child images two additional relationships are also added:

:has_image_part hasImagePart
:is_image_part_of isImagePartOf