Online publikálás (metaadatok és keretprogramok)

Mi a metaadat?

A metaadat fogalmának meghatározása bizonyos szempontból rendkívül egyszerű. Használatakor azonban tudatában kell lennünk annak a ténynek, hogy a metaadat fogalmát nem feltétlenül azonos tartalommal használják különböző kontextusokban, különböző szakterületek közösségei és szakirodalmai.

A fogalom egyszerű meghatározása szerint a metaadat adat az adatról, azaz információ az információról, vagy strukturált adat az adatról.

Ez az egyszerű, és letisztult definíció megfelelően kifejezi a metaadat fogalmának tartalmát, azonban messze nem elegendő ahhoz, hogy megértsük a fogalom minden részletét, illetve a metaadatok funkcióját és lényegét. Néhány konkrét példán keresztül nézzük meg, milyen típusú adatok lehetnek metaadatok. A konkrét példák ismeretében könnyebb lesz megérteni a metaadat pontosabb, árnyaltabb, tudományosabb meghatározásait, illetve a metaadat fogalma körül leggyakrabban felmerülő elméleti kérdéseket.

A digitális fényképezőgépek a fotózás pillanatában automatikusan tárolnak bizonyos információkat az elkészült digitális képpel, azaz digitális fájllal kapcsolatban. Ilyen információk lehetnek:

  • a digitális kép elkészítésének időpontja,

  • a kép felbontása,

  • a fájl típusa,

  • a fájl mérete.

Ezek az adatok metaadatok, mégpedig automatikusan generált metaadatok, és elsősorban a digitális dokumentumról szóló technikai információkat tartalmaznak.

Okostelefonnal készített fotók esetében megfelelő beállítás esetén a digitális kép készítésének pontos helyét is tárolja telefonunk. Ezen túl felhasználóként mi is megadhatunk további információkat a képről: így például megadhatjuk a képen szereplő személyek nevét. Ezzel a tevékenységgel metaadatokat hozunk létre, amelyek ez esetben nem technikai adatokat tartalmaznak, hanem leíró információkat adnak a digitális képről. Ezek a leíró adatok segítik a kép további felhasználhatóságát, ugyanakkor visszakereshetőségét is.

Az MP3, vagy MP4 lejátszó is metaadatokon keresztül szolgáltat számunkra információkat a rajta tárolt audio fájlokról. A lejátszó kijelzőjén megtekinthetjük az adott audio fájlban tárolt dal címét, előadóját, időbeli hosszát, vagy akár zenei műfaját is. Ezek is metaadatok, amelyek azzal a céllal jöttek létre, hogy könnyen megtaláljuk például egy adott szerző dalait (visszakereshetőség), vagy hogy egy könyvtárba gyűjthessük egy adott zenei műfaj műveit (böngészés).

Szintén metaadatok segítségével tudjuk könnyen visszakereshetővé, és elérhetővé tenni a digitális könyvtárak digitális dokumentumait (digitalizált könyveket, térképeket, fotókat stb.).

Figure 5.3. Egy térkép digitalizált változatát leíró metaadat rekord

Egy térkép digitalizált változatát leíró metaadat rekord


http://ganymedes.lib.unideb.hu:8080/dea/handle/2437/100384 Egy példa metaadat rekord, amely egy térkép digitalizált változatáról tartalmaz adatokat.

Az itt alkalmazott metaadatok az adott információforrás – jelen esetben a digitalizált térkép – készítőiről, címéről, kiadási helyéről stb. tartalmaznak információkat.

A konkrét példák ismeretében térjünk vissza a metaadat fogalmához.

A metaadat fogalmának mai értelmezés szerinti első megjelenése – azaz a metaadat, mint „adat az adatról” értelmű első használata – a NASA Directory Interchange Format Manual 1988-as kiadásához köthető. A fogalom ilyen értelmű használata 1994-ben a Federal Geographic Data Committee Content Standard for Digital Geospatial Metadata c. kiadványában jelenik meg ismét. Természetesen az internet és a web egyre gyorsuló terjedésével a metaadat fogalmának használata is egyre gyakoribb. A fogalom a könyvtárinformatika területén a Dublin Core szabvány 1995-ben történő elindulásával válik egyre szélesebb körben ismertté és használatossá.

A fogalom alapvető tulajdonsága, hogy a számítástechnika tudományterületéről indult el, és csak később vált használatossá az információtudomány, a könyvtártudomány, és egyéb tudományterületek által. Részben ebből adódik, hogy a különböző tudományágak közösségei, és a különböző szakirodalmak nem feltétlenül azonos tartalommal használják.

A metaadat fogalmát már sokan, sokféleképpen megfogalmazták. Néhány részletes definíciót érdemes megnéznünk.

Priscilla Caplan meghatározása szerint a metaadat nem más, mint „strukturált információ valamely elektronikus vagy nem elektronikus információforrásról, amely információforrás hordozóközege bármilyen típusú vagy formátumú lehet”.

W3C meghatározása ettől eltérő: „A metaadat gép által értelmezhető információ a web számára.” Eredeti nyelven: „Metadata is machine understandable information for the web.” http://www.w3.org/Metadata/

NISO (National Information Standards Organization): „A metaadat olyan strukturált információ, amely leírja, magyarázza, elhelyezi, vagy egyéb módokon teszi könnyebbé az információforrás visszakeresését, használatát, vagy menedzselését. A metaadatot leginkább úgy határozzák meg, mint adat az adatról, vagy információ az információról.” http://www.niso.org/publications/press/UnderstandingMetadata.pdf (Letöltve: 2013.01.29.)

Nézzük meg részletesen, milyen tulajdonságok jellemzik a metaadatot, és milyen elvi kérdéseket vet fel a fogalom meghatározása.

Azon túl, hogy a metaadat adat az adatról, fontos, hogy meghatározott szerkezettel rendelkezzen, azaz strukturált legyen.

A metaadat fontos tulajdonsága, hogy elkülönül az információforrástól, amelyről adatokat tartalmaz, még akkor is, ha valamilyen módon be van ágyazva az adott információforrásba (pl. HTML dokumentumok esetében).

A metaadatnak két alkotóeleme van: a metaadat elem (vagy tulajdonság) és a metaadat érték (vagy tartalom).

A következő táblázat néhány metaadat elemet és azok értékeit mutatja, amelyek egy adott digitális információforrásról adnak információkat:

Metaadat elemekMetaadat értékek
CímVándorlásaim és élményeim Persiában
SzerzőVámbéry Ármin
TárgyszóIrán--leírás és utazás
Dátum1867
Formátumbook
Nyelvhun
Azonosítóhttp://hdl.handle.net/2437/99075

Az egy adott információforrásról szóló metaadatok összessége a metaadatrekord. A metaadatrekord, mint egység leginkább a könyvtáros közösségek, és a katalogizálással foglalkozók számára természetes megközelítés. (Más megközelítés szerint a metaadatok egységeit inkább a metaadat elem – metaadat érték párok jelentik. Ez a szemantikus web számára alkalmas megközelítés, hiszen a metaadat elem és annak értéke tulajdonképpen az adott információforrásról szóló egy-egy állításként értelmezhető. Erről részletesebben később.)

A metaadatok célja, hogy könnyebben visszakereshetővé, használhatóvá, menedzselhetővé tegyék az információforrásokat. Ezt sokféle módon szolgálhatják, ennek megfelelően a metaadatokat funkciójuk, és céljuk szerint több típusba sorolhatjuk.

Metaadat típusok:

  • leíró,

  • adminisztrációs,

  • szerkezeti,

  • technikai,

  • megőrzési,

  • jogok, jogosultságok menedzseléséhez kötődő metaadatok (vagy szellemi tulajdonjo-gok metaadatai).

A metaadat típusokkal a későbbiekben foglalkozunk részletesen.

A metaadat fogalmával kapcsolatban gyakran felmerülő kérdés, hogy vajon csak a digitális információforrásokat leíró adatok nevezhetőek metaadatnak, vagy bármely információforrást leíró adat metaadat? Másik felmerülő kérdés, hogy magának a metaadatnak/ metaadatrekordnak digitálisnak kell-e lennie? Mindkét kérdésről megoszlanak a vélemények, és fontos tudnunk, hogy más-más kontextusban és más-más közösségben eltérőek lehetnek a kérdések megítélései.

Ha végiggondoljuk, akkor a „legmegengedőbb” megközelítés szerint – azaz, ha sem az infor-mációforrásnak, sem a metaadatnak nem kötelező digitális formátumúnak lennie – a könyvtárak katalóguscéduláin feltüntetett adatokat is metaadatoknak tekinthetjük. Szintén annak tekinthetők a könyvtárak online katalógusaiban tárolt bibliográfiai rekordok – amelyek önmaguk ugyan digitális formátumúak, viszont az általuk leírt információforrások nem feltétlenül digitálisak, azaz lehetnek nyomtatott könyvek, térképek, vagy folyóiratok is.

Metaadatok típusai

A metaadatokat funkcióik szerint típusokba sorolhatjuk. A legáltalánosabb nézet szerint három alap metaadat típust érdemes megkülönböztetni:

  • leíró metaadatok,

  • adminisztrációs metaadatok,

  • szerkezeti metaadatok.

Az adminisztrációs metaadat típuson belül további három altípust szokás megkülönböztetni:

  • technikai metaadatok,

  • megőrzési metaadatok,

  • jogok, jogosultságok menedzseléséhez kötődő metaadatok (vagy szellemi tulajdon-jogok metaadatai).

Egyes szakirodalmak megkülönböztetnek egy negyedik altípusi is: a felhasználással kapcsolatos metaadatokat. Más szakirodalmak viszont ezeket az altípusokat egy szinten kezelik az előbb említett alap típusokkal.

Tulajdonképpen nincs túl nagy jelentősége a típusok pontos elméleti besorolásának, elhatárolásának, hiszen a metaadatok típus szerinti megközelítésének gyakorlati szempontból van valódi jelentősége. Az egyes metaadat típusok egymástól való elhatárolódása nem éles és sokszor nem is egyértelmű, sokszor átfedéseket tapasztalunk a típusok között.

Leíró metaadatok (descriptive metadata)

A leíró metaadatok legfontosabb funkciója, hogy olyan tulajdonságokat tartalmazzanak az információforrásról, amelyek alapján biztosított az adott információforrás megtalálása, visz-szakereshetősége. A leíró metaadatok azok a metaadat elemek, amelyek leírják, indexelik, vagy katalogizálják az információforrást.

Tulajdonképpen a klasszikus könyvtári katalógusban megtalálható bibliográfiai rekordok által tárolt adatok is leíró metaadatok. Így tehát leíró metaadat lehet: az adott információforrás címe, szerzője, hozzá kapcsolható tárgyszavak, de a létrehozás dátuma, vagy a digitális fájl formátuma is ide tartozhat.

A könyvtáros szakma sokáig szinte csak a leíró funkciókat tartotta fontosnak a metaadatok tekintetében, éppen ezért az ilyen típusú metaadat sémákat preferálta, így a Dublin Core-t, vagy a VRA-t.

A leíró metaadatok másik funkciója az azonosítás. Ez egyrészt jelentheti az adott digitális dokumentum tartalmának azonosítását, leírását, másrészt jelentheti az adott információforrás megkülönböztetését más hasonló dokumentumoktól.

