...
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 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 | Defer for now; what history is to be captured as provenance is a later workflow/preservation consideration | 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 | hydrafedora:hasModel=hydra:genericParent | hydrafedora:hasModel=hydra:genericContent ... or ... |
...
Per Hypatia EAD conversion analysis
sourceMetadata
This may be supplied as part of creating the object to meet repository preservation requirements for separately recording information about the source media. Stanford is eamining the Xanadu and Gould output for information that might be placed here.
provenanceMetadata
What history is to be captured as provenance to complete the full ingest story for a repository is a workflow/preservation consideration, not applicable to the first round of shared Hypatia demo objects.
technicalMetadata
The digitization of the artifacts carrying born digital materials produces one or more collateral files that describe the physical media and their contents. It is tempting (and not incorrect) to consider these files are forms of technical metadata. But similar to the way photos of a hard drive or diskette label might be considered metadata yet are treated as content to be delivered to the user, we believe bit-images and content analysis files such as those produced by the Forensics Toolkit (FTK) are in the realm of user-delivered content, to be shared as part of the understanding of the digital object. The technicalMetadata stream serves a slightly different purpose. Here is where we would place repository workflow output relevant to the characterization and validation of content files. For example, in technicalMetadata there might be JHOVE or similar output concerning the .jpg, .dd and .txt or .xml files associated with the object.
contentMetadata
See references to Stanford schema and Hull's version at the Hydra content models page. Sample contentMetadata XML is also online as part of the description of the Xanadu EAD and Hypatia fixture objects .
rightsMetadata
First round has publicly accessible objects only, using the following rightsMetadata:
Panel |
---|
<rightsMetadata> |
RELS-EXT
Example (incomplete):
Panel |
---|
<rdf:RDF xmlns:fedora-model="info:fedora/fedora-system:def/model#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rel="info:fedora/fedora-system:def/relations-external#" xmlns:hydra="http://projecthydra.org/ns/relations#"> |