Kossuth Lajos Tudományegyetem
Természettudományi Kar

A Z39.50 információkeresési 
szabvány és alkalmazása

Burmeister Erzsébet
 informatikus könyvtáros

Témavezető: Boda István tanársegéd

Debrecen
1996

TARTALOM
1. Bevezetés
2. A szabvány jellemzése
2.1. A szabvány története
2.2. A szabvány jelentősége
3. A szabvány ismertetése
3.1. Az információkeresés modellje a Z39.50 alapján
3.2. Az információkeresés lehetőségei
3.3. Üzenetméret, rekordméret, szegmentálás
3.4. Műveletek és a hivatkozási azonosító
3.5. Párhuzamos műveletek
4. A keresés részletes elemzése
5. A lekérdezés és megjelenítés elemzése
6. A Z39.50 és a World Wide Web
6.1. A Z39.50 és a WWW összekapcsolása
7. Létező Z39.50 alapú alkalmazások
7.1 Néhány európai Z39.50-re alapuló projekt
7.2. Kereskedelmi alkalmazások
7.3. Az Internet hálózatról letölthető Z39.50 kliens programok
8. Gondolatok a KözElKat projekttal kapcsolatban
Irodalomjegyzék

1. Bevezetés
Szakdolgozatom tárgya a Z39.50 szabvány és alkalmazása.

Napjainkban az Internet egyre szélesebb körű elterjedésével egyre többen lekérdezhetik a hálózaton található információkat, köztük az adatbázisokat és a könyvtári rendszereket. Azonban a hagyományos könyvtári rendszereken keresztül a felhasználó csak a helyi adatbázisokat éri el. Ahhoz, hogy egy távoli rendszer adatállományaihoz is hozzáférhessen, be kell a távoli gépbe jelentkeznie és az ottani rendszer felhasználói felülete segítségével kereséseket végrehajtani. Hatékony keresésekhez tehát több rendszert is tanulmányoznia kell. Ez a tapasztalatlan felhasználó számára nehézségekkel jár, meglehetősen időigényes. Ezen felül a megtalált adatok átvétele is sokszor bonyolult eljárások elvégzését kívánja meg.
Az ideális az volna, ha a felhasználó egy számára jól ismert felhasználói felület segítségével minden, számára fontos adatállományt elérhetne. Ez a gondolat az alapja a Z39.50 szabvány létrehozásának. A Z39.50 révén az eddig csak helyben rendelkezésre álló funkciók távoli adatállományokra is kiterjeszthetők. A felhasználó szempontjából nincs többé észrevehető különbség a helyi és távoli adatbázisok között.
A Z39.50 szabvány alkalmazása alapvetően két területen jelent észrevehető változást.
I,	Amerikában és Nyugat-Európában már megtörtént a könyvtári katalógusok számítógépre vitele, létrejöttek az ún. OPAC-ok. (Nálunk is sok helyen elkezdték már építeni az online katalógusokat). De ezek a katalógusok még olyan értelemben nem “szabványos” hálózati alkalmazások, hogy az Internet leginkább használt kereső rendszereivel, a Gopherral vagy a WWW‑n közvetlenül nem érhetők el, csak úgy, ha egy ún. telnet kapcsolattal kilép belőlük az ember, majd a keresés elvégeztével visszatér. És a különböző OPAC ‑ ok mind más rendszerrel működnek. Mindennek az oka a könyvtári rendszerek mögött levő adatbázisok különbözősége és ennek megfelelően az alkalmazások különbözősége. A Z39.50 úgy nyújt megoldást erre a problémára, hogy az adatbázisok keresését szabványosítja. Tehát ha a könyvtári rendszer hátterét adó adatbázishoz létezik a Z39.50 szabványnak eleget tevő ún. Z-szerver, akkor ezt a könyvtári rendszert már tetszőleges, a Z39.50 szabványnak megfelelő ún. Z‑klienssel keresni lehet. Ugyanígy adott Z39.50 klienssel bármilyen Z‑szerverrel rendelkező könyvtári rendszert keresni lehet. És a legtöbb Z39.50 szerverhez létrehozzák a HTML => Z39.50 gateway szoftvert is, hogy a Z39.50 szerver a WWW-n keresztül közvetlenül elérhető legyen.
II,	A Z39.50 nemcsak az adatbázisok keresését szabványosítja, hanem a visszakeresett adatbázisrekordok formátumát is. A Z39.50 alapú keresés után megmaradnak a találatok. Ez a két tulajdonság, vagyis a szabványos rekordformátum és a megőrzött találatok lehetővé teszik a találatok további feldolgozását. Ez jelentős változást jelent, mert az Internet többi kereső rendszerénél egyrészt nincs lehetőség könyvtári adatbázisok keresésére, másrészt a keresés eredménye nem szabványos rekordformátumban jelenik meg. A rekordok további felhasználása - könyvtári területen maradva - a különböző könyvtári szolgáltatások összekapcsolását teszi lehetővé. Például egy tartalomjegyzék szolgáltatásban megtalált cikk rekordját továbbítani lehet valamely más szolgáltatáshoz a cikket tartalmazó folyóirat lelőhelyének meghatározására ill. a cikket meg lehet rendelni a rekordot felhasználva.
Végül is elmondható az, hogy a Z39.50 szabvány alkalmazása a felhasználó kényelmét szolgálja, egy felületen keresztül keresheti a számára fontos könyvtári adatbázisokat - anélkül hogy egyáltalán tudna a Z39.50 létezéséről - és a találatokat más könyvtári szolgáltatásokhoz felhasználhatja. A könyvtári alkalmazások “szabványos” hálózati alkalmazásokká válnak és az egyes könyvtári szolgáltatásokat integrálni lehet egymással.

Dolgozatomban foglalkozom a szabvánnyal, egyre növekvő jelentőségével, kitérek a történetére, bemutatok néhány alkalmazást, elemzem a WWW-vel való kapcsolatát és pár gondolatot kifejtek a jelenleg folyó KözElKat projektről.

2. A szabvány jellemzése
2.1. A szabvány története
A Z39.50 amerikai nemzeti szabvány, hivatalos elnevezése: ANSI / NISO Z39.50‑1995, Information Retrieval (Z39.50) Application Service Definition and Protocol Specification. Az ANSI (American National Standard Institution) az amerikai nemzeti szabványok kiadásával foglalkozó intézet, a NISO (National Information Standards Organization) a nemzeti információs szabványokkal foglalkozó szervezet.
A szabvány elkészítését 1984-ben bibliográfiai információ kezelésére javasolták. 1988-ban jelent meg a Z39.50-1988, melyet a NISO egy albizottsága készített el. Ezt a bizottságot a Z39.50-1988 megjelenése után feloszlatták és a helyébe a Z39.50 Maintenance Agency (Z39.50 Karbantartó Ügynökség) lépett a Library of Congress (Kongresszusi Könyvtár) igazgatásával.
Az érdeklődés nőtt a szabvány iránt és 1990-ben megalapították a Z39.50 Implementors Group-ot, a ZIG-et, a Z39.50-et alkalmazók csoportját. Tagjai információ előállítók, tanácsadók, információszolgáltatók, egyetemek, melyek különböző típusú információkat szeretnének elérni illetve szolgáltatni, legyen az az információ akár bibliográfiai, akár szöveges, képi, pénzügyi, közszolgálati, vegyészeti, hír. ZIG tagság minden érdekelt részére lehetséges.
1992-ben megjelent a Z39.50-1988 átdolgozása a Z39.50-1992. A Z39.50 Maintenance Agency-t azzal bízták meg, hogy úgy dolgozza át a Z39.50-1988-at, hogy az a nemzetközi ISO 10162/10163, Search and Retrieve szabvánnyal bit-szinten kompatibilis legyen és így a Z39.50-1992 az SR-t részhalmazként tartalmazza. Ezen munkálatok miatt egyéb fontos változtatások nem kerültek be a szabványba.
A Z39.50-1995 fejlesztése már 1991-ben elkezdődött. A ZIG minden gyűlésére 1991-től 1994 áprilisáig a Z39.50 Maintenance Agency újabb változatot készített el. A változatokat megvitatták az Interneten egy levelező lista keretében és a ZIG gyűléseken is. 1994 áprilisában a ZIG azt javasolta, hogy a legutolsó változat legyen végleges.
Az 1992-es változat lett a “2-es verzió”, az 1995-ös változat a “3-as verzió”.
A Z39.50-1988 változat elavult, a Z39.50-1995 tartalmazza a Z39.50-1992-t kompatibilis módon, vagyis a 3-as verzióban mindig vannak utalások arra, hogy mi az új a 2-es verzióhoz képest, amit az még nem tartalmaz. Mind a két újabb változat érvényben van.
2.1.1. A Z39.50 és az SR
A Z39.50 valójában nemzeti amerikai szabvány, melyet a NISO fejlesztett ki, az SR viszont nemzetközi szabvány, az ISO terméke.
A nemzetközi SR részhalmaza az amerikai Z39.50-nek. A Z39.50-nek ezért nagyobb a hatásköre, s ezért gyakrabban választják, mint az SR-t. A legtöbb SR alkalmazás Európában található. Az egymást fedő részeikben nagymértékben kompatibilisek és az SR képes a Z39.50-nek azokat a részeit mellőzni, melyeket ő nem ismer és csak a fennmaradó részeket hajtja végre.
Az SR-t az ISO TC46/SC4/WG4 (Technical Committee 46 Subcommittee 4 for Search and Retrieval = 46-os Műszaki Bizottság 4-es Keresési és Visszakeresési Albizottsága) fejleszti. A két SR szabvány (10162 és 10163) létezésének oka az, hogy az ISO SR leírás két részre van felosztva:
- szolgáltatások meghatározása, ami az információ visszakeresési szabvány feladatait határozza meg
- protokoll megadása. (lásd 9. o. lábjegyzet, protokoll definíciója)
A Z39.50 ezt a két részt egy szabványban egyesíti.
Nyilvánvaló, hogy két különböző szabvány fenntartása nehézségekkel jár és a felhasználóknak is nehéz a döntés, melyiket alkalmazzák. Egy idő óta vitatják a két szabvány összeolvasztásának lehetőségét, de végső döntés még nem született.

2.2. A szabvány jelentősége
2.2.1. A szabványok fontossága
Ismert és sokat hangoztatott tény, hogy ma egy könyvtár egymagában nem élhet meg, hisz sehol a világon nincs a könyvtáraknak elegendő pénzügyi forrásuk az egyre növekedő számú és árú dokumentumot beszerezni. De olvasóikat mégis el szeretnének látni a számukra fontos dokumentumokkal ill. információkkal. Ennek az ellentmondásnak a feloldására egyetlen megoldás az együttműködés. Együttműködni viszont csak megfelelő keretek között lehet. Régebben a könyvtáraknak elég volt a saját céljaiknak megfelelően kialakított szabályrendszer (katalógus, kölcsönzési rendszerek, stb.) minden vonatkozásban. De ma, amikor a technikai feltételek már megvannak a hálózati kapcsolódáshoz, országos szinten és az egész világra kiterjedően egységesíteni kell az együttműködéshez szükséges szabályrendszert. Ezt biztosítják az egymással kapcsolódó és egymásra épülő szabványok. Az egységes bibliográfiai leírás céljaira létrehozták a 60-as években az ISBD szabványokat, a számítógépes katalogizálás bevezetése után az adatcsere biztosítására a különböző MARC szabványokat. De ezek a szabványok csak a dokumentumok bibliográfiai leírására és egységes besorolására adják meg a szabályokat. A könyvtárhasználók meg is szeretnének találni a dokumentumokat ill. az információkat. A keresés céljaira minden számítógépes rendszer más megoldást kínál és ez a tény nagyon megnehezíti a gyorsan céljukat elérni kívánók dolgát. Ezért merült fel a 80-as években a szükségessége annak, hogy a különböző szerkezetű adatbázisokban tárolt információkat egységes módon lehessen keresni s megszületett a Z39.50, az információkeresési szabvány is. A megfelelő dokumentum ill. információ megkeresése után a következő feladat ennek a megszerzése vagy megjelenítése. A dokumentumok fizikai kézbeadását végző könyvtárközi kölcsönzést az ILL (Interlibrary Loan=könyvtárközi kölcsönzés ISO 10160/1) szabvány támogatja.
A szabványok szoros kapcsolatát kiválóan példázza az a tény is, hogy maga a Z39.50 szabványban 15 más szabványra történik hivatkozás és pl. a Z39.50 üzeneteit, vagyis az ún. adategységeket (APDUs, application protocol data units) az ISO 8824-es (ASN.1 Abstract Syntax Notation One) szabvány segítségével írják le.
2.2.2. A szabvány fontosabb jellemzői
•	Mint hálózati alkalmazási szabvány a Z39.50 egy nyitott szabvány, mely lehetővé teszi különböző hardver és szoftver alapokon nyugvó rendszerek egymás közti kommunikációját.
•	A Z39.50-en alapuló információkeresés gyökeresen különbözik az adatbázis keresés hagyományos módszereitől, ahol a kereső a helyi terminálját használva bejelentkezik a távoli rendszerbe és ott a rendszer saját menüit és parancsnyelvét használja. Ez a régi módszer tapasztalatot és sok gyakorlatot kíván, ha a felhasználó hatékony kereséseket akar végezni. A szabvány nem ad meg ugyan szabványos felhasználói felületet, hiszen ez egy konkrét rendszert tételezne fel, de megadja azokat a szabványos módszereket, amelyek segítségével egy konkrét felhasználói felületen keresztül szerverekkel lehet kommunikálni.
•	A Z39.50 nemcsak a kliens és szerver közti üzeneteket szabványosítja, hanem a kereső kérdés szerkezetét és szemantikáját, az üzenetek cseréjének sorrendjét is. Támogatja a találatok visszajuttatásának mechanizmusát és ez azért fontos, mert ezáltal strukturált adatszerkezetek átvitelére van lehetőség, aminek révén lehetséges az adatok újrafelhasználása más alkalmazásokban (pl. a találatok továbbítása megrendelés céljából).
•	Végül, de nem utolsó sorban előnyös az is, hogy a keresőnek nem kell ismernie a szabványt részleteiben.
2.2.3. A Z39.50-en alapuló keresés menete
A Z39.50 programok közti protokoll. A felhasználó nem látja, sőt ideális esetben nem is tud a Z39.50 létezéséről. A felhasználó a felhasználói felületet látja maga előtt: ez lehet része egy integrált rendszernek vagy lehet része egy önálló Z39.50-es alkalmazásnak. Mivel a kliens és szerver közötti kapcsolat szabványosított, a Z-kliens nyíltan kommunikálhat tetszőleges Z-szerverrel a hálózaton keresztül. Tehát a felhasználó ugyanazon a felhasználói felületen látja adatbázisok sokaságát.
A protokoll olyan formátumokat és műveleteket határoz meg, melyek a kliens és a szerver közötti üzenetek cseréjét irányítják. A kliens kérést intéz a szerverhez egy adatbázis lekeresésére és a feltételeknek megfelelő rekordok azonosítására, majd az azonosított rekordok megjelenítésére.
A keresési és megjelenítési protokoll kliens - szerver környezetben működik. A Z39.50 szabvány terminológiája szerint a kliens oldalon van az eredet, a szerver oldalon a cél. Az ábrán látható a műveletek sorrendje: A kliens végen a kliens a felhasználó kérését “Z39.50”-be lefordítja és elküldi a célnak. A szerver oldalon a cél a kérést úgy alakítja át, hogy az az adatbázis alkalmazás számára érthető legyen. Az adatbázis alkalmazás, mely általában egy adatbázis kezelő, a kérést feldolgozza, a kért információ helyét meghatározza és visszaadja ezt a célnak. A cél ezt továbbítja az eredetnek, mely a kliensen futó felhasználói alkalmazás számára érthető és megjeleníthető formába visszaalakítja.

A Z39.50 definíciója Dempsey szerint: “A Z39.50 alkalmazási szintű protokoll, amely támogatja az osztott információkeresési alkalmazásokat.. Itt az OSI (Open Systems Interconnection) hét szintű modellra hivatkozik, ahol az alkalmazási szint a hetedik szint. Ez a szint foglalkozik az adatfeldolgozással.
Egy Z39.50 kliens elvileg képes akármilyen Z39.50 szerverrel való kommunikációra és egy Z39.50-es szervert elvileg bármely Z39.50 kliens le tud keresni.

3. A szabvány ismertetése
Alkalmazási terület: Olyan alkalmazások, melyek számítógépes adatbázisok rekordjainak lekérdezésével foglalkoznak.
Alkalmazói kör: A szabvány célja olyan szervezetek támogatása, melyek információkereső rendszereket tartanak fenn, mint pl. információs központok, egyetemek, könyvtárak.
A szabvány első részében leírja az infomációkeresési szolgáltatásokat, a második részében a protokollt adja meg. A szolgáltatások a szabvány által támogatott lehetőségeket jelentik (pl. keresés, rendezés, stb.), a protokoll a lehetőségek megvalósításához szükséges üzenet- és adatformátumokat és eljárásokat határozza meg. A leírás teljesen absztrakt fogalmakkal dolgozik, konkrét számítógépes implementációt nem ismertet.

