Szabványos metaadatok jelentősége a kooperatív szolgáltatásokban

Átállás HUNMARC-ról a MARC21 szabványra a WorldCat-csatlakozás előkészítéseként

A Magyar Tudományos Akadémia Könyvtár és Információs Központ (továbbiakban MTA KIK) 2016. január 1-től MARC21 formátumban dolgozza fel az állományát. Az automatikus konverziót precíz előkészületek előzték meg és számtalan utómunkálat követi a mai napig is. Számos feladat és kihívás hárult a Szakinformatikai, valamint a Gyűjteményszervezési osztályra a konverziós feladatok és a feldolgozási útmutatók kidolgozása kapcsán. A különböző állományrészek feldolgozóinak tapasztalatai alapján együttműködve próbáljuk minden adatnak és mezőnek megtalálni a helyét az új struktúrában.

Mielőtt részletezném az átállás folyamatát, illetve a HUNMARC és a MARC21 formátum közötti különbségeket, nézzük meg, miből indultunk ki, mik a rendszersajátosságaink!

Az MTA KIK az Aleph integrált könyvtári rendszert használja, és az átállás előtt HUNMARC formátumban dolgoztuk fel a műveket. A fő dokumentum-formátumokon belül báziskódokkal dolgozunk. Külön báziskód jelöli a törzsgyűjteményi könyvállományt, a folyóiratokat, a sorozatokat, a kéziratokat, a régi könyveket, az ősnyomtatványokat, a mikrofilmeket, a dezideráta, a rendelési és a különböző retrokonverzió során létrejött rekordokat.

Minden gyűjteményrészhez készítettünk egy űrlapot a szerveren, így például a Nemzeti Casino állományának feldolgozásához készített űrlap betöltésekor már a sablonban szerepel a báziskód, valamint a kötelező és a speciális mezők is.

A szerzőkhöz, testületekhez authority rekordokat készítünk, ahol felvesszük a főbb ismérveket, így a feldolgozáskor beemelhetővé válnak a személynevek, testületi nevek egységesített formában. A sorozatokhoz sorozati rekordokat készítünk, így a sorozati címek, alsorozatok, ISSN-ek is beemelhetők a rekordokba. Mind az authority rekordokat, mind a sorozati rekordokat összekapcsoljuk a művek leírásaival, így a sorozati rekordnál látható lesz minden hozzá kapcsolt sorozati tag, illetve az adott személynél minden mű, amivel valamilyen kapcsolata áll fenn.

A feldolgozásnál előnyben részesítjük a rekordok átemelését más (lehetőség szerint nemzeti) könyvtárak adatbázisaiból. Az átemelés tényének és forrásának jelölését (040, SID mezők) minden esetben kötelezővé tettük a véglegesített rekordokban. Az átemelt rekordot véglegesítjük egy fixáló programmal, ami a legfontosabb mezőket hagyja csak a rekordban és kitörli a példányra vonatkozó vagy helyi mezőket, illetve a számunkra irreleváns mezőket. A feldolgozóknak össze kell vetni a leírást a kézben tartott könyvvel, és az alapján – ha szükséges – javítani és kiegészíteni példányjellemzőkkel, speciális adatokkal.

A különböző gyűjtemények, korábbi konverziók, feldolgozási gyakorlatok következtében a rekordjainkban vegyes a kötetkezelés. Előfordul, hogy a kötetek egy rekordban szerepelnek (774, 300), de az is, hogy minden kötetnek saját rekordja van (245 $a$n$p).

A rekordkapcsolást a MARC kapcsolati mezők helyett speciális Aleph kapcsolati (LKR) mezővel oldjuk meg. Ennek a kapcsolatnak következtében, a típusától függően a példány a megfelelő helyen szerepel, de minden szükséges helyen látható. LKR mezővel kapcsoljuk össze

  • a sorozati tagok rekordjait a sorozati főlappal,
  • a részcímes művek rekordjait a folyóirat rekordjával,
  • a monografikusan feldolgozott évkönyvek számait az évkönyv (CR formátumú) rekordjával,
  • a kolligátumi tagokat egymással (példányt csak az első tag leírásához kapcsolunk, de az látszik minden egyes tag leírásánál az LKR kapcsolat következtében).

