##Analysis Documentation ## Headline such as "Analysis of Backup Requirements" = Analysis of Meta Data Content = ## Add detailed explanation/analysis of the task(problem)/action. ## This may include use-case diagrams etc. attached like this: ## attachment:MyUseCase.png 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 == ## Describe any prerequisites and assumptions that are important for this analysis, e.g.: ## What can we rely on? ## Which assumptions must hold in order to solve the problem described in this document? 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. ##== Risks and Potential Problems == ## Describe anything that may cause problems when solving this task. ##== Stakeholders == ## List of links to any relevant stakeholders. That is, people who has knowledge about this task or in any other way are relevant to contact for input. ##||Stakeholder ||Knowledge|| ##||["Link to stakeholder"] ||Usability expert. || ##||["Link to Bart Ender"] ||Expert on mixing margaritas || ##||["Link to out esteemed customer"] ||The guy with the money who actually may know what he wants. || ##== Resources == ## List links to documents, wiki pages etc. that are relevant to this analysis. ## * [:LinkToMyRessource:Use case diagram xx] ## * [:LinkToMyVersionControlledDocument:Link to document on user studies e.g. stored in SVN]