A leíró metaadatok célja lehet még a kiválasztás/szelekció biztosítása, azaz annak meghatározása, hogy az adott dokumentum milyen speciális igényeket elégít ki (pl.: az adott információforrás egy videó felvétel DVD verziója).

A leíró metaadatok legfontosabb funkciói tehát:

  • visszakereshetőség, megtalálás,

  • azonosítás,

  • kiválasztás/szelekció.

A leíró metaadatok kevésbé általános funkciói lehetnek még:

  • értékelés,

  • összekapcsolás,

  • felhasználhatóság.

Az értékelés jelentheti az információforrás (egy könyv, vagy egy mozifilm) értékelését akár narratív formában, akár valamely szabvány szerinti skála használatával.

Az összekapcsolás különböző információforrások közötti kapcsolatok létrehozását jelenti. Így például jelentheti egy adott mű különböző kiadásainak, különböző fordításainak, vagy különböző változatainak összekapcsolását. De jelentheti egy adott forrás különböző formátumban való megjelenéseinek összekapcsolását – így például összekapcsolható egymással egy adott épület, illetve az épületről készült fotó, és a fotóról készült digitális másolat is.

A felhasználhatóság funkcióban a leíró metaadatok a felhasználó személy számára adnak információkat arra vonatkozóan, hogy az adott információforrást milyen eszközök segítségével tudja használni. Így például egy digitalizált könyv esetében arról, hogy milyen program használata szükséges ahhoz, hogy a könyvet elolvashassa a felhasználó. Leíró metaadat sémák: DC, VRA

Adminisztrációs (adminisztratív) metaadatok (administrative metadata)

Az adminisztrációs metaadatok a digitális tartalmak menedzseléséhez szükséges információkat tartalmazzák. Céljuk tehát a digitális tartalmak menedzselésének biztosítás, segítése. Ezt a célt a következő funkciókon keresztül érik el:

  • digitális dokumentum technikai adatinak tárolása,

  • digitális dokumentumon végzett változtatások végigkövetése,

  • hozzáférés szabályozása,

  • az információforráshoz, és ahhoz való hozzáféréshez köthető felelősségek meghatározása, és szabályozása.

Néhány példa arra, milyen típusú adatokat tartalmazhatnak az adminisztrációs metaadatok:

  • mikor, és hogyan készült el a dokumentum,

  • ki felelős a hozzáférhetőség megfelelő beállításáért és fenntartásáért,

  • ki felelős a tartalom archiválásáért,

  • milyen tevékenységek történtek meg a fenti célok érdekében,

  • milyen hozzáférési határok, jogosultsági szintek tartoznak a dokumentumhoz,

  • a mesterfájl, a megjelenítési fájl, vagy a bélyegkép megnevezése

Az adminisztrációs metaadat típus további altípusokra bontható:

  • technikai metaadatok,

  • megőrzési metaadatok,

  • jogok, jogosultságok menedzseléséhez kötődő metaadatok (vagy szellemi tulajdonjogok metaadatai),

  • felhasználási metaadatok (csak néhány szakirodalom különbözteti meg ezt a csoportot).

A technikai metaadatok a digitális fájl (fájlok) technikai adatait, paramétereit, jellegzetességeit tartalmazzák, illetve a fájl létrehozásának technikai körülményeit, és a fájlon elvégzett változtatások fázisait, adatait. Ilyen adat lehet például a digitalizálásra használt szkenner típusa, a mesterfájl felbontása, színmélysége, vagy a képen elvégzett szerkesztésekhez használt programok megnevezése is.

A megőrzési metaadatok az információforrás hosszú távú megőrzéséhez szükséges adatokat tárolják. A megőrzési metaadatoknak tulajdonképpen fontos részét képezik a technikai metaadatok, hiszen az adott digitális dokumentum technikai adatainak ismerete elengedhetetlenül szükséges a hosszú távú megőrzéshez – így akár a digitális fájl migrálásához, vagy más, az információforrás hosszú távú felhasználhatóságát biztosító tevékenységek elvégzéséhez.

A jogok, jogosultságok menedzseléséhez kötődő metaadatok természetesen a nevükben megjelölt funkciót elősegítő információkat tartalmazzák.

Néhány szakirodalom szerint az adminisztrációs metaadatoknak létezik egy negyedik altípusa is: a felhasználási metaadatok. A felhasználási metaadatok az információforrás használatához köthető adatokat tartalmazzák. Ilyen adat lehet például, hogy az információforrást hányszor tekintették meg. A felhasználási metaadatok sokszor átfedést képeznek a jogok, jogosultságok menedzselését biztosító metaadatokkal.

Az adminisztrációs és a leíró metaadatok közötti alapvető különbség az, hogy a leíró metaadatok elsősorban a felhasználók keresési, böngészési tevékenységeit szolgálják és ennek megfelelően általában publikus hozzáférésű keresőrendszerekben bárki által láthatóak, kereshetőek, és hozzáférhetőek. Az adminisztrációs metaadatok viszont a digitális gyűjteményt menedzselő szakemberek tevékenységeit szolgálják, és általában rejtve maradnak a gyűjtemény felhasználói számára.

A két típus közötti határok azonban nem mindig élesek. Sokszor az adott metaadatot felhasználó személy adott tevékenységétől, céljától, nézőpontjától függ, hogy a metaadat az adott esetben leíró, vagy adminisztratív metaadatként funkcionál-e. Például egy hozzáférési azonosítószám lehet leíró metaadat, hiszen azonosító funkciója is van, ugyanakkor a hozzáférés szempontjából adminisztratív funkciót lát el. A nem mindig egyértelmű határok ellenére fontos és hasznos a két metaadat típus megkülönböztetése, hiszen különböző metaadat sémákban szabályozottak, valamint egymástól eltérő rendszerekben, egymástól eltérő feladatokat ellátó csoportok használják őket.

Adminisztrációs metaadat séma: A-Core (DC) Megőrzési metaadatok leggyakrabban használt metaadat sémája: PREMIS

Szerkezeti vagy strukturális metaadatok (structural metadata)

A szerkezeti metaadat az összetett digitális dokumentumokat összetartó „erő”, amely leírja az összetett digitális információforrás egyes elemei közötti kapcsolatokat, hogy azok megfelelő megjelenítése biztosítva legyen. Ezek a metaadatok tehát a komplex digitális dokumentumok belső szerkezetét írják le, arról tartalmaznak információkat. Szintén a szerkezeti metaadatok segítségével kapcsolhatóak össze az egy adott objektumról, de különböző nézetekből (elölről, hátulról, oldalról stb.) készített digitális képek is. A szerkezeti metaadatok gépek, programok, szoftverek számára szolgáltatnak adatokat, hogy azok képesek legyenek létrehozni a komplex digitális dokumentum megfelelő megjelenítését.

A megjelenítő szoftverek tehát a szerkezeti metaadatok által tárolt adatok alapján végzik el például az oldalanként egy-egy fájlban tárolt könyv egyes oldalainak megfelelő sorrendű megjelenítését, és ezek alapján teszik lehetővé az ilyen típusú könyvekben való előre és hátra lapozást. Ezek a metaadatok biztosítják azt is, hogy egy könyv adott fejezeteihez a megfelelő oldalak kapcsolódjanak, és a felhasználók közvetlenül a kiválasztott fejezethez ugorhassanak. Az automatikusan generált tartalomjegyzékek létrehozásához is ezek a metaadatok szükségesek.

Szintén a szerkezeti metaadatok biztosítják a multimédiás források egyes összetevőinek a megfelelő szinkronban való megjelenítését, tehát például azt, hogy a narrátor hangja a megfelelő oldal megjelenésével együtt legyen hallható.

Tudjuk, hogy a leíró metaadatok szintén tartalmazhatnak olyan adatokat, amelyek a megjelenítést segítik elő. A különbség a két típus között abban fogható meg leginkább, hogy a leíró metaadatok a felhasználó személy által értelmezhető formában tartalmazzák az ilyen típusú információkat, a szerkezeti metaadatok pedig a szoftverek számára értelmezhető formában szolgálják ugyanezt a célt.

A szerkezeti metaadatok legáltalánosabban használt metaadat sémái: METS, EBIND, MPEG-7.

Metaadat sémák

Mind a digitális dokumentumok, mind az azokat tároló digitális gyűjtemények rendkívül sokfélék lehetnek, és nagyon sok szinten különbözhetnek egymástól. A digitális gyűjteményeket menedzselő intézmények között nagy különbségek lehetnek méretükben, céljaikban; a gyűjtemények felhasználói is nagyon eltérőek lehetnek; a gyűjteményben tárolt dokumentumok formátuma, létrehozásuk célja, a felhasználási jogosultságok szintjei szintén nagy különbségeket mutathatnak egymástól.

Ezért a metaadatok használatában is szükségessé vált szabványok kialakítása, ennek köszönhetően jöttek létre a metaadat szabványok, vagy metaadat sémák, amelyek nagyban hozzájárulnak ahhoz, hogy a digitális információforrások valóban megtalálhatóak legyenek.

A metaadatséma: metaadat elemek meghatározott készlete (elemkészlet) és az elemkészlethez kapcsolódó szabályok összessége.

Egy-egy metaadat sémát általában valamely nemzetközileg elfogadott szervezet, vagy konkrétan az adott séma kidolgozásával megbízott szakcsoport hozza létre, és folyamatosan fejleszti, karbantartja, menedzseli azt.

Séma elemkészlete (séma szemantikája)

A metaadat sémában meghatározásra kerül az adott séma elemkészlete, vagyis hogy mely metaadat elemek használhatóak a sémában. A séma felsorolja és megnevezi az elemkészlethez tartozó elemeket, és pontos definíciójukat is megadja. Ezeken túl az elemekre vonatkozó szabályokat is megadja. Ilyen szabály például annak meghatározása, hogy az egyes elemek használata kötelező, vagy szabadon választható, vagy csak bizonyos esetben kötelező; illetve hogy mely elemek ismételhetőek és melyek nem. A metaadat sémának ez a szintje a séma szemantikája.

Séma tartalmi szabályai

A metaadat séma tartalmazhat ún. tartalmi szabályokat, amely szabályok a metaadat értékekhez kapcsolódnak. A metaadat séma tehát azt is meghatározhatja, hogy a metaadat értékeinek milyen szabályoknak kell megfelelniük, azaz az értéket milyen formátumban kell megadni, vagy milyen kötött szókészletek, listák, vagy kódolási sémák elemei használhatóak kötelezően az értékek megadásakor. Például tartalmazhat szabályokat arra vonatkozóan, hogy személynevek esetén milyen formátumban kell azokat metaadat értékként megadni (Pl.: vezetéknév után vesszővel elválasztva a keresztnév).

Séma szintaktikája

A séma programok, szoftverek által értelmezhető formában való kódolása jelenti a séma ún. szintaktikáját. Ilyen kódolási lehetőségek például: a HTML, az XML, vagy az RDF/XML. Léteznek olyan sémák, amelyek egy adott szintaktikához kötöttek, ilyen például a MET, amely XML-hez kötött. De vannak sémák, amelyek szintaktikája nem kötött, ilyen a Dublin Core séma is. A különböző kódolási lehetőségekre a Dublin Core séma részletezésénél adunk példákat.