3.1. Az információkeresés modellje a Z39.50 alapján
Az információkeresés a szabvány értelmében két alkalmazás között lezajló műveleteket jelent. Az egyik a kezdeményező alkalmazás, a kliens, a másik a válaszadó alkalmazás, a szerver. A kliensre eső Z39.50 protokoll eljárásokat az eredet, a szerverre eső protokoll eljárásokat a cél hajtja végre.
Egy alkalmazási kapcsolaton (A-kapcsolaton) belül jön létre a cél és az eredet között a Z39.50 kapcsolat, a Z-kapcsolat. A Z kapcsolatot az eredet hozza létre és az eredet vagy a cél fejezi be. Egy A kapcsolaton belül több Z kapcsolat is lehetséges. A műveletek követhetik egymást ill. párhuzamosan folyhatnak egy Z kapcsolaton belül. Az eredet és a cél szerepe nem cserélhető fel a Z kapcsolaton belül. A Z kapcsolatot nem lehet újraindítani.
3.1.1. A Z39.50 szolgáltatásai
A Z39.50 szolgáltatások az eredet és a cél közötti üzenetek cseréjével valósulnak meg. Az üzenet vagy kérés, vagy válasz. Például kezdeményezési kérés és kezdeményezési válasz, keresési kérés és keresési válasz, böngészési kérés és böngészési válasz, stb., ahol a kezdeményezés, keresés, böngészés egy-egy szolgáltatás. A szolgáltatások lehetnek visszaigazoltak, nem visszaigazoltak és feltételesen visszaigazoltak. Visszaigazolt szolgáltatás az a szolgáltatás, ahol a kérést válasz követi. A kérést vagy az eredet vagy a cél küldi. Pl. a keresés az egy visszaigazolt szolgáltatás, az eredet elküldi a célnak a keresési kérést és a cél válaszol a keresési válaszban. Vannak nem visszaigazolt (a kéréshez nem tartozik válasz) és feltételesen visszaigazolt szolgáltatások (a kérést követheti válasz).
3.1.2. A Z39.50 műveletei
A szabvány 8 műveleti típust ír le: kezdeményezés (Init), keresés (Search), megjelenítés (Present), törlés (Delete), böngészés (Scan), rendezés (Sort), erőforrásjelentés (Resource report) és kibővített szolgáltatások (Extended services). Az eredet adott műveleti típusú kérését a cél ilyen típusú válasza zárja le. Csak az eredet kezdeményezhet műveletet és nem minden kérés kezdeményez műveletet.
Az eredet szemszögéből a művelet a kezdő kérés kibocsátásával kezdődik és a lezáró válasz megérkezésével fejeződik be. A cél szemszögéből a művelet akkor kezdődik, amikor a kezdő kérés befut az eredettől és akkor fejeződik be, amikor a cél elküldi a lezáró választ.
3.1.3. Az adatbázis modellje
A szabvány célja a kliensek és szerverek közötti nyílt együttműködés megkönnyítése, amikor is a kliensek lekérdezik a szerver adatbázisait. A különböző rendszerek adatbázisai nagyon különböznek egymástól az adatok tárolását és azok elérését tekintve. Ezért egy közös, mindenütt használható absztrakt adatbázis modellre van szükség, melyhez az egyes rendszerek hozzáigazíthatják a saját implementációjukat. Így lehetővé válik a különböző rendszerek számára, hogy egymással szabványos és kölcsönösen érthető fogalmak szerint kommunikáljanak.
Az adatbázis rekordok gyűjteményét jelenti. Minden rekord egymással kapcsolatban levő információk egységként kezelt gyűjteménye. Az adatbázis rekord a helyi adatstruktúrát jelenti, melynek segítségével az információ az adott rekordban megjelenik. Az adatbázissal kapcsolatos az elérési pont és az egy vagy több elemhalmaz fogalma: az elérési pont vagy pontok magukban vagy egymással kombinálva a kereséskor megadható egységes vagy nem-egységes kulcsszavakat jelentik, az egy vagy több elemhalmazt az adatbázisrekordból lehet visszakeresni. Az elérési pont kapcsolódhat elemhez, megegyezhet egy elemmel, vagy nem kapcsolatos egy elemmel sem.
3.1.4. Az adatbázis keresése
A kereső kérdés (query) értékeket továbbít az adatbázis felé és ezek az értékek az adatbázis elérési pontjaival összehasonlításra kerülnek. A lekérdezéskor keletkező rekordokból áll a találati halmaz. A keresési kérés egy vagy több adatbázist jelöl meg és tartalmaz egy 1. típusú (lásd később) kereső kérdést, mely egy vagy több egymással logikai operátorokkal összekötött elérési pont feltételt (access point clause) tartalmaz. Pl.: A “könyv” elnevezésű adatbázisban keresse meg az összes olyan rekordot, melynek “cím kulcsszó” elérési pontja tartalmazza a “csillagok” értéket és (AND) a “szerző” elérési pontja tartalmazza a “Gárdonyi” értéket.
Minden elérési pont feltétel a kereső kifejezésből és attribútumokból áll. Az attribútumok pontosítják a kifejezést; általában az egyik attribútum egy normalizált elérési pontnak felel meg, amellyel a kifejezés összehasonlításra kerül. Mindegyik attribútum egy attribútum típusból és egy hozzátartozó értékből áll. Pl.: A típus lehet “elérési pont” és az érték “szerző”, vagy a típus “csonkolás” és az érték “bal”.
3.1.5. A találati halmaz modellje
A találati halmaz nem magukat a fizikai rekordokat jelenti, csak a mutatókat, vagyis a rekordok azonosítóit. Rekordok lekérdezésénél a találati halmaz adathármasok rendezett, névvel ellátott listája, ahol egy adathármas az alábbiakból áll:
(a)	sorszám, az adathármas sorszáma a listában,
(b)	adatbázis név
(c)	egy rekord egységes azonosítója a b) alatti adatbázisban
A találati halmaz egy elemére a sorszámával a)-val történik hivatkozás.
Keresési célra, amikor a találati halmaz operandusként használatos a kereső kérdésben, a logikai szerkezet az alábbi:
•	Alapmodell          Párok halmaza, ahol minden pár (b)-ből és (c)-ből áll.
•	Bővített modell	   Hármasok halmaza, ahol a hármasok (b)-ből és (c)-ből állnak és valamilyen nem definiált információból.

3.2. Az információkeresés lehetőségei
A lehetőségek a Z39.50-es szolgáltatások logikailag összetartozó csoportjai. A találatok visszaküldése, mint lehetőség a megjelenítési és a szegmentálási szolgáltatásból áll. Mindamellett egy lehetőség nem biztos hogy tartalmaz szolgáltatásokat, de más lehetőségek szolgáltatásait használja. Pl. a tájékoztatási lehetőségnek nincs szolgáltatása, a keresési és megjelenítési szolgáltatásokat használja.
3.2.1. Kezdeményezés
Egyetlen szolgáltatásból áll, ez a kezdeményezés.
A eredet javaslatot tesz a kezdő paraméterekre, a cél válaszol erre és azok a paraméterek, melyek a cél által javasolt paraméterektől eltérnek, lesznek a végleges paraméterek, vagyis a cél dönt a paraméterek kérdésében.
Ha a cél igenlően válaszol, a Z-kapcsolat létrejött. Ha az eredet nem fogadja el a cél által javasolt értékeket, a ‘Befejezés’ szolgáltatással lezárhatja a Z-kapcsolatot. Ha a cél visszautasítóan válaszol, akkor az eredet újra megkísérelheti a kezdeményezést.
Paraméterek:
Eredet 	Cél	
Paraméter	kérése	válasza	
Verzió	x	x	
Azonosító	x (opcionális)		
Opciók	x	x	
Javasolt üzenetméret	x	x	
Kivételes rekordméret 	x	x	
Eredmény		x	
Implementáció azonosítója	x (opcionális)	x (opcionális)	
Implementáció neve	x (opcionális)	x (opcionális)	
Implementáció verziója	x (opcionális)	x (opcionális)	
Felhasználói információ mező 	x (opcionális)	x (opcionális)	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (ha van értelme)	

