A RAKTÁRI JEGYZÉKEK ELEKTRONIKUS

MEGJELENÍTÉSE ÉS KEZELÉSE
MÓDSZERTANI TANULMÁNY

Boross István

Magyar Nemzeti Levéltár Veszprém Megyei Levéltára

boross.istvan@veml.hu

Dr. Juhász Zoltán

Pannon Egyetem, Műszaki Informatikai Kar, Villamosmérnöki és Információs Rendszerek

Tanszék

juhasz@virt.uni-pannon.hu

Lektorálta
Dr. Sipos András
Budapest Főváros Levéltára

www.nka.hu

A MAGYAR NEMZETI LEVÉLTÁR VESZPRÉM MEGYEI LEVÉLTÁRA

VESZPRÉM, 2014
TARTALOM

1 Bevezetés ........................................................................................................................................................ 4
1.1 Előzmények ........................................................................................................................................... 4
1.2 A tanulmány felépítése ......................................................................................................................... 6
2 A raktári jegyzék ............................................................................................................................................. 6
2.1 Rendszerezés és segédletek a levéltárakban ........................................................................................ 6
2.2 Segédletkészítés a raktári jegyzék előtt ................................................................................................ 7
2.3 A raktári jegyzék megalapozása ............................................................................................................ 9
2.4 A raktári jegyzék születése .................................................................................................................. 11
2.5 A raktári jegyzék utóélete ................................................................................................................... 14
2.6 A raktári jegyzék digitális alakváltozása .............................................................................................. 16
3 A digitalizálás előnyei és hátrányai a levéltári gyakorlatban ........................................................................ 20
3.1 A digitalizálás céljai és előnyei ............................................................................................................ 20
3.2 A digitalizálás hátrányai ...................................................................................................................... 21
3.2.1 Rejtett hátrányok ............................................................................................................................ 21
4 Digitális adatok tárolása ............................................................................................................................... 22
4.1 Tárolási alapelvek ................................................................................................................................ 23
4.2 Strukturált adatok tárolása ................................................................................................................. 24
4.2.1 Relációs adatbázisok ....................................................................................................................... 25
4.3 Részlegesen strukturált adatok tárolása ............................................................................................. 27
5 Az XML adatleíró nyelv ................................................................................................................................. 29
5.1 Az XML szintaxis alapjai ....................................................................................................................... 30
6 Az XML technológia további alkotóelemei ................................................................................................... 32
6.1 XML Névtér (Namespace) ................................................................................................................... 32
6.2 AZ XML séma ....................................................................................................................................... 33
6.3 Az XPath technológia .......................................................................................................................... 34
6.4 Az XQuery Technológia ....................................................................................................................... 35
6.5 Az XML dokumentumok megjelenítése .............................................................................................. 37
6.6 Az Xforms technológia ........................................................................................................................ 38
7 XML szerkesztő és feldolgozó szoftverek ..................................................................................................... 39
7.1 XML dokumentumok létrehozása ....................................................................................................... 39
7.2 XML adatok előállítása űrlapok segítségével ...................................................................................... 41
7.3 XML adatok tárolása adatbázisban ..................................................................................................... 42
8 A levéltári raktári jegyzék digitális leírása ..................................................................................................... 43
8.1 A raktári jegyzék tartalmi elemzése .................................................................................................... 43
8.2 Szerkezeti elemzés .............................................................................................................................. 47

2
 8.3 Szabványok alkalmazási lehetősége .................................................................................................... 48
8.4 A javasolt XML raktári jegyzék modell ................................................................................................ 52
8.4.1 A modell logikai leírása ................................................................................................................... 53
8.4.2 A raktári jegyzék XML séma ............................................................................................................ 55
8.5 Specifikus jegyzékek létrehozása ........................................................................................................ 63
9 Raktári jegyzékek kezelésének munkafolyamat támogatása ....................................................................... 64
10 Összefoglalás ........................................................................................................................................... 68
11 Mellékletek .............................................................................................................................................. 70

3
1 BEVEZETÉS

A magyarországi levéltárak segédletkészítési gyakorlatának legalapvetőbb és a mindennapi munka során

megkerülhetetlen terméke évtizedek óta a raktári jegyzék. Bár a jogszabályok és a levéltártani szakirodalom
klasszikusan a nyilvántartási célú segédletek, több esetben egyenesen a nyilvántartások közé sorolja a raktári
jegyzéket1, mégis e segédlettípus szinte már megszületésétől kezdve paradox módon kutatási és tájékoztatási
célú használattal is bírt. A raktári jegyzékek évtizedek alatt felhalmozott gazdag adattartalmának interneten való
megjelenítésére, és ezzel teljes körű nyilvánossá tételére az utóbbi évtizedben egyre erősebb igény jelentkezett
a kutatni vágyó laikusok és a tájékoztatást végző levéltárosok részéről is.

A levéltáros szakmát több irányból ható erők terelik abba az irányba, hogy újragondolja eddigi gyakorlatait. A
raktári jegyzékek számítógépes megjelenítése ma már csakis valamilyen adatbázisba rendezetten képzelhető el,
ami a levéltárelmélet oldaláról szükségszerűen igényli e segédletünk bizonyos mértékű formai és tartalmi
reformját. Az adatbázisba rendezés gyakorlati problémáin való gondolkodás előtt tisztázni kell olyan kérdéseket
is, mint például a nemzetközi levéltári szabványok alkalmazhatósága a magyarországi raktári jegyzék-készítési
gyakorlatban, azaz hogyan biztosítható a raktári jegyzékekbe foglalt, a levéltári anyagra vonatkozó információk
visszakereshetősége és a szabványos adatcsere-forgalom.

A levéltárelméleti kérdések megújítására tett javaslat mellett a tanulmányunk elsődleges célja annak a
kérdésnek a vizsgálata, hogy a levéltárak legszélesebb körben használt középszintű segédletét, a raktári
jegyzéket miként lehet optimális módon elektronikus úton elkészíteni, megjeleníteni és kezelni. Arra is ki
szeretnénk térni, hogy raktári jegyzékeinket a tartalmi elemek megőrzése mellett – akár ezen a néven, akár új
név alatt – milyen formában lenne célszerű elkészíteni a jövőben. A digitalizálódó világhoz való alkalmazkodás
jegyében felmerül a kérdés, hogy mit kezdhetünk a már meglévő jegyzékeinkkel, legyenek azok papíralapúak,
vagy már valamilyen digitális formában létezők.

A raktári jegyzékek számítógépes kezelése több fontos problémát vet fel informatikai szempontból is. Olyan
megoldásra van szükség, amely egyidejűleg biztosítja a hosszútávú archiválást, a papíralapú rendszerekhez
hasonló megbízhatóságot, de jóval gyorsabb és hatékonyabb feldolgozást, a bővíthetőséget, és a levéltáros
szakma elvárásainak való maximális megfelelést.

1.1 ELŐZMÉNYEK

A magyarországi levéltárügy több szempontból is jelentős átalakulást ért meg az utóbbi időben, és még bizony
további mélyreható változások fognak következni. Elegendő arra utalnunk, hogy megalakult az ország
levéltárainak többségét magában foglaló Magyar Nemzeti Levéltár, az e-levéltár projekt kifutása most zajlik, a
szakmai munka követelményrendszerét meghatározó rendeletünk megújítás alatt van. Tanulmányunk témája
szempontjából a legfontosabb az e-levéltár projekt országos szintre kiterjesztett fejlesztése volt 2012–2013
során. Ennek eredményeként létrejött az Elektronikus Levéltári Portál, amely a kutatók, érdeklődők számára
kényelmes, otthonról az interneten keresztül történő tájékozódás, kutatás lehetőségét nyújtja. A portál
szolgáltatásai között szerepel az ország közlevéltári állományainak levéltári leírásaiban, levéltári adatbázisokban
való keresés és a digitális kutatószolgálati felületen történő online beiratkozás és iratrendelés is. A 2012. október
1-jével felálló Magyar Nemzeti Levéltár integrációs folyamata a megyei tagintézmények számára is
megteremtette a lehetőséget az új központi levéltári nyilvántartórendszerhez, a ScopeArchivhoz való
csatlakozásra. Ezek a fejlemények a digitális levéltári információszolgáltatás nagyfokú előretörését fogják
eredményezni a következő években. A levéltárak tartalomszolgáltató tevékenységében a raktári jegyzékek,

1
A művelődésügyi miniszter 130/1971. sz. (M.K. 10.) MM számú utasítása a Levéltárak Ügyviteli Szabályzata kiadásáról 83.§
(3); Levéltári ismeretek kézikönyve (szerk. Endrényi Ferenc), Tankönyvkiadó, Bp., 1980. 250–253.; A közlevéltárak és a
nyilvános magánlevéltárak tevékenységével összefüggő szakmai követelményekről szóló 10/2002. (IV.13.) NKÖM rendelet
34.§ (2); Szerk.: Körmendy Lajos. Levéltári kézikönyv. Osiris, Bp., 2009. 499–501.

4
illetve a jelenleg csak bennük fellelhető információk nyilvánvalóan jelentős szerepet fognak játszani. Azonban
nem mindegy, hogy hogyan, milyen eszközök, programok segítségével, milyen adatbázisok építésével és
elektronikus rendszerek kialakításával történik mindez. A 2000-es években fokozatosan gyűrűzött be a hazai
szakmai közvélemény tudatába a nemzetközi levéltári leíró szabványok2 léte. A levéltárügy és a levéltári
szervezetek prominensei felismerték, hogy ezeket a szabványokat lehet és kell is alkalmazni levéltárainkban.
Előtte azonban mindenképpen át kell őket szabni saját viszonyainkra. Ez a felismerés odáig vezetett, hogy 2011-
től a Levéltári Kollégium felállította a Levéltári Szabványügyi Bizottságot, amelynek a fő feladata a digitális
környezetre alkalmazható levéltári leíró szabványok létrehozása a nemzetközi szabványok felhasználásával.
Megszülettek az első leíró levéltári szabványok az anyakönyvek, a térképek és a testületi jegyzőkönyvek
irattípusaira3. Az általános levéltári leírás tervezete is elkészült, amelynek bevezetése gyökeresen át fogja
alakítani a levéltárakban folytatott segédletkészítési munkát. Ennek kapcsán már a szabványügyi bizottsági
üléseken, több fórumon vagy kollégák közötti informális beszélgetésekben egyaránt gyakran felmerül a kérdés,
mit is kezdjünk raktári jegyzékeinkkel. Fel kell tennünk azt a kérdést a levéltáros közösségnek, hogy miként
gondolkodjunk a raktári jegyzék műfajáról: kifutó vagy továbbélő segédlet-e a raktári jegyzék? Meg lehet-e
reformálni vagy rövidesen a helyébe lépnek az európai szabványokon alapuló adatmodellt magukban hordozó
olyan új rendszerek, mint a ScopeArchiv? Reméljük, hogy tanulmányunk végére érve az olvasó is egyetért majd
azzal a konklúziónkkal, hogy van mód a raktári jegyzékek átalakítására és a szabványos digitális környezethez
való idomulására.

Tanulmányunk a Magyar Nemzeti Levéltár Veszprém Megyei Levéltárában készült, a szerzők elsődleges
tapasztalatai innen származnak. A levéltári informatikai fejlesztések terén a Veszprém Megyei Levéltár és a
Pannon Egyetem Műszaki Informatikai Karának Villamosmérnöki és Informatikai Rendszerek Tanszéke 2008 óta
működik együtt. A kezdetektől az egyik frekventált informatikai probléma, amelyre a levéltárosok és az
informatika tudományának egyetemi kutatói együtt keresik a választ, a levéltár elektronikus formában rögzített
raktári jegyzék állományának adatbázisba rendezése, a raktári jegyzékekkel végzett munkafolyamat informatikai
támogatása volt. A közös munka egyik első állomásaként a Veszprém Megyei Levéltárban 2011. április 14-én
Elektronikus nyilvántartási rendszerek a levéltárban címmel a Nemzeti Kulturális Alap támogatásával
megvalósított levéltári informatikai szakmai műhelybeszélgetésen már bemutattuk a raktári jegyzékek kezelését
biztosító programunk első változatát4. A program a levéltár e-archivumos fondjegyzék-szerkezetéhez applikálva
egy olyan dokumentumkezelő rendszert mutatott, amely az újonnan készített raktári jegyzékek bevitelét
támogatta elsősorban. A jegyzékek többszintűségének megjelenítésére kísérleti megoldás született, ezen kívül a
program a jogosultsági szintek beállításával segítette az ellenőrzés és a visszacsatolás munkafolyamatát.
Lehetőséget nyújtott a kész raktári jegyzékek publikussá tételéhez. A program keresőrendszere azonban még
kezdetleges volt, és a beviteli felület sem volt eléggé felhasználóbarát. Ezen kívül mind levéltári, mind
informatikai oldalról koncepcionális problémák is mutatkoztak, amelyekre az előadást követő vita mutatott rá.
Ennek a projektnek a tapasztalatait felhasználva 2012-ben újabb kísérleti program fejlesztéséhez fogtunk 5.

A raktári jegyzék adatbázis második verziója egy XML adatleíró nyelvre épülő rendszer, amely már az EAD-vel
való kompatibilitást is figyelembe veszi. A második rendszer megmutatta az új technológia lehetőségeit, és hogy
az elképzelés helyes, de nem volt alkalmas országos méretű rendszer kiépítésére. Az új intézményrendszer
kialakulása és az eddig nyert tapasztalatok arra vezettek minket, hogy egy újabb vizsgálatot kezdjünk. A további
fejlesztés során egy olyan adatmodell és koncepció létrehozása a cél, amelyet nyílt forráskódú, a hosszantartó

2 ISAD(G), második kiadás, 2000.; ISAAR (CPF), 2004.; ISDF, 2007.; ISDIAH, 2008.; http://www.archivportal.hu/id-600-
leveltari_szabvanyok.html; EAD, második kiadás, 2002. http://www.loc.gov/ead/
3
http://www.archivportal.hu/id-600-leveltari_szabvanyok.html
4Pintér Milán: Levéltári raktári jegyzék alkalmazás tervezése. Pannon Egyetem, Villamosmérnöki és Információs Rendszerek
Tanszék, Műszaki informatika szak. Diplomadolgozat. Veszprém, 2010.
5Kemenszki Gábor: Levéltári raktári jegyzék-kezelő rendszer fejlesztése. Pannon Egyetem, Villamosmérnöki és Információs
Rendszerek Tanszék, műszaki informatikus MSc. diplomadolgozat. Veszprém, 2012.

5
archiválást elősegítő technológiákkal hozunk létre. Alapvető követelmény a rugalmasság elvének megvalósítása,
egyrészt a bővítés lehetősége, másrészt a könnyű konvertálhatóság révén. Figyelmünk azért fordult a konkrét
adatbázis létrehozása helyett az adatmodell felé, mert az időközben a levéltárügyben zajló, az egységesülés
irányába mutató informatikai fejlesztések idején szigetszerű fejlesztésnek nincs értelme. Szándékaink szerint
javaslatunk alapot nyújthat egy országos méretű fejlesztéshez is, amennyiben a levéltáros szakma fantáziát lát
benne. Véleményünk szerint az általunk javasolt elképzelés alkalmazása a levéltárak becslésünk szerint százezres
nagyságrendű raktári jegyzék állományának optimális elektronikus megjelenítéséhez és adattartalmának legjobb
kiaknázásához vezethet el.

1.2 A TANULMÁNY FELÉPÍTÉ SE

Tanulmányunkban igyekszünk a raktári jegyzék elektronikus leírásának, feldolgozásának levéltár szakmai és

informatikai témaköreit érinteni. A 2. fejezetben először a raktári jegyzék megszületésének körülményeit, útját
követjük végig levéltártani források segítségével az 1950-es évektől napjainkig, közben a veszprémi gyakorlattal
illusztráljuk a változásokat. A 3. és 4. fejezetekben röviden érintjük a digitalizálás levéltári gyakorlatát és a
digitális adatok tárolási módjait. A célunk annak bemutatása, hogy a digitális – bináris – adat mennyire másképp
viselkedik, mint a papírra írt betű, információ. Az 5-7. fejezetekben az XML adatleíró nyelvet, az arra épülő
technológiákat mutatjuk be. Kitérünk az egyes technológiák alkalmazására, az XML adatok adatbázisban
tárolására is. Meggyőződésünk, hogy az XML technológia a legmegfelelőbb adatleírási forma a levéltárak
számára a rugalmassága, szabványossága és kiterjedt informatikai támogatása miatt. Az informatikai
ismereteket igyekszünk közérthető módon átadni, véleményünk szerint a konkrét javaslat megértéséhez
szükséges a levéltárosoktól talán kissé távolabb eső informatikai háttér megvilágítása is. A tanulmány záró
fejezetében a raktári jegyzék digitális, XML-alapú leírására szolgáló adatmodellt mutatjuk be, valamint
felvázoljuk egy olyan rendszer alapjait, amely a teljes raktári jegyzék feldolgozási munkafolyamat minden
szakaszát támogatni tudja.

2 A RAKTÁRI JEGYZÉK

Bízunk benne, hogy tanulmányunk interdiszciplináris jellege miatt nemcsak levéltárosok érdeklődésére tarthat
számot, hanem az informatika szakemberei is olvassák majd. Ezért mielőtt ismertetnénk a raktári jegyzék
létrejöttének történetét, néhány alapvető levéltári fogalom felvázolásával kezdjük ezt a fejezetet.

2.1 RENDSZEREZÉS ÉS SEGÉ DLETEK A LEVÉLTÁRAKBAN

A levéltári iratok rendszerezésének két fontos alapelve van, a proveniencia és a pertinencia elve. A
provenienciaelv az iratok keletkezésének körülményei alapján rendszerezi az iratokat, az azokat keletkezető
iratképzők szerint kialakított fondok rendszerében helyezi el a levéltári iratokat. A pertinenciaelv az iratokat
területi, tárgyi, időbeli vagy formai alapon csoportosítja. A magyarországi és az európai levéltári gyakorlatban a
proveniencia alapú rendszereké a vezető szerep. A fond a levéltári anyag legfontosabb alapegysége, amely alatt
egy iratképző szerv vagy személy iratainak (proveniencia alapon) létrejött összességét, vagy egy bizonyos
szempont alapján (pertinencia alapon) mesterségesen kialakított iratgyűjteményt értünk. A levéltárban őrzött
minden egyes irat valamilyen fondba tartozik. A fondok bizonyos szempontok alapján önálló jellegű egységekre,
állagokra tagolódhatnak, de ez nem szükségszerű. Egy levéltár iratanyaga nem csupán fondok
konglomerátumából áll, hanem a fondok hierarchikus rendszerben több szinten is csoportokba rendeződhetnek.
Ezek a felsőbb szintek fentről lefelé a következők: fondfőcsoport vagy szekció, fondcsoport (ezekből egymás alatt

6
több is elhelyezkedhet), fond, állagcsoport6, állag. A fondon és/vagy az állagon belül további szinteket szoktunk
kialakítani. Ezek lehetnek: fősorozat, sorozat, alsorozat, tétel (tárgyi egység, kútfő), ügyirat, ügyiratdarab.

A levéltárakban őrzött nagy mennyiségű iratállományban való tájékozódáshoz úgynevezett segédleteket

használunk. A segédletek egyrészt a levéltári iratanyag nyilvántartására, biztonságos megőrzésére szolgálnak,
másrészt a tájékoztató funkciót, valamint az iratok feltárását, kutathatóvá tételét segítik. Vannak olyan
segédletek, amelyek a levéltárba kerülést megelőzően készülnek az iratképző szervek napi munkája során,
ezeket ügyviteli segédleteknek nevezzük. Ilyenek például az iktatókönyvek, a lajstromkönyvek, a betűsoros
személynév-, helynév- és tárgymutatókönyvek. Az ügyviteli segédletek az iratanyaggal együtt kerülnek
levéltárba, majd a rendezési-feldolgozási munkák lezárulta után is a hozzájuk tartozó iratok mellett maradnak.
A levéltárban folyó feldolgozó munka során további segédletek jönnek létre, amelyeket összefoglalóan levéltári
segédleteknek nevezünk. A segédletkészítés a levéltári munkák közül az egyik legalapvetőbb és legfontosabb
tevékenység. A 20. század második felében a papíralapon készült segédleteknek külön rendszere alakult ki,
valamint különböző szempontok szerint csoportosították is őket, ezzel határozva meg jellemzőiket. Témánk
szempontjából a levéltári segédletek készítésének célja szerinti csoportosítás érdemel figyelmet. A biztonságos
megőrzést szolgáló nyilvántartási célú segédletek belső használatra készültek, a kutatók tájékoztatására készült
nyilvános segédleteket tájékoztatási segédleteknek nevezték el. Ez a felosztás az integrált elektronikus
rendszerek bevezetésének korában gyakorlatilag értelmetlenné válik. Az adatokhoz való hozzáférést az
interneten keresztül is elérhető levéltári adatbázisok jogosultságainak beállításával lehet szabályozni, így
manapság már nincs szükség külön nyilvántartási és tájékoztatási célú segédletekre. A levéltári segédletek
készítésekor követett módszerek szerinti osztályozás szerint a szintetikus segédletek összefoglaló adatokat, míg
az analitikus segédletek részletes ismertetést nyújtanak a leírt levéltári egységről. Lényeges szempont a
segédletek készítésekor, hogy milyen szintig tárjuk fel az iratanyagot. Eszerint beszélhetünk alapszintű,
középszintű és darabszintű segédletekről. A minősítés attól függ, hogy a segédletben milyen szintűnek minősülő
levéltári egységek kerülnek leírásra. A legismertebb alapszintű segédlet például a nagyközönség számára is
könnyen elérhető fond- és állagjegyzék, amely egy levéltár teljes anyagáról nyújt szintetikus áttekintést. További
alapszintű segédletek még az egy levéltár teljes anyagáról készített levéltári kalauz, levéltári útmutató vagy
levéltárismertető, az 1950-es években a fondok, állagok szintjén készített szintetikus jellegű alapleltárak vagy a
2000-es években nemzetközi minták után készülő fondismertetők. Középszintű segédletnek számít a
tanulmányunk középpontjában álló raktári jegyzék és a repertórium, miután ezek a fond, illetve állag alatti
szintek szintetikus módon történő, egységenkénti leírását valósítják meg. A darabszintű segédletek az egyes
iratok jegyzékelése, leírása alkalmával készülnek. Gyakrabban előforduló speciális darabjegyzék a lajstrom, a
különböző típusú mutatók, de idesoroljuk az analitikus módszerrel készülő regeszta műfaját is. A számítógép
használatának elterjedése új lehetőségeket nyitott a levéltárosok számára darabszintű leírások készítésére. Így
levéltárainkban leggyakrabban a darabszintű leírást igénylő iratanyagokhoz készülnek egyedi számítógépes
adatbázisok, amelyekben az egyes iratok digitalizált képéhez kapcsolódó metaadatokká transzformálódik a
korábbi papíralapú segédletek tartalma.

2.2 SEGÉDLETKÉSZÍTÉS A RAKTÁRI JEGYZÉK ELŐTT

A raktári jegyzék elnevezés alkalmazására Ember Győző az 1958-ban megjelent, a levéltári segédletek készítése
terén mérföldkőnek tekintett munkájában tett először javaslatot 7. A raktári jegyzék kialakulásának gyökereit az
1950-es évek elején megindult leltárazási munkafolyamatok környékén kell keresnünk. Ezt követően mintegy
két évtized alatt kristályosodtak ki e levéltári segédlettípus elméleti alapjai és a gyakorlati megvalósítás részletei.
A magyar levéltárakban őrzött iratállomány feltártságának mértéke a 2. világháború után sok kívánnivalót

6
Csak a Magyar Országos Levéltárban használt szint.
7Ember Győző: A levéltári segédletek. Magyar Országos Levéltár Kiadványai IV. Levéltár és Történeti Segédtudományok 1.
Akadémiai Kiadó, Budapest, 1958. 66–68.

7
hagyott maga után8. Elsősorban a történettudomány képviselői szorgalmazták a levéltárak országos szintű, teljes
körű állományfelvételét9. Az Országos Levéltárban évekig folyt az adatfelvételi metódus kialakítása. Ennek
eredményeként kezdték meg 1949 áprilisában az alapleltárak felállítását. A segédlettípus elnevezése már
magában hordozta a levéltárosok gondolkodásmódját a munkafolyamatról. A leltárazás, a leltárkészítés és a
segédlettípus szintje mai fogalmaink szerint alapszintű volt. 1950-ben a felálló Levéltárak Országos Központja
(LOK) a vidéki állami levéltárakban is az Országos Levéltárban alkalmazott alapleltárak felvételét tűzte ki célul.
Az alapleltár létrehozásának célkitűzéseiben a leltár jelleggel összhangban a hosszútávú megőrzés biztosítása és
a belső nyilvántartási jelleg dominált. A LOK tervei szerint az alapleltárazás megindítása után második körben
kellett elkészülnie egy olyan leíró típusú segédletnek, amely a kutatók tájékoztatását kellőképpen szolgálja. Ezt
a segédlettípust ismertető leltárnak nevezték el10. Egyébként az 1950-es évek első felében a levéltári segédletek
elnevezése, formája folyamatos átalakulásban volt, ezt jól mutatják a készítésükre vonatkozó tervezetek,
utasítások és a szakfolyóiratokban11 megjelent írások sora. Kezdetben még maga a segédlet fogalma is szűkebb
értelemben volt használatos, az eredeti, ügyviteli segédletekre használták a segédlet kifejezést. Csak később
jelölte összefoglalóan a különböző típusú levéltári (szintetikus és analitikus) jegyzékeket, ami a kialakulóban lévő,
új szakmai felfogásra utal.

A levéltári munka napi gyakorlata azonban arra ösztönözte a levéltárosokat, hogy az őrzött iratanyagról az
alapleltárak után és az ismertető leltárak mellett (előtt) olyan középszintű részletező leltár jellegű segédleteket
készítsenek maguknak, amelyeket a napi munkában a levéltári anyag kezelése, őrzése és a kutatók tájékoztatása
terén is felhasználhatnak. Leegyszerűsítve a levéltáros elemi érdeke volt, hogy tudja, hogy a keresett információt
hordozó iratot melyik csomóban, dobozban, kötetben stb. találja meg, és a lehető leggyorsabban elő is tudja
keresni azt. Makkai László, az MTA Történettudományi Intézetének neves történésze az Országos Levéltár
alapleltárainak értékelése kapcsán ezt írta: „A rakszámok, ill. egy-egy levéltári egység csomóinak vagy köteteinek
sorszámai vegyes tartalmú egységek … esetében a kutató számára eligazodást csak abban az esetben
nyújtanának, ha az alapleltárak az egyes csomók (kötetek) tartalmát és évkörét külön is feltüntetnék… Kívánatos
volna, hogy az ismertető leltárak ilyen különleges esetekben rakszám szerint részletezve közöljék az iratok
tartalmát és évkörét.”12 Az előbb vázolt kettős igény hatására – központi utasítás nélkül is – öntevékeny módon
különféle tétellajstromok, csomójegyzékek születtek 13. A LOK tudományos osztályán dolgozták ki a leírójegyzék
készítésére vonatkozó utasítás tervezetét, amelyet 1955-ben tártak a szakma elé14. Ezt a segédletfajtát
tájékoztatási célú, részletes leltárnak szánták. Az állagszintre vonatkoztatott leírójegyzék elnevezés mögött
megjelenő tartalom a csomójegyzékelés gyakorlatából kiindulva, a csomójegyzéket a konspektussal15
összevonva az első olyan formát mutatta, amely már egyértelmű rokonságot mutat a raktári jegyzékkel. A
tervezet az állagot alkotó raktári egységek darabonkénti felsorolását és leírását várta el. „Tárgyi tagolódású
iratanyag esetén a leírójegyzéket úgy kell elkészítenünk, hogy ebből az iratanyagnak mind tartalmi kifejtése,

