V roce 2001 zhodnotila česká Rada pro katalogizační politiku perspektivy dalšího vývoje formátů UNIMARC a MARC21 a dospěla k doporučení přejít výhledově na formát MARC21 – zdůvodnění viz Zápis z jednání Rady pro katalogizační politiku k formátům UNIMARC a MARC21. Od té doby začalo MARC21 používat několik knihoven, např. VŠE nebo MU v Brně, které spojily přechod na nový automatizovaný systém s novým formátem – tyto knihovny však přecházely ze systému T-Series (dříve Tinlib), nekonvertovaly záznamy z formátu UNIMARC. Pro konverzi z UNIMARCu musel být napřed připraven konverzní program, který ve spolupráci s Národní knihovnou zpracoval programátor Ústavu výpočetní techniky UK. První knihovny, které se do ostré konverze pustily, byly Národní knihovna, Moravská zemská knihovna a Vědecká knihovna v Olomouci. Ve všech knihovnách proběhla konverze úspěšně, i když se určité problémy či chyby samozřejmě objevily.

Jedním z Murphyho zákonů je, že každá změna je k horšímu. I kdyby nebyla, určitě se to alespoň z počátku zdá. Je těžké srovnávat, v čem je MARC21 horší a v čem lepší než UNIMARC. Faktem je, že MARC21 má pravděpodobně lepší perspektivy dalšího rozšíření a rozvoje. Zároveň je nepopiratelnou skutečností, že UNIMARC je strukturovanější formát a že konverze z formátu MARC21 do UNIMARCu bude vždy ztrátová. Doporučení katalogizační rady bylo v české knihovnické komunitě přijato prakticky bez námitek - výjimkou byla letošní diskuse v konferenci Knihovna, která však přišla trochu "s křížkem po funuse". Proto zřejmě konverze čeká dříve či později všechny naše knihovny. Tímto článkem bych se chtěla podělit o naše zkušenosti s těmi, kteří mají konverzi teprve před sebou, a upozornit na některé rysy nového formátu, které mohou způsobit problémy. Jde o pohled systémového knihovníka knihovny s řadou různých bází a velkým množstvím záznamů – v menší knihovně bude situace jistě jednodušší.

Jak probíhala konverze a přípravy na ni v Národní knihovně

Začátkem roku jsme si sestavili harmonogram úkolů a naplánovali i postup vlastní konverze dat. S dalšími dvěma velkými "alephovskými" knihovnami, MZK a VKOL, jsme se dohodli, že konverzi provedeme zároveň, aby nám rozdílné formáty neznemožnily již poměrně dobře fungující spolupráci v oblasti autorit a přejímání záznamů. Konverze hlavní báze NKC (online katalog) musela s ohledem na uživatele proběhnout v období uzavření knihovny, a protože naše bibliografické báze jsou navázány na bázi autorit, bylo nutné zkonvertovat všechny báze v co nejkratším časovém intervalu. Situaci navíc zkomplikovaly dvě věci: většina knihoven zapojených do kooperačního systému národních autorit zatím na MARC21 nepřechází a souborný katalog, báze SKC, rovněž napojený na autoritní bázi, zůstává také až do konce roku ve formátu UNIMARC.

Základní podmínkou úspěšné konverze byly konverzní programy, resp. správné formulace pravidel, podle nichž se měly záznamy konvertovat. Základ univerzální verze pro konverzi bibliografických záznamů sice byl hotov již dříve, avšak teprve při testování na zvlášť složitých či chybových záznamech se objevovaly drobné chyby. Navíc bylo nutno do konverze zapracovat i odchylky od čistého UNIMARCu, které se používaly v různých bázích Národní knihovny, včetně národních polí bloku 9XX, z nichž některé při převodu do formátu MARC21 nezůstaly beze změny. Bylo třeba zpracovat pravidla pro autority, důležitá byla i pravidla pro kontrolní programy, které odhalily chyby ve stávajících záznamech. Opravy chyb byly nezbytností, protože konverzní program podpole, která v konkrétním poli nemá definované, zahodí, a tak by při konverzi chybových záznamů mohlo dojít ke ztrátě dat. (Některé chyby dokonce způsobovaly kolaps konverzního programu.) Dolaďování a testování kontrolních a konverzních programů, pořizování výstupů pro opravy chyb, individuální opravy chyb a globální opravy chyb podle požadavků knihovníků byly časově dost náročnou součástí přípravy konverze, která zaměstnala specialisty na marcové formáty spolupracující s programátorem, systémové knihovníky i katalogizátory. (Knihovny, které přistoupí ke konverzi později, by měly mít tuto fázi snazší – v programu i pravidlech již budou snad všechny chyby "vychytané". Základní verze konverzního programu, která neobsahuje možnost modifikace pravidel, je pro české knihovny k dispozici zdarma.)