A sémák komoly eltéréseket mutatnak a tekintetben, hogy mely területeken tartalmaznak sza-bályokat (szemantika, tartalmi szabályok, szintaxis), és a tekintetben is, hogy milyen részletességgel szabályozzák az adott területeket.

A metaadat sémák tehát nemzetközi szabványok, amelyeket nemzetközi együttműködések hoznak létre és fejlesztenek tovább. Ezzel szemben léteznek az egyes digitális gyűjteményekre, vagy egyes intézményi digitális könyvtárakra testre szabott, ott helyileg alkalmazott ún. helyi metaadat alkalmazási profilok. Előfordul, hogy az alkalmazási profilokat is metaadat sémának nevezik, de tudatában kell lennünk a két fogalom közötti különbségeknek. A helyi alkalmazás profilokról később írunk részletesen.

Valójában nagyon sokféle metaadat séma létezik. Létrejöttek metaadat típushoz köthető sémák (Dublin Core, PREMIS); vannak speciálisan bizonyos dokumentumtípushoz kapcsolódó sémák (VRA); és léteznek olyanok is, amelyeket valamely közösség speciális céljait, igényeit kielégítendő hozták létre (pl.: ONIX, GIS, LOM, MOS); vagy valamely speciális tudományterülethez, vagy témához köthetők (Geospatial).

Tudnunk kell továbbá, hogy az egyes sémák egymásba is ágyazhatók. Azaz egy adott infor-mációforrás leírásánál – tehát egy metaadatrekordon belül – alkalmazhatunk több metaadat sémát is. Az ilyen megoldás létjogosultsága abban van, hogy általában egy-egy séma csak bizonyos metaadat típus kezelésében kidolgozott. (Erről részletesen az egyes sémák leírásában.)

Napjaink legtöbbet alkalmazott metaadat sémái

Dublin Core (DC). Elemkészlete leíró metaadatokat tartalmaz, és általánosan, minden tudományterületre alkalmazható. A könyvtáros szakma túlnyomórészt ezt a metaadat készletet használja az általuk készített digitális gyűjtemények, könyvtárak menedzselése során. Rendkívül széles körben elterjedt metaadat séma. A következő fejezet részletesen foglalkozik ezzel a sémával.

MODS - Metadata Object Description Schema http://www.loc.gov/standards/mods/A kulturális intézmények által egyre szélesebb körben alkalmazott séma. Napjainkban az eddig DC-t használó intézmények közül egyre többen döntenek a MODS használata mellett. Ez a jelenség egyre jelentősebb. A MODS kifejezetten könyvtári környezetben kezelt digitális gyűjtemények számára készült séma. Bármilyen tudományterületen jól alkalmazható. Library of Congress által karbantartott séma.

METS - Metadata Encoding and Transmission Standard http://www.loc.gov/standards/mets/A Library of Congress által karbantartott, digitális könyvtárak objektumainak leírására rögzített séma, amely leíró, adminisztratív és szerkezeti metaadatokat is tartalmaz. A séma kódolási nyelve csak az XML leíró nyelv lehet. A METS erőssége a szerkezeti metaadatokban rejlik, éppen ezért a komplex digitális dokumentumok leírásakor leginkább alkalmazott séma. A METS egyik fontos jellemzője, hogy a leíró metaadatok és az adminisztratív metaadatok tekintetében használhatók külső sémák is: a leíró metaadatok tekintetében a MARCXML, MODS és a Simple Dublin Core az ajánlott; az adminisztratív metaadatok tekintetében a MIX az állóképek, a TextMD a szövegek számára; a megőrzési metaadatok esetében pedig a PREMIS séma elemei integrálhatók a METS sémába.

PREMIS - PREservation Metadata: Implementation Strategies http://www.loc.gov/standards/premis/A PREMIS kezdeményezés célja a megőrző metaadatok elemeinek meghatározása volt, így a séma is a megőrző metaadatok kifejezésére használatos. A PREMIS alkalmas a digitális objektum hierarchikus felépítésének kódolására is, de a METS erőssége éppen ez a funkció. Munkacsoport alakult, amely ajánlásokat állít össze arra vonatkozóan, hogy a PREMIS egységei hogyan integrálhatók METS rekordokba.

VRA Core4 - Visual Resources Association http://www.loc.gov/standards/vracore/vizuális kultúra alkotásainak és az alkotások képi másolatainak leírására alkalmas metaadat séma, tehát elsősorban a múzeumok által alkalmazott szabvány. De alkalmazható művészeti előadások leírására is. A séma leíró elemeket tartalmaz. Erőssége, hogy megkülönbözteti a Mű (Work), a Kép (Image) és a Gyűjtemény (Collection) entitásokat, és képes azok külön rekordokban történt leírása után a közöttük lévő kapcsolatok kifejezésére. Kódolása az XML. Visual Resources Association – http://www.vraweb.org/projects/vracore4/ 2010-től a Library of Congress tartja karban: http://www.loc.gov/standards/vracore/

EAD - Encoded Archival Description http://www.loc.gov/ead/Levéltárak különleges igényeihez igazodó séma.

GILS - Global Information Locator Service http://www.gils.net/Kifejezetten a kormányzati intézmények igényeihez kialakított séma, amely vállalati és egyéb szervezeti felhasználásra is jól alkalmazható. Napjainkban egyre inkább veszít jelentőségéből.

LOM - Learning Object Metadata http://ltsc.ieee.org/wg12/Kifejezetten az oktatás területének igényei szerint kialakított szabvány.

CSDGM - Content Standard for Digital Geospatial Metadata. Kifejezetten a digitális térbeli dokumentumok leírására készült. A séma 1994-es első kiadása említi az elsők között a metaadat fogalmat a ma is használatos értelmezésben.

ONIX. Könyvkiadók által létrehozott séma, amely a könyvterjesztéshez, könyvkereskedéshez specifikusan kötődő adatok megjelenítését támogatja. Így például megadható általa a dokumentum tartalomjegyzéke, a róla írt recenzió, a nyert díjak, de akár a szállítási súly is.

MIX. Technikai metaadat elemeket tartalmazó séma, digitális képeket tartalmazó gyűjtemények számára. XML-ben kódolt.

Ellenőrző kérdések:

  1. Adja meg a metaadat fogalmának rövid, illetve részletes meghatározását is!

  2. Az adminisztrációs metaadatok milyen típusú információkat tartalmazhatnak, és milyen altípusait különbözteti meg a szakirodalom?

Dublin Core

A Dublin Core metaadat séma és elemkészlet hivatalos információs és dokumentációs forrása a Dublin Core Metadata Initiative (DCMI) honlap http://www.dublincore.org/ . A metaadatséma karbantartását, dokumentációját, és fejlesztését a DCMI végzi.

A Dublin Core (DC) bármely tudományágra alkalmazható metaadat séma, amely leíró metaadat elemeket tartalmaz. A sémára jellemző az egyszerűség és a rugalmasság. Széles körben való alkalmazásának egyik oka éppen egyszerűsége, könnyen érthetősége és átláthatósága. A Dublin Core sémára is jellemző, hogy folyamatos fejlesztések, egyeztetések eredményeként folyamatosan fejlődik. A fejlesztések egyik fontos irányát a tapasztalt hibákra, hiányosságokra adott válaszok jelentik, a másik irányt pedig az újonnan felmerülő kihívásokra adott válaszok.

A Dublin Core metaadat séma története 1995-ben, az Ohio állambeli Dublinban kezdődött. Az OCLC/NCSA Metadata Workshop keretében egy kb. 50 fős szakértői csoport gyűlt össze azzal a céllal, hogy összeállítsanak egy olyan kiindulási, vagy alap adatelem készletet, amely elégséges és megfelelő az elektronikus információforrások leírására. A cél természetesen az volt, hogy az egyre szaporodó elektronikus információforrások kereshetővé, és elérhetővé váljanak az adatelemek használata által. Az elektronikus információforrások leírására az addig használt eszközök már nem voltak alkalmasak. Az addig alkalmazott eszközök túl bonyolultak, és hozzáértést igénylőek voltak, így olyan új eszközre volt szükség, amelyet a digitális világ minél szélesebb körben képes, és hajlandó alkalmazni. Ezt a célt az egyszerűség és könnyen érthetőség szolgálta leginkább. Ugyanakkor az is egyértelműen látszott, hogy valamilyen szabványosításra, egységesítésre is szükség van ahhoz, hogy az információforrások ténylegesen kereshetővé váljanak. A szakértői csoportnak sikerült megállapodnia 13 elemről, amely elemkészlet szükségesnek és elégségesnek tűnt a kitűzött cél eléréséhez.

A séma nevének első eleme (Dublin) a workshop helyszínére utal. A második elem, a Core, azaz mag kifejezés pedig arra utal, hogy a kialakított elemkészlet tulajdonképpen egy olyan alap, amely tovább bővíthető.

1995-ben tehát 13 metaadat elemet határoztak meg és fogadtak el az említett szakértői össze-jövetelen. További egyeztetések és a séma további fejlesztései a kb. évenként tartott konferenciákon történtek meg. Így első körben az elemek listája kiegészült 15 elemre. A következő fontos változást az ún. „minősítők” bevezetése hozta. Időközben a metaadat szabvány ISO szabvánnyá is alakult. Napjainkban ismét fontos fejlődés zajlik a szabványt illetően: a szemantikus web igényeinek és kihívásainak megfelelő fejlesztések, változtatások történnek. Így a QDC helyét már hivatalosan is átvette a DCMI Terms ajánlás. Nézzük meg a sémát és fejlődését részletesen.

A Dublin Core elemkészlete Magyarországon 2004-ben vált ISO szabvánnyá – az MSZ ISO 15836 Információ és dokumentáció. A Dublin Core metaadat elemkészlete címen adták ki. A Dublin Core 15 alapelemét tartalmazza a következő táblázat:

1.TitleCímaz információforrásnak adott név
2.CreatorLétrehozóaz információforrás tartalmának létrehozásáért elsősorban felelős entitás
3.SubjectTárgy- és kulcsszavak, jelzetekaz információforrás tárgyának megadása
4.DescriptionLeírásaz információforrás tartalmának ismertetése
5.PublisherKiadóaz információforrás nyilvánossághoz közvetítéséért felelős entitás
6.ContributorKözreműködőaz információforrás tartalmához készült hozzájárulás létrehozásáért felelős entitás
7.DateDátumaz információforrás létezése során előforduló esemény időpontja (dátuma)
8.TypeTípusaz információforrás tartalmának jellege, vagy fajtája
9.FormatFormátumaz információforrás fizikai vagy digitális megjelenési formája
10.IdentifierForrásazonosítóaz információforrásra való, adott környezeten belüli egyértelmű hivatkozás
11.SourceEredeti információforráshivatkozás arra az eredeti információforrásra, amelyből a jelen információforrás származik
12.LanguageNyelvaz információforrás intellektuális tartalmának nyelve
13.RelationKapcsolathivatkozás az információforrással kapcsolatban lévő másik információforrásra
14.CoverageTér-idő vonatkozásaz információforrás tartalma vagy alkalmazási területe térben vagy időben (kiterjedés)
15RightsJogokinformációk az információforrással kapcsolatos jogokról

