Úvod

Dříve něž se začneme zabývat otázkou kam kráčí CASLIN – Souborný katalog ČR, podívejme se odkud vyšel. Rozběh elektronického národního souborného katalogu byl jedním z konkrétních výsledků projektu CASLIN. V rámci realizace projektu CASLIN byly odstartovány všechny důležité aktivity související s fungováním národního souborného katalogu. Kromě jasně vymezené a podrobné koncepce souborného katalogu (model fungování souborného katalogu, sběr a správa dat, kategorizace uživatelů, apod.), byly stanoveny základní standardy a určen správce souborného katalogu.

V současné době je již všeobecně známo, že základním kritériem aktivní spolupráce účastníků CASLIN - Souborného katalogu ČR je povinnost respektovat stanovené standardy zpracování záznamů:

• primárním výměnným formátem je UNIMARC, sekundárním je Výměnný formát

Z hlediska kvality souborného katalogu je jistě velmi významná skutečnost, že na samém počátku sběru dat byla stanovena jednotná instrukce, která specifikovala strukturu a obsah záznamu pro souborný katalog. V září 1994 byl vydán návrh instrukce Záznam pro souborný katalog, na jejímž základě v lednu 1995 správce zahájil první kontakty s knihovnami, které projevily zájem přispívat svými záznamy do souborného katalogu. V červnu 1995 byly do souborného katalogu importovány první záznamy zahraničních monografií a do konce roku 1995 bylo importováno celkem 25.000 záznamů osmi knihoven. Ověřovací provoz souborného katalogu, kdy byly přijímány záznamy pouze zahraničních monografií bez možnosti kontroly duplicit, probíhal od 1.1.1996 do 31.1.1997, na konci ověřovacího provozu souborný katalog obsahoval téměř 44.000 záznamů čtrnácti účastníků. V květnu1996 vydala Národní knihovna ČR schválenou instrukci Záznam pro souborný katalog: UNIMARC. Tištěné monografie (diskuse nad návrhem instrukce trvala téměř dva roky, což svědčí o obtížnosti vytvoření takové instrukce pro souborný katalog). V lednu 1997 bylo dokončeno testování programu na kontrolu duplicit pro souborný katalog a všechny záznamy do té doby dodané do souborného katalogu byly porovnány na duplicitu. K 1.2.1997 zahájil souborný katalog příjem záznamů nejen zahraničních, ale také českých tištěných monografií a zahájil tak svůj rutinní provoz. Na konci roku 1997 souborný katalog obsahoval téměř 65.000 záznamů (z toho 1.780 duplicitních) devatenácti českých a moravských knihoven. Kvantitativní údaje naplňování souborného katalogu v letech 1995 – 1998 ukazuje graf a tabulka v Příloze 1. 2. Zpracování dat pro souborný katalog v systému ALEPH Již v prvních koncepčních materiálech souborného katalogu CASLIN je konstatováno, že “cílovým principem budování souborného katalogu CASLIN je sdílená katalogizace on-line.” V poslední době bylo při různých příležitostech konstatováno, že právě zajištění sdílené katalogizace pro knihovny v ČR je hlavním důvodem změny systému pro souborný katalog. Mnohem méně se však hovořilo o tom, že vývoj vlastních aplikací pro provoz a správu souborného katalogu v systému ORACLE jepro správce nezbytné z důvodu zásadní racionalizace zpracování a celkové správy dat. Souborný katalog je provozován v systému ALEPH, který však neumožňuje provádět import záznamů s kontrolou na duplicity dle potřeb souborného katalogu a dále nedovoluje zásahy do záznamů v bázi jinými než vlastními prostředky. Další modifikace pomocí programů je nutno provádět mimo bázi. Správce souborného katalogu používá externě vytvořený program pro řízený import s kontrolou duplicit. Toto řešení však vyžaduje aktivaci procedury kontroly duplicit mimo bázi v systému ALEPH, a tudíž je možné zpracovávat pouze data získaná off-line. Účastnící souborného katalogu zasílají data na ftp server nebo na disketě klasickou poštou. Zasílání dat prostřednictvím e-mailu se neosvědčilo, velmi často docházelo k narušení struktury i obsahu dat. Povolené formáty dat a znakové sady jsou: Znakový repertoár: Abecedy na základě latinky, přípustné kódy jsou: ISO 646 a/nebo ISO 5426 veškerá diakritika kódována pomocí GIZMO notace kód PC Latin 2 (Microsoft Code Page 852) + GIZMO kód Kamenických + GIZMO ISO 8859-2 + GIZMO Formát souborů dat: Řádkový UNIMARC UNIMARC ISO 2709 Výměnný formát ISO 2709 Exportní soubor z ALEPH (ALEPH load formát) Výměnný formát, exportní soubor ze systému CDS/ISIS. Celý proces zpracování záznamů se skládá z těchto fází: kvalitativní analýza dat konverze dat konverze dat do exportního souboru ALEPH konverze znakových sad do ISO 8859 rozlišení záznamů českých a zahraničních dokumentů přidělení kvalitativní váhy řízený import dat do báze souborného katalogu obnovení kompatibility pomocného souboru BASE s bází souborného katalogu pro import dat 2.1. Kvalitativní analýza dat Kvalitativní analýza dat spočívá v ruční kontrole struktury a obsahu dat u každé dodané dávky. Pokud se jedná o účastníka, který již dodává data pravidelně, je prováděna pouze namátková kontrola u každé nové dávky dat. Záznamy všech nových účastníků jsou prověřovány velmi pečlivě v několika kolech, kdy dochází k aktivní komunikaci písemné i telefonické a osobní mezi správcem souborného katalogu a účastníkem, který má zájem o dodávání svých záznamů do souborného katalogu. Nejčastější nedostatky, na které správce upozorňuje, se týkají: použití znaků vylučujících z abecedního řazení mluvnické členy u cizojazyčné literatury a číslovky na začátku názvu (<The > <3. >) ukládání řadových číslovek na začátku názvu konferencí, symposií a jiných akcí zápisu do polí pro korporace a pro akce absence polí nebo podpolí pro: siglu vlastníka (pole 910^a) zpracovatele záznamu (pole 801^b) MDT (pole 675) použitá katalogizační pravidla (pole 801^g) jazyk dokumentu (pole 101^a) chybného zápisu kódů jazyků a zemí absence indikátorů nebo naopak nesprávné použití indikátorů použití nepovolených polí. U záznamů dodávaných v ALEPH load formátu (exportní soubor ALEPH) velmi často chybí návěští (label). Pro potřeby kvalitativní analýzy se záznamy ve formátu UNIMARC i ve Výměnném formátu zaslané jako ISO soubory importují do pomocné báze na lokálním PC, kde probíhá vlastní kontrola obsahu záznamů. Záznamy dodané v řádkovém UNIMARCu nebo v ALEPH load formátu se prohlížejí jako textové soubory. Výsledek kvalitativní analýzy správce písemně oznámí účastnické knihovně. Pokud jsou data v pořádku, přesune správce soubor dat do jiného adresáře na lokálním PC a přistoupí k jejich konverzi. 2.2. Konverze dat Konverze dat do exportního souboru ALEPH Správce provede konverzi dat do exportního souboru ALEPH (ALEPH load formátu), k tomu účelu spustí některý z níže uvedených programů, jenž vybere na základě použitého formátu dat a znakové sady v konkrétním souboru dat:

UNIALE.EXE

konverze řádkového UNIMARCu do ALEPH load formátu

ISOALEKA.EXE

konverze UNIMARC ISO 2709 s rozlišením znakové sady Latin 2 a Kamenických do ALEPH load formátu

5426ALKA.EXE

konverze ISO UNIMARC s rozlišením znakové sady ISO 646 a ISO 5426 do ALEPH load formátu

JVF2UNK

konverze Výměnného formátu ISO 2709 s rozlišením znakové sady Latin 2 a Kamenických do ALEPH load formátu.

Konverze znakových sad do ISO 8859

Je-li to nutné, provede správce konverzi znakových sad do ISO 8859 s využitím programu:

XLIT

konverze znakových sad do ISO 8859.

Dávky záznamů jednotlivých účastníků tvoří samostatné soubory. Ty jsou po skončení kvalitativní analýzy a konverze přesunuty pomocí ftp z adresáře na lokálním PC na server, kde správce pokračuje v jejich zpracování.

2.3. Rozlišení záznamů českých a zahraničních dokumentů

S využitím programu BASE1 přidělí správce záznamům tzv.logické báze, které umožní rozlišení záznamů českých a zahraničních dokumentů.

2.4. Přidělení kvalitativní váhy

Váha je numerická hodnota vyjadřující kvalitu záznamu. Správce musí otevřít soubor záznamů ve vi editoru, prohlédnout jejich obsah (při tom se však již opírá o provedenou kvalitativní analýzu) a přidělit příslušnou váhu (viz Tabulka 1).

