Analysis of Meta Data Content

When addressing this task, we should consult the following TDR requirements:

• Collection specific requirements we should consider to some degree in DOMS B1.3, B1.4, B1.6, B2.3, C2.1, R72
• Proper reporting required from ingest module, ensure only complete objects are ingested and reported ok, report indicates preservation status B1.7, B1.8, B1.9, R48-49, R63
• Preserve existing PIDs in metadata: B2.5
• Must be possible to document properties we will preserve for all digital material B1.1, B3.5
• Sufficient metadata about digital objects required: Technical, administrative and preservational as well as descriptive, generated or analyzed to be correct, fail on errors: B.1.5, B1.8, B.3.4, B3.6, B4.1, R11, R54, R62
• Standard permanent UIDs needed, accessible from the rest of world: B2.4, R64
• Must be possible to document copyrights and restrictions on all digital material in a format that it is possible to act on/Require enforced access rights A5.3, B.5.1, C3.3, C3.4, D3.2, D3.3, R15-17, R18?, R36, R52, R76
• Referential integrity required between file storage and metadata (creation and validation): B4.2, B4.3, D1.5, D1.6, R64, R69
• Audit trail required: B3.8, B3.11, D1.6, R70

See TaskC.1AnalysisDocumentDetails#CollSpec

See TaskC.1AnalysisDocumentDetails#ReportingFromIngestModule

See TaskC.1AnalysisDocumentDetails#PreservePIDs

See TaskC.1AnalysisDocumentDetails#PreservationProperties

See TaskC.1AnalysisDocumentDetails#Metadata

See TaskC.1AnalysisDocumentDetails#PUID

See TaskC.1AnalysisDocumentDetails#Rights

See TaskC.1AnalysisDocumentDetails#ReferentialIntegrity

See TaskC.1AnalysisDocumentDetails#AuditTrail

TODO

ActionDataModelTDRRequirements has produced the following TODO list:

• Define alternative PIDs in contentModel_DOMS (B2.5. If unique identifiers are associated with SIPS before ingest, they are preserved in a way that maintains a persistent association with the resultant AIP).

• ContentModel_???PreservationFile should specify the properties that are preserved. Question: can these properties vary between collections. If so, what are the consequences? Different preservation content models for the same format? (B1.1. Repository identifies properties it will preserve for each class of digital object. )

• What is the exact content of the Premis Datastream (ORIGIN), e.g. after a migration?
• We need a clear definition of the interactions between states of objects in Fedora and files in Bitstorage, such that no files or objects end in 'limbo states'. Question: does our use of states in the objects hold a risk of loosing reference to files in bitstorage? (B1.8. Repository can demonstrate that all SIPs are either accepted as whole or part of an eventual AIP, or otherwise disposed of in a recorded fashion)
• What is the output and the format of the output of characterization and validation?

Prerequisites and Assumptions

The estimation of this task is based on these notes, which also should be taken into consideration when implementing the task:

BAM: Men jeg ved stadig ikke med Sprog og rettigheder...

TE: Det er noget vi skændes meget om

TSH: Base typer, access kontrol.

MKE: (Nepomuk mail) faktisk beskrivelse af onto (iterativt udvidet)

KFC: Iterativ udviklingsproces, slutprodukt adresserer det hele.