A táblázat a magyarországi ISO szabvány adatait tartalmazza. http://mek.oszk.hu/dc/szabvany/134715.pdf (Letöltve: 2013.01.29.)

A Dublin Core szabvány az elemkészlet egyik elemét sem teszi kötelezővé – azaz az elemkészlet minden elemének használata szabadon választható, vagyis opcionális. A séma azt is kimondja, hogy az elemkészlet minden eleme szabadon ismételhető. Az elemek sorrendjét sem szabályozza a séma.

A Dublin Core sémának eddig két változatát volt szokás megkülönböztetni: az ún. egyszerű Dublin Core-t (Simple Dublin Core) és az ún. minősített Dublin Core-t (Qualified Dublin Core – QDC).

Az egyszerű Dublin Core kizárólag csak a 15 elemet tartalmazza.

A minősített Dublin Core (QDC) is ezeket az alapelemeket tartalmazza, viszont az alapelemek jelentései tovább finomíthatóak ún. minősítők használatával. A Dublin Core-nak ilyen irányú fejlesztésére éppen túlzott egyszerűsége miatt volt szükség. Széles körű használata során kiderült, hogy az alapelemeket sokszor nem azonos értelmezéssel használják felhasználói. Ezért vált szükségessé azok jelentésének pontosítása, szűkítése, finomítása. Így tehát egyes alapelemek ún. minősítőkkel (element refinements) egészíthetők ki, amelyeknek köszönhetően az elem jelentése és értelmezése következetessé, pontossá, egyértelművé válik. A minősítők használata nem kötelező. Dönthetünk úgy, hogy a minősített Dublin Core-t alkalmazzuk, és bizonyos elemek esetében használjuk a minősítőket, míg más elemek esetében nem alkalmazzuk azokat. A séma nem minden elemhez határoz meg használható minősítőket. A következő ábra mutatja, hogy mely elemek esetében, mely minősítők alkalmazhatóak a DC ajánlás szerint.

A minősített Dublin Core másik fontos elemét az ún. kódolási sémák (encoding schemes) használata jelenti. A QDC bizonyos elemek estében meghatároz külső kötött szókészleteket, listákat, vagy szabványokat, amelyek az adott elem értékének megadásához alkalmazhatóak. Szintén az itt következő ábra tartalmazza az DCMI által ajánlott kódolási sémákat, és hogy mely séma, mely elem értékének megadásakor alkalmazható.

DCMES ElementElement Refinement(s)Element Encoding Scheme(s)
TitleAlternative-
Creator--
Subject-

LCSH

MeSH

DC

LCC

UDC

DescriptionTable Of Contents, Abstract-
Publisher--
Contributor--
Date

Created

Valid

Available

Issued

Modified

DCMI Period

W3C-DTF

Type-DCMI Type Vocabulary
Format

Extent

Medium

-

IMT

Identifier-URI
Source-URI
Language-

ISO 639-2

RFC 1766

Relation

Is Version Of

Has Version

Is Replaced By

Replaces

Is Required By

Requires

Is Part Of

Has Part

Is Referenced By

References

Is Format Of

Has Format

URI
Coverage

Spatial

Temporal

DCMI Point, ISO 3166, DCMI Box, TGN

DCMI Period, W3C-DTF

Rights--

A táblázat a DCMI Dublin Core Qualifiers dokumentumának adatait tartalmazza. A dokumentum ma már nem érvényes – a DCMI Metadata Terms dokumentum helyettesíti. http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/ (Letöltve: 2012.01.29.)

A minősítők és a kódolási sémák használatának bemutatására leginkább a Dublin Core Date/Dátum eleme mutatkozik alkalmasnak.

A Dátum elem a séma definíciója szerint: az információforrás létezése során előforduló esemény időpontja (dátuma). Ez tehát bármely dátum, vagy időperiódus lehet, amely az információforráshoz köthető annak létezése során. Ezt az általános meghatározást finomítják, szűkítik a Dátum elemmel együtt használható minősítők.

Created / Létrehozvaaz információforrás létrehozásának időpontja
Valid / Érvényesinformációforrás érvényességének ideje, dátuma
Available / Hozzáférhetőa dátum, amikor az információforrás elérhetővé válik, vagy fog válni
Issued / Kibocsátvaaz információforrás formális kibocsátásának (pl.: kiadásának) dátuma
Modified / Módosítvaaz információforrás módosításának időpontja

A Dátum elemhez kapcsolható még további három minősítő, amelyek használata nem igazán elterjedt. Ezek a következők: Accepted (Elfogadva), Copyrighted (Szerzőjogilag védve), Submitted (Feltöltve/Benyújtva).

A Dátum elem értékének megadásakor ajánlott kódolási sémák:

Példák a Dátum elem értékének az ajánlott kódolási sémák alapján történő megadására:

Date.Created2009-07-30év, hónap, nap pontos megadásával
Date.Created1915?év megadásával, bizonytalan keletkezési dátummal
Date.Issued1958-1998időperiódus megadása

A kódolási sémák által ajánlott formátumok vagy kötött szókészletek használata természetesen szintén nem kötelező. Ezek csak lehetséges érték formátumok, amelyekhez az adott helyi alkalmazási profil előírásai és szabályai szerint esetlegesen alkalmazkodnia kell a metaadatok készítőinek.

A minősített DC használata akkor megfelelő, ha a megadott metaadat értékekre igaz, hogy ha a DC elemekből elhagyjuk a jelentésüket finomító minősítőket, az értékek akkor is megfelelőek, és valósak az így „keletkező” egyszerű DC elemekhez. Ez az ún. némítás (vagy lebutítás – dumb down) szabálya. Példák:

DC.Format.MediumDVDDC.FormatDVD
DC.Format.Extent3,000,000 bytes DC.Format3,000,000 bytes
DC.TitleSzáz fénykép - száz népi műemlékDC.TitleSzáz fénykép - száz népi műemlék
DC.Title.Alternative100 Fotos - 100 Denkmäler der VolksarchitekturDC.Title100 Fotos - 100 Denkmäler der Volksarchitektur
DC.Relation.IsPartOfLibrary Journal v. 127, no. 9 (May 15, 2002) p. 32-4 DC.RelationLibrary Journal v. 127, no. 9 (May 15, 2002) p. 32-4

Az egyszerű és a minősített Dublin Core séma használata rendkívül elterjedt a digitális gyűjtemények, digitális könyvtárak világában.

Az egyszerű Dublin Core ráadásul úgy is működik a digitális világban, mint egyfajta tolmács nyelv – azaz egyszerűsége miatt ezt a sémát használják a különböző sémák közötti átjárás biztosítására, illetve a különböző sémát használó digitális gyűjtemények közötti együttműködések megvalósítására is.

Dublin Core metaadatok különböző kódolásban (szintaxisban)

A DC elemek és értékek nagyon sokféleképpen kapcsolódhatnak az általuk leírt információ-forráshoz. Ezen túl nagyon sokféle rendszerben, nyelvben, kódolásban tárolhatók, szolgáltathatók és jeleníthetők meg. A következőkben csak néhány gyakrabban használt kódolási lehetőségre térünk ki az egyes nyelvek, kódolások részletes leírása, magyarázata nélkül.

HTML

A HTML nyelvben a metaadatok kezelésére, és tárolására a <meta> elemek használatosak. A <meta> elem ”name” attribútumának értéke tartalmazza az adott metaadat elemet, a ”content” attribútumának értéke pedig a metaadat értéket. Nézzünk meg néhány példát különböző esetekre.

Egyszerű DC esetén:

<meta name = "DC.Creator"
content = "Gogh, Vincent van" />
<meta name = "DC.Title"
content = " Metaadatok készítése" />

QDC esetén a kódolási séma megadása (a séma megnevezése a ”scheme” attribútum értéke):

<meta name = "DC.Subject"
scheme  = "LCSH"
content = "Vietnamese Conflict, 1961-1975" />

QDC esetén minősítők használata:

<meta name = "DC.Date.Created"
content = "1935" />
<meta name  = "DC.Date.Available"
content = "1939" />

Metaadat nyelvének megadása:

<meta  name = "DC.title"
lang  = "de"
content = "Das Wohltemperierte Klavier, Teil I" />

HTML dokumentumokban a <meta> elem a dokumentum fej részében (<head> </head>) helyezkedik el. A megfelelő névteretek meghatározása is a fej részben, a <link> elemben történik meg. A következő példában az egyszerű DC 15 elemét tartalmazó névtere kerül meghatározásra a ”rel” és a ”href” attribútumok használatával:

<html>
<head>
<title> A Dirge </title>
<link rel = "schema.DC"  href="http://purl.org/DC/elements/1.0/">
<meta name = "DC.Title"   content = "A Dirge">
<meta name = "DC.Creator"  content = "Shelley, Percy Bysshe">
<meta name = "DC.Type"     content = "poem">
<meta name = "DC.Date"     content = "1820">
<meta name = "DC.Format"   content= "text/html">
<meta name = "DC.Language"  content = "en">
</head>
<body>
…       
</body>
</html>

HTML dokumentumokban a metaadatok beágyazhatók az általuk leírt információforrásba. Erre példa a fenti HTML dokumentum, ahol a <head>-ben találhatók a metaadatok, és a <body> már magát a dokumentumot tartalmazza.

Külön adatbázisban is tárolhatók a metaadatok. Ez esetben az információforrástól külön álló metaadatrekordnak tartalmaznia kell az információforrást azonosító URI-t is: <meta name= "DC. Identifier" content= "http://hdl.handle.net/2437/99985" />

XML

Egyszerű DC:

<?xml version="1.0" encoding=”utf-8”?> 
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:title> A Szaharában </dc:title>
<dc:creator> Sebők, Imre </dc:creator>
<dc:publisher> Szent István Társulat </dc:publisher>
<dc:subject> Sivatagok </dc:subject>
<dc:identifier> http://hdl.handle.net/2437/99078 </dc:identifier>
</metadata>

QDC esetén két névtér meghatározása szükséges. Az egyik névtér az egyszerű DC 15 elemére utal, a másik névtér a DC.Terms névtérben meghatározott további elemekre.

<?xml version="1.0" encoding=”utf-8”?>  

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns:dcterms="http://purl.org/dc/terms/"> 
<dc:title> A Csendes óceán szigetvilága </dc:title>
<dcterms:alterantive> Úti jegyzetek </dcterms:alternative> 
<dc:creator> Vojnich, Oszkár </dc:creator>
…
</metadata>

XHTML

Példa QDC használatára XHTML kódolásban:

...
<head profile="http://dublincore.org/documents/dcq-html/">
<title>Expressing Dublin Core in HTML/XHTML meta and link elements</title>
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" /> 
<meta name="DC.title" lang="en" content="Expressing Dublin Corein HTML/XHTML meta and link elements" />
<meta name="DC.creator" content="Andy Powell, UKOLN, University of Bath"/>
<meta name="DCTERMS.issued" scheme="DCTERMS.W3CDTF" content="2003-11-01" />
<meta name="DC.identifier" scheme="DCTERMS.URI"content="http://dublincore.org/documents/dcq-html/" />
<meta name="DCTERMS.abstract" content="This document describes howqualified Dublin Core metadata can be encodedin HTML/XHTML" />
<meta name="DC.format" scheme="DCTERMS.IMT" content="text/html" />
<meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text" />
</head>
...

