Souborný katalog a Národní autority jak obejít omezení komerčního systému

Automatizace knihovnických procesů 2005 (AKP 2005), 10. ročník semináře, Liberec, 3. a 4. květen 2005

Souborný katalog a Národní autority – jak obejít omezení komerčního systému Helena Dvořáková* [email protected] Abstrakt: Komerční integrovaný knihovní systém může dobře sloužit praktickému provozu knihovny, ne vždy však má nástroje potřebné pro specializované agendy. Situace je ještě složitější, jde-li o kooperační systémy v heterogenním prostředí, jako jsou Souborný katalog ČR a Národní autority. Dají se speciální funkce „naroubovat“ na komerční knihovní systém, nebo je nutné vyvinout a udržovat proprietární systém? Národní knihovna ČR má zkušenost s oběma cestami. Souborný katalog ČR fungoval po více než 10 let své existence pod různými systémy, nyní používá systém Aleph500 s integrovanou kontrolou na duplicity a novými pravidly pro tvorbu klíčů a ohodnocení záznamů. Databáze Národních autorit musela externími prostředky vyřešit problém, jak umožnit knihovnám s jinými systémy vytvářet záznamy autorit. WWW formuláře a s nimi spojené nadstavbové programy nabízejí spolupracujícím knihovnám další možnost, jak zasílat či modifikovat záznamy v kooperačních bázích bez využití klienta Aleph500 nebo Z39.50. Zpřístupnění záznamů z bází NK ČR pro stahování v jiném než originálním formátu zajišťují na Aleph navázané konverzní programy. Klíčová slova: souborné katalogy, soubory autorit, knihovní systémy

1

Úvod

Když instalujete v knihovně integrovaný knihovní systém, musíte počítat s tím, že i když pokryje (lépe či hůře) všechny standardní knihovní procesy, možná se nevypořádá se specializovanými agendami. Spokojenost s jakýmkoli knihovním systémem trochu závisí i od toho, jaké nároky na něj měl uživatel. Dalším důležitým faktorem, podle něhož se často knihovny rozhodují při výběru systému, je jeho flexibilita a šíře možností lokálních nastavení vlastními silami, protože i když je distributor systému dostupný, ochotný a rychlý, „nadstandardní“ úpravy vždycky něco stojí. Národní knihovna (dále NK) nemá jen svůj fond, který je třeba zkatalogizovat, a své čtenáře, kterým půjčuje. Její ústřední postavení mezi českými knihovnami, potvrzené i statutem, ji předurčuje k tomu, aby spravovala také nejrůznější centrální agendy. S rozvojem automatizace se rozběhla i řada kooperačních projektů a tam, kde se NK zapojila, obvykle také převzala úlohu garanta projektu a povinnost zajišťovat ho po technické stránce. V databázové podobě [1] se z mnoha agend a projektů v NK realizují následující: Souborný katalog ČR (CASLIN) + Adresář knihoven a informačních institucí [2, 3]. Národní autority ČR [4]. Knihy a hudebniny ohlášené agenturám ISBN a ISMN + Adresář nakladatelů ČR. Články v českých novinách a časopisech. Terminologická databáze z oblasti knihovnictví a informační vědy (+ databáze zkratek + anglicko-český a česko-anglický slovník z téhož oboru) . Pro specifika některých agend samotné prostředky systému Aleph500, který používá NK, nedostačovaly. Ale ať má Aleph jakékoli mouchy (a že je má, to jako systémový knihovník *

Národní knihovna ČR, Klementinum 190, 110 00 Praha 1

1


vím lépe než jiní), otevřený je do té míry, že se většina problémů dala vyřešit kombinací nastavení a nadstavbových programů využívajících i alephovské procedury. V příspěvku se budu věnovat pouze prvním dvěma databázím, protože právě zde byly nároky na přizpůsobení systému speciálním potřebám největší..

2 2.1

Souborný katalog Od Alephu ke Cubusu a zpět

