...
Site | Collection | EAD structure / location of born digital materials [type of hydra object] | notes | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a5460e16fdcecfbb-90ae38b2-43574fcb-92d9b67f-f60ce6c165f6310601995505"><ac:plain-text-body><![CDATA[ | Hull | Gallagher | collection [set] |
| |||||||||
Hull | Socialist Health Assoc. |
|
| ||||||||||
Stanford | Xanadu | collection | 1. Target "born digital" sub-level identified by <unittitle> | ||||||||||
Stanford | Gould | collection -- unittitle "Stephen Jay Gould papers" unitid: M1437 | EAD only goes down to the single "Born digital" series description, with no details expressed at lower levels. A rationalized directory structure and FTK output are intended to support a direct translation into Hypatia objects for both unprocessed and processed views without an intermediary EAD. | ||||||||||
Virginia | Cheuse |
|
| ||||||||||
Yale | Conn. Oral Histories |
|
| ||||||||||
Yale | Love Makes a Family |
|
| ||||||||||
Yale | Pelli |
|
| ||||||||||
Yale | Tobin | collection | 1. Target sub-level identified by <unittitle> | ||||||||||
Yale | Turner |
|
| ||||||||||
Yale | Welch |
|
|
...
In general, "item" level entries in an EAD will map to individual Hypatia objects. The "file" level" may also be considered an item node for a specific EAD. Unless otherwise indicated for a specific conversion, other levels will translate to set objects in Hypatia, even if they are empty sets because the EAD had no item-level description.
EAD-to-MODS - general information
There is a scarcity, dare I say dearth, of tools available to do this mapping or to offer an existing implemented conversion. So the mappings here are based on data encountered in the Hypatia sample EADs and can be augmented as we go along. They are informed by two sources:
- DLF Aquifer Guidelines for Shareable MODS Records: EAD to Aquifer MODS Crosswalk
- Bountouri, L., & Gergatsoulis, M. Interoperability Between Archival and Bibliographic Metadata : An EAD to MODS Crosswalk, 2009.
Assumption: Working assumption is that all descriptive metadata, for collections, intermediate sets (levels) and digital objects will be MODS.
Issue: the mapping from EAD to MODS is not perfect and is not fully reversible:
Stanford FTK-backed Digital Object creation
Stanford uses the Forensic Toolkit (FTK) software to analyze and characterize the contents of computer media. Starting with the Gould collection, we will only provide a single series node in the EAD to represent "Born Digital Materials". Conversion routines will be able to auto-generate objects representing the unprocessed collection (the media artifacts themselves, e.g., hard drives and floppy discs) as well as detailed file content objects from a modified form of the FTK output.
EAD-to-MODS - general information
There is a scarcity, dare I say dearth, of tools available to do this mapping or to offer an existing implemented conversion. So the mappings here are based on data encountered in the Hypatia sample EADs and can be augmented as we go along. They are informed by two sources:
- DLF Aquifer Guidelines for Shareable MODS Records: EAD to Aquifer MODS Crosswalk
- Bountouri, L., & Gergatsoulis, M. Interoperability Between Archival and Bibliographic Metadata : An EAD to MODS Crosswalk, 2009.
Assumption: Working assumption is that all descriptive metadata, for collections, intermediate sets (levels) and digital objects will be MODS.
Issue: the mapping from EAD to MODS is not perfect and is not fully reversible:
- The original EAD header, while preserved along with the original EAD, is not The original EAD header, while preserved along with the original EAD, is not part of the makeup of the resulting Digital Objects and would not change.
- While no metadata information should be lost, it may not be mappable to original form of expression if multiple styles or patterns are reconciled into one, e.g., implicit vs explicit labels based on <head> elements.
- There are artifacts of EAD markup, such as qualifying element attributes, that have no corresponding place in MODS and will not be brought over unless further accommodation is made.
...
| Panel |
|---|
<repository encodinganalog="3.1.2">Hull University Archives</repository> <unitid encodinganalog="3.1.1" label="Reference" countrycode="GB" repositorycode="50">U DGA/1/2/5/a</unitid> <unitid label="Call Number:" countrycode="US" repositorycode="US-CtY">MS 1746</unitid> <physdesc encodinganalog="3.1.5" label="Extent"> <accessrestrict id="ref5"> ... <origination label="creator"> <persname rules="aacr" source="naf">Shearer, Rhonda Roland, 1954- </persname> <unitdate normal="1951/1996" type="inclusive" calendar="gregorian" era="ce">1951-1996</unitdate> <note type="bpg"> |
Conversion rule: Attributes not specifically targeted for conversion will be ignored/lost.
Issue: retaining ref and level information , do these map to appropriate container descriptions?
Issue: "otherlevel" levels -- <c level="otherlevel" otherlevel="SubSeries"> (Hull)
Issue: Stanford <container> conventions
<c id="ref432" level="file">
...
CtY">MS 1746</unitid> <physdesc encodinganalog="3.1.5" label="Extent"> <accessrestrict id="ref5"> ... <origination label="creator"> <persname rules="aacr" source="naf">Shearer, Rhonda Roland, 1954- </persname> <unitdate normal="1951/1996" type="inclusive" calendar="gregorian" era="ce">1951-1996</unitdate> <note type="bpg"> |
Conversion rule: Attributes not specifically targeted for conversion will be ignored/lost.
Issue: retaining ref and level information, do these map to appropriate container descriptions?
Issue: "otherlevel" levels -- <c level="otherlevel" otherlevel="SubSeries"> (Hull)
Issue: Stanford <container> conventions and mapping into a MODS "Located in" note
We will create a concise representation of the physical/logical location (as appropriate) of the materials in the context of the collection and its hierarchy. It will be a single string concatenating
- Collection name
- Intermediate series, subseries names etc if present
- The container label
- The container type + value
Is this generalizable, across Stanford collections? across institutions?
Examples:
Collection | EAD | MODS |
|---|---|---|
Gould | <c id="ref432" level="file"> | <mods:location> |
Hensen | <c id="ref50" level="item"> | <mods:location> |
Issue: Derived <mods:location> information
Where all items objects are derived from FTK information about files in a directory, how is this logial_physical locaiton information assembled and presented?
Collection | FTK | MODS |
|---|---|---|
Gould |
| <mods:location> |
...
Issue: Recursively nested <descgrp>
...