A példa a DCMI ajánlásaiban megtalálható elektronikus dokuemntumból való: POWELL, Andy: Expressing Dublin Core in HTML/XHTML meta and link elements. http://dublincore.org/documents/dcq-html/ (Letöltve: 2013.01.29.)

RDF/XML kódolásban

A Dublin Core RDF/XML kódolásban való használatát a fejezet végén, a szemantikus web rövid bevezetése után tárgyaljuk.

A Dublin Core séma szemantikus web céljainak megfelelő átalakítása folyamatosan zajlik. Ezen átalakulásnak köszönhetően a Dublin Core hivatalos dokumentációi szerint a QDC, azaz minősített Dublin Core séma helyét a Dublin Core Terms ajánlás vette át. Mindenképpen fontos tudnunk ezekről a változásokról, de azt is meg kell jegyeznünk, hogy természetesen a digitális gyűjtemények döntő többsége még nem a szemantikus web szemlélete szerint működik.

Ahhoz, hogy a DC új változatát megértsük, további információkra van szükségünk, elsősorban a szemantikus web elvéről, technológiájáról, világáról. Így a DCMI új ajánlására a fejezet végén térünk vissza.

Ellenőrző kérdések:

  1. Miben különbözik a minősített Dublin Core metaadat séma az egyszerű Dublin Core sémától?

  2. Milyen lehetséges kódolásai léteznek a Dublin Core sémának?

Metaadatok tervezése és készítése

Helyi metaadat alkalmazási profilok megtervezése

Digitális gyűjtemények tervezésénél, és létrehozásánál szükség van olyan szakember közre-működésére, aki ismeri a metaadatok fontosságát, célját, funkcióit; a metaadat sémák nyújtotta lehetőségeket, az egyes sémák működését, erősségeit és gyengeségeit; a helyi igényeket, és sajátosságokat, illetve a születő digitális gyűjtemény sajátosságait. Az ilyen szakember feladata az adott digitális gyűjteményhez kapcsolódó ún. helyi metaadat alkalmazási profil (metaadat alkalmazási útmutató, alkalmazási gyakorlat, helyi alkalmazási profil, helyi metaadat séma) megtervezése. A helyi alkalmazási profil megtervezésekor döntést kell hozni arról, hogy az adott digitális gyűjteményben milyen metaadat elemek, és értékek, milyen megnevezéssel, milyen szabályoknak megfelelően lesznek alkalmazhatóak. Ez tulajdonképpen az adott gyűjteményre jellemző séma létrehozását jelenti, egyfelől a helyi igényeknek megfelelően, másfelől általában valamely nemzetközi metaadat séma szabályait követve.

A helyi metaadat alkalmazási profil megtervezésének első fázisában fontos megvizsgálni a következőket:

  • milyen céllal jön létre a gyűjtemény, és milyen igényeket akar kielégíteni,

  • a felhasználók milyen elvárásokkal, igényekkel fordulnak majd a gyűjtemény felé,

  • milyen környezetben funkcionál majd az új gyűjtemény, azaz milyenek az adott intézmény által már működtetett egyéb digitális gyűjtemények, vagy az intézmény digitális könyvtára,

  • milyen külső, vagy nemzetközi együttműködési szabályoknak, projekteknek, alkalmazásoknak kell majd megfelelnie a gyűjteménynek,

  • milyen jellegű és milyen tartalmú digitális információforrásokat tárol majd a gyűjtemény,

  • milyen képzettségű, és milyen mértékű emberi erőforrás építi majd a gyűjteményt.

A fenti tényezők megvizsgálása után kezdődhet meg az adott gyűjtemény metaadat elemkészletének összeállítása. Az adott gyűjteményre jellemző elemkészletet több tényező egyidejű figyelembevételével kell megalkotni. A gyűjteményre jellemző elemkészlet természetesen összeállítható teljesen csak a helyi igényeket figyelembevételével, csak a gyűjteményre jellemző elemnevek használatával. A könyvtárak, és egyéb kulturális intézmények azonban már mind tudatában vannak az együttműködési projektek fontosságának, éppen ezért olyan helyi elemkészletet állítanak össze, amelyek vagy csak a nemzetközi metaadat szabványok elemeit tartalmazzák, vagy viszonylag könnyen elkészíthető a helyi elemkészlet és a nemzetközi szabvány közötti konverziós térkép, megfeleltetés. A helyi elemkészlet tehát magán hordozza az adott gyűjteményre jellemző elemeket, az adott intézmény digitális könyvtárának esetleges helyi sajátosságait, elemeit, illetve a nemzetközi szabvány elemeit is. Fontos tehát azt is eldönteni, hogy mely nemzetközi séma (vagy sémák) elemei jelennek meg a gyűjtemény elemkészletében.

Ha az elemek összegyűjtése megtörtént, akkor az elemek elnevezése (helyi, intézményi és nemzetközi szinten), definíciójuk rögzítése is meg kell, hogy történjen.

Rögzíteni szükséges azt is, hogy mely elemek használata kötelező, opcionális, vagy csak bizonyos esetben kötelező. Egyes elemekre az ismételhetőséget is meg kell adni. Meg kell határozni, hogy pontosan milyen minősítők használata engedélyezett, és mely elemek esetében.

Meg kell határozni azt is, hogy az egyes elemek értékei milyen formátumban, milyen kódolási séma, vagy kötött szókészlet használatával adhatóak meg. Esetleg szabályozni érdemes azt is, hogy egy-egy elem értéke maximum hány karakterben adható meg.

Szintén a helyi alkalmazási profil részét képezi annak rögzítése, hogy mely elemek értékei lesznek indexeltek a keresésben, illetve mely elemek használatával érhetőek majd el böngésző funkciók. Mely elemek lesznek láthatóak a felhasználók számára már a találati lista megjelenítésekor, melyek egy rövidebb, illetve egy részletesebb metaadatrekord megjelenítési formátumban; és mely elemek maradnak rejtve a felhasználók elől.

Az ún. helyi metaadat alkalmazási profilok általában egymástól nagyon eltérőek mind kidolgozottságukban, mind terjedelmükben, mind abban, hogy milyen mélységben szabályozzák az egyes területeket. Fontos lenne, hogy ezek a szabályok, ajánlások, útmutatások írásban is rögzítve legyenek egyrészt minden egyes gyűjteményre külön-külön, illetve az adott intézmény által működtetett digitális könyvtárra vonatkozóan is.

A helyi metaadat alkalmazási profil megtervezése és dokumentálása jó esetben a gyűjtemény indításakor megtörténik megfelelő szakemberek megfelelően átgondolt döntései alapján.

A jól megtervezett és elkészített alkalmazási profil nagy segítséget jelent a metaadatok elkészítésének munkafázisában, azaz az adott információforrás metaadat elemei értékének megfelelő megadásakor.

Példák helyi metaadatsémák, helyi útmutatók dokumentálására:

Metaadatok készítése

Metaadatok készítésénél a legfontosabb irányelv, hogy megfelelő minőségű metaadatokat hozzunk létre. A jó minőségű metaadat a helyi igényeknek megfelelő, de emellett jól megosztható, azaz elősegíti az adott gyűjtemény együttműködési képességét, interoperábilitását is.

Ahhoz, hogy jó minőségű metaadatot hozzunk létre, általánosságban a következőkre kell törekednünk:

Teljesség. Törekednünk kell minden olyan adat rögzítésére, amely rendelkezésünkre áll a dokumentumról. Természetesen ennek betartását csak az anyagi ésszerűség, vagy lehetőség határain belül tehetjük meg. De fontos, hogy véletlenül ne maradjanak el adatok. (Hiba lehet például, ha elmarad a digitális fájl formátumának megadása.)

Következetesség. A következetesség több szinten is kell, hogy jellemezze mind a metaadatokat, mind a metaadatok készítőjét. Egyrészt következetesen követnünk kell az alkalmazott séma szabályait. A metaadat elemeket definícióiknak megfelelően kell használnunk. A metaadat értékek megadásánál is követnünk kell a kötött szókészleteket, illetve a kódolási sémákat, ha vannak ilyenek.

Naprakészség. Lehetőség szerint mindig friss, és naprakész adatokat rögzítsünk a metaadatokban, illetve szükség esetén frissítsük azokat.

Igények kielégítése. A felhasználói igényeknek, elvárásoknak megfelelő metaadatokat kell készítenünk. Ez természetesen az OAI-PMH adatszolgáltatók számára külön problémát jelenthet, hiszen ilyen esetben nem csak a helyi felhasználókat kell figyelembe venni, hanem azt is, hogy metaadataink hogyan fognak „működni” távoli keresőrendszerekben, és hogyan fogják kiszolgálni azok felhasználóit.

Megfelelő kapcsolat. Fontos elvárás, hogy a metaadatok ténylegesen ahhoz a dokumentumhoz kapcsolódjanak, amelyről adatokat tartalmaznak. Biztosítanunk kell továbbá azt is, hogy a felhasználók hozzá tudjanak férni a metaadatokhoz.

Pontosság. A metaadatoknak pontos és a valóságnak megfelelő adatokat kell tartalmazniuk.

Milyen konkrét feladatok, választási lehetőségek, esetleg hibák merülhetnek még fel metaadatok készítése közben?

Alapvető kérdés, hogy dokumentumról, vagy összetett dokumentumról vagy esetleg gyűjteményről készítünk-e metaadatokat. Mindig figyeljünk rá, hogy a megfelelő szintű leírást készítsük el. Szintén sokszor felmerül a kérdés, hogy digitalizálás esetén az eredeti dokumentum (például egy nyomtatott könyv) adatai is szerepeljenek a digitalizált változat metaadatrekordjában, vagy sem. Általános gyakorlat, hogy szerepelnek ilyen adatok is a digitális változat leírásában, természetesen bizonyos megfontolások után, megfelelő következetességgel alkalmazva ezt.

Jó minőségű metaadatok létrehozásához fontos, hogy adott metaadat elemekhez a megfelelő típusú metaadat értékeket adjunk meg. A Dublin Core esetében a gyakran használt elemek közül leginkább a következők használatában fordulnak elő félreértések, hibák: Date – Coverage, Format – Type elemek esetében.

A Date elem a digitális dokumentumhoz köthető dátumokat, időintervallumokat tartalmazza, míg a Coverage.Date elem a dokumentum tartalmához köthető dátumokat tartalmazhatja. Így például egy 2000-ben kiadott regény esetében, amely az első világháborúról szól a Date elem a kiadás dátumát (2000), míg a Coverage.Date elem az első világháború idejét kell, hogy tartalmazza.

A Type elem a dokumentum tartalmára vonatkozik, míg a Format elem a digitális dokumentum digitális formátumát tartalmazza. Például egy digitalizált könyv esetében, ahol az egyes oldalak TIFF formátumban kerültek digitalizálásra és archiválásra a Type értéke a Text (azaz szöveg) lesz, míg a Format értéke a Still Image (azaz kép) megnevezés lesz helyesen.