Souborný katalog ČR, dříve nazývaný CASLIN podle projektu, který ho „odstartoval“, prošel za dobu více než deseti let své existence několika etapami vývoje – podrobnosti viz [8, 9]. Po počátcích pod systémem CDS/ISIS (periodika byla redigována v tomto systému až do roku 2003) fungoval nějaký čas pod systémem Aleph300, s využitím externích programů pro deduplikaci, což se však při větším nárůstu záznamů ukázalo jako problematické řešení – program pracující na principu čtení řádkových souborů nestačil zpracovat přírůstek v únosném čase. Z těchto důvodů bylo v roce 1997 rozhodnuto, že se pro souborný katalog nechá vytvořit speciální systém, který by jednak efektivněji vyřešil deduplikace a mergování záznamů, jednak poskytl nástroje pro online sdílenou katalogizaci, po níž knihovnická veřejnost volala. Systém Cubus byl uveden do provozu v roce 2000 a vcelku se osvědčil, avšak splnil jen jeden z výše zmíněných požadavků. Nakonec se ukázalo, že o centrální zpracování záznamů (v cizím prostředí) vlastně velký zájem není; o co však byl zájem, byla možnost snadného stahování záznamů s přístupem do báze přes protokol Z39.50. V roce 2002 měla již NK své ostatní báze pod vyšší verzí systému Aleph (Aleph500), který přístup přes Z39.50 pro vyhledávání nabízel. Navíc pod Alephem500 již běžel kooperační systém národních autorit, bibliografické záznamy z alephovských bází již byly na autoritní záznamy napojeny, v Alephu fungovala i báze Adresář. Bylo tedy zcela logické, že se vedení NK začalo zabývat otázkou, zda by nebylo lepší převést pod Aleph i souborný katalog. I určité nástroje pro deduplikaci Aleph500 měl, ale nikoli tak sofistikované jako na míru vytvořený systém Cubus. Jak tedy dál? Nebylo to lehké rozhodování. Bylo jasné, že další vývoj Cubusu (zabudování Z39.50, vyřešení vazeb do autorit a do adresáře, umožnění online editace záznamů alespoň pro správce báze) by byl nemálo nákladný a určitě by výsledky nebyly k dispozici brzy. Vývoj deduplikačních mechanismů pro Aleph se jevil jako problematický i z toho důvodu, že Aleph v té době neměl lokálního distributora a bylo by nutné se s požadavky obracet na izraelskou firmu. Schůdným řešením se zdálo převedení báze pod Aleph s využitím deduplikačních mechanismů systému Cubus. Řešení poměrně levné a rychlé, samozřejmě nepříliš „elegantní“, ale hlavně trochu vzbuzující pochybnosti, zda vůbec může fungovat. Expertní rada, kterou si ředitel NK pozval na pomoc při rozhodování, nebyla schopna dát jednoznačné doporučení. Všichni se shodovali v tom, že nejlepší by bylo mít všechno včetně autorit pod jedním systémem, tato možnost však v té době nebyla reálná. Ředitel nakonec rozhodl pro Aleph. 2.2

Etapa koexistence dvou systémů

Během podzimu 2002 byly provedeny přípravy pro přechod SK ČR pod Aleph, na jaře 2003 byla naplněna báze SKC. Pro bázi samotnou nebylo třeba provádět mnoho úprav, vazby do autorit a do adresáře se daly nastavit standardními prostředky Alephu, přístup přes Z39.50 nabízela v té době NK i do svých ostatních bází. Dalšími novinkami byl přístup k záznamům přes rejstříky a možnost přechodu ze záznamu v SKC na záznam v lokální bázi knihovny, která ho zaslala (pokud knihovna dodala potřebné parametry). Import dávek záznamů se 2