Ačkoli systém Aleph bez problémů pracuje s formáty UNIMARC i MARC21 a náš český distributor (Ústav výpočetní techniky UK) dodal i lokalizovanou českou verzi definičních tabulek pro MARC21, mnohé z tabulek nevyhovovaly zcela potřebám jednotlivých bází. Konverze se týkala bází NKC, SLK, ANL, KKL, STT, WEB a AUT - každá z těchto bází používá trochu jiný sortiment polí (včetně národních polí bloku 9XX a písmenných polí), jiné přístupové soubory, jiné zobrazovací formáty a šablony. To všechno museli systémoví knihovníci upravit. Nezbytné byly i úpravy části externích programů pro tisky, exporty a importy a úpravy nástrojů ulehčujících práci katalogizátorů ("makra" na funkční klávesy). Pracovníci z útvaru zpracování fondů neboli katalogizace měli také plné ruce práce: kromě toho, že se museli důkladně seznámit s novým formátem, mnozí z nich navíc spolupracovali na zadáních pro definiční soubory, připravovali metodické pokyny a školili ostatní (nejen pracovníky z Národní knihovny, ale i katalogizátory z dalších knihoven).

Akce konverze v NK začala 28. června 2004 exportem báze SLK. V dalších dnech jsme exportovali, konvertovali a importovali zpět bázi autorit a menší báze KKL, STT a WEB, následovala ANL. V každé z bází bylo nutno po importu vytvořit přístupové soubory, další pomocné oraclovské tabulky a vazby do autorit, což pro větší báze trvalo několik hodin. Po letních svátcích přišla na řadu báze NKC. 12. července byly opět přístupné všechny báze v nové podobě, formátu MARC21. Konverzí prošlo celkem více než 2,5 milionu záznamů.

Vlastní konverze dat, tj. převod z formátu do formátu pomocí konverzního programu, proběhla díky předchozímu otestování, kdy se vychytaly a opravily vadné záznamy, které by konvertor nedokázal zpracovat, bez problémů. Různé zádrhele se vyskytly, jak už to bývá, tam, kde jsme je vůbec nečekali. Po konverzi se sice samozřejmě našly nějaké chybně zkonvertované údaje, ale na to, jak neuvěřitelně složitá byla pravidla pro konverzní program, která se prakticky do poslední chvíle upravovala na míru jednotlivým bázím, je to chybovost zanedbatelná. Chyby nyní postupně v bázích opravujeme.

Poměrně hodně práce nám dala konverze báze autorit a věci s ní spojené. Jednak bylo celkově na přípravu pravidel konverzního programu méně času, jednak se musela zajistit řada dalších věcí spojených s kooperací a souborným katalogem. Pro bázi SKC jsme vazbu do autorit vyřešili kopií autoritní báze se záznamy v UNIMARCu (CZE10), která se bude aktualizovat podle změn v živé autoritní bázi zpětně konvertovanými záznamy. Souborný katalog plánujeme zkonvertovat do MARC21 koncem roku – od příštího roku by měly být funkční i nové importní a deduplikační mechanismy, které budou postaveny již na základě nového formátu.

