Vývoj protokolu Z39.50

Protokol Z39.50 má své kořeny v roce 1970. Tehdy se tři organizace v USA: Library of Congress, Online Computer Library Center (OCLC) a Research Libraries Information Network pokusily o zavedení standardizovaných prostředků pro vyhledávání informací v jejich bázích dat. Primárním cílem byla podpora sdílené katalogizace využívající národní bibliografickou databázi a až na druhém místě byla snaha poskytnout koncovému uživateli jednotný pohled na velký počet autonomně spravovaných databází. Tento projekt nesl označení Linked Systems Project. Původně se účastníci projektu podíleli jak na specifikaci protokolu, tak na jeho implementaci, avšak postupně se jejich zájem posunul směrem k implementaci, zatímco záštitu nad vývojem specifikace převzala organizace National Information Standards Organization (NISO).

V roce 1979 byla v rámci NISO vytvořena tzv. komise D. Jednalo se o skupinu expertů, kteří pracovali na tvorbě nového standardu. V roce 1988 byl zveřejněn první standard s dlouhým názvem ”American National Standard Z39.50, Informational Retrieval Service Definition and Protocol Specification for Library Applications”.

Koncem osmdesátých let přibylo mnoho organizací, které se o Z39.50 začaly zajímat i z jiného pohledu než byl Linked Systems Project. V té době existovala na mezinárodní scéně komplikovaná množina jiných standardů. Mezinárodní komise ISO Technical Committee 46 Subcommittee 4 vyvinula protokol s označením Search and Retrieve (SR), který byl téměř identický se Z39.50 a byl standardizován pod označením ISO 10162/10163. Za této situace vznikla potřeba vytvořit novou verzi Z39.50 tak, aby jednak lépe vyhovovala implementátorům a jednak aby byla kompatibilní s uvedeným ISO standardem.

V roce 1989 se vývoje protokolu ujala organizace Z39.50 Maintenance Agency, spravovaná Knihovnou amerického Kongresu, jejímž prvotním úkolem bylo sladit americký protokol s ISO standardem. Komise D se rozpadla a její fukci převzala v roce 1990 neoficiální skupina implementátorů Z39.50 Implementators Group (ZIG). Další vývoj protokolu tak probíhá za spolupráce Z39.50 Maintance Agency a ZIG. Výsledkem všech těchto událostí bylo přijetí nového standardu protokolu Z39.50 v roce 1992, označovaného jako Z39.50-1992 nebo jako verze 2.

V letech 1992-1993 byl spuštěn program Z39.50 Interoperability Testbed, jehož smyslem bylo usnadnit vývoj implementací Z39.50 na Internetu. Velká většina implementátorů zúčastněných v projektu Testbed byly prodejci knihovnických automatizovaných systémů a také poskytovatelé universitních a knihovnických databází. Projekt slavil úspěch a umožnil tak vznik množství navzájem komunikujících Z39.50 klientů a serverů přes TCP/IP, čímž si protokol Z39.50 získal přízeň knihovnické obce.

Zatímco se Z39.50-1992 stával obecně rozšířeným standardem, ZIG zahájila práci na nové, ambiciozní verzi 3. Zatímco verze 2 byla vybudována na funkcích standardu Z39.50-1988 a ISO 10162/10163, verze 3 vznikala na základě konkrétních připomínek jednotlivých členů ZIG a představuje tedy určitý koncensus. Výsledný produkt byl schválen v roce 1995 a označuje se tedy jako Z39.50-1995 nebo jako verze 3. V březnu 1997 byla verze 3 uznána jako ISO standard s označením ISO 23950.

V současnosti jsou v plném proudu práce na propojení Z39.50 s různými jinými standardy. Pro Z39.50 dotazy bylo například definováno vlastní URL. Existuje také snaha o začlenění SQL jako dotazovacího jazyka pro Z39.50 (projekt Z+SQL). Samozřejmě, diskutuje se také o možném vývoji verze 4. Obecně se má za to, že budoucí verzi standardu bude třeba zjednodušit a zefektivnit a také důkladná zpětná kompatibilita, charakteristická pro přechod ze Z39.50-1992 na Z39.50-1995, nemusí být v budoucí verzi nutně implementována.

O čem je Z39.50

Jedná se o standardizovaný protokol pro vyhledávání a přejímání dat. Z39.50 specifikuje abstraktní informační systém s velkou množinou funkcí pro vyhledávání a přejímání záznamů, procházení uspořádaných seznamů, atd. Na straně serveru je tento abstraktní systém mapován na konkrétní systém správy bází dat. Komunikace mezi serverem a klientem je přesně definována protokolem. Implementační detaily serveru jsou zakryté síťovým rozhraním, takže klient může přistupovat k libovolnému typu databáze prostřednictvím stále stejného protokolu. Na straně klienta je abstraktní informační systém zpětně namapován na uživatelské rozhraní, které může být šité na míru konkrétním požadavkům uživatele. Výhodou Z39.50 tedy je, že umožňuje odlišným informačním zdrojům vystupovat pod jednotným uživatelským rozhraním a současně dává každému informačnímu systému možnost vytvořit několik rozhraní pro odlišné skupiny uživatelů.

Jak Z39.50 pracuje

Komunikace, služby