Verzió: A cél és az eredet is megadja az általa ismert Z39.50 verziót és a legmagasabb számú közös verzióban megegyeznek. Ha nincs közös verzió, a cél az eredmény paraméter segítségével utasítja vissza a kezdeményezést.
Azonosító: A cél és a eredet a szabvány keretein kívül megegyeznek abban, hogy ezt a paramétert az eredet használja-e és ha igen, mi legyen az értéke. A cél ezt a paramétert annak a meghatározására használja, hogy az eredet kapcsolatba léphet-e a céllal, vagyis az eredet ezzel azonosíthatja magát.
Opciók: Az alábbi opciókra a eredet javaslatot tesz, hogy érvényben legyenek-e vagy sem, és azt a cél dönti el, hogy melyik lesz érvényben és melyik nem.
Az opciók: az alábbi műveletekre /keresés, megjelenítés, törlés, erőforrásjelentés, böngészés, rendezés és kibővített szolgáltatások/ a eredet sorban megadja, hogy kíván-e ilyen típusú műveletet kezdeményezni; ha igen, a cél is megmondja, hogy az adott műveletet végre tudja‑e hajtani. Ha az eredet egy-egy műveletet nem kíván, ebbe a célnak bele kell egyeznie.
Indított (trigger) erőforrás ellenőrzés, az eredet kérhet indított erőforrás ellenőrzést, de ha nem kér, akkor ezt a célnak el kell fogadnia.
1-es és 2-es szintű szegmentálás (bővebben lásd 3.3.): Az eredet 3 javaslattal élhet: nem kér szegmentálást, 1-es szintű szegmentálást kér, 2-es szintű szegmentálást kér. A szegmentálás akkor van érvényben, ha vagy az 1-es vagy a 2-es szintű szegmentálás érvényben van. Szegmentálás csak a 3. verzió esetében lehetséges. Ha a cél egyik szegmentálást sem támogatja, akkor nincs szegmentálás az eredet javaslatától függetlenül. Ha a cél az 1-es szintet támogatja, akkor az lesz érvényben, ha a 2-es szintet adja meg, akkor az eredetnek fel kell a 2-es szintű szegmentálásra készülnie.
Párhuzamos műveletek (bővebben lásd 3.5.): Az eredet javasolhatja a párhuzamos műveletek lehetőségét és a célnak válaszolnia kell, hogy ezt elfogadja-e. Ha az eredet nem javasolja a párhuzamos műveleteket, akkor ezt a célnak el kell fogadnia. Ha párhuzamos műveletek nem lehetségesek, akkor soros műveletekről beszélünk. Párhuzamos műveletek csak a 3. verziónál lehetségesek.
Találati halmazok elnevezése: A eredet kérheti azt, hogy a találati halmazokat elnevezhessék és az eredet válaszában megmondja, hogy ezt támogatja-e. Ha az eredet nem kéri ezt, a célnak ezt el kell fogadnia.
Erőforrás ellenőrzés és hozzáférés vizsgálat:  Az eredet megadja, hogy kér-e majd a céltól erőforrás ellenőrzést és hozzáférés vizsgálatot. Biztonsági okokból a cél ragaszkodhat a hozzáférés vizsgálatokhoz, akkor is ha az eredet nem kéri ezt és ezért a Z-kapcsolatot is visszautasíthatja.
Javasolt üzenetméret és kivételes rekordméret: Az eredet javasolja mind a kettőt byte‑okban és a cél válasza tartalmazza a cél által használatba kerülő értékeket, melyek eltérhetnek az eredet által javasolttól. Mind kérésnél, mind válasznál a javasolt üzenetméretnek kisebb egyenlőnek kell lennie a kivételes rekordméretnél. A kivételes rekordméretnek a megjelenítésnél van jelentősége, ha egy kivételesen nagy rekord megjelenítését kérik. Ha egyenlőek, akkor a kivételes rekordméretnek nincs jelentősége.
Eredmény: A cél megadja, hogy a Z-kapcsolatot elfogadja-e az ‘elfogad’ vagy ‘visszautasít’ értékekkel.
Az implementáció azonosítója, implementáció neve és implementáció verziója. Mind a kérés, mind a válasz tartalmazhatja ezeket a paramétereket. Mind az eredet, mind a cél implementációjának lehet azonosítója, neve és verziója. Ezek a paraméterek a felhasználók kényelmét szolgálják az implementációk megkülönböztetése céljából.
Felhasználói azonosító mező: Ezt a paramétert az eredet is és a cél is használhatja további információk közlésére, melyet ez a szabvány nem határoz meg.
Egyéb információ: Ezt a paramétert az eredet is és a cél is használhatja további információk közlésére, melyeket ez a szabvány nem határoz meg. Használata azonban csak a 3. verzió esetén lehetséges.
Hivatkozási azonosító: lásd 3.4.
3.2.2. Keresés
Egyetlen szolgáltatásból áll, a keresésből.
A keresési kérésben az eredet kereső kérdéseket küld a célnak és tájékoztatást kap a keresés eredményéről. A cél létrehoz egy találati halmazt, és ezt a későbbi megjelenítési kérések számára megtartja.
A keresési paraméterektől függően egy vagy több rekordot tartalmazhat már a keresési válasz is. A találati halmaz rendezett halmaz, a rekordot a pozíciója azonosítja.
Paraméterek:
Eredet 	Cél	
Paraméter	kérése	válasza	
Kereső kérdés típusa	x		
Kereső kérdés	x (opcionális)		
Adatbázis nevek	x		
Találati halmaz neve	x		
Helyettesítési indikátor	x		
Elemhalmaz nevek kis halmaz esetén	x (opcionális)		
Elemhalmaz nevek közepes halmaz esetén	x (opcionális)		
Kért rekordszintaxis	x (opcionális)		
Kis halmaz felső korlátja	x		
Nagy halmaz alsó korlátja	x		
Közepes halmaz megjelenítési szám	x		
Válaszrekordok		x (ha van értelme)	
Találatok száma		x	
Visszaküldött rekordok száma		x	
Következő pozíció a találati halmazban		x	
Keresési státusz		x	
Találati halmaz státusza		x (ha van értelme)	
Megjelenítési státusz		x (ha van értelme)	
További keresési információk	x (opcionális)	x (opcionális)	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (ha van értelme)	
A kereső kérdés típusa és a kereső kérdés: A kereső kérdés típusát adja meg, vagyis a kereső kérdés szintaxisát. 6 típus van:
•	0-ás típus, akkor használható, ha a típust illetően az eredet és a cél a szabvány keretein kívül előzetesen megegyezik.
•	1-es típus, az RPN formátumú kereső kérdés.
•	2-es típus, az ISO 8777 típusú kereső kérdés.
•	100-as típus, a Z39.58 típusú kereső kérdés, melyet az ANSI Z39.58 specifikál.
•	101-es típus, az 1-es típus bővítése, az ERPN formátumú kereső kérdés, mely közelségi (proximity) operátorokat és a találati halmazok korlátozását is lehetővé teszi.	
Megjegyzés: A 3. verzió esetén az 1-típusú kereső kérdés is tartalmazhat közelségi operátorokat ill. korlátozást.
•	102-es típus: rangsorolt listás kereső kérdés, a szabvány későbbi változatában lesz majd definiálva.
Adatbázis nevek: Az eredet megadja a lekeresendő adatbázisok nevét. A cél kijelöli (vagy a tájékoztatási lehetőség segítségével vagy más módon a szabványon kívül) a szóbajöhető adatbázisokat és azt, hogy ezek milyen kombinációkban kereshetők. Az adatbázisok nevében kis és nagy betűk tetszőlegesen használhatók.
Találati halmaz neve és a helyettesítési indikátor: Az eredet megadja a találati halmaz nevét. Ha már van ilyen név a célnál, akkor a helyettesítési indikátor határozza meg, hogy mi történjék az alábbi módon:
•	Ha a helyettesítési indikátor értéke ‘on’, vagyis érvényben van, akkor a meglévő találati halmaz törlődik és ezzel a névvel új halmaz jön létre. Ha a keresést nem lehet végrehajtani, akkor a találati halmaz üresen marad.
•	Ha a helyettesítési indikátor értéke ‘off’, a keresést a cél nem hajtja végre, egy diagnosztikai rekordot küld vissza és a már meglevő találati halmaz változatlanul megmarad.
Ha nincs ilyen név a célnál, akkor a cél ezzel a névvel létrehoz egy találati halmazt és a helyettesítési paramétert nem veszi figyelembe. A találati halmaz először üres. Ha a kereső kérdés nem eredményez találatot, akkor üresen is marad.
A célnak általában nem kell támogatnia a találati halmazok eredet által történő elnevezését. De legalább a ‘default’ elnevezésű találati halmazt támogatnia kell, vagyis ha az eredet a ‘default’ nevet adja meg, akkor a helyettesítési indikátor értéke ‘on’ kell hogy legyen.
A találati halmazra ezek után lehet egy későbbi megjelenítési kérésben vagy egy újabb keresési kérésben hivatkozni a Z kapcsolat végéig vagy addig amíg, nem törlik:
•	egy törlési művelettel,
•	egy másik találati halmaz ugyanezt a nevet kapja a helyettesítési indikátor ‘on’ értéke mellett,
•	a cél egyoldalúan törli,
•	a Z kapcsolat véget ér.
Elemhalmaz nevek kis halmaz esetén és elemhalmaz nevek közepes halmaz esetén: Ezek a paraméterek a keresési válaszban tartalmazott rekordok kért szerkezetét adják meg. Ha a kereső kérés kis halmazt eredményez, akkor az ‘elemhalmaz nevek kis halmaz esetén’ paraméter, míg közepes halmaz esetén az ‘elemhalmaz nevek közepes halmaz esetén’ paraméter lép érvénybe.
Kért rekordszintaxis: Az eredet megadhatja a visszakeresett rekordok kívánt rekordszintaxisát. Ha ezt a cél nem tudja támogatni, akkor a megjelenítéshez rendelkezésre álló többi absztrakt rekordszintaxisból választ.
Kis halmaz felső korlátja, nagy halmaz alsó korlátja, közepes halmaz megjelenítési száma: A találati halmaz “kis halmaz”, “közepes halmaz”, ill. “nagy halmaz” attól függően, hogy ezek a paraméterek milyen értékekre vannak beállítva ill. mennyi a találatok száma. A találati halmaz kis halmaz, ha a találatok száma nem nagyobb mint a ‘kis halmaz felső korlátja’, nagy halmaz, ha a találatok száma nagyobb vagy egyenlő, mint a ‘nagy halmaz alsó korlátja’, egyébként közepes halmaz. Ha a találati halmaz kis halmaz, akkor a cél köteles átadni a rekordokat az eredetnek. Ha a találati halmaz nagy halmaz, akkor ezt nem kell megtenni. Ha a találati halmaz közepes halmaz, akkor a ‘közepes halmaz megjelenítési száma’ paraméter szabja meg a visszajuttatandó rekordok számát.
Ha az eredet nem kér válaszrekordot, akkor a ‘kis halmaz felső korlátját’ 0-ra, a ‘nagy halmaz alsó korlátját’ 1-re állítja. A ‘kis halmaz alsó korlátja’ lehet ugyanis 0 és a két korlátértéknek különböznie kell.
Válaszrekordok: A cél végrehajtja a keresést és létrehoz egy találati halmazt. A keresés végrehajtása azonban nem feltételezi a rekordok fizikai elérését. Elképzelhető, hogy egy adott rekord nem érhető el, de ez a tény csak a megjelenítési rekord létrehozásának megkísérlésekor derül ki. Az olyan adatbázis rekordok helyett, melyeket nem lehet visszajuttatni, diagnosztikai rekordokat küld a cél. Ez a paraméter tehát vagy megjelenítési rekordot vagy diagnosztikai rekordot jelent.
A paraméter értéke az alábbiak szerint alakul:
•	N válaszrekord (N függ a találatok számától és a fentebb leírt korlátoktól).
•	N-nél kevesebb válaszrekord, mert az üzenetméret ill. rekordméret korlátozó tényezőként lép fel (lásd 3.3.).
•	Egy vagy több diagnosztikai rekord, melyek azt jelzik, hogy a keresést nem lehet végrehajtani és miért nem.
•	Egy vagy több diagnosztikai rekord, melyek azt jelzik, hogy a rekordokat nem lehet megjeleníteni és miért nem, pl. az elemhalmaz név nem érvényes az adatbázisban.
A válaszrekordok sorrendje megfelel a találati halmazban a rekordok sorrendjének. Mindegyiket kísérheti az adatbázis neve, az első rekordot mindenképpen kísérnie kell az adatbázis nevének és mindegyik olyan rekord mellett ott kell állnia az adatbázis nevének, ahol az az előzőtől különbözik.
Találatok száma és visszakeresett rekordok száma: A találati halmazban levő adatbázis rekordok száma. Ha a találati halmaz üres, ez a paraméter 0. A megjelenítési rekordok száma a keresési válaszban visszaküldött rekordok teljes száma.
Következő találati halmaz pozíció: Az M+1 értéket veszi fel, ahol M az utolsó visszaküldött válaszrekord pozíciója. Ha M = a találatok száma, akkor 0.
Keresési státusz: A paraméter két értéket vehet fel:
siker - A keresés sikeresen zárult.
hiba - A keresés nem folyt le sikeresen.
A ‘siker’ nem jelenti feltétlenül, hogy a várt válaszrekordok a válasz részei lesznek. Azt is észre kell venni, hogy a ‘siker’ nem feltétlenül jelenti azt, hogy a keresésnél volt találat. Hiba esetén a cél egy vagy több diagnosztikai rekordot küld vissza annak jelzésére, hogy miért nem lehetett a keresést végrehajtani.
Találati halmaz státusza és a megjelenítési státusz: Ezek a státusz jelzők azért szükségesek, hogy a keresés közben lehetséges kétértelmű helyzeteket meg lehessen egymástól különböztetni.
A ‘találati halmaz státusz’ csak akkor kap értéket, ha a ‘keresési státusz’ paraméter értéke hiba és ekkor az alábbiak egyike lehet:
részhalmaz 	- Részben vannak jó találatok.	
közbenső 	- Vannak részben találatok, de nem feltétlenül érvényesek.	
semmi 	- Nincs találati halmaz.	
A ‘megjelenítési státusz’ paraméter csak akkor kap értéket, ha a ‘keresési státusz’ paraméter értéke siker és ekkor az alábbiak egyike lehet:
siker - Minden válaszrekord megjeleníthető.
részleges-1 	- Nem lehet minden válaszrekordot megjeleníteni, mert a kérést hozzáférési ellenőrzés szakította meg.	
részleges-2 	- Nem lehet minden válaszrekordot megjeleníteni, mert azok nem férnek el mind a kért rekordméretben.	
részleges-3 	- Nem lehet minden válaszrekordot megjeleníteni, mert a kérést erőforrás ellenőrzés szakította meg az eredet kérésére.	
részleges-4 	- Nem lehet minden válaszrekordot megjeleníteni, mert a kérést erőforrás ellenőrzés szakította meg a cél kérésére.	
hiba 	- Egy válaszrekordot sem lehet megjeleníteni. Egy vagy több diagnosztikai rekord visszaadására kerül sor.	
További keresési információk: Olyan, a keresés melléktermékeként jelentkező információk átadására használhatja ezt a paramétert a cél, mint pl. keresés közben a találatok száma, miért használt egy adott attribútumot a kereséshez. Az eredet megadhatja itt az ilyen mellékes információk formátumát. Csak a 3. verzióban lehetséges ennek a paraméternek a használata.
Egyéb információk: Az eredet és a cél is használhatja ezt a paramétert további, a szabvány által nem definiált információkra. Csak a 3. verzióban lehetséges ennek a paraméternek a használata.
Hivatkozási azonosító: Lásd 3.4.
3.2.3. Visszaküldés
A visszaküldési lehetőség két szolgáltatása: a megjelenítés és a szegmentálás.
Az eredet megjelenítési kérést intéz a célhoz, hogy az adott pozíciótól jelenítsen meg rekordokat a találati halmazból. A cél erre a kért rekordok megjelenítésével válaszol. Ha a szegmentálás (lásd 3.3.) érvényben van és a kért rekordok nem férnek el a válaszban, akkor a cél szegmentálhatja a választ, miután előzőleg egy vagy több szegmentálási kérést küldött az eredetnek. Minden szegmentálási kérés és a megjelenítési válasz is egy-egy szegmens a megjelenítési válaszban. Ha a válasz egyetlen elemből áll, akkor egyszerű megjelenítési válaszról van szó.
3.2.3.1. Megjelenítési szolgáltatás
Az adatbázis rekordokra a relatív pozíciójuk szerint történik a hivatkozás. Az eredet sorban megadhat intervallumokat. A 3. verzióban egy egyszerű kérés több intervallumot is tartalmazhat. Például az eredet kérheti 1-től 5-ig a rekordok megjelenítését, majd 4‑től 6-ig.
Paraméterek:
Eredet	Cél	
Paraméter	kérése	válasza	
A kért rekordok száma	x		
A találati halmaz kezdő pozíciója	x		
További intervallumok	x (opcionális)		
A találati halmaz azonosítója	x		
Elemhalmaz nevek	x (opcionális)		
Kért rekordszintaxis	x (opcionális)		
Rekordszerkezet	x (opcionális)		
Max. szegmens szám	x (opcionális)		
Max. szegmens méret	x (opcionális)		
Max. rekord méret	x (opcionális)		
Válaszrekordok		x (ha van értelme)	
Visszaküldött rekordok száma		x	
Következő találati halmaz pozíció		x	
Megjelenítési státusz		x	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (ha van értelme)	
A kért rekordok száma és a találati halmaz kezdő pozíciója: Az eredet kér egy intervallumot: N rekordot az M-edik rekordtól kezdve. M = a találati halmaz kezdő pozíciója, N = a kért rekordok száma és N nem nagyobb, mint az (összes találat száma ‑ M) +1.
További intervallumok: Az eredet egy vagy több (M,N) pár megadásával kérheti további rekord intervallumok megjelenítését, ahol M,N-re az előbbiek vonatkoznak. Az első (M,N) párra M nagyobb egyenlő kell legyen, mint a találati halmaz kezdő pozíciójának és a kért rekordok számának összege. Bármely további (M1,N1) és (M2,N2) párra M1+N1kisebb, mint M2. Ez a paraméter csak a 3. verzióban érvényes.
A találati halmaz azonosítója: Az eredet megadja egy, ebben a Z kapcsolatban létrehozott átmeneti találati halmaz nevét, amelyből a rekordokat meg kell jeleníteni.
Elemhalmaz nevek: Az eredet megadhatja a visszakeresett rekordok szerkezetét.
Kért rekordszintaxis: mint a keresésnél.
Rekordszerkezet: Csak akkor lehetséges ez a paraméter, ha nincs ‘Elemhalmaz nevek’ paraméter és a 3. verzió van érvényben. Ha meg van adva, akkor a megjelenített rekordok kívánt szerkezetének egy másfajta megadását teszi lehetővé.
Max. szegmens szám, max. szegmensméret, max. rekordméret: A ‘max. szegmens méretet’ akkor lehet megadni, ha vagy az 1-es vagy a 2-es szintű szegmentálás érvényben van. A ‘max. szegmens szám’ a szegmensek max. számát adja meg a megjelenítési válaszban. Ha értéke 1, akkor nincs szegmentálás és a max. rekordméretet nem kell megadni. A max. szegmensméretnek és max. rekordméretnek csak a 2-es szintű szegmentálásnál van értelme. ‘Max. szegmensméret’ a legnagyobb megengedhető szegmens, ha nincs megadva, akkor értéke a ‘javasolt üzenetméret’. A ‘max. rekordméret’ a legnagyobb visszakereshető rekord, ha szerepel, akkor egyenlő vagy nagyobb, mint a ‘max. szegmens méret’. Lásd még 3.3. Szegmentálás.
Válaszrekordok: Rekordok sorozatát jelenti, ill. ha a 2-es szintű szegmentálás van érvényben, akkor egy utolsó rekordrész is lehet, melyet követhet egy vagy több válaszrekord. Hasonlóképpen, ha a művelet nem tartalmazott szegmentálási kérést, akkor egy vagy több diagnosztikai rekordból is állhat, jelezve, hogy a kérést nem lehetett végrehajtani.
Minden kért rekordhoz tartozik egy válaszrekord. Mindegyik válaszrekord a találati halmaz egy elemének számít és a találati halmaz rekord sorszámai növekvő sorrendben egymást követik, kivéve ha a kérés további intervallumokat tartalmazott. Ekkor a pozíciókat szünetek szakíthatják meg.
Minden válaszrekordot kísérheti annak az adatbázisnak a neve, amelyikből származik. Az első válaszrekordot (vagy kezdő részrekordot) kísérnie kell az adatbázis nevének és minden olyan válaszrekordot (vagy részrekordot) kísérnie kell az adatbázis nevének, amelyhez tartozó adatbázis különbözik az előtte levő rekordhoz tartozó adatbázistól.
Mihelyt az eredet megkapta a megjelenítési választ (és a szegmenseket is összerakta, ha voltak), az eredmény az alábbi:
•	N válaszrekord, ahol N= a kért rekordok száma
•	N-től kevesebb válaszrekord (az ok meg van adva a megjelenítési státuszban)
•	Egy vagy több diagnosztikai rekord, jelezve hogy a kérést nem lehetett végrehajtani.
Visszaküldött rekordok száma és a következő találati halmaz pozíció: A ‘visszaküldött rekordok száma’ a megjelenítési válasz rekordjainak teljes száma. A ‘következő találati halmaz pozíció’ M + 1, ahol M az utolsó rekord pozíciója a találati halmazban vagy nulla, ha M a találati halmaz utolsó elemének a pozíciója.
Megjelenítési státusz: A ‘megjelenítési státusz’ kötelező a megjelenítési válaszban és értékei ugyanazok, mint a keresésnél a ‘megjelenítési státusz’ értékei.
Egyéb információk: Az eredet és a cél is használhatja ezt a paramétert további, a szabvány által nem definiált információkra. Csak a 3. verzióban lehetséges ennek a paraméternek a használata.
Hivatkozási azonosító: Lásd 3.4.
3.2.3.2. Szegmentálási szolgáltatás
Ha a megjelenítési kérés által kért rekordok nem férnek bele egyetlen szegmensbe és ha a szegmentálás érvényben van, akkor a cél több szegmenst küld vissza. Az utolsó szegmenst kivéve a szegmenseket szegmentálási kérésként továbbítja.
Megjegyzések:
1.	A szegmentálási szolgáltatás kérésként van modellezve, jóllehet logikailag a cél nem küldhet kérést. Ennek az az oka, hogy egy üzenet az vagy kérés vagy válasz, egy választ egy ugyanolyan kérésnek kell megelőznie és legfeljebb egy válasz lehet minden kéréshez. A szegmentálási szolgáltatást nem lehet válaszként modellezni (mert ha így lenne, akkor szükségszerűen szegmentálási kérésre válaszolna és az egy nem visszaigazolt szolgáltatás); és a megjelenítési műveletet nem lehet megjelenítési kérésként modellezni, melyet több megjelenítési válasz követ.
2.	Csak a 3. verzióban lehetséges ez a szolgáltatás.
3.	Ha szegmentálás nincs érvényben, akkor a cél nem küld szegmentálási kéréseket és akkor a megjelenítési válasz egyetlen egyszerű megjelenítési válaszból áll. Ha a kért rekordok nem férnek be egy szegmensbe, akkor a 3.3.-ban ismertetett eljárás érvényes.
4.	Ha a kért rekordok beférnek egy szegmensbe, akkor a cél nem küld szegmens kéréseket és a megjelenítési válasz egyetlen egyszerű megjelenítési válaszból áll.
Paraméterek:
Paraméter	Cél kérése	
Szegmens rekordok	x	
Visszaküldött rekordok száma	x	
Egyéb információ	x (opcionális)	
Hivatkozási azonosító	x (ha van értelme)	
Szegmens rekordok: Ha az 1-es szintű szegmentálás van érvényben, akkor ez a paraméter válaszrekordok sorozatából áll.
Ha a 2-es szintű szegmentálás van érvényben, akkor ez a paraméter mind válaszrekordokat, mind részrekordokat tartalmazhat. Állhat egy befejező részrekordból (kivéve, ha a megjelenítési rekord első szegmensében van), melyet nulla vagy több válaszrekord követ és egy kezdő részrekord.
Mindegyik válaszrekordot vagy kezdő szegmenst kísérheti az adatbázis neve. De az első válaszrekordot (vagy kezdő részrekordot) kísérnie kell az adatbázis névnek, szintúgy minden olyan válaszrekordot (vagy kezdő részrekordot), amelyhez tartozó adatbázis különbözik a közvetlen előtte levő rekordhoz tartozó adatbázistól.
Visszaküldött rekordok száma: Ez a válaszrekordok és kezdő részrekordok teljes száma a szegmensben.
Egyéb információ: Ezt a paramétert a cél használhatja további szabványon kívül megadott információhoz.
Hivatkozási azonosító: Lásd 3.4.
3.2.4. Törlés
Találati halmaz törlése.
Egyetlen szolgáltatásból, a törlésből áll. Az eredet kéri egyes találati halmazok törlését vagy az összes, a Z kapcsolatban létrehozott találati halmaz törlését. A cél a művelet eredményét közli.
Paraméterek:
Eredet	Cél	
Paraméter	kérése	válasza	
Törlés	x		
Találati halmaz lista	x (ha van értelme)		
A törlési művelet státusza		x	
Törlési lista státuszai		x (ha van értelme)	
Nem törölt szám		x (ha van értelme)	
Összes törlés státusza		x (ha van értelme)	
Törlési üzenet		x (ha van értelme)	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (opcionális)	
Törlés: Az eredet vagy a megadott találati halmazok vagy minden, a Z kapcsolat alatt létrehozott találat törlését kéri. Értéke ennek alapján: lista vagy teljes törlés kérése.
Találati halmaz lista: Ez a paraméter csak akkor szerepel, ha listás a törlés, vagyis megadott találati halmazok listáját kell törölni.
A törlési művelet státusza: A törlés kérés státusza. A következő pont alatti listából veheti fel a siker ill. a 3-tól 9-ig a hiba értékeket.
Törlési lista státuszok: A találati halmazokhoz hozzá van rendelve egy státusz. A lehetséges értékek:
siker	A találati halmaz törlődött.	
1-es hiba	A találati halmaz nem létezett.	
2-es hiba	A találati halmazt már a cél előzőleg egyoldalúan törölte.	
3-as hiba	Rendszerprobléma a cél oldalon.	
4-es hiba	Hozzáférési hiba, a törlési kérés kiváltott a célnál egy hozzáférés ellenőrzést, melyet az eredet nem elégített ki, vagy nem tudta fogadni.	
5-ös hiba	A műveletet az erőforrás ellenőrzés szakította meg az eredet kérésére.	
6-os hiba	A műveletet a cél szakította meg erőforrás megszorítások miatt.	
7-es hiba	A cél nem támogatja az összes halmaz törlését.	
8-as hiba	Nem törlődött az összes halmaz ennek kérése esetén.	
9-es hiba	Nem lett az összes kért halmaz törölve.	
10-es hiba	A találati halmaz használatban van.	
Nem törölt szám és az összes törlés státusz: Csak akkor fordulnak elő, ha összes törlésről van szó és a törlési művelet státusza 8-as hiba. A ‘nem törölt szám’ a nem törölt halmazok számát adja meg és az ‘összes törlés státusz’ megadja a nem töröltek egyedi státuszát. A cél nem kötelező megadni minden teljes törlésnél a nem törölt halmaz státuszát.
Törlési üzenet: Ha van törlési üzenet, akkor lehet benne szöveges üzenet is.
Egyéb információk: Az eredet és a cél is használhatja ezt a paramétert további, a szabvány által nem definiált információkra. Csak a 3. verzióban lehetséges ennek a paraméternek a használata.
Hivatkozási azonosító: Lásd 3.4.
3.2.5. Hozzáférés ellenőrzés
Egyetlen szolgáltatást jelent, a hozzáférés ellenőrzést.
A cél kérdőre vonhatja az eredetet, hogy az azonosítsa magát.
Az eredetnek fogadnia kell tudni a cél hozzáférés ellenőrzésre vonatkozó kéréseit, ha a hozzáférés ellenőrzés érvényben van. A cél indítványozhatja a hozzáférés ellenőrzést az aktív művelet alatt vagy a Z kapcsolat részeként. A hozzáférés ellenőrzéskor az eredetnek igazolnia kell magát, ez vonatkozhat jelszómegadásra, nyilvános kulcsok titkosítására és algoritmikus igazolási eljárásra.
•	Ha a párhuzamos műveletek érvényben van, akkor,
-	ha a hozzáférés ellenőrzés kérés tartalmaz hivatkozási azonosítót: a megadott azonosítónak meg kell felelnie egy aktív művelet azonosítójának, vagyis a hozzáférés ellenőrzés kérés része a műveletnek. A válasznak is kell a hivatkozási azonosítót tartalmaznia.
-	ha a hozzáférés ellenőrzés kérés nem tartalmaz hivatkozási azonosítót: se a kérés, se a válasz nem része műveletnek, a Z-kapcsolathoz tartozik mind a kettő.
•	Ha egymást követő műveletek vannak érvényben: a cél csak akkor kívánhat hozzáférés ellenőrzést, ha van aktív művelet: a kérés és az azt követő válasz részei ennek a műveletnek és tartalmazniuk kell a művelet hivatkozási azonosítóját (ennek feltételezett értéke nulla, ha a kezdeményezést indítványozó kérésben nincs benne).
Ha a hozzáférési kérés műveletre vonatkozik:
A kezdeményezési kérés után az eredetnek képesnek kell lennie a hozzáférési ellenőrzés kérést fogadnia, válaszolnia kell a hozzáférés ellenőrzés válasszal, aztán később újabb ilyen kérést kell tudnia fogadni, stb. míg befejezési választ nem kap. A cél, miután elküldte a hozzáférés ellenőrzésre vonatkozó kérését, addig felfüggesztheti a művelet végzését, amíg nem kap választ.
Paraméterek:
Eredet	Cél		
Paraméter	kérése	válasza	
Biztonsági lekérdezés	x		
Válasz a biztonsági lekérdezésre		x	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (ha van értelme)	x (ha van értelme)	
Biztonsági lekérdezés és válasz a biztonsági lekérdezésre: A ‘biztonsági lekérdezés’ és válaszra vonatkozó formátum és tartalom megegyezés (regisztráció) tárgya: több definíciót tartalmaz erre vonatkozóan a szabvány 7. melléklete: A hozzáférés ellenőrzés formátumai.
Egyéb információk: Az eredet és a cél is használhatja ezt a paramétert további, a szabvány által nem definiált információkra. Csak a 3. verzióban lehetséges ennek a paraméternek a használata.
Hivatkozási azonosító: Ha egymást követő műveletek vannak érvényben vagy ha párhuzamos műveletek vannak érvényben és az ellenőrzés egy adott műveletre vonatkozik, akkor a hivatkozási azonosító használatát lásd 3.4. Ha ‘párhuzamos műveletek’ vannak érvényben és a lekérdezés az egész Z kapcsolatra vonatkozik, akkor a hivatkozási azonosítót el kell hagyni.
3.2.6. Erőforrás ellenőrzés
A számlázás/erőforrás ellenőrzési lehetőség három szolgáltatásból áll:
•	erőforrás ellenőrzés, melyet a cél kezdeményez vagy egy aktív művelet részeként vagy a Z-kapcsolat részeként;
•	indított erőforrás ellenőrzés, melyet az eredet kezdeményez egy aktív (bármelyik a kezdeményezésen kívüli) művelet részeként;
•	erőforrásjelentés, melyet az eredet kezdeményez egy erőforrásjelentési művelet beindítására.
Az erőforrás ellenőrzés révén a cél erőforrás ellenőrzési kérést küldhet, mely tartalmazhat egy erőforrásjelentést. A jelentéssel a cél az eredet tudtára adhatja, hogy vagy az aktuális vagy a megjósolt erőforrás felhasználás át fogja lépni a megállapított határokat és kérheti az eredetet a művelet folytatásának hozzájárulásához az erőforrás ellenőrzési válaszban. Például a cél közölheti az eredettel egy találati halmaz státuszát a keresési művelet alatt és információt nyújthat a művelet lefolyásáról.
Az indított erőforrás ellenőrzés lehetővé teszi az eredet számára, hogy erőforrás ellenőrzés kezdeményezést kérjen a céltól vagy megszakítson egy műveletet.
Az erőforrásjelentés szolgáltatás révén az eredet kérheti a céltól, hogy a cél vagy egy befejezett műveletre vonatkozóan vagy a Z kapcsolatra vonatkozóan jelentést küldjön.
3.2.6.1. Erőforrás ellenőrzési szolgáltatás
Ha az erőforrás ellenőrzés érvényben van, akkor az erőforrás ellenőrzési kérés fogadására és megválaszolására az eredetnek fel kell készülnie.
•	Ha a ‘párhuzamos műveletek’ érvényben van, akkor
-	Ha a kérés tartalmaz hivatkozási azonosítót, akkor ennek meg kell felelnie egy aktív művelet azonosítójának és a válasznak is tartalmaznia kell ezt.
-	Ha a kérés nem tartalmaz hivatkozási azonosítót, akkor a kérés és a válasz nem részei műveletnek, a Z kapcsolatra vonatkoznak.
•	Ha ‘soros műveletek’ vannak érvényben: a cél csak akkor kérhet erőforrás ellenőrzést, ha van aktív művelet; az erőforrás ellenőrzési kérés és válasz ennek a műveletnek a részei és tartalmazniuk kell a hivatkozási azonosítót.
Ha az eredet az erőforrás ellenőrzési kérésre a válaszában a művelet befejezését kéri, akkor várhat befejezési választ a céltól és a válasz jelezheti, hogy a művelet az eredet kérésére szakadt meg. De ugyanakkor a válasz azt is jelezheti, hogy a művelet befejeződött, mert közben a cél folytatta a művelet elvégzését és befejezte azt, mielőtt az erőforrás ellenőrzési válasz elérte volna a célt.
Paraméterek:
Cél	Eredet	
Paraméter	kérése	válasza	
Erőforrásjelentés	x (opcionális)		
Részeredmények vannak	x (ha van értelme)		
Felfüggesztés jelzés	x (ha van értelme)		
Válasz szükséges-e	x		
Indított kérés jelzése	x (opcionális)		
Folytatás jelzés		x	
Találati halmaz kell		x (ha van értelme)	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (ha van értelme)	x (ha van értelme)	
Erőforrásjelentés: Ezt a paramétert lehet használni a tényleges és a becsült erőforrás felhasználásról. A formátumát a szabvány 6. melléklete (Appendix 6 RSC) tartalmazza.
Részeredmények vannak: A cél jelzi a találati halmaz státuszát, melynek értéke az alábbiak egyike lehet:
részhalmaz	- Vannak részleges, érvényes eredmények.	
közbenső	- Nem feltétlenül érvényes részeredmények vannak.	
nincs	- Nincs találat.	
Ennek a paraméternek csak a keresési művelet részeként van értelme. Ha az értéke ‘részhalmaz’ ill. ‘közbenső’, akkor a cél elfogad megjelenítési kéréseket, feltéve ha az eredet a ‘Folytatás jelzés’ paraméterrel jelzi, hogy a műveletet be kell fejezni és ha a ‘Találati halmaz kell’ paraméter érvényben van. Ha az értéke ‘nincs’, akkor a célnak nem kell további megjelenítési kéréseket elfogadnia akkor, ha az eredet jelzi, hogy a műveletet be kell fejezni.
Felfüggesztés jelzés: Ez a paraméter csak akkor érvényes, amikor a kérés műveletre vonatkozik. A cél jelzi, hogy a művelet végrehajtása az erőforrás ellenőrzési választól függően fel lett-e függesztve. Ez a jelzés csak akkor van érvényben, ha a ‘Válasz szükséges-e’ paraméter értéke ‘igen’.
Válasz szükséges-e: A cél megadja, hogy kér-e választ az eredettől.
Indított kérés jelzés: Ez a paraméter csak akkor érvényes, ha a kérés műveletre vonatkozik. A cél jelezheti, hogy a kérés indított erőforrás ellenőrzési kérésből származott-e vagy sem.
Folytatás jelzés: Ez a paraméter csak akkor érvényes, ha a kérés műveletre vonatkozik. Az eredet jelzi a célnak, hogy folytassa-e vagy sem a műveletet.
Találati halmaz kell: Ez a paraméter:
•	keresési művelet alatt
•	amikor a ‘Részeredmények vannak’ paraméter értéke ‘részhalmaz’ vagy ‘közbenső’ és
•	a folytatás jelzés értéke ‘ne folytassa’.
feltételek mellett érvényes.
3.2.6.2. Indított erőforrás ellenőrzés
Az eredet valamely művelet közben kiadhat indított erőforrás ellenőrzésre vonatkozó kéréseket (kivéve a kezdeményezést) a művelet részeként. Ez jelzésként szolgál a cél számára, hogy az eredet a céltól azt kívánja, hogy az
•	egyszerűen küldjön egy erőforrás beszámolót, vagyis úgy adjon ki erőforrás ellenőrzési kérést, hogy a ‘Válasz szükséges-e’ paraméter nincs érvényben (értéke ‘off’)
•	teljes erőforrás ellenőrzést kíván, vagyis a cél úgy küldjön erőforrás ellenőrzési kérést, hogy a ‘Válasz szükséges-e’ paraméter érvényben van (értéke ‘on’)
•	a műveletet szakítsa meg.
Paraméterek:
Eredet		
Paraméter	kérése	
Kért akció	x	
Kívánt erőforrásjelentési formátum	x (ha van értelme)	
Találati halmaz kell-e	x (ha van értelme)	
Egyéb információ	x (opcionális)	
Hivatkozási azonosító	x (ha van értelme)	
Kért akció: Az eredet az alábbiak egyikét kéri:
erőforrásjelentés	- erőforrás ellenőrzési kérés kiadása és a ‘Válasz szükséges-e’ paraméter ne legyen érvényben (‘off’)	
erőforrás ellenőrzés	- erőforrás ellenőrzési kérés kiadása és a ‘Válasz szükséges-e’ paraméter legyen érvényben (‘on’)	
törlés	- a művelet szakadjon meg.	
Kívánt erőforrásjelentés formátum: Az eredet megadhatja az erőforrásjelentés formátumát.
Találati halmaz kell-e: Csak a keresési művelet közben van értelme és akkor, ha a kért akció a törlés. Ha a paraméter értéke ‘igen’, akkor az eredet kéri célt, hogy az az esetleges részleges találati halmazt tartsa meg a későbbi megjelenítési művelethez.
Egyéb információ: Az eredet és a cél is használhatja ezt a paramétert további, a szabvány által nem definiált információkra. Csak a 3. verzióban lehetséges ennek a paraméternek a használata.
Hivatkozási azonosító: lásd 3.4.
3.2.6.3. Erőforrásjelentési szolgáltatás
Az erőforrásjelentési szolgáltatás révén az eredet erőforrásjelentést kérhet egy megadott, befejezett műveletre vagy az egész Z-kapcsolatra vonatkozóan.
Az erőforrásjelentési szolgáltatás különbözik az indított erőforrás ellenőrzési szolgáltatástól, mert ez utóbbi nem visszaigazolt szolgáltatás, vagyis van kérés, de nincs válasz. Az utóbbinál a kérés része a műveletnek, de nem kezdeményezi a műveletet, az aktív művelettel kapcsolatban kér jelentést. Az erőforrásjelentési szolgáltatás ezzel ellentétben visszaigazolt szolgáltatás: van kérés és van válasz.