Objektumcsatolást alkalmazunk az Aleph-en belül az ADAM digitális objektumkezelő modul segítségével, a leírások mellett megjeleníthető például a címlap vagy a tartalomjegyzék. Egyes állományrészeknél képként digitalizáljuk a címoldalakat és karakterfelismerő programmal elemezve a tartalomjegyzékeket, majd ezeket csatoljuk a leírásokhoz. A WebOpac keresője össze van kapcsolva az objektumokkal, így amikor az olvasó keres egy kifejezésre, de nem adta meg, hogy melyik mezőben keres, akkor a tartalomjegyzékek szövegében is keres. Objektumként csatoljuk például minden kurrens könyv tartalomjegyzékét a leírásokhoz, vagy például állományvédelmi szempontból a Nemzeti Casino kötetek címoldalát és tartalomjegyzékét is digitalizáljuk és csatoljuk a rekordokhoz. (Így csak abban az esetben veszi kézbe a kötetet az olvasó, ha a tartalomjegyzék alapján talál benne releváns információt.)

Könyvtárunkban az Informatikai Üzemeltetési osztály mellett Szakinformatikai osztály működik. Az Aleph-feladatok, javítások a Szakinformatikai osztály tennivalói közé tartoznak. A HUNMARC – MARC21 konverzió az Ex-Lh Kft. segítségével ment végbe, a további javításokat magunk végezzük el az Aleph-ben. 2017 elejétől néhány javítási feladatot programozással oldunk meg. Ezt korábban nem alkalmaztuk, de egyes, bonyolultabb problémák csak így oldhatók meg a rendszerben csoportos művelettel.

Néhány éve üzemel a WebOpac-unk mellett a Primo Discovery szolgáltatás (továbbiakban Primo), és egyéb Exlibris termékeket is használunk, mint a MetaLib, vagy az SFX (linkfeloldó szolgáltatás a teljes szöveg eléréséhez).

Az MTA KIK része a törzsgyűjtemény mellett a Keleti Gyűjtemény, a Kézirattár és Régi Könyvek Gyűjteménye, a Mikrofilmtár, a Lukács-Archívum, illetve dolgozunk elektronikus dokumentumokkal, melyek a REAL Repozitóriumok valamelyikébe kerülnek.

Állományunk közel 2,5 millió dokumentumegységből áll, jelenleg csaknem egymillió Aleph rekordon. Eddigi rekordjaink többféle módon kerülhettek be a rendszerbe az évtizedek során:

  • normál feldolgozó munka (kurrens anyagok feldolgozása; hagyatékok feldolgozása; különgyűjteményi állományrészek feldolgozása),
  • korábbi konverziók, betöltések,
  • pályázatok, projektek (perzsa, héber, török, RMK I.),
  • retrokonverziós pályázatok,
  • rövidített leírások (pl.: kölcsönzésben készített).

Rendszerünkben különféle dokumentumok szerepelnek: könyvek (kurrens, hagyatéki, régi könyves állományrészek) • ősnyomtatványok, antikvák • kézira­tok, levelezések, régi levéltári anyagok • folyóiratok • disszertációk • mikrofilmek • CD/DVD/adatbázis • térképek • érmek, egyéb tárgyi egységek • elektronikus dokumentumok.

MARC21 – WorldCat

Könyvárunk célja, hogy a nemzeti és nemzetközi könyvtári hálózatba minél pontosabb és egységesebb adatokkal, modern formátumú rekordokkal kapcsolódjon be. Könyvtárunk aláírta a csatlakozási szerződést a WorldCat adatbázisához, a világ legnagyobb online könyvtári közös katalógusához.

A csatlakozással az MTA KIK szándéka a könyvtár állományának megjelenítése a világkatalógusban, aktívabb részvétel a nemzetközi kölcsönzésben, a digitális másolatrendelés és a repozitóriumban közzétett digitalizált tartalmak használatának elősegítése, illetve a határon túli tudományos élet támogatása.

A következő néhány hónapban összeállítjuk rekordjainkból a próbacsomagot, majd az ellenőrzési és konverziós folyamatok után kezdhetjük el az állományunk betöltését a WorldCat adatbázisába. A csatlakozás egyik fő feltétele, hogy a leírásaink teljes mértékben megfeleljenek a MARC21 szabványnak.

