Page History

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
or FTK 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:commonMetadata

hydra:isGovernedBy relationship to an Admin Policy object
fedora:isMemberOf relationship to any immediate aggregate set of which this object is a member
fedora:isMemberOfCollection relationship to top "collection" set

fedora:hasModel=hydra:genericContent ... or ...

isPartOf relationship to parent item

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.

Where the content file is an image, the staticImage model may be appropriate.