Paraméterek:
Eredet 	Cél		
Paraméter	kérése	válasza	
Kívánt erőforrásjelentési formátum	x (opcionális)		
Műveleti azonosító	x (opcionális)		
Erőforrásjelentés státusza		x	
Erőforrásjelentés		x (opcionális)	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (opcionális)	
Kívánt erőforrásjelentési formátum: Az eredet megadhatja az erőforrásjelentés formátumát.
Műveleti azonosító: Az eredet használhatja ezt a paramétert annak a műveletnek a megadására, melyről a jelentést kéri. Csak a 3. verzió esetén érvényes. Nem ajánlott aktív művelet azonosítóját megadni. Ha az eredet aktív műveletről szeretne információt kapni, akkor ne ezt a szolgáltatást használja, hanem az indított erőforrás ellenőrzési szolgáltatást a művelet részeként. Ha ez a paraméter nincs megadva, akkor a jelentésnek az egész Z-kapcsolatra kell vonatkoznia.
Erőforrásjelentés státusza: A cél az alábbi státusz értékeket szolgáltatja:
siker	- Van erőforrásjelentés (a megadott kívánt formátumban, ha az meg volt adva).	
részleges	- Van erőforrásjelentés, de nem a kívánt formátumban (csak akkor lehetséges, ha a meg volt adva formátum).	
1-es hiba	- A cél nem tud jelentést adni.	
2-es hiba	- A művelet befejeződött erőforrás korlátok miatt.	
3-as hiba	- Hozzáférés hiba	
4-es hiba	- Nem definiált hiba.	
5-ös hiba	- Nincsen ilyen művelet a megadott azonosítóval.	
6-os hiba	- Az azonosítóval aktív művelet zajlik.	
Az 5-ös és 6-os hiba csak a 3. verzióban létezik.
Erőforrásjelentés: Lásd 3.2.6.2.
Egyéb információ: Az eredet és a cél is használhatja ezt a paramétert további, a szabvány által nem definiált információkra. Csak a 3. verzióban lehetséges ennek a paraméternek a használata.
Hivatkozási azonosító: lásd 3.4.
3.2.7. Rendezés
Egyetlen szolgáltatást tartalmaz, a rendezést.
Az eredet kérheti a célt, hogy a találati halmazt (ill. a találati halmazokat) olvassza össze és rendezze. Az eredet megadja a rendezési elemek sorrendjét.
Paraméterek:
Eredet 	Cél	
Paraméter	kérése	válasza	
Input találati halmaz	x		
Rendezett találati halmaz	x		
Rendezési sorrend	x		
A rendezés státusza		x	
A rendezett halmaz státusza		x (ha van értelme)	
Diagnosztika		x (ha van értelme)	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (ha van értelme)	
Input találati halmaz: Ebben a paraméterben adható meg a rendezni kívánt találati halmaz(ok) neve. Ha több halmazt kér az eredet, akkor ezeket a cél előbb összeolvasztja, aztán rendezi.
Rendezett találati halmaz: A rendezett találati halmaz neve. Ez megegyezhet az input találati halmaz nevével, ekkor rendezés után az eredeti input találati halmaz törlődik és az ilyen nevű halmaz a rendezett találati halmazt tartalmazza. Ha a név nem egyezik meg az input találati halmaz nevével, akkor a cél ezzel a névvel létrehoz egy rendezett találati halmazt. Ha valamilyen oknál fogva a rendezés nem zajlik le, akkor a rendezett találati halmaz tartalmára vonatkozóan ‘A rendezett találati halmaz státusza’ paraméter ad útbaigazítást.
Rendezési sorrend: Ez a paraméter információt tartalmaz a rendezésben résztvevő elemekre, a rendezés sorrendjére (csökkenő, növekvő), a kis és nagy betűk kezelésére valamint arra, hogyha egy rekordból hiányzik a rendezendő elem, mit tegyen a cél.
Rendezési státusz: A cél adja vissza, lehetséges értékei:
siker	- A rendezés sikeresen lezajlott.	
részleges-1	- A rendezés lezajlott, de a cél felfedezett egy vagy több olyan rekordot, melyekből a rendezendő elem hiányzott.	
hiba	- A rendezés nem történt meg. A cél a diagnosztikai paraméterben közli a diagnosztikai rekordokat.	
A rendezett halmaz státusza: A cél csak akkor tölti ki ezt a paramétert, ha ‘A rendezés státusza’ paraméter értéke hiba. Ekkor ez a paraméter a rendezett találati halmaz tartalmára vonatkozik a következő értékekkel:
üres	- A találati halmaz üres.	
közbenső	- Részeredmények vannak, de nem feltétlenül érvényesek.	
változatlan	- A találati halmaz tartalma változatlan.	
semmi	- Találati halmaz nincs.	
Diagnosztika: A cél akkor adja meg ezt a paramétert, ha ‘A rendezés státusza’ paraméter értéke hiba. Egy vagy több diagnosztikai rekordot tartalmaz.
Egyéb információ: Ezt a paramétert a forrás is és a cél is használhatja további információk közlésére, melyeket ez a szabvány nem határoz meg.
Hivatkozási azonosító: lásd 3.4.
3.2.8. Böngészés
Egyetlen szolgáltatásból áll: a böngészésből.
Különböző rendezett listák (pl. szerző, cím, tárgyszó) böngészésére ad lehetőséget. Az eredet megadja a listát, melyet böngészni kíván és egy induló kifejezést, a tételek távolságát, a kívánt tételek számát és az induló kifejezés pozícióját a válaszban.
Paraméterek:
Eredet 	Cél	
Paraméter	kérése	válasza	
Adatbázis nevek	x		
Lista és kiindulópont	x		
Kifejezések távolsága	x (opcionális)	x (ha van értelme)	
Kifejezések száma	x	x	
Pozíció a válaszban	x (opcionális)	x (opcionális)	
Böngészési státusz		x	
Kifejezések		x	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (ha van értelme)	
Adatbázisnevek: A paraméter megadja az adatbázisok nevét, melyekben az eredet böngészni szeretne.
Lista és kiindulópont: Az eredet megad egy attribútum listát és egy kereső kifejezést. Az attribútum lista tartalmazza azokat az attribútumokat, melyek megadják, hogy mely listákat kívánja böngészni, a kereső kifejezés pedig megadja, hogy mely kifejezéstől kezdve.
Tételek távolsága: Az eredet megadhatja a válaszlistában két szomszédos kifejezés között kihagyott tételek számát. A 0 érték azt jelent, hogy ne hagyjon ki egyet sem. Ha a cél nem tudja a megadott távolságot támogatni, akkor hibát jelez a ‘Böngészési státuszban’ és üzenetet küld, hogy pl. “csak a 0 távolság megengedett”. Ha az eredet nem adja meg ezt a paramétert, akkor a távolságot a cél választja ki és válaszában közli az eredettel.
Tételek száma: Az eredet a visszakért tételekre javaslatot tesz. A cél jelzi a visszajuttatott tételek aktuális számát. Ha az aktuális szám kevesebb, mint a javasolt szám, akkor ennek okát a böngészési státuszban adja meg.
Pozíció a válaszban: Az eredet opcionálisan megadhatja a megadott kiindulási pont pozícióját a visszaadott tételek listájában. 1 azt jelenti, hogy a lista a kereső kifejezéssel kezdődjön, 0 azt jelenti, hogy az utána következő tétellel kezdődjön a lista.
Böngészési státusz: A cél tájékoztat a művelet eredményéről. A definiált értékek az alábbiak:
siker	- A válasz a kívánt számú tételt tartalmazza.	
részleges-1	- Az összes kért tételt nem lehetett visszaadni, mert a műveletet hozzáférés ellenőrzés szakította meg.	
részleges-2	- Nem minden kért tétel fér el a válaszban.	
részleges-3	- Az összes kért tételt nem lehet visszaküldeni, mert a műveletet erőforrás ellenőrzés szakította meg az eredet kérésére.	
részleges-4	- Az összes kért tételt nem lehet visszaküldeni, mert a műveletet a cél erőforrás ellenőrzéssel megszakította.	
részleges-5	- Nem lehet minden kért tételt visszaadni, mert a lista kevesebb elemet tartalmaz, mint amennyit az eredet kért.	
hiba	- Egy tételt sem lehet visszaadni. Egy vagy több diagnosztikai rekordot küld a cél.	