Knihovnám, které zůstaly u formátu UNIMARC a bázi autorit využívají pomocí protokolu Z39.50, jsme nabídli možnost stahovat záznamy přímo z "živé" báze ve formátu UNIMARC: nadefinovali jsme pro ně virtuální bázi AUT15, která vrací pro Z39.50 klienta záznamy z AUT10 zkonvertované do UNIMARCu on-the-fly. Na "bandasce" je pro změnu zabudovaná konverze UNIMARC->MARC21, takže ani knihovnám do báze autorit přispívajícím přes Z39.50 se situace nekomplikuje. A protože se ukázalo, že tyto i další knihovny také hojně využívaly protokol Z39.50 ke stahování bibliografických záznamů z NKC a chtěly by záznamy v UNIMARCu i nadále, nabídli jsme jim pro tento účel obdobnou možnost jako u autorit – virtuální bázi NKC05. To, že máme díky ÚVT nástroje nejen pro dávkové konverze, ale i pro konverzi on-the-fly, která se používá i na JIB, usnadní našim knihovnám bez problémů přežít mezidobí, kdy budou v Česku koexistovat dva formáty. Pokud jde o JIB, stačí požádat o definici speciálního profilu pro databáze, jejichž záznamy jsou v odlišném formátu, a zabudovaný konvertor vrátí záznamy tak, aby je mohl domácí systém zpracovat. Konverzní programy MARC21->UNIMARC (pro autoritní i bibliografické záznamy) se ještě dolaďují, ale je nutno počítat s tím, že tato konverze bude vždycky "se ztrátou kytičky".

Co nám konverze do MARC21 přinesla

Již první seznámení s novým formátem ukázalo, že přechod na MARC21 přinese knihovníkům dost radikální změnu katalogizační praxe. Je jisté, že než se s novým formátem "skamarádí", značně se zpomalí zpracování záznamů a vzroste jejich chybovost. Po letech "soužití" s UNIMARCem si budou muset katalogizátoři zvyknout nejen na jiné kódy polí a podpolí pro téměř všechny údaje, které do báze ukládají, ale i na jinou strukturovanost záznamů a také na nutnost ukládat přímo do dat interpunkci ISBD, kterou za ně dosud doplňoval (i když ne vždy úplně korektně) systém. Z pohledu systémového knihovníka je vnořená interpunkce pozitivem – formátování záznamů podle ISBD v UNIMARCu bylo náročné, ve složitějších případech téměř nemožné, pěkně nevypadaly při veškeré snaze rejstříky předmětových hesel obsahující nejrůznější druhy údajů. Ostatní rysy nového formátu však spíše budou komplikovat práci všem.

Abych už od počátku nekritizovala jenom MARC21. Skutečně nepochopím, co vedlo kdysi tvůrce UNIMARCu k tomu, že i v případech, kde struktura pole zůstala stejná, použili oproti USMARC, jímž se inspirovali a jenž byl předchůdcem dnešního MARC21, jiné číslování polí a podpolí – snaha odlišit se za každou cenu a zkomplikovat konverze? Ale na nové kódy si katalogizátor zvykne, zvlášť když mu systém nabídne nápovědu. S interpunkcí je to horší - hrozí zde riziko větší chybovosti, protože systém většinou může kontrolovat povolená pole a podpole, případně jejich závislosti či konkrétní obsah, ale již nikoli ukládané interpunkční znaky, zvlášť jestliže se mění v závislosti na následujícím podpoli. Další nepříjemností vnořené interpunkce je nemožnost zjednodušeného formátování – jestliže bychom chtěli pro stručný formát některá podpole vypustit, je téměř jisté, že záznam bude mít nepatřičnou interpunkci. Řešení v použití formátu MARC21 bez interpunkce, kterou by doplňoval systém, jak se o tom uvažovalo v diskusích v elektronické konferenci, ale rozhodně nevidím. Pokud bychom se měli od formátu MARC21 odchylovat víc, než je nezbytně nutné (a činíme tak jen přidáváním polí či podpolí, nikoli jejich jiným použitím), pak bychom tu měli zase CZ-MARC s nutností konverze – to už jsme mohli rovnou zůstat v UNIMARCu, pro nějž máme poměrně dokonalý konvertor. S interpunkcí je tedy nutno se smířit.

