HUNMARC rekordok előállításának tartalmi nehézségei Az előadás címe talán kissé sematikusnak, perifériálisnak tűnik, amíg át nem gondoljuk, hogy hányféle okból is merülhet fel HUNMARC formátumú rekordok előállításának igénye: §
Könyvtári együttműködések. A múltban sok olyan kezdeményezés volt, mely azonos könyvtári rendszert használó könyvtárak közötti együttműködést szorgalmazott. Ez esetben az adatcsere formátuma lehetett akár a könyvtári rendszer sajátos outputja is, amennyiben az adott rendszer erre a rekordcserére fel volt készítve. Az effajta együttműködések azonban napjainkban háttérbe szorulóban vannak a nagyobb szakmai, illetve ágazati együttműködésekhez képest. Az újabb együttműködésekben (pl.: MOKKA) való részvétel feltétele a HUNMARC /USMARC rekordszolgáltatási ill. fogadási képesség.
§
Teljes adatkonverzió. HUNMARC rekordok csereformátumként történő alkalmazása a napjainkban folyó könyvtári „rendszerváltások”1 lebonyolítása során is kézenfekvő. Az integrált könyvtári rendszerek első generációját felváltó korszerűbb rendszerek szinte kivétel nélkül MARC alapokon szerveződő rendszerek, melyek részéről a HUNMARC / USMARC rekordok fogadása alapszolgáltatás. Az új rendszerre való áttérés egyik sarkalatos pontja tehát a leváltandó rendszer adatainak HUNMARC formában történő kinyerése.
§
WEB-es OPAC szolgáltatása. Ma már a hagyományos alapokon álló rendszerek (TINLIB, TEXTLIB, SZIRÉN, stb.) OPAC felülete is elérhető WEB böngészővel, ahová elegánsan ki szoktak tenni egy „HUNMARC letöltés” gombot. A megjelenítés mögött álló adatbázis azonban valójában nincsen felkészítve a MARC struktúrára, a böngésző a hagyományos struktúrának megfelelően képes megjeleníti az adatokat. Letöltést választva nem állít elő valódi MARC rekordot, hanem bináris formátumra hozza a képernyőn megjelenített adatokat. Ekkor tehát nem történik meg sem a kötelező adatok létrehozása, sem a problémásabb adatok kezelése.
Egy HUNMARC rekord előállítása a sajátságos bináris formátumot tekintve lényegében programozói feladat. Jól lehet a bináris MARC leképezése elméletben nem okoz gondot, a gyakorlatban ez sem mindig egyszerű, hiszen a MARC struktúrából adódóan a headerben kell tárolni a rekord hosszát és az egyes mezők kezdő pozícióját, hosszát. Látszólag jó MARC rekordok bizonyulnak nem egyszer fogyaszthatatlannak akár a rekordban maradt speciális karakterek (CR LF) miatt, akár a header hibás értékeiből adódóan. Előadásomban a MARC rekordok előállításának szemantikai, tartalmi problémájára szeretném a hangsúlyt fektetni. A felmerülő tartalmi nehézségek illusztrációját elsősorban a TINLIB-HUNTÉKA konverziók, illetve a MOKKÁ-hoz csatlakozó TINLIB-es könyvtárak exportjánál felmerült problémák szolgáltatták, de a vázolt problémák tapasztalataim szerint más rendszerekből származó (ISIS, TEXTÁR, SZIRÉN, SRLIB, DRLIB) (HUN)MARC rekordokra is általánosíthatóak. (A WEB-es OPAC-ok által szolgáltatott HUMNARC rekordok elemzésére - a felsorolásban említett szempont miatt - nem kívánok kitérni.) A problémát elsősorban az okozza tehát, hogy a „hagyományos” rendszerekben az adatok feltárása nem MARC alapú volt, így lehetett az bármilyen részletes, a HUNMARC /USMARC output előállításakor olyan adatelemeket kell generálni, melyek a feltáráskor nem készültek el, illetve más mezőkbe ágyazva voltak találhatók. Kötelező adatok létrehozása A HUNMARC szabvány szerint minden bibliográfiai rekordban kötelezően szerepelnie kell az alábbi adatelemeknek: §
rekordfej
§
001 rekordazonosító
§
005 a rekorddal végzett utolsó művelet dátuma
§
008 jellemzők és információs adatok
§
040 a leírás forrása
Ezek az adatok rendszerint nem jönnek létre a hagyományos rendszerekben való katalogizáláskor, azonban HUNMARC rekord szolgáltatásakor a fogadó rendszer elvárhatja ezek meglétét, ellenkező esetben rekordjainkat hibás rekordként fogja kezelni. 1
Lengyel Monika – Simon András: Rendszerváltás a hazai könyvtárakban – divathullám vagy kényszer? Pécs, 2003. ápr. 6-8.
1
A rekordfej előállításának nagyobb része kifejezetten programozás technikai feladat – tartalmi szempontból annak 05- 07 pozíciója érdekes. Ha MARC alapokon katalogizálunk, akkor ezek az értékek számos szoftver esetében (QTÉKA, HUNTÉKA) már lényegében a feldolgozandó dokumentumtípust jellemző beviteli űrlap kiválasztásakor beállítódnak. A 05. pozíció értékének létrehozásához csak ellenőriznünk kell, hogy a szolgáltató rendszerben milyen dátummal rendelkezik a rekord (katalogizálási/ módosítási). Izgalmasabb kérdés a 06-07. pozíciók értékének előállítása. A dokumentum jellegére vonatkozó információkat a hagyományos rendszerekben kereshetjük az információhordozók, kiadványtípusok, valamint a tárgyszavak között. Jó esetben az itt szereplő kifejezések ellenőrzötten kerültek bevitelre. Ezt kell a HUNMARC-ban meghatározott egy karakteres értékre lecserélni. A bibliográfiai szint előállításához elegendő figyelembe venni, milyen állományból származik a rekord, mivel a legtöbb hagyományos rendszer (pl.: TINLIB, TEXTÁR, ISIS, SZIRÉN) külön állományokban tárolta az egyes dokumentumtípusoknak (folyóiratok, cikkek, könyvek stb.) is megfeleltethető információt. A megfelelő értéket beállítva állományonként külön-külön outputot kell létrehozni. Ellenkező esetben viszont (pl SrLIB) a dokumentum jellegéhez hasonlóan ezt is a kiadványtípusa, vagy tárgyszó mezőkből kell ki mazsolázgatni. A 001 adatelem létrehozása kötelezősége ellenére csekély gyakorlati jelentőséggel bír, hiszen a legtöbb rendszerbe való betöltődéskor tartalma felül íródik a fogadó rendszer által kiosztott rekordazonosítóval. A 005 előállításának szükségessége is kérdéses, hiszen az export során nyilvánvalóan megegyezik az exportálás időpontjával, de a betöltéskor ez már a betöltés időpontját kell jelölnie. Ide kapcsolódik még a – nem kötelező – 035-ös adatelem is, melyre a rekordkapcsolatoknál fogok kitérni. A 040 adatelem előállítása nem jelent különösebb problémát, hiszen minden rekordba ugyanazt a jelsorozatot (az előállító könyvtár kódját és a leírás nyelvét) kell generálni. Az előzőeknél lényegesen sokrétűbb azonban a 008-as adatelem tartalma. A szabvány rendelkezése szerint itt valamennyi karakterpozíció értékének kitöltése kötelező, meghatározhatatlansága esetén a térköz illetve „egyéb” megjelölésnek megfelelő standard érték is meg engedett. A 008-as adatelemet a rekordfejhez hasonlóan a fogadó rendszerek szemszögéből kell tartalmaznia a rekordnak, mert a legtöbb rendszer szintaktikai ellenőrzéssel szűri a hibás rekordokat, s ennek kötelező hossza és egyes tartalmi elemeinek megléte/ hiánya kézenfekvő szűrési kritériumot nyújthat. Teljes konverzió esetében igen fontos a 008. adatelem 00-05 pozíciója. Ha ezt nem hozzuk létre, akkor például egy konvertált állományban a konverziót követő időszakban nehézséget fog okozni egyes kimutatások, statisztikák elkészítése. (A legtöbb rendszer ezt az import időpontjával tölti fel automatikusan, ami azonban erősen félrevezető lehet.) Vannak olyan elvetemült rendszerek (pl.: KISTÉKA), melyek a kiadás évét a 008. adatelem 07-10. pozíciójából tárolják le. Ezzel a fogadó rendszer részéről felesleges ellenőrzés és programozói munka spórolható meg, hiszen a 260$c-ben az év többféleképpen is szerepelhet (pl.: cop. 1968; [1978]), míg a 008-ból „konyhakész” állapotban is kinyerhető. Szép és jó, ha az országkódot és az első nyelvkódot is prezentálni tudjuk, bár ezeknek a 008-ban inkább csak „díszítő” funkciójuk van. Igazi helyük a 041 és 044-es mezőkben lenne, a fogadó rendszerek többsége is innen tárolja. A kiadó ország kódját a hagyományos struktúrában katalogizálók ritkán szokták megjelölni, inkább csak időszaki kiadványoknál, cikkeknél fordul elő. (Megfelelő mező hiányában ilyenkor is gyakran kerül a kiadás helyének tárolására szolgáló mezőbe, ahonnan meglehetősen nehéz kiemelni). Tapasztalatom szerint a nyelv megjelölése mindenki számára kézenfekvő, amennyiben nem magyar nyelvű dokumentumról van szó. A nyelv megjelölésének hiányában némi informálódást követően a rekordot el lehet látni a „hun” kóddal – hiszen ha valaki csak magyar nyelven olvas, akkor egy keresés során az összes lehetséges nyelvre kellene negálnia a keresését. Az ország illetve nyelv megjelölése a hagyományos rendszerekben csak a legritkább esetben szokás a szabványos kódokkal, vagyis nagy valószínűséggel a kódokat az export során kell előállítani a természetes nyelvi kifejezésekből. A dokumentum típusokra jellemző 008-as értékek beállításának kötelezettsége lényegében elhagyható, azonban nem árt tájékozódni a fogadó rendszer import tulajdonságairól, mert elképzelhető, hogy ezeket a pozíciókat is figyeli. A HUNTÉKA MARC importja például tárolja és visszaadja a 008 adatelem 24-27 (tartalmi jellemzők) valamint a 33. (műfaj) pozíciók értékeit. Ezek előállítása meglehetősen nehézkes, kiadványtípus, tárgyszó, műfaj és hasonló mezők tartalmának figyelésével lehetséges. Erre leginkább csak konverzió során, leendő katalógusunk homogenitása miatt lehet szükség.
2
Problémás adatmezők Szerzőségi főtétel (1xx-7xx) Tapasztalataim szerint az adatmezők közül a legtöbb gondot a HUNMARC-ban szereplő 1xx, valamint 7xx mezők előállítása okozza. Egy konverzió vagy letöltés során sokszor már annak eldöntése is nehéz, hogy az adott rekord rendelkezik-e szerzői főtétellel. Ez egy meglehetősen bonyolult algoritmussal történik, hiszen négy szerző megléte, vagy közreműködési jelleggel bíró személyek esetén nem kerülhet adat a 100-as mezőbe, és csak ezt követően vehetjük vizsgálat alá a rekordban szereplő esetleges testületeket vagy rendezvényneveket. Mindez azonban aránylag jól algoritmizálható. Komoly problémát okoz azonban, hogy a nem MARC alapon szerveződő rendszerek általában nem rendelkeznek külön a testületi nevek számára fenntartott mezővel, így azok a szerzőkkel vagy egyes esetekben a kiadói nevekkel keverednek. A bibliográfiai rekord létrehozásakor elsősorban a személyi és testületi nevek szétválogatása szükséges. Ez testületi szerzőkre jellemző jelsorozatok szűrésével történhet (pl.: ’Intézet’, ’Magyarország’, ’közread’, stb.) Ilyen esetekben mindig tanulmányozni kell az exportálandó adatokat. A testületi szerzők és rendezvénynevek $c, $d, $n almezői csak nagyon következetesen katalogizált állományból válogathatók le. Konferencia : Magyar Ökológus Kongresszus (1.) (1988) (Budapest) 711 $aMagyar Ökológus Kongresszus$n1.$d1988$cBudapest Testület: Államigazgatási Főiskola (Budapest) (közr.) 710 $aÁllamigazgatási Főiskola$cBudapes$4közr. Természetesen az ilyen jellegű szétválogatásoknál el kell fogadni egy bizonyos hibaszázalékot, s nem egyszer keletkeznek hibás adatok: 100 $aAligai$jhegyközség 700 $aSzáztagú$jCigányzenekar Külön problémát okoz a személynevek kettéválasztásának kötelezettsége. Általános szabályként elfogadható a név két tagja közötti vessző+szóköz vagy szóköz delimiter, azonban mint mindenütt itt is vannak kivételek, melyek a fenti algoritmus szerint hibásak lesznek: 100 $aABDEL$jAZIZ Ali ELSAYED GHABN 100 $Ácsné$jMolnár Judit 100 $aAlföldi$jFlatt Károly A fenti esetekben külön bonyodalmat okoz a szabvány szerinti indikátorok előállítása. Megjelenési adatok (260) Látszólag problémamentes adatmező. Jó példa azonban arra, hogyan tud fejtörést okozni a hagyományos rendszerek korlátozottsága és ezzel egyidejű szabadossága. Sok könyvtár küzd a kolligátumok feltárásának problémájával. A kolligátumok feltárása bonyolult, több lépcsős leírást igényel. Ahol erre nem volt mód, egy kolligátum egy rekordban került leírásra. Ebben az esetben egy rekordon belül több megjelenési év is van, azonban sem a 260-as adatmező, sem pedig annak $c almezője nem ismételhető. Hová kerüljenek hát az összekötött dokumentumok eltérő kiadási évei? Megjegyzések (500 – 504 – 541 – 599 – 520) A HUNMARC szabvány számos megjegyzés mezőt kínál, míg a hagyományos rendszerekben legfeljebb egy – két megjegyzés mező állt rendelkezésünkre. HUNMARC output előállításakor felmerülhet tehát a megjegyzések tartalmi szétválogatásának igénye is. Tapasztalataim szerint a hagyományos rendszerekben általánosítható megjegyzés tartalmak típusai alapján a bekezdés elején jelzett MARC mezők a „legnépszerűbbek”. Az általános megjegyzések közül jelsorozatra való szűréssel válogathatók le a bibliográfiára (504), valamint a beszerzés módjára (541) utaló tartalmak. Kapcsolódó rekordok szolgáltatása Általános konverziónál és együttműködésekbe történő rekord szolgáltatáskor egyaránt fontos a kapcsolódó rekordok együtt tartása és együttes megjelenítése. Ez kétféle kapcsolatot jelenthet: •
két bibliográfiai rekord közötti kapcsolat (pl.: sorozat – sorozat tagja; folyóirat – folyóirat előzménye; cikk – forrásdokumentum, stb.)
3
•
besorolási rekord – bibliográfiai rekord közötti kapcsolat (szerzői besorolási rekord – bibliográfiai rekord)
A bibliográfiai rekordok közötti kapcsolódást a HUNMARC szabvány széleskörűen szabályozza. Általánosságban elmondható, hogy a $w almezőnek kell tartalmaznia a kapcsolódó rekord rekordazonosítóját, azaz annak 001-es adatmezőjére mutat. Ennek leképezése akkor okoz problémát, ha a szolgáltató rendszer nem tartalmazott numerikus rekordazonosítót, mint például a TINLIB. Ez esetben az exportot megelőzően szükségszerű minden egyes rekordhoz utólagosan egy azonosító számot generálni, mert természetes nyelvi kifejezések (cím) alapján történő rekordkapcsolat kiépítése rendkívül bizonytalan. A korábban jelentéktelennek minősítet 001-es adatmező létrehozása a rekordkapcsolatok felépítésekor bír jelentősséggel. Minthogy a 001-es adatmező tartalma rekord import során rendszerint felülíródik a fogadó rendszer belső azonosítójával, egy sajátos gyakorlatias logika alapján azt is mondhatjuk, hogy a hozott rekordazonosító közvetlenül kerüljön be a 035-ös adatmezőbe, betöltésnél pedig a $w-ből kiindulva a 035-ös tartalma alapján találja majd meg a kapcsolódó rekordot, és írja felül a $w almező tartalmát annak 001-értékével. Ezzel a kapcsolat kiépülése egy lépéssel lerövidül. Amennyiben a szolgáltató rendszer kidolgozott szerzői besorolási rekordokkal is rendelkezett, a besorolási rekordok exportjára is szükség van. Ekkor azonban azonos nevű szerzők megléte esetén már kétséges a besorolási rekordok és bibliográfiai rekordok közötti korrekt kapcsolatok kiépülése. Mivel már a hagyományos rendszerek többségére is elmondható, hogy relációs adatmodellre épültek, a művek – szerzők N:N kapcsolatának feloldását kereszttáblán keresztül biztosították. Ebben csak a bibliográfiai és szerzői rekordazonosítók szerepelnek, viszont egy teljes export során ez az információ a HUNMARC szabvány olvasatában elvész. Ha például a szerzői besorolási rekord nem a 100-as mezőben tartalmazta a megkülönböztető információt ($c egyéb kiegészítő, $d születési év), hanem a bibliográfiai rekordban szereplő szerzőnél leképezhetetlen besorolási megjegyzések között (pl.: 678, 680), akkor a megkülönböztetés elveszik, az azonos nevű szerzők rekordjai összekeverednek, a bibliográfiai rekordok „rossz” szerzőhöz rendelődnek. A meglévő precíz kapcsolatok az áttöltést követően is megőrizhetőek, ha a MARC szabványtól kissé eltérve bevezetünk egy ideiglenes technikai jellegű almezőt, mely a szerzői rekord meglévő rendszerünkben birtokolt rekordazonosító számára utal. Besorlási rekordban: 001 $a134502 100 $aTóth$jÁrpád 678 $aköltő bibliográfiai rekordban: 700 $aTóth$jÁrpád$3134502 XML formátumú HUNMARC rekordok A HUNMARC rekordok előállítását megnehezítő tartalmi problémák megoldásának egyik hátráltató tényezője éppen a MARC rekordok bináris struktúrájában rejlik. A rekordok áttekintése és az adatok ellenőrzése igazán csak a betöltést követően végezhető el, ami nem egyszer jelentősen lassítja mind az együttműködések megvalósulását (pl.: MOKKA), mind pedig a „rendszert váltó” könyvtárak áttérését. A kinyert output állomány rekordjai lényegében nem javíthatóak, bármiféle hiba kiküszöbölése csak az egész állomány újbóli exportálásával történhet. A struktúrából adódóan nemcsak maga az adat, hanem a szerkezet is generálhat hibás adatokat, így a hibakeresés is mellékvágányra futhat. Nagy állományok esetében ez természetesen jelentős időt vehet igénybe. A fentiek tanulságait figyelembe véve a TINLIB-ről HUNTÉKÁ-ra áttérő könyvtárak konverzióját a Library of Congress által kifejlesztett XML alapú MARC rekordokra építettük. A Library of Congress az Internet kiterjedésével, valamint a feldolgozandó dokumentumok körének bővülésével 1995-1997 között dolgozta ki a bináris MARC rekordok XML környezetben való SGML (=Standard Generalized Markup Language) reprezentációját2. Az XML formátumú MARC rekordok egy az egyben a MARC rekordok szemantikáján alapulnak, annak esszenciális adatai az alábbihoz hasonló XML struktúrába konvertálva jelennek meg:
2
Az XML formátumú MARC rekordok részletes specifikációja, valamint az átalakításhoz szükséges szabadon letölthető eszköz az Library of Congress oldalán a http://www.loc.gov/marc/marcxml.html címen találhatók.
4
01142cam 2200301 a 4500 92005291 DLC 19930521155141.9 920219s1993 caua j 000 0 eng <subfield code="a">0152038655 : <subfield code="c">$15.95 <subfield code="a">DLC <subfield code="c">DLC <subfield code="d">DLC <subfield code="a">Sandburg, Carl, <subfield code="d">1878-1967. <subfield code="a">Arithmetic / <subfield code="c"> Carl Sandburg ; illustrated as an anamorphic adventure by Ted Rand. <subfield code="a">1st ed. <subfield code="a">San Diego : <subfield code="b">Harcourt Brace Jovanovich, <subfield code="c">c1993. <subfield code="a">1 v. (unpaged) : <subfield code="b">ill. (some col.) ; <subfield code="c">26 cm. <subfield code="a">One Mylar sheet included in pocket. <subfield code="a">Arithmetic <subfield code="x">Juvenile poetry. <subfield code="a">Children's poetry, American. <subfield code="a">Arithmetic <subfield code="x">Poetry. <subfield code="a">American poetry. <subfield code="a">Visual perception. <subfield code="a">Rand, Ted, <subfield code="e">ill.
5
A projekt eredményeképpen létrehozták a két formátum közötti átjárhatóságot biztosító eszközt is, mely lényegi adatvesztés nélkül képes elvégezni az átalakítást. Értelemszerűen egy XML struktúrában a MARC strukturális elemei feleslegesek, így a MARC-SGML átalakításkor ezek (az egyes mezők hossza és kezdő pozíciója, rekord hossza) eldobásra kerülnek. A TINLIB-HUNTÉKA konverzió során ennek egy egyszerűsített, ugyanakkor a rekordkapcsolatoknál elmondottakat figyelembe véve mégis kibővített változata került kidolgozásra. Az indikátorok a HUNTÉKA eltérő filozófiájának következtében feleslegessé váltak, viszont bevezetésre került a bibliográfiai és besorolási rekordok közötti kapcsolat kiépülését szolgáló technikai jellegű „3”-as almező:
00000cam 2200000 5p 4500 n hu u j hun 1 <subfield code="a">Állattenyésztési biotechnológia. Kerekasztal-konferencia <subfield code="n">2. <subfield code="d">1986 <subfield code="c">Szerencs <subfield code="3">712 <subfield code="c">30, -Ft <subfield code="j">fűzött <subfield code="a">59529 <subfield code="a">GATE <subfield code="b">hun <subfield code="d">GATE <subfield code="a">hun <subfield code="a">hu <subfield code="a">636 <subfield code="a">136.246 <subfield code="a">2. Kerekasztal-konferencia az állattenyésztési biotechnológia köréből <subfield code="b">Szerencs, 1986. október 7 - 8. <subfield code="c">szerk. Seregi János, Borogdai Béla <subfield code="h">01 <subfield code="a">Bp. <subfield code="b">OMIKK <subfield code="c">1986 <subfield code="a">44 p. <subfield code="c">24 cm <subfield code="a">Napjaink biotechnológiája <subfield code="x">0237-8469 <subfield code="v">4. <subfield code="a">állattenyésztés <subfield code="3">42858 <subfield code="a">biotechnológia <subfield code="3">43980
6
<subfield code="a">Borogdai <subfield code="j">Béla <subfield code="3">5092 <subfield code="4">szerk. <subfield code="s">C00047167 <subfield code="i">C00047167 <subfield code="a">GATE <subfield code="x">hozzaferheto <subfield code="b">Raktár <subfield code="k">Kölcsönözhető <subfield code="u">30.00 <subfield code="t">Napjaink biotechnológiája <subfield code="x">0237-8469 <subfield code="v">4. <subfield code="w">107785
A bemutatott struktúra nemcsak felgyorsítja az output ellenőrzési fázisát, de lehetőséget ad annak gyors – akár egyszerű szövegszerkesztővel - történő javítására is. Adathiba észlelése esetén nem feltétlenül kell egy 70-80 ezres állományra újból az exportot ráengedni, s így jelentős idő takarítható meg.
7