prováděl dvoufázově. Nejprve proběhl celý proces kontrol, konverzí, deduplikací, mergování a importu pod systémem Cubus do pomocné báze; poté byly nové a změněné záznamy exportovány a importovány do báze SKC. Aby mohl správce báze v Alephu editovat záznamy seriálů, bylo však také nutno zajistit opačnou cestu – z Alephu do Cubusu, protože obě báze musely udržovat identický stav. Zajištění oboustranného exportu-importu byla záležitost několika drobných prográmků, důležitá však byla časová koordinace. Naše tzv. „kolečko“ jsme nastavili tak, že po skončení práce v Alephu v 19.00 se ze SKC vyexportovaly nové a změněné záznamy, které se importovaly do pomocné báze ještě před příjmem první dávky nových záznamů. Zpracování v Cubusu muselo skončit do páté hodiny ranní, kdy byl nastaven import do SKC, aby se zde záznamy stačily zaktualizovat. Velké dávky, např. z retrokonverze, měly dostatek času na zpracování o víkendech. Systém „kolečka“ fungoval poměrně spolehlivě. Když došlo k nějaké chybě, import do pomocné báze proběhl a záznamy se přitom do SKC nedostaly, dostali správci bází zprávu a import se spustil ručně dodatečně, případně se zastavily editace v bázi. Problémů bylo minimálně, ale nepovažovali jsme to za řešení trvalé ze dvou důvodů: jednak bylo nutné udržovat dvě identické báze s cca 2 milióny záznamů, jednak by po konverzi báze SKC z Unimarcu na MARC21 bylo třeba „přestavět“ nástroje Cubusu pro nový formát.

2.3

Problémy deduplikace v systému Aleph

V létě 2004 jsme tedy začali pracovat na programech, které by nahradily Cubus. Ačkoli kontroly a konverze nejsou přímo součástí importních procedur a tudíž je není třeba vázat na Aleph, hotové nástroje Cubusu se právě kvůli novému formátu MARC21 nedaly použít a jejich rozšíření a úpravy by byly časově i finančně náročnější než vytvoření programů 3


nových, resp. zabudování již hotových dílčích programů do importního skriptu. Nástroje pro vlastní deduplikaci uvnitř Alephu byly vyhovující, až na jeden dost závažný nedostatek – limit počtu znaků u takto porovnávaného indexovaného pole. Má-li být deduplikace spolehlivá, je potřeba postavit klíč pro porovnávání z dostatečného množství údajů a při prostém spojení údajů z několika polí (např. název + ISBN) je tento limit téměř vždy překročen. Navíc je žádoucí klíč vytvořit poněkud sofistikovanější metodou, tj. podobně, jako tomu bylo v Cubusu, vytvořit pro klíč speciální pole, a kromě toho navíc zajistit, aby se klíč upravil dle potřeby, když je záznam v bázi editován. Na toto prostředky Alephu nestačily, ale pomohl chytrý programátor a nový konverzní nástroj MarcMan, který se dá využít i jako připojený externí program při ukládání záznamů online. Limit počtu znaků jsme překonali tak, že vlastní porovnávací klíče různě dlouhé, tvořené různými metodami a z různých polí a podpolí záznamu program zakóduje hashovací metodou MD5 na řetězec s konstantní délkou 32 znaků.

4


Zbývalo ještě vyřešit porovnávání záznamů podle váhy, aby v bázi pokud možno zůstával záznam kvalitnější. A protože nebylo možné použít již hotové programy, postavili jsme rovnou přidělování váhy na novém principu: váha se nepřiděluje stejná celé dávce, ale jednotlivým záznamům, a to tak, že se k základní váze určené dané knihovně (na základě analýzy jejích dat) přičítají „bonusové“ body za určité znaky kvality záznamu, např. za vazbu na autority, ISBN, věcný popis apod. Méně kvalitním záznamům, např. z retrokonverze, se přiděluje nižší základní váha. Mergovací procedury pro seriály jsme navíc vylepšili tak, aby se některá důležitá pole zachovávala z obou spojovaných záznamů (pokud nejsou identická). Tyto procedury již běží mimo Aleph, ale nejsou časově náročné. Zpracování dávky o cca 10.000 záznamech, které jsou již ve formátu MARC21, trvá včetně kontrol až po import zhruba půl hodiny. Dalších několik hodin pak probíhá na pozadí aktualizace přístupových souborů (ta však byla na čas nejnáročnější jak v samotném Cubusu, tak při kombinovaném zpracování). Import záznamů probíhá při otevřené bázi – zajistili jsme to speciální úpravou alephovského importního programu, standardně totiž Aleph při importu bázi zamyká i pro uživatele v OPACu. 2.4

Současný stav souborného katalogu

