Z39.50 – protokol z minulého století

V úvodu příspěvku je nutné věnovat několik slov jeho názvu, který byl ukraden ve víře, že skutečný autor se nepohorší
nad touto ignorací autorských práv. Pochopitelně jde o nadsázku, protože žijeme v prvním roce nového století a 99,99% věcí,
které nás obklopují, pocházejí ze století minulých. Cílem názvu je upoutat pozornost čtenáře a upozornit na to, že se
chystáme věnovat protokolu Z39.50 trochu jinak, než tomu bylo na stránkách ITlib dosud.

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 pro dobro věci zde 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 15 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 (http://www.nlcbnc.ca), 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ů realizovali 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, které mají omezený přístup, 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. Nutno si ale 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á zdolávat tu zeď.

Budoucnost protokolu Z39.50

Je velmi obtížné předpovídat budoucnost protokolu Z39.50, zvláště v době jako je ta dnešní, 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 množství nejrůznějších informačních zdrojů?

Informační prostředí dnešního světa je úplně jiné než bylo na počátku 90. let, kdy se ve větším měřítku začaly šířit
implementace protokolu Z39.50. Lidé byli nadšeni novým systémem nazvaným Gopher, který sliboval úžasné možnosti pro přístup k
informacím a vědci v CERNu vyvíjeli malý systém nazvaný World Wide Web, který byl skutečně určený pouze pro fyziky. Ti jej
chtěli původně využít jen k organizaci informací ve svém oboru, Tim Berners-Lee však začal brzy tušit, že by World Wide Web
mohl být užitečný i pro jiné typy dat.

Na začátku 90. let, kdy byl zahájen vývoj 2. verze protokolu Z39.50, probíhala v rámci ZIG (Z39.50 Implementor‘s Group)
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.

Zatím WWW rostl a mohutněl, zvláště s příchodem grafických browserů se internet otevřel uživatelské komunitě a
aplikacím před několika málo lety nemyslitelným. Růst informací zpřístupněných prostřednictvím WWW byl astronomický. Otevřel
se nový trh a počet podnikatelů, kteří do něj pronikali, byl neuvěřitelný. Díky WWW vzniklo nové průmyslové odvětví,
technologie, způsoby realizace obchodu, vazby mezi lidmi a organizacemi, vznikla nová komunita, apod. Jaký budou mít tyto
skutečnosti dlouhodobý dopad, lze těžko odhadnout, a pokud bychom se o to pokusili, pohybovali bychom se na úrovni fantazie a
science fiction. Protokol Z39.50 sehrál ve všem tomto dění zcela nepatrnou úlohu. To však neznamená, že se během této doby
nevyvíjel v rámci své komunity. Stále rostl počet nových instalací 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.

V roce 1990 vznikla ZIG – Z39.50 Implementor’s Group, která zodpovídá za technický rozvoj standardu Z39.50. Skupina
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.

Použitá literatura:

RUBRINGER, Tomáš. Z39.50. Ikaros [on-line]. 1999, č.8 [cit.2001-29-01]. Dostupný z: URL:
http://ikaros.ff.cuni.cz/1999/c08/usti/usti_rubringer.htm

LUNAU, Carrol C. The Virtual Canadian Union Catalogue Project (vCuc): Using Z39.50 to Emulate a Centralized Union
Catalogue. Resource Sharing & Information Networks, 2000, vol. 14, no. 2, s. 21 – 35.

PSOHLAVEC, Stanislav. Z39.50 versus (?) XML. Národní knihovna, 2001, roč. 12, č. 1, s. 46 – 46.

ŘEHÁK, Tomáš. Jahody, počítače a standardy v knihovně. Čtenář, 2001, roč. 53, č. 6, s. 169 – 172. Dostupný též z:
URL:
http://www.mlp.cz/cz/doc/jahody.htm 

NEEDLEMAN, Mark. Z39.50 – A Review, Analysis and Thoughts on the Future. Library Hi Tech, 2000, vol. 18, no. 2, s.
158 – 169.

BOSS, Richard W. Interfaces. Library Technology Report, 2000, vol. 36, no. 4, s. 49 – 64.