Z39.50 je aplikačním protokolem, který specifikuje komunikaci mezi klientem a serverem při vyhledávání informací v bázích dat. Spojení navazuje klient zasláním tzv. Init požadavku, kterým se představí serveru a ve kterém navrhuje hodnoty parametrů nezbytných pro vytvoření Z39.50 relace (verze protokolu, ověření identity, podporované operace, maximální délka zprávy, apod). Server zareaguje zasláním Init odpovědi, ve které oznamuje klientovi hodnoty parametrů a informuje ho, zda souhlasí s vytvořením Z39.50 relace. Následně klient zformuluje dotaz (seznam bází plus termy k vyhledání s hodnotami atributů, pospojované boolskými operátory) a odešle jej jako tzv. Search požadavek. 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.

Ve verzi 2 server vkládá odpověď do jedné jediné zprávy. Pokud je odpověď příliš dlouhá, jednoduše ji ořízne tím, že zašle méně záznamů, než o které byl požádán. Klient potom musí znovu žádat o chybějící záznamy a tato nadbytečná komunikace se serverem zpomaluje jeho činnost. Ve verzi 3 server může server vložit odpovědˇ do posloupnosti po sobě jdoucích zpráv (segmentů), bez interakce s klientem. Tento proces se nazývá segmentace (prvního stupně) odpovědi. Může se ovšem stát, že i jednoduchý záznam je natolik rozsáhlý, že se nevejde do segmentu. V takovém případě je záznam rozřezán na tzv. fragmenty, ty jsou vloženy do segmentů a celý záznam je zaslán v několika zprávách. Tuto situaci nazýváme segmentací 2.stupně.

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.

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.

Formáty

Z39.50-1995 podporuje 6 typů dotazu: Type-0, Type-1 (obrácená polská notace), Type-2 (ISO 8777), Type-100 (ANSI Z39.58), Type-101 (rozšířená RPN) a Type-102 (Ranked List Query). Standard přikazuje povinnou podporu Type-1 dotazu, který je vyjádřen jedním či kombinací více termů. Každý term má svoji množinu atributů, která určuje například strukturu termu nebo jeho typ. Server je zodpovědný za mapování atributů na logickou struktutu databáze. Termy jsou v dotazu kombinovány pomocí boolských operátorů, syntaxe dotazu je vyjádřena v obrácené polské notaci (RPN).

Atributy, přiřazené termu, náleží do společné množiny atributů, jejíž definice je registrována, tzn. že této množině je přiřazen jednoznačný globální identifikátor, tzv. identifikátor objektu (OID). Z39.50 uznává 6 různých množin atributů: Bib-1, Exp-1, Ext-1, CCL-1, GILS a STAS.

Protokol rozlišuje 2 druhy záznamů, které se mohou vyskytnout v odpovědi serveru: jsou to záznamy databázové a diagnostické. Databázové záznamy musí vyhovovat některému z registrovaných formátů, přičemž Z39.50-1995 podporuje 15 formátů záznamu: Unimarc, Intermarc, CCF, USmarc, UKmarc, Normarc, Librismarc, Danmarc, Finmarc, MAB, Canmarc, SBN, Picamarc, Ausmarc a Ibermarc. Diagnostické záznamy server posílá v případě, že z nějakých důvodů není schopen obsloužit dotaz. Jsou akceptovány 2 druhy registrovaných diagnostických formátů, a to Bib-1 a Diag-1.

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

Využití Z39.50 v knihovnictví

V knihovnickém prostředí lze protokol Z39.50 využít zejména k:

Z39.50 a STK

Ve Státní technické knihovně byl nad bázemi knih a časopisů vytvořen experimentální Z39.50 server, který nabízí základní vlastnosti Z39.50-1992. Server byl koncipován jako portabilní a platformově nezávislý. Server totiž k bázi dat nepřistupuje přímo, nýbrž prostřednictvím volání dvou pomocných skriptů, posazených nad vlastními daty, což zaručuje snadnou přenosnost i na systémy s jinými způsoby správy dat, protože stačí vždy přeprogramovat pouze uvedené dva skripty. Platformovou nezávislost zaručuje zvolený programovací jazyk C++, jehož překladače existují pro všechny operační systémy. Server má implementovány operace Init, Search a Present, očekává dotaz v obrácené polské notaci (type-1) s nejvýše třemi termy ohodnocenými atributy z podmnožiny množiny Bib-1. Server zasílá záznamy v syntaxi Unimarc v kódování ISO 8859-2. K dispozici je na počítači alex.stk.cz na TCP portu 8888.

Z39.50 z praktického hlediska

Ačkoli 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ů, velikosti 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 mnohá zjednodušení. Usnadňuje například přejímání autorit, protože záznam s sebou nese informaci o použitém formátu. Velký přínos Z39.50 je však zejména v tom, že výrazně zjednodušuje implementaci 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í.

Příklady projektů

• Project ONE – Virtuální síť evropských knihovnických systémů s jednotným Z39.50 profilem; vývoj softwaru (http://www.dbc.dk/ONE/oneweb/index.html)

Odkazy

1. Specifikace Z39.50-1995 : http://lcweb.loc.gov/z3950/agency/1995doce.html
2. Přehled Z39.50 projektů : http://lcweb.loc.gov/z3950/agency/projects/projects.html
3. Katalogy se Z39.50 rozhraním : http://lcweb.loc.gov/z3950/gateway.html
4. Definice Z39.50 profilů : http://lcweb.loc.gov/z3950/agency/profiles/profiles.html
5. Dostupný Z39.50 software : http://lcweb.loc.gov/z3950/agency/projects/software.html
   http://www.dbc.dk/ONE/oneweb/soft.html