Tételek: A cél adja meg ezt a paramétert:
•	vagy 
- 	N tétel, ahol minden tétel vagy a listából való vagy diagnosztikai, ahol N az eredet által 	kért tételek száma	
-	N-nél kevesebb tétel és 0 is lehet (a böngészési státusz utal az okára)
•	vagy
-	egy vagy több diagnosztikai rekordból áll (a művelet nem zárult sikeresen és miért  nem)
Minden tétel a listában egy kifejezést tartalmaz (a kért adatbázisokból) és még választhatóan az alábbiakat:
•	Egy megjelenítési kifejezést (ha az aktuálist a cél nem tartotta megjelenítésre valónak).
•	Egy listát a javasolt attribútumokról, melyeket további böngészéshez fel lehet használni.
•	Egy másik kereső kifejezést.
•	Előfordulási információt (a kereső kifejezés hány rekordban fordul elő).
•	Egyéb a kifejezésre vonatkozó információt.
Egyéb információ: Ezt a paramétert a forrás is és a cél is használhatja további információk közlésére, melyeket ez a szabvány nem határoz meg.
Hivatkozási azonosító: lásd 3.4.
3.2.9. Kibővített szolgáltatások
Egyetlen szolgáltatásból áll, a kibővített szolgáltatásokból (KSZ). A KSZ révén az eredet létrehozhat, módosíthat vagy törölhet egy feladatcsomagot (task package) a célnál. A cél a feladatcsomagokat egy speciális adatbázisban tartja nyilván. Ebben minden feladatcsomag egy KSZ feladatra vonatkozik.
Egy kibővített szolgáltatás az egy olyan feladattípus, mely kapcsolódik ugyan az információ kereséshez, de nem Z39.50 szolgáltatás. A feladatok végrehajtása a célnál történik a szabvány keretein kívül. Definíciójukat a 8. melléklet (Appendix 8 EXT) tartalmazza.
Az eredet KSZ kérést küld a célhoz, melyben egy feladat végrehajtását kéri. A kérés tartalmazza azokat a paramétereket, melyekre a célnak a feladatcsomag létrehozásához szüksége van. A cél visszaküld egy KSZ választ, melyben közli az eredettel, hogy a kérést elfogadja vagy jelzi, hogy miért utasítja vissza.
A KSZ szolgáltatás visszaigazolt szolgáltatás, melyet az eredet kezd, a cél fejez be és esetleg hozzáférés ellenőrzés vagy erőforrás ellenőrzés szakítja meg. Bár a kérés egy feladatot kezdeményez, maga a feladat nem tartozik a Z39.50 művelethez. A cél válasza nem feltétlenül jelzi azt, hogy a feladat végrehajtása megtörtént-e. A feladat élettartama hosszabb is lehet, mint maga a Z-kapcsolat.
A KSZ művelet eredménye egy feladatcsomag létrehozása, amelynek egy rekord felel meg a KSZ adatbázisban.
A feladatcsomag tartalmaz egyrészt olyan paramétereket, melyek a csomag típusától függetlenül minden feladatcsomagban közösek, másrészt olyanokat, melyek csak az adott feladatcsomagra jellemzőek. A közös paraméterek egy részét az eredet adja meg, egy részét a cél. Az adott feladattípusra jellemző paramétereket a szabvány 8-as melléklete (Appendix 8 EXT) tartalmazza.
Paraméterek:
Eredet 	Cél 	Feladat	
Paraméter	kérése	válasza	
Funkció	x		
Csomagtípus	x		
Csomagnév	x (opcionális)	x (opcionális)	
Felhasználói azonosító	x (opcionális)	x (opcionális)	
Megőrzési idő	x (opcionális)	x (opcionális)	
Engedélyek	x (opcionális)	x (opcionális)	
Leírás	x (opcionális)	x (opcionális)	
Cél hivatkozása		x (opcionális)	
Létrehozási idő		x (opcionális)	
Feladat státusza		x	
Csomag diagnosztika		x (opcionális)	
Feladattípusra jellemző pár.	x	külön	
		mindre	
Várakozási akció	x		
Elemek	x (ha van értelme)		
Műveleti státusz		x	
Műveleti diagnosztika		x (ha van értelme)	
Feladatcsomag		x (ha van értelme)	
Egyéb információ	x (opcionális)	x (opcionális)	
Hivatkozási azonosító	x (opcionális)	x (opcionális)	
Funkció: Létrehozás, törlés vagy változtatás lehet. Ha a funkció a létrehozás, akkor a célnak létre kell hoznia egy feladatcsomagot és a csomagnevet hozzárendelni, amennyiben az meg van adva. Ha a funkció a törlés vagy a változtatás, akkor a célnak a csomagnevű feladatcsomagot törölnie kell vagy meg kell változtatnia. A cél meg is tagadhatja ezeket a kéréseket, ha a feladat végrehajtása már folyik vagy a csomag használatban van. Ha a funkció törlés, akkor a célnak nem szabad a megadott feladatot elindítania, ha az még nem történt meg. Ha már a végrehajtás elkezdődött, akkor a végrehajtást meg kell szakítania vagy a kérést vissza kell utasítania. Változtatás esetén a paraméterek értékeit kell megváltoztatnia.
Csomagtípus: A kért KSZ típusát adja meg:
•	találathalmaz mentése későbbi használatra
•	keresőkérdés mentése későbbi használatra
•	időszaki keresési profil definiálása
•	egy tétel megrendelése
•	adatbázis aktualizálása
•	export jellemzők megadása
•	korábban létrehozott export specifikáció felidézése
Csomagnév: Az eredet megadhat egy nevet a feladatcsomaghoz. Ha ad nevet, akkor a (csomagtípus, felhaszn. azonosító, csomagnév) hármasnak egyedinek kell lennie és ez a hármas azonosítja a későbbi hivatkozások számára a feladatcsomagot. A csomagnevet meg kell adni, ha az eredet a későbbiekben hivatkozni akar a feladatcsomagra.
Felhasználói azonosító: A feladatcsomaghoz kapcsolódó felhasználó neve. Ha nincs megadva, akkor a felhasználó azonosítója.
Megőrzési idő: Az eredet megadhat megőrzési időt (pl. 2 óra, 3 nap, 1 hét), melyet a cél felülbírálhat. Ha a megőrzési idő lejárt, akkor a cél törölheti a megőrzött feladatcsomagot. Nulla megőrzési idő azt jelenti, hogy a feladat végrehajtása után a feladatcsomagot a célnak nem kell megőriznie.
Engedélyek: Az eredet megadhatja, hogy ki férhet hozzá a feladatcsomaghoz. Ha nem ad meg semmit, akkor csak a feladatcsomagot létrehozó felhasználó teheti ezt meg.
Leírás: Az eredet megadhatja pl. egy megőrzött találati halmaz vagy kereső kérdés leírását.
Cél hivatkozás: A cél adhat egyedi azonosítót a feladatcsomagnak.
Létrehozási idő: A cél adja meg a feladatcsomag létrehozási dátumát és idejét.
Feladat státusz: A cél adja meg a feladat státuszát, mely ‘függő’, ‘aktív’, ‘befejezett’ és ‘megszakítva’ lehet.
Csomag diagnosztika: A cél egy vagy több diagnosztikai információt adhat meg a feladatcsomagban.
Feladatra jellemző paraméterek: Mindegyik KSZ-ra más paraméterek. A szabvány 8. melléklete tartalmazza a definíciójukat.
Várakozási akció: Az eredet jelzi, hogy a cél tartalmazza-e válaszában a feladatcsomagot. Ennek az azonnali válaszolási mechanizmusnak köszönhetően el lehet kerülni azt, hogy később a feladatcsomagot keresni kelljen az KSZ adatbázisban.
4 érték lehetséges:
•	Várj: a célnak el kell végeznie a feladatot, mielőtt a választ visszaküldené és a válaszban tartalmaznia kell a feladatcsomagot. Ha erre a cél nem hajlandó, akkor a kérést ‘hiba’-val vissza kell utasítania.
•	Várj, ha lehetséges: az eredet azt kéri, hogy a cél lehetőleg a válasz visszaküldése előtt hajtsa végre a feladatot. Ha ez nem lehetséges, akkor a célnak úgy kell végrehajtania a feladatot, mintha a paraméter értéke ‘Ne várj’ lenne.
•	Ne várj: az eredet nem kéri a feladat előzetes végrehajtását.
•	Ne küldd a feladatcsomagot: a cél végrehajthatja a feladatot, de semmiképp ne tartalmazza a feladatcsomagot.
Elemek: Az eredet akkor adhatja meg ezt a paramétert, ha a ‘Várakozási akció’ nem ‘Ne küldd a feladatcsomagot’. Ez egy elemhalmaz név a feladatcsomag számára.
Műveleti státusz: A KSZ művelet státusza. Az alábbiak egyike lehet:
kész	- A kérést elfogadta a cél, a feladatot végrehajtotta és a feladatcsomag tartalmazza az eredményeket.	
elfogadva	- A kérést a cél elfogadta. A feladat végrehajtásra vár vagy folyamatban van a végrehajtás.	
hiba	- A kérést elutasította a cél és egy vagy több diagnosztikai megállapítással szolgál.	
Műveleti diagnosztika: A cél további diagnosztikai információt nyújthat, amennyiben a műveleti státusz ‘hiba’.
Feladatcsomag: Ha a műveleti státusz ‘kész’, akkor a cél tartalmazza a feladatcsomagot.
Egyéb információ: Ezt a paramétert a forrás is és a cél is használhatja további információk közlésére, melyeket ez a szabvány nem határoz meg.
Hivatkozási azonosító: lásd 3.4.
3.2.9.1. A KSZ adatbázis
A KSZ-t lehetővé tevő célok elérést biztosítanak az ún. KSZ adatbázishoz. Ennek az adatbázisnak a rekordjai feladatcsomagok, melyeket a kérés paraméter csomagjából hoz létre a cél. A cél megőrizheti (de erre nem köteles) a feladatcsomagot addig, amíg a kért feladatot befejezte, megőrizheti addig, amíg az eredet kéri a törlését és egyoldalúan is törölheti azt bármikor a KSZ adatbázisból.
Valójában a célnak nem kell létrehoznia a feladatcsomagot, ha a feladatot rögtön végrehajtja. De ha a feladat státusza függő, aktív, vagy megszakadt, akkor ajánlatos ezt megtennie.
Amikor a cél megkap egy KSZ kérést, akkor azonnal létrehozhat egy feladatcsomagot a ‘függő’ státusszal. Így az eredet bármikor keresheti ezt a feladatcsomagot az adatbázisban, ugyanabban vagy egy későbbi Z-kapcsolatban. Különösen akkor, ha egy KSZ művelet megszakadt, akkor az eredet megnézheti, hogy a kérést a cél megkapta-e.
A KSZ adatbázisról említést lehet tenni az Info adatbázisban, a kibővített szolgáltatások listáját, a megengedett exportálási lehetőségeket meg lehet adni ott.
A KSZ adatbázis úgy jelenik meg a felhasználónak, mint bármely más, a cél által támogatott adatbázis. A KSZ adatbázis rekordjait a Z39.50 keresési és visszaküldési lehetőségeivel lehet keresni és megjeleníteni. Az adatbázis kereséséhez szükséges attribútum halmaz a szabvány 3-as mellékletében van megadva. A feladatcsomag szerkezetét a szabvány 8-as melléklete tartalmazza.
Az eredet csak abban a Z-kapcsolatban kaphat választ a KSZ kérésére, amelyben azt feladta. Ha a KSZ művelet megszakadt, akkor az eredet nem kap befejező választ. Ennek nincs hatása a feladat elvégzésére a várakozási akció értékétől függetlenül. Ha a KSZ művelet megszakad, a ‘Várakozási akció’ automatikusan a ‘Ne küldd a feladatcsomagot’ értéket tételezi fel. Ha a KSZ művelet megszakadt, akkor az eredet keresheti a KSZ adatbázist az információk végett, melyet amúgy a válaszban megkapott volna.
3.2.10. Tájékoztatás
A tájékoztatási lehetőség révén az eredet a célnál található implementációról kaphat részletes információkat. Milyen kereshető adatbázisok vannak, milyen attribútum halmazokat és diagnosztikai halmazokat használ a cél, milyen a rekordszintaxis és az elemek definíciója, stb.
Tájékoztatási lehetőséget kínáló cél
•	elérést biztosít egy ún. IR-Explain-1 adatbázishoz (INFO adatbázisként fogunk rá utalni),
•	támogatja a tájékoztatási attribútum halmazt, melyet a szabvány 3-as melléklete definiál,
•	támogatja a tájékoztatási szintaxist, melyet a szabvány 5-ös melléklete (Appendix 5 REC) definiál.
Az INFO adatbázisban található rekordokra info rekordokként fogunk utalni.
Az INFO adatbázis ugyanúgy jelenik meg az eredet előtt, mint bármely más cél által támogatott adatbázis. De a keresés megkönnyítése végett egyes kereső kifejezéseket előre definiáltak.
Az Exp-1 attribútum halmaz (lásd 4.) használatos az INFO adatbázis keresésére. A Use attribútumok és a kereső kifejezések kombinációi segítségével lehet az egyes információs kategóriákat keresni, pl. a kereső kifejezés lehet a ‘DatabaseInfo’, a Use attribútum az ‘ExplainCategory’, vagyis az ExplainCategory=‘DatabaseInfo’ kereső kérdéssel azok a rekordok kereshetők vissza, melyek az adatbázisokról tartalmaznak adatokat. Amennyiben megadunk egy ún. kulcsot is, mely pl. lehet az ‘adatbázisnév’, akkor közvetlenül az ‘adatbázisnevű’ adatbázisról kapunk információkat.
Néhány előre definiált információs kategória és kulcs
Információs kategória	Miről szolgáltat infot	Kulcs	
‘TargetInfo’	a célról	a cél neve (target name)	
‘SchemaInfo’	az adatbázis sémájáról	az adatbázis neve	
	(database name)		
‘TagSetInfo’	a rekord elemeihez rendelt 	a hívójelhalmaz	
hívójelekről	azonosítója (tagSet oid)		
‘RecordSyntaxInfo’	a rekordszerkezetről	a rekordszerkezet	
	azonosítója		
	(record syntax oid)		
‘AttributeSetInfo’	egy adott attribútumhalmazról	attribútum halmaz	
	azonosítója		
	(attribute set oid)		
‘ExtendedServicesInfo’	egy adott KSZ-ról	KSZ azonosítója	
	(extended services oid)		
stb.
Az információk keresése egy adott nyelven: Minden rekord tartalmaz egy, az olvasható szöveg nyelvére vonatkozó elemet, mely megadja, hogy milyen nyelvű a rekordban található szöveg. Az INFO adatbázis tartalmazhat több rekordot is azonos információkkal, de különböző nyelveken. Adott nyelvű információk keresésére a HumanStringLanguage attribútum használható. A nyelvek kódját a Z39.53 elnevezésű 1994-es szabvány tartalmazza.
Például ha meg szeretnénk kapni az adatbázisok listáját angol nyelven, akkor a kereső kérdés következő formát ölthet:
(Category=‘DatabaseInfo’) AND (HumanStringLanguage=‘eng’)
3.2.11. Befejezés
A befejezési lehetőség egyetlen szolgáltatásból áll, a befejezésből.
A befejezés szolgáltatás révén az eredet is és a cél is váratlanul befejezhet minden aktív műveletet és kérheti a Z kapcsolat befejezését.
Csak a 3. verzióban használható.
Paraméterek:
Eredet 	Cél	Megj.		
Paraméter	kérése 	válasza		
Befejezés oka	x	x		
Diagnosztikai információ	x (opcionális)	x (opcionális)		
Erőforrás tájékoztatás formátuma	x		csak az eredet	
Erőforrás tájékoztatás	x (opcionális)	x (opcionális)	csak a cél	
Egyéb információ	x (opcionális)	x (opcionális)		
Hivatkozási azonosító	x (opcionális)	x (ha van értelme)		
Befejezés oka: Ez a paraméter jelzi, hogy az eredet vagy a cél miért fejezi be a Z kapcsolatot. Értékei: befejezve, gép lezárás (shutdown), rendszerprobléma, költséghatárok, erőforrások, biztonság megsértése, protokollhiba, tevékenység szünet, nem definiált, válasz a befejezés kérésre.
Diagnosztikai információ: A cél tetszőleges szövegben megadhat további diagnosztikai információt.
Erőforrás tájékoztatás formátuma és erőforrás tájékoztatás: Ha az eredet kéri a befejezést, akkor megadhatja ezt a paramétert azért, hogy a cél válaszában tartalmazzon erőforrás tájékoztatást. A cél döntése egyoldalú: tartalmazhatja és elhagyhatja ezt a tájékoztatást a paraméter ottlététől függetlenül. Ha a cél kéri a befejezést, akkor is ő dönt egyoldalúan a tájékoztatásról.
Egyéb információ: Ezt a paramétert a forrás is és a cél is használhatja további információk közlésére, melyeket ez a szabvány nem határoz meg
Hivatkozási azonosító: A hivatkozási azonosítót tartalmazhatja egy befejezési kérés vagy elhagyhatja. Ha a cél kéri a befejezést, akkor elhagyja a hivatkozási azonosítót. Ha nem a cél kérte a befejezést, akkor a válasznál tartalmazhatja a hivatkozási azonosítót, ha az eredet kérése is tartalmazta azt. Ha a kérés nem tartalmazott hivatkozási azonosítót, akkor a cél is elhagyhatja azt.