8 Bár már 1942-ben döntés született az Országos Levéltárban, hogy a teljes iratállományról alapleltárakat és ismertető
leltárakat kell felvenni, a háborús helyzet alapvetőbb feladatot adott a levéltárosoknak, az iratanyag megőrzését, megóvását
a pusztulástól.
9 A két világháború közötti korszakban egy ilyen jellegű felmérést akadályozott a levéltári rendszer tagoltsága.

Amagánlevéltári státuszú családi, egyházi, vállalati levéltárak állami jellegű felmérése ellenállásba ütközhetett volna. Vö.:
Megyei és városi közlevéltáraink alapleltárairól. In: Levéltári Híradó, 2. (1952) 2. szám, 29.
10 Az ismertető leltár az alapleltártól két fontos elemben tér el: a leírt levéltári egység tárgyát részletesen írja le, valamint

közli a hivataltörténetet és a fondtörténetet.

11 A háború előtt indult Levéltári Közlemények több éves szünet után 1954-ben indult újra. 1951-ben indult a Levéltári Híradó,

amely 1961-től Levéltári Szemle néven jelent meg.

12 Makkai László: A levéltári alapleltár mint a tudományos kutatás segédeszköze : megjegyzések az Országos Levéltár eddig

megjelent alapleltárairól. In: Levéltári Híradó 3. (1953) 2-4. sz. 109–111.

13 Borsa Iván: A levéltári anyag hozzáférhetővé tételének néhány aktuális kérdése. In: Levéltári Híradó, 5. (1955) 3–4. szám

203.
14 Utasítás a leírójegyzék készítéséhez. Tervezet. 86401-17-1/1955 LOK MOL XIX-18-a (www.archivportal.arcanum.hu)
15 Konspektus: tájékoztatási célú, a legkisebb tárgyi egységek szintjén készült, szintetikus, belső használatra szánt levéltári

segédlet. A konspektustól a levéltári anyagra vonatkozóan csupán egyetlen adatot várunk: a levéltári címeket vagy jelzeteket.
Ember Győző: Levéltári terminológiai lexikon. Akadémiai Kiadó, Budapest, 1982. 195.

8
mind raktári elhelyezése valóban áttekinthető legyen. Az egyes raktári egységek tartalmának kifejtésén kívül az
egész állag általános tagolódását is fel kell tüntetnünk. … Az iratanyag tartalmának kifejtésében az egyes raktári
egységeknél /csomó, dosszié, stb./ nem szabad megállnunk, hanem az ezeken belüli tárgyi tagolódást is ki kell
fejtenünk, ha egy csomón belül több tárgyi kategória található.” Az ezt követő szakmai viták részletes kifejtése
szétfeszítené e dolgozat kereteit. Mégis mindenképpen érdemes külön megemlíteni – már csak elődünk iránti
tisztelet okán is – Takáts Endre16 hozzászólását. A vidéki levéltárak érdekeit képviselve kinyilvánította, hogy az
eddigi gyakorlat helyett, amely az alapleltárak készítését helyezte előtérbe, jobb lett volna a
csomójegyzékeléssel indítani az országos szintű leltárkészítő munkát. Rávilágított arra, hogy a levéltári
terminológiában így is van némi zavar, a leírójegyzék mint új fogalom és jegyzéktípus behozása ezt tovább erősíti.
Másrészt érdekes fordulattal azt javasolta, hogy az eddigi alapleltár továbbfejlesztésével alakuljon ki inkább a
közönségnek szánt ismertető leltár formája. Míg a csomóról csomóra haladó leírójegyzéket kereszteljék át
alapleltárrá, amely a nyilvántartási célokat szolgálná17.

1956-ban a Levéltári Híradóban jelent meg Balázs Péter, aki a LOK majd a Levéltári Igazgatóság tudományos
munkatársa volt ekkoriban, által jegyzett cikkben 18 a csomójegyzék és repertórium készítéséről szóló utasítás.
Ismét visszatért tehát a szakma a csomójegyzékhez, ugyanakkor bevezették a repertórium fogalmát is. A szerző
felhívta arra is a figyelmet, hogy mindkét jegyzéktípus önálló segédlet sorozatot képez, nem az alapleltárak
melléklete19. Voltaképpen szerkezetében a két segédlettípus között nem volt különbség. A tárgyilag nem tagolt
(pl. sorszámos, alapszámos, időrendben lévő) állagok esetében csomójegyzék készítését írták elő, a repertórium
a tárgyilag tagolt állagok (pl. egyes közigazgatási irattárak, főképpen családi és üzemi levéltárak) anyagának
leírására szolgált. A két jegyzéktípus pontokba szedett jellemzői között a különbség az állagot alkotó raktári
egységek felsorolása pontban mutatkozott meg. A repertórium az állag tárgyát és szerkezeti felépítését
tartalmazó áttekintő jegyzékek jellemzőit is magába foglalva az iratok tartalmának ismeretét is elvárta
készítőjétől, hiszen másképp nem volt lehetősége a tárgyilag tagolt iratanyag tárgyi kibontására. Míg a
csomójegyzékben elégséges a jelzetek (iktatószám, alapszám) rendjében kezelt iratoknak a raktári egységen
belüli legalacsonyabb és legmagasabb jelzetét és az évet megadni az iratok tárgyának meghatározása nélkül.

2.3 A RAKTÁRI JEGYZÉK ME GALAPOZÁSA

Az évtized végére eljutott oda a levéltáros szakma, hogy már egy komolyabb, a későbbi évekre nézve
iránymutató összefoglalás is születhessen a levéltári segédletekről. Ember Győző, az Országos Levéltár
főigazgatója az induló levéltártani és történeti segédtudományi kiadványsorozat első köteteként publikálta
1958-ban A levéltári segédletek című művét20. E munka első felében a szerző a segédletek rendszerének fő
jellemzőit általánosan ismerteti. Ezek közül témánk szempontjából két elem érdemel külön is említést. A
segédletek legfontosabb adatai közül a levéltári anyag címe és jelzete Ember Győzőnél nem válik el egymástól,
ezeket a szerző „és” illetve „vagy” jelleggel együttesen kezeli21. Ez a gyakorlat meg is gyökeresedett
Magyarországon, és nem is okozott problémát mindaddig, amíg a nemzetközi szabványok alkalmazása a 2000-
es években be nem gyűrűzött Magyarországra. Erre a kérdésre később a szabványok alkalmazhatóságának
tárgyalásakor vissza fogunk még térni. Ember Győző másik fontos megállapítása a raktári jelzettel volt
kapcsolatos. Leírása szerint korábban a raktári jelzet fogalmában szorosan összekapcsolódtak a raktárépület, a

16 Takáts Endre a cikk írásakor a Soproni Állami Levéltár vezetője volt, később a Veszprémi Állami (majd Megyei) Levéltár
igazgatója lett (1961), e tisztet nyugdíjazásáig (1973) töltötte be.
17
Takáts Endre: Hozzászólás a leírójegyzék készítésére vonatkozó utasítás-tervezethez. In: Levéltári Híradó 5. (1956) 3-4. sz.
278–284.
18 Balázs Péter: Csomójegyzék és repertórium készítésének szabályozása. In: Levéltári Híradó 6. (1956) 1. sz. 153–165.

19
Előfordult, hogy az alapleltárat bővítették ki a csomójegyzékkel, például „a győri levéltárban a Győri Törvényszék urbéri
és tagosítási iratainak alapleltára 26 oldal terjedelmű” írja, ami az áttekinthetőség rovására ment.
20 Ember Győző: A levéltári segédletek. Magyar Országos Levéltár Kiadványai IV. Levéltár és Történeti Segédtudományok 1.

Akadémiai Kiadó, Budapest, 1958.

21 A levéltári terminológiai lexikonban is így rögzült. pl. 14-105, 14-108, 14-109.

9
raktárterem, az állvány és a legkisebb raktári egység azonosító, jelölő elemei. Ugyanakkor a legkisebb egység, az
iratokat közvetlenül magába foglaló tárolóegységek, a raktári egységek jelzete nem egészen konzekvensen hol
a raktári, hol a nagyobb levéltári egységen belüli helyét jelezte egy-egy iratcsomónak, kötetnek22. Ezért a szerző
a raktári jelzetet kettéválasztva bevezette a helyrajzi (topográfiai) jelzet és az önálló raktári jelzet egymástól
elkülönülő fogalmait. Így a legkisebb raktári egységre szűkített raktári jelzet már nem az iratanyag
helymeghatározásához kötődött elsődlegesen, hanem sokkal inkább a levéltári anyag elvi tagozódásához
közelített. Megvolt a gyakorlati oka ennek a változtatásnak, hiszen az iratoknak egyik polcról a másik polcra,
egyik raktárból a másik raktárba való áthelyezésekor a helyváltozás nyilvántartása könnyebb volt úgy, ha a raktári
jelzet nem a pontos, fizikailag körülhatárolható raktári helyet jelöli. A raktári egység jelzete függetlenedett a
raktári helytől, könnyebben mobilizálhatóvá vált hát a levéltári anyag nyilvántartásának szempontjából is. Ez a
fogalmi elhatárolás a raktári jegyzék szerkezetére komoly hatással volt a későbbiekben azáltal, hogy a raktári
egységek jelzete az irategységek levéltárbeli helyét jelző levéltári jelzetekkel került közelebbi kapcsolatba. A mű
második részében Ember Győző sorra veszi a segédletek egyes típusait. Ezek között pedig már önálló műfajként
megtalálhatjuk a raktári jegyzéket is a közepes szintű levéltári segédletek sorában. A raktári jegyzék mellé ebbe
a csoportba még a konspektus és a repertórium került. A csomójegyzék raktári jegyzékre átkeresztelésének
legfőbb indoka az volt, hogy a csomójegyzék elnevezése egyértelműen az egyik típusú legkisebb raktári egységre
utal, ugyanakkor a csomójegyzék tartalmazhatja a többi típusú legkisebb raktári egységet is: köteteket,
dobozokat, tékákat. Ember Győző a raktári jegyzék elsődleges céljának a levéltári anyag biztonságos őrzését
tartotta, ezzel a nyilvántartási jellegű segédletek közé sorolta. A raktári egységekben elhelyezett iratok levéltári
jelzeteivel kapcsolatban megállapítja, hogy a raktári jegyzék szintetikus volta miatt nem kell feltüntetni a
jegyzékben a teljes mélységű levéltári jelzetet. Azaz elegendő a raktári egységben foglalt legkisebb és legnagyobb
jelzetet megadni, ha közte vannak hiányzó jelzetek, iratok, ezt a raktári jegyzék nem kell, hogy tartalmazza. Ez a
megoldás a későbbiekben teljes polgárjogot nyert, az 1971-es raktári jegyzék munkautasításban is ez köszön
vissza. Gyakorlati szempontból logikus megoldás volt, hátránya az esetleges félretájékoztatás mellett (azt
gondolhatja a kutató, hogy a számkontingensbe eső minden irat megtalálható az anyagban), hogy a raktári
egység–levéltári egység kapcsolatot tovább erősítette. A terjedelmi adatok megadására a később általánossá
váló két fajta számítási módot fogalmazta meg Ember Győző. Egyrészt az iratfolyóméterben mért terjedelmet
elégségesnek gondolta a nagyobb levéltári egységek (állag, fond) szintjén megadni. Emellett célszerűnek tartotta
a raktári egységek számát fajtánként is részletezni. A mű a raktári jegyzék formai kérdéseit nem taglalta azon túl,
hogy a jegyzék szerkezete a levéltári anyag tényleges rendszerével egyezzen meg, és ívformában készüljön.

A levéltári szakmai problémák hatékonyabb megoldására a LOK helyébe lépett Levéltári Osztály 1958-ban
létrehozta a Levéltári Módszertani Kollégiumot. A Módszertani Kollégium keretében 1960-tól működő
bizottságok egyike volt a segédletkészítési bizottság. A Wellmann Imre által vezetett bizottságnak fő feladata az
egységes rendszerű segédletek elkészítését elősegítő munkautasítások kidolgozása volt. A segédletkészítési
bizottság 1961-ben tette közzé tervezetét a levéltári leltár munkautasításáról23. Az újabb segédletnév-változat
mögött valójában a raktári jegyzék formai és tartalmi elemeinek részletes leírása rejlik. A rendezési munkák
eredményeképpen létrejövő segédletnek tekinti a levéltári leltárat, amelynek létrehozásához részletes
gyakorlati útmutatással is szolgál. A „raktári jegyzék” elsődleges feladata továbbra is az „hogy az iratanyag
számbavétele után annak épségben való megőrzését szolgálja”, de az utasítás már kiemeli azt is, hogy a tárgyilag
tagolódó fondok esetében ez a segédlet a kutatáshoz is segítséget nyújthat. Másrészről érzékelhetően tovább
erősödött a raktári egységekhez kötött jegyzékkészítési elv. „A leltár számbavételi egysége általában a raktári
egység. ... A leltár szerint általában lemegy az egyes raktári egységekig /csomókig, kötetekig stb./, de ennél
mélyebbre: raktári egységen /csomón stb./ belüli kisebb tárolási vagy tárgyi egységekig nem hatol.”

22 Ilyen példákat említ: 11. sz. raktárterem 1001. sz. raktári egysége; vagy: helytartótanácsi levéltár, helytartótanács
regisztratúrája 101. sz. raktári egysége.
23
A levéltári leltár munkautasításának tervezete. 1961. március 18. [A segédletkészítési bizottság nevében Wellmann Imre]
http://www.archivportal.arcanum.hu/korpusz/a100526.htm?v=pdf&a=pdfdata&id=3d67&pg=0&l=hun

10
Az 1960-as években a Veszprém Megyei Levéltárban Takáts Endre igazgatói működése alatt kezdődött meg a
raktári jegyzékek készítése, ezeken jól láthatóak az előző évtized szakmai vitái nyomán kialakult formai és
tartalmi jegyek. A fond- vagy állagszinten felvett jegyzékek a raktári egységek rendjében rögzítették a levéltári
egységek tartalmát, a tárgyilag nem tagolt sorozatok esetében a csomójegyzék mintájára történt az iratanyag
tárgyi ismertetés nélküli leírása, a tárgyilag tagolt sorozatok esetében a legkisebb tárgyi egységek címeinek
megadása a jellemző. A két leírási típus jegyzéktől függően külön-külön és együttesen is előfordul. Példánkban
a csajági körjegyzőség (MNL VeML V.321.) elnöki iratairól 1968-ban készült jegyzék egy tárgyilag nem tagolt
sorozatot mutat. Az 1966-ban a község iratairól készült jegyzék iktatott iratsorozattal indul, majd a II. sorozattól
már tárgyilag csoportosított levéltári egységek következnek.

1. ábra V.321. A csajági körjegyzőség iratainak raktári jegyzéke (készült 1966-ban és 1968-ban)

2.4 A RAKTÁRI JEGYZÉK SZ ÜLETÉSE

A levéltárügy 1968–1971 közötti reformja új jogszabályok 24 segítségével szabályozta újra a levéltári szervezeti
felépítést, a levéltári munka feltételrendszerét pedig minden eddiginél részletesebben határolták körül.
Természetesen ezek a folyamatok a segédletkészítés területén is érzékeltették hatásukat. A raktári jegyzék
jellemzői is ekkor rögzültek véglegesen.

Az 1971-ben kiadott Levéltárak Ügyviteli Szabályzata (LÜSZ) a levéltári anyagról felveendő nyilvántartások közé
sorolta a raktári jegyzéket.

„89. § (1) A levéltár fondonként raktári jegyzéken tartja nyilván az általa őrzött levéltári anyag
raktári egységeit (csomó, doboz, kötet stb.).
(2) A raktári jegyzék az egyes raktári egységeket
a) a fond szerkezetének megfelelő, a fondképző szervezetét, illetőleg funkcióit is tükröző
tagolásban és
b) e tagolásnak megfelelően kialakított levéltári egységek (állagok, sorozatok, tételek stb.)
ideális sorrendjében sorolja fel.
(3) A raktári jegyzék az egyes raktári egységekről a következő adatokat tartalmazza
a) a raktári egységek — a (2) bekezdésben említett sorrendnek megfelelő — száma;

24
A levéltári anyag védelméről és a levéltárakról szóló 1969. évi 27. számú törvényerejű rendelet.; a 30/1969. (IX.2.)
kormányrendelet a levéltári anyag védelméről és a levéltárakról szóló 1969. évi 27. számú törvényerejű rendelet
végrehajtásáról; a művelődésügyi miniszter 130/1971. sz. (M.K. 10.) MM számú utasítása a Levéltárak Ügyviteli Szabályzata
kiadásáról

11
 b) külön-külön az egyazon raktári egységbe esetleg összefogott valamennyi levéltári egység
(tétel stb.) címe;
c) a raktári egységbe foglalt levéltári egységek kezdő és záró jelzete, valamint — ha a jelzet
nem tartalmazza — a rájuk jellemző időadat.”
A lakonikus jogi megfogalmazásból láthatjuk, hogy a korábbi tendenciát folytatva itt is a raktári egységekre fűzik
fel a raktári jegyzék szerkezetét. A raktári egységek elsőbbsége látszik érvényesülni, dacára annak, hogy ekkor
már ismert volt Sashegyi Oszkár cikke a raktári jegyzékről, amelyben a raktári egységek és a levéltári egységek
párhuzamos, egyenrangú haladását mutatta be. Egy jogi szabályozásnak természetesen kellőképpen tömörnek
kell lennie, nem fér bele a részletek bemutatása, ugyanakkor így jobban kiütköznek a hangsúlyok is. A LÜSZ
raktári jegyzéke a raktári egységekben elhelyezett levéltári egységek leírásáról csupán annyit mond, az ideális
sorrendben kell őket felsorolni. Összességében túlságosan leegyszerűsítettnek tűnik a jogszabályban rögzített
leírás. Mintha a korábban több hivatkozott szakcikkben is bemutatott két különböző típusú iratsorozatnak a
különböző módon való jegyzékelési módja itt összemosódna. Csak az egyszerűbb szerkezetű, nem tárgyilag
rendezett iratok leírásának elemei köszönnek vissza: a levéltári egység címe, a raktári egységbe foglalt levéltári
egységek kezdő és záró jelzete, valamint kora. A tárgyilag tagolódó iratok konspektus jellegű leírása nem
fedezhető fel a LÜSZ szövegében. Furcsa még, hogy bár az ismertetett szakmai anyagok fond, illetve állag szintjén
„készíttetik” a raktári jegyzéket, a LÜSZ csak a fondonként készítendő raktári jegyzéket említi. A jogszabály
előnyére írandó, hogy a többszintű leírási módot viszont tartalmazza.

A szabályzat új fogalomként megemlíti még az ideiglenes raktári jegyzéket és a darabjegyzéket. Az ideiglenes

raktári jegyzéket a rendezettség alacsonyabb szintje különbözteti meg a raktári jegyzéktől. Szerkezete
hasonlatos, pusztán a tárgyi egységekről közölt adatok szegényesebbek a raktári jegyzékben előfordulóknál. A
darabjegyzék a legkisebb tárgyi egység alatti szint, az egyes ügyiratok leírására szolgál, adattartalma speciális,
igazodik az adott iratanyaghoz. Érdekes módon az áttekintő raktári jegyzék fogalma nem került bele a LÜSZ-be.

A segédletkészítési bizottság még a nagy jogszabályalkotást megelőzően befejezte működését, de a bizottság

egyik volt tagja, Sashegyi Oszkár 1970-ben a Levéltári Szemlében az áttekintő raktári jegyzék tervezetéről írt
cikket jelentetett meg25. Már a cikk címe is újdonságot hozott, az áttekintő jelzőt helyezte a raktári jegyzék elé.
Az áttekintő raktári jegyzék szintetikus, a legkisebb tárgyi egységeken belülre nem hatoló, középszintű segédlet,
amelynek rendeltetését a szerző kettősnek tekinti: nyilvántartó és tájékoztató is egyben. A raktári jegyzék
komplexitásának alapja a csomójegyzék (a szerző egyszerű raktári jegyzéknek hívja) és a konspektus
összeolvasztása. A korábbi tendenciát megtörve a jegyzék szerkezetében a konkordancia érvényesül a raktári
egységek és a levéltári egységek között, tehát a raktári jegyzéknek azt kell bemutatnia, hogy az iratanyag külső-
fizikai és belső-tartalmi tagolódása hogyan felel meg egymásnak. Ezzel Sashegyi Oszkár felfogása szerint a
levéltári egységek szerepe a jegyzék felépítésében minimálisan egy szintre kerül a raktári egységgel. Bár a raktári
egységek sorrendjében halad a jegyzék, de a törzsegység vertikális tagolódásának, tehát a levéltári anyag
többszintűségének26 a megjelenítésével végül a levéltári egységek leírására helyeződik át a hangsúly. Az
áttekintő jellegét elsődlegesen a törzsegység általános, szöveges ismertetése adja, amely más, a magasabb
szintű levéltári egységre vonatkozó adatokkal együtt a raktári jegyzék elejére került, ezeket Sashegyi Oszkár
általános adatoknak nevezte el. A tulajdonképpeni jegyzékrész a speciális adatok elnevezést kapta, miután ezek
az adatok csupán az egyes legkisebb raktári vagy tárgyi egységekre vonatkoznak, azokra egyedileg, speciálisan
jellemző adatok.

25
Sashegyi Oszkár: Az áttekintő raktári jegyzék. In: Levéltári Szemle 20 (1970) 2. szám, 262–273.
26
A többszintűség abból ered, hogy a raktári jegyzék fond, vagy állagos fond esetén állag szintjén készül. Tehát az állagon
belül található sorozatok, alsorozatok, tételek egymáshoz való viszonyulásának bemutatása eredményezi egyes
jegyzékekben a többszintű megjelenést.

12
Egy év múlva Sashegyi Oszkár írását a Levéltári Igazgatóság szinte változatlan szöveggel mint raktári jegyzék
munkautasítást adta ki (1971). Tehát az előbbiekben az áttekintő raktári jegyzékről leírtak érvényesek a
munkautasításban közreadott raktári jegyzékre is. Arra a munkautasításra, amely a LÜSZ-szel gyakorlatilag
egyidőben jelent meg. Roppant érdekes azonban, noha azt azért nem mondhatjuk, hogy a LÜSZ-ben
megfogalmazott raktári jegyzék és a munkautasítás raktári jegyzéke gyökeres ellentéte lenne egymásnak, de
mégis érezhető bennük a hangsúlyeltolódás27. A raktári jegyzék munkautasításban kiemelten fontos jellemzőnek
tekintett áttekintő jelleg a LÜSZ-ből teljes egészében hiányzik. A munkautasítás pontosan megfogalmazta, hogy
a később fondismertetőnek is nevezett bevezető szövegben mire kell kitérni. Le kell írni a fond (és állag)
anyagának keletkezését (a fondképzőre, a fond és állag kialakítására vonatkozó fő tudnivalókat), a fond (és állag)
tárgyát, szerkezetét, rendszerét, kutatási lehetőségeit, az anyag rendezettségére és selejtezettségére vonatkozó
adatokat, a jelentősebb hiányokat, az anyag levéltárba kerülésének módját. Megjegyzendő, a korábbi gyakorlat
szerint ezeket az adatokat az alapleltár tartalmazta.

A raktári jegyzékben foglalt adatok részben olyanok, amelyek nagyobb egységekre vonatkoznak, részben
olyanok, amelyek a legkisebb raktári, illetőleg tárgyi egységekre jellemzők. A nagyobb egységek, a fond vagy az
állag (attól függően, hogy melyik szinten történik a jegyzékelés) adatai összefoglalóan az általános adatok. A
legkisebb raktári, illetve levéltári egységek adatai a speciális adatok.

Általános adatok:

1. A fond, illetve állag törzsszáma

2. A fond, illetve állag címe

3. A fond, illetve állag kora

4. A fond, illetve állag terjedelme

5. A fond (és állag) általános ismertetése

6. A fond, illetve állag nagyobb levéltári egységekre tagolódásának feltüntetése

7. A fond, illetve állag raktári helye

Speciális adatok:

1. A raktári szám

2. A raktári egység tárolási módja

3. A tárgyi egység címe

27 Véleményem szerint a két alapdokumentumban megmutatkozó különbség azért nem volt szerencsés, mert esélyt
teremtett arra, hogy ezután a levéltári dolgozók által készített jegyzékek eltérő szerkezetű és minőségű raktári jegyzékekként
jelenjenek meg. Mindez csupán attól függött, hogy ki melyik alapdokumentumhoz ragaszkodott inkább, vagy melyikkel
találkozott egyáltalán. Feltételezhető, hogy a kezdeti években ez a probléma még nem jelentkezett, hiszen egy friss
szabályozásnak kell néhány év, amíg meggyökeresedik, majd mintegy 15-20 évig mindenképpen élő is maradhat. De 30-40
évvel a bevezetés után (a 2000-es évek elején) sem történt semmilyen megújítás, pedig a levéltári környezet addigra
jelentősen megváltozott. Megújítás nélkül már nem olyan evidens, hogy mihez fognak nyúlni mintaként a jelenkor
levéltárosai. Elég csak az interneten ma már szép számmal elérhető raktári jegyzékek között tallózni, hogy ezt
megállapíthassuk. Egyre több helyen találkozni magának a segédlettípusnak a helytelen megnevezésével is: raktárjegyzék
(sic!). Talán Ember Győző nem véletlenül tette hozzá az “i” képzőt. Raktárjegyzék: raktárak jegyzéke, raktári jegyzék: a
raktárban (raktári egységekben) elhelyezett iratok jegyzéke. Egy személyes megjegyzés még ehhez a gondolathoz: bizony, ha
a levéltárba kerülésemkor (1997-ben) nem kapok Somfai Balázs kollégámtól egy többször fénymásolt, elmosódott
stencilezett példányt a munkautasításból, magam aligha találtam volna rá, valahogy még utóbb a szakirodalom is érdekes
módon eléggé megfeledkezett erről a szabályozásról.

13
 4. A tárgyi egység kora

5. A legkisebb raktári egységbe foglalt iratok levéltári jelzetei

Ismét levéltárunkból hozunk egy 1976-ban készült példát, amely megmutatja, hogyan tükrözhető a raktári
egységek és a levéltári egységek konkordanciája.

2. ábra IV.1.f A nemesi felkelés iratainak raktári jegyzéke (készült 1976-ban)

2.5 A RAKTÁRI JEGYZÉK UT ÓÉLETE

Ettől kezdve jelentős változás a raktári jegyzék szerkezetében nem történt. Az 1970-es évek közepén még a
repertórium körül élénkült fel a szakmai aktivitás28. Végeredményben a repertórium nem sokban különbözik egy
jól megírt áttekintő raktári jegyzéktől, illetve többnyire egy kisebb-nagyobb fondcsoport fondjainak egybefűzött
áttekintő raktári jegyzékeitől. Miután kiadásra szánták, tehát a tájékozató jellege dominál, a fondtörténeti
bevezető tartalmi elemeinek pontosabb kidolgozása jellemzi 29. Viszont a raktári jegyzék speciális adatai
helyenként csökkentett adattartalommal jelennek meg, az egyes raktári egységek nem kerülnek mind
felsorolásra, hanem az azonos tárgyi egységhez tartozó és azonos típusú iratok adatait összevontan adják meg
évkörrel és a raktári egységek típusonkénti számával.

Ember Győző 1982-ben kiadott fő művében30 a témánkhoz kapcsolódó lexikonbeli címszavak alatt a raktári
jegyzék addigra már rögzült formájának és adattartalmának jellegzetességeit a rá jellemző kiérlelt, precíz
megfogalmazással közölte. A Veszprém Megyei Levéltárban az 1970-es, 1980-as években klasszikus formátumú,
írógépen gépelt raktári jegyzékek születtek az 1971-es munkautasítás szellemében.

