Hybridní soubor jako příklad
Na příkladu ingestu hybridního souboru zde ukážu, čemu je třeba se věnovat, pokud by někdo chtěl používat systém Archivematica v provozu.
- Droid/Fido ho chybně identifikují jako html - fmt/96
- Archivematika ani nemrkne, a uloží to jako html soubor
- Administrátor se nic nedozví o tom, že vložil soubor s koncovkou txt, který systém identifikuje a validuje jako html
- Administrátor nemá žádnou možnost jak tohle v systému vyřešit (měl by se dozvědět, že s tím souborem není něco v pořadu a měl by mít nástroje jak to řešit, tak aby soubor skončil v archivu správně validovaný jako txt..)
Jaké úpravy mikroslužeb zvážit?
Pro reálný provoz by to minimálně chtělo modifikovat mikroslužbu identify, tak aby workflow kváklo, pokud koncovka (nebo i mime type) nesedí s tím, co zjistí Droid nebo Fido....
Ideálně by byly potřeba další výraznější úpravy mikroslužeb, tak aby administrátor mohl podobné situace vyřešit pro tento jeden konkretní soubor případně i pro všechny další přicházející se stejnou chybou v budoucnu....
Služby tvořící transfer a ingest (hlavně characterize a validate) by měly vědět:
- s jakými vlastnostmi deklarovanými v metadatech třeba v SIP METS objekt přišel (např. v METS SIP může být mime type, originál file name, někdy i PUUID - viz standard NDK)
- s jakou koncovkou a mime typem objekt přišel (v těle souboru)
- co zjistil Droid/Fido v identify v předešlém kroku - a měly by si všimnout, pokud to nesedí s tím, co ví ony
- služba normalize by měla před aplikací normalizace také provádět nějaké kontroly...
Optimalizace AIP METS
V AIP METS Archivematiky jsou rozporné informace. Archivematice to možná nevadí:-), ale mě, pokud bych měl s takovými daty pracovat, by to asi dost vadilo. Bez rozumné úpravy je informace v METS AIP matoucí, a bylo by dobré předělat služby characterize a create AIP metadata, tak aby dávaly do AIP XML METS jen smysluplné výsledky.
V tomhle jednom triviálním příkladě je v AIP METS:
- v premis object FormatregistryKey atd - formát fmt/96
- premis object Charecteristics - výstup z FITS - identify výstup apache tika - unkwnon binary (další blbost - proč apache tiká tady?), vedle toho pak unix file (korektně plain text), NZME (extrakce tecMD - lenght, jinak nic moc), OIS FIle info (size, name, last modified), ffident (nesmysl), tika z znovu text/html, utf-8, jhove (jediný smysluplný výstup).