NDK a LTP – naše požadavky a skutečnost Jan Hutař 16.12.2011
Osnova • RFI, Studie proveditelnosti, POC • přípravy zadávací dokumentace vs. finální podoba • technické problémy řešení z pohledu LTP cíl prezentace • objasnit, co nás na vyústění projektu NDK tak irituje
RFI 2008 a 2009 • po analýze trhu jsme oslovili firmy, o kt. se mezinárodně vědělo, že mají hotový LTP systém (systém na dlouhodobou ochranu dig. dat) • 1. kolo červenec 2008 (IBM, ExLibris) • 2. kolo po roce – září 2009 (IBM, Tessella, ExLibris) • u všech jsme věděli, že systémy existují a jsou někde nasazeny • v RFI byl základ našich požadavků (vycházel z NL NZ, LTP WG, Wellcome Library) • všechny firmy odpověděly formou odpovědí na naše požadavky; velmi podrobné, fundované, včetně screenshotů • z odpovědí bylo jasné, že firmy (jejich zástupci) vědí o čem mluví a co NK ČR požaduje
Příklad odpovědi ExLibris
Studie proveditelnosti 2009/2010 • 1. verze podzim 2009 – na 700 mil. Kč • 2. verze leden 2010 po krácení rozpočtu na 300 mil. Kč • prokázala, že vývoj jakékoliv funkcionality není schůdná varianta (str. 140 SP) a může ohrozit naplnění indikátorů projektu • SP měla vyrovnaný rozpočet, zahrnovala hotové komerční systémy na digitalizaci i LTP > od ledna 2010 snížení cen HW > v ZD požadován i systém zpřístupnění • peníze na odpovídající řešení máme (resp. měli jsme)
Proof of Concept 2010 • ExLibris, Tessella a IBM osloveny s požadavkem na poskytnutí systémů k testování • pouze ExLibris a Tessella souhlasily • test na našich datech, v prostředí NK ČR cíle: – zjistit podrobně vlastnosti systémů – zjistit, zda jsme schopni to vůbec provozovat; jaké role, kolik a jakých pracovníků bude k provozu potřeba – zjistit jak náročné je vložit naše archivní data – vidět naše data uvnitř systému a otestovat jej – zjistit, jaká je s firmami spolupráce (pochyby o Tesselle) – zjistit chyby a nedostatky systémů a na tyto se soustředit v ZD
Výsledky POC • oba systémy vhodné pro NDK – žádná preference • obě firmy mají odborníky na toto téma (účastní se EU výzkumu) • oba systémy jsou hotové k použití • vytvořeny java aplikace na vložení archivních dat NK do obou systémů (1 člověk za 14 dní s podporou NK ČR!) – k dispozici propracované datové modely od obou firem, školení i veškerou dokumentaci
• vylepšení ZD – obecná funkcionalita, která neupřednostňovala ani jeden systém • pochopili jsme, že vývoj LTP je holé bláznovství – pro NK nemožné
Zadávací dokumentace • vznikala od roku 2008 do února 2011 (přebráno novým vedením projektu) • novému vedení projektu odevzdána v „naší“ podobě – založena hlavně na OAIS – aby nic nešlo napadnout – založena na ZD NL NZ, Wellcome Library, Rakouského nár. archivu, Nizozemské NK a na podkladech pracovní skupiny LTP (NK člen, vedle NK Německa, Norska, Nizozemí, Švýcarska aj.)
• odevzdáno 4.2. 2011 protokolárně dr. Svobodovi – včetně • tabulek • finální ZD se od naší podoby výrazně odlišuje (subsystémy digitalizace, infrastruktura, LTP a zpřístupnění) • hlavní problém – vypadly podstatné věci z kvalifikačních předpokladů a další věci u digitalizace a infrastruktury!
ZD – co zmizelo? • tabulky – údajně nebylo možné mít tabulky s váhami a požadovat odpověď na každý požadavek… proč? postavit takto odpověď není pro firmy problém • obsah tabulek přenesen do textu k subsystémům, bez povinnosti na požadavky odpovědět, váhy zmizely • kvalifikační předpoklady – – – –
digitalizace LTP infrastruktura zpřístupnění
LTP - původní kvalif. předpoklady (25.1.2011) • Dostatečný popis systému, jeho modulů, funkcí, architektury a rozhraní a jejich použití • Mapování jejich systému na OAIS funkce a vysvětlení jak systém řeší jednotlivé OAIS procesy a funkce • Odpovědi na tabulky funkčních a nefunkčních požadavků • Dokumentace ze zátěžových testů systému • Seznam stávajících zákazníků, kteří mají celý LTP systém. • Plán vývoje funkcionalit LTP systému na další roky • Seznam výzkumných projektů v oblasti digital preservation, kterých producent LTP systému aktivně účastnil osekány právníky – proč?
LTP - původní kvalif. předpoklady – po zásahu právníků (únor 2011) • Uchazeč doloží reference o minimálně dvou implementovaných kompletních LTP systémech (jako OAIS funkční celek) ve světě. • Alespoň jedna z implementací musí být v knihovně, která ukládá v LTP zdigitalizované knihovní dokumenty. Implementace nesmí být starší než dva roky. Reference mají být ve formě testimoniálu, včetně kontaktních údajů osoby, která daný testimoniál vypracovala.
Kvalifikační předpoklady LTP – co zbylo ve finále v ZD? • předložení seznamu významných dodávek a služeb realizovaných uchazečem v posledních 3 letech s uvedením jejich rozsahu a doby plnění – ze seznamu musí vyplývat, že: • uchazeč v uvedeném období realizoval minimálně dvě významné zakázky, jejichž předmětem byla realizace digitálních archivů (nebo úložišť elektronických dokumentů, popř. archivačních systémů) včetně implementace dokumentového workflow (systému pro řízený oběh dokumentů), přičemž minimální finanční objem každé jedné takové významné zakázky nesmí činit méně než 10 mil. Kč bez DPH;
• ani slovo o kompletním LTP systému • objevilo se workflow - proč? AIP SAFE nabízí workflow, na kterém staví svou výjimečnost, akcentováno i v posudku – workflow v původních požadavcích nefigurovalo
Důsledky pro LTP a NDK I. • v nabídce firmy Logica nejsou odpovědi na všechny požadavky • odpověď na ZD obsahuje většinou pouhá konstatování o plánované funkcionalitě • velký počet bodů nabídky je doslova opsán ze zadávací dokumentace, ovšem jako odpověď – viz str. 641 nabídky o metadatech se doslova shoduje s kapitolou 2.4.4 přílohy 11 zadávací dokumentace! • nabídka nepopisuje existující systém dle OAIS, ale plánovaný • namísto LTP systému dostaneme DMS systém, do kterého se firma bude snažit vyvinout nutnou funkcionalitu pro LTP – odporuje Studii proveditelnosti – DMS systém zajišťuje oběh dokumentů a jejich uložení, obdoba spisové služby, správa dokumentů – takových systémů jsou desítky
Důsledky pro LTP a NDK II. • dostaneme systém, který NK pro archiv a digitalizaci již v roce 20022003 používala, ale neosvědčil se • nemáme dokumentaci – LTP AIP SAFE jako celek dosud neexistuje • systém, jako OAIS celek, bude k testování až v dubnu 2012! • nemáme mapování na OAIS • NK a AIP SAFE nemluví stejným jazykem – firma nemá zkušenosti s nástroji, které NK ČR požaduje v celém řešení • prováděcí projekt je obecný a v mnoha místech odporuje ZD • neznáme plány rozvoje systému AIP SAFE
Ukázky odpovědí na ZD které se shodují doslova se zadáním
Text ZD, příl. 11, kap. 2.4.4
Text nabídky firmy Logica, str. 642, kap. 5.7.4.6
ZD vs. nabídka pokračování • ZD
• nabídka firmy Logica
ZD vs. nabídka pokračování ZD
Logica
Alegorie - smartphone vs. běžný mobil • NK ČR chtěla smartphone – hotový, na trhu dostupný, kvůli funkcionalitě • dostala běžný mobil • ANO – obě zařízení telefonují, posílají smsky, ukládají kontakty a mají baterii • běžný mobil je od firmy, která je udělat umí, ale smartphony zatím nedělala • BOHUŽEL z běžného mobilu smartphone neuděláte, můžete se snažit, ale nebude to ono • ze 4 nabídek v tendru měly 3 smartphone
Co DMS AIP SAFE nyní nabízí z pohledu požadované funkcionality LTP NE - VÝVOJ ČÁSTEČNĚ NE – TM VÝVOJ
ČÁSTEČNĚ ANO
ČÁSTEČNĚ
Co nabízí ostatní systémy z nabídek? ANO ANO ANO
ANO ANO
ANO
… z toho vyplývají technické problémy • uvedeny jsou pouze hlavní • nevyplývají z nefunkčnosti AIP SAFE, ale z toho, že jako DMS je AIP SAFE určeno na něco jiného než LTP
Ukládání AIP balíčků jako ZIP • Aip safe: „stejnou funkcionalitu nabízejí i jiní dodavatelé, například SDB“ • Realita: SDB i Rosetta a většina open-sourců používá XML kontejner ve svém vnitřním formátu (ověřeno)
• SDB pracuje se ZIPem jako s formátem! (Aipsafe: AIP=ZIP, SDB: AIP=ZIP+XML)
Vstupní formáty • AIP safe: NK stačí 12 formátů • Realita: Národní úložiště – Webarchiv: stovky formátů – Povinný výtisk: desítky formátů – Data z nosičů (dnes převedeno 3000 CD, potenciálně 10 tisíc nosičů včetně audio, video atd.) desítky formátů – Digitalizace dosud - desítky typů formátů Trvalé úložiště nemůže mít limity na typy vložených formátů ani struktur dat
Verzování v AIP SAFE • pouze uložení nové verze, není možné stávající metadata pouze doplnit, vždy vzniká nová verze • po změně v AIP SAFE vzniká nová verze AIP balíčku – ne nová verze dig. objektu • AIP musí zůstat stejné, nepotřebuje novou verzi, pouze doplnění metadat a databáze • souvisí s tím, že AIP SAFE nemá vnitřní formát metadat
Vnitřní formát metadat v LTP systému • tvoří obal jakýmkoliv metadatům • zajistí konzistenci, neukládáme jednou MARCXML, jednou MODS, jednou DC – vždy jen vnitřní formát • metadata X musí být na vstupu do LTP transformována do vnitřního formátu LTP systému • AIP SAFE vnitřní formát nemá – pro DMS není potřeba, uloží vše jako objekty > při změně je nová verze • co se ale stane, pokud chceme do LTP bez vnitřního formátu vložit objekt (např. PDF), který nemá žádná metadata? jak bude vypadat v AIP SAFE archivní balík AIP? kam se uloží metadata získaná na vstupu? kam se budou ukládat údaje o procesech a změnách? • řešení AIP? SIP a AIP musí být stejné – tj. metadata z digitalizace budou ukládána tak jak jsou > specifikace metadat pro digitalizaci ale nebyla vytvářena s tím, že se použije jako vnitřní formát pro LTP > proto ji AIP SAFE kritizuje a mění
Document management pro malou/ střední firmu vs. národní úložiště - Počty dodavatelů dat: - (VISKy, krajská digitalizace) – desítky - Povinný výtisk – musíme být připraveni na tisíce
-
10 milionů digitalizovaných stran do 2011 26 milionů in-house do 2014 26 milionů z Googlu Několik stovek TB dat z Werbarchivu Desítky tisíc dokumentů od dodavatelů dat (VISKy, Kraje, nakladatelů)
- Systém musí automatizovat maximálně všechny procesy
Chráněné prostředí archivu • AIP safe: archiv = archival storage • Standardně dle OAIS - Archiv = 1) Prostor pro vkládání dat (psp, sip) 2) Prostor pro zpracování dat při ingestu 3) Pracovní prostor pro práci s archivními daty 4) Archivní úložiště Tohle celé je archiv. Data musí být zpracována uvnitř tohoto chráněného prostředí.
Chráněné prostředí archivu II Veškeré zpracování dat musí probíhat v systémech, které jsou výhradně dedikovány archivu – udržení autenticity Archivní data nemohou sdílet systémy s masovou digitalizací (editační modul, workflow) Validace formátů, migrace a editace metadat musí probíhat uvnitř archivního systému….
DMS AIP safe • Kolik implementací bylo uděláno jako zakázka na OAIS systém? • Kolik implementací používá vyžadované standardy? • Kde má AIP safe ve správě PB dat? • Jak je možné, že firma nemá zkušenosti s nástroji na validaci formátů, když tvrdí, že se dlouhodobé archivaci věnuje? • kde má AIP safe instalaci s několika sty tisíci objekty denně na vstupu, které je potřeba validovat a obohatit o metadata?
O co se hraje? 1. 2. 3. 4. 5. 6. 7. 8.
o národní úložiště digitálních dat pro síť knihoven v ČR – o metodické vedení a zkušenosti o čas – již nyní jsme mohli do hotového systému migrovat data! chce NK být „na stejné lodi“ jako západní knihovny a archivy? tj. využívat stejný systém, sdílet problémy i řešení? chceme LTP systém vyvíjet? chceme vázat lidi z NK na vývoji a specifikaci funkčnosti v situaci, kdy můžeme mít hotový systém? chceme opravdu spojovat digitalizaci a LTP v jednom systému!? chceme být pokusným králíkem a implemetovat LTP systém, který není jako celek implementován v žádné instituci? opravdu chceme za peníze NK /EU vyvíjet firmě komerční systém? dostaneme od AIP SAFE v dubnu 2012 požadovanou funkcionalitu? ve stejné kvalitě jako ji mají hotové systémy?
Závěrem • doufám, že nyní chápete naše zklamání • jak je možné, že vyhrála takováto nabídka? • proč nebyl text tendru až do 12.12.2011 veřejný? • proč nebyla do stejného data veřejná studie proveditelnosti? • viz Národní archiv a jeho tendr
