Jak funguje Z39.50

Na konferenci Automatizace knihovnických procesů v roce 1999 v Ústí nad Labem poskytl Tomáš Rubringer [1] ve svém příspěvku "Protokol Z39.50" základní popis fungování protokolu Z39.50. Rubringerův popis je dobře srozumitelný i pro "netechnicky" zaměřené knihovníky a "technici" se jistě nebudou pohoršovat, jestliže zde pro dobro věci stručně zopakuji skutečnosti z jejich pohledu notoricky známé a naprosto jasné.

Z39.50 je standardizovaný aplikační protokol, který specifikuje komunikaci mezi klientem a serverem při vyhledávání informací v databázích a umožňuje také přejímání dat z databází.

Základní kroky komunikace:

Klient Z39.50 naváže spojení
Spojení navazuje klient zasláním tzv. Init požadavku, kterým se představí serveru a ve kterém navrhuje hodnoty parametrů (např. verze protokolu, ověření identity, podporované operace, maximální délka zprávy) nezbytných pro vytvoření Z39.50 relace tj. navázání interaktivní komunikace mezi konkrétním Z39.50 klientem a jiným konkrétním Z39.50 serverem.

Server Z39.50 odpoví
Server zareaguje zasláním Init odpovědi, ve které oznamuje klientovi své hodnoty parametrů a informuje ho, zda souhlasí s vytvořením Z39.50 relace.

Klient formuluje a odešle dotaz
Následně klient zformuluje dotaz a odešle jej jako tzv. Search požadavek.

Server hledá v databázích a zašle odpověď
Server prohledá databáze, vytvoří si množinu výsledných záznamů a odpovídá zasláním počtu prvků této množiny v Search odpovědi. V závislosti na počtu nalezených záznamů může tato odpověď obsahovat také některé či všechny nalezené databázové záznamy. Ostatní nalezené záznamy jsou pro klienta k dispozici prostřednictvím dodatečných dotazů, tzv. Present požadavků, po kterých následují Present odpovědi serveru obsahující požadované záznamy.

Ukončení spojení
Proces ukončení Z39.50 relace může zahájit jak klient, tak server, a to zasláním Close požadavku a obdržením Close odpovědi.

Jiné operace Z39.50
Kromě výše uvedených služeb Init, Search a Present nabízí protokol Z39.50 mnoho dalších operací, jako např. vyhledávání v uspořádaném seznamu (služba Scan), setřídění či zrušení množiny výsledků (služba Sort, resp.Delete), ověřování totožnosti klienta (služba Access-control), zasílání služebních informací (služba Resource-control), atd. Databázové záznamy musí vyhovovat některému z registrovaných formátů, přičemž 2. verze protokolu Z39.50 z roku 1995 podporuje patnáct především MARC-formátů (UNIMARC, USMARC, UKMARC, NORMARC, apod.).

Jako přenosová syntaxe záznamu je podporována struktura záznamu pro výměnu dat podle normy ISO 2709.

Z39.50 v praxi

Ačkoliv je představa o využití protokolu Z39.50 jako sjednocujícího prvku při sdílení informací mezi různými knihovnickými systémy velmi revoluční, v praxi je třeba zůstat na zemi. Aplikace využívající protokol Z39.50 mohou poskytovat jednotné rozhraní jen tehdy, budou-li tento protokol beze zbytku podporovat. Z39.50 je však protokolem velice rozsáhlým, takže ve skutečnosti každý systém založený na protokolu Z39.50 využívá spíše jen větší či menší podmnožinu jeho vlastností. Rozhraní těchto systémů jsou tedy sice založena na standardu protokolu Z39.50, avšak není zaručena jejich vzájemná kompatibilita. Při vytváření distribuovaných či virtuálních souborných katalogů je proto třeba, aby se zúčastněné strany dohodly na konkrétní množině podporovaných vlastností Z39.50, čili na tzv. profilu, jehož součástí jsou např. typy atributů a jejich hodnoty, syntaxe záznamů, velikost zpráv, apod. Pokud se v současnosti rozhodneme využívat služeb Z39.50 serverů, zjistíme, že různé servery mají nejenom odlišné vlastnosti, ale jejich chování je dokonce nezřídka v rozporu s protokolem Z39.50, takže je téměř nemožné vytvořit univerzálního Z39.50 klienta, který by dokázal komunikovat s libovolným Z39.50 serverem bez předchozí studie jeho chování. I přes tuto skutečnost přináší protokol Z39.50 určitá zjednodušení, např. zjednodušuje implementaci virtuálních souborných katalogů, protože rozdíly mezi chováním jednotlivých serverů nejsou zdaleka tak veliké, jaké jsou mezi systémy, které Z39.50 nepodporují.