A javítások és a csatlakozás kapcsán több problémával találkoztunk, amit nem sikerült megoldanunk, vagy csak bonyolult módszerekkel. Kérdéseinket a tapasztalatcsere érdekében más könyvtárakkal is megbeszéltük. Jártunk a Szegedi Tudományegyetem Klebelsberg Könyvtárában, ahol a kollégák megosztották velünk a WorldCat csatlakozással kapcsolatos tapasztalataikat. Nagyon tanulságos út volt, még akkor is, ha ők Corvina rendszerben dolgoznak, és korábban is MARC21 szabvány szerint dolgoztak fel. Olyan ötleteket kaptunk tőlük, melyeket megpróbálunk a mi rendszerünkben is meghonosítani.

Az Eötvös Loránd Tudományegyetem Egyetemi Könyvtárával folyamatos kapcsolatban állunk, keressük egymást mind a problémamegoldás, mind a kölcsönös segítségnyújtás érdekében. A javítások során közösen áttekintettük és elemeztük a nálunk, ill. az ő rendszerükben felmerült problémákat.

Átállás/konverzió

2016 januárjától álltunk át a HUNMARC formátumról a MARC21 adatcsere-formátumra. Az átállást a Szakinformatikai osztály irányította. Az előző év végén összeállítottunk egy mező megfeleltetési konverziós táblázatot. Értelmeztük, hogy melyik HUNMARC mező és almező tartalma melyik MARC21-es mezőbe és almezőbe kerüljön, milyen indikátorokkal. Meghatároztuk a megszűnt mezők új helyeit, a megszűnt almezőknél megadtuk, hogy a tartalmuk melyik almezőbe kerüljön, milyen formában. Ahol nem tudtunk egyértelműen konverziós parancsot megadni, ott listát kértünk az adott mező teljes tartalmáról rendszerszámokkal, és elemzés után csoportosan áthelyeztük a tartalmakat a megfelelő helyre, vagy utólag online javítottuk az egyes tételeket. A konverzió során kiszűrtük a hibás és már a HUNMARC szerint is érvénytelen mezőket. Ezekről is listákat kértünk ellenőrzés céljából.

A KSZ/4.1: 2002 HUNMARC (A bibliográfiai rekordok adatcsere formátuma) és a MARC21 szabvány között több mint 1300 pontban van eltérés. Ebbe beletartozik az értékek, indikátorok, mezők, almezők változása, megszűnése vagy éppen létrejötte is. A mi katalógusunkat a változások viszonylag kis töredéke érinti. A konverzió során közel 150 változást sikerült automatikusan lekövetnünk, és azóta is számos változást javítottunk az utómunkálatok során. A fő különbség a két szabvány között számunkra az, hogy a MARC21 sokkal aktuálisabb, naprakészebb, ezért jobban használható a mai világban. A klasszikus – esetenként mára elavult – hordozók mellett már a modern technika elemeinek is megtalálható a pontos helye. Számos új mezővel egészült ki az évek során a MARC21 és továbbra is folyamatosan frissítik.

A karácsonyi szünet alatt az Ex-Lh Kft. munkatársai lezárták az Aleph rendszert és elvégezték a szükséges rendszerfrissítéseket (egyidejűleg áttértünk a rendszer újabb verziójára) és a konverziót a megadott utasítások alapján. A 2017-es év minden érintett munkatárs számára az új szabályok megismerésével és folyamatos megbeszélésekkel kezdődött. A kezdeti nagy létszámú megbeszéléseket hamarosan felváltották az egyes osztályok képviselőiből felállt MARC21 munkabizottság ülései, amelyeken mezőről mezőre megbeszéltük a változásokat, a problémákat és a teendőket. Ezzel párhuzamosan frissítettük az elkészült házi szabályzatunkat, és minden megbeszélés után megosztottuk az eredményeket a munkatársakkal. A MARC 21 bizottság továbbra is működik, és minden javítási feladatot és problémát közösen elemzünk és döntünk.

Házi szabályzat

A szabályzatok megírásánál a magyar és nemzetközi szabványokat tekintettük kiindulásnak, ezt feleltettük meg a MARC 21-es mezőknek és figyelembe vettük a DEENK és az ELTE MARC21-útmutatóit. Alkalmazkodni kellett a MOKKA előírásaihoz is, mivel az elkészült rekordjainkat átadjuk a MOKKA-ba, a régi könyves leírásokat a MOKKA-R-be. Több szabályzatot készítettünk:

  • monografikus és többkötetes művek (kolligátum, régi könyvek),
  • időszaki kiadványok (sorozatok, részcímesek, évkönyvek),
  • elektronikus dokumentumok,
  • authority tételek,
  • kartográfia,
  • folyamatban: számítógépes fájl, kézirat, tartalmi feltárás.