3.3. Üzenetméret, rekordméret, szegmentálás
A “szegmens” olyan üzenet, melyet a cél küld a megjelenítési válasz részeként, vagyis szegmentálási kérésként vagy megjelenítési válaszként. A rekordok egy halmaza akkor fér be a szegmensbe, ha a méretük összege nem lépi túl a javasolt rekordméretet. A megjelenítési műveletnél előfordul, hogy a cél nem tudja a kért rekordokat egyetlen szegmensbe betenni a rekord vagy üzenetméret korlátozások miatt. Ekkor a cél a megjelenítési választ szegmensekre bonthatja szét (amennyiben a szegmentálás érvényben van) úgy, hogy több szegmenst küld (azaz szegmentálási kéréseket küld, melyeket a megjelenítési válasz követ).
A szegmentálás két szintje, az 1-es és a 2-es megegyezés tárgyát képezik. Ha egyik sincs érvényben, akkor a cél válasza a megjelenítési kérésre egyetlen egyszerű megjelenítési válaszból áll, mely egész számú rekordot tartalmaz. Ha 1-es szintű szegmentálás van érvényben, akkor a cél válasza több szegmensből is állhat (szegmentálási kérések, melyeket egy megjelenítési válasz zár le) és minden szegmensnek egész számú rekordot kell tartalmaznia. Ha a 2-es szintű szegmentálás van érvényben, akkor a megjelenítési válasz több szegmensből állhat és a rekordok több szegmensen átnyúlhatnak.
Ha a 2-es szintű szegmentálás van érvényben, akkor a megjelenítési kérés tartalmazhatja az alábbi 3 paramétert:
Max. szegmens méret: A megengedhető legnagyobb szegmens. Ha meg van adva ez a paraméter, akkor ez hatálytalanítja a javasolt üzenetméretet. Ha nincs megadva, akkor a max. szegmens méret a javasolt üzenetméretet feltételezi.
Max. rekordméret: A megengedhető legnagyobb visszaküldött rekord a megjelenítési válaszban. Ha meg van adva, akkor egyenlőnek kell lennie vagy nagyobbnak, mint a max. szegmens méret.
A szegmentálás menete: Az alábbi eljárás a 2-es szintű szegmentálásra vonatkozik. A cél annyi egész számú rekordot illeszt az első szegmensbe, mint amennyi lehetséges. Ha minden belefér, akkor a szegmenst egyszerű megjelenítési válaszként küldi el. Máskülönben, ha marad még hely a szegmensben, akkor a következő rekord első részét is beilleszti és a szegmenst szegmentálási kérésként küldi el. Ezután a rekord maradékát a következő szegmensbe teszi bele és annyi egész számú rekordot tesz még be a szegmensbe, amennyi lehetséges. Így folytatja tovább, amíg a legutolsó rekordot is elhelyezte (vagy elérte a max. szegmens számot) ás a legutolsó szegmenst megjelenítési válaszként küldi el.

3.4. Műveletek és a hivatkozási azonosító
Az eredet adott műveleti típusra vonatkozó kérése elindítja a műveletet, melyet a cél megfelelő típusú válasza zár le. A következő műveleti típusok léteznek: kezdeményezés, keresés, megjelenítés, törlés, erőforrásjelentés, rendezés, böngészés és kibővített szolgáltatások. (Tehát az eredet minden típusú kérése egy műveleti típusnak felel meg, kivéve az indított erőforrás ellenőrzést és a befejezést). Egy művelet a kezdő kérésből és a befejező válaszból áll, esetleg közbenső hozzáférés ellenőrzési és erőforrás ellenőrzési kérésekből és válaszokból, és indított erőforrás ellenőrzési és szegmentálási kérésekből. Az eredet ad hivatkozási azonosítót a műveleteknek. Ha az eredet tartalmazza a hivatkozási azonosítót a kezdeményezési kérésben, akkor a művelet minden üzenetének kell ezt tartalmaznia. Ha ‘soros műveletek’ van érvényben, akkor a hivatkozási azonosítót a kezdeményezési kérésben el lehet hagyni, ekkor a hivatkozási azonosító nulla erre a műveletre és a művelet minden üzenetének el kell ezt hagynia.
Minden üzenetet, melyet az eredet küld a célnak vagy fordítva, része egy műveletnek az alábbi kivételekkel:
•	A Befejezési kérés vagy válasz nem része egy műveletnek sem.
•	Ha ‘párhuzamos műveletek’ van érvényben, akkor azok az erőforrás ellenőrzési vagy hozzáférés ellenőrzési kérések vagy válaszok, melyek nem tartalmaznak hivatkozási azonosítót, nem részei műveletnek.
A szabvány nem feltételez kapcsolatot az egymást követő műveletek között még akkor sem, ha ugyanaz a hivatkozási azonosítójuk. A szabvány nem definiálja a hivatkozási azonosító tartalmát, sem a jelentését, kivéve azt a tényt, hogy a műveletet azonosítja. A hivatkozási azonosítókat mindig az eredet adja és csak az eredet rendszerében van jelentésük.

3.5. Párhuzamos műveletek
Ha ‘párhuzamos műveletek’ van érvényben, a hivatkozási azonosító paraméter kötelező a kezdő kérésben és az eredet több párhuzamos műveletet kezdeményezhet, melyekhez különböző hivatkozási azonosítók tartoznak.
Amíg egy művelet tart, addig másik művelet nem kaphatja meg ugyanazt a hivatkozási azonosítót. A szabvány nem határozza meg, hogy a cél milyen sorrendben végzi el a párhuzamos műveleteket; a cél bármilyen sorrendben végrehajthatja azokat.

4. A keresés részletes elemzése
Egy a Z39.50 szabványon alapuló Z39.50 alkalmazás legalább a kezdeményezés, keresés és megjelenítés szolgáltatásokat kell hogy támogassa. Ennél kevesebb nem lehetséges. A jelenleg létező Z39.50-es lekérdezést lehetővé tevő könyvtári szerverek ezeken kívül főleg a találati halmaz törlését és a böngészést támogatják. Hogy a 3.2 alatt leírt szolgáltatások közül egy konkrét kliens szerver alkalmazás melyeket alkalmazza, attól függ, hogy a kliens által támogatott szolgáltatások és a szerver által támogatott szolgáltatások közül mennyi a közös. A közös szolgáltatások meghatározása a kezdeményezésen keresztül zajlik. A fizikai kapcsolat létrejötte után a kliens a kezdeményezési kérésben közli a szerverrel, hogy mely szolgáltatásokat támogatja. A szerver erre a kezdeményezési válaszban felel a saját listájával. Ezek után a konkrét kapcsolatban a közösen támogatott szolgáltatások alkalmazhatók.
A távoli adatbázishoz való hozzáférés minőségét a felhasználó számára lényegében a keresési szolgáltatás minősége határozza meg. A felhasználónak nem szabad észrevennie a különbséget a helyi adatbázishoz való hozzáférés és a távoli adatbázis közti hozzáférés között. Tételezzük fel, hogy van két rendszerünk: egy A és egy B. Általában két különböző rendszert különböző módokon lehet lekérdezni. Legyen most is ez a helyzet. A-nál a kereső kérdés lehetne pl.
SEARCH AU Jókai AND TIT A kőszívű ember fiai
a B rendszerben pedig
FIND AU = Jókai AND TI=A kőszívű ember fiai.
Mielőtt a kliens átküldené a szervernek a kereső kérdéseket, át kell mind a két kérdést a helyi szintaxisból egységes szintaxissá alakítania. Ennek a szintaxisnak annyira “okos”-nak kell lennie, hogy bármilyen helyi adatbázisban összeállított kereső kérdést egységes alakra tudjon hozni. A Z39.50-ben erre a célra definiálták az RPNQuery-t vagyis az RPN formátumot kereső kérdések összeállítására.
Minden Z39.50 alkalmazásnak két átalakítást kell tudnia elvégezni:
helyi szintaxis	=>	átalakított szintaxis	(a kliens feladata)	
átalakított szintaxis	=>	helyi szintaxis	(a szerver feladata)	
Az RPN formátum segítségével tetszőlegesen bonyolult kereső kérdéseket lehet összeállítani és ezekben lehet használni az AND, OR, AND NOT és a közelségi operátorokat. A kereső kérdésekben használatos mezőknek számértékek vannak megfeleltetve, melyeket szintén a szabvány határoz meg a Bib-1 elnevezésű attribútum halmazban. Az 1. táblázat részleteket közöl ebből az attribútum halmazból. (Az attribútum halmazokat a szabvány a 3. számú ATR: Attribute Sets mellékletében tartalmazza.)
Use (használat)	Value (érték)	
Personal name (személynév)	1	
Corporate name (testületi név)	2	
Conference name (rendezvénynév)	3	
Title (cím)	4	
:		
Subject precis	45	
:		
Abstract (összefoglaló)	62	
Note (megjegyzés)	63	
Author-Title (szerző-cím)	1000	
:		
Author-Title-Subject (szerző-cím-tárgyszó)	1036	
A keresőkérdésben tehát nem a mezőnevek szerepelnek, hanem az ezeknek megfeleltetett számok. A számok kiküszöbölnek sok problémás esetet: nem kell foglalkozni a kis és nagy betűkkel, és azzal sem, hogy a különböző rendszerek különböző mezőneveket használnak.
De a kereső kérdéseket nem lehet mindig pontosan megadni. Van amikor csonkolásra van szükség, van amikor nem ismert az egész cím, csak szavak belőle. Az előbbi példánál maradva az alábbi esetek lehetségesek még:
TI = A kőszívű ember fiai 	/az egész cím ismert/	(1)	
			
TI = kőszív*   	/csak részben ismert az első szó, a * 0 vagy egy karaktert jelent/	(2)	
			
TI = kőszívű fiai 	/több szó ismert és a sorrendjük is/	(3)	
			
TI= fiai ember	/több szó ismert, de a sorrendjük nem/	(4)	
Az ilyen típusú kereső kérdések átalakításához az RPN formátum az attribútumokat bocsátja rendelkezésre. Az előbb említett Bib-1 attribútum halmaz hat különböző attribútum típust definiál a hozzájuk tartozó értékekkel. A hat attribútum típus:
use attribútum	(1-es típus)	
relációs attribútumok	(2-es típus)	
pozíciós attribútumok	(3-as típus)	
szerkezeti attribútumok	(4-es típus)	
csonkolási attribútumok	(5-ös típus)	
teljességi attribútumok	(6-os típus)	

Kivonat a többi attribútum táblázatból:
Reláció	Érték		Pozíció	Érték	
kisebb mint	1		első a mezőben	1	
kisebb egyenlő	2		első az almezőben	2	
egyenlő	3		bárhol a mezőben	3	
nagyobb egyenlő	4				
:					

Szerkezet	Érték		Csonkolás	Érték	
kifejezés	1		jobb csonkolás	1	
szó	2		bal csonkolás	2	
szólista	6		bal és jobb	3	
dátum (nem norm.)	100		nincs csonkolás	100	
:			:		

Teljesség	Érték	
nem teljes almező	1	
teljes almező egyenlő	2	
egyenlő	3	
nagyobb egyenlő	4	
:		
Az attribútum halmazok értékeit felhasználva és leegyszerűsítve a kereső kérdés a (2)
FIND TI = kőszív*
RPN formátumban így néz ki:         1,4; 2,3; 3,3; 4,2; 5,1; 6,1; “kőszív”, mert
1-es use halmaz 4-es érték:	cím	1,4	
2-es relációs halmaz 3-as érték	egyenlő	2,3	
3-as pozíciós halmaz 1-es érték:	bárhol a mezőben	3,3	
4-es szerkezeti halmaz 2-es érték:	szó	4,2	
5-ös szerkezeti halmaz 1-es érték:	jobb csonkolás	5,1	
6-os teljességi halmaz 1-es érték	nem teljes almező	6,1	
Az RPN formátumú kereső kérdést a felhasználó számára észrevétlenül a Z39.50 kliens program állítja össze.
Ez a példa tipikus bibliográfiai alkalmazást mutatott be. De a Z39.50 bármilyen tartalmú és felépítésű adatbázis információinak visszakeresésére képes. Ha például egy felhasználó teljes szövegekben keres számára releváns fogalmakat, akkor az ilyen kereső kérdések összeállításánál a 3-as pozíciós halmaznak, az 5-ös szerkezeti halmaznak és a 6-os teljességi halmaznak nincs jelentősége. Egy teljes szövegű adatbázisban végzett keresés az alábbi módon nézhetne ki:
1,1010; 2,102; 4,105, “releváns fogalmak”
vagyis
1-es use halmaz 1010-as érték:	szövegtest	1, 1010	
2-es relációs halmaz 102-es érték:	szótő releváns	2, 102	
  4-es szerkezeti halmaz 105-ös érték:	szabad formájú szöveg	4, 105	
Az eddigi példákban mindig csak a Bib-1 alapú attribútum halmazról volt szó. De a szabvány lehetőséget adna tetszőleges Bib-1-hez hasonló felépítésű attribútum halmazok használatára. Zenészek létrehozhatnák a saját attribútum halmazaikat is a zeneművekre jellemző use attribútumokkal (pl. zeneszerző, a mű típusa, zenekar, stb.).

5. A lekérdezés és megjelenítés elemzése
A keresés elemzésekor azt néztük meg, hogy mit jelent a kereső kérdések átalakítása. Fordított irányban is szükség van azonban az átalakításra a találatok átviteléhez. A Z39.50 15 bibliográfiai formátumot definiál, pl. UNIMARC, USMARC, CANMARC, stb. és 4 ASN.1 formátumot. Amíg a bibliográfiai formátumok különálló szabványokban találhatók a Z39.50 keretein kívül, addig az utóbbi 4 formátum része a Z39.50 szabványnak. A 4 formátum rövid leírása:
SUTRS (Simple Unstructured Text Record Syntax = egyszerű, nem strukturált szöveges rekord szintaxis)
A kereső kérdéssel megtalált rekord tartalmát soronként, de tovább nem bontva bocsátja rendelkezésre. A kliens alkalmazás ezért az ilyen formátumú információt nem tudja programmal tovább feldolgozni.
OPAC rekord szintaxis
A megtalált rekord tartalmát a bibliográfiai formátumok egyikében bocsátja rendelkezésre. Ezenkívül a valós objektum meglétéről, kikölcsönözhetőségéről is szolgáltat információt strukturált formában.
SUMMARY rekord szintaxis
Ez a formátum az adatbázisrekord kiválasztott elemeit (pl. szerző, cím, absztrakt, dokumentum szám) bocsátja rendelkezésre strukturált formában.
GRS-1 (Generic Record Syntax 1)
A GRS-1 a legrugalmasabb, de ugyanakkor a legösszetettebb formátum. A rekord elemeit tetszőlegesen kiválogatva, strukturált formában, kívánt megjelenítésben (pl. szöveg, mint HTML dokumentum, kép, mint GIF file, stb.) tudja a felhasználó rendelkezésére bocsátani.

6. A Z39.50 és a World Wide Web
A World Wide Web (WWW), ez a kliens-szerver felépítésű rendszer, kétségtelenül olyannyira átalakította a hálózati információk elérésének természetét, hogy ma a WWW-t tartják az Internet legfontosabb navigáló eszközének. A WWW a HTTP protokollal működik a TCP/IP felett.
A dokumentumok létrehozásához és kezeléséhez a WWW nagyon egyszerű formátummal rendelkezik: a dokumentum részeit csupán meg kell címkézni a HTML jelzéseivel, hogy a kívánt formájú legyen (főcímek, betűnagyság, betűtípus, képek, gombok, stb.). Ezek a műveletek sokféle, erre a célra kifejlesztett szövegszerkesztővel elvégezhetők. A WWW hipertext természetének megfelelően a WWW oldalakról hivatkozni lehet más szövegekre, képekre, hangokra, video file-okra, melyek valahol a világon egy másik számítógépen találhatók.
A HTTP protokoll főbb műveletei:
• kapcsolódás:	a kliens létrehozza a kapcsolatot a szerver felé	
• kérés:	a kliens a kérést elküldi a szervernek	
• válasz:	a szerver választ küld a kliensnek	
• befejezés:	egyik vagy mind a két fél lezárja a kapcsolatot	
Az egyszerű, hipertextes kapcsolódással létrejövő böngészési műveleteken túl a felhasználó kereséseket is kezdeményezhet űrlapok (HTML oldalak) kitöltése révén, melyre a WWW szerver válaszol: a keresést CGI scriptek segítségével elvégzi és az eredményt HTML formátumban elküldi.
Felmerül a kérdés: ha mind a két szabvány elősegíti a több helyen meglevő, úgynevezett osztott információk elérését, mind a kettő kliens - szerver felépítésű, akkor miért nem elég az egyik közülük?
Miért felel meg jobban a Z39.50 az összetettebb, OPAC jellegű munkához?
•	A WWW-s kliens alig játszik szerepet az előbb ismertetett lekérdezési műveletben, a szerver dönt a találatok megjelenítésében. A WWW-vel ellentétben a Z39.50 kliens maga dönt a rekordok megjelenítéséről, így az adatbázisok egyformán jelennek meg a végfelhasználó előtt, a fizikai osztottság és heterogenitás rejtve marad.
•	A WWW kliens “buta”, a különféle szerverektől különböző HTML lapokon beérkező különböző rekordokat nem tudja tovább hasznosítani (pl. könyvtárközi kölcsönzésre, vagy elektronikus dokumentum rendelésre). A Z39.50 kliens “intelligens”, a szabványos formában megkapott rekordokat megérti és azokat különféle további szolgáltatásokhoz fel tudja használni.
•	Sok OPAC többet tud a hagyományos keresés, lekérdezés, rendezés és megjelenítés négyesnél. Tudja a keresési eredményeket manipulálni, könyvtárközi kölcsönzéseket végrehajtani, többféle heterogén adatbázist elérni. OPAC szintű lekérdezéseket a WWW-vel nem lehet végrehajtani. A HTML-nek nincsenek meg az eszközei a katalógus rekord szöveges elemeinek (pl. alcím, szerző, kulcsszavak, stb.) értelmezésére és helyes megjelenítésére. A könyvtári alkalmazás igazi funkcionalitását csak a Z39.50-nel lehet kiaknázni.
Általánosan elismert tény, hogy a jövő könyvtára az együttműködésre van alapozva. Az egyes könyvtári szolgáltatásokat, mint pl. a könyvtárközi kölcsönzés, dokumentum szolgáltatás, virtuális közös katalóguskészítés, egymással integrálni kell. Az ilyen osztott könyvtári szolgáltatások és rendszerek együttműködésének a kulcsa a Z39.50.