Za závažnější problém formátu MARC21 považuji jeho menší strukturovanost, a to nejen pro zpětnou konverzi. Některé údaje se při konverzi do MARC21 "slily" do jednoho podpole tak, že to značně komplikuje posílání konkrétních údajů do přístupových souborů pro vyhledávání. Jsou zde možná tři řešení: ukládat vybraný údaj do zvláštního pole separátně znovu, generovat z části obsahu podpole jiné fyzické či virtuální pole speciálním programem (pokud to systém umožňuje anebo nabízí možnost doprogramování), nebo konečně na možnost separátního vyhledávání rezignovat. Zatím jsme narazili na problém u těchto polí:

• 245 - název části či název dalšího díla nelze vyčlenit ze „směsových“ podpolí 245b či 245c – pokud chceme podle těchto údajů vyhledávat, je třeba je ukládat navíc do pole 246
  
• 020 – ISBN se nachází v jednom podpoli s doplňujícími údaji, např. "(brož.)" – pokud není v samostatném poli či podpoli, nelze kontrolovat systémem na jedinečnost ani spolehlivě vyhledávat v jiných bázích za účelem stahování záznamů, protože forma zápisu nemusí být jednotná (pro potřeby alephovských knihoven by to měl vyřešit speciální program na virtuální pole)
  
• 008 – země vydání a jazyk vydání nejsou v samostatném podpoli, ale jsou součástí řetězce kódovaných údajů

Jednou z věcí, pro niž se nám při zběžném pohledu zdál MARC21 "přívětivějším" formátem než UNIMARC, byla jednodušší struktura vazebních polí - komplikovaná pole bloku 4XX v UNIMARCu bylo obtížné nejen ukládat, ale také formátovat pro zobrazení nebo z nich separovat údaje pro rejstříky (alespoň v Alephu). Ukázalo se však bohužel, že nutnost dvojího ukládání údajů nám MARC21 ve všech případech nevyřešil. Struktura propojovacích polí a vnořená interpunkce u pole 700-autor-název neodpovídá struktuře odpovídajících polí autorských údajů, takže není možno tyto údaje posílat do autorských rejstříků s vazbou do autorit.

Můžeme tedy vidět v přechodu na MARC21 nějaká pozitiva? Jistěže budou, jen nejsou tak viditelná jako negativa; a vidí je spíše ti, kteří mají více času sledovat vývoj v knihovnické oblasti než systémový knihovník, ponořený hlavně do současných problémů Alephu, autorit a souborného katalogu. (Věřím, že můj článek nebude k této tematice poslední.) Jak zaznělo v diskusích v elektronické konferenci Knihovna, jak UNIMARC, tak MARC21 jsou "dinosauři" a budoucnost patří úplně jiným strukturám záznamů, jen to nejspíš bude ještě nějaký čas trvat, než se zpracují a prosadí. Protože lepší zázemí pro další vývoj i větší rozšíření má MARC21, iniciativy se nejspíš budou odvíjet od tohoto formátu. Otázkou, teď už čistě akademickou, je, jestli jsme nemohli počkat na ten nový modernější formát, když směnitelnost našich záznamů i možnost stahování z cizích bází používajících MARC21 nám poměrně dokonalý konvertor vytvořený v ÚVT umožňuje již nejen dávkově, ale i v reálném čase. Investice do konvertoru, kontrolních programů ani do oprav dat však rozhodně zbytečné nebyly. Kdyby tu nebyl pevně stanovený termín reálné konverze, pravděpodobně bychom ještě tak dobrý konvertor v praktickém použití neměli. Nebýt konverze, také bychom nikdy v našich bázích neudělali tak důkladné čistky. Pokud se nám, jak pevně věřím, neztratily při konverzi v záznamech nějaké důležité údaje, ani tento vedlejší produkt konverze není zanedbatelný.