Jak na FITS (File Information Tool Set) - návodné video na Youtube

Na Youtube (uživatel Nick Krabbenhoeft) se objevil zajímavý návod na instalaci a použití nástroje FITS. Ten se používá na identifikaci formátů dat a obsahuje několik nástrojů (JHOVE, NZME, TIKA, file, mediainfo aj). FITS je schopen použít tyto nástroje na identifikaci a podat výsledek v jednom XML souboru. S tím se samozřejmě pojí problémy, protože různé nástroje mají mnohdy různý nebo nejednotný výstup a výsledky.
Každopádně, pokud chcete FITS vyzkoušet, vše podstatné naleznete zde https://www.youtube.com/watch?v=ZghGAmdMd18

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

Hodí se epub k dlouhodobé archivaci?

Jedním ze základních předpokladů formátu vhodného pro dlouhodobou archivaci je dostupnost kvalitních validátorů, (vedle dalších věcí jako jsou standardizace, rozšířenost, podpora SW, metadat atd. k tomu viz nedávný příspěvek na tomto blogu). V praxi nemusí být vždy jednoduché rozhodnout, co je validní  nebo nevalidní. Který soubor bychom měli pustit do dlouhodobého archivu, a který má už vlastnosti, jež ohrozí trvalou dostupnost uloženého obsahu?

Na příkladě born digital dokumentů si ukážeme, jak velkou roli mohou hrát právě validátory. Použili jsme soubor 595 dokumentů ve formátu epub z různých zdrojů, část je v českém jazyce z volných zdrojů a část je v cizích jazycích. Tento soubor jsme identifikovali DROIDem verze 6.01, signature files v 65. Pak jsme zkusili dva nejrozšířenější validátory, Epubcheck a Flightcrew v posledních verzích. S obvyklými nástroji jako je Jhove tady moc nepořídíme, Jhove označuje všechny epuby za bytestreamy a pokud je tedy nerozbalíme, a nevalidujeme jejich obsah samostatně, nemá jeho použití moc smysl.

A co jsme se dozvěděli?

Hrajeme si s DOSem, historické ovladače a SW

Honza narazil na pěknou stránku (http://www.osdos.net/download.htm) s historickým softwarem a ovladači. Některé odkazy nefungují, pak se stačí podívat na první sklizně stránky na archive.org a zkusit to tam. Pomocí různých nástrojů jako je DOSBOX (http://www.dosbox.com) nebo Virtualbox si můžete vyzkoušet emulaci v praxi.