6.1. A Z39.50 és a WWW összekapcsolása
A mai felhasználók gyakran kombinálják a két szabványt és mind a kettőnek az előnyeit használják fel. Például WWW interfészt használnak a Z39.50 kliens elérésére. A WWW biztosítja a széles körű elérést, míg a Z39.50 a közös interfészt, a rekordok szabványos formájú átvitelét garantálja.
A WWW-t az alábbi három tulajdonsággal lehet, mint számítógépes rendszerek virtuális hálózatát jellemezni:
•	minden résztvevő szerver a legkülönbözőbb információkat - adatbankok, szövegek, hipertextek, képek - bocsátja rendelkezésre.
•	az egy-egy szerver által rendelkezésre bocsátott információt valamilyen Internet protokoll segítségével lehet - ftp, Gopher, HTTP, Z39.50 stb. - elérni.
•	a felhasználó az információkhoz valamilyen WWW-kliens, böngésző segítségével fér hozzá.
Minden Z39.50 alkalmazásra áll az első két tulajdonság, vagyis
•	minden Z39.50 szerver információkat tesz elérhetővé
•	az információt a Z39.50 protokoll segítségével lehet elérni
A 3. tulajdonságot elemezve kiderül, hogy a Z39.50-es alkalmazások elérésének két alapvető módja lehetséges a WWW segítségével:
1.	közvetlenül valamely WWW böngésző révén
2.	HTTP - Z39.50 gateway útján
6.1.1. A WWW-böngésző kibővítése Z39.50 kliens komponenssel
A WWW alapját képező modell abból indul ki, hogy minden Interneten elérhető információforrást egy ún. URL-lel címeznek meg és így válik a felhasználó számára elérhetővé. Az URL eleget tesz egy adott, általános szintaxisnak, melyet az RFC 1738 rögzít, és az egész, a megcímzett objektum visszakereséséhez szükséges információt tartalmazza:
•	a hozzáféréshez szükséges protokollt (pl. ftp, gopher, Z39.50, stb.)
•	a rendszer fizikai címét
•	az elérési utat
Az URL konkrét szintaxisa függ az alkalmazási protokolltól. Jelenleg már szabványosítva van a fentebb említett RFC 1738 szerint például az ftp-, Telnet-, WAIS‑, NNTP-, és a HTTP- URL. Néhány példa konkrét URL-ekre:
ftp:// ftp.uni-miskolc.hu
http://www.netscape.org/users/dwb/url-guide.html/
A Z39.50 alkalmazási protokollhoz már két URL-t definiáltak egy ún. Z39.50 Retrieval-URL-t (visszakeresési URL) és egy ún. Z39.50 Session - URL-t (kapcsolati URL). Mind a két URL-re jellemző az, hogy az URL-ben megtalálható kereső kérdés a dokumentum azonosítójára vonatkozik és ezáltal egyértelműen pontosan egy találatot fog eredményezni. Egy konkrét Z39.50 visszakeresési URL így nézhetne ki:
Z39.50://ddb.dbf.hu/PublicOPAC?Doc5731
Az URL aktivizálásánál a ddb.dbf.hu/PublicOPAC?Doc5731 információ átkerül a Z39.50 klienshez, mely
•	létrehozza a kapcsolatot a ddb.dbf.hu Z39.50 szerverrel
•	a Z39.50 kapcsolatot a Kezdeményezés szolgáltatással megnyitja
•	elküld egy RPN lekérdezést a docid Use attribútummal és a DOC5731 kereső kifejezéssel
•	a keresési eredmény átvétele után a kapcsolatot lebontja
•	a felhasználónak megjeleníti az eredmény HTML formátumban.
A Z39.50 Session URL szintaxisának definíciója megfelel a Z39.50 Retrieval URL definíciójának, de míg abban pontosan egy adott lekérdezés végrehajtására kerül sor, addig a Session URL célja egy teljes Z39.50 kapcsolat létrehozása. Ekkor egy Z39.50 kliens felhasználói felülete jelenik meg a felhasználó előtt a Z39.50 minden lehetőségével együtt. Az eredményeket a felhasználó nem szükségképpen HTML formátumban kapja meg.
6.1.2. HTTP - Z39.50 gateway alkalmazása:
A Z39.50-es alkalmazásokhoz való hozzáférésnek ez a módja nem igényli a WWW-böngésző kibővítését, de szükség van egy HTTP - Z39.50 gateway-re. A WWW böngésző és a gateway között a kommunikáció a saját HTTP protokollon keresztül zajlik, míg a kommunikáció a gateway és a Z39.50 szerver között a Z39.50 protokollon keresztül. A gateway lehet helyi és központi. A helyi gateway segítségével csak a helyi adatbázisok érhetők el, míg a központi gateway révén a gateway számára távoli Z39.50 alkalmazások is elérhetőek.
Több ilyen gateway létezik már. Néhány ezek közül:
Ameritech Library Services	WebPAC	
Geac	GeoWeb	
Library of Congress	Z39.50 Gateway	
OCLC	WebZ	
A Library of Congress gateway-je révén (http://lcweb.loc.gov/z3950/gateway.html) hozzáférést biztosít helyi adatbázisaihoz és további 70 amerikai, kanadai és európai Z39.50 alkalmazáshoz. Miután a felhasználó az LC-gateway URL-jét kiválasztotta, a WWW böngésző lekeres egy HTML alapú űrlapot, melyen a felhasználó választhat a felkínált Z39.50 szerverek közül. Ezután megtörténik a kapcsolódás a kért szerverhez és itt a felhasználó kitölt egy HTML űrlapot a kereső kifejezéseit megadva. A böngésző ezek után a mezőkbe bevitt adatokat előre definiált módon egy karaktersorozattá összeolvasztja és még mindig a HTTP protokollon keresztül eljuttatja a gateway-nek. Ott a lekérdezést megkapja a Z39.50 kliens, átalakítja Z39.50 lekérdezéssé és továbbítja a Z39.50 szervernek. A szerver a keresés eredményét átadja a Z39.50 kliensnek a Z39.50 protokoll útján, a kliens továbbítja azt a gatewaynek, mely HTML dokumentummá alakítja és a böngészőnek átadja.

7. Létező Z39.50 alapú alkalmazások
7.1 Néhány európai Z39.50-re alapuló projekt
7.1.1. IRIS
Az IRIS (Irish Interlending Service) egyike a legelső Z39.50-re alapuló szolgáltatásoknak. 1992-ben indult. Jelenleg kereskedelmi célzatú dokumentum nyilvántartással és szolgáltatással foglalkozik üzleti, könyvtári és más információközvetítő intézmények igényeit figyelembe véve az Ír Köztársaságban. A felhasználók hat ír könyvtár és az UnCover amerikai folyóiratügynökség katalógusaiból kereshetnek le és rendelhetnek meg számukra érdekes dokumentumokat. A projektet az az igény indította el, hogy hatékonyabban szerették volna kihasználni egymást között az ír könyvtárak szellemi vagyonát. A stratégiai döntés az volt, hogy inkább átjárhatóan kapcsolják össze a független könyvtári katalógusokat, minthogy létrehozzanak egy osztott katalógust. A szolgáltatások magjául Z39.50-re alapuló alkalmazás mellett döntöttek.
A különböző felhasználói kategóriáknak megfelelően különböző szolgáltatási szintek léteznek. A résztvevő könyvtárak olvasói pl. más feltételekkel használhatják a rendszert, mint a kereskedelmi felhasználók.
A IRIS könyvtárak az UnCover felhasználóknak is szolgáltatnak dokumentumokat.
A rendszer felépítése: minden felhasználó először az IRIS kliens hosthoz kapcsolódik, mely a szolgáltatások integrált rendszerét kínálja fel, amelyek szükségesek egy kereskedelmi szolgáltatáshoz: keresési, dokumentumrendelési, nyilvántartási és számlázási szolgáltatások. A kereső kérdéseket Z39.50 kérdésekké alakítják át és a Z39.50 kliens révén a Z39.50 szervert üzemeltető könyvtárhoz továbbítják. Az IRIS-re jellemző, hogy párhuzamosan több Z39.50 kapcsolatot is létre tud hozni. A felhasználó egyszerre több könyvtárat is kiválaszthat a felhasználói interfész révén. A keresést lefuttatják mindegyik kiválasztott adatbázisban és az IRIS rendszer a visszaadott válaszokat egyezteti és a felhasználó számára érthető módon jeleníti meg. A könyvtárak Z39.50 szervereket implementáltak (Urica, BLCMP, Dynix és Oracle könyvtári rendszerek). A dokumentumrendelési szolgáltatás e-mail alapú és használ néhányat az ILL protokoll adatelemeiből, de nem a teljes protokollt.
A host kliens rendszert a Fretwell-Downing fejlesztette ki a Z39.50 2. verzióját használva TCP/IP felett. A felhasználók terminál eléréssel kapcsolódnak a hosthoz, de most már a Windows alapú elérést is megcsinálták. A Fretwell-Downing felhasználta itt néhány, a DALI projektben szerzett tapasztalatát.
7.1.2. DALI
DALI (Document and Library Integration) projektet a European Libraries Programme támogatta. 1995 elején indult. Brit, ír és görög egyetemek vesznek részt benne. A céljuk multimédia dokumentum szolgáltatást biztosítani osztott környezetben, a Z39.50-et és az SR-t használva. A projektet a Fretwell-Downing cég vezeti.
A projekt hangsúlyt helyez szabványos összetevőkön alapuló egységes rendszer kifejlesztésére. A cél olyan integrált szolgáltatás létrehozása, amely révén a felhasználó a dokumentumokat lekeresheti, megrendelheti, a dokumentum szolgáltatás révén azokat megkapja, de a szolgáltatások mögött meghúzódó mechanizmusok és bonyolult eljárások rejtve maradnak előtte. Három fő összetevője van a DALI rendszernek: a DALI kliens, az adatbázis szerverek és a DALI szerver. A DALI kliensen keresztül éri el a felhasználó a rendszert. Az erőforrásokat az adatbázis szerverek teszik elérhetővé. Ezek az erőforrások lehetnek bibliográfiai jellegűek, dokumentum szerverek stb.
A rendszer legérdekesebb része a kicsit zavarólag DALI szervernek elnevezett összetevő. Ez irányítja és szervezi a szolgáltatásokat: az adatbázisok keresését, a dokumentumok rendelését és a dokumentumok szolgáltatását. A DALI kliens és a DALI szerver saját protokoll révén kommunikálnak egymással. A DALI szerver az adatbázis szerverekkel szabványos protokollokon keresztül kommunikál (WAIS és Z39.50 a keresésnél; SMTP feletti ILL /Interlibray Loan/, HTTP és Z39.50 a dokumentumok rendelésénél; fax, e-mail és HTTP a dokumentumszolgáltatásnál). Ezenkívül a DALI szerver irányítja a rendszert és a számlázást, foglalkozik a felhasználók hozzáférési jogosultságainak kiosztásával és felügyeletével. A DALI szerver más módon is növeli a szolgáltatások értékét: a találatokat egyezteti, a formátumokat konvertálja, stb. A DALI az IRIS szolgáltatási környezet továbbfejlesztésének tekinthető: az IRIS keresést, dokumentum rendelést biztosít és ezeket a szolgáltatásokat hangolja össze. A DALI mindezt tovább fejleszti, kibővíti és hozzáadja a dokumentumszolgáltatást. Mind a két rendszer érdekes ellenpéldát mutat arra a naiv elképzelésre, mely szerint a végfelhasználónak elégséges az íróasztalára egy Web vagy egy Z39.50 kliens.
7.1.3. EUROPAGATE
Az EUROPAGATE projektet is az European Libraries Programme támogatja pénzügyileg. A résztvevő partnerek között van angliai, ír, dán, spanyol könyvtár. A projekt 1994 elején kezdődött és 1996 januárjában 70 %-ban fejeződött be. Az EUROPAGATE céljai az alábbi címszavakban foglalhatók össze:
1.	az SR és a Z39.50 közötti gateway létrehozása
2.	az SR/OSI és a Z39.50/TCP/IP közötti gateway megteremtése
3.	egyéb gateway funkciók létrehozása, pl. a szerverek elérése e-mail-lel, több szerver együttes elérése és a gateway elérése Web-es felületen.
A projekt folyamán bekövetkező változások azonban eltolták a hangsúlyokat ezen a sorrenden. Az 1. szükségessége csökkent, hiszen a két protokoll (SR és a Z39.50 ) közelít egymáshoz. A 2. fennmarad ugyan, bár nagyon kevés szerver működik jelenleg OSI környezetben és ezért ilyen gateway-re a jelen körülmények között nincs igazán igény. Nem lehet azonban tagadni a projekt ezen részében rejlő potenciális értéket, több kereskedelmi szerver ugyanis lehet, hogy mOSI (minimális OSI) környezetben fog működni. Ez azonban egyelőre kiszámíthatatlan. A 3. keretén belül a gateway biztosítja a különböző MARC formátumok közötti konverziót és lehetővé teszi a kereső kérdések e-mailben való elküldését és a találatok e-mail útján történő fogadását. A projekt további szakaszaiban a Web-es elérést is biztosítani akarják. A HTTP az egymás utáni kapcsolódások között nem őrzi meg az információt, a Z39.50 pedig a felhasználói kapcsolat vége után is megőrzi az információt. Az e-mail-es gateway kialakításánál a fejlesztők külön szoftvert iktattak be azért, hogy az információt a kliens részére megőrizzék. Ez most meg fogja könnyíteni a HTTP-től Z39.50-be vezető gateway megszerkesztését is és ezáltal az jobban használható lesz, mint a legtöbb ma kapható ilyen gateway. A fejlesztők a gateway létrehozásánál néhány létező szoftvert használtak fel, különösen a Nordic SR-t, a kanadai nemzeti könyvtár (National Library of Canada) IRToolját és a CNIDR Zdist szoftverét. A projekt folyamán kiderült, hogy több akadályt kell leküzdeniük, mint amennyire számítottak, sok programhibát fedeztek fel, kevés volt a dokumentáció.
A gateway végül is tartalmaz egy TCP/IP felett működő Z39.50 szervert és egy OSI felett működő SR szervert. Kereső kérdéseket elfogad TCP/IP felett bejövő Z39.50 kliensektől és OSI felett működő SR kliensektől és e-mail útján (ekkor a kérdéseket a CCL formátumban kell megfogalmazni) és ezeket lefuttatja bármelyik környezetben működő szerveren.
A projekt megvalósítói úgy gondolják, hogy a gateway nyilvánosan elérhető lesz. Ehhez összeszedték és leírták az összes olyan környezetet, amelyben használható lesz.
Bővebb információ: http://www.dtv.dk/egate/egate.html/
7.1.4. Pica
A Pica holland intézmény és nemzeti szinten nyújt automatizálást, osztott katalógust és más információs szolgáltatásokat az egyetemi és egyéb könyvtárak számára. Nemrégiben működését kiterjesztette Németországra is és a Pica féle osztott katalogizálást és könyvtári automatizálást sok német tartományban átvették.
A Pica megvalósította a források megosztásán és közös használatán alapuló rendszerekhez szükséges szolgáltatások létrehozását és most a hangsúlyt a végfelhasználót kiszolgáló információs rendszerek fontosságára helyezik. Vannak ill. lesznek olyan szolgáltatásaik, melyek révén a tagkönyvtárak olvasói erőforrások sorában (helyi katalógus, egyéb könyvtárak katalógusai, nemzeti osztott katalógus, tartalomjegyzék szolgáltatás, kivonatkészítő és indexelő szolgáltatások, távoli OCLC szolgáltatások) kereshetnek, a dokumentumokat megrendelhetik az ILL rendszerük révén és a dokumentumokat elektronikusan vagy más módon megkaphatják.
A Pica korán felismerte, hogy a jövő osztott könyvtári és információs rendszerei csak szabványokra, protokollokra alapozva képzelhetőek el és valósíthatóak meg. Vezető szerepet töltöttek be az ILL és az SR protokollok kifejlesztésében és most a ZIG-nek is aktív tagjai. Tapasztalataikat beleviszik a ONE és DBV-OSI II projektekbe (lásd később).
A szabványokat akkor kezdik szolgáltatásaikban alkalmazni, mikor azok megszilárdultak, elfogadottá váltak. Például az Open Library Network elnevezésű, OPAC-okat összekapcsoló projektet először nem a Z39.50-re alapozták, csak most teszik át arra. Az OCLC SiteSearch elnevezésű termékét használják kiválasztott könyvtáraik az OCLC ill. a Pica erőforrások elérésére Z39.50-es interfészek segítségével. A katalogizálóik Z39.50 kapcsolódást használnak az RLIN szolgáltatások elérésére.
7.1.5. SOCKER
A SOCKER (SR Origin Communication Kernel) projektet szintén az European Libraries Programme támogatta. 1992 decemberében indult be és 1995 végéig tartott. A dán UNI-C (Danish Computing Centre for Research and Education) koordinálta, résztvett benne még egy másik dán intézmény valamint az IME, a TINLib integrált könyvtári rendszer gyártója.
A projekt központi célkitűzése volt egy SR kliens létrehozásához szükséges toolkit (fejlesztő rendszer) megteremtése.
A projekt résztvevői a toolkitet használva fejlesztették ki saját SR kliensüket, így pl. az IME a TINLib rendszere OPAC-jába integrálta a SOCKER szoftvert.
A SOCKER magját úgy fejlesztették ki, hogy vagy a teljes OSI felett vagy közvetlenül TCP/IP felett működik. Mivel SR szerverek nincsenek, ezért a SOCKER szoftvert különböző Z39.50 szerverekkel tesztelték.
7.1.6. Nordic SR-Net
A ONE projekt előfutárának tekinthető a Nordic SR-Net. 1991-ben, viszonylag korán indult el és 1994-ben fejezték be. Ahogy a neve is sejteti öt északi országot fogott össze, Izlandot megfigyelőként. Egyike a nagyon kevés működő SR implementációknak, melyben öt különböző rendszeren futó katalógus együttműködése valósul meg. Mivel azonban nincsenek működő SR szerverek a projekt érdeklődése a ONE projekt felé irányul.
7.1.7. ONE
A ONE (OPAC Network in Europe) projektet is a European Libraries Programme támogatja. Hivatalosan 1995 elején indult és valószínűleg eddig a legnagyobb számú részvevőt (15) és országot (8) fogja össze. A projektet a BRODD (R&D and Consultancy Department of the Norwegian School of library and information science) vezeti és a résztvevők között van többek között a British Library, a Die Deutsche Bibliothek, a Pica, a BibSYS, stb. A projekt azért is jelentős, mert igen fontos európai intézményeket ölel fel. A projekt célja, hogy összekapcsolja a résztvevő nemzeti könyvtárak OPAC-jait és katalogizáló szolgáltatásait és olyan kísérleti szolgáltatást akar bevezetni, melynek révén egyetlen belépési ponton át el lehet az összes katalógust érni. A legtöbb résztvevő már fejleszt Z39.50 vagy SR alapú szolgáltatásokat, ezért ők a meglévő rendszereiket használják fel a további fejlesztés céljaira és a rendszerek jövendő egyesítésére. A projekt egyik kulcs célja olyan public domain (nyilvánosan és ingyenesen elérhető) eredet és cél szoftverek létrehozása, melyek mind a TCP/IP felett, mind OSI felett futnak. A karakterkészletek kérdése is előtérbe kerül. A projekttól egy Európát átfogó OPAC hálózat alapjainak létrehozását várják. A ONE a Satellites International Ltd brit cég által kifejlesztett Z39.50 szoftvert fogja használni, melyet az a DBV-OSI projekt számára fejlesztett ki.
Bővebb információ: http://www.bibsys.no/one.html/
7.1.7. DBV-OSI
A legtöbb felsorolt projekttől eltérően a DBV-OSI II-t nem az Európai Közösség támogatja. Ez egy német nemzeti projekt szövetségi támogatással. 8 résztvevő partner van benne. A Die Deutsche Bibliothek vezeti, részt vesznek többek között az STN, a DIMDI, a Deutsches Bibliotheksinstitut (DBI) és utolsó belépőként a Pica, mivel a résztvevő könyvtári rendszerek közül sok a Pica rendszerét használja.
A cél a keresés, a lelőhely információ nyújtásának, a dokumentumok rendelésének és szolgáltatásának egy rendszerbe foglalása és mindezt Z39.50-es alapon.
A brit Satellites International Ltd-nek kellett a szoftvert kifejlesztenie, melyben a Z39.50 3. verzió lehetőségeinek egy részhalmazát biztosítják. A felhasználói interfész a TCP/IP-t támogatja. Speciális műszaki megközelítés teszi azt lehetővé, hogy a szoftver maximálisan átvihető és újra felhasználható legyen. A ONE projekt is ezt a szoftvert fogja használni. A kliens Windows-os verzióját jelenleg fejlesztik.
A kölcsönös együttműködést 1996 szeptember végén kezdték tesztelni. A béta tesztelést 1996 januárjában kezdték el. A projekt második fázisában, mely 1997-ben kezdődik, implementálni szeretnék az ILL protokollt a dokumentum szolgáltatás támogatására. A projekt tervezi a Z39.50 dokumentumrendelési kibővített szolgáltatását.

7.2. Kereskedelmi alkalmazások
Az alábbi táblázat az európai legnagyobb forgalmazókat sorolja fel.
Rendszer	Forgalmazó	Z-kliens	Z-szerver	
Advance	Geac	igen	igen	
ALEPH	Ex Libris	igen	béta tesztelés	
BOOK Plus	Stowe Computing	96 végére várható	96 végére várható	
Data Trek	Data Trek	Windows-os kliens	nincs	
Dynix	Ameritech Library Services	igen	igen	
Horizon	Ameritech Library Services	igen	igen	
INNOPAC	Innovative Interfaces	igen 	igen	
Libertas	SLS	igen	igen	
Olib (Oracle Libraries)	Fretwell Downing	igen	igen	
Pica	Pica	igen	igen	
Plus	Geac	igen	igen	
Talis	BLCMP	nem	igen	
TINLIB	IME	fejlesztés alatt 	fejlesztés alatt	
Unicorn	Sirsi	igen	igen	
VTLS	VTLS	igen	igen	

7.3. Az Internet hálózatról letölthető Z39.50 kliens programok
A washingtoni Kongresszusi Könyvtár tartja fenn a Z39.50 Maintenance Agency ottlapját. Ez a lap sok fontos információt tartalmaz a szabvánnyal kapcsolatban. Az ottlap elérhető a
http://lcweb.loc.gov/Z39.50/agency/
címen. Felsorolja a Z39.50-es profilokat, a Z39.50 alkalmazóit, bibliográfiákat, cikkeket ismertet, leírja az 1995 óta történt változásokat, stb. Az európai ottlapot az UKOLN (UK Office for Library & Information networking) tartja fenn a bathi egyetemen. Címük:
http://ukoln.bath.ac.uk/z39.50/
Kevésbé hivatalos információk találhatók a “Pointer page about Z39.50 resources” ottlapon, melynek címe:
http://www.research.att.com/~wald/z39.50.html
Ezenkívül fontosabb Z39.50-nel kapcsolatos WWW címek:
Z39.50 kliensek: http://www.dstc.edu.au/RDU/reports/zclients.html
WWW-to-Z39.50 Gateways http://is.rice.edu/~riddle-webz39.50.html/
Számos kereskedelmi és ún. public domain Z39.50 kliens szerezhető meg. Ezek a kliensek sok mindenben különböznek.
Kliens neve
Opciók	Bookwhere	CIIR	CanSearch	Willow	YAZ	I-Site	
Keresés	I	I	I	I	I	I	
Megjelenítés	I	N	I	I	?	I	
Erőforrás
jelentés	N	N	I	I	N	N	
Böngészés	I	I	N	I	I	I	
Rendezés	N	N	N	N	N	N	
Kibővített szolgáltatások	N	N	N	N	N	N	

Kliens neve
Opciók	Bookwhere	CIIR	CanSearch	Willow	YAZ	I-Site	
Indított erőforrás ell.	I	N	I	N	N	N	
1-es szintű szegmentálás 	N	N	N	N	N	N	
2-es szintű szegmentálás	N	N 	N	N	N	N	
Párhuzamos műveletek	I	N	I	N	N	N	
Elnevezett találati halmazok	N	N	I	N	N	N	
Erőforrás ellenőrzés	I	N	Y	Y	N	N	
Hozzáférés ellenőrzés	?	N	I	N	N	N	
Rekord szintaxis
MARC
GRS-1
SUTRS
OPAC	
I
N
N
N	
I
I
I
I	
I
N
N
N	
I
I
N
N	
I
N
I
N	
I
N
I
N?	
Attribútum halmazok
Bib-1
Exp-1 (Info)
Ext-1 (KSZ)
CCL-1
GILS
STAS	
I
N
N
N
N
N	
I
?
?
?
I
?	
I
?
?
?
?
?	
I
N
N
N
N
N	
I
N
N
?
N
N	
I
N
N
N
N
N	
Kereső kérdések
0-típusok
RPN
ISO8777
Z39.50
ERPN
Rangsorolt lista	
N
I
N
N
N
N	
?
I
?
?
I
?	
N
I
N
N
N
N	
I
I
?
?
?
N	
N
I
I
N
N
N	
N
I
N
N
N
N	
Bookwhere?: Microsoft Windows alapú kliens program. Kereskedelmi forgalomban kapható, de 40 napos ingyenes kipróbálásra letölthető a hálózatról. Kimondottan könyvtári katalógusok elérésre tervezték, a bib-1 attribútum halmazt és a MARC formátumot tudja használni. Egy kereső kérdéssel több adatbázist is le tud keresni. A kereső kérdéseket és a találatokat magas szinten kezeli. Azokat az adatbázisokat keresi le, melyeket regisztráltak. A regisztrált adatbázisok file-ja is letölthető. 
Bővebb információ: http://www.netjobs.com:8000/seachange/bookweb.html

CanSearch: Microsoft Windows alapú kliens program. A CanSearch-t a National Library of Canada (Kanadai Nemzeti Könyvtár) számára készítették. Segítségével jól bemutathatók a Z39.50-ben rejlő lehetőségek. A 2-es verzió sok szolgáltatását támogatja, de gyenge a kereső kérdések és találatok kezelésében. Jól használható Z39.50-es cél alkalmazások tesztelésére, egyszerre több szerver is elérhető vele. A konfigurációja nehézkes. Új Z39.50 szerverek felismeréséhez egy bonyolult file-t kell kitölteni. A CanSearch szoftver része a National Library of Canada IRTool public domain programcsomagjának, melyet a már említett EUROPAGATE projektban is felhasználtak. 
Bővebb információ: http://www.ds.internic.net/Z39.50/nlc.txt

CIIR: (Center for Intelligent Information Retrieval)
Ez a Z39.50 3. verziójának megfelelő kliens a Windows alatti Netscape bővítésére, hogy az a Z39.50-es URL-eket értelmezni tudja. Egyszerre egy Z-szervert tud keresni. A kereső kérdések kezelése gyenge.
Bővebb információ: ftp://www.usgs.gov/pub/gils/ciir/dtic_a02/

I-Site: 1994 végén fejlesztette ki a CNIDR. Az ún. I-Site csomag tartalmazza a Zdist szervert, a Zclient WWW gateway-t, egy kereső alkalmazói programinterfészt (API = Application Programming Interface) és az Isearch nevű szövegkeresőt. Ezek együtt olyan teljes információs rendszert alkotnak, melyet Z39.50 kliensek és WWW kliensek (Mosaic, Netscape) is elérhetnek. Az I-Site-ot a C++ programozási nyelv GNU verziójában írták.
A szoftver magja a Zdist szerver a Z39.50 2. verziójának implementációja, mely a kéréseket a Z39.50 kliensektől fogadja, melyeket aztán a kereső API juttat el a helyi és távoli adatbázisokhoz. A dokumentumokat SUTR, GRS és USMARC rekordformátumban lehet kérni.
Bővebb információ: http://vinca.cnidr.org/pub/NIDR.tools/Isite/

Willow: A University of Washington Computing & Communications és az UW Libraries közös projektja alapján készült. 1992-től működik a Washington egyetemen. Sok UNIX rendszeren fut és tervezik a Windows alapú változatát is. A forrásprogram és a futtatható program is rendelkezésre áll. Csak egy szervert tud egy kereső kérdéssel lekeresni. Adatbázis konfigurációs file-ok közlik a Willow-val, hogy milyen adatbázisok elérhetőek, azok hogyan kereshetőek és a rekordokat hogyan lehet megjeleníteni. A szabványos konfigurációs file-okat is le lehet tölteni. 
Bővebb információ: http://www.washington.edu/willow

YAZ:
A YAZ a Z39.50 és az SR protokollok különböző szintű eléréséhez kínál “toolkit”-et. Az IrTcl kliens a YAZ használatát mutatja be. Az IrTcl kliens programot a dán Index Data szoftverház készítette. A Z39.50 2. verzióját támogatja. Unix operációs rendszerre készült. Egyszerre egy szervert képes keresni. A kereső kérdések és a találatok kezelése nem túl jó.
Bővebb információ: ftp://ftp.funet.fi/pub/doc/library/z3950/yaz/

8. Gondolatok a KözElKat projekttal kapcsolatban
A számítógépekkel elérhető online könyvtári katalógusok Magyarországon is egyre általánosabbá válása, majd a hálózatok elterjedése, a nagy külföldi osztott katalógusok létrejötte (OCLC, német tartományi katalógusok, PICA, stb.) természetszerűleg vezettek el arra a gondolatra, hogy hazai viszonyaink között is létrehozzunk egy országos szintű, WWW-n elérhető könyvtári katalógust, mely egységes felhasználói felületen biztosítaná sok magyar könyvtár nyilvános katalógusának elérését és később esetleg a könyvtárközi kölcsönzést. Egy központi szerveren lenne a lekérdező program, ahova WWW-s böngészővel lehet bejelentkezni, egy HTML űrlapon a kívánt könyvtárakat kiválasztani és a kereső kérdést is megadni. Jelenleg a projektben Szeged és Debrecen vesz részt és a Voyager integrált könyvtári rendszer katalógusait lehet WWW-n keresztül lekérdezni. Cím: http://www.sk-szeged.hu/burgi/ kozelkat.html
A gondolat jó, mindenképpen felkarolandó, gondok azonban felmerülnek több oldalról is. A legkönnyebben áthidalandónak talán az adatátvitelt biztosító hálózati összeköttetések jelenlegi szűkös keresztmetszete látszik. Hiszen a magyar vidéki városok is hamarosan mind élvezhetik az 512 Kbit nyújtotta gyorsaság előnyeit.
Haladjanak a Z39.50 irányában vagy sem? A Z39.50 ellen szól, hogy kevés magyar könyvtárnak van ma Z39.50 szerver elérése és ha elkészül a Z39.50 kliens, hány könyvtárat tudnak majd egyáltalán elérni? Megjegyzendő az is, hogy egy Z39.50-es kliens program kifejlesztése nem kevés vesződséggel jár. Egyelőre ezért úgy döntöttek, hogy saját programot fejlesztenek ki. Ennek nagy hátránya azonban, hogy minden részt venni akaró könyvtárnak saját rendszerét illesztenie kell, vagyis a közös lekérdező program elvárásainak megfelelő szerkezetben biztosítani az adatok átadását. Ez azt jelenti, hogy ahány rendszer létezik, annyi külön programot kell elkészíteni.
Szerény véleményem szerint mégiscsak a Z39.50 felé kellene elmozdulnunk, mert az egyre jobban ajtónkon kopogtató információs társadalom csak akkor tér majd be hozzánk is, ha szabványos elérésű információkkal tudunk beleintegrálódni.
Érdemes lenne beszerezni egy szabadon letölthető Z39.50 kliens program forráskódját és vagy azt továbbfejleszteni vagy annak segítségével újat írni. Mindenképpen szükséges a szabvány letöltése és alapos tanulmányozása is.

Irodalomjegyzék
ANSI/NISO Z39.50-1995	
(A szabvány szövege Internetről letölthető a http://lcweb.loc.gov/z39.50/agency/ címről többféle formátumban)

Lorcan Dempsey, Rosemary Russell, John Kirriemuir: Towards distributed library systems: Z39.50 in a European context Program, vol. 30, no. 1, 1996. január, 1-22 o. és	
Internet dokumentum: http:// www.bib.lu.se/elbibl/litt/lorcan.hml

Lorcan Dempsey: Libraries, networks and Europe: a European networking study. Neil Smith (ed.)m London: British Library research & Development Department, 1994. (LIR Series; 101) ISBN: 0712332952	
Internet dokumentum: http://www.bib.lu.se/elbibl/litt/lorcan.html

Sebastian Hammer: Z39.50 and the World Wide Web, D-Lib Magazine, 1996 március, ISSN: 1082-9873	
Internet dokumentum: http://www.dlib.org/march/briefings/03indexdata.html/

Bernd Hergeth, Danet GmbH, Darmstadt: Z39.50 in Bibliotheken und im World-Wide-Web
Internet dokumentum: http://www.ub.uni-dortmund.de/lnetbib/v-herget.html

Hálózati értelmező szótár
Magyar Elektronikus Könyvtár (http://www.mek.iif.hu)

Finbarr Joy and Robin Murray, Fretwell-Downing Informatics Ltd.: The Worl-Wide-Web and Z39.50: which way for libraries	
Vine, 1995. június, 38-43 old.

Rosematie Russell: Z39.50 and SR: an overview	
Vine 1994. december, 97. szám 3-8. o.

Fay Turner: An overview of the Z39.50 Information Retrieval Standard 	
1996, június	
Internet dokumentum: http://www.nlc-nbc.ca/ifla/VI/5/op/udtop3.htm/

Dr. Tapolcai Ágnes: Könyvtári információk megjelenési formái az Interneten, szakdolgozat az OSZK Könyvtártudományi és módszertani Központ, könyvtár-informatika szakon, 1996	
Magyar Elektronikus Könyvtár (http://www.mek.iif.hu)