Katalógusban, illetve könyvtári rendszerben nem használható, relatíve rossz struktúrájú, vagy hiányos szerkezetű rekordok (például html oldalak, vagy a katalogizálás szabályai nem figyelembevevő adatforrások (pl.: OSZK levelestár)) kereshetővé tétele bibliográfiai rendszerekben (Z39.50 protokollon keresztül).
Előadásomban a Indexdata nevű dán cég Zebra nevű ingyenes, nyílt forráskódú Z39.50 szerverét fogom bemutatni, illetve azt, hogy hogyan egészíthetjük ki ezzel a szoftver a már meglévő integrált könyvtár-informatikai rendszerünk szolgáltatásait.
Először is tekintsük át, hogy milyen előnyökkel jár a Z39.50 protokoll használata. A mai világban az adatainkat szeretjük relációs adatbázis-kezelő rendszerekben tárolni, mert így gyorsan hozzájuk férhetünk, gyorsan és többnyire ütközésmentesen módosíthatjuk őket, illetve (viszonylag egyszerűen és viszonylag gyorsan) különféle kimutatásokat készíthetünk belőlük. A modern relációs adatbázis-kezelő rendszerekben az adatok többé-kevésbé azonos (szabványos) SQL utasításokkal is elérhetők. Mindennek ellenére a relációs adatbázis-kezelő rendszerben tárolt adatbázisok struktúrája szinte minden esetben eltérő: eltérőek a táblanevek, a táblákban szereplő oszlopok (az oszlopok nevei, az oszlopokban tárolt adatok típusai), stb. Ezért ha két különböző adatbázisból szeretnénk adatokat kinyerni, és a kinyert adatokat valahogy egységesen megjeleníteni, akkor szinte biztos, hogy két eléggé eltérő (ráadásul bonyolult adatbázisok esetén rettenetesen komplikált) SQL utasítást kell kiadni.
A Z39.50 protokoll ezen a problémán igyekszik segíteni. Egy Z39.50 szervert talán úgy lehet a legegyszerűbben elképzelni, mint egy már létező adatbázis-kezelő rendszer elé illesztett lekérdezőfelület, amely a hozzá érkező kéréseket a mögötte álló adatbázisnak és adatszerkezetnek megfelelő formátumú kéréssé alakítja, illetve az adatbázis felöl érkező válaszokat a hozzá befutott kérésnek megfelelő alakra hozva adja vissza. A protokoll használatával egységes kérést lehet intézni egy vagy több Z39.50 szerver felé, például: mutasd meg azokat a tételek "USMARC" formátumban, amelyeknél a szerző nevében szerepel az "Arany" szó és a címben szerepel a "Toldi" szó és olyan kiadványra utalnak, amely "1950" után jelent meg. Ezt a kérést elméletileg változatlan formában fel lehet tenni két teljesen különböző Z39.50 szervernek. Persze a gyakorlatban nem ilyen jó a helyzet, mert nem biztos, hogy mindegyik Z39.50 szerver támogatja a USMARC formátumot, vagy képes a megjelenési évre keresni...
Kicsit mélyebbről szemlélve a Z39.50 protokollt leíró specifikációt, észrevesszük azt, hogy például a címre keresés paraméterei egyszerű esetben egy attribútum (USE (1) attribútum) értékének egy meghatározott számértékre (4) történő állításából és a keresendő szó vagy kifejezés megadásából áll:
find @attr1=4 "Toldi"
Ugyan létezik szabványos, előre definiált keresőkifejezés készletet (előre definiált USE attribútumok) a bibliográfiai rendszerekben történő keresésekhez (pl.: BIB-1), de ez nem követeli meg saját maga teljes felhasználását, sőt lehetőséget biztosít a bővítésre, illetve végső soron az egész ajánlást ki lehet váltani egy alapjaiban más rendszerrel, hiszen a Z39.50 protokollt nem csak a könyvtárak használják. Például mondom azt, hogy az én rendszeremben a címre keresést a 82-es USE attribútum megadásával lehet kezdeményezni. Bár ezzel eltérek a BIB-1 ajánlástól, a Z39.50 specifikáció keretein belül maradok, azaz a adatbázisomat cím alapján bárki le tudja kérdezni, feltéve ha tudja, hogy a címre kereséskor a 4-es USE attribútum helyett a 82-est kell használnia:
find @attr1=82 "Toldi"
Láthatjuk tehát, hogy a Z39.50 protokoll használata sem éppen problémamentes. Mégis a modern könyvtár-informatikai rendszerek (Aleph, Amicus, Corvina, Olib, Voyager, stb.) egytől-egyig támogatják ezt a protokollt, azaz ezen a protokollon keresztül (megfelelő beállítások mellett) le tudják kérdezni egymás adatbázisait, illetve bármilyen más adatbázist, amelynek az adatai Z39.50 protokollon keresztül elérhetőek. Ilyenek például a Zebrával létrehozott adatbázisok.
A Zebra szöveges adatforrások (például: normál szöveg, címkékkel ellátott szöveg, marc fájl, xml/sgml fájl, stb.) indexelésére, és Z39.50 protokollon történő keresésére és megjelenítésére (marc, xml, sutrs, stb. formátumban) használható, eléggé jó stabilitással és sebességgel. Ebből következően kiválóan alkalmas arra, hogy segítségével a már meglévő Z39.50 protokollt támogató könyvtár-informatikai rendszerünkhöz új adatforrásokat kapcsoljunk.
Mit érdemes Zebrával szolgáltatni?
Ha már van egy könyvtár-informatikai rendszerünk, akkor a Zebrával szerintem csak olyan adatbázisokat érdemes szolgáltatni, amelyeknek a tartalma nem megfelelő ahhoz, hogy a meglévő könyvtár-informatikai rendszerbe kerüljön, vagy pedig a meglévő rendszerbe történő rögzítés túlságosan költséges lenne.
Az OSZK-ban egyelőre a következő anyagokat dolgozzuk fel Zebrával:
- Az egyik "partnercégünk" által Folio View-ban rögzített (antik) anyagokat. Ezek xml szerű anyagok, de borzasztó rosszul strukturáltak, és könyvtáros nézőpontból borzasztó gyenge minőségűek.
- A MEK webről elérhető (html formátumú, folyamatosan bővülő) állományjegyzékét.
- A saját honlapjainkat.
Bár a Zebra sok lehetőséget kínál fel a források értelmezésére, nekem kedvelt módszerem, hogy ha szükséges egy-egy perl script segítségével értelmezem a forrásfájlokat, módosítom az adatokat és a végeredményt egy sgml szerű fájlba írom. A folyamat végeztével a Zebra az újonnan keletkezett sgml fájlt fogja leindexelni, illetve az abban szereplő adatokat fogja visszaadni. Az sgml formátum talán a legalkalmasabb arra, hogy mind a Zebra, mind pedig a Zebra működését felügyelő ember a legtöbbet hozza ki az adatokból.
Véleményem szerint a Zebrával kapcsolatos rendszergazdai tevékenységeink közül a legfontosabb és legbonyolultabb az egyes adatbázisok indexeléshez és szolgáltatáshoz történő bekonfigurálása. A folyamat azért bonyolult, mert még minimális igények esetén is legalább 3-4 konfigurációs fájl tartalmát ajánlott átnézni, illetve módosítani, míg bonyolultabb esetekben a konfigurációs fájlok száma könnyen 6 fölé szaladhat, sőt előfordulhat, hogy ezek közül jó néhányat nekünk kell létrehozni. Természetesen a "konfigurációs fájlok" egymásra épülnek, így az sem mindig triviális, hogy milyen sorrendbe nézzük át őket. Én a következőt javasolnám:
Egyből fölvetődik a kérdés, hogy mik azok a TESZT*.* fájlok, és miért éppen a TESZT szóval kezdődik a nevük. A válasz a Zebra sajátos viselkedésében található: sgml fájlok indexelésekor úgy jár el, hogy a legfelsőbb szintű tag nevével megegyező nevű ".abs" kiterjesztésű konfigurációs fájlban keresi az indexelés paramétereit, illetve az indexeléshez és a szever funkciók működéséhez szükséges konfigurációs fájlok neveit, ezért az indexelendő adatbázisunknak mondjuk így kellene, kinéznie:
<TESZT> <SZERZO>
<VEZETEKNEV>Andrási</VEZETEKNEV>
<KERESZTNEV>Áron</KERESZTNEV> </SZERZO> <CIM>Z39.50 használati útmutató</CIM> <URL>http://www.oszk.hu/1.html</URL> </TESZT>
<TESZT> <SZERZO>
<VEZETEKNEV>Palyik</VEZETEKNEV>
<KERESZTNEV>Katalin</KERESZTNEV> </SZERZO> <CIM>Amicus rendszeradminisztrátori
kézikönyv</CIM> <URL>http://www.oszk.hu/2.html</URL> </TESZT>
Elvileg elég lenne, ha csak az ".abs" kiterjesztésű fájlunk neve egyezne meg az sgml "adatbázisunk" legfelső elemének nevével, azonban ha több adatbázist akarunk beindexelni, és mindegyikhez egyedi konfigurációs fájlok tartoznak, akkor célszerű az összetartozó fájloknak hasonló (egységes) nevet adni.
profilePath:
[konfigurációs_(tab)_fájlok_elérési_útjai]
attset:
bib1.att attset:
explain.att
recordType:
gsr.sgml
lockDir:
lock setTmpDir:
tmp keyTmpDir:
tmp
# ... [egyéb beállítások például a
memóriakezelésre vonatkozóan]
A zebra.cfg fájlban állíthatjuk be, hogy a Zebra mely könyvtárakba keresse az indexeléshez, és a rekord szolgáltatáshoz szükséges konfigurációs fájlokat, illetve hogy az ezen folyatok által ideiglenesen létrehozott fájlok mely könyvtárakba kerüljenek. Itt rendelkezhetünk a memóriahasználatról is.
type 4
# tag [sorszám]
[sgml_tagnév] [típus]
tag
1 SZERZO structured tag
2 VEZETEKNEV string tag
3 KERESZTNEV string tag
4 CIM string tag
5 URL string
Ahhoz, hogy az indexelendő fájlunkban lévő adatokat értelmezni tudjuk, egyedi azonosítókkal kell ellátnunk a benne szereplő (számunkra fontos) adattagokat (xml tag-et), illetve meg kell határoznunk a típusukat is. Ezt végezhetjük el a TESZT.tag fájlban.
Az egyedi azonosítók (amelyeket később a TESZT.abs fájlban használunk fel) két részből állnak:
Vagyis a <SZERZO> tag által jelölt adatra a TESZT.abs fájlban (4,1)-ként fogunk hivatkozni, míg a <SZERZO><VEZETEKNEV> tag által jelőlt adatra (4,1)/(4,2)-ként
reference GILS-schema attset TESZT.att tagset TESZT.tag
maptab TESZT-usmarc.map
esetname B @ esetname F @
all any
# elm ([type],[sorszám]) [zebra_elnevezés] [index_neve:index_típusa]
elm
(4,1) szerzo - elm
(4,1)/(4,2) vezeteknev nev:w elm
(4,1)/(4,3) keresztnev nev:w elm
(4,4) cim !:w,!:p elm
(4,5) url -
Az indexelés "mikéntjét" a TESZT.abs fájlban határozhatjuk meg. A TESZT.tag fájlban megadott azonosítók felhasználásával megmondhatjuk, hogy az egyes adatokat hogyan indexelje a rendszer (szavanként és/vagy kifejezésenként, stb.), az indexekhez neveket rendelhetünk, amelyek alapján a TESZT.att fájlban hivatkozhatunk rájuk (ott definiáljuk, hogy egy meghatározott Z39.50 use attribútum beérkezésekor milyen indexben keressen a Zebra). Ha két adattaghoz ugyanazt az indexnevet rendeljük, akkor a Zebra ennek megfelelően mindkét adattag tartalmát beteszi egy közös indexbe. Arra is lehetőségünk van, hogy egy adattag tartalmát egyszerre több indexben is szerepeltessük.
A fent említett indexelési lehetőségen kívül itt adhatjuk meg azt az azonosító nevet (a fent látható mintában [zebra_elnevezés] ennek az oszlopnak a neve), amely alapján az adattagot a megjelenítéskor használt *.map fájlban (jelen példában a TESZT-usmarc.map fájlban) azonosíthatjuk.
Ebben a fájlban határozzuk meg az indexeléshez, illetve a rekord szolgáltatáshoz szükséges többi konfigurációs fájl nevét is.
Az "all any" direktíva megadásával "létrejön" egy "any" nevű index, amely tartalmazza az összes általunk definiált indexet. Példánkban ha az any indexben keresnénk akkor az azt jelentené, hogy egyszerre keresünk a vezetéknevek, keresztnevek, és címek között.
Az 'esetname' kulcsszó segítségével rendelkezhetünk arról, hogy a rövid (Brief) és teljes (Full) megjelenítéskor mely adattagokat küldje vissza a szerver. A @ paraméter megadásával minden adattag szerepelni fog a szerver által küldött válaszban, míg a @ helyére egy fájlnevet írva a csak fájlnév által jelölt fájlban szereplő 'simpleelement' tagok paraméterei (melyek nagyjából megegyeznek az 'elm' tagok paramétereivel (azaz a TESZT.tag fájlban megadott azonosítók sorozatából áll)) szerepelnek a válaszban. Például nézzük meg egy lehetséges TESZT-b.est fájl tartalmát:
simpleelement (4,1)/(4,2) simpleelement (4,1)/(4,3) simpleelement (4,4)
reference Bib-1
# att
[Z39.50_use_attribútum]
[index_neve]
att 1003 nev
att 4 cim
att 1016 any
A TESZT.att fájlban adjuk meg, hogy a TESZT.abs fájlban meghatározott indexek milyen Z39.50 use attribútumon keresztül legyenek elérhetőek. A fent látható példában ha "név"-re szeretnénk keresni, akkor a 1003-as use attribútumot (és persze egy nevet) kellene megadni a keresőkérdésben. Pl.:
find @attr1=1003 "Arany"
Azt hiszem fontos megjegyezni, hogy a TESZT.att fájlban szerepelnie kell az összes TESZT.abs fájlban létrehozott indexnek, egyébként hibaüzenetet kapunk.
targetname usmarc targetref
usmarc
# map
[elnevezés] [MARC_kód]
map vezeteknev /(3,100)/(3,a)
map keresztnev /(3,100)/(3,b)
map cim /(3,245)/(3,a)
map url /(3,856)/(3,u)
A TESZT-usmarc.map fájl nevéből következően ahhoz nyújt segítséget, hogy a felhasználó által kért rekordot a Zebra marc (usmarc) formátumban küldhesse vissza. Tapasztalatom szerint a Zebrán belül igazából semmi nem ellenőrzi, hogy az itt megadott beállítások megfelelnek a usmarc előírásainak, vagy sem, így akár hunmarc formátumot, vagy bármi mást is be lehet állítani usmarc címén.
Erre esetleg szükség is lehet erre, ugyanis a targetname, illetve targetref direktívák hunmarc-ra állításától a Zebrának elvileg támogatnia kellene a hunmarc formátumot, ám próbálkozásaim során arra a következtetésre jutottam, hogy míg danmarc és usmarc beállításokkal jól működik a rendszer, addig a hunmarc formátumot ismeretlennek tekinti.
Igen érdekes, és kissé ködös az a mód, ahogy ebben a konfigurációs fájlban a TESZT.abs fájlban megadott és általam [zebra_elnevezés] néven jelölt adattag azonosítóhoz (a TESZT-usmarc.map fájlban [elnevezes]-ként szerepel) hozzárendeljük a marc hívójelen és az almezőkódot. Példánkban a "vezeteknev"-vel jelzett adathoz a "100"-as marc hívójel "a" almezőkódját rendeljük (vagy ha úgy jobban tetszik a 100 $a marc kódot). Arra a kérdésre, hogy ezt miért /(3,MARC_HÍVÓJEL)/(3,ALMEZŐ_KÓD) ( példánkban /(3,100)/(3,a) ) formában kell megadni, nem tudom a választ. Nem tudom mit jelent a 3-as, és miért kell odatenni, ahol van, de eddigi tapasztalataim alapján a Zebrában mindennek megvan az értelme, úgyhogy valószínűleg ennek is (csak egyelőre nincs benne a dokumentációban, vagy nagyon nehéz kihámozni belőle).
lowercase {0-9}{a-z} uppercase {0-9}{A-Z}
space
{\001-\040}!"#$%&'\()*+,-./:;<=>?@\[\\]^_`\{|}~
# map (mit)
mire
map
(á) a map
(é) e map
(í) i map
(ó) o map
(ö) o map
(ő) o map
(ú) u map
(ü) u map
(ű) u
map
(Á) A ...
Mivel a Zebra nyugat Európai szoftver, joggal feltételezhetjük, hogy alapesetben nem kezeli helyesen a magyar karaktereket (például nem tudja a magyar abc szabályai szerint rendezni a szavakat, mert nem ismeri mondjuk a "ő" vagy az "ű" betűket). Mivel ez a feltételezés helytálló, valahogy meg kell mondanunk a Zebrának, hogy mit kezdjen a magyar abc betűivel. Erre a célra szolgál a string.chr fájl.
A lowercase és uppercase kulcsszavak után fel kell sorolni az indexelendő rekordokban (esetleg) előforduló karaktereket olyan sorrendben, ahogyan az egyes karaktereket rendezni szeretnénk.
Az ékezetes karaktereket a könyvtári gyakorlatban az ékezet nélküli megfelelőjükkel egyenrangúként kezeljük. Például az azték és az Ábel "könyvtári" sorrendje:
Ábel
azték
Ezért ezt az egyelőséget definiálnunk kell, amire nagyon alkalmas a map kulcsszó. Arra azért ügyelni kell, hogy a map-elni kívánt betű, (a példában: mit oszlop elemei) ne szerepeljen a lowercase és uppercase listában, de az a betű amelyre map-pelni szeretnénk (a fenti példában mire oszlop elemei) feltétlenül szerepeljen ott.
A fenti map-pelésnek az lesz a mellékhatása, hogy ékezetesen és ékezet nélkül is tudunk keresni, illetve böngészni, de böngészéskor csak ékezet nélküli alakban jelennek meg a szavak.
# zebraind -d [adatbázis_neve] update [indexelendő_fájlok_helye]
zebraidx -d TESZT update records
Ha a előzőekben megemlített konfigurációs fájlokat beállítottuk, akkor elindíthatjuk az indexelés. Az indexelő programnak megadható paraméterek közül a két legfontosabb talán az, hogy mit indexeljen, és hogy milyen "logikai adatbázisnéven" legyen elérhető az így keletkezett index.
# zebrasrv -l [log_fájl_neve] tcp:[ip]:[port]
zebrasrv -l log/index.log tcp:@:9999
Az indexelés befejeződése után el lehet indítani a Zebra szervert. Az indító parancsban célszerű megadni, hogy milyen ip címen és milyen porton legyen elérhető a szerver. Emellett a szerver által készített log-ot is célszerű valamilyen fájlba írni.
Persze nem csak egy Z39.50 szerver áll ingyenesen a rendelkezésünkre, hanem kliensek, és kliens készítő eszközök egész sora. Az Indexdata például a következő jelentősebb eszközöket kínálja:
A Z39.50 protokoll fejlődése szerencsére nem állt meg. A Library of Congress vezetésével kidolgozásra került a Z39.50 szabvány legújabb változata (Z39.50 Initiative Next Generation röviden ZING), amely a mai informatikai trendnek megfelelően webszolgáltatásként képzeli el a Z39.50 kliens-szerver funkciókat, és ennek megfelelően olyan új eszközökkel és fogalmakkal (mint például XML, SOAP, WSDL) gazdagítja a Z39.50 protokoll eszköz- és fogalomkörét. Már meg is jelentek az első Jáva és egyéb nyelveken készült implementációk, melyek közvetve elérhetők a Library of Congress weboldaláról.
http://www.loc.gov/z3950/agency/document.html
http://www.indexdata.com/
http://www.crxnet.com/icone.php
http://www.endnote.com
http://www.loc.gov/z3950/agency/zing/
http://www.oszk.hu/zing/
http://solanum.oszk.hu/~aa/zebra/