Konverze záznamů báze SKC do MARC21 a přechod na nové mechanismy deduplikace a importů proběhly koncem prosince 2004 a v prvních lednových týdnech 2005. Samotná konverze by byla záležitostí dnů, ale postupovali jsme trochu složitější cestou, abychom dosáhli zároveň zkvalitnění obsahu báze. Záznamy NK jsme z vyexportovaných záznamů vyřadili, pokud neměly jiného odběratele, abychom je nemuseli znovu konvertovat, a do báze SKC je naimportovali jako základ (mnohé byly v souvislosti s letní konverzí opraveny a byla v nich vytvořena řada nových vazeb do autorit). Ostatní záznamy jsme exportovali podle jednotlivých sigel a vah a posílali je do báze s novým váhovým ohodnocením a deduplikací podle nových klíčů, čímž se podařilo zlikvidovat část duplicit způsobených krátkými klíči. (Toto je jeden z důvodů, proč celkový počet záznamů v SK dočasně poklesl; druhým důvodem je vyřazení zcela nestandardních nebo nějakým způsobem problematických záznamů). Novou podobu dostalo i webovské rozhraní pro zpřístupnění výsledků importů pro uživatele. 2.5

Možnost editace záznamů

Záznamy v souborném katalogu je oprávněn online editovat pouze správce, tj. pracovníci odd. souborných katalogů. Editace se až na výjimky týká seriálů, kde je nutno upravovat jak bibliografický obsah, tak údaje o odběru knihoven, z nichž většina stále hlásí změny v odběru tradičním způsobem. Teoreticky nic nebrání tomu, aby měli do báze přístup k editaci i katalogizátoři knihoven s Alephem500, případně v omezené míře i knihoven s jinými systémy, pokud by se využilo mechanismu používaného u autorit (viz dále), ale záměrně jsme se pro tuto možnost nerozhodli. Centrální redakce je u seriálů nutností, knihovny mohou upravovat maximálně své údaje o odběru. A pokud jde o monografie, není tu potřeba zavedený systém měnit, protože knihovnám zasílání dávek vyhovuje - export se dá snadno zautomatizovat. Jediné, co by bylo žádoucí, je zvýšit frekvenci zasílání záznamů, aby byl SK více aktuální, což je důležité pro stahování záznamů. Aby mohly knihovny pohodlně upravovat své údaje o odběru seriálů přímo do báze, na to jim již několik měsíců slouží formuláře z webovského rozhraní. Zpracování údajů uložených do formuláře zajišťují programy navázané na alephovské exportní a importní procedury. Protože editace probíhá v době, kdy se v bázi pracuje a kdy je otevřená uživatelům, import změněných údajů se provádí při zamčené bázi, a to každou čtvrthodinu. Webové formuláře se 5


používají i pro objednávky MVS. Uvažuje se také o možnosti nabídnout knihovnám z webového rozhraní i export záznamů, a to v obou u nás používaných formátech, MARC21 i Unimarc. Využily by toho zřejmě hlavně ty knihovny, které nemají Z39.50 klienta (jinak je samozřejmě stahování záznamů touto cestou jednodušší, a to i pro knihovny, které zůstávají ještě v Unimarcu – viz kapitola o konverzi).

3

Národní autority