Tabulka 1

VÁHA	KVALITA ZÁZNAMU
4	Nestandardní
9	Záznam splňuje rozsah minimálního záznamu ve jmenném popisu, chybí MDT
10	Záznam splňuje rozsah minimálního záznamu
11	Záznam přesahuje rozsah minimálního záznamu ve jmenném popisu
12	Záznam přesahuje rozsah minimálního záznamu ve jmenném a věcném popisu
20	Záznam Národní knihovny ČR

2.5. Řízený import dat do báze souborného katalogu

JIMCHECK -program pro řízený import dat do bází ALEPH s kontrolou duplicit pracuje následujícím způsobem: program pracuje s pomocným souborem BASE, který je vytvořen exportem báze ALEPH, ale obsahuje pouze vybraná pole tj. pole, která se používají k identifikaci dokumentu a k tvorbě porovnávacích klíčů; proti záznamům v souboru BASE porovnává záznamy, které jsou určeny pro souborný katalog, a upravuje je pro import do báze ALEPHpomocný soubor musí být před každým zpracováním vstupních dat v souladu s bází ALEPH aby nebylo nutné po každém importu do souborného katalogu provádět export pomocného souboru BASE z báze ALEPH, modifikuje doplňkový program JIMAPP pomocný souborBASE tak, aby byl v souladu se stavem báze ALEPH po importu nových záznamů; program JIMAPP do něj přidává nově přidané záznamy neduplicitní stav báze ALEPH může být v souladu se stavem pomocného souboru BASE pouze za podmínky, že se v bázi ALEPH neprovádějí žádné modifikace cestou on-line (tj. ani katalogizace, ani údržba autorit); po každé modifikaci v bázi ALEPH by totiž bylo třeba znovu vytvořit pomocný soubor BASE, jinak dojde ke ztrátě informací, vzniku nežádoucích nových duplicit a možná i “falešných spojů”.   Program pro řízený import(JIMCHECK) vyrobí následující výstupní soubory:

Soubory add, upd a new se jeden po druhém importují do báze souborného katalogu, přičemž správce použije alephovské utility – UTIL 91 : import dat do báze.