28
A tanácsi levéltárak anyagáról készülő leltárak [repertórium]. Melléklet: minta. Tervezet. (1975.09.22-1975.09.24-i
hajdúszoboszlói igazgatói értekezlet 2. napirendi pont); Szempontok a tanácsi levéltárak középszintű leltárának
[repertóriumának] elkészítéséhez 27.002/1976 IX. LIG
29Szempontok a tanácsi levéltárak középszintű leltárának [repertóriumának] elkészítéséhez. 27.002/1976 IX. LIG 2-3.; Lásd
még a repertóriumról: Útmutató az Új Magyar Központi Levéltár repertóriumainak készítéséhez (összeállította: Szőcs
Sebestyén), ÚMKL, Budapest, 1986. Levéltári módszertani füzetek 5.
30Ember Győző: Levéltári terminológiai lexikon. Akadémiai Kiadó, Budapest, 1982. A Magyar Országos Levéltár Kiadványai
IV. Levéltártan és történeti forrástudományok 4.

14
 3. ábra Részlet a ciszter rend zirci hittudományi főiskolája iratainak raktári jegyzékéből (készült 1985-ben)

A példaként felhozott jegyzékben láthatunk a 2. tételhez kapcsolva egy olyan elemet, amelyet Ember Győző a
talányos „benne-észrevétel” kifejezéssel nevezett meg. Végülis a tétel címében megfogalmazott
tárgymeghatározáshoz (tanári tanácskozások jegyzőkönyve) fűzött kiegészítésről van szó, amely valamilyen
különleges érdekességű vagy jelentőségű tudnivalót (az apácák személyi adatairól szóló feljegyzés is
megtalálhatók a tételben) közöl. Ez a megjegyzés azért érdemel figyelmet, mert a későbbiekben az elektronikus
raktári jegyzékben valahol el kell helyeznünk az ilyen típusú tartalmi információkat, ha nem akarjuk, hogy az
elektronikus jegyzékünk alacsonyabb információtartalommal bírjon a papíralapúnál. Azért problematikus
rendszertanilag ez az elem, mert az az iratszint, amelyre vonatkozik, a tételen (a legkisebb tárgyi egységen)
belül/alatta van, tehát a raktári jegyzékben már nem kerül általános jelleggel, minden egyes tételnél leírásra. A
tétel alatt lévő (nevezhetjük ügyiratszintnek, bár ez a fogalom a konkrét példánkra nem egészen jó megnevezés)
szintről a raktári jegyzékek sokszor elszórt, töredékes, de mégis fontos és megőrzendő információkat közölnek.
Ehhez még hozzátehető, hogy a raktári jegyzékek a napi használat során nem egyszer önálló életre keltek, a
levéltárosok a kereséseik, kutatásaik alkalmával megszerzett információmorzsákat szívesen jegyezték rá kézzel
a gépelt jegyzékekre, hogy ezzel segítsék a legközelebbi keresést. És ha még hozzátesszük, hogy egy jegyzéknek
több gépelt példánya is forgalomban lehetett különböző rájegyzésekkel, akkor látható, hogy a jegyzékek
elektronizálása előtt a raktári jegyzék letisztázását is érdemes bevennünk a tervezett munkafolyamatba.

4. ábra VIII.1. A ciszter rend zirci hittudományi főiskolája iratainak raktári jegyzéke (készült 1985-ben)

15
2.6 A RAKTÁRI JEGYZÉK DI GITÁLIS ALAKVÁLTOZÁS A

A rendszerváltozást követően előbb az új levéltári törvény, majd annak 1995-ben történt megjelenését
követően a hozzátartozó végrehajtási rendelet kidolgozása foglalta le a levéltáros szakmát, hogy a kárpótlási
törvény hatására a levéltárakat elöntő ügyféláradat szakmai munkát hátráltató hatásairól ne is beszéljünk. A
levéltári rendezőszobák csendjében persze folytatódott a raktári jegyzékek készítése a megszokott módon. Aztán
vidéken jobbára az 1990-es évek közepétől már megjelentek a számítógépen, Word szövegszerkesztő
programmal készített raktári jegyzékek is. Veszprémben az 1992, 1993 körüli évek jegyzékei közül néhány került
először elektronizálásra. A forma a klasszikus gépelt raktári jegyzékek vonalát követi, mind tartalmában mind
formai jegyeiben a klasszikus raktári jegyzéket próbáltuk lemásolni. A számítógépet voltaképpen ekkor még csak
elektronikus írógépként elektronikus szövegírásra használtuk. A begépelés, szövegszerkesztés és megjelenítés
után a jegyzéket kinyomtattuk, és papíralapon került használatba, ez biztosította egyúttal a hitelességet is. Az
elektronikus változat megőrzése annyiból volt érdekes, hogy hasonló fondokról, állagokról egyszerűbb volt
átmásolás és módosítás útján új jegyzékeket előállítani. Az archiválást még nem tartották fontosnak a levéltár
vezetői. Ezt a felfogást támasztja alá, hogy ebből a korszakból nem maradt ránk egyetlen jegyzék elektronikus
változata sem, nem volt igazán fontos a fájlok megőrzése, konvertálása.

Tanulmányunkban nem törekszünk, nem törekedhetünk országos helyzetkép felvázolására, de némi kitekintést
azért illik tennünk, hogy a képet némiképp teljesebbé tegyük. A fővárosban természetesen más lehetőségek,
technikai és szakmai feltételek mellett dolgoztak ekkortájt a levéltáros kollégák. Nem véletlen, hogy Budapest
Főváros Levéltárában kezdtek el először alaposabban foglalkozni az ISAD(G) nemzetközi levéltári leíró
szabvánnyal. Egy hat fős team az 1990-es évek végén elvégezte az ISAD(G) magyarítását, továbbfejlesztését is.
Az ebből készült szerkesztési utasítás alapján 1999-től a fővárosi levéltár munkatársai fondismertetők készítését
kezdték meg. A fondismertetőket az áttekintő raktári jegyzék fondtörténeti bevezető tanulmányának egyfajta
átstrukturált változataként fogták fel. A BFL-ben már akkor arra a következtetésre jutottak, hogy ezt az új típusú
segédletet egy átfogó számítógépes nyilvántartó program részeként lehet a legjobban a nyilvántartás és a
tájékoztatás céljaira egyaránt felhasználni31. Meg is kezdték a megvalósítást a Registrum számítógépes program
létrehozásával32. A BFL-ben kialakított elképzelés szerint az ISAD(G) alapú fond- és állagszintű leírások alatt
továbbra is a „hagyományos” raktári jegyzék biztosította a részletes feltárást. A fond- és állagszint leírása és az
ügyiratszinten releváns adatok szabványos adatbázisba rendezése mellett a kettő között elhelyezkedő raktári
jegyzékek rögzítése szabványosítás nélkül történt meg a Registrumot kiegészítő raktári jegyzék programban.
Egyszerű adatbevitelt végezve, a papíralapú jegyzékek szerkezetét másolták le, mint ahogyan a
szövegszerkesztővel készült raktári jegyzékek esetében is történt33.

A raktári jegyzék a közlevéltárak és a nyilvános magánlevéltárak tevékenységével összefüggő szakmai

követelményekről szóló 10/2002. (IV.13.) NKÖM rendeletben továbbra is a levéltári anyagról vezetett
nyilvántartások között szerepel. Ekkor rögzítették először jogszabályban az áttekintő raktári jegyzék fogalmát és
jellemzőit. Valamint a korábbról már ismertetett adattartalmú raktári jegyzék és az ideiglenes raktári jegyzék
került be a rendeletbe. Egyetlen adatelem kopott ki az idők során az általános adatok közül, ez volt a raktári hely
(épület, raktár, polc) megjelölése34. Nem véletlenül történt így, hiszen a praktikusabb raktári topográfia külön

31 A levéltáros berkekben a segédletekkel kapcsolatos új felfogás terjedését mutatja: Cseh Gergő

Bendegúz–Körmendy Lajos–
Németh István–Rádi Péter–Reisz T. Csaba: A levéltárak helye az információs társadalomban, a levéltári anyag informatikai
feldolgozása. In: Levéltári Szemle 51 (2001) 1. sz. 13.
32Szegőfi Anna: Fondismertető (fondtörténeti bevezető) tanulmányok készítése a BFL-ben. In: Levéltári Szemle 53 (2003) 3.
szám 22–46.
33
Sipos András főosztályvezető (Budapest Főváros Levéltára) szíves közlése.
34A megrendezett, elvileg végleges állapotú levéltári egységeket tartalmazó raktári jegyzék leggyakrabban változó eleme a
raktári elhelyezés lehet, ami nem kedvez a jegyzék kezelésének, hiszen elvileg újra kellett volna gépelni változás esetén, ami

16
nyilvántartási segédlettípusként egyre több levéltárban tűnt fel, és egyre inkább elektronikus formában. A
rendelet kimondja azt is, hogy „az áttekintő raktári jegyzék, a raktári jegyzék, az ideiglenes raktári jegyzék egy,
a készítő aláírásával hitelesített példányát a fonddossziéban kell elhelyezni”. Visszautalva itt az előbbi gondolatra
a számítógép-írógép párhuzamról, ez a rendelkezés megerősítette azt a felfogást, hogy a raktári jegyzékeknek
elég a képét a számítógépen reprodukálni, legalábbis – úgy vélem – nem ösztönözte arra a levéltárosokat, hogy
a számítástechnika adta lehetőségeket jobban kihasználják. Természetesen a realitásokról sem szabad
megfeledkeznünk, a levéltárak többségének számítógépparkjai – különösen vidéken – még nagyon alacsony
színvonalon álltak, sem a technikai sem a személyi feltételek (informatikus alkalmazása, levéltárosok
számítástechnikai ismeretei) nem tették lehetővé a raktári jegyzékek adatbázisba szervezésén való
gondolkodást35.

A Veszprém Megyei Levéltár számára óriási lépést jelentett, hogy 2005 végén egy állami támogatással felújított
épületbe költözhetett. A beruházás egyik legnagyobb eredménye volt, hogy egy korszerű számítógépes
hálózatot kaptunk. Minden kolléga asztalára saját személyi számítógép került új távlatokat nyitva a levéltári
munkában. Veszprémben 2007–2008 táján merült fel az igény az elektronikusan előállított raktári jegyzék házi
reformjára. A dilemmánk az volt, hogy adatbázist építsünk vagy a Microsoft Office irodai programcsomagban
általánosan elérhető, és egyre inkább általunk is használatba vett Excel programra alapozzunk. Úgy láttuk, hogy
nincs reális lehetőség egy igazán jó adatbázis belátható időn belüli létrehozására. Kockázatos raktári
jegyzékeinket olyan rendszerbe bedolgozni, amelynek nem belátható a hosszú távú működtetése. Ugyanakkor
bíztunk abban, hogy az időközben bevezetett E-Archivum egységes nyilvántartó programot fejleszteni fogják, és
alkalmassá válik a raktári jegyzékek kezelésére is36. Így az Excel alkalmazása mellett döntöttünk, mondván, abból
lehet a későbbiekben adatbázist is szervezni, vagy legalábbis jó eséllyel megoldható az adatok konvertálása,
áttöltése. 2008 végétől a levéltárunk szisztematikusan hozzákezdett a raktári jegyzékek MS Office Excel-
formátumban való rögzítéséhez. Ehhez a munkához egyedi mintajegyzék-űrlap kialakítására került sor. Az évek
során az alap-űrlapból számos újabb űrlap készült a különböző összetételű iratanyagok raktári jegyzék-típusai
számára. Az iratanyag középszintű leírása mellett a darabszintű jegyzékek, lajstromok készítéséhez is hoztunk
létre sablonokat. Az Excel-program lehetőséget kínált arra, egyszersmind meg is követelte, hogy a régi, gépelt
mintájú raktári jegyzékek formáját megreformáljuk. Ez a reform azonban csak addig ment el, hogy a
kereshetőséget szűréssel optimálisan biztosíthassuk, ugyanakkor megtartottuk azokat a jellemzőket, amelyeket
hagyományosan követtünk, illetve a jogszabályok előírnak. Ügyeltünk például a többszintű hierarchiát tükröző
jegyzéktípus megtartására, s könnyen nyomtatható jegyzék-űrlapok készültek, hogy a fonddossziékban is
szabályosan elhelyezhető legyen a raktári jegyzékek aláírt első példánya. Metódusunk nagy hátránya, hogy a
raktári jegyzékek gazdag adattartalmának kiaknázása nem lehetséges a különálló fájlok halmazában, közös
keresésre nincs lehetőség. A következő példán megmutatjuk milyen alakváltozáson ment át levéltárunkban a
raktári jegyzék.

a számítógép nélküli korszakban mindenképpen problémás volt. A veszprémi jegyzékeken is érzékelhetően elmaradt az idők
során a raktári hely megjelölése.
35Vö.: Künstler Ferenc: A levéltárak középtávú informatikai stratégiája és feladatterve, 2006–2010. Levéltári Szemle 55.
(2005) 4. szám, 4-5.
36
Ugyan az E-archivum fejlesztése elkészült 2010 végére, azonban olyan korlátokkal bírt, hogy a Veszprém Megyei Levéltár
többszintű raktári jegyzékeinek betöltésére esély sem volt.

17
V.142.f Veszprém Város Tanácsának adóügyi iratainak raktári jegyzékei

5. ábra a) Az eredeti gépelt jegyzék 1979-ből b) Az Excel-mintába gépelt változat kinyomtatott verziója

Veszprém Megyei Levéltár

V.142.f
VESZPRÉM VÁROS TANÁCSÁNAK IRATAI
Adóügyi iratok
1850–1870

Terjedelem: 4 doboz 0,52 ifm irat Összesen: 0,52 ifm

rakt. e. sorszáma

tárgyi egység-cs.
rakt. e. típusa

tételszám

tárgyi egység címe tárgyi alegység címe tárgyi egység kora megjegyzés Fő tárgyi egység-csoport címe Tárgyi egység-csoport címe

aa. Adóalap-összeírások és nyilvántartások

1 doboz 1 Adóalap-összeírás 1850 aa. Adóalap-összeírások és nyilvántartások

1 doboz 1 Adóalap-összeírás 1851 aa. Adóalap-összeírások és nyilvántartások
1 doboz 2 Birtokváltozások betűrendes jegyzékei 1854–1861 aa. Adóalap-összeírások és nyilvántartások
1 doboz 3 Birtokváltozások naplója 1856 aa. Adóalap-összeírások és nyilvántartások
1 doboz 4 Birtokváltozások nyilvántartó lajstromai 1855 aa. Adóalap-összeírások és nyilvántartások
1 doboz 4 Birtokváltozások nyilvántartó lajstromai 1856 aa. Adóalap-összeírások és nyilvántartások
1 doboz 5 Adókötelesek betűrendes névsora é.n. aa. Adóalap-összeírások és nyilvántartások

bb. Adókivetési- és beszedési lajstromok

1 doboz 1 Személyes kereseti, ház-, föld-, legeltetési és jövedelemadó 1851 bb. Adókivetési- és beszedési lajstromok
lajstromok
1 doboz 1 Személyes kereseti, ház-, föld-, legeltetési és jövedelemadó 1854 bb. Adókivetési- és beszedési lajstromok
lajstromok
1 doboz 1 Személyes kereseti, ház-, föld-, legeltetési és jövedelemadó 1862 bb. Adókivetési- és beszedési lajstromok
lajstromok
1 doboz 2 Személyes kereseti adólajstromok 1851 bb. Adókivetési- és beszedési lajstromok
1 doboz 2 Személyes kereseti adólajstromok 1852 bb. Adókivetési- és beszedési lajstromok
1 doboz 2 Személyes kereseti adólajstromok 1864 bb. Adókivetési- és beszedési lajstromok
1 doboz 3 Földadó lajstromok 1863 bb. Adókivetési- és beszedési lajstromok
1 doboz 4 Jövedelemadó bevételi (incassationalis) lajstroma 1853 bb. Adókivetési- és beszedési lajstromok
1 doboz 4 Jövedelemadó bevételi (incassationalis) lajstroma 1854 bb. Adókivetési- és beszedési lajstromok

6. ábra Az Excel-mintába átírt változat 2012-ből

18
Ezzel párhuzamosan kialakult a raktári jegyzék készítési munkafolyamat elektronikus leképezése is a levéltári
hálózatunkon. A kialakult szisztémát az elektronikus ügyiratkezelésre való átállás kezdeti lépéseként is
felfoghatjuk. A levéltári iratanyagok rendezése során elkészített raktári jegyzéknek különböző munkafázisokon
kell átmennie, míg végül véglegessé válik. A készítő által késznek tekintett jegyzék leadása a hálózaton kialakított
mapparendszerben, az átmeneti mappákban való elhelyezéssel történik. Először a leadott jegyzéket
nyilvántartásba vesszük egy nyilvántartó Excel-fájlban, amelyben feltüntetjük a jegyzék legfontosabb adatait.
Többek között a jegyzékben megtalálható általános adatok is bekerülnek a nyilvántartásba (nyilvánvaló a
redundancia!). Az átmeneti tárhelyen zajlik az ellenőrzés, amelyre formai és tartalmi szempontból is szükség
van. Hibák esetén az ellenőrzést végző vezető javításra küldi vissza a jegyzéket a készítőnek, illetőleg az
ideiglenes mappában a készítő is hozzáfér a jegyzékhez, javítani tud az e-mailben megkapott értesítés után.
Sajnos, ebben a rendszerben nem akadályozható meg, hogy bármely jegyzéket készítő levéltári dolgozó
hozzáférjen az ellenőrzés alatt lévő jegyzékhez, ami biztonsági kockázatot rejt magában. A hálózatban a
jogosultsági szintek csak mappaszinten állíthatók be. A javítás elvégzése után a készítő visszajelez, az ellenőrzést
végző pedig engedélyezi a nyomtatást. (Addig nyilván nem célszerű kinyomtatni a jegyzéket, amíg nem kerülnek
javításra a hibák.) Amennyiben rendelkezésre áll a levéltárban egy olyan számítógépes hálózat, amelyet minden
kolléga elér, a jegyzékekhez való elektronikus hozzáférés nem okozhat gondot. A kinyomtatott jegyzék a
jogszabályi előírások szerint aláírás után bekerül a fonddossziéba, illetve a kutatószolgálati sorozatban is
elhelyezzük. (Ezt a papíralapú jegyzéksorozatot használják a levéltár munkatársai a kutatók tájékoztatása mellett
minden más kereséskor is.) Ugyanakkor a számítógépes hálózaton egy, az érvényes jegyzékeket tartalmazó külön
mapparendszerbe kerülnek át a véglegesített jegyzékek. Itt a hozzáférés mindenki számára (kivéve a rendszer
kezelőjét) csak olvasást tesz lehetővé, ez biztosítja a raktári jegyzékek hitelességét és biztonságát. Ennek a
rendszernek a működtetése a tapasztalat szerint sok manuális munkával jár, ezért egy teljes dokumentumkezelő
rendszerre is igény támadt 2009 táján37. Elképzelésünk az volt, hogy amennyiben olyan adatbázist hozunk létre,
amely képes kezelni a leírt munkafázisokat és a nyilvántartást is, egyszerűbbé és gördülékenyebbé válik a
munkafolyamat, kiküszöbölhetők a sérülékenységi pontok, valamint magasabb szinten érvényesíthető a
minőség biztosítása is. Az adatbázisba szervezés előnye még, hogy egy ilyen rendszer a hosszú távú megőrzésről
és a hitelességről is megfelelőképpen képes gondoskodni.

A raktári jegyzék történetét végül a legfrissebb országos fejleményekkel zárjuk. Ahogy a bevezetőben már
utaltunk rá, a raktári jegyzékkel kapcsolatos legújabb változást a 2008 óta tartó e-levéltár projekt felgyorsulása
hozta. A jövőben a Magyar Nemzeti Levéltár, azaz a Magyar Országos Levéltár és a tagintézmények, a volt megyei
levéltárak, valamint Budapest Főváros Levéltára, tehát a magyar levéltári rendszer jelentős hányada a Scope
Archiv rendszerben fogja kezelni a levéltári anyagra vonatkozó alapvető adatait. Az adatbázisban vezetett
nyilvántartások, mint a törzskönyvi nyilvántartás, a raktári topográfia, az állományváltozási naplók és a raktári
nyilvántartás integrált rendszerben fognak együttműködni. A kialakuló elektronikus környezet szükségessé tette,
hogy a jogszabályi környezet is ehhez igazodjon. 2013-ban a Levéltári Kollégium létrehozott egy szakmai
bizottságot a levéltári szakmai követelményrendszert meghatározó 10/2002. NKÖM rendelet módosítására. A
bizottság javaslatában a raktári jegyzékből raktári nyilvántartás lett. Adattartalma azonban nem változik. A
névváltozás mögött a levéltárelméleti felfogás változása áll. A nemzetközi levéltári leíró szabvány által képviselt
segédletfelfogásnak a raktári jegyzék annyiban nem felel meg, hogy a raktári egységek nem lehetnek a leírás
alapegységei. Ugyanakkor a levéltári anyag nyilvántartására a raktári jegyzék szerkezete a továbbiakban is
alkalmas. Nem is képzelhető el, hogy rövidtávon a raktári jegyzék kiváltható lenne nemcsak a nyilvántartás, de
még a tájékoztatás terén sem. Bár ez utóbbi előbb-utóbb remélhetőleg megvalósul a levéltári leírás magyar
szabványának kiadásával38 és elterjedésével.

37
A Pannon Egyetemmel a raktári jegyzék dokumentumkezelő-rendszer ügyében való együttműködésünket a bevezetőben
már taglaltuk.
38
A Levéltári Szabványügyi Bizottság 2012 novemberében elkészült az általános levéltári leíró szabvány első változatával.

19
3 A DIGITALIZÁLÁS ELŐNYEI ÉS HÁTRÁNYAI A LEVÉLTÁRI GYAKORLATBAN

A digitalizálás mára már megkerülhetetlen feladat a magyar levéltárakban is. A 2000-es évek elejéhez viszonyítva
az elmúlt években már szinte nem maradt olyan levéltár, amely ne kapcsolódott volna be a digitalizálási
folyamatba39. Ez a fejezet a digitalizálás informatikai vonzatait járja körül a digitalizálás előnyeinek, hátrányainak,
és korlátainak bemutatása céljából40.

A digitalizálás fogalom alatt azt a tevékenységet, folyamatot értjük, amikor egy számítógépben tárolásra-
feldolgozásra alkalmatlan formából a számítógép számára érthető, feldolgozható formátumot hozunk létre.
Egyszerűen fogalmazva, egy ún. „analóg” technológiával készült, papírra írt dokumentumot, rajzot, képet
számítógépben tárolható számsorozattá, digitális formátumúvá alakítunk. A levéltári állomány méretéből
következően, a levéltári gyakorlatban tipikusan tömeges digitalizálásról beszélünk, tehát nem egy-egy
dokumentum átalakításáról, hanem dokumentumok tíz- és százezreinek feldolgozásáról. Ilyen mennyiségű
anyag digitalizálása már ipari méretű folyamatnak tekinthető, ami alapos mérlegelést és tervezést igényel a
megvalósítás előtt41.

A digitalizálás alapértelmezetten a tartalom leírásával nem foglalkozik, csak digitális másolatot eredményez. A
digitalizálás szó szerinti értelmezése alapján tehát az iratok szöveges átírása számítógépen nem tartozik a
digitalizálás témaköre alá. Tanulmányunk célja alapvetően a hazai levéltárak működésében fontos raktári
jegyzékek elektronikus kezelésének vizsgálata. Ebben a fejezetben mégis egy rövid kitérőt teszünk a digitalizálás
problémakörére, mivel szeretnénk a figyelmet felhívni arra, hogy a levéltári munkában az iratok tartalmának
elektronikus leírása és feldolgozása legalább akkora figyelmet kell, hogy kapjon, mint a digitalizálás.

3.1 A DIGITALIZÁLÁS CÉLJ AI ÉS ELŐNYEI

A levéltári digitalizálás elsődleges célja az állományvédelem. Amennyiben rendelkezésre áll digitális másolat az
eredeti dokumentumról, az eredetit nem kell mozgatni, így a használat közbeni sérülések elkerülhetők. Fontos
szerepe a digitális másolatoknak, hogy az eredeti dokumentum megsemmisülése esetén a biztonsági másolatból
rekonstruálható legyen az eredeti dokumentum kópiája. A digitális másolatok elősegítik a kutatók munkájának
gyorsítását. Amennyiben a dokumentumok kiegészülnek egy hatékony kereső rendszerrel, nincs szükség
minden kérés alkalmával a korábbi dokumentum előkészítési munkálatokra, az esetenként előforduló
hosszadalmas várakozásra. Ez nagymértékben csökkentheti a levéltári alkalmazottak leterheltségét is, növelve a
munka hatékonyságát.

A minőségi digitális másolatok lehetővé teszik az élményszerű vizuális megjelenítést is. Az interneten való
közzétételben, közművelődési tevékenység során előadásokon, levéltárpedagógiai foglalkozásokon való
felhasználással emelhető a levéltári szolgáltatások színvonala. Így nagyobb célközönség számára válnak
elérhetővé a levéltárban őrzött dokumentumok. A nagyobb közösség elérése tehát a digitalizálás további fontos
célja.

39 A levéltárak középfokú informatikai stratégiája 2006–2010 közötti időszakában pályázati forrásokkal támogatott
digitalizálási akciók indultak.
40 Vö.: Szerk.: Körmendy Lajos. Levéltári kézikönyv. Osiris, Bp., 2009. 686–688.
41
Tanulmányunknak nem célja a levéltári digitalizálás módszertanával részletesen foglalkozni. Ehhez nyújt útmutatót a
következő tanulmány: Ambrus Gábor–Biszak Sándor–Somfay Örs: A levéltári anyagok digitalizálásával szemben támasztott
követelmények. Arcanum Adatbázis Kft. Budapest, 2012.
http://www.bfl.archivportal.hu/eleveltar/data/files/278381236.pdf

20
Általában nem fogalmazódik meg explicit módon, de a digitalizálás fontos további szempontja kell, hogy legyen
a kereshetőség. Ha a digitalizált anyagok rendezetlenül, koncepció nélkül kerülnek tárolásra, az ahhoz
hasonlítható, mintha az eredeti dokumentumainkat egy zsákba tömnénk bele. A levéltári munka alapja a
rendszerezés, a dokumentumok „megtalálhatóságának” biztosítása. Egyes levéltári irattípusok esetében a
karakterfelismerő programok segítségével szöveges állománnyá alakíthatók a képfájlok, ami a levéltári
feldolgozást és kutatást egyaránt segíti. A digitális anyagok kezelése során is a hagyományos levéltári
dokumentumok esetén megszokott precizitásra van szükség. Emiatt a dokumentumokat ún. adatbázisokban kell
tárolnunk, amelyek biztosítják a kontrollált hozzáférést és a kereshetőséget.

3.2 A DIGITALIZÁLÁS HÁTR ÁNYAI

Mint minden új technológia vagy folyamat, a digitalizálás is rendelkezik hátrányokkal. Ezek közül több
egyértelmű, mások rejtettek, csak hosszútávon jelentkeznek. Ezeknek a hátrányoknak az ismerete
elengedhetetlen, ha a digitalizálás tömeges méretű alkalmazása a kérdés.

Az egyértelmű hátrányok közül az első a költség. A digitalizálás számítógép környezet számára készül,
elengedhetetlen a megfelelő teljesítményű, megbízhatóságú számítógépes infrastruktúra megléte, kialakítása.
Az infrastruktúrába tartoznak a levéltári dolgozók számítógépes munkahelyei, az őket összekötő belső
számítógépes hálózat, a központi feladatokat ellátó szerverek, nagykapacitású tárolóegységek, digitalizáló
készülékek, stb. Mivel a digitalizálás nem egyszeri feladat – a digitális dokumentumokat keletkezésük után
folyamatosan számítógépeken tároljuk – a rendszer fenntartása, folyamatos, évtizedeken át tartó üzemeltetése
is költségeket indukál.

