Archivematica - co je potřeba upravit pro reálný provoz?

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. 

Zkusil jsem do demo Archivematiky ingestovat klasický hybrid - OCR TXT, který obsahuje HTML tagy.

• 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..)

Podobných hybridů je, především pokud jde o pdf, kolem poměrně dost. Archivematika není schopná s takovými soubory  "spolehlivě" pracovat, protože příliš spoléhá na Droid/Fido, které ale samy o sobě nejsou dokonalé - a pak chybně aplikuje další kroky - extrakci techMD (characterize), normalizaci.

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).

V tomhle totálním bordelu se o souboru dozvím, že to je "možná fmt/96 možná unkwnon binary nebo plain text, octet stream nebo formát UTF-8" ale v celém AIP METS xml není x-fmt/111 což ten soubor skutečně je....:-) Možná si tvůrčí Archviematiky myslí, že pořádek je pro blbce, otázka je, jestli to je přístup, jakým by mělo být ingestovano (protože o nic jiného než o ingest v Archivematice zatím nejde) větší množství dat. Podle mého názoru nikoli, bez úprav služeb by to do provozu jít někde nemělo...