Dobrým příkladem takového virtuálního souborného katalogu je kanadský národní souborný katalog známý jako vCuc - Virtual Canadian Union Catalogue, který byl vybudován v letech 1996 - 1998. Dvacet jedna účastníků vCuc (Národní kanadská knihovna, univerzitní knihovny, speciální i regionální knihovny) používá celkem devět různých knihovnických systémů (např. Geac, Sirsi, Endeavor, AMICUS, Zebra). Na začátku projektu již měla většina z nich protokol Z39.50 implementován. Vytvořit virtuální souborný katalog tedy většinou znamenalo "pouze sladit" protokol Z39.50 implementovaný v jednotlivých knihovnických systémech. Na základě několikaměsíčního pečlivého testování bylo nutné nakonfigurovat "shodné" Z39.50 klienty a servery v jednotlivých knihovnách (resp. upravit konfiguraci stávajících klientů a serverů). Je jistě zajímavé, že knihovny preferovaly vlastní vývoj Z39.50 klienta před jeho nákupem od svého dodavatele knihovnického systému. Nákup a úpravu Z39.50 serveru však ve valné většině případů realizovaly u producenta svého knihovního systému. V rámci realizace projektu nebyl stanoven jednotný profil Z39.50 pro vCuc, což se projevilo např. proměnlivými a nepřesnými výsledky při vyhledávání. Protokol Z39.50 obsahuje mnoho volitelných údajů (options), které jsou rozdílně interpretovány jednotlivými producenty knihovnických systémů. Stanovení jednotného profilu, který definuje jednotlivé atributy a jejich kombinace, může pomoci minimalizovat tento nedostatek. Jak napovídá název kanadského projektu "Využití Z39.50 k napodobení centralizovaného souborného katalogu" [2], jeho ambicí bylo poskytovat služby v kvalitě srovnatelné s centralizovaným souborným katalogem. V závěrečném hodnocení projektu se říká: "Cílem projektu bylo stanovit, zda protokol Z39.50 může být používán k napodobení centralizovaného souborného katalogu. Odpověď je ano, avšak jen pro některé jeho funkce. Stručně řečeno: Z39.50 zatím nemůže nahradit dobře spravovaný centralizovaný souborný katalog, rozhodně však poskytuje kvalitní nástroje k vyhledávání v katalozích omezeným přístupem a nástroj k získávání záznamů pro sdílenou katalogizaci."

Obtížnost dosažení skutečné kompatibility spolupráce knihoven na bázi protokolu Z39.50 ukazuje také ambiciózní projekt OCLC. V roce 1995 dostaly účastnické knihovny OCLC možnost on-line dodávání záznamů do báze WorldCat s využitím serveru a klientů Z39.50 s přesnou specifikací OCLC. Původně chtěl OCLC zcela zastavit dávkový import a export záznamů, ale na straně klientů se opakovaně vyskytovalo tolik technických problémů, že on-line dodávání záznamů s využitím protokolu Z39.50 zůstalo nadále jen jako alternativní.

Z39.50 včera a dnes

V 60. letech minulého století vznikaly ve světě první elektronické souborné katalogy. V 70. letech dala potřeba komunikace mezi elektronickými lokálními i soubornými katalogy a potřeba sdílení distribuovaných dat vzniknout komunikačnímu protokolu Z39.50. Jeho kořeny najdeme v roce 1970 v realizaci projektu Linked Systems Project. Protokol Z39.50 jako norma ISO 23950 existuje ve třech verzích: 1. verze z roku 1988, 2. verze z roku 1992 a 3. verze z roku 1995. Vznik protokolu iniciovali technici - přímo implementátoři, možná i programátoři. Neexistoval komunikační standard, jeho potřeba byla evidentní, možnost volné domluvy také. Standard byl vyvíjen jako knihovnický. Charakteristické je také to, že vývoj standardu a konkrétní implementace probíhaly v podstatě paralelně. Technici na více oddělených pracovištích občas (spíše však často) předbíhali standard. To se projevilo v tom, že standard existuje, neexistuje však snad žádná kompletní implementace. Kompatibilita je částečná, protože jde o kompatibilitu již existujících systémů (lokální knihovnické systémy) [3].

