A javítások, a konverziók, az ellenőrző beállítások során folyamatosan bele-botlottunk ugyanabba a problémába: nem kezelhetők teljesen ugyanazon a módon az egy formátumba tartozó dokumentumok sem. Az alap formátumok a következők voltak az új tipológia bevezetése előtt: BK – könyv, CR – idő-szaki kiadvány, CF – számítógépes fájl, MP – térkép, MU – zene, VM – vi-zuális anyag, MX – vegyes anyag. Egy formátum több dokumentumtípust is tartalmaz, melyekre más-más szabály vonatkozik. Például a BK formátumba tartozik a könyv, a kézirat és az elektronikus könyv is; CR formátum a folyóirat és a sorozat is. Így ha egy mezőt kötelezővé tettünk az egyik formátumon, az vonatkozott az összes dokumentumtípusra a formátumon belül, ami sokszor nem volt indokolt.
A BK formátumú rekordok 87%-a könyv, a többi e-könyv, kézirat, levéltá-ri anyag, levelezés, disszertáció és bibliográfia. Az automatikus javításokat ez megnehezítette, ilyen nagy halmazzal nehezen lehetett dolgozni, főleg hogy a halmazokban többféle dokumentum is megtalálható volt.
Ezeknek a problémáknak a kiküszöbölésére 2017 elején saját dokumentumti-pológia kidolgozásába fogtunk és március végén be is vezettük az új rendszert.
A korábbi rekordjainkat javítottuk az új tipológia szerint, azóta pedig az új formátumok szerint készülnek a rekordok.
A tipológia bevezetésétől azt vártuk, 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 dokumentumtípus szerinti keresésre a Primo-ban (a könyvtár discovery rendszerében);
• 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, a MOKKA-ba és a MOKKA-R-be is.
Az eddigi hét formátumot (BK, CR, CF, MP, MU, VM, MX) bővítettük, így 30 formátumunk lett, melyekhez egyedi LDR (rekordfej) é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. Minden változtatásnál szem előtt tartjuk azt az alapelvet, hogy mindig MARC21-nek megfelelően katalogizálunk, nem térünk el a szabályzatoktól.
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 beszerzendő dokumentumfajták feldolgozására felkészülve 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álasz-tásával kezdi a munkát, majd az ennek megfelelő, a fix értékekkel előre kitöl-tö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 a házi szabályok szerint töltjük ki, a rekord többi mezőjének adatai kerülnek 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 a virtuális (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 ér-tékeket;
• pontosítottuk a hibaüzeneteket;
• aktualizáltuk a feldolgozási űrlapokat;
• új átemelési módszert alakítottunk ki;
• átdolgoztuk a véglegesítő (fix) és egyesítő (merge) programokat.
A legtöbb feladatot elő tudtuk készíteni, létrehoztuk az új fájlokat a rend-szerben, í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 fo-lyamat után lehetett ismét dolgozni a rendszerben. A munkatársak teljeskörű tájékoztatást kaptak a változásokról és a tipológia bevezetése óta is tehetnek javaslatokat a rendszer finomítását illetően.
A korábbi rekordjainkat a báziskódok alapján tudtuk átkonvertálni az új for-mátumokra, majd automatikusan javítottuk az LDR, 008 mezőkben az érin-tett pozíciókat. Az eddig könyvként, BK formátumon kezelt, az új rendszer
szerint nem oda illő rekordokat az adott típus speciális mezői alapján tudtuk beazonosítani és a megfelelő formátumba áthelyezni.
Mindezekkel a módosításokkal törekedtünk a rekordlétrehozási folyamat optimalizálására, a hibalehetőségek csökkentésére a hatékonyság érdekében, illetve a formailag téves adatbevitel lehetőségének szoftveres megelőzésére.
Az ellenőrző táblákat és a kapcsolódó beállításokat folyamatosan aktualizáljuk.
Dokumentumtipológia – BK
Dokumentumtipológia – CR
Dokumentumtipológia – CF
Dokumentumtipológia – MU
Dokumentumtipológia – MP
Dokumentumtipológia – VM
Elhatároztuk, 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, a megjelenítést vagy 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ül-nek be a közös katalógusokba. 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 a 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 (illetve a rekordhoz kapcsolódóan, hiszen virtuális mező lévén nem a leírás része), amikor az ehhez meghatározott LDR és 008-as pozíció ér-tékek szerepelnek a rekordban. Ilyen módon – a TYP-mező szempontjából – az LDR és a 008-as mezők tartalma a döntő a rekord típusának meghatározásakor,
melyek MARC21-nek megfelelő mezők. Konkrét példán bemutatva: elektroni-kus 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).
A TYP mező használata a Primo típus szerinti megjelenítésének is alapja lett.
Régóta terveztük egy „típus-facetta” létrehozását a találati lista szűkítésére.
A Primo-ban néhány fő típus (könyv, cikk, folyóirat stb.) alapértelmezetten jelen van. Azonban az új dokumentumtipológia keretében létrehozott egyéb „speciá-lis” formátumokat (például kézirat, könyv, disszertáció) is meg akartuk jeleníteni a discovery rendszerben is. A típusbeállítás alapja Primo-ban csak olyan MARC mező lehet, amely rendelkezik almezővel. Ez alapján például az FMT mező nem használható erre a célra. A TYP mező viszont minden szempontból megfelelt arra, hogy a típusfeltételek megadását erre a mezőre alapozzuk.
40. ábra TYPmező az Aleph rekordban
41. ábra Típus szerinti megjelenítés a Primo-ban
42. ábra A „Forrás típusa” facetta a Primo-ban
Olvasószolgálati tapasztalatok alapján elmondható, hogy a keresés során a fel-használók számára fontos szűkítési szempont a dokumentum típusa. Emiatt is igyekszünk a TYP mező alapján az Aleph-ben kialakított teljes típusválaszté-kot megjeleníteni a Primo-ban is.
Az FMT a rekord formátumát adja meg, ami minden esetben a 008-as mező összetételéből határozható meg, mivel minden formátumhoz egyedi 008-as struktúra tartozik. Viszont a keresések, szűrések megkönnyítésének érdekében, tükrözzük a rekord formátumát egy FMT mezőben, így ez kereshetővé válik, meg lehet adni feltételként beállításoknál, megjelenítéseknél.
Az Aleph kliens (feldolgozói) felületén tudunk keresni, szűkíteni ezekre a me-zőkre, a javítási listákat is eszerint tudjuk kisebb halmazokra bontani. A Web-OPAC nyitó felületén látható gyűjteményi adatbázisok szerinti keresés a BAS kódok alapján lehetséges. A Web-OPAC-ban van egy „Típus” oszlop, amely az FMT mező alapján ikonokkal jelöli a felhasználó számára az adott doku-mentum típusát. 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.
Ezeknek a mezőknek a használatával nem térünk el a szabványtól, de meg-könnyítik a keresést, az indexelést és a megjelenítést is. Nem jelentenek plusz beviteli feladatot a feldolgozó munkatársaknak sem, mivel vagy szerepelnek az űrlapokban vagy mentésnél jönnek létre automatikusan.