...
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, that is to say, Hypatia fully embraces the atomistic model, separating the parent metadata-bearing object from child content-bearing object(s), even in cases off single-file content. This is not a given across Hydra in general, but a simplifying assumption for early Hypatia. | 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. |
...