A konverzió tesztelése, elemzése

A konverzió elvégzése után fontos – nem kihagyható – az ellenőrzés. Elle-nőrizni kell a konverzió helyességét és a rekordok megfelelő elérhetőségét. Ha a megjelenítés nem az eddig megszokott, az nem feltétlenül a konverzió hibája, lehet tábla beállítási probléma is.

Ellenőrizni kell tehát, hogy minden adat hiánytalanul és a konverziós utasítás-ban megadott helyére került, a rekordok elérése – tekintettel a rekordkapcsola-tokra és a csatolt objektumokra – megfelelő.

2016. január 3-án kaptunk értesítést az Ex-LH Kft. munkatársaitól a konver-zió elkészültéről, elkezdhettük a tesztelést. Az MTA01 rekordok az eredeti rendszerszámokkal kerültek át, a DIS01 rekordok pedig ezek után, ezért az ellenőrzéshez megkaptuk e rekordok rendszerszám tartományát a bázis cso-portok bontásában. A DIS01 és az MTA01 adatbázisban voltak azonos bázis-kódok, ezért ezeket is cserélni kellett (DIS01 11 → MTA01 DIS, DIS01 22

→ MTA01 SOR lett) DIS01 összesen: 127 184

11 [→DIS] 000722798 → 000741175 18 378 db 22 [→SOR] 000741176 → 000748816 7 641 db

RAL_GIL 000748817 → 000764192 15 376 db

MSS_KKT 000764193 → 000808490 44 298 db

INC 000808491 → 000809552 1 062 db

LGYL 000809553 → 000820257 10 705 db

egyéb báziskód 000820258 → 000820817 560 db

Az ‘egyéb báziskódok’ halmaz rekordjait az INC alapján konvertálták, ezekben vagy érvénytelen báziskód volt vagy kimaradt a konverziós utasításból.

A nyelvkódokat és az FMT kódokat is javították a konverziós utasítás szerint, megkaptuk a kért ellenőrző listákat és a konverzió során talált hibákat.

Kezdhettük a konverzió tesztelését, elemzését. A konverzió kritikus pontja volt az MTA01 és a DIS01 adatbázisok összeosztása. Számítottunk arra, hogy itt lehet probléma, ezért ennek ellenőrzésével kezdtünk. Az alábbi problémákat találtuk a tesztelés során (csak a legfontosabbakat emeljük ki):

A rekordok bibliográfiai szintű összekapcsolására az Aleph kapcsolómezőt (LKR) használjuk, amiben meg kell adni a kapcsolódó mező azonosítóját (rendszerszám). Az ellenőrzés során kiderült, hogy az LKR mezőben a rend-szerszámok elcsúsztak. A kapcsolatokat kezelő Oracle tábla (Z103) újraépíté-sével a probléma megoldódott, január 4-én ezt már lezárhattuk.

Az LKR mezőkből eltűntek a $b almezőtartalmak vagyis a rendszerszám.

Szükség volt a konverzió előtti rekordok ellenőrzésére, hogy bizonyítsuk, ko-rábban volt benne tartalom. Ezek után a konverziós programot javították és január 4-én ez a probléma is lezárható volt.

A 852 mezők megjelenítésénél indikátorokat használtunk, hogy a nem egy-ségesen kezelt 852 mezőből meg tudjuk jeleníteni a raktári jelzetet a külön-böző dokumentumtípusoknál. A konverzió előkészítése során nem kaptunk megfelelő információt a feldolgozóktól a mező használatára vonatkozóan, így nem jelent meg minden részcímesként feldolgozott dokumentum rekordjánál a raktári jelzet. Megkerestük azokat a rekordokat, ahol a konverzió során indi-kátort töröltünk, ezeket a konverzió előtti exportból visszatöltöttük.

Találtunk duplán konvertált rekordokat: az elemzés során kiderült, hogy a konverziós utasítás és a konverziós program is hibás volt, ugyanis mivel több báziskódot is tartalmaztak, mindegyik bázis-csoport konvertálásakor módo-sultak. Ezt a hibát csak később fedeztük fel, de a javítást elvégezték, nem volt szigorúan megszabott reklamálási időszak.

Ezeken kívül a konverziós program hibájából adódó probléma nem volt.

A bibliográfiai rekordokhoz kapcsolódó besorolási elemek (authority reordok), példányadatok és a példányrekordokhoz kapcsolódó szerzeményezési, köl-csönzési adatok konverziójának ellenőrzésére nem kellett különösebb figyel-met fordítani, mivel ezek konverziója az új verzióra való átállás standard eljá-rásának része.

A katalógusunk (bibliográfiai és authority adatbázisok) konverzió előtti álla-potáról készült exportot számunkra (Szakinformatikai Osztály munkatársai) könnyen elérhető helyre tettük, így ellenőrizni tudtuk a rekordokat, ha valaki reklamációval élt. Az MTA01-be beosztott DIS01 rekordok régi rendszerszá

mai a konverzió során a 036 mezőbe kerültek, indexeltük is ezt a mezőt, így bármikor a régi rendszerszám alapján is megtaláltuk a rekordokat.

A konverzió januári tesztelése után úgy gondoltuk, a szupport cég által vég-zett konverziót lezárhatjuk, március–áprilisban azonban találtunk még hibákat (dupla rekordokat). A konverziós utasításban kért hibalistákat megkaptuk, a következő lépés ezek feldolgozása és munkafolyamatba illesztése volt.

Felhasználva a konverzióhoz szükséges adatelemzés eredményét és a MARC21 szabványra alapozott feldolgozási házi szabályzatokat, körvonalazódott milyen mélységben szükséges adattisztítást végezni.

