...
Datastream | Set | Item | Child of atomistic object |
|---|---|---|---|
identityMetadata | Has <objectType>set</objectType> | Has <objectType>item</objectType> | Minimal, to record objectType objectLabel and uuid |
descMetadata | EAD to MODS mapping, with <mods:typeOfResource collection="yes"/> | EAD to MODS mapping | n/a |
sourceMetadata | n/a | if supplied as part of creating the object to meet repository preservation requirements for separately recording information about the source media | n/a |
provenanceMetadata | n/a | None for now; what history is to be captured as provenance is a later workflow/preservation consideration | n/a |
technicalMetadata | n/a | None for now Defer; part of object creation, validation and preservation workflows. | possible during object assembly until integrated into parent item record; not part of final Hypatia objects |
contentMetadata | n/a; "content" is defined by the set's membership | Using Stanford schema | possible during object assembly until integrated into parent item record; not part of final Hypatia objects |
rightsMetadata | Public template | Public template | n/a |
RELS-EXT | hydra:hasModel=implicitSet | hydra:hasModel=genericParent | hydra:hasModel=genericContent ... or ... |
Issues
A few Stanford-centric features may not be of relevance ot of interest to other Hypatia partners. What accommodation, if any, is needed for Stanford vs generic software?
- Stanford identityMetadata datastream
- Stanford-specific extensions to contentMetadata, e.g., shelve, publish and preserve directives
- Stanford has all content in its externally managed "Digital Stacks"
- Child objects have no content datastreams (and in some cases may be obviated)
- contentMetadata <location> URLs will point to stacks delivery services
identityMetadata
Stanford-specific. Will appear in Stanford produced fixtures and demo objects; not required otherwise.
...