Po úspěšném importu všech tří souborů se s využitím UTIL 101 a UTIL 303 opět exportují záznamy souboru new, přičemž všechny nové záznamy již mají své SYSNO (systémové číslo v rámci báze souborného katalogu). S využitím doplňkového programu JIMAPP se tyto záznamy ve zkrácené formě a se správnými SYSNO přihrají na konec pomocného souboru BASE a obnoví se tak jeho kompatibilita s bází souborného katalogu pro další import záznamů jiné knihovny. Řízený importdat s kontrolou duplicit do souborného katalogu s využitím programu JIMCHECK trvá nejméně osm hodin, pokud se vyskytnou komplikace i déle. Přitom nezáleží na velikosti jedné dávky dat, protože program “čte” celou bázi, ale záleží na velikosti báze, která pochopitelně stále roste (viz Příloha 1). Z výše uvedeného vyplývá, že zpracování dávky dat jedné knihovny (bez ohledu na to, zda obsahuje 100 či 10 000 záznamů) trvá dva pracovní dny. Od počátku roku 1998 je souborný katalog zdrojem pro kooperativní zpracování České národní bibliografie, proto správce musí pravidelně každý měsíc přednostně importovat záznamy MZK v Brně a ostatních státních vědeckých knihoven, které se na kooperativním zpracování ČNB podílejí. Lze si snadno spočítat jak málo pracovních dní zbývá správci souborného katalogu na zpracování záznamů ostatních účastníků, kterých je již celkem 28. S rostoucím počtem záznamů v souborném katalogu probíhá vlastní import jednotlivých dávek stále pomaleji. Správce řeší situaci tak, že pokud je to nezbytné, importuje záznamy ostatních účastníků po dvou až třech dávkách najednou. Každé řešení tohoto stavu je na úkor aktuálnosti souborného katalogu. Racionalizace správy souborného katalogu a tudíž i značné zrychlení importu dat bude vyřešeno využitím vlastních aplikací pro souborný katalog v systému ORACLE. 3. Zpracování dat pro souborný katalog s využitím vlastních aplikací databázového systému ORACLEPotřeba zásadního zkvalitnění správy souborného katalogu a nutnost dalšího rozvoje služeb pro uživatele i knihovníky vedla k rozhodnutí vývoje vlastních aplikací s využitím databázového systému ORACLE pro správu i provoz souborného katalogu. Veškeré služby budou realizovány prostřednictvím SQL Serveru ORACLE a WebServeru ORACLE, a to při zachování všech současných standardů pro dodavatele a příjemce dat: budou i nadále respektovány všechny výše uvedené formáty a znakové sady, navíc budou přijímána data využívající UNICODE UTF 8. Od března 1998 probíhá vývoj aplikací pro provoz souborného katalogu v systému ORACLE, koncem června 1999 bude zahájena správa a provoz souborného katalogu v systému ORACLE (budou zpřístupněny záznamy tištěných monografií). Dojde ke značné automatizaci všech činností spojených se správou bází souborného katalogu včetně analýzy vstupních dat, a to s maximálním využitím k tomu účelu dosud vytvořených softwarových prostředků. Při vývoji aplikací pro souborný katalog v systému ORACLE měl správce na mysli maximální racionalizaci pracovních postupů, která spočívá v eliminaci lidského zásahu všude tam, kde je to možné a efektivní. Zpracování záznamů probíhá zcela automaticky: příjem a identifikace souboru dat (včetně konverze) formálně logické kontroly dat import dat statistiky problémy k řešení pro správce

3.1. Příjem a identifikace dat

Účastník umístí svá data v přiděleném prostoru na ftp serveru (pokud je dodá na disketě, nahraje je na ftp server správce). Program bude v pravidelných intervalech kontrolovat, zda na ftp server nepřibyla nová data. Stáhne je a dle názvové konvence (viz níže) zjistí jejich vlastníka, v jakém jsou formátu a jaká byla použita znaková sada. Názvová konvence - délka názvu datového souboru je 8 + 3 tedy 11 znaků: prvních 6 znaků názvu tvoří sigla instituce znaky 7 a 8 popisují použitou znakovou sadu znaky 9, 10 a 11 popisují formát dat Znaková sada (znaky 7 a 8): um ISO 646 a/nebo ISO 5426 gi veškerá diakritika pomocí GIZMO notace lg PC Latin 2 + GIZMO kg kód Kamenických + GIZMO uc UNICODE UTF 8 sg ISO 8859-2 + GIZMO Formát dat (znaky 9 až 11): dat exportní soubor z ALEPH rum řádkový UNIMARC uis UNIMARC ISO 2709 vfo Výměnný formát ISO 2709 vfi Výměnný formát, exportní soubor ze systému CDS/ISIS Příklady: aba006lg.uis ola001kg.vfo sigla aba006 - CIKS VŠE Praha sigla ola001 - SVK Olomouc znaková sada lg - PC Latin2 + GIZMO znaková sada kg - kód Kamenických + GIZMO formát dat uis - UNIMARC ISO 2709 formát dat vfo - Výměnný formát ISO 2709

3.2. Formálně logické kontroly dat