Ha egy metaadat értékhez valamilyen kódolási séma adott, akkor következetesen annak megfelelve kell megadnunk az értékeket. De ezen túl még érdemes arra is figyelmet fordítani, hogy egy gyűjteményen belül a séma által megengedett esetleges választási lehetőségek közül mindig csak az egyik féle lehetőséget alkalmazzuk. Így például a dátum megadásánál bizonytalanság esetén a sémák szerint alkalmazhatjuk a következő formák bármelyikét: ca.1945, vagy 1945?. Egy gyűjteményen belül lehetőleg következetesen csak az egyik típusú formátumot használjuk.

Ha szabad szöveges formátumban kell megadnunk egy elem értékét, azt is az adott gyűjteményen belül megfelelő következetességgel tegyük. Például, ha szabad szöveges leírást kell készítenünk egy képi dokumentumról a Description mezőben, akkor próbáljuk meg kb. azonos részletességgel megtenni ezt az egyes dokumentumok tekintetében. Azaz ne kövessük el azt a hibát, hogy valamely dokumentumot túlzott részletességgel írunk le, míg másikról csak éppen egy-két információt közlünk.

Bizonyos típusú dokumentumoknál nehézséget okozhat bizonyos metaadat értékek megadása. Így például képi dokumentumok esetében a cím megadása nem feltétlenül egyértelmű. Ilyen esetben érdemes valamilyen irányelveket kidolgozni, amiket követve a gyűjtemény felhasználói számára is jól használható, de a valóságnak is megfelelő, pontos metaadat születhet meg. Például egy ex librisek digitális másolatait tartalmazó gyűjteményben nem adhatjuk minden dokumentumnak csupán csak az „Ex libris” címet, mert az túl sok információt nem tartalmaz a felhasználók számára. Hasznosabb lehet az „XY ex librise” cím meghatározása, vagy más, hasonló gyakorlat kidolgozása. Fontos a böngészés funkciót figyelembe véve dönteni ezekről a követendő gyakorlatokról.

Milyen formában kapcsolható a metaadat az információforráshoz? A metaadatok beágyazhatóak az általuk leírt dokumentumba, de a dokumentumtól különállóan is tárolhatóak úgy, hogy az dokumentumra utaló valamely azonosítót elhelyeznek az adott metaadatrekordban.

Interoperabilitás

Természetesen a digitális gyűjteményeket fenntartó intézmények számára is cél, hogy minél több felhasználó találjon rá az általuk szolgáltatott digitális tartalmakra, digitális dokumentumokra. A felhasználóknak is érdeke, hogy minél nagyobb mennyiségű adatban kereshessenek. Fontos tehát, hogy a különálló digitális gyűjteményekben tárolt dokumentumok minél szélesebb körben legyenek kereshetők. Ezért a digitális gyűjtemények felé ma már fontos elvárás, hogy képesek legyenek együttműködni más gyűjteményekkel, más rendszerekkel, keresőmotorokkal, keresőrendszerekkel. Ez az együttműködési képesség az ún. interoperábilitás. A metaadatok, metaadat sémák, kódolási szabványok, kötött szókészletek szintén fontos szerepet játszanak abban, hogy az egyes digitális gyűjtemények közötti együttműködések létrejöhessenek.

Aratás és az OAI-PMH. Az egyik ilyen együttműködési lehetőség az egyes digitális gyűjteményekben tárolt metaadatok ún. aratása (harvesztelése). Erre napjainkban a leginkább elterjedt protokoll az ún. OAI-PMH, azaz Open Archives Initiative-Protocol for Metadata Harvesting. Az metaadatok aratásának folyamatában, az ún. adatszolgáltatók (Data Providers) elérhetővé, és arathatóvá (azaz begyűjthetővé) teszik az általuk szolgáltatni kívánt metaadatokat az általuk megjelölt ún. adat halmazokból (set-ekből). Az adatszolgáltatók általában különböző intézmények, az egyes adat halmazok (set-ek) pedig nagy általánosságban egy-egy digitális gyűjteményt jelentenek. Az így arathatóvá tett adat halmazokból az ún. szolgáltató (Service Provider) egy megfelelő script segítségével begyűjti a metaadatokat. Ezt elvégzi minden egyes adatszolgáltatónál. Az így begyűjtött metaadatrekordokat egy közös adatbázisban tárolja. Így tehát olyan adatbázis keletkezik, amely csak a metaadatokat tárolja. Az ilyen típusú adatbázisokat szokás metaadat-repozitóriumoknak is nevezni (ilyen például az NDA, vagy az Europeana). Ebből az adatbázisból szolgálja ki a felé érkező keresőkérdéseket, és így teszi lehetővé, hogy a felhasználó egyetlen kereséssel különböző intézmények különböző gyűjteményeiben tárolt dokumentumai között kereshessen. A metaadatokhoz tartozó digitális dokumentumok továbbra is csak az eredeti digitális gyűjteményekben tárolódnak, és a metaadat-repozitórium csak az oda vezető elérési útvonalat (azaz általában az URI-t) tartalmazza.

Az OAI-PMH protokoll alapkövetelménye az egyszerű Dublin Core elmeinek használata XML kódolásban. Ez azt jelenti, hogy amennyiben az aratni kívánt digitális gyűjtemény metaadatai más metaadat séma szerint készültek, akkor meg kell feleltetni őket a 15 Dublin Core metaadat elemek valamelyikével. Azaz el kell készíteni az ún. konverziós táblázatot vagy térképet (cross-walking), amely a két séma (a helyi metaadat alkalmazási séma és az egyszerű DC) közötti megfeleltetést tartalmazza, illetve el is kell végezni a megfeleltetést, vagy konverziót (mapping).

A nemzetközileg elismert metaadat sémák közötti konverziós térképek több helyen is elérhetőek az interneten. A Library of Congress honlapján is találunk ilyen térképeket, táblákat, a sémák hivatalos honlapjain is elérhetőek ilyen típusú táblázatok, illetve a UK Office for Library and Information Networking (UKOLN) honlapja is közzétesz egy gyűjteményt a különböző intézmények által elkészített táblázatok elérhetőségéről.

A UKOLN honlapján http://www.ukoln.ac.uk/metadata/interoperability többek között a következő sémák megfeleltetési térképei érhetők el:

kiindulási sémacél séma

Dublin Core

EAD
Dublin CoreUSMARC
TEI headerUSMARC/Dublin Core
Dublin Core

EAD/GILS/USMARC

Fontosabb sémák megfeleltetése egy közös táblázatban a Getty Research Institute összeállításában: http://www.getty.edu/research/publications/electronic_publications/intrometadata/crosswalks.html

Részlet egy konverziós táblázatból (DC sémából MODS-ba való konvertálás):

Dublin Core elementMODS element
Title<titleInfo> <title>
Creator

<name><namePart><role><roleTerm type=text">

creator

Subject

<subject><topic>

<classification>

Descriptipn

<abstract>

<note>

<tableOfContents>

Publisher<originInfo><publisher>
Date

<originInfo><dateIssued>

<originInfo><dateCreated>

<originInfo><dateCaptured>

<originInfo><dateOther>

Type

<typeOfResource>

<genre>

http://www.loc.gov/standards/mods/dcsimple-mods.html (Letöltve: 2013.01.29.)

Természetesen a metaadat sémák közötti komoly eltérések miatt a sémák közötti megfeleltetések elvégzése általában igen nehéz feladat, amely átgondolt és sokszor komoly kompromisszumokkal járó döntéseket igényel. Minél inkább különbözik a két séma egymástól, annál nehezebb lesz a megfeleltetés elvégzése.

A megfeleltetésben különböző szintű problémák és különbségek merülhetnek fel:

  • sémák szemantikájában lévő különbségek (pl.: az adott sémában nem létezik a megfeleltetni kívánt elem),

  • gyakorlatbeli különbségekkel (metaadat készítésének különböző közösségek által gyakorolt alkalmazások),

  • megjelenítési különbségekkel (metaadat értékek megjelenítési formátumainak külön-bözőségei: pl. személynevek esetén: W. Faulkner, William Faulkner, Faulkner, William etc.),

  • szókészletek különbségei (a különböző sémák metaadat értékeihez használt különböző kötött szókészletek, vagy csak egyszerű szabad megnevezések különbségei),

  • egyszintű és hierarchikus sémák közötti különbségek (ha az egyik séma nem képes a másik által kifejezett hierarchiák kifejezésére),

  • nyelvi problémák (a metaadat értékek nem azonos nyelvűek).

A Dublin Core-nál már említettük az egyszerű DC szerepét, amely mintegy közös nyelvként működik a különböző sémák között, leginkább éppen egyszerűsége miatt.

Mindezek mellett fontos még, hogy megfelelő minőségű metaadatokat hozzunk létre. Erről részletesen a metaadatok létrehozásánál.

A felhasználó végezhet keresést az adott gyűjtemény keresőfelületén, amely természetesen tartalmaz minden a gyűjteményre specifikusan jellemző mezőt, mező elnevezést, és keresési lehetőségeket. Elképzelhető, hogy a felhasználó az adott intézmény által működtetett intézményi digitális könyvtár minden gyűjteményében egyszerre végez keresést, amely esetben az intézményi speciális tulajdonságok (mezők, mező elnevezések, keresési lehetőségek) még jelen vannak, de az egyes gyűjteményekre jellemzőek már nem.

A különböző digitális gyűjteményekben tárolt dokumentumok komoly részéről készült metaadatokat ma még nem indexelik a különböző webes keresőmotorok, éppen ezért ezt a komoly mennyiségű adathalmazt mély webnek is szokás nevezni. Ezek a dokumentumok nehezen találhatóak meg a felhasználók számára. Éppen ezért a megtalálásuk elősegítésére különböző együttműködési kezdeményezések indultak el.

Ellenőrző kérdések:

  1. Milyen kritériumoknak kell megfelelnie a jó minőségű metaadatoknak?

  2. Mit jelent a digitális gyűjtemények esetében az interoperábilitás?

  3. Milyen problémák léphetnek fel metaadat sémák egymás közötti megfeleltetése során?

Metaadatok és a szemantikus web

A metaadatok teljesen új megközelítését kívánja meg a szemantikus web egyre komolyabb térnyerése. A szemantikus web és Linked Data lehetséges jövőbeni szerepéről megoszlik még a szakemberek, és a felhasználók véleménye. A kulturális örökséget kezelő intézményeknek és közösségeknek viszont egyértelműen foglalkozniuk kell a szemantikus web kínálta egyre bővülő lehetőségekkel, alkalmazásokkal, technológiákkal. Szintén ebbe az irányba mutató jel, hogy a Library of Congress is komoly szerepet vállal az ilyen irányú fejlesztésekben és azok alkalmazásában. Ugyan így a Dublin Core Metadata Initiative is elköteleződött a szemantikus technológiák és alkalmazások mellett, és ezeknek megfelelően fejleszti a Dublin Core sémát. Ezért szükséges a szemantikus web elméletének és működésének néhány elemét megismernünk.

Szemantikus webről röviden