Az adattisztítási munka menedzselésére elkezdtük a könyvtári – eddig csak informatikai problémák bejelentésére használt – hibabejelentőt (Redmine) használni, ebben kiosztva a feladatot és így követni a javítást.

A konverziós utasítás tábláját az adattisztításhoz is használjuk, ezért az eredeti táblázat folyamatosan bővül és így lassan minden javítandó, átalakítandó adat-mezőre vonatkozó komplett táblázattá válik.

Az alábbi javításokat végeztük vagy végezzük el:¹⁹

– az arab kéziratok rekordjaiban a 988-as mezőket 880-ra konvertáltuk (ahogy az a perzsa és héber űrlapban is szerepel) - 880 mezőbe $6 almező került a hozzátartozó mező megjelöléssel: 520-00/(3

– az arab kéziratoknál a megszűnt 74X mezőket 740-re konvertáltuk, az in-dikátorok megtartásával

– az arab kéziratokban az 503-as mezőt 510-re konvertáltuk (ahogy az a perzsa és héber űrlapon van) - pontosvesszővel elválasztva szerepelt az is-métlődő tartalom, ezeket külön mezőkbe osztottuk utólagos konverziós utasítással

– 751 konverzió (földrajzi elnevezés) - helyi 951 mezőből régi könyveknél volt használatban, városnevek régi elnevezésének mai megfelelője

– 774-es mező tartalma konverzió előtti lista alapján lett javítva - 442 db mező (36 rekord) törölve/áthelyezve

– 041 mezőkben ‚/’ jellel írt nyelvkódok is voltak. Ezeket a konverzió nem tudta kezelni, mert nem tudtunk róla, ezért nem volt a konverziós utasítás-ban erre külön szabály. Szétszedtük 3 karakteres blokkokra ismétlődő $a almezővel a ‚/’ jel alapján, ezeket (betölthető halmaz) online kell javítani.

19 Válogatott lista.

– BAS mező javítása DIS01 rekordokban - A DIS01 konverzió során ki-szűrtük azokat a rekordokat, melyeknek rossz volt a báziskódja. Volt olyan, ahol a BAS mezőben nem $a az almező kódja, ezért hibás. Volt olyan, ahol nem érvényes báziskód szerepelt, pl. 7

– 240-es mezők javítása - $$i → $$l almezőkód csere

– 700 $$4 almező javítása - közreműködői kód/megnevezés egységesítése – Authority (MTA10) 110 és 410-es mezőinek javítása

– FMT javítása - ellenőrzés előzte meg, találtunk nem érvényes értéket, ezért dokumentípus alapján újraterveztük a kódokat és ezeket vittük be/

cseréltük át

– LDR javítása - dokumentumtípus alapján tudtuk egységesen javítani – 222 mező javítása - áttettük a 210-es mezőbe: korábbi

konverziós/feltölté-si hiba, hogy a rövidített kulcscímek 222 mezőbe kerültek – BAS kód nélküli rekordok kigyűjtése és javítása

– példány nélküli rekordok kigyűjtése és a javítás menedzselése

– megrendelt, de be nem érkezett példányrekordok kigyűjtése, ellenőrzése, szükség szerinti törlése

– rendelési, érkeztetési rekordok/példányok ellenőrzése, függőben lévő ren-delési rekordok karbantartása

– 852 $9 ellenőrzések - retrokonverzió során a példányrekordokat automa-tikusan készítjük el a 852 mező adatai alapján, a $9 almezőbe kerül ekkor a példány kölcsönözhetőségi státusa, amit a példányrekord elkészülte után törlünk

– tévesen használt xx országkód javítása

– ország vagy nyelvkód nélküli rekordok legyűjtése, ellenőrzése, csomagban vagy online javítása

– kötelező mezők (LDR, 008, 040, 041, 245, 260, 300, 850) ellenőrzése, a hiányos rekordok legyűjtése, ellenőrzése, a javítás menedzselése

– kötetkezelés nem egységes - a különböző kötetkezeléseket áttekinteni, ki-dolgozni az egységesítésre vonatkozó elveket figyelembe véve mit lehet visszamenőlegesen is javítani

– még mindig található 9XX szerzeményezési mező - ezeket legyűjteni, el-lenőrizni és törölni

– helyi mezők felszámolása

– RC (részcímes rekordok) rendbetétele - korábban nem a folyóirat

leírás-hoz kapcsoltuk a tematikus számok leírásait, hanem fiktív sorozati rekord készült. Fiktív sorozatok legyűjtése, ellenőrzése, folyóiratrekorddal beazo-nosítása, a csomagban való javítás lehetőségének kialakítása

– 541 rendbetétel - az 541 mezőbe kerülnek a beszerzésre vonatkozó adatok, ezek lehetőség szerinti egységesítését szeretnénk elérni a mező almezőinek használatával

– 710 mező helyett 700 mezőben van a testület - retrokonverzió során ke-rültek rossz mezőbe, ennek javítása fontos, mert jelenleg a discovery rend-szerben (Primo) megjelenik mellette a VIAF kapcsolat (amit csak sze-mélyneveknél akarunk)

– 856 rendbetétel - a linkek ellenőrzése, a rossz linkek törlése, a mező hasz-nálatának folyamatos ellenőrzése

– 260 - 008 összevetés - a 008 mező tartalmának ellenőrzése a 260 mező tartalma alapján (év és országkód)

– törölt rekordok szabályos törlése - korábban rekordokat nem a szabályos módon töröltek, hanem az összes mező törlésével, ezért a rekordokban maradtak olyan mezők, melyek gondot okoztak a különböző legyűjtések-nél, kereshetővé és így kiszűrhetővé tettük ezeket

3.3 A feltárás munkafolyamatainak egységesítése katalogizálási