Na rozdíl od západního světa neměl v České republice v polovině 90. let 20. století implementován protokol Z39.50 ani jediný knihovnický systém, vedle toho si však knihovnická komunita plně uvědomovala potřebu sdílení dat a s ní související nezbytnost kompatibility knihovnických systémů. V současné době jiné komplexní funkční řešení komunikace nad existujícími knihovnickými systémy než protokol Z39.50 neexistuje. Je ale nutné si uvědomit, že nositelé "know-how" okolo Z39.50 mají minimální motivaci tento současný konsensus narušovat. Nevím, zda je v pořádku, že v době překotného rozvoje informačních technologií používají knihovníci k řešení kompatibility knihovnických systémů standard, který vznikl v 70. letech a jeho poslední verze je z roku 1995. Navíc trh pro Z39.50 je relativně malý, pevně ohraničený knihovnami, překotný rozvoj tedy ani v budoucnu nelze očekávat. Internet a jeho standardy knihovnické prostředí ovlivňují a pronikají do něj velmi snadno, protože nabízejí levná řešení vyvinutá pro mnohem větší trh. Protokol HTTP (třeba ve spojení s jazykem XML) představuje příliš lacinou a efektivní kombinaci, než aby mu protokol Z39.50 dokázal dlouho čelit, vzhledem k tomu, že podíl investic do něj vyznívá velmi nepříznivě ve srovnání s investicemi do webových technologií. A proto jsou technologie postavené na Z39.50 výrazně dražší a méně technologicky vyspělé, než technologie svázané se světem WWW [4].

Udržování vlastního odděleného knihovnického prostředí je drahé a je otázkou, na jak dlouho je vůbec reálné a zda je to účelné. Není to prostě jen tím, že milujeme ty své kamenné knihovny s knihami pěkně srovnanými na policích, a tak si jednu takovou budujeme přímo uvnitř sítě? - Data okleštěná MARCovým formátem, který okolní internetovský svět neumí číst a data vystavovaná a sdílená za zdí protokolu Z39.50, kam se nikdo jiný nedostane, protože odmítá tuto zeď zdolávat.

Budoucnost protokolu Z39.50

Je velmi obtížné předpovídat budoucnost protokolu Z39.50, zvláště v dnešní době, kdy vývoj informačních technologií ubíhá nesmírně rychle a nejeví žádné známky toho, že by se v nejbližší době mohl zpomalit.

Ačkoliv základní model fungování protokolu vznikl v 80. letech a ačkoliv jsme stále odkládali setkání protokolu Z39.50 s novými požadavky a potřebami uživatelů, nepřestal se používat [5]. Z39.50 nabízí vysoce strukturovaný a puntičkářsky přesný přístup do široké řady zdrojů, za přesně stanovených sémantických podmínek, které určují, jak pokládat dotaz, a přesně stanovené struktury, jak poskytovat data, čímž svazuje své uživatele do přesně definovaného informačního prostředí. Je to však správné v době, kdy je na internetu on-line k dispozici obrovské množství nejrůznějších informačních zdrojů?

