Suggested Architecture, a work in progres

Tasks to solve

• Ingest into the archive
• Automatic QA of a batch (valid data and metadata)
• Manuel QA of a batch
• Creation of preservation metadata
• Creation of dissemination copy
  

Principles

• Early Ingest
• QA, preservation- and dissemination tasks take place in the archive
• Autonomous components, rather than a fancy workflow
• Automatic QA should be runnable by Ninestars

Elements of the Solution

Existing Elements

• Bit repository
• DOMS
• Hadoop platform
• DOMS GUI

New Elements

• Presentationinterface for pages (Prototype from Toke)
• Early Ingest-platform
• Platform for validation of metadata in DOMS
• Extraction of Files/metadata for manual QA

Autonomous Components

Overall Description

An autonomous component is watching the system, and discovers work to be done

Suggested solution:

• The Component performs a query to discover tasks to do
• The query is to a Summa index of the DOMS
• If there are tasks to do, a task is started
• The component is responsible for making sure that it does not start a task it has already started. This can safely be done in memory.
• The result of the task is written back to the Batch object in DOMS as metadata
• Information about the execution of the taks is written back to DOMS as preservation metadata. Probably as a Premis Event.
• Event data and the like is harvested frequently by Summa for indexing, and thus form the input for other autonomous components 

Ingest into the Archive

Overall description:

Given a batch, put all jp2-files in the bitrepository, and all xml-files (including ALTO) into DOMS

Suggested solution:

• Hotfolder is watched for new batches
• All files with the extension *.jp2 is put into the bit repository (.md5-files are used for fixitychecks). The solution should be configurable to support other extensions
• All other files are put into DOMS
• The directory structure is preserved in the bitrepository File ID
• The directory structure is preserved in DOMS by having one object per directory, one datastream per file. The directory names are preserved in the object lables, the filenames in the datastream labels

Surveilance interface

Overall description:

A graphical web interface to show the current state for each batch

 Suggested solution:

• Each batch is represented as a row in a table
• Each column represents an autonomous component, and the cell shows if this component have completed it's work on the batch
• Each cell in the table is a simple lamp, that shows if the taks have been completed. Pressing the lamp will fetch more information.
• The web interface integrates with MF PAK to get states from batches before and after digitisation
• This interface could possibly be used to approve or reject a batch

Bitarkivet og bånd

Overordnet beskrivelse:

Filer skal gemmes i bitarkivet på ten ben, et nearline og et offline. Begge de involverede ben vil have en anseelig mændge cache, men vil være tape-backed.

Foreslået løsning:

• Filerne lægges på de to ben ved modtagelse,
• Filer i cache vil blive rullet på bånd når et bestemt, men pt. udefineret (tidsbestemt, eller eksplicit ved godkendelse af batch), signal sendes.
• Filer fra batches der fejler validering vil blive slettet igen.
• Vi antager at vi kan validere og afvise et batch før det bliver nødvendigt at rulle det på bånd, men i værste fald er der spildt noget plads på båndet
• Nøglerne der giver adgang til at slette fra bitmagasinet skal eksplicit skaffes hvis der skal fjernes et ekstra batch. Som udgangspunkt kan nøglerne også slette allerede godkendte batches.

Opgaver på data (jp2-filer)

Overordnet beskrivelse:

Alle operationer på data køres som hadoop-jobs på filer i bitmagasinet. Herunder karakterisering og generering af formidlingskopier.

Foreslået løsning:

• jpylizer køres i map-skridt af map/reduce-job. Resultatet lægges i DOMS (som datastream) i reduce-skridt.
• Udtræk af histogram køres i map-skridt af map/reduce-job. Resultatet lægges i DOMS i reduce-skridt.
• Generering af formidlingskopi køres i map-skridt af map/reduce-job. Filen skrives direkte til formidlingsstorage. Eventuelle fejl skrives tilbage til DOMS i reduce-skridt.
• Der laves ingen validering i map/reduce-job. Dette foretages som efterbehandling af metadata.

Validering af metadata (i DOMS)

Overordnet beskrivelse:

Alle jobs der validerer metadata opfattes som jobs på et helt batch. Metadatavalidering kan være lokalt for én xml-fil eller kræve kendskab til sammenhæng mellem flere xml-filer i et batch - f.eks. validering af samme batchnummer i alt metadata eller validering af fortløbende sidenumre

Foreslået løsning:

• Validering implementeres som gennemløb af en træstruktur (svarende til filstruktur-hierarki), med mulighed for validering i hver knude
• Validering af en enkelt XML-fil kan foretages med XML-schema og schematron
• Træet kan gennemløbes med et filsystem eller DOMS som nederste niveau
• Resultatet af en validering skrives tilbage til DOMS
• En fejlet validering skal medføre en notifikation til Supervisor
• Hellere små autonome skridt end ét stort workflow

Manuel QA

Overordnet beskrivelse:

Der skal foretages manuel QA på filer og metadata udvalgt efter statistisk princip. Derudover skal der evt. foretages manuel QA på filer vi kan identificere som mistænkelige (f.eks. et helt mørkt batch). Manuel QA kræver adgang til et system til at inspicere jp2-filer og metadata. Vi fravælger i første omgang at lave et egentligt workflowstyringsprogram.

Foreslået løsning:

• Der etableres en fremvisningsløsning til avissider i bitmagasinet. Toke har lavet en første udgave.
• Der etableres mulighed for direkte links til objekter i DOMS GUI.
• Der udtrækkes hvilke sider der skal checkes udfra den statistiske visning.
• Ud fra dette udtræk laves et regneark (csv-fil) med link til fremvisning og DOMS GUI.
• Til dette ark tilføjes mistænkelige objekter med tilsvarende links og en begrundelse for hvorfor de er mistænkelige
• Vi laver ingen support af hvordan regnearkene benyttes til at godkende batches

Fejlede batches

Overordnet beskrivelse:

Batches fejles eller godkendes som et hele. Man kan ikke afvise dele af et batch, og leverandøren vil aflevere et nyt batch.

Foreslået løsning

• Hvis et batch fejler, skal hele batches slettes fra Bitarkivet
• Slette fra bitmagasinet involverer anskaffelse af slette nøglen
• Hvis et batch fejler, skal hele batches slettes fra DOMS
• Doms kan slette uden en bestemt slette nøgle, da alt bliver bevaret alligevel, og kan genskabes.
• Et genafleveret batch skal behandles på samme måde som et nyt batch