Databáze Národních autorit začínala podobně jako souborný katalog v systému Aleph300 a zpočátku sloužila jen jako zdroj ověřených forem personálních jmen a biografických údajů – tehdy ještě ani nefungovaly mechanismy vazeb mezi bibliografickou a autoritní bází. To se radikálně změnilo s přechodem na Aleph500 v roce 2000. V té době se zároveň začal v českých knihovnách více používat protokol Z39.50, většina systémů se „naučila“ s autoritami pracovat a zájem o stahování autoritních forem jmen výrazně vzrostl. Projekt „Kooperativní tvorba a využívání souborů národních autorit“ nastartoval novou etapu – řada knihoven projevila zájem nejen autority stahovat, ale i do báze přispívat. Umožnit to knihovnám se systémem Aleph500 nebyl problém, jak ale s jinými knihovnami? Tady se projevilo jedno výrazné omezení systému Aleph: má zabudován protokol Z39.50 verze „search+retrieval“, nikoli vyšší verzi „update“, která by umožňovala i ukládání záznamů do báze. Hned na počátku bylo jasné, že v našich podmínkách těžko přesvědčíme knihovny, že si mají nainstalovat klienta Aleph a zvyknout si pracovat ve dvou systémech, muselo se tedy hledat jiné řešení. Stačil nápad, pár chytrých hlav a na světě byla „bandaska“ – přestupní stanice pro ukládání záznamů. Knihovník ve svém prostředí uloží záznam do neveřejné báze na Z39.50 serveru a speciální programy zajistí, aby se do 15 minut dostal do báze autorit. Využívá se při tom opět standardní alephovská importní procedura. Při přechodu báze autorit na formát MARC21 do hry vstoupily ještě konverzní programy. Protože zatím všechny knihovny, které přispívají přes „bandasku“, zůstaly v Unimarcu, řešení bylo jednoduché – pro knihovny se nic nezměnilo a záznamy se konvertovaly cestou z „bandasky“ do báze autorit. Pro chvíli, kdy některá z těchto knihoven přejde na MARC21, máme připraveno rozdělení „bandasky“ na marcovou a unimarcovou část – záznamy budou muset procházet dvěma větvemi zpracování. V současnosti mají paradoxně největší problém některé knihovny s Alephem: tam, kde se zůstalo v Unimarcu, musejí katalogizátoři autority ukládat v MARC21, tam, kde mají jinou verzi Alephu, se to dá řešit jen „zapůjčením“ klienta. Jakékoli změny systému, verze či formátu pochopitelně každou kooperaci ovlivní – je téměř pravidlem, že chvíli trvá, než se příslušná knihovna znovu plnohodnotně zapojí. A pokud ke změně dojde v knihovně, která spravuje centrální bázi, je všechno samozřejmě mnohem složitější. Přímého ukládání do báze AUT nebo „bandasky“ již dnes využívají katalogizátoři téměř 40 knihoven. Rutinně se vytvářejí návrhy autorit (které posléze reviduje supervizor NK) pro autority jmenné, tj. personální jména a korporace či konference. V menší míře takto vznikají také návrhy geografických autorit a formálních deskriptorů. Pro tyto dva typy autorit, kde potřeba vytvořit novou autoritu není tak častá, byly navíc vytvořeny formuláře ve webovském prostředí, aby návrh mohla zaslat i knihovna, která přístup přes Z39.50 nemá nebo do kooperace není zapojena. Zcela jiná je situace u vlastních věcných autorit, předmětových hesel Národní knihovny. Zde je centrální redakce už kvůli nutnosti zajistit správné propojení příbuzných záznamů (nadřazené, podřazené a asociované termíny) naprostou nezbytností, proto kromě supervizora 6


nikdo tyto autority do báze ukládat nesmí. Místo toho jsme zavedli systém zasílání návrhů autorit v podobě tabulek, které obsahují kromě příbuzných termínů i MDT a anglické ekvivalenty. Poté co správce věcných autorit obsah tabulek zreviduje a doplní, speciální program zajistí import do báze – v bázi jednak vzniknou nové autority, jednak se o příslušná pole doplní autority stávající.

4

Konverze z Unimarcu na MARC21

V létě r.2004 přešla NK spolu s dalšími dvěma „alephovskými“ knihovnami, brněnskou Moravskou zemskou knihovnou a Vědeckou knihovnou v Olomouci, z formátu Unimarc na formát MARC21. Několik knihoven tento formát používalo již dříve, převážná většina českých knihoven však ještě v Unimarcu zůstala a přechod na nejbližší dobu neplánuje. Koexistence těchto dvou formátů v ČR bude tedy ještě dlouho nevyhnutelná a byla by škoda, kdyby to negativně ovlivnilo tak slibně rozvinutou sdílenou katalogizaci („copy-cataloging“). Jak však stahovat záznamy z bází, které používají jiný formát? Umožňuje to konverzní program MarcMan, který se dá zabudovat i na server a může konvertovat záznamy on-the-fly. Jestliže toto knihovna využije, může své záznamy nabízet v obou formátech – vedle skutečné báze vytvoří navíc bázi virtuální. Národní knihovna takto dává k dispozici své záznamy z bází NKC, AUT a od ledna 2005 také SKC. Jediné, co musí uživatel na straně Z39.50 klienta udělat, je správné nastavení jména báze. Báze NKC, AUT a SKC jsou v MARC21, virtuální báze NKC-U, AUT-U a SKC-U vracejí záznamy již konvertované zpět do Unimarcu. Navíc 7