Az infrastruktúra kezeléséhez, a digitális dokumentumok létrehozásához, feldolgozásához, kezeléséhez

megfelelően képzett levéltáros szakemberek szükségesek. Az új technológia bevezetése miatt jelentős lehet a
szükséges továbbképzés költsége is.

A költségek harmadik tényezője az idő. Bár a digitális másolatok megléte tehermentesíti a levéltáros dolgozók
munkáját, a digitális másolatok létrehozása (előkészítő- és utómunka, metaadatok feldolgozása) emberfeletti
terheket róhat a levéltáros közösségre. Több tízezer iratfolyóméter anyag digitalizálása nem megy gyorsan,
kérdéses, hogy egyáltalán lehetséges-e. Még ha teljesen automatizálható lenne is a folyamat, az időigény
hatalmas. Példaként vegyünk két esetet. Az első esetben egy dokumentum digitalizálása 1 másodpercet vesz
igénybe, a második esetben 1 percet. A feldolgozási idő 1, ill. 1000 iratfolyóméter anyag esetén közelítőleg az
alábbi (az egyszerűség kedvéért mai szabvány A4-es lap papírvastagsággal – 0,1 mm – számolva):

Feldolgozási sebesség Teljes feldolgozási idő

1 ifm (10 000 oldal): 2,8 óra 1000 ifm (10 millió oldal): 115 nap
a) 1 mp / oldal
1 ifm (10 000 oldal): 167 óra 1000 ifm (10 millió oldal): 19 év
b) 1 perc / oldal

Természetesen ezek az idők gyorsíthatók, amennyiben többen dolgoznak egyszerre az anyagok digitalizálásán,
azonban a digitalizálási berendezések, illetve a rendelkezésre álló szakképzett alkalmazottak száma fizikai
korlátokat jelent. A legnagyobb korlát azonban az, hogy a folyamat a gyakorlatban általában nem
automatizálható teljesen, szükség van emberi beavatkozásra, ellenőrzésre, elektronikus segédletek készítésére,
ami miatt még az 1 perc/oldal sebesség is irreálisan gyorsnak számít.

3.2.1 REJTETT HÁTRÁNYOK

A digitalizálásnak sajnos vannak rejtett hátrányai is, amik alapvetően az anyagok digitális formájából
következnek. Ezek közül a legkritikusabb a hosszú távú megőrzés, archiválás problematikája. A digitális

21
dokumentumok alapeleme a bit42. Ez egy bináris logikai állapot (igaz-hamis vagy 1-0) gépi reprezentációja. Bit-
ekből állnak össze a számok, számokból karakter sorozatok, és így tovább. A bit tárolásán áll vagy bukik egy
dokumentum létezése vagy nem létezése. Jelenlegi adattárolási technológiák félvezető, optikai vagy mágneses
adattárolókat használnak az adatok megőrzésére. Valamennyi tárolási technológia sérülékeny és limitált
élettartamú.

A hosszútávú adatmegőrzés problematikája

A mai háttértárolók (félvezető tárolók vagy merevlemezek) tárolókapacitása és élettartama korlátozott. Bár a
mágneses elven működő merevlemezek viszonylag nagy kapacitásúak (2013 végén akár 4 teraByte (TB) adat is
tárolható egyetlen merevlemezen), azonban mechanikai és mágneses hatásokra érzékenyek. Folyamatos
használat esetén élettartamuk szintén csak pár év. A mágneses tárolók egy speciális csoportja az archiválási célú
tárolók, melyek a merevlemezek és mágnesszalagok kombinációját alkalmazzák akár többszáz TB-nyi adat
tárolására. Élettartamuk több évtized is lehet, azonban ezek jelenleg a legdrágább adattároló rendszerek.

Bármilyen technológiát is választunk, biztosítanunk kell az adat biztonságát a hordozó meghibásodása,

tönkremenetele esetére. Ez biztonsági másolatok használatát igényli, ami természetesen többszörösére emeli a
tárolás költségét. Még ha biztosítjuk is a hordozó hibátlanságát, további veszélyek leselkednek ránk. Ha megsérül
a tároló adatszerkezete, vagy a dokumentumunk digitálisan tárolt formája, legrosszabb esetben akár a teljes
dokumentum használhatatlanná válhat. További veszélyforrás, ha megszűnik az adattároló szerviztámogatása,
esetleg maga a gyártó cég. Ugyanezek a problémák fennállnak a dokumentumot létrehozó-olvasó programok
esetén is; hiába tároljuk az iratot 50 évig, ha 10 év múlva már sehol nem futtatható az eredeti szoftver (akár a
szoftver, akár a szükséges kompatibilis számítógép hiánya miatt), amivel a dokumentumot létrehoztuk.

Ezek a veszélyek jól jelzik a digitális dokumentumok kezelésének problémáit, illetve azok súlyát. Mára
általánosan elfogadott, hogy a hosszú távú archiválás költséges tevékenység, folyamatos adatkarbantartást,
másolást és gyakran formátumkonvertálást igényel, mert a digitális világban csak így biztosítható a
dokumentumok „életben tartása”.

A digitalizálás csapdája

A digitalizálás csak ott jelent megoldást, ahol elég digitális kópiákat készíteni, de nincs szükség kereshetőségre.
Amennyiben tartalmat akarunk tárolni, és azt szeretnénk, hogy ahhoz minél többen minél gyorsabban
hozzáférjenek, a digitalizálás önmagában nem megoldás. Egy beszkennelt irat fénykép formátumban nem irat,
csak fénykép. Ha az irat tartalma fontos, az iratot újra be kell gépelni a gépbe, vagy szerencsés esetben
karakterfelismerő programmal automatikusan elkészíthetjük az elektronikus változatot. Ez az
adatbeviteli, -feldolgozási munkafolyamat már nem a digitalizálás területe.

4 DIGITÁLIS ADATOK TÁR OLÁSA

Minden digitalizált állomány, kép, videó, stb. adatok formájában, numerikusan tárolódik a számítógépek
memóriájában vagy háttértárolóiban. Ezek a számok megfelelő tartalmi, szerkezeti leírás, egyezmény nélkül
használhatatlanok, értelmezhetetlenek lennének. Az adataink visszanyerésének tehát a formátum rendkívül
kritikus tulajdonsága. Ez különösen érzékenyen érinti a levéltárakat, ahol hagyományosan évszázadokon át
megőrzendő dokumentumokkal dolgoznak. Ennek a fejezetnek az a célja, hogy az adatok tárolásának
legalapvetőbb egységétől indulva bemutassa, hogy a formátum milyen informatikai módszerekkel köthető hozzá
a tárolandó adatokhoz, illetve felhívja a figyelmet, hogy az adatok szerkezete, tulajdonsága meghatározza a
felhasználható adattárolási módszereket is.

42 A bit a binary digit (bináris számjegy) rövidítéséből keletkezett szó

22
4.1 TÁROLÁSI ALAPELVEK

A digitális dokumentumok alapegysége a már fent említett bit. Bár a tároló eszköz biteket tárol, a
dokumentumunk leírása során magasabb szintű egységeket használunk. Amint látni fogjuk, a digitális
dokumentumoknak bonyolult, többnyire hierarchikus struktúrája van, amit a tárolás során figyelembe kell
vennünk. Nyolc bit alkotja a következő szint egységét, a byte-ot (használható a magyarosított bájt forma is). A 7.
ábrán a 10-es szám bináris reprezentációját látjuk. A felső 0-7 számok a bitek helyiértékét jelzik. Ez a kettes
számrendszerben a 2 kitevőinek felel meg, így kapjuk meg az egyes bit értékkel ábrázolt számot. A szám végleges
értéke az egyes helyiértéken lévő bitekből kapott számok összege, a példánkon ez 0·20 + 1·21 + 0·22 + 1·23 + 0·24
+ 0·25 + 0·26 + 0·27 + = 0·1 + 1·2 + 0·4 + 1·8 + 0·16 + 0·32 + 0·64 = 10.

7 6 5 4 3 2 1 0

0 0 0 0 1 0 1 0

27 26 25 24 23 22 21 20

7. ábra Egy byte adat (8 bit) bináris ábrázolása kettes számrendszerben.

Az adatok ezen a bináris reprezentációs szinten byte-ok sorozataként jelennek meg. Honnan tudjuk azonban,
hogy ezek a byte-ok mit jelentenek? Számokat, szavakat? Ezt az adatok kódolása és a digitális állomány
szerkezete adja meg.

Tegyük fel, hogy 0-64 közötti számokat kívánunk tárolni egy állományban (file-ban). Mivel egy byte 0-255 közötti
számokat reprezentálhat (20 – 28-1), a tárolt byte sorozat elemei egyértelműen megfeleltethetők a számoknak.
Amennyiben nagyobb számokat is szeretnénk tárolni, amik már nem ábrázolhatók egy byte-on, több byte-ból
álló egységeket kell alkotnunk. Használhatunk pl. 2, 4 vagy 8 byte-ból álló egész és lebegőpontos (tizedes tört
alakú) számreprezentációkat. Ekkor azonban tudnunk kell, hogy a tárolandó egymás utáni számok egész vagy
tört reprezentációt, 2, 4 vagy több byte-os egységet használnak-e. Ha ezt nem tudjuk, a byte-okból nem tudjuk
újra előállítani az eredeti számot.

3 2 1 0

2 4 6 8
2563 2562 2561 2560

8. ábra Nagy számok ábrázolása több byte felhasználásával.

Több byte-os ábrázolásnál további problémát jelent a byte-ok sorrendje. Vannak rendszerek, ahol a
legalacsonyabb helyiértékű byte-ot tároljuk először, majd az eggyel magasabb helyiértékű következik. Más
rendszerek fordított sorrendet használnak, előbb a legmagasabb helyiértékű byte kerül tárolásra. Ha ugyanazt a
dokumentumot egyik rendszerről átmásoljuk a másikra, értelmetlen adathalmazt kapunk a byte sorrend
megváltozása miatt! A 8. ábrán látható 4 byte-os szám például a két különböző byte sorrendben 33 818 120 vagy
134 611 970 értéket ad (8·1 + 6·256 + 4·2562 + 2·2563 vagy 2·1 + 4·256 + 6·2562 + 8·2563).

Hasonló bonyodalmakat okoz a szöveges karakterek tárolása is. Az eredeti karakterábrázolási szabvány az ún.
ASCII kódrendszert használta, amelyben minden angol betűt egy egy byte-on tárolható szám ábrázolt.
Amennyiben szöveget tárolunk és tudjuk, hogy ASCII kódrendszert használ a dokumentum, a visszaolvasott byte
értékeket meg tudjuk feleltetni az eredeti karaktereknek. Azok a nyelvek, amelyek több karaktert használnak,
mint az angol ábécé (mint pl. a magyar), más kódrendszert kénytelenek használni. Az egyértelmű
visszaolvashatóság érdekében ezért célszerű a kódtábla információt is együtt tárolni a dokumentummal.

23
4.2 STRUKTURÁLT ADATOK T ÁROLÁSA

A tárolandó adataink sajnos legritkábban állnak azonos típusú adatelemekből. Az alkalmazási területtől függően
szöveges és számadatok tetszőleges kombinációival dolgozunk. A tárolás során elengedhetetlen, hogy egyrészt
az adatok jelentését, másrészt azok struktúráját is tároljuk annak érdekében, hogy az eredeti dokumentumot
vagy a programban használt adatszerkezeteket tökéletesen vissza tudjuk állítani eredeti formájára. Ehhez olyan
programokra van szükség, amelyek ezeket az extra információkat is tárolni tudják.

A legegyszerűbb strukturált tárolási formátum a CSV (Comma Separated Values) formátum. Legfontosabb
tulajdonsága, hogy az adategységek szöveg soronként jelennek meg a file-ban. Minden egyes sor egy adat
rekordot reprezentál, a rekord elemeit pedig vesszővel választjuk el egymástól. Minden sor azonos elemszámot
tartalmaz. A CSV file-ok kiterjesztése általában CSV agy TXT, pl. filenev.csv vagy filenev.txt. Az alábbi példában,
pl. név, születési hely, születési dátum, életkor, gyermekek száma szerepel.

Kovács János, Szeged, 1623. jan. 6., 33, 2

Szabó Imre, Kecskemét, 1630. feb. 22., 26, 1

Olyan nyelvterületen, ahol a vessző a tizedes jegy ábrázolására szolgál, általában más karaktert használunk az
adatok elválasztására. Magyarországon a legelterjedtebb a pontosvessző használata. A CSV formátum és
adatszerkezet nem szabványos volta miatt használata limitált, általában programok közötti ideiglenes
adatmozgatásra használjuk. Látható, hogy a fenti példa adat elemeinek jelentése sem egyértelmű, a dátum és a
számok jelenthetnek mást is, mint amit mi tulajdonítottunk nekik.

A napi gyakorlatban leggyakrabban szövegszerkesztő és táblázatkezelő programokkal állítunk elő

dokumentumokat. A szövegszerkesztő (pl. Microsoft Word, OpenOffice vagy LibreOffice Writer, stb.) lehetővé
teszi az irat hierarchikus logikai egységeinek megjelenítését különböző cím stílusok használatával, valamint
lehetőséget ad táblázatok és más adatelemek beágyazására. Az így létrehozott raktári jegyzékekre láttunk
példákat a 2.6. fejezetben.

A szövegszerkesztő programok által létrehozott file-ok több problémát is rejtenek a levéltárak szempontjából. A
szövegszerkesztő alapvetően nyomtatott levelek, iratok létrehozására készült. Egy szépen elkészített, formázott
anyag lehet bármilyen esztétikus, ennek a tárolt adatok szempontjából semmi jelentősége nincs. A logikai
egységeket kifejező stílus (fejezet cím, stb.) az adatok kereshetőségét nem segíti. A szövegben általában csak
pontos keresésre van lehetőség, továbbá mivel az irat független file-ként kerül a számítógép merevlemezére,
több szöveges file-ban egyszerre megkeresni egy bizonyos adatot vagy adatokat szinte lehetetlen.

Strukturált adatok létrehozására az irodai programcsomagok közül alkalmasabb a táblázatkezelő (pl. Microsoft
Excel, OpenOffice vagy LibreOffice Calc, stb.) programok használata. Ezeket a programokat – mint a nevük is jelzi
– táblázatos adatok leírására fejlesztették ki. Az ilyen típusú adatok közül is elsősorban is a számszerű adatok
feldolgozására alkalmasabbak. A táblázatkezelő programok elterjedtsége miatt több levéltárban is
megkezdődött a raktári jegyzékek Excel formátumú feldolgozása. Sajnos a táblázatkezelő nem a legalkalmasabb
eszköz a raktári jegyzékek leírására, amint ezt a következő ábránk is illusztrálja.

A raktári jegyzék hierarchikus felépítése jól illusztrálja, hogy az Excel programban hierarchikus adatok csak
meglehetősen körülményesen ábrázolhatók. Összefoglalóan megállapíthatjuk, hogy az irodai programcsomagok
több-kevesebb sikerrel alkalmazhatók a jegyzékek leírására, azonban precíz, hatékony és gyors számítógépes
feldolgozásra nem igazán alkalmasak. Ilyen feladatokra adatbázis rendszereket alkalmaznak, de amint majd
látjuk, a jelenleg legelterjedtebb relációs adatbázisok alkalmazása sem problémamentes a levéltári
környezetben.

24
 9. ábra Hierarchikus felépítés ábrázolása Excel-ben készült raktári jegyzékben.

4.2.1 RELÁCIÓS ADATBÁZISOK

Az adattárolási technológiák között jelenleg a legáltalánosabban elterjedt technológia a relációs adatbázis
modell és az ezt támogató relációs adatbáziskezelő rendszer. A relációs adatbázisok az üzleti élet, a közigazgatás
és általában a napi életünket kiszolgáló informatikai rendszerek motorjai.

A relációs adatbázisok alapja egy, a felhasználási célnak legjobban megfelelő adatmodell, ami lehetővé teszi az
optimális, legkevesebb helyet igénylő adattárolást, illetve az adatok leghatékonyabb visszakeresését. A relációs
adatbázis annyiban hasonlít pl. az Excel táblázatkezelőhöz, hogy az adatbázis is adattáblákból áll, azonban
általában több táblából, amelyek között kapcsolat (reláció) van. Azért használunk több adattáblát, hogy az
adatok optimális módon, felesleges többszörös tárolás nélkül kerülhessenek be az adatbázisba. Az adatok
tárolása egyedi, optimalizált bináris formátumban történik.

Az adatok módosítása, keresése tipikusan az SQL 43 (Standard Query Language) lekérdező nyelv segítségével
történik. Leegyszerűsítve, az így leírt lekérdező kifejezésekben az mondjuk meg, hogy melyik tábla melyik
adatoszlopában szereplő adatokkal mit csináljon a rendszer, vagy bizonyos feltételek teljesülése esetén azokat
listázza ki. Az adatbázis használatának elengedhetetlen feltétele az adatmodell, a táblák szerkezete és
kapcsolataik pontos ismerete. Emiatt laikus felhasználók általában nem tudnak egy ismeretlen adatbázisban
eligazodni és hatékonyan keresni. Az általános megoldás célzott kereső kifejezések előzetes leprogramozása,
amiben csak a paramétereket kell változtatni. Ezt a gondolatmenetet egy viszonylag egyszerű példa segítségével
illusztráljuk.

Az adatbázis Veszprém megye anyakönyvi kerületeinek és azok időbeli változásainak leírására jött létre. Az
adatbázis a 10. ábrán látható táblaszerkezetre épül. A rendszer célja, hogy a megye minden településéről tudjuk,
hogy adott időpontban melyik anyakönyvi kerülethez tartozott, önállóan anyakönyvezett-e, voltak e beosztott
kerületei, stb. A modell fő elemei a települések, az anyakönyvi kerületek és a beosztott kerületek, valamint a
változásokat megjelenítő események. Egy táblában tároljuk az összes települést (tblTelepulesekTorzs), és ezt
kötjük össze az anyakönyvi kerület (tblAnyakonyviKeruletek) vagy a beosztott kerületek
(tblBeosztottAnyakonyviKeruletek) táblák egyes soraival.

43 SQL ISO szabvány: http://www.iso.org/iso/catalogue_detail.htm?csnumber=45498

25
10. ábra Az anyakönyvi kerületek adatbázis modellje.

Ha például tudni szeretnénk egy adott anyakönyvi kerület székhelyét, ehhez két táblát kell felhasználnunk a
kereséshez. Amennyiben egy kerület beosztott településeit is szeretnénk listázni, már három táblát kell
felhasználnunk. Jól látszik, hogy az adatbázis belső felépítésének részletes ismerete nélkül nem tudunk
végrehajtani semmilyen műveletet.

11. ábra Az anyakönyvi kerületek leírására szolgáló tábla részletes szerkezete tervezési nézetben. Az első oszlopban szereplő nevek
lesznek az Excel táblákhoz hasonló adattábla oszlopnevei. Az így létrejött táblában minden sor egy kerületet leíró adatok halmazát tárolja
majd.

A relációs adatbázisok nagyon hatékonyak olyan használati esetekben, amikor az adat jól strukturált, szerkezete
nem változik, a cél a nagy adatmennyiség hatékony tárolása és jól definiált ismétlődő keresések nagyon gyors
végrehajtása. Amennyiben az adatunk szerkezete változhat – akár azért mert újabb követelmények lépnek fel,
akár azért mert a tervezés pillanatában még nem ismertük a teljes problémát –, vagy a lekérdezések nagyon
változatosak, a relációs modell használata könnyen nehézkessé válhat. Különösen nagy veszélyt jelent az
adatmodell bővítése, mert az átalakítás rossz kivitelezés esetén akár adatvesztést is eredményezhet. Szintén
komoly veszélyforrás az adatmodell dokumentáció megsemmisülése, mivel ennek hiányában a rendszer
működése, karbantartása hosszútávon nem biztosítható.

26
4.3 RÉSZLEGESEN STRUKTUR ÁLT ADATOK TÁROLÁSA

Míg az adatbázis rendszerek jól szolgálják a strukturált adatok tárolását, adataink nagy része olyan, részlegesen
strukturált formátumú, ami nehezen illeszthető be az adatbázisok szigorú szerkezetébe. A legtöbb írott szöveg,
dokumentum ebbe a részlegesen strukturált adatcsoportba tartozik. Ezeket az adatokat az jellemzi, hogy
szöveges és számszerű adatok egyaránt megtalálhatók bennük, gyakran hierarchikus szerkezetű részekből
állnak. A részeknek és az adatoknak jelentése van, amit valamilyen rugalmas módon jelezni-tárolni szükséges.
Az Internet térhódítása ugrásszerűen megnövelte az ilyen dokumentumok jelentőségét, hiszen a kereső
rendszerek (mint pl. a Google) ezekből a dokumentumokból szerzett információk alapján adnak keresési
találatokat, illetve állítják azokat sorrendbe. Emiatt a 2000-es évek elejétől kezdve megnőtt az érdeklődés a
részlegesen strukturált adatok tárolása iránt, mint a weboldalakon elérhető szöveges információk, az újságok,
könyvek írott tartalma. Emiatt új szakterületek, tárolási elvek jelentek meg a hagyományos adatbázisrendszerek
mellett.

A részlegesen strukturált dokumentumok két fontos tulajdonsága, hogy i) nem tárolhatók egy nagy adatbázis
rendszerben, mivel a dokumentumok önálló életet élnek, másrészt ii) a dokumentumnak a keresést segítő
kiegészítő leírást kell tartalmaznia a dokumentum szerkezetéről, jelentéséről. Annak érdekében, hogy ezek a
leírások szabványosak és a számítógépek számára is érthetőek legyenek, több ún. leíró nyelvet fejlesztettek ki.
A leíró nyelvek közös jellemzője, hogy a dokumentum tartalmának tetszőleges részéhez címkéket (angolul tag)
tud rendelni, melyek fontos szemantikai információt rendelhetnek a tartalomhoz.

A címkék és a leíró nyelvek használatát egy egyszerű példán mutatjuk be:

„Esterházy IV. Dániel 1755-ben Oszlop és Csetény lakosainak robotkötelezettségeit megállapítván

ötven öl fa megvágására kötelezte jobbágyait, a fát Győrbe voltak kötelesek szállítani és ott eladni,
minden öl után 1 tallért tartoztak fizetni a roboton kívül, robotjukba pedig mindezért 5 gyalogos
napszám került beszámításra.”

A fenti szövegrészletben szerepelnek nevek, időpont, helységek illetve további tevékenységre utaló információk.
A humán olvasó számára ezek az információk egyértelmű jelentéssel bírnak, azonban egy számítógép nem tudja
mi 1755, vagy Oszlop. Ezek a gép számára csak karakterek értelmetlen sorozatai. Ha azt szeretnénk, hogy ezek a
gép számára is érthetőek legyenek, a különböző fogalmakat, szavakat meg kell jelölnünk. Ezt gyakran megtesszük
mi is írott szövegek elemzése során. Ismételjük meg ezt a példát, de különböző színekkel emeljük ki a neveket,
helységeket és időpontokat:

„Esterházy IV. Dániel 1755-ben Oszlop és Csetény lakosainak robotkötelezettségeit megállapítván ötven
öl fa megvágására kötelezte jobbágyait, a fát Győrbe voltak kötelesek szállítani és ott eladni, minden öl
után 1 tallért tartoztak fizetni a roboton kívül, robotjukba pedig mindezért 5 gyalogos napszám került
beszámításra.”

A számítógép nyelvére lefordítva a sárga, zöld és kék kiemelést, a névhez, dátumhoz és a helységekhez hozzá
kell rendelnünk jelentést leíró címkéket. Ezt az ún. leíró (markup) nyelvekkel tehetjük meg.

Az első szabványos számítógépek számára kifejlesztett leíró nyelv az SGML 44 (Standard Generalized Markup
Language) volt. Az SGML szigorú dokumentum szerkezetet, betartandó szabályokat és szintaxist ír elő az SGML
dokumentumok létrehozására. A legfontosabb tulajdonsága azonban a címke (angolul tag) bevezetése, ami a
következő szintaxis szerint jelenik meg a dokumentumokban:

<TAG>szöveg</TAG>.

44 http://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language

27
A címkét a <> jelek azonosítják, minden megjelölt szövegrésznek kötelezően van egy nyitó és záró címkéje
(mintha nyitó és záró zárójelek közé tennénk egy szövegrészt). A címke neve tetszőleges lehet, azonban a nyitó
és záró címke meg kell, hogy egyezzen. A záró címkét mindig egy per jel ’/’ előzi meg. Ezt az elvet követve, a fenti
szövegrészünk pl. az alábbi módon látható el a gépi értelmezést-keresést segítő címkékkel:

„<név>Esterházy IV. Dániel</név> <dátum>1755</dátum>-ben

<helység>Oszlop</helység> és <helység>Csetény</helység> lakosainak
robotkötelezettségeit megállapítván ötven öl fa megvágására kötelezte
jobbágyait, a fát <helység>Győr</helység>be voltak kötelesek
szállítani és ott eladni, minden öl után 1 tallért tartoztak fizetni
a roboton kívül, robotjukba pedig mindezért 5 gyalogos napszám került
beszámításra.”

Az SGML szabvány elemeiből építkezett a böngészők nyelve is, a World Wide Web alapját képező HTML
(Hypertext Markup Language) nyelv. A HTML45 kevésbé szigorú a nyelvtani szabályok szempontjából és
alapvetően a tartalom web böngészőn belüli megjelenítési szabályainak leírására szolgál. Szabványos HTML
címkékkel írhatjuk le például, hogy egy szövegrész cím, fejezetcím legyen-e, milyen méretben, vagy esetleg
táblázatos formában jelenjen-e meg. A korábbi példa szövegrészünk HTML nyelven leírva az alábbi módon nézne
ki:

<!DOCTYPE html>
<html>
<body>

<h1>1. Fejezet</h1>
<h2>1.1 Egy példa</h2>

<p>A címkék és a leíró nyelvek használatát egy egyszerű példán mutatjuk be: <br>
<i>„Esterházy IV. Dániel 1755-ben Oszlop és Csetény lakosainak
robotkötelezettségeit megállapítván ötven öl fa megvágására kötelezte jobbágyait, a
fát Győrbe voltak kötelesek szállítani és ott eladni, minden öl után 1 tallért
tartoztak fizetni a roboton kívül, robotjukba pedig mindezért 5 gyalogos napszám
került beszámításra.”</i>
</p>

</body>
</html>
A címkék a file szerkezetét (html, body), a tartalom szerkezetét (h146, h2), illetve a megjelenést (p: bekezdés, br:
sortörés, i: dőlt szedés) adják meg. Ez a file, ha megnyitjuk a web böngészőben, a 12. ábrán látható módon jelenik
meg előttünk.

45 World Wide Web Consortium, HTML szabvány: http://www.w3.org/html/

46 A h1-h6 címkék a fejezet szinteket jelzik a legmagasabbtól az alacsonyabb szintig: heading 1, heading 2, stb.

28
12. ábra A szövegrészlet HTML verziója a böngészőben.

Az Internet elterjedése miatt a számítógépek megbízható hálózati adatcseréjének biztosítása érdekében idővel
szükségessé vált egy olyan általános, gépfüggetlen adatleíró szabvány kialakítása, ami minden szempontból
támogatja az automatizált számítógépes feldolgozást. A szabványosítási folyamat eredménye az XML (Extensible
Markup Language) leíró nyelv, amely ma a legelterjedtebb és legfontosabb adatleíró nyelv. Az XML nyelvről,
annak tulajdonságairól és használatáról szól a következő két fejezet.

5 AZ XML ADATLEÍRÓ NYELV