Itt csak olyan részletességgel foglalkozunk a szemantikus web és a Linked Data elméletével, amely szükséges a metaadatok és különösen a Dublin Core esetében végbemenő szemlélet váltás megértéséhez.

RDF, RDF állítások, RDF-gráf

A szemantikus web nyelve az RDF (Resource Description Framework – Erőforrás Leíró Nyelv). Az RDF erőforrások leírására alkalmas keretrendszer, amelynek alapegységei az ún. háromtagú állítások, kijelentések, tripletek, vagy hármasok (statement).

A háromtagú állítások az egyszerű kijelentő mondatok szerkezetét követik:

Horváth Zsófia ismeri Szilágyi Máriát.

(Arra, hogy mik lehetnek erőforrások, a későbbiekben térünk vissza.)

Egy háromtagú állítás mindig a következő három elemből kell, hogy álljon:

  • alany (subject)

  • pedikátum (predicate)

  • tárgy (object)

Az előbbi mondat tehát így épül fel:

alany (subject)

predikátum (predicate)

tárgy (object)

Horváth ZsófiaismeriSzilágyi Máriát

Ez az állítás a szemantikus web világában gyakran használt RDF-gráfként ábrázolva így mutat:

Ha ezeket az egyszerű kijelentéseket programok, alkalmazások számára érthető formában tesszük meg, akkor a nagy mennyiségű kijelentések feldolgozásával a programok olyan következtetéseket is el tudnak végezni, amelyek magukban a kijelentésekben valójában nincsenek benne. Egy nagyon egyszerű példa néhány állítással:

alanypredikátumtárgy
William Shakespeareírtaa Machbeth-et
A Machbethírva voltLondonban
Londona fővárosaNagy-Britanniának.

A szemantikus web alkalmazásai ezen állítások alapján levonhatják a következő következtetéseket:

William Shakespeare írt Londonban
William Shakespeare írt Nagy-Britannia fővárosában
William Shakespeare írt Nagy-Britanniában

Láthatjuk, hogy ha ezeket a rendkívül egyszerű állításokat összekötjük egymással, azaz a világ számtalan pontján elkészített állítások egymással összekapcsolódnak: hihetetlen mennyiségű, adat szinten összekapcsolt adattér jön létre. Ebben a különleges adattérben adat szinten léteznek kapcsolatok, míg a jelenlegi weben dokumentum szintű kapcsolatok léteznek. A szemantikus web egyik nagyon fontos tulajdonsága éppen ez, hogy az adatok kapcsolódnak egymáshoz, és ezekből a megfelelő alkalmazások következtetéseket vonhatnak le.

Bár még csak néhány elemét érintettük a szemantikus webnek, mégis már ennél a pontnál jól látszik, hogy a metaadatok hogyan illeszkedhetnek a szemantikus web világába. A metaadatok információforrásokat írnak le, azaz információforrásokról tesznek kijelentéseket, vagyis állításokat.

Példánkban Chernel István: Utazás Norvégia végvidékére c. könyvének digitalizált változata szerepel, a DEENK digitális könyvtárából.

Információforrás (alany)

Metaadatelem (predikátum)

Metaadatérték (tárgy)

A digitalizált könyv a

http://hdl.handle.net/2437/97811 URI-val

DC CreatorChernel István

A digitalizált könyv a

http://hdl.handle.net/2437/97811 URI-val

DC TitleUtazás Norvégia végvidékére

A digitalizált könyv a

http://hdl.handle.net/2437/97811 URI-val

DC SubjectNorway – Description and travel

A fenti állítások RDF-gráfként:

URI-k használata

A szemantikus web háromtagú állításainál nagyon fontos, hogy az állítás tagjai teljesen egyértelműen beazonosíthatóak legyenek. Tehát ne csak egy-egy adott adatbázisban, adathalmazban, vagy névtérben legyenek egyedien azonosíthatók, azaz egyértelműen megkülönböztethetők a többi forrástól, hanem az egész www világra vonatkozóan. Ennek eszköze a megfelelő minőségű URI-k használata. Vagyis az állítások tagjait URI-k használatával kell „megnevezni” minden esetben, amikor ez lehetséges. Így biztosítható, hogy az erőforrások teljesen egyértelműen egyedileg azonosíthatóak legyenek.

Ennek az elvnek megfelelően a Library of Congress elvégezte tárgyszókészletének RDF alapú publikálását, amely itt elérhető: http://id.loc.gov/authorities/subjects.html .

A Library of Congress ezen projekt során a ’Norway—Desciption and travel’ tárgyszónak a http://id.loc.gov/authorities/subjects/sh85092636 URI azonosítót határozta meg. Így a világ bármely pontján ennek az URI-nak a használata az LC ezen tárgyszavát azonosítja, azaz ezt a tárgyszót jelenti. Ezt tovább gondolva, a világ bármely pontján menedzselt digitális gyűjteményben, adott elektronikus információforrásokra alkalmazva ezt az URI-t, ezek az információforrások összekapcsolódnak.

Az URI-k azonban nem csak a www világában létező információforrásokat azonosíthatják, hanem a világ bármely fizikai megvalósulását is. Így például egy személyt is azonosíthat egy URI. Ennek a fejezetnek az íróját a http://orcid.org/0000-0002-2185-4887 URI azonosítja.

A VIAF projekt is hasonló valamelyest az LC projektjéhez. Ebben a projektben viszont nem tárgyszavak, hanem személyek URI-val való meghatározása történt meg. Így a példánkban szereplő Chernel István-t (1865-1922) azonosító URI a következő: http://viaf.org/viaf/12699579/

Anélkül, hogy a részletekbe belemennénk, annyit kell tudnunk, hogy nem csak információforrásokat, személyeket stb. aznosíthatunk URI-kal, hanem a háromtagú állítások predikátum eleme is kifejezhető URI-k segítségével. Így a DC metaadat elemek URI-kkal való megfeleltetése, azonosítása is megtörtént a DCMI által. A Dublin Core Subject elemének a DCMI által meghatározott egyértelmű URI azonosítója: http://purl.org/dc/elements/1.1/subject

Ezek ismeretében már érteni fogjuk a következő táblázat háromtagú állításait, amelyek megegyeznek az előző táblázat és RDF-gráf állításaival.

Ezek az állítások RDF-gráfként:

Ezekhez az RDF állításokhoz mások által készített állítások is kapcsolódhatnak. Azaz ugyan arról az erőforrásról készülhet nagyon sok állítás. Csak az URI-val azonosított erőforrásokra igaz ez. Tehát az előbbi RDF-gráfhoz kapcsolódhat például egy Chernel Istvánról szóló könyvről (erőforrásról) tett kijelentés, így tovább bővítve az előbbi gráfot.

Az RDF állítások egyre jobban behálózzák a világot, egyre nagyobb adatteret hoznak létre, rengeteg kapcsolódási ponttal. Példa az RDF-gráfok, illetve a gráfokból összeálló adat szettek egymás közötti kapcsolati rendszerére:

Forrás: http://www.jiscinfonet.ac.uk/infokits/optimisation/somewhere/open-data/ Letöltve: 2013.01.29.

Ezek az RDF állítások tehát egyre inkább behálózzák az egész világot, és így létrejön egy programok számára is értelmezhető, adatokat leíró, hihetetlen méretű adattér. Ebben az adattérben, ha minden erőforrás egyértelműen azonosítható, akkor a programok hihetetlen mennyiségű adattal dolgozva tudnak következtetéseket levonni, illetve a szemantikus keresők által feltett kérdésekre válaszolni. Ilyen kérdés lehet például akár az is, hogy 1850-1900 között milyen Shakespeare drámákat játszottak a világ színházaiban.

Az eddigiek ismeretében összegezzünk, pontosítsunk néhány részletet, fogalmat, lehetséges szerepeket.

Tudjuk, hogy az RDF állításokkal erőforrásokat írunk le. Mi lehet erőforrás, amely leírható RDF-ben? Valójában bármi.

Erőforrások lehetnek:

  • fizikai tárgyak (könyvek, épületek, állatok, emberek, stb.)

  • digitális objektumok (digitális képek, weblapok, stb.)

  • fogalmi objektumok (színek, időpontok, stb.)

 FunkciójaMi lehet?Mi azonosítja?
alanyamiről állítunk valamiterőforrásURI
predikátum/tulajdonságkapcsolat megadása, vagy tulajdonság meghatározásaerőforrásURI
tárgy/értéka kapcsolat, vagy a tulajdonság értékeerőforrás vagy literálURI vagy literál

Predikátum lehetséges szerepei:

  • két erőforrás (alany és tárgy) közötti kapcsolatot írja le (Példa: Kiss Petra ismeri Nagy Zsófiát. Kiss Petra barátja Nagy Zsófiának.)

  • az alany erőforrás valamely tulajdonságát adja meg, amelynek értékét a tárgy/érték elem tartalmazza (Példa: a fájl mérete 120 KB.)

A literál nem URI azonosítású állandó érték, amelyhez újabb állítás nem kapcsolható. (Előző példáinkban literál például: „Utazás Norvégia végvidékére”.)

RDF-gráf elemeinek jelölése:

RDF egyik kódolási nyelve: az RDF/XML

Ha az előbbi RDF-állításokat programok által is értelmezhető kódolásban szeretnénk leírni, többféle szintaxis közül is választhatunk. Ezek egyike az RDF/XML nyelv. Szintén RDF kódolására alkalmas nyelvek: a Turtle, a Notion 3, vagy a N-Triples nyelvek.

Az RDF/XML tehát RDF állítások XML-ben való kódolását jelenti.

Az előbbi állítások RDF/XML-ben leírva:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#
"xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://hdl.handle.net/2437/97811">
<dc:title> Utazás Norvégia végvidékére </dc:title>
<dc:creator rdf:resource=”http://viaf.org/viaf/12699579/”  />
<dc:subject rdf:resource=”http://id.loc.gov/authorities/subjects/sh85092636”  /> 
</rdf:Description>
</rdf:RDF>

Ha célunk, hogy a szemantikus web alkalmazásai számára „érthető” adatokat szolgáltassunk digitális gyűjteményeinkről, akkor az eddigi adatainkat át kell alakítanunk a szemantikus web legkisebb egységére: a háromtagú állításokra. Ez tehát azt jelenti, hogy az egyes metaadatrekordok tartalmát is ilyen kijelentésekben kell hozzáférhetővé tennünk.

Természetesen a szemantikus web világa, a szemantikus alkalmazások, technológiák, különböző nyelvek, és azok lehetséges szintaxisa, valamint a szemantikus keresőprogramok ma már egyre szélesebb szakirodalommal rendelkeznek, de ebben a könyvben nem térhetünk ki ezekre ennél részletesebben. Annyit azonban érdemes tudnunk, hogy ez a szemlélet, ezek a technológiák és alkalmazások egyre inkább fejlődnek, egyre nagyobb számban jelennek meg, és a kulturális örökséget gondozó intézmények, közösségek számára mindenképpen a jövő részét képezik majd. A digitális gyűjtemények és a metaadataink menedzselésekor már tudatában kell lennünk létezésüknek és egyre komolyabb térnyerésüknek. Így képesek leszünk a szemantikus web világának új kihívásaira megfelelően és időben válaszolni.