jsme pro zájemce o kódování UTF-8 zpřístupnili nedávno tyto báze pod jmény NKC-M8, NKC-U8 atd. – v ČR je standardní nastavení pro Z39.50 servery CP-1250. Detaily o přístupu k bázím NK přes protokol Z39.50 viz [5]. (Poznámka na okraj: k záznamům knihoven, které si serverovou verzi konvertoru nepořídily, je možné se dostat využitím nástrojů Jednotné informační brány tak, že si zájemce o stahovaní záznamů zařadí příslušnou knihovnu do svého profilu – více viz [6] )

5

Závěr

Národní knihovna používá systém Aleph již deset let. Stručně řečeno - naučila se s ním žít. S některými věcmi, které Aleph neuměl či stále neumí, jsme se se skřípěním zubů smířili, na některé se nám vyzrát podařilo. A daří se nám to tím lépe, čím víc se v komplikovaném systému vyznáme - jednou z jeho slabších stránek je bohužel dokumentace, a tak se stává, že teprve po nějaké době přijdeme na to, že problém vyřeší jiné nastavení. Katalogizační či výpůjční rutina se také dá nemálo zjednodušit, jestliže se využije všech nástrojů, které nabízí Aleph, ve spojení s cizím softwarem nebo vlastními programy. Takhle šetří našim katalogizátorům práci a omezují chybovost virtuální pole pro stahování údajů, fix-programy a na funkční klávesy navázaná „makra“. Ale to už by bylo téma pro jiný článek…

WWW odkazy a vybrané související materiály 1. 2. 3. 4. 5. 6. 7.

8.

9.

10.

11.

12.

http://sigma.nkp.cz (přehled databází NK ČR) http://skc.nkp.cz (báze SKC) http://sigma.nkp.cz/cze/adr (báze ADR) http://aut.nkp.cz/ (báze AUT) http://intra.nkp.cz/Aleph500/Z39_NK_cze.htm (info o Z39.50 serveru NK ČR) http://jib-info.cuni.cz/index.php?fname=jib.mnu&sub=2&url=metalib/ (JIB – stahování záznamů) Krčmařová, Gabriela; Trtíková, Ilona. CASLIN – Souborný katalog ČR na konferenci v Tallinnu : Část 1. Ikaros [online]. 2002, č. 12 [cit. 2002-12-01]. Dostupné na World Wide Web: . ISSN 1212-5075. Krčmařová, Gabriela; Trtíková, Ilona. CASLIN - Souborný katalog ČR na konferenci v Tallinnu : Část 2. Ikaros [online]. 2003, č. 01 [cit. 2003-01-01]. Dostupné na World Wide Web: . ISSN 1212-5075. Svobodová, Eva; Vyorálková, Danuše. Souborný katalog ČR pod systémem Aleph 500. In Knihovny současnosti 2003. Brno : Sdružení knihoven ČR, 2003, s.218-226. ISBN 80-86249-239. Svobodová, Eva; Hájková, Zuzana. Možnost stahování záznamů českých knihoven a perspektivy sdílené katalogizace v rámci souborného katalogu ČR a zkušenosti se stahováním záznamů v českých knihovnách. In Knihovny současnosti 2004. Brno : Sdružení knihoven ČR, 2004, s. 194 210. ISBN 80-86249-30-1. Dvořáková, Helena. Báze národních autorit v polovině roku 2002. Ikaros [online]. 2002, č. 11 [cit. 2002-11-01]. Dostupné na World Wide Web:

. ISSN 1212-5075.

Bartl, Zdeněk. Český projekt kooperativní tvorby národních autorit on-line aneb Jak to funguje v praxi. In INFOS 2003. Bratislava, Centrum vedecko-technických informácií SR, 2003. Dostupné na World Wide Web: .

8

Souborný katalog a Národní autority jak obejít omezení komerčního systému

Recommend Documents