Az érvényben lévő főbb magyar szabványok: (bővebben ld. a Könyvtári Intézet weboldalán
http://ki.oszk.hu/sites/ki.oszk.hu/files/dokument umok/5_szabvanykatalogus_honlapra_20151116.pdf)

  • MSZ 3424-1:1978 Könyv szabvány (MSZ)
  • KSZ/1:1999 Bibliográfiai leírás. Kartográfiai dokumentumok
  • KSZ/2:2000 Bibliográfiai leírás. Elektronikus dokumentumok
  • KSZ/3:2001 Bibliográfiai leírás. Időszaki kiadványok
  • KSZ/5:2005 Földrajzi nevek mint adatbázisrekordok tárgyi hozzáférési pontjai
  • KSZ/6:2009 Bibliográfiai leírás. Régi nyomtatványok
  • MSZ 3440-1:1983 A bibliográfiai leírás besorolási adatai. Fogalommeghatározások. 5 p. (Utolsó helyesbítése megjelent: 1988.)
  • MSZ 3440-2:1979 A bibliográfiai leírás besorolási adatai. Személyek nevei. 32 p. (Helyesbítése megjelent: 1988.)
  • MSZ 3440-3:1983 A bibliográfiai leírás besorolási adatai. Testületek neve. 28 p. (Helyesbítése megjelent: 1988.)
  • MSZ 3440-4:1986 A bibliográfiai leírás besorolási adatai. Címek. 13 p.

Fejtörők, adattisztítás

Új alapelveket állítottunk fel és vezettünk be az egész intézményre vonatkoztatva. A legfontosabb, hogy a MARC21-től nem térünk el (https://www.loc.gov/marc/bibliographic/). Egységes leírási elveket alkalmazunk a különböző gyűjteményrészekben. Egy mű esetén csak egy leírást készítünk, vagyis művet írunk le és nem példányt. Minden rekordnak kell, hogy legyen példányrekordja a megfelelő helyen, függetlenül a hordozótól. Minden rekordnak kell, hogy legyen érvényes formátuma és báziskódja. Egységes 852-es mező (raktári jelzet) struktúrát dolgozunk ki minden gyűjteményrészre. A többkötetes művek feldolgozásánál egy leírást készítünk, és a 774-es mezőkben jelöljük az egyes kötetek saját adatait. Kiemelt figyelmet fordítunk az LDR és 008 mezőkre, mivel a Primo ezekből a mezőkből veszi például a dokumentumok típusadatait. Kerüljük a helyi mezők használatát, minden információnak megkeressük a legoptimálisabb helyét a MARC21 mezőkben.

Az alapelveket az új rekordbevitelnél folyamatosan be tudjuk tartani, viszont a korábbi rekordjaink új szempontok szerinti javítása még nem fejeződött be.

Próbáltuk megtalálni azt a módszert, amivel elkülöníthetők a különböző fizikai példányokra vonatkozó speciális jellemzők egy leíráson belül. Megfogalmaztuk a duplum példányok kezelésének szabályait és módszereit. A leírásban is egyértelművé kell tenni, hogy melyik példányjellemző melyik fizikai egységre vonatkozik. A megjegyzés mezőknél használható $5 almezővel oldottuk meg: például ha egy adott mű megtalálható a Kézirattárban, a Nemzeti Casino-ban és egy törzsgyűjteményi hagyatékban is, csak egy leírást készítünk, ahol egyértelműen kiderül, hogy melyik raktári jelzetű példány melyik gyűjteménybe tartozik, milyen speciális tulajdonságai vannak (beszerzés forrása, proveniencia, tulajdonosi bejegyzés, pecsét, kötés, fizikai állapot).

A konverzió kapcsán újra kellett definiálni a speciális fogalmakat, hogy meghatározzuk a kezelési módokat. Ilyenek például a kolligátum, gyűjteményes művek, monografikusan feldolgozandó évkönyv, rekordkapcsolatok. Közös kolligátum-feldolgozási, kötetkezelési és példányadat-készítési elveket állapítottunk meg. A megjegyzés típusú mezőkre kiemelt figyelmet fordítunk, hogy a speciális adatoknak megtaláljuk a pontos helyét, még akkor is, ha ezzel az egész korábbi gyakorlatunkat felül kell vizsgálnunk.

A pontos visszakereshetőség, érthetőség és az esetleges jövőbeni konverziók érdekében figyeltünk rá, hogy minden adat a neki kijelölt helyen és formátumban (mezőben és almezőben) legyen. Folyamatosan ellenőrizzük a WebOpac-kal és a Primoval való összhangot, szükség esetén pontosítjuk, módosítjuk a beállításokat.

A konverziónál sok fejtörést okozott a megszűnt mezőknek, illetve almezőknek megtalálni az új helyét. Sok esetben egy másik mező/almező végére kellett áttenni valamilyen központozási jellel a tartalmat. Az új mezők/almezők feltöltése is kihívást jelentett, amikor az adott tartalom korábban valahol máshol, vagy máshol is volt. Külön feladat mezőcsere esetén arra figyelni, hogy az indikátor-módosulásokkal nehogy adatvesztés következzen be. Egyes esetekben a szabvány nem egyértelmű, és példákat se közöl minden speciális esetre. A könyvek leírása esetén továbbra is az ISBD szabvány az irányadó, így azt mindig meg kell feleltetni a MARC21 szabványnak. Néhány mezőcserénél megváltozott az indikátor, és egyes címmezőknél megszűnt a leszámolandó karakterek kezelésének a lehetősége (246, 490).

A 880-as mezőben egyéb írásrendszerű adatokat tudunk bevinni. Többnyire címek, szerzők kapcsán, arab, kínai, japán, koreai, cirill, görög és héber írásrendszer esetén használjuk. A MARC21 szerinti mezősorrend használatakor indexproblémák jelentkeznek a rendszerünkben, melyeket egyelőre mezősorrend-cserével sikerült megoldanunk. Problémát jelent továbbra is a nem gregorián naptár szerinti évek kezelése a 008-as mezőben, 260 kitöltése után. A 830-as mező mögött beemelhető indexet használunk, ahol a leszámolandó karakterek következtében beemelésnél levágja a névelőt a rendszer.

Korábbi feldolgozási gyakorlatainkból, a retro­kon­verziók nyomán és a különböző gyűjteményeinkből eredően rengeteg duplum leírás található az adatbázisunkban. Azokat, amelyek kézbe kerülnek, egységesítjük, egy leírást készítünk, áthelyezzük a példányokat, és töröljük a felesleges leírásokat. Mivel a művelet nem automatizálható, nem tudjuk gyorsítani a javítást. Abban az esetben, amikor azonnal nem tudjuk összevonni, összekötjük a rekordokat az LKR rekordkapcsolati mező PAR típusával, így az olvasó is látja a WebOpac-ban, ha az egyik leíráshoz tartozó kötet kölcsönzés alatt van, hogy más példány még elérhető lehet a számára. Szerencsére a Primo már az adott szempontok szerint felismeri a duplum leírásokat, így megkönnyítve az olvasó dolgát a keresés során.

A házi szabályzat alapján építjük fel a mezősúgókat, így a szabályzat frissítése esetén a súgót is aktualizálnunk kell. A különböző osztályokhoz és gyűjteményekhez, az illetékes feldolgozó munkatársakkal egyeztetve külön űrlapokat készítettünk a központi szerveren. Gondosan ellenőrizzük, hogy melyik indexbe milyen mező(k), illetve almező(k) kerüljenek, segítve ezzel a később érkező példányok behasonlítását.

A Szakinformatikai osztály munkatársai fokozatosan bővítik, pontosítják az indexelési eljárásokat. Az olyan almezők esetén, melyek tartalma részben előre meghatározható, a leggyakrabban előforduló kifejezéseket sablon listába teszik, melyek így néhány kattintással beemelhetők (Ctrl+F8). Ezzel valamennyire megpróbáljuk kiszűrni az elgépelés lehetőségét.

A könyvtárnak van egy online informatikai hibabejelentő rendszere, ahol az Aleph-fel kapcsolatos problémákat is be lehet jelenteni.  Ezt a szakinformatikusok azonnal látják, és elkezdenek dolgozni a problémán, visszajeleznek, válaszolnak a bejelentőnek. A konverzió utáni problémákat, javításra szoruló mezőket itt tudjuk kezelni, a javításra váró mezők listái itt közzétehetők.

Az elkészült hibalisták alapján elemezzük a mezők tartalmát, mintákat, sémákat állítunk fel, melyek alapján az adott tartalmú mezőket át tudjuk helyezni egy másik mezőbe. Szükség esetén most már programozással javítunk. Amennyiben nincs lehetőség csoportos áthelyezésre, egyesével, rekordonként, online javítjuk a mezőtartalmakat. Az adott mezőhöz tartozó hibalistát megpróbáljuk gyűjteményekre bontani, például a folyóirat mezőit a folyóiratos munkatársak, a régi könyves speciális mezőket régi könyves feldolgozók javítják.

A katalógusban előforduló korábbi konverziókból adódó hibákat is keressük és javítjuk. A rekordokban felmerülő tipikus hibákra, problémás mezőkre külön felhívjuk a figyelmet. Mezőösszefüggéseket is vizsgálunk, hogy egyes mezők milyen kapcsolatban álljanak egymással a rekordon belül.

A hibák előzetes kiszűrése érdekében a szabvány szerint kötelező mezők/almezők meglétét ellenőrző (check) táblákkal próbáljuk ellenőrizni. Megadjuk a rendszernek a dokumentum-formátumokhoz tartozó kötelező mezőket/almezőket, így azok megléte nélkül vagy többszörözése esetén nem menthetők el a rekordok.

Egyrészt az új rekordok létrehozásánál segítség ez a kollégáknak, másrészt a javítások során, amikor egy korábbi rekordban végzünk javítást, a rendszer jelzi, hogy azóta esetleg kötelező lett egy adott mező. Ennek a módszernek a nehézsége, hogy ezt többnyire csak rekord formátumokra tudjuk megadni, viszont egy formátumon több dokumentumtípus is szerepel, melyekre más-más szabály vonatkozik. Azonos követelmények vonatkoznak különböző dokumentum­típusokra. Például a BK formátumba tartozik a könyv, a kézirat és az elektronikus dokumentum is; CR formátum a folyóirat és a sorozat is. Így ha egy mezőt kötelezővé teszünk az egyik típuson, a másikon is az lesz, ami nem minden esetben indokolt.

Jelenleg a törzsgyűjteményi állományunk több mint 600 000 rekord. Az automatikus javításokat ez megnehezíti, mert ilyen nagy halmazzal nehezen tudunk dolgozni, főleg hogy a halmazban többféle dokumentum is található.

Ezeknek a problémáknak a kiküszöbölésére új dokumentumtipológia kidolgozását kezdtük meg, és március végén be is vezettük az új rendszert. A meglévő rekordjainkba a tipológia felvezetése még tart, de az új rekordjaink már az új formátumok szerint készülnek.

Új dokumentumtipológia

A tipológia bevezetésétől azt várjuk, hogy hatékonyabb lesz az ellenőrzés már a rekordbevitelnél; kisebb, homogénebb javítási halmazokkal tudunk majd dolgozni; egyszerűbbé válik a csoportos visszamenőleges javítás; lehetőség nyílik a dokumentum típus szerinti keresésre a Primoban; elektronikus dokumentumok könnyebb kezelése valósul meg minden formátumon; és – nem utolsó sorban – gördülékeny betöltést tudunk biztosítani a WorldCat-be, MOKKA-ba, és MOKKA-R-be.

Az eddigi hét formátumot (BK, CR, CF, MP, MU, VM, MX) osztottuk tovább, vagyis bővítettük, így 30 formátumunk lett, melyekhez egyedi LDR és 008 pozíció értékek tartoznak. A létrejött értékkombináció alapján a rendszer automatikusan létrehoz egy ún. virtuális mezőt (TYP) – a feldolgozók számára láthatatlan –, amely tartalmazza a vonatkozó formátum kódját és megnevezését.

A lista szükség esetén bővíthető, bár könyvtárunk állományát jelenleg teljes mértékben lefedi – mind a jelenlegi Aleph rekordjainkat, mind az állományunk még feldolgozatlan gyűjteményrészeit –, sőt, egyes kategóriákat a jövőben érkező dokumentum-fajtákra alakítottuk ki.

Átalakítottuk a korábbi feldolgozói munkamenetünket úgy, hogy új rekord létrehozásakor a feldolgozó munkatárs minden esetben a formátum kiválasztásával kezd, majd az ennek megfelelő, a fix értékekkel előre kitöltött LDR és 008 mezőket egészíti ki az adott dokumentum speciális értékeivel. Ezt a folyamatot követi akkor is, ha átemeléssel hozza létre a rekordot, vagyis a formátumot és ezt a két mezőt minden esetben mi töltjük ki, és a rekord többi mezője kerül csak átemelésre.

Az új típusok kidolgozását követően, az átállás előkészítéseként a következő lépések megtételére volt szükség:

  • az Aleph-ben is létrehoztuk az új formátumokat (FMT) és TYP mezőket;
  • módosítottuk az ellenőrző, ún. check-táblákat és – ahol szükség volt rá – a megjelenítési és index-táblákat;
  • beállítottuk az új formátumoknál előforduló érvényes LDR és 008 értékeket;
  • pontosítottunk a hibaüzeneteken;
  • aktualizáltuk a feldolgozási űrlapjainkat;
  • új átemelési módszert alakítottunk ki;
  • átdolgoztuk a véglegesítő (fix) és egyesítő (merge) programjainkat.

A legtöbb feladatot elő tudtuk készíteni, létrehoztuk az új fájlokat a rendszerben, így a tényleges átállás során csak le kellett cserélni a korábbi fájlokat az újakra. Az új rendszer élesítésekor néhány órás tesztelési és ellenőrzési folyamat elvégzése után már lehetett dolgozni a rendszerben. A munkatársak teljes körű tájékoztatást kaptak a változásokról, és folyamatosan várjuk a javaslataikat a rendszer finomítása kapcsán.

A meglévő rekordjainkat a báziskódok alapján tudjuk átkonvertálni az új formátumokra, majd automatikusan javítjuk az LDR, 008 mezőkben az érintett pozíciókat. Az eddig könyvként BK formátumon kezelt, az új rendszer szerint nem oda illő rekordjainkat az adott típus speciális mezői alapján tudjuk beazonosítani és megfelelően áthelyezni.

Az alábbi táblázat kivonat az új típusokról, de nem tartalmazza a teljes listát és az új FMT és TYP kódokat:

Kimondtuk, hogy nem térünk el a MARC21 szabványtól, de az Aleph kínálta lehetőségeket kihasználjuk. A BAS (báziskód), FMT (formátum), TYP (típus), LKR (rekordkapcsolat) mezők – és az általunk használt egyéb virtuális mezők is – többnyire nem részei a leírásnak, csak kiegészítik azt, hogy megkönnyítsék a feldolgozást, megjelenítést vagy éppen a keresést. A külső rendszerek, mint például a MOKKA vagy a WorldCat helyi mezőként kezeli ezeket, vagyis nem kerülnek átadásra. A helyi mezőket minden intézmény saját belátása szerint használhatja a saját igényeinek megfelelően.
A TYP mező az Aleph-ben egy virtuális mező, ami az LDR és 008 mezők meghatározott értékei alapján épül fel. Tehát egy adott TYP-mező akkor jön létre a rekordban (ill. a rekordhoz kapcsolódóan, hiszen virtuális mező lévén nincs „benne” a rekordban), amikor az ehhez meghatározott LDR és 008-as pozíció értékek szerepelnek a rekordban. Ilyen módon ‒ a TYP-mező szempontjából ‒ az LDR és 008-as mezők tartalma a döntő a rekord típusának meghatározásakor, és azok MARC21-es mezők. Konkrét példán nézve: elektronikus kézirat esetén az EK (eKézirat) TYP csak akkor jön létre, ha egy rekordban az LDR 06-os pozíció értéke ’t’ (kéziratos nyelvi anyag), 07-es pozíció értéke ’m’ (monográfia) és a 008 23-as pozíció értéke ’s’ (elektronikus).
Az FMT a rekord formátumát adja meg, ami minden esetben kiderül a 008-as mező összetételéből, minden formátumhoz egyedi 008-as struktúra tartozik. Viszont a keresések, szűrések megkönnyítése végett tükrözzük a rekord formátumát egy FMT mezőben, így erre már tud a rendszer és az olvasó is keresni, ezt már feltételként meg tudjuk adni beállításoknál, megjelenítéseknél.
Az Aleph kliens (feldolgozói) felületén tudunk keresni/szűkíteni ezekre a mezőkre, a javítási listákat is e szerint tudjuk bontani kisebb halmazokra. A WebOpac nyitó felületén látható gyűjteményi adatbázisok szerinti keresés a BAS kódok alapján lehetséges. A dokumentumtípus szerinti keresés a Primo felületén fejlesztés alatt áll, ehhez szükséges, hogy a rekordjaink teljes mértékben megfeleljenek az új tipológiának. A WebOpac-ban van egy „Típus” oszlop, amely a FMT-mező alapján ikonokkal jelöli a felhasználó számára az adott dokumentum típusát már a rövid listás megjelenítésben. Másrészt a nyitóoldalon van egy „Formátum” szerinti szűrési lehetőség, amely szintén az FMT-kódok alapján működik.
Az LKR mezők felépítésüknek köszönhetőn bármikor megfeleltethetőek MARC21 kapcsolati mezőknek, minden szükséges adatot tartalmaznak ehhez. Ezek feladata a rekordok összekapcsolása valamilyen szempont szerint, aminek a bibliográfiai leírásból ki kell derülnie. Például a sorozati LKR-t kiváltja a 830-as mező, a kolligátum LKR-t az 501-es mező. Vagyis az LKR mezők tartalmának van MARC21 megfelelője, de az LKR-nek köszönhető a WebOpac-ban látható kattintható összekapcsolás a rekordok között. Külső rendszereknek, például a MOKKA-nak, nem minden esetben van ezekre a kiegészítő lehetőségre szüksége.
A fiktív vagy virtuális mezők a megjelenítési és indexelési lehetőségeket bővítik az Aleph-ben. Néha a bibliográfiai leírás szabályaival ellentétes index-problémákat virtuális mezővel oldjuk meg. Több cím típusú mező esetében probléma a névelő jelölése a MARC21-ben, ami főleg konverzió vagy adattisztítás esetén jelent gondot.

Például a sorozati címeknél 490-es mezőben nincs lehetőség az elhagyandó karakterek jelölésére, ezt a 830-as mezőben tehetjük meg. Hasonló eset a 246-os mező, ahol nincs névelő indikátor, viszont 740-es mezőben van, de itt a cím típusának a jelölésére nincs mód. A 246-os mezőben a névelő index felőli letakarását a <<>> jelek közé tétellel oldhatjuk meg az Aleph-ben. „<<A>> magyar” kezdetű címek az indexbe az ’m’ betűnél lépnek be. Amennyiben egyik módszerrel sem oldható meg a helyes indexelés, létrehozunk egy fiktív mezőt, ahol a névelő a mi igényeinknek megfelelően viselkedik, és ezt a mezőt irányítjuk az indexbe. Amennyiben például a 490-es és a 830-as mező egy közös indexbe kerül – az egyik névelő indikátorral, a másik anélkül –, a névelő letakarása nélkül van szükség a 830-ra is, hogy egységesen lehessen kezelni. Ilyenkor megismételhetjük a címet egy erre a célra létrehozott láthatatlan mezőben indikátor nélkül, és ezt küldjük az indexbe.
Ezekkel a mezőkkel nem térünk el a szabványtól, de megkönnyítik a kereséseket, indexeléseket és a megjelenítéseket is. Nem okoznak plusz beviteli feladatot a feldolgozó munkatársaknak sem, vagy már az űrlapokban vannak benne, vagy mentésnél jönnek létre automatikusan.

Mind a HUNMARC – MARC21 konverziós táblázatot, mind az új dokumentumtipológia listát – a kapcsolódó LDR-008 értékkombinációkkal és a teljes dokumentációs anyaggal – hamarosan publikálni fogja az MTA KIK. Az átállással, illetve az adattisztítással kapcsolatban felmerülő további kérdésekben szívesen állunk az érdeklődők rendelkezésére.

Beérkezett: 2017. április 6.

A bejegyzés kategóriája: 2017. 2. szám
Kiemelt szavak: , , , , , , , , , .
Közvetlen link.

MINDEN VÉLEMÉNY SZÁMÍT!