...
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 | optional | n/a |
provenanceMetadata | n/a | Defer | n/a |
technicalMetadata | n/a | 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 | fedora:hasModel=hydra:genericParent | fedora:hasModel=hydra:genericContent ... or ... |
content | n/a | n/a | For Hypatia we can use both the simple genericContent model where each child object bears a single file, or the compoundContent model where multiple content files in the child are in content01, content02, etc. |
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?
...