Skip to end of metadata
Go to start of metadata

In some of our older collections, EAD finding aids are used to generate item-level MODS records, and the items are treated like any other objects that are described by item-level MODS records.

Moving forward, most of our collections based on EAD finding aids will be collections that have a mixture of item-level and collection-level description. Depending on the collection, all, none, or some of the objects in the collection may be digitized. It is likely that these collections will undergo changes as time passes. The collection may be re-organized. Additional objects may be digitized. For items that were digitized and treated as a simple collection of objects in a folder, additional item-level descriptions may be added.

Proposal:

  • The EAD file will be treated as the master metadata.
  • Identifiers
    • Typically, the entire EAD file (entire collection) will be given a single NOTIS-form identifier. If the collection has multiple entries in the main library catalog, it may receive multiple NOTIS-form identifiers.
    • Each node likely to be adressable (<c0x> and <dao>) within the EAD file will be given an identifier that consists of the EAD file's identifier plus a "node number" (e.g., ABC1234-0056). The node numbers will likely reflect the order in which nodes were created, but they carry no meaning other than serving as a unique identifier for the node. Each <c0x> in EAD file will receive a node number, including <c0x>s enclosing information about individual items. If the finding aid is reorganized, new node numbers will be created for any new nodes, but an effort will be made to retain node numbers where the item identified by the number is essentially unchanged. All accesses to the digitized contents of the finding aid will be via PURLs that reference these node numbers. Note that while <dao> nodes may receive node numbers, in a <c0x> node that only contains a single <dao>, the <dao> will not receive a node number.
    • Each digitized file will have a filename indicating the node that it is associated with, and multi-page items will include a page number (e.g., ABC1234-0056-2-screen.jpg).
  • PURLs
  • Fedora organization
    • There will be a finding aid object containing the EAD file.
    • Depending on the nature of the collection, there may be more objects to store digitized items, folders, etc. Each of these objects will implement the appropriate content model, and store any derived information necessary to facilitate use in the appropriate delivery systems.
    • Often, structural metadata for box- and folder-level objects will be derived automatically from the EAD file.
  • Fedora behaviors (these are still very sketchy)
    • getObject(nodeID) – Returns the Fedora object that best represents the given ID
    • getChildren(nodeID)
    • getNumChildren(nodeID)
    • getEAD(nodeID) – Returns a portion of the EAD file, or the full EAD file if no nodeID is specified.
      • Could this simply fit into getMetadata?
      • Or should it use the paged text disseminator? (This is essentially what Tufts does.)
  • No labels