Všechny nové i editované záznamy budou před importem do souborného katalogu testovány. Součástí automatické kontroly je: test na UNIMARC přidělení kvalitativní váhy test na duplicitu záznamů. Test na UNIMARC Pomocí vyvinuté aplikace budou jednotlivé záznamy automaticky testovány na správnost zápisu do polí formátu UNIMARC. Algoritmus testování na UNIMARC je podrobně popsán v materiálu CASLIN – Souborný katalog ČR. Zadání pro vývoj aplikací v systému ORACLE přístupném na domácích stránkách CASLIN, u všech polí se prověří: zápis obecně opakovatelnost polí a podpolí, přítomnost a hodnota indikátorů různé podmínky zápisu v poli Přidělení kvalitativní váhy byla vytvořena tabulka sigel a k nim přidělených vah pro knihovny, které již dodávají záznamy. každá nová knihovna je ručně analyzována, správce jí přidělí váhu a zapíše do tabulky vyskytne-li se v prostoru pro vstupní data soubor se siglou v názvu, která dosud není v tabulce, nebude se automaticky analyzovat, ale bude upozorněn správce, který data zanalyzuje data došlá od knihoven, které již mají přidělenou váhu v tabulce, projdou automatickým testem na přidělování vah. Takto přidělená váha bude automaticky porovnána s vahou v tabulce. Bude-li shodná, data se zpracují automaticky. Bude-li se váha lišit, zpracování dat se zastaví a bude upozorněn správce. Algoritmus přidělování vah je podrobně popsán v materiálu CASLIN – Souborný katalog ČR. Zadání pro vývoj aplikací v systému ORACLE přístupném na domácích stránkách CASLIN. Test na duplicitu záznamů Záznamy jsou automaticky testovány na duplicitu, je-li to nutné, probíhá testování duplicity ve dvou fázích. Algoritmus primárního i sekundárního klíče pro porovnávání záznamů je také podrobně popsán v materiálu CASLIN – Souborný katalog ČR. Zadání pro vývoj aplikací v systému ORACLE. Duplicitní záznamy s vyšší váhou nahradí záznamy s nižší váhou. 3.3. Import datV průběhu testování záznamů na duplicitu v aplikacích systému Oracle nevznikají výstupní soubory add, upd a new. Každý záznam se hned po porovnání naimportuje do báze souborného katalogu a porovnává se s každým dalším záznamem dané dávky, dochází tudíž ke kontrole také vnitřní duplicity vstupní dávky dat. Informace o nevyhovujících záznamech budou prostřednictvím e-mailu jako statistika s příslušným komentářem zaslány zpět příslušné knihovně k opravě. Celý proces zpracování záznamů má správce možnost spustit jako celek, takže jednotlivé kroky proběhnou automaticky v návaznosti na sebe, nebo po jednotlivých krocích tak, že má možnost kontroly výstupů z každého kroku. V obou variantách správce může nastavit datum a čas spuštění celého procesu nebo kroků.

3.4. Statistiky

Statistiky se vytvářejí pro uživatele i pro správce. Uživatel má možnost zobrazit si statistiku a zprávy systému vztahující se k jeho činnosti v bázi na konci své aktivity. Tyto statistiky jsou archivovány po dobu stanovenou správcem a přístupné uživateli. Statistika pro uživatele: siglu uživatele (login) ip adresu, ze které akce probíhala činnosti, které systém prováděl počty zpracovávaných záznamů při sdílené katalogizaci rozdělené na editované, nově uložené, stažené svoje a cizí dále chybová hlášení datum a čas relace. Statistika pro správce (za 24 hodin):

3.5. Problémy k řešení pro správce souborného katalogu:

stejně jako dodavatel dat obdrží správce přesnou statistiku chyb v záznamech chybového souboru pokud v průběhu automatického zpracování dat dojde k chybnému zakončení procesu, zabývá se správce hledáním příčiny, proč k tomu došlo a hledá nápravu pokud kvalitativní váha přidělená nové dávce dat neodpovídá dříve přidělené váze, systém na to správce upozorní a ten provede hlubší analýzu dat systém správce upozorní, že vlastníkem dodané dávky dat je knihovna, která ještě nemá přidělenou váhu, správce provede ruční kvalitativní analýzu dat. Základní činností správce souborného katalogu již nebude zdlouhavé a náročné zpracování a import dat, uvolněné pracovní kapacity bude možné věnovat systematickému čištění dat v souborném katalogu. 4. Sdílení záznamů v rámci souborného katalogu Vývojem vlastních aplikací pro souborný katalog v systému ORACLE vytvořil správce kvalitní technické podmínky k zásadnímu zlepšení aktuálnosti souborného katalogu. V zásadě je možné se s vybranými knihovnami domluvit, aby každý den ke konci pracovní doby zaslaly na ftp server souborného katalogu záznamy toho dne zpracovaných dokumentů, které správce během noci naimportuje. Od poloviny roku 1999 budou mít účastníci souborného katalogu možnost stahovat vybrané záznamy (copy cataloguing) nebo využít možnosti katalogizace uvnitř souborného katalogu s následným kopírováním záznamu ve svém lokálním katalogu (shared cataloguing). 4.1. Copy cataloguing Uživatel má možnost stahování jednotlivých záznamů nebo dávek záznamů ve zvoleném formátu a znakovém repertoáru, který zadá v menu. Při využití obsahu pole 001 u záznamů editovaných vlastníkem záznamu může uživatel vlastními prostředky docílit přepsání původního záznamu ve své bázi kvalitnějším (staženým ze souborného katalogu). 4.2. Shared cataloguing Při tvorbě nového záznamu v souborném katalogu využije katalogizátor dané knihovny nabídnutý vstupní formulář (JAVA applet), který neobsahuje nepovolená pole. Povinná pole dle instrukcí pro souborný katalog jsou rozepsána, avšak katalogizátor má možnost další zvolená pole, která nejsou jednotlivě uvedena ve formuláři, zahrnout do verze vstupního formuláře. Tuto vlastní verzi si pojmenuje, uloží do svého prostoru a kdykoliv znovu použije. 4.3. Editace záznamu Pro editaci je k dispozici vstupní formulář, který zobrazí kompletní obsah editovaného záznamu. Při editaci má uživatel možnost vložit do svého záznamu identifikační číslo (tag 001), a tím může vlastními prostředky docílit přepsání původního záznamu ve své bázi kvalitnějším, který upravil v souborném katalogu. Použití tagu 001 umožní plně využít tuto službu také knihovnám, které jsou nuceny provádět konverzi formátu záznamů vlastními prostředky. Kam kráčí CASLIN - Souborný katalog ČR?Domnívám se, že ve chvíli, kdy nabízíme knihovnám sdílenou katalogizaci jako cílový stav budování národního souborného katalogu, je ten správný okamžik k ohlédnutí na cestu, po které souborný katalog šel. Věřím, že po třech letech fungování souborného katalogu již správce nemusí zdůrazňovat, že: informační funkce souborného katalogu je stejně důležitá jako katalogizační, že záznamy CEZL musí být nedílnou součástí CASLIN - Souborného katalogu ČR souborný katalog musí zůstat otevřený všem knihovnám, které jsou schopny a ochotny dodržet stanovené standardy, že právě tyto standardy jsou oním přirozeným sítem a není nutné některé knihovny upřednostňovat před jinými neusiluje o maximální kvantitu záznamů na úkor jejich kvality budování souborného katalogu se všemi jeho funkcemi není totéž co kooperativní katalogizace (ačkoliv by se právě souborný katalog měl stát základním nástrojem k tomu, aby každý dokument v České republice byl zkatalogizován jen jednou).Správce souborného katalogu připravuje technické podmínky ke sdílení záznamů, nyní záleží na účastnících do jaké míry se tato služba stane výhodná a hojně využívaná. Závěrem je třeba zdůraznit, že vývoj vlastního softwaru dává správci souborného katalogu i do budoucna možnost úprav stávajících aplikací a vývoj nových aplikací v souladu s vývojem informačních technologií.