Na počátku 90. let se implementace protokolu Z39.50 začaly šířit ve větším měřítku; byl zahájen vývoj 2. verze protokolu Z39.50. V roce 1990 vznikla ZIG - Z39.50 Implementor`s Group, která zodpovídá za technický rozvoj standardu Z39.50; zde probíhala rozsáhlá diskuse o tom, co je nezbytné udělat, aby byl Z39.50 vhodný pro širokou škálu dat přístupných na internetu. Členové ZIG věřili, že se Z39.50 stane všudypřítomným informačním vyhledávacím protokolem, což se projevilo v některých službách 2. verze protokolu. Jednou z nich byla možnost segmentace souborů, která umožňuje přenos objemných souborů dat (např. binární data jako audio, video, mutimediální data) nebo možnost určení celkové syntaxe záznamu, který tak poskytuje informace o svém formátu nebo obsahuje metadata o záznamu. V té době byl vyvíjen Z39.50 klient nejen pro integrované knihovnické systémy, ale také pro každodenní práci informačních pracovníků s předpokladem, že jej knihovníci budou instalovat na své počítače a používat raději než jiné produkty jako primární vstupní mechanismus k vyhledávání v internetových informačních zdrojích. To se však nestalo a klienti Z39.50 tohoto typu úplně zmizely. Obecně jsou přístupy do Z39.50 zdrojů realizovány prostřednictvím informačních bran založených na WWW, kde rozhraní pro koncového uživatele je browser.

Postupně stále rostl počet nových instalací Z39.50 a rozšiřoval se počet zdrojů, které poskytovaly alternativní přístup prostřednictvím Z39.50. Zvyšovala se funkcionalita protokolu, ten dnes nabízí bohatý rejstřík služeb, z nichž mnohé nejsou obecně známy, ale využívají je informační zdroje na webu. Protokol Z39.50 sliboval integrovaný přístup do širokého pole informačních zdrojů na webu, což by velmi uvítali všichni uživatelé webových služeb. Ovšem, pomineme-li informační brány založené na využití Z39.50, které existují v knihovnách, muzeích a podobných institucích, nebyl tento slib ještě naplněn.

Nezdá se, že by internetová nebo webová komunita braly nebo v budoucnu začaly brát Z39.50 příliš vážně, nebo jej chtěly převzít do svých používaných protokolů a technologií. Protokol Z39.50 není využíván při vývoji žádného protokolu ani nové technologie, kterými se zabývají významné instituce, jejichž centrem zájmu je internet (Worldwide Web Consortium - W3C a Internet Engineering Task Force - IETF). V některých případech jsou dokonce vyvíjeny nové technologie, které často duplikují využití různých mechanismů, které z velké části nabízí protokol Z39.50. Jsou to pokusy jak převzít Z39.50 a přiblížit jej komunitě, jejímž zájmem jsou technologie internetu (např. vazby mezi Z39.50 a URL, Z39.50 a http). Tyto snahy však nebyly příliš úspěšné, alespoň dosud.

Ačkoliv je Z39.50 používán k přístupu do velkých komerčních databází informačních zdrojů, žádný producent takového systému (s jednou či dvěma výjimkami) nenabízí Z39.50 jako základní část implementace, většinou tuto implementaci dodává dodatečně na žádost třetí strany (např. producenta systému pro knihovnu či muzeum). Protokol Z39.50 nebyl implementován na největší webové browsery a servery vendorů jako Netscape a Microsoft a zatím nebyly zaznamenány signály, že by k tomu mělo někdy dojít. Naproti tomu však stále více producentů automatizovaných knihovnických systémů podporuje kombinaci Z39.50 klienta a webových browserů. Tato kombinace poskytuje přístup do Z39.50 databází prostřednictvím oblíbeného WWW rozhraní webových browserů jako Netscape nebo Internet Explorer [6]. V rámci realizace projektu Mozilla má být realizováno napojení modulu Z39.50 na otevřené zdroje přístupné prostřednictvím Netscape. Dokonce i když bude tento projekt úspěšně dokončen, není vzhledem k rostoucí dominanci Internet Exploreru jasné, jaký to bude mít další dopad. Někteří producenti operačních systémů zpočátku se zájmem sledovali činnost ZIG a uvažovali o začlenění Z39.50 do svých produktů, k tomu však nikdy nedošlo a je nepravděpodobné, že se to někdy stane.

Konsorcium W3C ustanovilo skupinu, jejímž úkolem je vyvinout dotazovací jazyk pro XML. Ačkoliv jsou členové této pracovní skupiny zároveň odborníky na protokol Z39.50 a dokonce komunita pracující s protokolem Z39.50 požaduje stejný dotazovací jazyk také pro Z39.50, je zcela jasné, že pracovní skupina nemá zájem ani touhu pokusit se a využít nebo převzít Z39.50 ke splnění svého úkolu. Protokol Z39.50 spíše možná časem převezme dotazovací jazyk, který bude vyvinut v rámci W3C pro XML.

Z39.50 Implementor`s Group organizuje pravidelná osobní setkání v USA i v Evropě a dále velmi aktivně komunikuje v rámci elektronické konference ZIG. Právě zde v současné době probíhá diskuse o Z39.50 - Next Generation (ZNG), který by měl být rozhodně něco víc než jen pouhá revize původního protokolu Z39.50.

Závěr

Robustní aplikace protokolu Z39.50 v nejbližší době nezmizí ze své přesně definované komunity knihoven, muzeí apod., která si jej už zvykla používat. Má-li však i nadále kvalitně sloužit, je nutné usilovat o jeho rozšíření v prostředí webu a internetu. V praxi to znamená, že komunita kolem Z39.50 musí usilovat o zavádění technologií vyvinutých pro web a internet do protokolu Z39.50. Je totiž naprosto jasné, že opačného postupu, kdy by webovské a internetovské aplikace integrovaly technologie související se Z39.50, se zcela jistě nedočkáme.