Az XML (Extensible Markup Language – bővíthető leíró nyelv) kifejlesztése 1996-ban kezdődött, a 2000-es évek
elejétől alkalmazása egyre elterjedtebbé válik. Az XML létrehozásának elsődleges célja az volt, hogy
létrehozzanak egy olyan egyszerű, gyártó és programozási nyelv semleges leíró nyelvet, amely alkalmas
szövegalapú dokumentumok Interneten történő továbbítására. A dokumentumok leírása mellett mára több
adatátviteli szabvány alapját is képezi. Több elterjedt irodai programcsomag tárolási formátuma is az XML-re
épül (pl. Word – docx, Excel – xlsx formátum47).

Az XML egyik legfontosabb tulajdonsága, hogy adatleíró nyelv. Ellentétben a HTML-lel, ami a weboldalak
böngészőn belüli megjelenítésének leírására szolgál, az XML az adat szerkezetét írja le. A HTML leírás az adat
struktúrájáról nem mond semmit, csak arról, hogy az hogyan jelenjen meg a böngészőben (pl. szövegesen,
táblázatosan, mik a fejezet vagy szakasz címek). Az XML leírás nem tartalmaz megjelenítési információkat, csak
a szerkezetre fókuszál. A megjelenés szabadon változtatható a felhasználási igények szerint. Ennek technikáját
később ismertetjük.

A következő fontos XML tulajdonság a bővíthetőség. Ez alatt azt értjük, hogy tetszőleges címkéket hozhatunk
létre az adataink leírására, nem egy központilag definiált szókészletből kell választanunk. Ez nagyon rugalmassá
teszi az XML nyelvet, egy adott terület adatait, dokumentumait az arra jellemző szókészlettel írhatunk le. Ez a
tulajdonság, kiegészülve azzal, hogy az XML egy nyelv, lehetővé teszi újabb XML-re épülő nyelvek létrehozását

47 Bár a Word és Excel speciális, ún. bináris XML formátumot használ.

29
is. Ezek egyik fontos következménye, hogy az XML ún. metaadat leíró nyelvek kialakítására is alkalmas, ami
tanulmányunk szempontjából nagy jelentőséggel bír.

Mivel az XML dokumentumok elsősorban számítógépes feldolgozás céljából készülnek, fontos, hogy a
dokumentum leírása precíz, egyértelmű és hibamentes legyen, hiszen bármilyen kis fogalmi vagy tartalmi hiba
megállíthatja a számítógépes feldolgozás menetét. Az XML szabvány garantálja ezt az egyértelműséget, illetve a
szabályok pontos betartatásával a leírás hibamentességét is.

5.1 AZ XML SZINTAXIS ALAPJAI

Az XML dokumentumok elemekből (element) állnak. Egy elem egy adategység címkékkel (tag-ekkel) megjelölt
egysége. Mivel az XML hierarchikus felépítésű, az elemek csoportosíthatók és egymás alá is kapcsolhatók.
Minden XML dokumentumnak csak egy kiindulási eleme lehet, ezt angolul root elemnek hívják. Ez nem azt
jelenti, hogy ez az elem címkéje. Az elem bármilyen címkét használhat, a root logikai szerepet jelent – kiindulási
elem.

Az alábbi egyszerű példa segítségével mutatjuk be az XML legfontosabb szintaktikai szabályait. A példa egy könyv
leíró adatait foglalja egységbe. Az érthetőség kedvéért magyar nyelvű címkéket használunk, de meg kell
jegyeznünk, hogy bár az XML megengedi tetszőleges nyelvű címkék használatát, a számítógépes feldolgozás
megbízhatósága érdekében célszerűbb angol címkeneveket használni.

<könyv>
<cím>A levéltári segédletek</cím>
<szerző>Ember Győző</szerző>
<kiadó>Akadémiai Kiadó</kiadó>
<év>1958</év>
</könyv>
13. ábra Egy könyv adatainak XML formátumú leírása.

Példa XML dokumentumunk kiindulási eleme, ami egyben a dokumentum egyetlen eleme is, a könyv. Ez több
további elemet tartalmaz, eggyel alacsonyabb szerkezeti szinten, egy konkrét könyv leírására (cím, szerző, kiadó,
év). Egy elemet kötelezően egy címke pár és megjelölendő adat alkot, pl. <cím>A levéltári
segédletek</cím>. A címkét mindig a kisebb-nagyobb jelekből alkotott zárójelpárok azonosítják <>. Az elem
lezáró címkéje esetén kötelező a címke szó előtti per jel - / - használata. A számítógépes feldolgozás során a gép
ezeket a zárójeleket keresi a szövegben, ezek alapján tudja logikai egységekre bontani a tartalmat, illetve
azonosítani az egyes elemek jelentését. Az elemek nevei érzékenyek a kis- és nagy betűkre, a kezdő címkének
betűhelyesen meg kell egyeznie a záró címkével. Például, a <szerző>Ember Győző</szerző> címke pár
helyes, míg a <szerző>Ember Győző</Szerző> vagy a <SZERZŐ>Ember Győző</szerző> pár hibás
elemnek számít.

Az egyes elemek tartalmazhatnak kiegészítő adatokat is, amelyeket attribútumoknak nevezünk. Ezek a nyitó
címke zárójelén belül helyezkedhetnek el a következő példán bemutatott módon:

<könyv id="122">
...
</könyv>

Az attribútumok tipikusan olyan kiegészítő információk tárolására alkalmasak, amelyek a végfelhasználó számára
érdektelenek, de a feldolgozás irányításában fontos szerepük lehet. Itt például az id paraméter a könyv
feldolgozás során használt azonosítója, amit a felhasználó számára nem kell megjelenítenünk. Ha viszont az ISBN
szám könyv azonosítóra gondolunk, azt már önálló címkeként és nem attribútumként kell elhelyeznünk a könyv
adatai között.

30
Ha a dokumentumban több azonos elemet akarunk tárolni, például több könyv adatait, akkor be kell vezetnünk
egy magasabb egységet, ami a könyveket tartalmazza. Ez amiatt szükséges, hogy az XML csak egy legfelső szintű
elemet tartalmazhat. A könyvek példa esetén megoldás lehet például egy gyűjtemény bevezetése:

<gyűjtemény>
<könyv id="122">
<cím>A levéltári segédletek</cím>
<szerző>Ember Győző</szerző>
<kiadó>Akadémiai Kiadó</kiadó>
<év>1958</év>
</könyv>
<könyv id="123">
<cím>Levéltári kézikönyv</cím>
<szerző>Körmendy Lajos</szerző>
<kiadó>Osiris</kiadó>
<év>2009</év>
</könyv>
<könyv id="124">
<cím>A számítástechnikai adatok és adathordozók
archiválása</cím>
<szerző>Tamáska Péter</szerző>
<kiadó>Új Magyar Központi Levéltár</kiadó>
<év>1992</év>
</könyv>
<könyv id="125">
<cím>Az abszolutizmuskori levéltár: repertórium</cím>
<szerző>Sashegyi Oszkár</szerző>
<kiadó>Magyar Országos Levéltár</kiadó>
<év>1984</év>
</könyv>
</gyűjtemény>

14. ábra Egy néhány könyvből álló gyűjtemény adatainak egy lehetséges leírása XML formátumban.

Az XML elemek típusa alapvetően szöveg, azonban ha elő akarjuk írni, hogy bizonyos elemekbe csak numerikus
adat vagy dátum szöveges reprezentációja kerülhet, ezt a későbbiekben ismertetésre kerülő XML séma
segítségével érhetjük el. Fontos megemlíteni, hogy az XML alapértelmezett karakterkódolási szabványa az UTF-
8, ami minden nyelv karakterkészletét támogatja, így nem kell aggódnunk karakter kódtábla keveredések miatt.

Az XML dokumentumok elsődleges tárolási formája a számítógépen tárolt file. Az XML-ben leírt file-ok
szabványos név kiterjesztése, az „xml”, pl. konyv.xml. Bár nem kötelező, mégis ajánlott minden XML file első
sorában elhelyezni az alábbi sort:

<?xml version="1.0"?>

Ez a speciális XML címke a dokumentumban használt XML szabvány verzió azonosító számát tartalmazza. Ez
egyértelműen leírja, hogy a feldolgozás során milyen XML szintaxist, nyelvi elemeket és szabályokat kell
figyelembe venni. Mivel az XML technológia – mint minden más informatikai terület – folyamatos fejlődésben
van, a változások precíz, szabályozott követése nagyon fontos feladat.

Mielőtt továbblépünk az XML nyelvre épülő technológiák ismertetésére, foglaljuk össze az XML előnyeit:

• Szabványokra épülő, szabályos, logikailag ellenőrizhető formátum.

• Hierarchikus struktúrája jól támogatja a szöveges dokumentumok és komplex adatszerkezetek leírását.

31
 • Nem függ konkrét gyártótól, operációs rendszertől vagy programozási nyelvtől, emiatt a technológiai
változásokra nézve semleges.
• Mind ember, mind gép számára olvasható formátumot használ. Bármilyen szövegszerkesztővel
megnyitható a file és megtekinthető az adat.
• Támogatja az Unicode karakterkódolást, ami lehetővé teszi bármely információ bármely emberi nyelven
történő leírását.
• Szigorú szintaktikus és elemzési követelményeket támaszt, ami biztosítja, hogy a feldolgozó programok
hatékonyan és ellentmondásmentesen működjenek.
• Kiforrott technológia, több mint tíz éve használja az informatikai ipar, széleskörű tapasztalat és szoftver
eszközök támogatják a fejlesztők és az alkalmazók munkáját.

6 AZ XML TECHNOLÓGIA TOVÁBBI ALKOTÓELEMEI

Bármilyen rugalmas is az XML nyelv, ez csak egy nyelv, ami bár dokumentumok felcímkézésére vagy adatok
leírására nagyon megfelelő, önmagában nem oldja meg minden problémánkat. Ha az XML dokumentumban
tárolt információkat fel is szeretnénk dolgozni, szükség van keresési funkciókra, esztétikus megjelenítésre,
további technológiákat kell felhasználnunk. Ebben a fejezetben az ún. XML technológiai lánc további
legfontosabb elemeit mutatjuk be. A célunk nem a részletes ismertetés, inkább annak demonstrálása, hogy ezek
a résztechnológiák mire szolgálnak, és hogyan illeszkednek egymáshoz egy komplex rendszer létrehozása során.

6.1 XML NÉVTÉR (NAMESPACE)

Mivel az XML megengedi tetszőleges címkék definiálását, előbb vagy utóbb felbukkanhat egy-egy címke, aminek
más jelentése lehet különböző esetekben, különböző adatleírásban vagy kontextusban. Ezt név ütközésnek
nevezzük, ami a feldolgozó program számára komoly problémát jelenthet. Vegyük példaként a <cím></cím>
címkét. Ha egy könyv feldolgozásáról van szó, ez valószínűleg a könyv címének megjelölésére szolgál. Ha azonban
egy postai címről van szó, lehet például a kiadó, a könyvesbolt vagy a szállítási címe, akkor a címke már más
jelentést kap. Komplex dokumentumok esetén előfordul, hogy mások által előírt címkéket kell használnunk (pl.
szabványok), így ezek ütközhetnek az általunk használt címkékkel. Az ütközés megszüntetésének egyik módja a
saját címkéink megváltoztatása, vagy az ún. névterek használata.

A névtér egyszerűen csak egy címke halmaz, amit elnevezünk egy egyedi azonosítóval, amit majd a címkéink
előtt egy előtagként, prefix-ként használunk majd. A dokumentumban felhasznált névtérre a dokumentumban
hivatkozunk az

xmlns:prefix="URI"

szintaxis szerint. Az xmlns az XML Namespace rövidítéséből létrehozott kulcsszó, a prefix az a név, amivel az
adott névtérre hivatkozunk majd a dokumentumunkban, az URI pedig a névtér leírásának elérési útvonala. Ez
tipikusan egy webcím szokott lenni, ahol a névtérben használt címkék leírása megtalálható. Ennek a címnek az
elérése nem szükséges a dokumentum feldolgozásához. Az xmlns:h=http://www.w3.org/TR/html4/ névtér
definíció után például a h: prefix-szel hivatkozhatunk egy XML dokumentumban pl. HTML címkékre.

<root xmlns:h="http://www.w3.org/TR/html4/">
<h:html>
<h:body>
<h:h1>Fejezet</h:h1>
</h:body>
</h:html>
<root>

32
Az XML név levéltári alkalmazása legjobban az EAD szabvány alkalmazása kapcsán érthető meg. Amennyiben
egy szöveges leírást az EAD szabványnak megfelelően kívánunk leírni, az ott alkalmazott címkéket kell
használnunk. Amennyiben szükség van rá, az xmlns:ead3=http://ead3.archivists.org/schema/ névtér definíció
után az ead3 prefix segít az EAD címkék helyes használatában, pl:

<irat xmlns:ead3=http://ead3.archivists.org/schema/>
<ead3:archdesc ...>
...további elemek...
</ead3:archdesc>
</irat>

6.2 AZ XML SÉMA

A névtér alkalmazása megakadályozza a különböző célra szolgáló címkék összekeveredését, de nem segít abban,
hogy hibamentes dokumentumokat állítsunk össze. Amennyiben az XML leírásban tárolt adatokat le tudjuk írni
általános szabályokkal, akkor az XML séma (XML Schema48) segítségével adat sablonokat, adattípusokat
definiálhatunk. A séma szerepe, hogy miután hozzárendeljük egy XML dokumentumhoz, az XML szerkesztő és
feldolgozó programok már a dokumentum létrehozása során ellenőrizni tudják, hogy a megengedett címkéket a
megfelelő helyen és módon alkalmazzuk.

Amennyiben biztosítani szeretnénk például, hogy a 14. ábrán látható XML dokumentumban csak könyv adatok
szerepelhessenek, mégpedig azokkal az adat elemekkel, amit ott látunk, létre kell hoznunk egy XML sémát a
könyvgyűjtemény adattípusra. Látható, hogy a könyvgyűjtemény egy hierarchikus adattípus, a gyűjtemény szint
alá kerülnek a könyvek, a könyv adatai pedig a könyv szintje alá. A séma definíció lehetőséget teremt egy adott
szint alatt egy vagy több azonos elemtípus megjelenésére a sorozat (sequence) megadásával. Lehetőségünk van
továbbá több lehetséges elem megjelenését is leírni (choice), pl. a könyv mellett megadhatunk a gyűjteményben
DVD-ket is. Az 15. ábrán a fenti könyv gyűjtemény séma vizuális modelljét, a 16. ábrán pedig a séma XML leírását
láthatjuk.

15. ábra A 14. ábrán látható XML dokumentumban leírt adatok logikai modellje.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" elementFormDefault="qualified"
attributeFormDefault="unqualified" vc:minVersion="1.1">
<xs:element name="gyűjtemény">
<xs:annotation>
<xs:documentation>Comment describing your root element</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="könyv" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>

48 World Wide Web Consortium, XML Schema: http://www.w3.org/standards/techs/xmlschema

33
 <xs:element name="cím"/>
<xs:element name="szerző"/>
<xs:element name="kiadó"/>
<xs:element name="év"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

16. ábra A 14. ábrán látható adatmodell XML sémája. A séma elemeinek neve (name=””) definiálja a séma alapján készülő XML
dokumentumban használható címkéket.

A séma tehát jellemzően különböző szintaktikai megszorításokat tartalmaz a dokumentumon belüli tartalom
struktúrájára és megengedett adattípusaira.

6.3 AZ XPATH TECHNOLÓGIA

Egy XML dokumentum a jellemzően hierarchikus felépítés miatt több szinten tartalmaz adatokat. A teljes
adathalmazt felfoghatjuk egy hierarchikus gráf szerkezetnek is, ami mint egy fa gyökere ágazik el, és tartalmaz
egyre több és több elemet. Az egyes szintek, illetve az ott található elemek elérést teszi lehetővé az XPath 49
technológia, ami nem más, mint egy egyszerű lekérdező nyelv. XPath kifejezések segítségével kiválaszthatunk
tetszőleges adatelemeket az XML adatszerkezetünkben.

A szintaxis alapja a megcélzott adatcsoportok elhelyezkedését leíró elérési útvonal kifejezés. Ez az elemek
nevéből és elválasztó ’per’ jelekből áll. Az útvonal lehet ún. abszolút elérési útvonal, ami a legmagasabb elemtől
indul, vagy relatív, ami egy adott elemtől értelmezendő. Például, a könyvlistánk esetében:

gyűjtemény Visszaadja az összes „gyűjtemény” nevű elemet. Esetünkben ez egy elem.

/gyűjtemény Visszaadja a dokumentum legmagasabb szintjén található gyűjtemény elemet.
gyűjtemény/könyv Visszaadja gyűjtemény elemhez tartozó összes könyv elemet.
//szerző Visszaadja valamennyi szerző adatelemet, függetlenül attól, hogy a
dokumentumban hol helyezkednek el.
gyűjtemény//cím Visszaadja a gyűjtemény elem alatt található összes könyvcímet, függetlenül az
elérési útvonaltól.
//@id Visszaadja az összes olyan elemet, amelynek van „id” nevű attribútuma.

Az alábbi XPath kifejezés egy konkrét könyv adatait kérdezi le a gyűjteményünkből:

/gyűjtemény/könyv[@id=122]/*

Az eredmény az alábbi:

A levéltári segédletek
Ember Győző
Akadémiai Kiadó
1958

49 World Wide Web Consortium, XPath: http://www.w3.org/TR/xpath20/

34
Amennyiben az összes könyv címére vagyunk kíváncsiak, a következő kifejezést használhatjuk:

/gyűjtemény/könyv/cím

Az eredmény:

A levéltári segédletek
Levéltári kézikönyv
A számítástechnikai adatok és adathordozók archiválása
Az abszolutizmuskori levéltár: repertórium

Az XPath kifejezések jelzik, hogy a feldolgozás során milyen fontos egyes elemek, vagy elem halmazok
összegyűjtése. Ezek a kifejezések azonban önmagukban, önállóan nem használhatók, alkalmazásuk további XML
technológiákban, mint például az XSL vagy az XQuery, résztechnológia formában jelenik meg.

6.4 AZ XQUERY TECHNOLÓGIA

Amennyiben az adatainkat nem relációs adatbázisban, hanem XML dokumentumokban tároljuk, szükségünk van
XML alapú keresési módszerekre. Az XQuery50 technológia egy keresési nyelv illetve a keresési kifejezést
végrehajtó alrendszer együttese. Az XQuery nyelv célja, hogy a felhasználók a relációs adatbázisokban
megszokott és bevált formához hasonló keresési kifejezéseket tudjanak definiálni és végrehajtani. A korábban
tárgyalt technológiákhoz hasonlóan az XQuery is XML alapokra épül, de saját kulcsszavai, és szabályrendszere
van. A legfontosabb technológia, amire az XQuery alapul, az az XPath, ami lehetővé teszi tetszőleges elemek
kiválasztását a dokumentumból. Ehhez társulnak a keresés végrehajtását vezérlő utasítások, amelyeket FLWOR
utasításoknak nevezünk. A FLWOR a for, let, where, order by, return kulcsszavak kezdőbetűiből képzett
rövidítés, ami az XQuery legfontosabb alaputasításaira utal.

 A for kifejezés egy dokumentum összes megadott elemét kiválasztja egy változóba. A végrehajtás egy
ciklusban történik. Több ciklus egymásba ágyazása is megengedett.
 A let kifejezés változók értékadására használható.
 A where kifejezés leszűkíti a kiválasztott elemeket azokra, amelyekre a kifejezésben megadott feltétel
teljesül.
 Az order by kifejezés az elemek sorrendjét határozza meg.
 A return kifejezés pedig meghatározza, hogy a végleges eredménylistából mi jelenjen meg az
eredmények között.

A kifejezések az alábbi formában használjuk:

for $x in doc("filename.xml")path-expression
where $x/conditional-expression
order by $x/expression
return $x/expression

Összegezve a fenti kifejezést, az első sorban megadott elem kiválasztási kifejezés (path-expression) által
összegyűjtött elemek az ‘x’ változóba kerülnek, ezek közül a második sorban megtartjuk azokat, ahol a feltétel
teljesül (conditional-expression), ha kell, az így kapott elem listát rendezzük (3. sor), majd visszatérünk a negyedik
sorban megadott elemekkel. A változó neve nem kötelezően x, tetszőleges név használható.

50 World Wide Web Consortium, XQuery: http://www.w3.org/TR/xquery-30/

35
A korábbi könyv gyűjtemény példán keresztül illusztráljuk az XQuery használatát. Az első példánkban a következő
kereső kifejezést hajtjuk végre: „Listázd ki a gyűjtemény könyveinek címét”.

for $x in doc("gyujtemeny.xml")/gyűjtemény/könyv
order by $x/cím
return $x/cím

A keresés eredménye:

<cím>A levéltári segédletek</cím>

<cím>A számítástechnikai adatok és adathordozók archiválása</cím>
<cím>Az abszolutizmuskori levéltár: repertórium</cím>
<cím>Levéltári kézikönyv</cím>

Látható, hogy e keresési lista XML elemeket eredményez. Ennek oka az, hogy az adatkeresés programok által
végrehajtott funkció, emiatt fontos, hogy az eredmény programozott feldolgozásra alkalmas formában álljon
elő. Mivel az eredmény tetszőleges komplex adatszerkezetet tartalmazhat, szükség van az XML formátum
megtartására.

A következő példában a következő kereső kifejezést hajtjuk végre: „Melyik kiadótól van a gyűjteményben 1970
után kiadott könyv?”.

for $x in doc("gyujtemeny.xml")/gyűjtemény/könyv
where $x/év>1970
order by $x/kiadó
return $x/kiadó

A keresés eredménye:

<kiadó>Magyar Országos Levéltár</kiadó>

<kiadó>Osiris</kiadó>
<kiadó>Új Magyar Központi Levéltár</kiadó>

Az XQuery nyelv támogatja a szabad szöveges keresést is. Mivel az XML dokumentumok alapvetően szöveges
tartalom leírására szolgálnak, alapvető funkciónak tűnik, hogy ne csak az elemek értékét, hanem hosszabb
szövegek tartalmát is vizsgálni tudjuk. Az XQuery szöveges keresés nagy előnye más szabad szöveges keresőkkel
szemben, hogy itt lehetőségünk van a szerkezet bizonyos elemeire szűkíteni a keresést. Sok kereső a szabad
keresés során nem veszi figyelembe a dokumentum struktúráját, a szöveget szerkezet nélküli karaktersorozatnak
tekinti.

A szöveges keresést az ftcontains kulcsszó valósítja meg. A használat az alábbi szintaxis szerint történik:

domain ftcontains full-text-query

ahol a domain a keresési elemeket reprezentálja, a full-text-query pedig a kereső kifejezést. A szöveges keresés
minden részletét e tanulmányban nem mutathatjuk be, azonban egy példa segítségével bemutatjuk az
alkalmazási lehetőségét. Tegyük fel, hogy a könyv címek között szeretnénk a „levéltár” szóra keresni; szeretnénk
azon könyvek címét és szerzőjét látni, amelyek címében szerepel ez a szó. Ehhez a következő XQuery kifejezés
alkalmas:

for $x in doc("gyujtemeny.xml")/gyűjtemény/könyv[cím ftcontains "levéltár" with wildcards ]

order by $x/cím
return $x/szerző

36
6.5 AZ XML DOKUMENTUMOK MEGJELE NÍTÉSE

Az XML leírás csak a dokumentum szerkezetét írja le, a megjelenését nem. Ha pl. a web böngészőben megnyitunk
egy XML file-t, általában az alábbi megjelenési képet kapjuk (nem minden böngésző kezeli azonosan az XML file-
okat, van, amelyik a címkéket kihagyja és csak az adatokat jeleníti meg ömlesztve):

17. ábra Egy XML file képe az Internet Explorer böngészőben.

Nyilvánvaló, hogy nem így szeretnénk olvasni az XML-ben leírt adatokat, szövegeket, hanem hagyományos,
címkék nélküli tördelt formátumban. Az XSL (Extensible Stylesheet Language /bővíthető stílusleíró nyelv/)
technológia ad lehetőséget arra, hogy leírjunk egy olyan transzformációs eljárást, ami a nyers XML formátumot
szerkesztett, tördelt formává alakítja át. Ha egy így elkészült leírást hozzárendelünk az XML file-hoz, a böngésző
automatikusan értelmezi és végrehajtja a stílus transzformációt.

Az alábbi példában egy egyszerű stílus file-t mutatunk be, ami a fenti gyűjtemény XML adathalmazt HTML
formátumra transzformálja. A leírás után látható a böngészőben létrejött transzformáció utáni megjelenítési
kép. Az XSL technológiai részeket szürke háttérszínnel emeltük ki. Jól látható az xsl: névtér kiválasztó
alkalmazása; ezzel érjük el, hogy a for-each és value-of parancsok értelmezése egyértelmű legyen. Az XSL
részletes bemutatása a tanulmány keretein túlmutató, itt elegendő azt látni, hogy ezzel a technológiával
tetszőleges formában megjeleníthetjük az adatokat. Természetesen nem csak HTML, hanem Word, PDF, stb.
formátumokat is elő tudunk állítani ezzel a módszerrel.

<?xml version="1.0" encoding="UTF-8"?>

<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
<xsl:for-each select="gyűjtemény/könyv">

37
 <div style="background-color:teal;color:white;padding:4px">
<span style="font-weight:bold"><xsl:value-of select="szerző"/> - </span>
<xsl:value-of select="cím"/>
</div>
<div style="margin-left:20px;margin-bottom:1em;font-size:10pt">
<p>
<xsl:value-of select="description"/>
<span style="font-style:italic"> (<xsl:value-of select="kiadó"/>, <xsl:value-of select="év"/>)</span>
</p>
</div>
</xsl:for-each>
</body>
</html>

18. ábra A könyvgyűjtemény XML file megjelenítése az XSL stílus transzformáció alkalmazásával.

6.6 AZ XFORMS TECHNOLÓGI A

Az utolsó XML technológia, amit érintünk tanulmányunkban az XForms, ami az adatbeviteli űrlapok
létrehozására létrehozott XML alapú szabvány. Az XForms létrehozásával a cél a HTML/XHTML űrlapok új
technológiai generációjának kifejlesztése volt. Az XForms XML nyelven megírt adatbeviteli űrlap oldalak leírására
szolgál, azonban elég általános ahhoz, hogy önállóan is használható legyen felhasználói felületek XML-alapú
létrehozására. Az XForms az XML séma és stílus (XSL) technológiákat alkalmazza a létrehozandó űrlap adatmodell
alapú validálásához és a megjelenés stílusának definiálásához. Érdekes módon a mai böngészők nem támogatják
az XForms technológiát. A Firefox a böngésző 19-es verziójáig támogatta az XForms szabványt, azonban azóta ez
a támogatás megszűnt. Ennek valószínűleg a HTML5 szabvány megjelenése az oka, bár a két technológia nem
ugyanazt a célt szolgálja.

Ettől függetlenül, több web-alapú rendszer támogatja az XForms űrlapokat és adatfeldolgozó rendszereket. A
betterForm51 és az Orbeon52 XML feldolgozó rendszerek beépített XForm feldolgozó egységet tartalmaznak,

51 betterFORM: http://www.betterform.de/en/index.html
52 Orbeon Forms: http://www.orbeon.com/

38
segítségükkel létrehozható tisztán XML-alapú web rendszerek, amelyekben a felhasználói felülettől a
feldolgozáson át az adatbázisig csak XML technológiákat alkalmaznak.

19. ábra Példa egy XForms technológiával létrehozott űrlapra.

7 XML SZERKESZTŐ ÉS FELDOLGOZÓ SZOFTVEREK

7.1 XML DOKUMENTUMOK LÉTREHOZÁSA

Az XML dokumentumok létrehozására, szerkesztésére több lehetőség is létezik. Mivel az XML szöveges állomány,
lehetőség van tetszőleges egyszerű szövegszerkesztővel is létrehozni XML állományokat. Ilyen
szövegszerkesztők valamennyi számítógépen megtalálhatók (pl. NotePad, …. ). Az XML formátum egyik
legnagyobb előnye, hogy minden XML file bármikor megnyitható a legegyszerűbb szövegszerkesztőben is. Sajnos
ezekben az XML állományok gyakran nehezen átláthatók és a szerkesztésük is meglehetősen körülményes (pl.
nincs szintaktikai ellenőrzés, formátum validálás).

20. ábra Egy XML állomány képe a Notepad szövegszerkesztőben.

Programozók számára készített szövegszerkesztők általában szintaxis alapú színezést alkalmaznak annak
érdekében, hogy egy program jobban olvasható és érthető legyen. Ez az XML esetén is alkalmazható. A 21. ábrán
a Notepad++ programszerkesztő XML megjelenítési képe látható.

39
21. ábra Egy XML állomány színezett képe a Notepad++ szövegszerkesztőben.

A következő, fejlettebb módszer a speciálisan XML dokumentumok szerkesztésére létrehozott, ún. XML
szerkesztőprogramok használata. Ezek már sok, kimondottan az XML adatok kezelésére, ellenőrzésére
létrehozott funkciót tartalmaznak. A funkcionalitástól függően vannak egyszerűbb és bonyolultabb programok.

22. ábra Az XML Notepad program kezelőfelülete.

Olyan felhasználóknak, akik nem csak egyszerű XML dokumentumokat, adatfile-okat akarnak létrehozni, hanem
az itt ismertetett további XML technológiákra is építenek, érdemes ún. XML fejlesztőkörnyezetet használni. Ezek
a programok magas szinten támogatják az XML szerkesztést, validálást, séma, XSL stílus transzformációk és
XQuery lekérdezések létrehozását, tesztelését. A sok elérhető program közül az egyik legelterjedtebb az
<oXygen/> XML Editor53, illetve az Altova XMLSpy54. A 23. ábrán ez utóbbi program kezelőfelületét láthatjuk.

53 oXygen XML Editor: http://www.oxygenxml.com/

54 Altova XMLSpy: http://altova.com/

40
Vannak olyan XML szerkesztőprogramok is, amelyek lehetővé teszik kijelölt szavak, mondatok felcímkézését. Az
alábbi képen az <oXygen/> XML Editor egyik üzemmódját látjuk, ahol a kék színnel kijelölt szót a legördülő
listában kiválasztott címkével jelölhetünk meg, anélkül, hogy az XML dokumentum formátumot látnánk vagy
használnánk.

23. ábra Egy komplex funkcionalitású XML szerkesztő, az Altova XMLSpy kezelőfelülete. A program a teljes XML technológiai láncot
támogatja.

7.2 XML ADATOK ELŐÁLLÍTÁ SA ŰRLAPOK SEGÍTSÉGÉ VEL

Az eddig ismertetett módszerek közvetlen XML file szerkesztésre épültek. Ez megköveteli az XML nyelv és a
speciális szerkesztőprogramok használatának ismeretét. Amennyiben a felhasználói, adatbeviteli oldalon el
szeretnénk rejteni az XML-specifikus részleteket, űrlap alapú adatfeldolgozó rendszereket kell használnunk. Ezek
alkalmazás-specifikus űrlapokon kérik be az adatokat és a háttérben – a felhasználó tudta és közreműködése

41
nélkül – alakítják a bevitt adatokat XML formátumúvá. Nem szükséges kiemelni, hogy ez a legkényelmesebb és
leginkább felhasználóbarát megoldás. Az űrlapfeldolgozó programok fejlesztés szempontjából lehetnek:

 egyedi fejlesztésű programok vagy

 általános célú (testre szabható) űrlapprogramok.

A működés helyétől függően pedig megkülönböztethetünk ún.:

 asztali (vagy desktop) űrlap alkalmazásokat és

 web-alapú adatfeldolgozó rendszereket.

Az általános célú asztali alkalmazások közül ki kell emelnünk az OpenOffice rendszert, ami támogatja az XML
űrlapok létrehozását. Ez statikus sablon dokumentumok létrehozására alkalmas, amin keresztül kényelmesen
elvégezhetők az adatbeviteli feladatok. Az adatok elküldése után azonban ezek a programok nem tudnak további
támogatást nyújtani az adathoz köthető egyéb munkafolyamatok során.

A web-alapú környezetben az XForms technológiára alapuló rendszerek közül az Orbeon 55 és betterFORM56

rendszerek érdemelnek említést. Ezek a szerver alkalmazások képesek XML adatsémákból űrlapokat generálni,
és egy web felületen ezeket elérhetővé tenni. Mindkét rendszer támogatja további saját funkciók beépítését is
a rendszerbe, így segítségükkel komplex dokumentumkezelő alkalmazások is létrehozhatók.

Az egyedi fejlesztések területén a felhasználható technológiák köre jóval tágasabb. Az alkalmazás tetszőleges
kliens technológiával létrehozza az űrlapokat, majd az adatok felvitele és validálása után átalakítja azokat XML
formátumra és továbbítja a rendszer további alrendszereinek. Általában az egyedi fejlesztésű rendszerek
nyújtják a legmagasabb szintű támogatást egy adott terület feldolgozási problémáinak megoldására, azonban a
fejlesztési költségek és a megvalósítás ideje minden szóba jöhető megoldás közül itt a legnagyobb.

7.3 XML ADATOK TÁROLÁSA ADATBÁZISBAN

Az XML dokumentumokat, mivel tárolási egységük a file (.xml), tárolhatjuk a számítógép file-rendszerében,
ahogyan a Word, Excel, stb. dokumentumainkat. Ez a stratégia azonban nem teszi lehetővé, hogy a
dokumentumaink kontrollált módon módosuljanak, vagy hatékony keresést tudjunk végrehajtani rajtuk. Ezeket
a funkciókat csak adatbázis kezelő rendszerekkel tudjuk megvalósítani.

Az XML adatokat, az eltérő szerkezetük miatt, azonban nehéz hagyományos relációs adatbázisokban tárolni. Az
XML adatok tárolási egysége a dokumentum, nem pedig a relációs adatbázis táblái, rekordjai. Az elmúlt 20
évben, nagymértékben az Internet térhódításának köszönhetően, ugrásszerűen megnőtt a különböző, relációs
adatbázisban nehezen tárolható, dokumentum és adatformátumok száma. Ennek következményeként alternatív
adattárolási rendszerek jelentek meg, megtörve az SQL-alapú relációs adatbázisok egyeduralkodását. A sok
szereplő közül itt csak a tanulmányunk szempontjából releváns, ún. dokumentum-orientált adatbázisokra, azok
közül is az XML adatbázisokra térünk ki.

Az XML adatok támogatása ma már minden komolyabb relációs adatbázisban megtalálható (IBM DB2, Microsoft
SQL Server, Oracle Database, PostgreSQL, stb.). Gyártótól függően két eltérő megoldást alkalmaznak. Az egyik
módszer az XML adat automatikus relációs táblákra alakítását jelenti, tehát csak a bemeneti és kimeneti
adatformátum XML, a belső tárolási formátum nem. A másik módszerben az adatbázis a relációs tárolás
kiegészítéseként, a módosítás nélküli, eredeti XML dokumentum formában tárolja az adatokat.

55 Orbeon Forms: http://www.orbeon.com/

56 betterFORM: http://www.betterform.de/en/index.html

42
Az XML adatbázisok másik csoportja az ún. natív XML adatbázis, amelyben nincs relációs támogatás, az XML
adatbázisok file formában, egy dokumentum tárházban tárolódnak, és ezt egészíti ki az adatbázis kezelő rendszer
dokumentum-kezelési, keresési és indexelési funkciókkal. Az adatok kezelésében a korábban bemutatott XPath,
XQuery technológiáknak van kiemelkedő szerepük. A natív XML tárolási elvet szintén több adatbázis rendszer
támogatja (például BaseX57, eXist58, MarkLogic59), ráadásul ezek közül az BaseX és eXist rendszerek nyílt
forráskódú programok. Ezek egyrészt ingyenesen használhatók, de ami még fontosabb, a szabadon
felhasználható forráskód következménye miatt a felhasználók soha nem kerülhetnek kiszolgáltatott helyzetbe;
a gyártó nem tudja elvenni a rendszert, illetve megtagadni egy funkció kifejlesztését (azt bárki kifejlesztheti) és
bármilyen katasztrófa esetén a program újraépíthető a forráskódból. Ennek jelentőségét a hosszú távú
archiválásra szakosodott levéltárak esetében nem lehet eléggé kiemelni!

8 A LEVÉLTÁRI RAKTÁRI JEGYZÉK DIGITÁLIS LEÍRÁSA

Tanulmányunk harmadik része a raktári jegyzék számítógépes feldolgozásra alkalmas digitális leírásáról szól.
Célunk egy olyan adatformátum és feldolgozási rendszer kialakításának előkészítése, ami az eddigi gyakorlatnál
sokkal hatékonyabb, pontosabb és automatizálható munkát eredményez és ezzel egyidőben követi a hazai
levéltári gyakorlat kialakult szabályait. A fejezetben először megvizsgáljuk a raktári jegyzéket tartalmi
szempontból, azonosítjuk a szakmai előírások alapján a gyakorlatban használatos adatelemeket. A megváltozott
igények miatt kiegészítjük ezeket az adatokat olyan elemekkel, amelyek lehetővé teszik más típusú jegyzékek
létrehozását is ugyanebben a rendszerben, illetve megkönnyítik a nyilvántartási feladatok ellátását. A tartalmi
vizsgálat során szem előtt tartjuk a régi jegyzékekkel való kompatibilitás megőrzését, valamint a levéltári leíró
szabványok alkalmazási lehetőségét.

A tartalmi elemzést kiegészíti a raktári jegyzék szerkezeti vizsgálata, aminek célja az egyes elemek egymással
való kapcsolatának feltérképezése. Ennek kiemelten fontos része az elemek közti vertikális és horizontális
kapcsolatok feltárása, valamint a raktári egységek és a levéltári egységek közötti mellérendelési viszony
vizsgálata.

Az elemzési folyamat után egy olyan leíró adatmodellre teszünk javaslatot, amely rugalmas, bővíthető,
támogatja a hosszú távú megőrzést, a lekérdezhetőséget és a kereshetőséget. A modell képes befogadni a
hagyományos levéltári jegyzékek adatait, és lehetővé teszi a megreformált új jegyzékek létrehozását is. A modell
minden raktári jegyzéket önálló egységként, dokumentumként kezel, alkalmas papír alapú nyomtatott jegyzék
előállítására is. A javasolt XML adatmodell nemzetközi informatikai és levéltári szabványokra épül és alapját
képezheti egy központi, egységes raktári jegyzék-nyilvántartó rendszernek.

8.1 A RAKTÁRI JEGYZÉK TARTALMI ELEMZÉSE

A 2.6 alfejezetben már megemlítettük, hogy amikor a Veszprém Megyei Levéltárban elkezdtük a raktári
jegyzékek Excel táblázatkezelőben való rögzítését, bár megreformáltuk az 1971. évi munkautasítás alapján
írógéppel készült, régi raktári jegyzékeink formáját, de a raktári jegyzék adattartalmán nem változtattunk. A
következőkben előbb a régi, megszokott adatelemeket, majd utánuk a most javasolt, új adatelemeket vesszük
sorra magyarázattal, illetve indoklással együtt.

57 BaseX XML adatbázis: http://basex.org/

58 eXist XML adatbázis: http://exist-db.org
59 MarkLogic Enterprise rendszer: http://www.marklogic.com/

43
Általános adatok

Ahogy a tanulmány első felében már szó esett róla, a raktári jegyzékbe foglalt nagyobb levéltári egységek, azaz
a fond vagy az állag egészére vonatkoznak az ún. általános adatok. Ezeket az adatokat a raktári jegyzék fejléc (és
az újakat részben a lábléc) részében találhatjuk meg.

1. A levéltár neve: az őrző levéltári intézmény neve, a munkautasítás szerint a cím részét képezi; az új
felfogás szerint a levéltárak alfanumerikus azonosító kóddal rendelkeznek, amely itt a levéltári jelzet
része.

2. A fond, illetve állag törzsszáma: levéltári jelzet, azaz a levéltári egység egyedi azonosítására alkalmas
kód, amely számok, betűk, írásjelek és szóközök szabatos rendszeréből áll. Egy adott levéltári egység
levéltári jelzete a legmagasabb levéltári szintből kiindulva – a levéltári vertikális tagolódásnak
megfelelően – tartalmazza mindazoknak a levéltári egységeknek a jelzeteit, amelyekbe az adott
levéltári egység beletartozik.

3. A fond, illetve állag címe: a fond, illetve állag teljes címe magában foglalja a fondfőcsoport (szekció)
címét, a fond címét és végül (állag esetében) az állag címét. Mindezeket a fond- és állagjegyzékben
foglalt módon kell megadni. A gyakorlatban a fondfőcsoport címét a raktári jegyzéken nem szoktuk
feltüntetni, mert a jelzetből egyértelműen kiderül, melyik fondfőcsoportba tartozik a fond.

4. A fond, illetve állag kora: a kort összefoglalóan szoktuk megadni, vagyis az iratanyag keletkezésének
csupán időhatárait jelöljük, tekintet nélkül a jelzett időhatárok közötti esetleges hiányokra.
Regisztratúra-jellegű levéltári anyagnál megkülönböztetjük a fondképző működése során létrejött
iratanyag korát az esetleges járulékos iratanyag (mellékletek, elő- és utóiratok) korától. Az utóbbiak
korát zárójelbe tesszük, mégpedig a legrégebbit a fondképző működése során létrejött és a fondban,
illetve állagban őrzött legrégibb iratok évszáma előtt, a legkésőbbit pedig a fondképző működése során
létrejött és a fondba, illetve állagba tartozó legújabb iratok évszáma után. A zárójeles megoldással
jelölhetjük a szórványéveket is.

5. A fond, illetve állag terjedelme: a terjedelmet kétféleképpen adjuk meg: a, a fondba, illetve állagba
tartozó raktári egységek számát, fajtánként összesítve, b, a teljes levéltári egység terjedelmét összesítve
iratfolyóméterben.

6. A fond (és állag) általános ismertetése: áttekintő raktári jegyzékekben a fond történetét bemutató
bevezető, amely tárgyalja a fond keletkezését, szerkezetét, rendszerét, a fondképző feladat- és
hatáskörét. A fondismertetőket az Excelbe átültetett raktári jegyzékek mellett is a hosszabb folyószöveg
befogadására alkalmas Word-formátumban szoktuk rögzíteni. Miután a jövőben a fondtörténeti
ismertetés adattartalmát a fond- és állagszintű levéltári leírás fogja tartalmazni, a fondismertetőnek is
nevezett bevezetőt kihagyjuk az adatmodellből60.

7. A fond, illetve állag nagyobb levéltári egységekre tagolódásának feltüntetése: a több legkisebb tárgyi
egységet összefogó nagyobb tárgyi egységek címeit a raktári jegyzék megfelelő részei elé szoktuk
helyezni, annak érdekében, hogy a jegyzéket könnyen áttekinthetővé tegyük. A fondon, illetve állagos
fond esetén az állagon belüli tárgyi egység csoportok, azaz belső levéltári szintek (fősorozat, sorozat,
alsorozat) jelzése véleményünk szerint inkább a speciális adatok közé tartozik. A levéltári szintek az
adatmodell logikai struktúrájába eleve másként illeszkednek. Ezért ezt a pontot mindenképpen ki kell
emelni az általános adatok sorából.

60
A 10/2002. (IV.13.) NKÖM rendelet minisztériumi egyeztetés alatt lévő módosítási javaslatában is szerepel az áttekintő
raktári jegyzéknek mint segédlettípusnak a megszüntetése. Az áttekintő raktári jegyzéket az “egyszerű” raktári jegyzéktől
elsődlegesen a fondismertető különböztette meg.

44
 24. ábra A hagyományos raktári jegyzék fejléce az általános adatokkal

Javasolt új adatelemek:

8. Gyarapodási azonosító: miután az ideiglenes raktári jegyzékeket is hasonló rendszerben készítjük és

kezeljük, és ezeken a jegyzékeken mindig feltüntetjük az iratátvétel azonosítóját, a gyarapodási számot
vagy a letéti számot, ezért szükség van a gyarapodási azonosítók jegyzéken való feltüntetésére.

9. Levéltári szint megadása: fond- vagy állagszint megjelölése, a nemzetközi szabványok figyelembevétele
szükségessé teszi a levéltári szint jelölését.

10. Rendezettség szintje: a szakmai ismérveknek megfelelően alap-, közép- és darabszint jelölhető; a
jegyzékek adatainak rendezettség szerinti lekérdezése, listázása adatszolgáltatáshoz hasznos lehet.

11. Jegyzék típusa: miután az adatbázisban különböző típusú jegyzékeket kívánunk kezelni, szükséges
megadni a jegyzék típusának nevét (pl. raktári jegyzék, ideiglenes raktári jegyzék, átvételi jegyzék,
lajstrom, elenchus, darabszintű jegyzék stb.), hogy eszerint is szűrhető, listázható legyen a
jegyzékállomány.

12. Megjegyzés (a jegyzék használati módjáról): sokszor találhatunk jegyzékeink végére írt olyan
folyószöveges megjegyzéseket, amelyek a jegyzék használatát segítik; érdemes ezeket az információkat
is megőrizni. Valamint további, máshol el nem helyezhető információkat is itt közölhetünk.

13. A jegyzék készítője: a jegyzék készítőjének neve hagyományosan a jegyzék végén szerepel, korábban
nem tekintették az általános adatok közé sorolandónak, mi ide vesszük.

14. A jegyzék készítésének ideje: hasonlóképpen kezeljük, mint a jegyzék készítőjét.

15. A hitelesítő neve: a raktári jegyzékeket ellenőrző személy neve, a jegyzék készítőjéhez hasonlóan
kezelendő.

45
 16. A hitelesítés ideje: hasonlóképpen kezeljük, mint a jegyzék készítésének idejét.

17. A referens neve: referenciarendszer alkalmazása esetén lényeges, hogy ki a felelős az adott fondért és
a raktári jegyzékért, miután a készítő és a referens személye nem feltétlenül azonos.

Speciális adatok

A legkisebb raktári, illetve levéltári egységek adatai a speciális adatok. Ezek képezik a raktári jegyzék tartalmi
részét, a jegyzék „testét”.

1. A raktári szám: a raktári egységnek a fondon, illetve állagon belüli sorszáma.

2. A raktári egység típusa: a raktári egység típusának megnevezése (csomó, kötet, téka stb.)

3. A tárgyi egység levéltári jelzete: A tárgyi egységek címei elé a megfelelő jelzeteket is kitesszük. A
gyakorlatunkban szintenként (pl. sorozatok) újrakezdődő, folyamatos sorszámozással (arab számmal)
szoktuk jelölni a tételeket mint legkisebb tárgyi egységeket.

4. A tárgyi egység címe: a legkisebb tárgyi egység pontos megnevezése.

5. A tárgyi egység kora: a legkisebb tárgyi egység időköre, amely lehet évkör, évszám, ha megkülönböztető
jelleggel bír, a kezdő és záró hónapot illetőleg napot is jelöljük.

6. A legkisebb raktári egységbe, illetve tárgyi egységbe foglalt iratok eredeti jelzetei: a raktári jegyzék
középszintű segédlet révén nem tartalmazhatja az iratanyag darabszintű nyilvántartását. Regisztratúra
jellegű levéltári egységek esetén összefoglalóan adjuk meg a legkisebb tárgyi egységbe tartozó iratok
jelzeteit. A legkisebb raktári egységbe tartozó iratok jelzeteit abban az esetben, ha valamely tárgyi
egység anyaga nem egyetlen raktári egységben, hanem két vagy több raktári egység közt megosztva
található, a raktári egységbe foglalt első és az utolsó irat számjelzetének megadásával kell közölni61.

Javasolt új adatelemek:

7. A tárgyi egység tartalmi leírása: többnyire a már korábban említett, és jegyzékeinkben gyakran
előforduló „benne-észrevételek” rögzítésére szolgáló adattípus, amely a legkisebb tárgyi egység
címében szereplő tárgymeghatározásnál bővebb leírási lehetőséget rejt opcionális módon.

8. Kapcsolódó tárgyi egység: különböző tárgyi egységek egymáshoz kapcsolódásának jelölésére szolgáló
adatelem, a másik tárgyi egység lehet a raktári jegyzéken belüli és akár kívüli is.

9. A tárgyi egység terjedelme: opcionálisan megadhatók a legkisebb tárgyi egység közelebbi terjedelmi
adatai (iratfolyóméter, lapszám, folió, oldalszám)

10. A tárgyi egységre vonatkozó megjegyzések: bármely olyan megjegyzés, amely egy konkrét tárgyi
egységre vonatkozik, és nem fér bele másik adatelembe.

61
Miután darabszintű jegyzékek befogadására és megjelenítésére is alkalmasnak találjuk a modellt, ezek esetében a jelzet
nyilvánvalóan egyedi jelzetet jelent.

46
25. ábra A hagyományos raktári jegyzék a speciális adatokkal

8.2 SZERKEZETI ELEMZÉS

A raktári jegyzék szerkezetének legalapvetőbb jellemzője a többszintűség, azaz a raktári jegyzék opcionálisan
több levéltári szintet is magában foglalhat. A fond- vagy állagszint alatt a raktári jegyzéken belül maximum 4+1
szinttel számolhatunk. A 4 szint lehet a fősorozat, a sorozat, az alsorozat és a tétel. Miután a darabszintű
jegyzékeket is megkíséreljük bevonni az adatmodellünkbe, a +1 szintnek az ügyiratok szintjét tekintjük. A szintek
egymással hierarchikus alá-, fölérendeltségi viszonyban állnak. A raktári jegyzék szerkezeti sajátossága, hogy a
fősorozat, a sorozat és az alsorozat közül egyik sem kötelező szint, az iratanyag jellegétől függően bármelyik
elmaradhat. A tételek, amelyek a középszintű segédletünk legkisebb tárgyi egységei a megyei levéltári
gyakorlatban, kötelező szintet képeznek. A raktári jegyzék legegyszerűbb formájában lehet akár egyszintű is,
azaz a jegyzék ez esetben csak horizontálisan tagolódik, ilyenkor egyenrangú tételekből áll. Szintén a lazább,
horizontális kapcsolat áll fenn az egyes fősorozatok, az egyes sorozatok és az egyes alsorozatok között szintjeiken
belül. Az adatmodell tervezésekor figyelembe kell venni, hogy különböző korokban eltérő módon értelmezték a
tételek jelzettel való ellátását, leszámozását. Régebben gyakran előfordult, hogy a vertikális tagolástól
függetlenül a tételek folyamatos sorszámot kaptak a raktári jegyzék első tételétől kezdve az utolsóig. Újabban
alapelvnek tekintjük (legalábbis Veszprémben), hogy a tételek minden egyes, szintet képező nagyobb levéltári
egységen belül kezdődjenek 1-es sorszámmal, a következő szintet jelző cím után pedig újrakezdődik a számozás.

A szerkezeti sajátosságok között meg kell említeni, hogy a raktári jegyzékekben, ahogy ezt a történeti részben
már taglaltuk, a jegyzékkészítési gyakorlatot tekintve kétféle iratsorozattal találkozhatunk. Az egyik a tárgyilag
nem tagolt iratsorozat, amely valamilyen jelzettel (pl. sorszámos, rendszámos, csoportszámos vagy alapszámos
iktatás; fasciculus/numerus) ellátott, mechanikusan pl. időrendi alapon vagy a jelzetek emelkedő rendjében

47
sorba rendezett ügyiratokból áll. Ekkor az egymás mellé kerülő ügyiratok között tárgyi összefüggés többnyire
nincs, vagy csak véletlenszerű. A másik a tárgyilag tagolt iratsorozat, amelynek minden egyes tétele olyan címmel
van ellátva, amely az irat tárgyáról is információt nyújt. Ekkor az egymás mellé helyezett tételek között szorosabb
a kapcsolat, a sorozaton belül valamilyen rendező elv (időrend, jelentőség, irattípus stb.) alapján állapítjuk meg
a tételek sorrendjét.

Szintén tárgyaltuk a raktári jegyzék történetéről szóló fejezetben a raktári egységek és a levéltári egységek
viszonyát. Megállapítottuk, hogy a raktári jegyzék a raktári egységekre fűzi fel a jegyzékbe foglalt levéltári
egységeket, miközben a kettő között biztosítja a konkordanciát. Mindig megállapítható, hogy melyik levéltári
egység pontosan melyik raktári egységben található, a másik oldalról pedig melyik raktári egység mely levéltári
egységeket foglalja magában. Ennek érdekében a legkisebb tárgyi egységeket úgy kell kialakítani, hogy lehetőleg
a raktári egységnél kisebbek legyenek. Ha mégis nagyobb a tétel, mint a raktári egység, akkor úgy kell
megbontani, hogy egyértelműen jelezni lehessen, hogy mely része esik egyik, illetve mely része esik a másik
raktári egységbe. A tárgyilag nem tagolt iratok esetén ezt a raktári egységen belüli első és utolsó jelzet
megadásával, többnyire egy számkontingens közlésével lehet megtenni egyértelműen. A tárgyilag tagolt iratok
esetében valamilyen más jellemzőt kell keresni, amellyel a szomszédos raktári egységek tartalmának
elkülönítése lehetővé válik. Az egyik gyakori ilyen lehetőség az időintervallum (vagy egyes évek) megadása, vagy
a további (tételen belüli) tárgyi tagolás feltüntetése.

8.3 SZABVÁNYOK ALKALMAZÁSI LEHETŐSÉ GE

A Nemzetközi Levéltári Tanács kezdeményezésére 1994-ben létrejött ISAD(G) szabványt a levéltári anyag
leírására alkották62. A 2000-ben második kiadást megért szabvány63 a levéltári iratok többszintű leírásához nyújt
hathatós segítséget. Az ISAD(G) egy olyan levéltári tartalmi leírás, amely hét adatcsoportba sorolva 26 fontos
adatelemet tartalmaz. Az adatelemek segítségével a levéltári iratanyag miden egyes szintje tartalmi
szempontból pontosan leírható, ugyanakkor a szabvány nem foglalkozik azzal, hogy a leírásokat vagy azok egyes
elemeit milyen módon jelenítsék meg vagy publikálják, és nem szól a számítógéppel való feldolgozás kérdéseiről
sem. Az ISAD(G) leíró szabvány alapul vételével a Levéltári Szabványügyi Bizottság 2012-ben készítette el az
Általános Levéltári Leírás Magyar Szabványát. Az ISAD(G) magyar változata szerint a legmagasabb levéltári
egységektől kezdve állagszintig kötelező a levéltári leírás elkészítése a szabványban meghatározott adatelemek
használatával, de a lehetőség fennáll az állagszint alatt is a leírt iratanyag sajátosságainak megfelelően a további
szintek, mint a „sorozat, alsorozat, kútfő vagy tétel, ügyirat, iratdarab” leírására. Az ISAD(G)-nek a magyar
levéltári rendszerre való alkalmazhatóságáról még évekkel ezelőtt két álláspont alakult ki. Az egyik szerint
állagszint alatt nem lehet szabványosítani, a levéltári anyag túlságos változatossága és a nagy mennyiségű adat
miatt. A másik elképzelés úgy vélte, hogy a levéltári anyag teljes vertikuma szabványosítható az általános leírás
szempontjai szerint64. Témánk szempontjából azért érdemes ezt a nézetkülönbséget feleleveníteni, mert a
raktári jegyzékek a levéltári anyagnak pont azokat a szintjeit (a közép-, és alsóbb szintű levéltári egységeket)
foglalják magukban, amelyekről a szabványosítás lehetőségében az álláspontok eltértek egymástól.

Vizsgáljuk meg újra a raktári jegyzék szerkezetét, majd pedig adatelemeit ezúttal a leíró szabvány
adatcsoportjaival való összevetés útján. A szerkezeti elemzéskor megállapítottuk, hogy a raktári jegyzék
opcionálisan több levéltári szintet foglalhat magában. A levéltári leírás lefedi a fond- vagy állagszint feletti
levéltári szinteket a szabvány 7 adatcsoportja szerint történő adatfelvétellel, viszont a fond- vagy állagszint alatt
a raktári jegyzéken belül számolhatunk még az említett 4+1 szinttel. Elvileg a többszintűség nem okozhat gondot,
hiszen a leíró szabvány pontosan a szintenkénti leírásra épül. Ehhez persze az kell, hogy az egyes szintek a raktári

62
Fordítása megjelent: ISAD(G): az első nemzetközi levéltári szabvány. In: Levéltári Szemle, 45. (1995) 2. szám, KILÁTÓ 53-
74. Ford.: Künstler Ferenc.
63
Fordítását lásd: http://www.archivportal.hu/data/files/153021420.pdf
64
Cseh Gergő Bendegúz–Körmendy Lajos–Németh István–Rádi Péter–Reisz T. Csaba: A levéltárak helye az információs
társadalomban, a levéltári anyag informatikai feldolgozása. In: Levéltári Szemle, 51. (2001) 1. szám 21.

48
jegyzéken belül elválaszthatók legyenek egymástól. Az elválasztás – ahogy már láttuk – gond nélkül megtehető
a raktári jegyzékek szerkezetében, hiszen a raktári jegyzék egyik fontos adateleme 1971 óta „a fond, illetve állag
nagyobb levéltári egységekre tagolódásának feltüntetése”. Ezeknek a szerkezeti információknak az ISAD(G)
adatcsoportjait tekintve egyrészt a törzsegység szintjén a levéltári leírás a leírási egység szerkezete (3.3.4.)
adatelemében találunk helyet. Másrészt az ISAD(G) szellemében a raktári jegyzékben előforduló minden alsóbb
szinthez elvileg hozzárendelhető egy-egy újabb leírás az adott szintre vonatkozó további adatelemek
felhasználásával.

A következő kérdés, hogy a raktári jegyzék egyes adatai milyen viszonyban állnak a szabvánnyal. Az alábbi
táblázatban azonosítottuk a raktári jegyzékbe foglalt adatokat a levéltári leírási szabvány adatelemeivel. A
táblázatban található raktári jegyzék adatelemek az általunk javasolt kibővített adattartalomnak felelnek meg.

Általános adatok táblázata:

raktári jegyzék adatelem ISAD/G adatcsoport ISAD/G adatelem

megnevezése
1. levéltár mint intézmény, szervezeti 3.1 azonosítási 3.1.1 jelzet
egység megnevezése adatcsoport
2. törzsszám (fondfőcsoport-fond- 3.1 azonosítási 3.1.1 jelzet
állag jelzete) adatcsoport
3.a fond címe 3.1 azonosítási 3.1.2 cím
adatcsoport
3.b állag címe 3.1 azonosítási 3.1.2 cím
adatcsoport
4. fond/állag összevont évköre, 3.1 azonosítási 3.1.3 idő(kör)
évszáma adatcsoport
5.a terjedelem (raktári egységek száma 3.1 azonosítási 3.1.5 terjedelem,
típusonként) adatcsoport adathordozók
5.b terjedelem (iratfolyóméterben 3.1 azonosítási 3.1.5 terjedelem,
vagy darabszám) adatcsoport adathordozók
8. gyarapodási azonosító 3.2 kontextusra 3.2.4 levéltárba
vonatkozó adatcsoport kerülés/gyarapodás
9. levéltári szint (fond vagy állag) 3.1 azonosítási 3.1.4 leírás szintje
adatcsoport
10. rendezettség szintje 3.3 tartalom és szerkezet 3.3.4 a leírási egység
adatcsoport szerkezete
11. jegyzék típusa 3.4 hozzáférésre és 3.4.5 segédletek
használatra vonatkozó
adatcsoport
12. megjegyzés a jegyzék használati 3.6 megjegyzések 3.6.1 megjegyzések
módjáról adatcsoport
13. jegyzék készítője 3.7 ellenőrző adatcsoport 3.7.1 a leírás készítése és
készítője
14. jegyzék készítésének ideje 3.7 ellenőrző adatcsoport 3.7.3 a leírás
készítésének ideje
15. hitelesítő neve 3.7 ellenőrző adatcsoport 3.7.1 a leírás készítése és
készítője
16. hitelesítés ideje 3.7 ellenőrző adatcsoport 3.7.3 a leírás
készítésének ideje
17. referens neve 3.7 ellenőrző adatcsoport 3.7.1 a leírás készítése és
készítője

49
Speciális adatok táblázata:

raktári jegyzék adatelem ISAD/G adatcsoport ISAD/G adatelem

megnevezése
1. raktári egység sorszáma nem feleltehető meg ––
2. raktári egység típusa nem feleltehető meg ––
ált. 7. tárgyi egység-csoportok/levéltári 3.1 azonosítási 3.1.1 jelzet (levéltári)
szintek (fősorozat-sorozat- adatcsoport
alsorozat) jelzete
ált. 7. tárgyi egység-csoportok/levéltári 3.1 azonosítási 3.1.2 cím
szintek (fősorozat-sorozat- adatcsoport
alsorozat) megnevezése
3. tárgyi egység levéltári jelzete 3.1 azonosítási 3.1.1 jelzet (levéltári)
adatcsoport
4. tárgyi egység címe 3.1 azonosítási 3.1.2 cím
adatcsoport
5. tárgyi egység kora 3.1 azonosítási 3.1.3 idő(kör)
adatcsoport
6. eredeti jelzet 3.1 azonosítási 3.1.1 jelzet (eredeti)
adatcsoport
7. tárgyi egység tartalmi leírása 3.3 tartalom és szerkezet 3.3.1 tárgy és tartalom
adatcsoport
8. kapcsolódó tárgyi egység 3.5 kapcsolódó anyagok 3.5.3 kapcsolódó leírási
adatcsoport egység
9. a tárgyi egység terjedelme 3.1 azonosítási 3.1.5 terjedelem,
adatcsoport adathordozók
10. a tárgyi egységre vonatkozó 3.6 megjegyzések 3.6.1 megjegyzések
megjegyzések adatcsoport

Következtetés

A raktári jegyzék adatainak az ISAD(G) adatcsoportokba, adatelemekhez való besorolása természetesen nem
jelenti azt automatikusan, hogy a raktári jegyzék egészében megfelelhet a szabványnak. A fenti táblázatokból
azt a következtetést vonjuk le, hogy a raktári jegyzék általános adatai, amelyek mindig a törzsegységek szintjén
kerülnek a raktári jegyzékben leírásra, teljes mértékben beolvadhatnak a szabványos levéltári leírásba, minden
itt szereplő adatelemnek megvan ott is a helye. Tehát a raktári jegyzék általános adatai egyrészt szabványosak,
másrészt nyilvánvalóan kiválthatók, amennyiben van olyan számítógépes programunk, amely a leíró
szabványnak megfelel, és feltéve, ha minden törzsegységünkre el is készítjük a teljes levéltári leírásokat65.

A speciális adatok esetében némiképp más a helyzet. Egyrészt a már korábban jelzett problémával
szembesülhetünk, a raktári egységek kilógnak a rendszerből, nem az iratanyagot leíró elemekről van szó, hanem

65
Ha az általános adatok táblázatában itt felsoroltakhoz hozzávesszük még a fondismertetőt avagy fondtörténeti bevezetőt
is, az áttekintő raktári jegyzék általános adatait kapjuk, amely adatok összessége megfelel a levéltári leírás elvárt
adattartalmának. A kettő közti különbség az adatok strukturálásában van. Az itt leírt raktári jegyzék adatokból viszont
szándékosan kihagytuk az áttekintő raktári jegyzék fondismertetőjét, mert adatmodellünkbe a fondismertetőt nem kívánjuk
beépíteni. A fondismertető tartalma a levéltári leírásban szétoszlik több különböző adatelem között, márcsak ezért is nehéz
lenne beépíteni az adatmodellünkbe.

50
a nyilvántartást szolgálják. Az ISAD(G) nem is tartalmaz olyan adatelemet, amelybe be tudnánk sorolni a tárolási
adatokat. A többi speciális adat pedig minimális adatkört fed le, mindössze az azonosítási adatcsoport néhány
eleme szerepel egy átlagos raktári jegyzékben a legkisebb tárgyi egységek szintjén. A kontextusra (pl.
szervtörténet), vagy a hozzáférésre vonatkozó adatcsoportok aligha relevánsak a raktári jegyzéken belüli
levéltári egységeknél. Viszont a raktári jegyzékbe foglalt teljes törzsegység levéltári leírásában felvett kontextus
és hozzáférési adatok nyilván érvényesek a benne foglalt levéltári egységekre is. Különböző raktári jegyzék
típusaink vizsgálata alapján állíthatjuk, hogy a raktári jegyzék speciális adatkörében az azonosító adatcsoporton
túl azért előfordulhat még további néhány szabványelem, ezekkel bővítettük is a raktári jegyzék új adataira tett
javaslatunkat. Így például a terjedelem (3.1.5.), a tárgy és tartalom (3.3.1.), a kapcsolódó leírási egységek (3.5.3.),
megjegyzések (3.6.1.) adatelemek körébe tartozó adattípusokat is találtunk.

Levéltárelméleti szempontból fontos, hogy tisztázzuk a leírási szabvány és a raktári jegyzék viszonyát. De mit
jelent mindez a számítógépes feldolgozás számára? Mennyiben segíti az adatmodell létrehozását? Az ISAD(G)
egy levéltári leíró szabvány, aminek elsődleges célja a levéltári iratok tartalmi leírásának egységesítése. A
szabvány nem írja elő ezen a leíró adatelemek felhasználásának a módját, nem kötelezi a felhasználót például
adatbázis vagy akár számítógép használatára. Az így készült, szabványt követő levéltári leírások tökéletesen
megfelelőek, mint levéltári segédletek, azonban nem feltétlenül alkalmasak közvetlen számítógépes
feldolgozásra. A szabvány nem ír elő olyan szigorú szintaxist, adatstruktúrát, ami az automatizált számítógépes
feldolgozást lehetővé tenné. Erre egy példa a 26. ábrán látható levéltári leírás részlet, ami tökéletesen megfelel
a szabvány előírásainak, mivel azonban Word dokumentum formában készült, a számítógépes feldolgozásra így
nem alkalmas. Természetesen, ha a szabványra épülő adatbázisba kerülnek be ugyanezek az adatok, akkor ez a
probléma nem jelentkezik. A veszély az, hogy fennáll az a lehetőség, hogy akár nagy mennyiségben létrejönnek
feldolgozásra alkalmatlan digitális anyagok.

26. ábra Példa az ISAD/G alapján készített leírásra66

A számítógépes feldolgozás problémájára kínál megoldást az EAD szabvány alkalmazása, mely kimondottan a
számítógépek számára alkalmas formátumban, XML nyelvi elemekkel írja le a levéltári anyagot. Az EAD egy XML
séma formában definiálja a leíró adatelemeket és azok felhasználási szabályait, így garantálható, hogy a létrejött
leírások megfelelnek a szabványnak és a számítógépek értelmezni is tudják őket. Előnye továbbá, hogy jóval
részletesebb az ISAD(G) szabványnál, minden levéltári iratanyag leírható az EAD-vel, az adatok könnyen

66
ISAD(G) Az Általános Levéltári Leírás Nemzetközi Szabványa, Második kiadás, magyar fordítás, 2009.
51
kezelhetőek és kereshetőek. Hátránya az EAD alkalmazásának, hogy a szabvány komplexitása miatt sok
megkötést jelent, illetve a gépi formátum miatt kötelező megfelelő szerkesztő-feldolgozó programokat
használni. Raktári jegyzék célú alkalmazása esetén további problémákat jelenthet, hogy az EAD – az ISAD(G)-hez
hasonlóan – az iratok általános leírására jött létre, nem pedig a tárolási egységekben elhelyezett levéltári
egységek nyilvántartás jellegű leírására. Az EAD-vel készült leírások hátrányaként említik meg, hogy nem
működnek adatbázisként, a relációs adatbázisok, illetve adatbázis-kezelők egyes szolgáltatásait nem tudják
nyújtani67. XML adatbázisok segítségével ez a probléma kiküszöbölhető és az általunk javasolt adatmodellre
készült konkrét példával illusztráljuk is a keresési lehetőségeket.

8.4 A JAVASOLT XML RAKTÁ RI JEGYZÉK MODELL

A raktári jegyzék digitális leírása során abból indultunk ki, hogy számítógépes feldolgozásra maximálisan
alkalmas legyen. Nem látjuk értelmét személyi számítógépen olyan adatok bevitelének, amelyek nem járulnak
hozzá a gyorsabb, hatékonyabb iratfeldolgozáshoz, nyilvántartáshoz, kereséshez.

A tanulmány tartalmi, szerkezeti elemzési része bemutatta, hogy a raktári jegyzék egy dinamikusan változó,
kötelező és opcionális adatelemeket is tartalmazó, hierarchikus felépítésű dokumentum. A digitális,
számítógépes adattárolási forma kialakításánál ezeket a tulajdonságokat figyelembe kell venni és biztosítani kell,
hogy a modell megfelelően rugalmas, bővíthető legyen, hogy a jövőbeli igényeket is ki tudja szolgálni. A jelenleg
legelterjedtebb gyakorlat – Word illetve Excel file-ban történő leírás – a rugalmasságot és a számítógépes
feldolgozást nem tudja egyidejűleg támogatni. A tárolt adatok feldolgozása külső programokkal majdnem
lehetetlen. Ezen felül, mindkét dokumentum esetén probléma a bináris, egyedi adatformátum, a gyakori
formátumváltozások, egyetlen vállalat termékétől való függőség. A hosszútávú archiválás és működés
érdekében célszerű olyan megoldás használata, ami független a gyártóktól és garantáltan fennmaradó
nemzetközi szabványokra épül.

A raktári jegyzék adatmodell tervezésekor az első felmerülő lehetőség a relációs adatbázisok használata, mivel
jelenleg ez a legelterjedtebb, leggyakrabban használt az adatbázis technológia. Bár relációs adatbázis rendszerrel
garantáltan le lehet írni a raktári jegyzékeket, komoly elvi problémák is jelentkeznek. Az adatbázis rendszerek
alapelve a pontos és lehetőleg nem változó adatmodell. A raktári jegyzék esetén, ahol hierarchikus, alapvetően
szöveges, nem numerikus adatokkal dolgozunk, és a szerkezet is változhat, a relációs modell komplikált
megoldás. További gond, hogy a tárolás bináris, adatbázistól függő formátumban történik, a modell ismerete
nélkül nem lehet kideríteni mit hogyan tárol, illetve ha az adatbázis sérül, minden adatunk odaveszhet. Mivel az
adatbázis rendszerek lehetőség szerint központosítottak, a területi elvű adat-partícionálás, pl. intézmények közti
szétosztás, összefésülés, adatcsere nagyon komplikált megoldásokat eredményeznek.

A hierarchikus adatmodell, a szöveges adatok túlsúlya, a változó adatszerkezet és a hagyományos dokumentum-

orientált feldolgozási mód, kiegészülve a hosszútávú megőrzés igényével, mind az XML technológiák
felhasználása irányába mutatnak. A modellünk kialakításánál az XML melletti döntés után a legfontosabb kérdés
a szabványok alkalmazása, alkalmazhatósága volt. Elvileg elkészíthető a raktári jegyzék az EAD szabványra építve,
azonban az alábbi indokok miatt tanulmányunkban egy saját raktári jegyzék XML adatmodell (séma) kifejlesztése
mellett döntöttünk:

 Az EAD szabvány a raktári jegyzékek számára túlzottan komplex, ebben az alkalmazási körben túl sok
felesleges kötelező elemet követel meg.
 Az EAD-ben alkalmazott XML címkék (tag-ek) angol nyelvűek. Mivel itt a címke a szabvány eleme, nem
lehet lefordítani, ezért a magyar raktári jegyzék leírások vegyes nyelvűek lennének: angol címkék között
magyar leírás. Ez elvileg célszoftverekkel elrejthető, azonban a normál XML file megnyitásakor egy

67
Szerk.: Körmendy Lajos. Levéltári kézikönyv. Osiris, Bp., 2009. 662–667.

52
 levéltáros mégis jobban érti a file tartalmát, ha a raktári jegyzékek feldolgozása során megszokott
terminológiát talál.
 Az EAD szabvány jelenleg új változat megjelenése előtt áll. Az érvényben lévő EAD 2002 verziót 2014
tavaszán váltja (kiegészíti) az EAD3. Tanulmányunk határideje miatt nem várhattuk meg e szabvány
végleges verziójának megjelenését, a régire pedig nem célszerű tervezni. Ez nem jelenti azt, hogy a
javasolt modellünket szükség esetén ne lehetne majd átültetni EAD3-ra.
 Mint említettük, az EAD magasabb szintű leírások elkészítésére szolgál, bár jóval több eleme van mint
az ISAD(G)-nek, elvileg találhatók benne olyan elemek, amelyek céljainknak megfelelhetnek. Emellett,
az EAD több eleme szöveges típusú, ahol a számítógép numerikus adatokat várna el, illetve csak
komplikált módon, kiegészítő attribútumok felhasználásával lehet fontos feldolgozási lépéseket
leprogramozni.
 A tanulmányunkban igyekeztünk a legegyszerűbb modellt létrehozni, hogy a szélesebb levéltári
közösség számára kiemeljük a modellben és az erre építhető rendszerben rejlő előnyöket. Egy bonyolult
modell elriaszthatja az olvasókat a rendszer megismerésétől.

8.4.1 A MODELL LOGIKAI LEÍ RÁSA

Mielőtt a részletes modellt bemutatnánk, a modellt felépítő adatelemeket ismertetjük. Elvárás a modellel
szemben, hogy tartalmazza a raktári jegyzék fent ismertetett általános és speciális adatait is. Mindkét
adathalmaz tárolásának az az oka, hogy szeretnénk, ha a rendszer önállóan is megállna a lábán, nem tudni még,
hogy a Scope Archivval vagy más adatbázisokkal miként működik majd az összekapcsolás. Amennyiben
lehetséges az adatmodell integrálása, természetesen az általános adatok feloldódnak a központi nyilvántartó
rendszer/adatbázis levéltári leírást tükröző részében.

Általános adatok

Adatelem elnevezése az XML- Adatelem meghatározása kötelező / Hagyományos

adatmodellben opcionális raktári jegyzékben
szerepel?
1. leveltari-intezmeny levéltár mint intézmény, K igen
szervezeti egység
megnevezése
2. torzsszam törzsszám (fondfőcsoport- K igen
fond-állag jelzete)
3. gyarapodasi-azonosito gyarapodási szám vagy letéti O nem
szám
4. fond-cim fond címe K igen
5. allag-cim állag címe O igen
6. idokor fond/állag összevont évköre, K igen
évszáma
7. leveltari-szint levéltári szint (fond vagy K nem
állag)
8. terjedelem-raktegyseg terjedelem (raktári egységek K igen
száma típusonként)
9. terjedelem-ifm terjedelem K igen
(iratfolyóméterben vagy
darabszám)
10. rendezettseg-szint rendezettség szintje K nem

53
 11. jegyzek-tipus jegyzék típusa K nem
12. megjegyzes-hasznalat megjegyzés a jegyzék O nem
használati módjáról
13. keszito jegyzék készítője K igen
14. keszitesi-datum jegyzék készítésének ideje K igen
15. hitelesito hitelesítő neve O igen
16. hitelesitesi-datum hitelesítés ideje O igen
17. referens referens neve O nem

Speciális adatok

Adatelem elnevezése az XML- Adatelem meghatározása kötelező / Hagyományos

adatmodellben opcionális raktári
jegyzékben
szerepel?
1. raktari-egyseg: sorszam raktári egység sorszáma K igen
2. raktari-egyseg: tipus raktári egység típusa K igen
3. leveltari-szint: jelzet tárgyi egység- O igen
csoportok/levéltári szintek
(fősorozat-sorozat-alsorozat)
jelzete
4. leveltari-szint: cim tárgyi egység- O igen
csoportok/levéltári szintek
(fősorozat-sorozat-alsorozat)
megnevezése
5. targyi-egyseg: jelzet tárgyi egység levéltári jelzete K igen
6. targyi-egyseg: cim tárgyi egység címe K igen
7. targyi-egyseg: tartalom tárgyi egység tartalmi leírása O nem
8. targyi-egyseg: idokor tárgyi egység kora K igen
9. targyi-egyseg: eredeti-jelzet eredeti jelzet O igen
10. targyi-egyseg: kapcsolodo- kapcsolódó tárgyi egység O nem
egyseg
11. targyi-egyseg: terjedelem tárgyi egység terjedelme O nem
12. targyi-egyseg: megjegyzes tárgyi egységre vonatkozó O nem
megjegyzések
raktári egységre vonatkozó adatok
raktári jegyzéken belüli levéltári szintekre vonatkozó adatok (fond vagy állag alatt, tárgyi egység felett)
tárgyi egységre vonatkozó adatok

A darabszintű jegyzékek bevonása az adatmodellbe a tárgyi egységek szintje alatti szint beépítésével valósítható
meg, mert adattartalmuk ügyiratszinten jelentkezik. A darabszintű jegyzékeknek (pl. lajstrom) a rendszerbe
illesztéséhez feltehetően szükségesek további adatelemek. Ezek az adatelemek a tárgyi egységekre vonatkozó
adatelemek típusaival megegyeznek, csak egy szinttel lejjebb jelentkeznek.

54
 Adatelem elnevezése az XML- Adatelem meghatározása kötelező / Hagyományos
adatmodellben opcionális raktári jegyzékben
szerepel?
1. ugyirat-lvt-jelzet ügyirat levéltári jelzete K nem
2. ugyirat-cim ügyirat címe K nem
3. ugyirat-tartalom ügyirat tartalma O nem
4. ugyirat-idokor ügyirat kora K nem
5. ugyirat-eredeti_jelzet ügyirat eredeti jelzete O nem
6. kapcs-egyseg ügyirathoz kapcsolódó O nem
irategység
7. ugyirat-terjedelem ügyirat terjedelme O nem
8. ugyirat-megjegyzes ügyiratra vonatkozó O nem
megjegyzések

Technikai okokból egy ügyiratcsoportnak nevezett elemet is be kell építeni a rendszerbe. Az ügyiratcsoport két
levéltári szint, a tárgyi egységek és az ügyiratok között helyezkedik el. A tárgyilag nem tagolt iratsorozatok
adatmodellbe illesztésekor találkoztunk azzal a problémával, hogy a több raktári egységre kiterjedő tárgyi
egységek (pl. iktatott iratok) részegységeinek megkülönböztetése csak az évkörök és jelzetek felhasználásával
nem oldható meg.

8.4.2 A RAKTÁRI JEGYZÉK XML SÉMA

A következőkben a konkrét XML adatmodellt mutatjuk be, az egyszerűség kedvéért több lépésben és nem XML
formátumban, hanem vizuális séma reprezentációval. A séma ábrák megértéséhez némi útmutató szükséges. A
modell elemeket balról jobbra olvassuk, a bal oldali egység a magasabb szintű, ami a jobbra elhelyezkedőket
tartalmazza. Így jönnek létre komplex adattípusok. Emlékezzünk a példáinkban mutatott könyv adatelemre. A
27. ábrán látható a raktari-jegyzek elem, ami az altalanos-adatok és a specialis-adatok elemek
sorozata.

A jel elemek sorozatát jelenti, jelen esetben mindkét elemtípusból maximum 1 példány jelenhet meg a
raktári jegyzékben, mégpedig kötelezően az előírt sorrendben (általános majd a speciális adatok rész). Az egyes
elemeket reprezentáló téglalapokban az elem neve a felső sorban jelenik meg, az alsó sorban pedig az elem
típusát láthatjuk. A későbbiekben előforduló xs: előtaggal ellátott típusok az XML Schema névtér beépített
típusait jelentik.

27. ábra A raktári jegyzék modell legmagasabb szintje: az általános és a speciális adatokat tartalmazó adatelemek.

A modell részletesebb ismertetését a 28. ábrán látható általános adatok komplex adatelem bemutatásával
folytatjuk. Az általános rész szintén több elem sorozata. Ezek közül a legtöbb kötelező elem, de vannak opcionális

55
elemek is, mint pl. a hitelesito, gyarapodasi-azonosito, megjegyzes és a referens. A kötelező
elemeket vastag, az opcionális elemeket vékony összekötő és határvonal jelzi.

Az általános rész legérdekesebb eleme a terjedelem mező. Ez az elem hivatott leírni az irat mennyiségét
iratfolyóméterben, illetve tárolási egységekben. A szöveges típus alkalmazása tetszőleges leírásra alkalmas
lenne, azonban a gépi feldolgozást nem támogatja. A célunk az, hogy a terjedelmi egységek mértékegységgel
ellátott számolásra alkalmas adatokat jelentsenek. Nézzük például az alábbi terjedelmi leírást:

Terjedelem: 11 doboz, 13 kötet 1,23 ifm. irat, 0,25 ifm. kötet, összesen: 1,48 ifm.

Folyó szöveg helyett ezt több számszerű adat sorozataként fogjuk fel: 11 [doboz], 13 [kötet], 1,23 ifm [irat], 0,25
ifm [kötet] és 1,48 ifm. Az egységek típusa szögletes zárójelben látható, a mértékegység – ahol van – ifm. A
modellnek lehetővé kell tenni, tetszőleges számú és típusú terjedelmi egység felsorolását a raktári jegyzékben.
Ennek érdekében két terjedelmi leíró tetszőleges sorozatából építjük fel a terjedelem elemet, ahol az attribútum
írja majd le az egység típusát. A séma definíció alapján létrehozott XML leírás a terjedelem elemre a fenti példánk
esetén az alábbi XML leírást eredményezi:

<terjedelem>
<egyseg tipus="doboz">11</egyseg>
<egyseg tipus="kötet">13</egyseg>
<iratfolyometer tipus="irat">1.23</iratfolyometer>
<iratfolyometer tipus="kötet">0.25</iratfolyometer>
<iratfolyometer tipus="összesen">1.48</iratfolyometer>
</terjedelem>

Jól látható az egyes terjedelmi egységek különválása és a numerikus adatok egyértelmű megjelenése, ami által
a terjedelmi adatok feldolgozása automatizálhatóvá tehető.

Az általános adatok részben kiemelnénk még a megjegyzés elemet. Ez egy opcionális elem, aminek két
attribútuma van, az egyik a megjegyzés dátuma, a másik a megjegyzés típusa. A megjegyzések száma nem
korlátozott, így a raktári jegyzék működése során tetszőleges számú megjegyzést lehet fűzni a dokumentumhoz.
Nem szerepel a megjegyzés attribútumai között, de a jövőben megfontolandó esetleg a megjegyzés készítőjének
nevét is feltüntetni a megjegyzés adatelemben.

A speciális részt egy külön komplex adatelem írja le, a TartalomTipus-ú <speciális-adatok> elem. Ez az adatelem
tárolja az iratok leírását szolgáló adatokat. Mivel a raktári egység szerkezet változó hierarchiájú, a modell
felépítése szempontjából a legfontosabb rész ennek kezelése volt. Amint a szerkezeti elemzésben szerepelt, a
tétel a kötelező elem, ez a tárgyi egységnek felel meg. Ez szerepelhet önmagában, több példányban (több tétel)
vagy sorozat, alsorozat alá besorolva is. A 29. ábrán látszik ennek a megoldása. A speciális adatrész két opcionális
részből áll: a <leveltari-szint> illetve a <targyi-egyseg> elemekből. Mindkét elemből több példány is szerepelhet
a jegyzékben. Az elemek közül csak az egyik típus jelenik meg, vagy a <leveltari-szint> vagy a <targyi-egyseg>. Az

ábrán megjelenő jel a séma elemek közötti „választás” (choice) komponenst jelenti. Összefoglalva tehát,
egy tárgyi egység vagy önállóan jelenik meg a speciális részben, vagy előbb egy levéltári szintnek kell szerepelni
és abba beágyazva jelenhet meg vagy egy további levéltári szint vagy a tárgyi egység. A levéltári szint elemet az
opcionális jelzet és a cím elemek teszik teljessé.

A 30. ábrán látható a <targyi-egyseg> elem részletes felépítése. A tárgyi egység a korábban vázolt kötelező és
opcionális elemek sorozatából áll. A tárgyi egység legfontosabb része azonban az attribútum specifikáció, ami a
tarolasi-egyseg-tipus és tarolasi-egyseg-sorszam alatt az iratokat tartalmazó egységet, pl. „doboz” és annak
sorszámát tárolja. Ezzel a módszerrel megoldható az elmúlt évtizedek alatt létrehozott raktári jegyzékek

56
problémamentes átírása olyan elektronikus leírássá, ami egyrészt önállóan is használható, illetve lehetővé teszi
a tárolási egység és az iratanyag keresését is. Ez a módszer megjelenik az EAD szabványban is.

28. ábra A raktári jegyzék általános adatait leíró komplex sémaelem

57
29. ábra A raktári jegyzék speciális adatait leíró komplex sémaelem. A tárgyi egység elem helyszűke miatt itt nincs részletezve.

30. ábra A tárgyi egység adatait leíró komplex adatelem

58
A séma alkalmazása

A létrehozott séma hozzárendelhető a készített raktári jegyzék XML dokumentumokhoz az

xmlns:”namespace_url” deklarációval. Egy XML szerkesztő ezután képes a séma alapján előírt elemeket
felajánlani szerkesztés során, illetve ellenőrizni azok sorrendjét, a kötelező elemek és attribútumok meglétét.
Ezt ábrázolja az alábbi képernyőkép, ahol azt látjuk, hogy a 149. sorban, az alsorozat levéltári szint jelzet és cím
eleme után a címke nyitó zárójelére felugranak az ebben a pozícióban legális elemek, ezek közül mi a tárgyi
egységet illesztjük be a dokumentumba. Természetesen nem az a cél, hogy ilyen nyers formában szerkesszen
bárki is XML dokumentumokat, de a háttérben minden rendszerben ez történik.

A kész raktári jegyzék XML file megjelenítése

A raktári jegyzéket XML stílus transzformációval alakíthatjuk „emberi fogyasztásra” alkalmasra. A séma
elemeinek ismeretében az XSLT szabályoknak megfelelően létrehozott raktarijegyzek.xsl stílus file-t az
alábbi XML részleten bemutatott módon beemelve az XML dokumentumba, az egy nyomtatott dokumentumhoz
hasonló módon jelenik meg a felhasználó előtt, jelen esetben – ahogy a fenti ábrán is látható – egy web
böngészőben. Ugyanez a technika teszi lehetővé a raktári jegyzék PDF formátumra alakítását és szükség esetén
nyomtatását.

<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet type="text/xsl" href="raktarijegyzek.xsl"?>
<raktari-jegyzek xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="RaktariJegyzek.xsd">
<altalanos-adatok>
<leveltari-intezmeny>Veszprém Megyei Levéltár</leveltari-intezmeny>

...

59
31. ábra A séma alapján létrehozott példa XML raktári jegyzék megjelenítése egy web böngészőben XSLT stílus file segítségével.

Az XML raktári jegyzékek feldolgozása

A modell bemutatása nem lenne teljes annak illusztrálása nélkül, hogy a javasolt XML alapú séma, illetve az így
létrejövő elektronikus raktári jegyzék hogyan támogatja az automatikus feldolgozást, lekérdezhetőséget,
kereshetőséget. A feldolgozást, keresést az XQuery lekérdezésekkel valósíthatjuk meg az XML
dokumentumokban, ezzel adatbázis funkciókat tudunk megvalósítani XML környezetben. Összeállítottunk
néhány példa lekérdezést, amelyek illusztrálják az XML ilyen célú alkalmazhatóságát.

Keresési példák:

1. Adott év, évkör tárgyi egységeinek listázása

2. Adott jelzet keresése: pl. 1968: 4-es jelzetű irat
3. Mi található a 14. dobozban?
4. Adott szint (sorozat) iratainak listázása
5. Adott szavakra keresni a tárgyi egységek címében

60
A példákban egy konkrét raktári jegyzékben végezzük el a keresést. Természetesen ez általánosítható tetszőleges
számú raktári jegyzékben történő egyidejű keresésre is. A raktári jegyzék file neve:
jegyzek_fejlec_XXIII.897.b.xml, tartalma az alábbi képen látható.

1. példa: Adott év, évkör tárgyi egységeinek listázása

A szükséges XQuery lekérdező kifejezés:

for $x in doc("jegyzek_fejlec_XXIII.897.b.xml")//targyi-egyseg
where $x/idokor=’1968’
return $x

A keresés eredménye:

<?xml version="1.0" encoding="UTF-8"?>

<targyi-egyseg xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
tarolasi-egyseg-tipus="doboz"
tarolasi-egyseg-sorszam="14">
<jelzet>1</jelzet>
<cim>Tanácsrendeletek </cim>
<tartalom tipus="">a közterületek tisztántartásáról és a háziszemét
elhelyezéséről, a temetőkre vonatkozó általános rendelkezések, a
közterületek használatáról</tartalom>
<idokor>1968</idokor>
</targyi-egyseg>

61
 <targyi-egyseg xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
tarolasi-egyseg-tipus="doboz"
tarolasi-egyseg-sorszam="14">
<jelzet>3</jelzet>
<cim>Bevételi, zárlati kimutatások</cim>
<idokor>1968</idokor>
</targyi-egyseg>
<targyi-egyseg xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
tarolasi-egyseg-tipus="doboz"
tarolasi-egyseg-sorszam="14">
<jelzet>4</jelzet>
<cim>Költségvetés, kiadási, bevételi lapok MNB-napló</cim>
<idokor>1968</idokor>
</targyi-egyseg>
Látható, hogy mindhárom tárgyi egységet megtalálta a keresés, aminek időköre 1968. Természetesen az
eredményeket is stílus transzformáció után kell majd megjeleníteni, de itt kimondottan az a célunk, hogy
bemutassuk, hogy a keresés XML adatelemeket ad vissza eredményül, amiken akár további feldolgozási lépések
is végrehajthatók a végső megjelenítés előtt.

2. példa: Adott jelzet keresése: pl. 1968: 4-es jelzetű irat címe

A szükséges XQuery lekérdező kifejezés:

for $x in doc("jegyzek_fejlec_XXIII.897.b.xml")//targyi-egyseg
where $x/jelzet=’4’ && $x/idokor=’1968’
return $x/cim

A keresés eredménye:

<?xml version="1.0" encoding="UTF-8"?>

<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Költségvetés, kiadási, bevételi lapok MNB-napló</cim

3. példa: Mi található a 14. dobozban?

A szükséges XQuery lekérdező kifejezés:

for $x in doc("jegyzek_fejlec_XXIII.897.b.xml")//targyi-egyseg
where $x[@tarolasi-egyseg-sorszam=14] and $x[@tarolasi-egyseg-tipus='doboz']
return $x/cim

A keresés eredménye:

<?xml version="1.0" encoding="UTF-8"?>

<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Tanácsrendeletek </cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Községi Tanács VB.
munkatervei</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Állandó Bizottságok
munkatervei</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">A Tanácsköztársaság 50.
évfordulója alkalmával tartott ünnepi ülés jegyzőkönyve</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Falugyűlésről
jegyzőkönyv Sümegprága – Sümeg közös tanáccsá alakulása tárgyában</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Választói
névjegyzék</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Szavazási
jegyzőkönyvek</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Tanácstagok
nyilvántartólapjai</cim>

62
 <cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Beszámolójelentés,
zárszámadás</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Beszámolójelentés,
zárszámadás</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Bevételi, zárlati
kimutatások</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Költségvetés, kiadási,
bevételi lapok MNB-napló</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Anyagszámadások</cim>

4. példa: Adott szint (alsorozat) iratainak listázása

A szükséges XQuery lekérdező kifejezés:

for $x in doc("jegyzek_fejlec_XXIII.897.b.xml")//targyi-egyseg[@szint='alsorozat']
return $x/targyi-egyseg/cim

A keresés eredménye:

<?xml version="1.0" encoding="UTF-8"?>

<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Iratok</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Tanácsrendeletek </cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Községi Tanács VB.
munkatervei</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Állandó Bizottságok
munkatervei</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">A Tanácsköztársaság 50.
évfordulója alkalmával tartott ünnepi ülés jegyzőkönyve</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Falugyűlésről
jegyzőkönyv Sümegprága – Sümeg közös tanáccsá alakulása tárgyában</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Választói
névjegyzék</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Szavazási
jegyzőkönyvek</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Tanácstagok
nyilvántartólapjai</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Beszámolójelentés,
zárszámadás</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Beszámolójelentés,
zárszámadás</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Bevételi, zárlati
kimutatások</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Költségvetés, kiadási,
bevételi lapok MNB-napló</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Anyagszámadások</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">KÖFA hátralékosokról
kimutatás</cim>
<cim xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">KÖFA hozzájárulás
fizetéséről tanácshatározat</cim>

8.5 SPECIFIKUS JEGYZÉKEK LÉTREHOZÁSA

A hagyományos középszintű raktári jegyzékek mellett további jegyzéktípusok is használatosak a levéltárakban.

Azt gondoljuk, hogy a javasolt modell képes ezeket is integrálni. Ezeknek a specifikus jegyzékeknek az egyik
csoportja ugyanazokat a kötelező adatelemeket tartalmazza, mint amiket a raktári jegyzék alapmodellje. Annyi
a különbség, hogy néhány plusz adatelem szükséges a jegyzék elkészítéséhez. Példák ezekre a jegyzéktípusokra
az alábbiak:

63
  tanácsi jegyzőkönyvek
 tanácsi segédletek
 telekkönyvi iratok
 tervdokumentáció
 vállalati iratok
 földhivatali iratok
 földnyilvántartási iratok
 kéziratos dolgozatok gyűjteménye
 polgármesteri iratok

A rendszer véleményünk szerint képes befogadni a darabszintű jegyzékek jelentős részét is, ehhez a tárgyi egység
szint alatt el kell helyezni egy újabb szintet, az ügyiratok szintjét. Példák ilyen jegyzéktípusokra:
 tematikai elenchusok
 építési ügyek lajstroma
 községek és községi tanácsok iratainak lajstroma
 bűnügyi lajstrom
 névmutatók
 regeszták
Mivel az XML egy bővíthető adatmodell leíró nyelv, a raktári jegyzék modellből is készíthetők további jegyzék
típusok, vagyis sémák. Ezek elkészítése során felhasználhatjuk az alap raktári jegyzék séma különböző
elemtípusait, szükség esetén azokat kiegészítve új adatelemekkel, új – ún. származtatott – típusokat hozhatunk
létre az egyes specifikus jegyzékek leírására. Ennek a részleteibe itt most nem megyünk bele, ennek részletes
kidolgozása egy következő tervezési szakasz feladata lehet.

9 RAKTÁRI JEGYZÉKEK KEZELÉSÉNEK MUNKAFOL YAMAT TÁMOGATÁSA

A 2.6 alfejezetben bemutattuk, hogy jelenleg miként folynak levéltárunkban a raktári jegyzékek készítési,
ellenőrzési, érvényesítési és kezelési munkafázisai. Amint tanulmányunkban többször említettük, az elektronikus
jegyzékkészítésnek akkor van értelme, ha ez megfelelő számítógépes támogatás segítségével hatékonyabbá teszi
a levéltárak működését. Ideális esetben a raktári jegyzékekkel végzett munka teljes folyamatának irányítását egy
elektronikus dokumentumkezelő rendszer végezhetné. Ennek megvalósulása esetén több, ma még jelentős
időráfordítást igénylő munkafázis kiiktatható, illetve automatizálható. A levéltári jegyzékek nagy száma és
központi szerepe miatt olyan számítógépes infrastruktúrára van szükség, ami biztosítja:

 a raktári jegyzékek szerkezeti hibáktól mentes létrehozását,

 a raktári jegyzékek ellenőrzését és javítását,
 a lekérdezést,
 a kutatók számára adatok publikálását és a kereshetőség biztosítását,
 a jegyzékek kezelési munkafolyamatának támogatását,
 az adatbázis támogatást,
 az adatok biztonságát, a hozzáférés szabályozását,
 a jegyzékek nyomtatási lehetőségét, valamint
 az adatcsere lehetőségét más rendszerekkel.

A fenti funkciókat biztosító rendszer megtervezéséhez érdemes áttekinteni az elvárásokat a levéltári munka, az
optimális számítógépes munkavégzés biztosítása szempontjából. A rendszer legfontosabb feladata a raktári
jegyzék elkészítésének támogatása lenne. Vegyük sorra, hogy ez a folyamat milyen lépésekből is áll.

64
A munkafolyamat elején a kijelölt levéltári egység rendezése során a levéltáros elkészíti a raktári jegyzéket. A
jegyzék adatait egy felhasználóbarát adatbevivő felületen rögzíti. Az általános adatok nagy része az adatbázisban
előre rögzíthető, így pl. egy legördülő menüből kiválasztható, így minimalizálható a gépelési munka, kizárható az
elírás, betűtévesztés. Jobbára a speciális adatelemek rögzítésekor kell többet gépelni. Az adatbázis előnye, hogy
a formai szempontokra kevésbé kell figyelnie az adatbevivőnek, mert a rendszer a bevitt adatok
megjelenítésekor a formát automatikusan szolgáltatja. Ezáltal az ellenőrzési folyamat is egyszerűsödik, mert a
formai ellenőrzés elhagyható, az ellenőrzést végzőnek csak a tartalmi hibákat kell kiszűrnie (pl. megfelelő-e a
tárgyi egységek kialakítása, szakszerű-e a címadás stb.). A jegyzék ugyanis a begépeléssel még nem tekinthető
késznek, azt előbb ellenőriznie kell az arra kijelölt felelősnek. Az ellenőrző személy vissza is küldheti a jegyzéket
javításra.

A jegyzék ellenőrzésre küldése, javításra visszaküldése, a javítás után ellenőrzésre való újra beküldése, és végül
az érvényesítés is a munkafelületen egy gombnyomásra történhetne. A munkafázisok zárt rendszerben a jegyzék
fizikai mozgása nélkül folynak, így a jegyzék biztonságban van, kisebb a hibák és az adatvesztés valószínűsége. A
jogosultságok beállításával a hozzáférés is megfelelően szabályozható. A dokumentumkezelés fontos része, hogy
az érvényes jegyzékek publikálása is egyszerűen történjen, ezért az adatbázisnak tudni kell kapcsolódni ahhoz a
rendszerhez, ahol a kutatók az érvényes, publikálható jegyzékekhez hozzáférhetnek. Természetesen az érvényes
jegyzékek rendszerében lehetséges az összes jegyzék tartalmában való együttes és összetett keresés. A
dokumentumkezelő rendszer egyszerűbbé teheti a nyilvántartási feladatokat és különösen az abból történő
adatszolgáltatást is. A rendszerbe bekerült jegyzékek leszűrhetőek lehetnének a típusuk, a keletkezés éve, a
rendezettség szintje, a készítő vagy a referens személye szerint. Elvárás egy ilyen rendszerrel szemben, hogy a
találatokat kilistázza, valamint a szűrés eredményéről összesített adatokat közöljön, például hány darab jegyzék
található a lekérdezett kategóriában, hány iratfolyóméter irat tartozik a leszűrt jegyzékekhez stb. A jegyzékek
egyenkénti nyomtatási lehetőségét is meg kell teremteni, célszerű a nyomtatási képet a hagyományos formához
közelíteni. A rendszer támogatja a már elektronikus formában létező jegyzékek integrálását, illetve az írógéppel
készült papíralapú jegyzékek karakterfelismerés segítségével történő elektronizálását.

A fent megfogalmazott elvárások, funkciók és az előző fejezetben ismertetett XML adatmodell előnyei alapján
úgy gondoljuk, hogy egy olyan XML dokumentumokra és XML adatbázisra épülő rendszert kellene létrehozni,
amelynek magas szintű, logikai felépítése az alábbi ábrán látható. A részletes tervezés nem e tanulmány feladata,
itt csak annyit említenénk meg, hogy a mai modern web technológiákkal egy ilyen sokfelhasználós rendszer
létrehozható.

65
 Belső levéltári rendszer Külső, publikus rendszer
Új jegyzék Kereső
beviteli modul
modul

Kereső,
XML lekérdező
Szkennelés OCR
Eredeti jegyzék program
gépelt adatséma
jegyzék
Manuális
adatbevitel

Word XML
XML
formátumú Konvertálás formátumú
adatbázis
jegyzék jegyzék

Excel Belső adatfeldolgozó, Külső adatfeldolgozó,

formátumú Konvertálás adatfelhasználó adatfelhasználó
jegyzék programok programok

32. ábra A raktári jegyzék feldolgozását, használatát támogató adatbázis rendszer logikai felépítése.

Ennek illusztrálására bemutatunk néhány érdekesebb részletet abból a raktári jegyzék feldolgozó prototípus
programból, amelyet a Veszprém Megyei Levéltár és a Pannon Egyetem közösen fejlesztett ki. A projekt
keretében feltérképeztük a levéltár raktári jegyzék készítési munkafolyamatát, ami a 333. ábrán látható.

33. ábra A raktári jegyzék készítésének munkafolyamata.

A vázolt munkafolyamat végrehajtása kezdetben Word/Excel állományok elektronikus levél csatolmányként

küldésével történt. Később ez egyszerűsödött, a levéltár belső hálózatán megosztott közös mappák
használatával. A prototípus rendszerben minden jegyzéken dolgozó felhasználó azonosítóval rendelkezik, így a
belépés után egyedi munkafelületen keresztül végezheti a munkáját. Az egyedi felület egyrészt lehetővé teszi a
jegyzékek keresését, lekérdezését, másrészt megjeleníti a felhasználóhoz kötődő jegyzékek státuszát, a

66
szerkesztés alatt lévő, ellenőrzésre vagy javításra váró jegyzékek listáját. A felhasználók egy-egy feladat
végeztével egy dokumentumot gombnyomással „küldhetnek” a megfelelő további feldolgozási szakaszba.

34. ábra A feldolgozó rendszer képernyői és az azok közötti navigációs kapcsolatok.

A jegyzékek egy XML adatbázisban tárolódnak, a rendszert soha nem hagyják el, csak a belső állapotuk változik.
A felhasználók természetesen soha nem látják a nyers XML formátumú jegyzéket. A feldolgozó felhasználók
űrlapon tudják bevinni az adatokat, a megjelenítés pedig a szöveges nézetnek megfelelő formátumban történik.

35. ábra Példa űrlap felület a raktári jegyzék elkészítésére.

A prototípus rendszer igazolta az XML jegyzék valamint a kapcsolódó XML technológiák használatának
létjogosultságát. Mivel kísérleti rendszerről van szó, ez jelenlegi állapotában nem alkalmas országos méretű
alkalmazás céljaira, azonban az így nyert tapasztalatok segíthetnek egy valóban korszerű, hatékony és
megbízható feldolgozó rendszer kialakításában.

67
10 ÖSSZEFOGLALÁS

Tanulmányunk első részében megvizsgáltuk a raktári jegyzék szerepét a magyar levéltári gyakorlatban.
Végigkövettük a raktári jegyzék kialakulását, fejlődését a kezdetektől, elemeztük szerkezetének változásait.
Tettük ezt azért, mert meggyőződésünk, hogy az előzmények alapos ismerete nélkül nem lehet olyan digitális
modellt építeni, amely a szükséges módon és mértékben alkalmas a raktári jegyzék funkcióinak jövőbeni
ellátására. Úgy véljük, minden problémája ellenére biztosítani kell e segédlettípusnak a kontinuitást, és a benne
foglalt levéltári tartalmak zökkenőmentes átvitelét elektronikus formába. Azért sem lenne célszerű gyökeresen
elszakadni a raktári jegyzék struktúrájától, mert levéltárainkban rengeteg kész raktári jegyzék vár arra, hogy
digitális formában is elérhetővé váljon. Tény, hogy a fond- és állagszint alatti levéltári egységekről készült
jegyzékek tartalmát akár – a nemzetközi szabványnak teljes mértékben megfelelő – levéltári leírással is
leírhatjuk. Egyrészt azonban a napi gyakorlat azt mutatja, hogy a gyors tájékoztatásban, az iratanyagok mielőbbi
megtalálásában, kiemelésében a raktári jegyzékek jó szolgálatot tesznek. Másrészt hosszú évek fognak eltelni
még addig, mire a levéltárosok a levéltári leírásokat mindazon iratanyagokról elkészítik, amelyekről a raktári
jegyzékek már jelenleg is rendelkezésre állnak. Így a vizsgálódásaink alapján arra jutottunk, hogy jelenleg
ésszerűbbnek tűnik a raktári jegyzékek digitális alakváltozását minél fejlettebb formában megvalósítani,
mintsem teljesen átalakítani azokat valamilyen új típusú segédletté.

A tanulmány második részében megmutattuk a leírásra felhasználható alternatív informatikai technológiákat és

megindokoltuk, hogy miért az XML alapú leírás jelenti a legbiztosabb formátumot a raktári jegyzék számára. Az
XML adatleíró nyelvre építve olyan komplex technológia áll rendelkezésre, amely platformfüggetlen, valamint
rendkívüli rugalmasság és bővíthetőség jellemzi. További előnye, hogy szerényebb informatikai ismeretekkel
rendelkezők is átláthatják és akár alkalmazhatják is, hiszen számos ingyenes, az interneten elérhető alkalmazás
épül az XML technológiára. Mindamellett különösen érdekes egy levéltáros számára, hogy az XML meglehetősen
sok hasonlóságot mutat a levéltártan rendszerelméletével.

A tanulmány harmadik részében tartalmi, szerkezeti és szabvány szempontú elemzést végeztünk. Majd erre
alapozva létrehoztuk a raktári jegyzék logikai modelljét, és erre definiáltuk az adatmodellt leíró sémát. A séma
alapján létrehozható a megújított tartalmú és szerkezetű raktári jegyzék (vagy raktári nyilvántartás). Úgy véljük,
hogy megoldottuk a raktári egységek és levéltári egységek logikai kapcsolatának dilemmáját, hiszen
adatmodellünkben a tárolási egység már nem képezi a jegyzék „gerincét”. Megfordítottuk a fontossági
sorrendet, a levéltári egységek hierarchikus elrendezésére és ennek leírására épül a modell, és a levéltári
egységekhez rendelődik hozzá attribútumként a raktári egység információ.

Elemeztük a raktári jegyzék jövőbeli helyét a digitális levéltári környezetben, amihez felhasználtuk a Veszprém
Megyei Levéltár és a Pannon Egyetem együttműködése során tervezett komplex dokumentumkezelő rendszerrel
végzett kísérleteinket. Felvázoltuk a raktári jegyzékkel kapcsolatos munkavégzés számunkra optimálisnak tűnő
útját. Majd javaslatot tettünk a raktári jegyzék feldolgozásának munkafolyamat támogatására, és bemutattunk
egy lehetséges web alapú rendszert, amely a napi feldolgozást szervezi.

A tanulmányunkban leírtakra alapozva javaslatunk a levéltáros szakma számára a következő. Úgy látjuk, hogy a
raktári jegyzékek létrehozásában, megjelenítésében és kezelésében az XML adatleíró nyelvre épülő technológia
és séma alkalmazása, valamint az erre való áttérés hosszútávon a levéltárak érdekeit szolgálja. Azonban ebben
a szakmai közösségnek konszenzusra kell jutnia, el kell dönteni, hogy kívánnak-e a levéltárak ebbe az irányba
egységesen elmozdulni. Részünkről ez nem egy kész, végleges megoldás, csak az első javaslat. A levéltáros
szakmának meg kellene vizsgálnia a javaslat életképességét, szükségességét, előnyeit és hátrányait. Ha a döntés
pozitív, vagyis ez a modell (vagy egy hasonló alapokon álló) érdemes a fejlesztésre, és széles körben
elfogadtatható, akkor lehet egy végleges szabványos leírási modellt létrehozni, és ez alapján akár egy teljes
dokumentumkezelő rendszert is kialakítani. Ha végleges modell és szilárd levéltári és informatikai szabvány áll
majd rendelkezésre, akkor érdemes mélyreható elemzést végezni a meglévő papíralapú és elektronikus

68
jegyzékeknek a rendszerbe való bedolgozásáról, migrálásáról. Emiatt ezzel a kérdéssel nem is tartottuk
érdemesnek most részleteiben foglalkozni.

A módszertani tanulmányban leírt adatmodell bárhogyan alakítható, nem tekintjük véglegesnek. Amellett, hogy
szerettük volna szélesebb körben is megosztani tapasztalatainkat, gondolatébresztőnek is szántuk. Amennyiben
elképzelésünk megvalósításra és bevezetésre alkalmasnak találtatik, abban az esetben egy következő körben azt
javasoljuk, hogy egy munkabizottság véglegesítse a raktári jegyzék adatmodellt és sémát. Jöjjön létre egy új
szabvány, amely végérvényesen leválthatja a már több mint negyvenéves munkautasítást. Adatmodellünket úgy
terveztük, hogy önállóan is megálljon, működőképes legyen. Arra nem volt lehetőségünk, hogy a közelmúltban
bevezetett új nyilvántartórendszerrel, a ScopeArchivval vagy más adatbázisokkal való együttműködést is
megvizsgálhassuk. Nem tudhatjuk, hogyan működik majd az összekapcsolás. Mindenesetre ez is egyike a soron
következő feladatoknak. Feltétlenül meg kell vizsgálni, hogy az XML-alapú rendszer megvalósítható-e a
ScopeArchiv rendszerében. Ha igen, akkor azon belül érdemes megvalósítani, ha nem, akkor egy külső
informatikai rendszer bevezetését érdemes mérlegelni a raktári jegyzékek számára. Ez utóbbi kifejlesztése egy
későbbi szakaszban valósulhat meg.

Végezetül köszönetünket szeretnénk kinyilvánítani a Nemzeti Kulturális Alapnak, hogy feldolgozásra

érdemesnek találta a témát, és támogatta tanulmányunk elkészítését. Köszönjük a Magyar Nemzeti Levéltár
Veszprém Megyei Levéltárának a levéltárszakmai, a Pannon Egyetem Műszaki Informatikai Kara
Villamosmérnöki és Információs Rendszerek Tanszékének az informatikatudományi támogatást.

69
11 MELLÉKLETEK

1. A csajági körjegyzőség iratainak raktári jegyzéke (MNL VeML V.321.) 1. ábra, 4 oldal
2. A nemesi felkelés iratainak raktári jegyzéke (MNL VeML IV.1.f) 2. ábra, 3 oldal
3. A ciszter rend zirci hittudományi főiskolája iratainak raktári jegyzéke (MNL VeML VIII.1.) 3-4. ábrák, 2
oldal
4. Veszprém Város Tanácsának adóügyi iratainak raktári jegyzékei (MNL VeML V.142.f) 5.a-b, 6. ábrák, 8
oldal
5. A Kolontári Községi Tanács iratai (MNL VeML XXIII.814.b) Word formátumú raktári jegyzék, 6 oldal
6. A Sümegprágai Községi Tanács iratai (MNL VeML XXIII.897.b) mintajegyzék a 8.4. fejezethez, 7 oldal
7. A Devecseri Községi Tanács iratai (MNL VeML XXIII.763.b) Excel formátumú raktári jegyzék
8. XML adatok

Rövidítés: MNL VeML = A Magyar Nemzeti Levéltár Veszprém Megyei Levéltára

70