Dublin Core legfrissebb változata: a DCMI Terms ajánlás

2006-tól kezdte alkalmazni a szemantikus web alkalmazásaiban élen járó Linked Data mozgalom a DCMI Metadata Terms ajánlását, szókészletét. A DCMI 2008-as ajánlásában jelenik meg a szemlélet váltás, amikor is az ajánlás már nem elemeket, és minősítőket tartalmaz, hanem a szemantikus web szemléletének megfelelő ún. tulajdonságokat és osztályokat.

A DCMI Metadata Terms mai építőelemei (2008-tól):

  • tulajdonságok (properties)

  • szókészlet kódolási sémák (vocabulary encoding schemes)

  • szintaxis kódolási sémák (syntax encoding schemes)

  • osztályok (classes)

Fontos változás még, hogy az ajánlás szerint a DC metaadatok is erőforrásokról tartalmaznak adatokat. A leírandó erőforrásoknak nulla, vagy több tulajdonsága lehet. A tulajdonság valamilyen jellemző, kapcsolat, jellegzetesség, vagy vonatkozás amely az erőforrást jellemzi. A tulajdonságnak egy vagy több értéke lehet. Ez az érték önmaga is valamely erőforrás. Tehát az erőforrásnak van valamilyen tulajdonsága, amely tulajdonságnak van valamilyen értéke.

A tulajdonságok az egykori elemek, és minősítők (elements, element refinements). Jelenleg két névtérben vannak meghatározva. Az egyszerű DC 15 eleme továbbra is az /elements/1.1/ névtérben, a további tulajdonságok pedig a /terms/ névtérben.

Az egykori kódolási sémák két külön csoportra oszlottak: a szókészlet kódolási sémákra, és a szintaxis kódolási sémákra.

A Dublin Core jelenlegi ajánlása http://dublincore.org/documents/2012/06/14/dcmi-terms/ :

Properties in the /terms/ namespace

Tulajdonságok a /terms/ névtérben

abstract , accessRights , accrualMethod , accrualPeriodicity , accrualPolicy, alternative , audience , available , bibliographicCitation , conformsTo , contributor , coverage , created , creator , date , dateAccepted , dateCopyrighted , dateSubmitted , description , educationLevel , extent , format , hasFormat , hasPart , hasVersion , identifier , instructionalMethod , isFormatOf , isPartOf , isReferencedBy , isReplacedBy , isRequiredBy , issued , isVersionOf , language , license , mediator , medium , modified , provenance , publisher , references , relation , replaces , requires , rights , rightsHolder , source , spatial , subject , tableOfContents , temporal , title , type , valid
Properties in the /elements/1.1/ namespace

Tulajdonságok az /elements/1.1/ névtérben

contributor , coverage , creator , date , description , format , identifier , language , publisher , relation , rights , source , subject , title , type
Vocabulary Encoding Schemes

Szókészlet kódolási sémák

DCMIType , DDC , IMT , LCC , LCSH , MESH , NLM , TGN , UDC
Syntax Encoding Schemes

Szintaxis kódolási sémák

Box , ISO3166 , ISO639-2 , ISO639-3 , Period , Point , RFC1766 , RFC3066 , RFC4646 , RFC5646 , URI , W3CDTF
Classes

Osztályok

Agent , AgentClass , BibliographicResource , FileFormat , Frequency , Jurisdiction , LicenseDocument , LinguisticSystem , Location , LocationPeriodOrJurisdiction , MediaType , MediaTypeOrExtent , MethodOfAccrual , MethodOfInstruction , PeriodOfTime , PhysicalMedium , PhysicalResource , Policy , ProvenanceStatement , RightsStatement , SizeOrDuration , Standard
DCMI Type VocabularyCollection , Dataset , Event , Image , InteractiveResource , MovingImage , PhysicalObject , Service , Software , Sound , StillImage , Text
Terms related to the DCMI Abstract ModelmemberOf , VocabularyEncodingScheme

Egy adott erőforrásról szóló állítások együttesen alkotják az ún. a leírás (description) egységét. Egymással valamilyen kapcsolatban lévő erőforrásokről szóló leírások alkotják a leírási készletet (descrpition set).

Az itt leírtak alapján tehát már értjük, és képesek vagyunk elemezni a következő példát. A példa egy egyszerű DC leírás (description), amely RDF/XML kódolású.

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF PUBLIC "-//DUBLIN CORE//DCMES DTD 2002/07/31//EN"
"http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd">

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://dublincore.org/">
<dc:title>Dublin Core Metadata Initiative - Home Page</dc:title>
<dc:description>The Dublin Core Metadata Initiative Web site.</dc:description>
<dc:date>2001-01-16</dc:date>
<dc:format>text/html</dc:format>
<dc:language>en</dc:language>
<dc:contributor>The Dublin Core Metadata Initiative</dc:contributor>
<dc:title xml:lang="fr">L'Initiative de métadonnées du Dublin Core</dc:title>
<dc:title xml:lang="de">der Dublin-Core Metadata-Diskussionen</dc:title>
</rdf:Description>
</rdf:RDF>

Természetesen a szemantikus web nagyon sok területére nem térhettünk itt ki. Így nem tértünk ki az osztályok, az ontológiák és a szemantikus keresők speciális területeire sem. A Dublin Core, a metaadatok és a szemantikus web alapvető kapcsolatának a megértetése lehetett csak célunk ilyen terjedelemben.

Ellenőrző kérdések:

  1. Milyen elemekből épül fel egy RDF állítás, azaz triplet?

  2. Miért fontos az URI-k használata a szemantikus web kontextusában?

  3. A Dublin Core metaadat elemek az RDF állítások mely elemeként jelennek meg?

Digitális könyvtárak menedzselésére alkalmazható szoftverek és keretrendszerek

A digitális gyűjtemények menedzselésére kifejlesztett ún. kulcsrakész szoftverek, vagy keret-rendszerek olyan megoldásokat jelentenek, amelyek segítségével már kevés programozói vagy informatikai tudással is biztosíthatjuk a digitális dokumentumaink online elérhetővé tételét, tárolását, megőrzését, publikálását, és kereshetővé tételét. Az ilyen típusú keretprogramok felé ma már komoly elvárásokat támasztanak felhasználóik, hiszen az általuk menedzsel digitális könyvtárakkal szemben is egyre magasabbak az elvárások.

A digitális gyűjteményeket menedzselő szoftverektől alapvető elvárás, hogy jól kezeljék a különböző formátumú digitális dokumentumokat, illetve, hogy minél több típusú digitális dokumentum kezelésére legyenek képesek, és az újonnan megjelenő formátumokat is támogassák. Szintén alapvető elvárás, hogy a digitális dokumentumokhoz kapcsolódó metaadatokat is képesek legyenek kezelni, illetve a helyi metaadat sémák dokumentálása is megoldható legyen a keretrendszeren belül. Ma már az is fontos elvárás, hogy más digitális könyvtárakkal, külső keretrendszerekkel is jól együtt tudjanak működni (interoperabilitás), miközben képesek legyenek megbirkózni mindazzal a heterogenitással, ami a digitális könyvtárakat jellemzi. A hozzáférési és a feltöltési jogosultságok adminisztrálását és menedzselését is biztosítaniuk kell a keretprogramoknak. Ezek az alapvető funkciók pedig lehetőleg felhasználóbarát és esztétikus kezelőfelületen keresztül legyenek használhatók.

Mivel ezek a keretprogramok folyamatos fejlesztés alatt állnak, így ezekhez az alapvető funkciókhoz ma már egyre több kiegészítő funkció is kapcsolódik. Ilyenek például, hogy ma már a felhasználók megjegyzéseket fűzhetnek akár egy gyűjtemény kezdőlapjához, akár egy-egy digitális dokumentumhoz; a szemantikus keresés irányába is folynak fejlesztések, és egyre inkább megjelennek ilyen típusú kiegészítő alkalmazások; statisztikai kiegészítések is léteznek; kötött szókészletek, ontológiák használatát lehetővé tévő alkalmazások is használhatók már; ajánlások is tehetők a felhasználók számára bizonyos alkalmazások segítségével.

Nézzük meg milyen típusú keretrendszerek léteznek.

Kifejezetten könyvtárak, múzeumok és levéltárak által menedzselt digitális gyűjteményhez fejlesztett szoftverek:

  • CONTENTdm

  • Insight + LUNA

  • Greenstone

Intézményi repozitórium-szoftverek:

  • DSpace

  • Fedora

Integrált könyvtári rendszerekhez csatlakozó rendszerek:

  • DigiTool

  • Content Pro

Speciális szoftverek:

  • PastPerfect – múzeumok számára kifejlesztett szoftver

  • Filemaker Pro

CONTENTdm http://contentdm.org/Az OCLC által fejlesztett szoftver. Napjainkban az Egyesült Államokban a legnépszerűbb az ilyen típusú szoftverek közül. Használatához minimális informatikai, programozói ismeret szükséges, a program csomagként azonnal használható megoldásokat kínál a digitális dokumentumok megfelelő szabványok szerinti publikálására. Beépített modulok teszik lehetővé például kötött szókészletek használatát, vagy a helyi metaadat alkalmazási profil megtervezését és dokumentálását. Nem ingyenes, de komoly felhasználó támogató apparátus áll mögötte. Napjainkban kb. 2.000 intézmény használja a világ minden pontjáról.

DSpace http://www.dspace.org/Az MIT és a HP által intézményi repozitóriumok menedzselésére kifejlesztett szoftver. De digitális gyűjtemények menedzselésére is jól használható. Ingyenes és nyílt forráskódú. Jelenleg mintegy 1.400 regisztrált felhasználója van, amelyből közel 500 kutatói, vagy tudományos intézmény. Kulcsra kész szoftver, amely szintén nem igényel programozói fejlesztéseket. Bár lehetővé tesz többféle testre szabási ehetőséget. A szemantikus web irányába egyelőre csak egy kiegészítő alkalmazás erejéig történt fejlesztés a keretrendszerrel kapcsolatban.

Greenstone http://www.greenstone.org/A szoftvert fejlesztésének elindítása a New Zealand Digital Library Project nevéhez fűződik. Nyílt forráskódú, többnyelvű szoftver, amit kifejezetten digitális könyvtárak publikálására, menedzselésére alakítottak ki. A Greenstone szoftver legújabb verziója már a szemantikus digitális könyvtári rendszerek közé tartozik. Azaz nem csak egyfajta kiegészítő alkalmazásként jelenik meg a szemantikus web irányába való fejlesztés, hanem az új verzió szerint már a digitális könyvtár szerkezete is a szemantikus web elveit követi.

JeromeDL http://www.jeromedl.org/Kifejezetten szemantikus digitális könyvtár létrehozására és menedzselésére létrehozott szoftver. Fejlesztése folyamatos, még viszonylag kezdetleges felhasználói köre van. A tapasztalatok gyűjtése, és a keretrendszer további javítása, alakítása folyamatban van.

Ellenőrző kérdések:

  1. Minimálisan milyen funkciókat kell ellátniuk a digitális könyvtárak menedzselésére alkalmazott szoftvereknek?

  2. Soroljon fel néhány ismert és széles körben alkalmazott ilyen típusú szoftvert!