Metadata ja sen hyödyntäminen verkkoympäristössä

HY/Palmenia 2005-04-27

Juha Hakala, HYK

Luennon tavoite

• Antaa yleiskuva siitä, mitä metadata on, mihin sitä käytetään ja millaista metadataa perinteinen ”integroitu” kirjastojärjestelmä ja tiedonhakuportaali edellyttävät

• Käsiteltäviä formaatteja MARC ja Dublin Core (etupäässä portaalin näkökulmasta)

• Oletetaan perustiedot näistä formaateista

Luennoijan taustaa

• HYK:n kehittämisjohtaja

• Vastaa tietokantapalvelut –yksiköstä– MARC21-Fin formaatin ja Dublin Coren

suomalaisen version ja sen joidenkin varianttien ylläpito

– Kirjastoverkon koordinointivastuu• Kansallisten tietokantojen ylläpito

• Standardiaktivisti (ISO, IFLA, SFS, NISO)

Luentojen sisällöstä

• Yleistä metadatasta

• Kirjastojen ohjelmistoarkkitehtuuri: nykytilanne ja tulevaisuuden näkymät– Muutosten vaikutus järjestelmien metadataan

• Kirjastoverkon edellyttämien standardien analysointi

• Metadataformaattien esittely ja analyysi– Tavoitteena ei luetteloijakoulutus, vaan yleisemmän

tason arviointi

Metadata: mitä se on?

• Lyhyesti: tietoa tiedosta• Resurssin rakenteinen kuvaus; rakenteen ja

tietosisällön voivat määrätä erilaiset säännöt ja ohjeistot (formaatit)

• Metadatalla laaja ja yhäti kasvava määrä tehtäviä, joita on eritelty esimerkiksi IFLA:n Functional Requirements for Bibliographic Records (FRBR) –hankkeessa

Metadata: mitä se on (versio 2)?

• Tietyn ammattikunnan tarpeista ja käytänteistä syntynyt tapa kuvata resursseja ao. alan kannalta tarkoituksenmukaisella tavalla

• Yhden ammattikunnan (esimerkiksi kirjastot) kannalta tarkoituksenmukainen tapa ei yleensä sovellu muille (vaikkapa arkistot) kovinkaan hyvin, siitä huolimatta että metadataelementit voivat olla osin samoja– kirjastot ja arkistot jäsentävät aineistoa eri tavalla

(tekijä vs. arkiston muodostaja)

Metadataformaatit: tarkastelunäkökulma

• Kolme analyysitapaa:– Missio/pragmatiikka: mihin formaattia sovelletaan– Semantiikka: mitä kuvailun elementtejä käytettävissä– Syntaksi: tietuerakenne; miten tieto on saatu

koneluettavaksi ja jopa –ymmärrettäväksi

• Pragmatiikka ja semantiikka riippuvat ammattikunnasta ja ovat yleensä kehitysvaiheen jälkeen vakaita, syntaksi on laitteisto- ja ohjelmistoriippuvainen– Kirjastoissa syntaksi on ollut stabiili, mutta

kuvailuelementtien määrä on kasvanut 10-kertaiseksi

Metadatan missio: esimerkkinä Dublin Core

1. Developing metadata standards for discovery across domains;

2. Defining frameworks for the interoperation of metadata sets;

3. Facilitating the development of community or discipline-specific metadata sets that work within the frameworks of cross-domain discovery and metadata interoperability.

(http://www.dlib.org/dlib/december00/weibel/12weibel.html)

Metadatan missio: Dublin Core (2)

• DC:n missio on osoittautunut liian kapeaksi; rajaus tiedonhakuun (resource discovery) poistetaan uudessa missiossa, jossa tavoite tulee olemaan kuvailu (resource description)

• Discovery / description –ongelma oli esillä jo alkuperäisen mission laadinnassa, tuolloin lähdettiin kaitaa tietä

• Ongelmana sen määritteleminen, milloin metadataelementti edistää tiedonhakua ja se, että monet hankkeet tarvitsevat kuvailevia elementtejä– auttaako kokoelman kattavuustieto haussa?

Metadatan missio ja informaatiotutkimus

• Tutkijat ja asiantuntijat ovat yleensä keskittyneet yhteen formaattiin kerrallaan tai tarkastelleet muita formaatteja oman alansa työkalun näkökulmasta– ”DC is just MARC done badly” – Michael Gorman

• Järjestelmien ”olemassaolon tarkoitus” on ollut ongelmaton asia; tässä suhteessa DC:n paradigmakriisi on mielenkiintoinen tapaus

• MARC ja kirjastojen uudet järjestelmät voi tuottaa vastaavaa keskustelua MARCin sovellusalasta

Metadataformaattien semantiikka

• EU:n DESIRE-hankkeen formaattijako:– Yksinkertaiset (esim. hakukoneet)

• Standardoimattomia, perustuvat kokotekstiin

– Rakenteiset (Dublin Core simple, MODS)• Standardointi käynnissä/valmis, yksinkertainen rakenne

– Rikkaat (MARC, ONIX)• Vakiintuneita domain-kohtaisia standardeja• Satoja / tuhansia tietoelementtejä (MARC: noin 2000)

• 20 formaattia arvioitiin (1997); teksti osin vanhentunut ja osa formaateista puuttuu

• Analyysi keskittyy ”pintaan”

Semantiikka: yleistä

• Keskeistä se, onko kenttien määrittely taustalla jokin määritelty säännöstö vaiko ”mutu”– AACR2 (AACR3) ja MARC21– Kehittäjäryhmän konsensus ja Dublin Core– Yksittäisen kehittäjän näkemys ja ONIX

• MARC21:n sisältöön voi vaikuttaa periaatteessa vain luettelointisääntöjä muuttamalla

• DC:n peruskenttien (15 kpl) muuttaminen vaatii aksiomaattisten periaatteiden muuttamista

• ONIX muuttuu kun vastaava henkilö näkee sen tarpeelliseksi: heikko ennustettavuus ja vakaus

Semantiikka: yleistä (2)

• Hajautetussa tiedonhaussa (portaalit) semanttinen yhteismitattomuus on keskeinen ongelma– vaikka bibliografinen kuvailu olisi kohtuullisen

yhtenevää, indeksoinnissa ja hakuliittymän teknisessä toteutuksessa on suuria eroja

• Vaikka kaikki kirjastot käyttäisivät samoja sääntöjä, meillä olisi edelleen ongelmia kirjastojen välilläkin, puhumattakaan sektorirajat ylittävästä tiedonhausta (kirjastot / arkistot / museot)

Syntaksi

• Tutkimuksen kannalta vähiten lupaava alue– datan muunto koneluettavaksi on köyhä tutkimuskohde

verrattuna metadatan pragmatiikkaan ja semantiikkaan– silti suurin osa tutkimuksesta ja muusta kirjoittelusta

keskittynyt tälle alueelle• ”MARC is dead” – Roy Tennant

• Semantic Web ja datan koneymmärrettävyys (XML/RDF ja ontologiatyö) muuttaa tilanteen– rahoitusta ja tutkimusintressiä tarjolla, mutta miten

asettaa tavoitteet realistisesti – koko Webin kattava tehokas tiedonhaku on Graalin malja

Tekniikka ja kirjastot

• Teknologian kehitys on jo nyt mullistanut kirjastojen toimintaa; jatkossa muutostahti nopeutuu – Elektroninen julkaiseminen vaikuttaa työtapoihimme

enemmän kuin kirjapainotaidon keksiminen– Monia uusia ratkaisuja ja myös ongelmia (esimerkiksi

elektronisen aineiston pitkäaikainen säilyttäminen)

• Kirjastojen missio on edelleen sama (aineiston hankinta, organisointi, jakelu ja säilytys) mutta toimintatavat muuttuvat– Kirjaston asema kirjaketjussa säilynee, mutta kirjakaupan

ei, koska ne eivät pysty sopeutumaan

Tekniikka ja kirjastot (2)

• Kaikkien tietojärjestelmiemme toiminta perustuu korkealaatuiseen metadataan; tässä suhteessa perinteinen kirjastojärjestelmä, portaali ja DOMS ovat samanlaisia– ”Garbage in – garbage out”; vrt. UKK-kokoelma

• Tiedämme mitä kirjastojärjestelmän pitää tehdä ja millaista metadataa se edellyttää; portaalin ja DOMSin osalta konsensus puuttuu ja tarvittavien spesifikaatioiden rakentaminen on vasta alkanut

Integroitu kirjastojärjestelmä

• Kirjastoatk:n paradigma 80-luvulta alkaen– Kaikki keskeiset palvelut yhdessä sovelluksessa– Vakiintunut käsitys järjestelmän toiminnoista ja

niiden edellyttämästä metadatasta• Bibliografiset, varastotiedot ja auktoriteettitiedot

MARC-formaatissa; lisäksi muuta metadataa (niteiden ja asiakkaiden tiedot)

– Kuvailutiedoille vakiintuneet ohjeet• Luettelointisäännöt; niiden mukaan laaditut MARC-

formaatit; tietojen vaihtoon ISO 2709-syntaksi

Integroitu kirjastojärjestelmä ja informaatiotutkimus

• Alan tutkijoille kirjastojärjestelmä ei ole ollut juuri korttiluetteloa mielenkiintoisempi– Integroitujen järjestelmien käyttöönotto valtava

mullistus joka tuotti noin 20 % työnsäästön; ei yhtään kunnon tutkimusta aiheesta ainakaan Suomessa

– Korttiluettelo – näyttöluettelo –muutoksesta asiakkaan näkökulmasta ei tiedetä paljoa

• USA:ssa näyttöluettelo monille opiskelijoille ensimmäinen atk-sovellus; samoin ehkä Suomessa (aloitus 1988)

– Näyttöluettelosta portaaliin – miten tämä koetaan?

Kirjastojärjestelmäparadigman hajoaminen

• Vuonna 2005 ei enää ole integroitua kirjastojärjestelmää, vaan keskeiset palvelut tuotetaan useilla sovelluksilla– ILS, tiedonhakuportaali, elektronisten dokumenttien

hallintajärjestelmä (DOMS)– Suomi: Voyager, MetaLib ja ENCompass

• Uusien järjestelmien osalta pelisäännöt puuttuvat ja standardointi on keskeneräistä– päällekkäistyön riski on suuri; vanhasta sovelluksesta ei

välttämättä saa kuvailuja pelastetuksi uuteen

Tiedonhakuportaalit

• Kehittyivät tuotteiksi 90-luvun lopulla; verkon resurssien tehokas käyttö tavoitteena

• Toiminnallisesti osin perinteisen näyttöluettelon laajennus, mutta tarjoaa myös täysin uusia palveluita ja edellyttää uudenlaisia metatietoja toimiakseen tehokkaasti– myös kirjastojen toimintatapojen pitää muuttua

• Toistaiseksi portaalien metatiedot ovat valmistajakohtaisia eikä vaihtoformaattia ole; standardointiprosessi alkanut NISO:ssa 2003

DOMS-järjestelmät

• Sovelluksia digitaalisten julkaisujen, ei vain niiden kuvailutietojen hallintaan

• ILS-järjestelmän ja portaalin toiminnallisuudesta meillä on kohtuullinen käsitys; DOMS-järjestelmän palveluista vasta yleiskuva– keskeinen ongelma työnkulkujen määrittely

• Toimittajina sekä kirjastojärjestelmäfirmoja että muita softataloja (kuten portaaleillakin)– Sopivatko muiden sovellukset kirjastoympäristöön?– Sopiiko periaatteessa kirjastolle tehty sovellus muille?– Keille kirjastojärjestelmätoimittajat markkinoivat?

Modulaarinen kirjastojärjestelmä –malli

• Kirjasto soveltaa useita ohjelmistoja jotka kommunikoivat keskenään ja muiden sovellusten kanssa standardirajapintojen kautta– toimii paremmin paperilla kuin käytännössä…

• Voyagerin OpenURL-ongelma ja sen ratkaisu• Voyagerin Z39.50-ongelmat ja niiden ratkaisu

• Keskeiset toiminnot ovat ”perinteinen” kirjastojärjestelmä, portaali ja DOMS

• Nämä palvelut tuotetaan 1-n sovelluksella– Perinteinen kirjastojärjestelmä voi hajota edelleen moduleiksi;

esim. ILL-osio tai kopioluetteloinnin välineet voidaan hankkia erikseen

Modulaarinen kirjastojärjestelmä –malli (2)

• Menestys riippuu sovellusten yhteismitallisuudesta, joka puolestaan on riippuvainen standardeista ja niiden yhteismitallisesta soveltamisesta– Kirjastojen ja sovellustoimittajien yhteistyö– Kansalliskirjaston KATVE-työryhmä

• Portaali ja DOMS-järjestelmät vaativat uudenlaista metatietoa, jota tuottavat mm. kirjastot, kustantajat ja kirjakaupat– käytössä useita formaatteja ja kuvailusääntöjä rinnan

Portaalin metatiedot: ryhmätyö

• Pohtikaa pienryhmissä millaisia asioita tiedonhakuportaalissa pitäisi kuvailla, ja minkä tyyppisiä elementtejä näiden kuvausten tulisi sisältää

• Miettikää myös sitä, olisiko perusteita näiden uusien kuvailutietojen ahtamiselle MARC-formaattiin, ja jos olisi, mitä vaikeuksia MARC-laajennushanke saattaisi kohdata

• Ottakaa kantaa siihen, pitäisikö näitä tietoja voida vaihtaa kirjastojen kesken, ja jos pitäisi, niin miksi

Portaalin metatiedot: palvelukuvaukset

• Suomenkielinen termi ei ole vakiintunut, englanniksi service description

• Tarkoittaa verkon välityksellä haettavissa olevan tietokannan tai vastaavan palvelun kuvausta

• Hyvän portaalisovelluksen on sisällettävä mieluiten tuhansia hyvälaatuisia palvelukuvauksia; jos etätietokannan kuvaus on virheellinen, laadukas haku on mahdotonta

• Näiden tietojen ylläpito on vaativa tehtävä

Portaalin metatiedot: kokoelmien kuvaukset

• Kun portaalista pääsee satoihin tietokantoihin, oikean kannan valinnasta tulee ongelma

• Kantojen sisältö kuvailtava kokoelmatasolla; esim. HYK:n Slaavilainen kokoelma tai OYK:n Kekkosen kokoelma

• Tarvitaan yleisiä periaatteita kokoelmien valintaan sekä niiden aiheiden ja kattavuuden esittämiseen

• Yliopistokirjastojen Tietokartta-projekti pohjustaa kansallista yhteistyötä Suomessa– hanke päättyy lokakuussa 2005; tämän jälkeen palvelu voi

jatkua Kansalliskirjaston virkatyönä

Portaalin metatiedot: lisenssitiedot

• OpenURL-standardiin perustuva dynaaminen viitteiden ja dokumenttien linkitys edellyttää portaalin ”tietävän” aineiston sijainnin ja käyttöoikeudet– Kuvailutietojen oltava riittävän yhteismitallisia

• Lisenssi- ja sijaintitiedot muuttuvat– Ylläpito vaikeaa (vrt. URL:t); tiedot tulisi voida ostaa

kustantajilta tai välittäjiltä

• Ylläpitoon ei ole ollut sovelluksia– Endeavorin Meridian ensimmäinen lajiaan

Portaalin metatietojen ongelmia

• Ei sääntöjä eikä vaihtoformaattia - vielä– Kuvailujen vaihto eri portaalien välillä ja siirtyminen

seuraavaan portaaliin voivat olla vaikeita

• Vaikka palvelujen tietoja voitaisiin kerätä osin automaattisesti, on tehtävä käsitöitä– Yhden palvelun (esim Z39.50-serverin) kattava kuvailu voi

viedä viikon

• Metadatan omistusoikeus– Järjestelmätoimittajan ”strateginen tietovaranto”

• Epästandardit tietokannat: datan lyhyt elinkaari– palvelukuvausta voi joutua editoimaan jatkuvasti

Portaalin metatietojen ongelmia (2)

• Järjestelmätoimittajat katsovat että vaikein asia on hakutulosten (viitteiden) esittäminen

• Semantiikka oleellisempi ongelma; jos hakutulos on väärä, ei väliä jos viitteet ovat vinksallaan

• Pahimpaan ongelmaan, semanttiseen yhteismitallisuuteen ei ole päästy kunnolla käsiksi

• Tarvitaan aiempaa oleellista tarkempia palvelukuvauksia, joiden avulla portaali voi sovittaa asiakkaan hakutermit kohdetietokannalle

Portaalin metatietojen ongelmia (3)

• Tietojen tuottaminen on työlästä– osa palvelukuvauksista ja kokoelmien kuvailut

tehtävä käsityönä– epästandardien hakujärjestelmien

palvelukuvausten tekoa on vaikea ellei mahdoton automatisoida

• Saavatko kirjastot tarvittavat resurssit tietojen tallentamiseen– vrt. Tietokartta-hanke

Portaalin metatiedot ja MARC

• Kongressin kirjastolla ei ole tarkoituksena kehittää uutta MARC-formaattia kokoelmien kuvailua tai muuta portaalien metadataa varten

• Periaatteessa voidaan lisätä kenttiä tai tietoelementtejä jotka mahdollistavat tietojen tallennuksen MARC-muodossa

• Ongelma: onko jälkimmäinen ratkaisu riittävä?– ellei ole, portaalien metadataa ei voi tallentaa MARC-

muodossa, minkä vuoksi tallennus kirjastojärjestelmään voi olla vaikeaa ja siirto vanhasta kirjastojärjestelmästä seuraavaan & vaihto kirjastojen kesken mahdotonta

NISO Metasearch Initiative

• Työryhmä 2 (Collection description) kehittää kahta metadataformaattia:– Collection description metadata element set; pohjana

DC Collection description application profile (http://www.dublincore.org/groups/collections/)

– Service description metadata element set; pohja ZeeRex (http://explain.z3950.org/)

• Maaliskuussa 2005 todettiin että ZeeRex ja DC CD AP ovat nyt valmiita standardoitavaksi; luonnokset kommenttikierrokselle 2005 aikana

NISO MI:n palvelujen kuvailuformaatti

• Pohjana ZeeRex– http://explain.z3950.org/

• Tavoitteena kuvata kohdejärjestelmä – esimerkiksi Z39.50-palvelin – niin, että siitä voidaan tehdä tehokkaasti hakuja

• ZeeRexillä on pitkä historia alkaen Z39.50-standardin Explain-palvelusta jatkuen sen kevytversioon (Explain Lite) joka kehitettiin ONE2-projektissa 1990-luvun lopulla

”Simppeli” ZeeRex-tietue

• <explain> – <serverInfo>

<host>helka.linneanet.fi</host> <port>210</port> <database>Helka</database>

– </serverInfo>

• </explain>

”Täysikasvuinen” ZeeRex-tietue

• Voi sisältää <serverInfon> lisäksi kentät: – databaseInfo>: human-readable information about the

database: its title, a description, the address of a contact person, etc.

– <metaInfo>: information about the ZeeRex record itself: when it was created or last modified.

– <indexInfo>: information about how to search in the database: which indexes exist and what combinations of attributes may be used to search against them

– <recordInfo>: information about which record syntaxes the database can serve records in.

ZeeRex-tietojen tuottamisesta

• Jos kohdetietokanta noudattaa Z39.50:ttä tai muuta standardoitua hakuprotokollaa, merkittävä osa tiedoista on luotavissa automaattisesti– indexInfo, recordInfo –tiedot voidaan generoida; näistä

etenkin edellinen on hyvin vaikea luoda käsipelillä (kaikkien mahdollisten hakujen tekeminen on työlästä)

• Epästandardit järjestelmät vaativat käsityötä, minkä lisäksi niiden tiedot vanhenevat usein

Portaalin metatietojen vaihto

• Mitä enemmän portaaleissamme on palvelujen ja kokoelmien kuvauksia, sitä parempi– asiakkaamme eivät välttämättä edes erota tietokantoja ja

WWW-sivustoja tiedonlähteinä, mutta vain jälkimmäisiin on apua Googlesta; syvän Webin (tietokantojen) penkomisessa tarvitaan portaaleja ja niiden metatietoja

• Kirjastojen on pystyttävä vaihtamaan portaaliensa metatietoja mieluiten globaalisti

• Kuvailut (eritoten kokoelmien) on tehtävä niin, että niistä on hyötyä myös ulkomailla

DOMS-metatiedot: kokoelmat

• DOMS-sovelluksissa aineisto jaetaan usein kokoelmiin; niiden kuvailu on löytyvyyden kannalta keskeinen asia

• Kuvailuun tulisi soveltaa samoja periaatteita ja välineitä kuin portaalissa

• ”Bubble-up”; kokoelman yksittäisten dokumenttien kuvailuista voidaan siirtää elementtejä kokoelmatasolle haettavaksi

DOMS-metatiedot: pitkäaikaissäilytyksen metadata

• Oleellinen rooli el. aineiston arkistoinnissa

• Pitää tukea kaikkia tarvittavia toimenpiteitä– Kopiointi, migraatio, emulointi, …– Emo-osakohderakenne olisi suotava

• Kaikkia Word-dokumentteja koskevat asiat; kuvailtavan dokumentin erityispiirteet

• Useita hankkeita ja ehdotuksia; esim. OCLC:n ja RLG:n Premis

DOMS-metatietojen ongelmia

• Ei kuvailusääntöjä eikä vaihtoformaattia– Kuvailujen vaihto eri DOMSien välillä tai

kirjastojärjestelmään/portaaliin vaikeaa– Siirtyminen seuraavaan DOMS-sovellukseen voi

olla vaikeaa

• Useita kilpailevia ehdotuksia pitkäaikaissäilytyksen metadataksi– Aineistoa tallennetaan jo nyt, joten kuvailutyö pitää

aloittaa

Sovellusten yhteismitallisuuden edellyttämät standardit

• Standardeja tarvitaan useilla tasoilla, jotka kaikki edellyttävät toisiaan– Verkkokerros: TCP/IPv4, IPv6– Merkistö: ISO 10646, Unicode 4.0.1– Tiedon siirto: ASN.1/BER, RDF/XML– Palvelut: ISO ILL; NCIP; OpenURL;

tiedonhakuun Z39.50, ZING– Viitteet: MARC, MARCXML+

Standardipohjaisista palveluista

• ISO Interlibrary lending (ILL)– Kaukopalvelun viestinsiirto järjestelmien välillä

• NISO Circulation Interchange Protocol– Lainauksen edellyttämä tietojen vaihto; asiakkaiden ja

aineiston tietojen siirtäminen

• OpenURL– Dynaaminen linkitys viitteiden ja aineiston välille

• Käyttöönotto ei ole vain tekninen vaan myös poliittinen kysymys (ILL yliopistokirjastoissa)

Standardit (2)

• Standardisoimisjärjestöjä ja ryhmiä:– HYK:n KATVE-työryhmä– SFS/Tietohuoltokomitea– ISO TC46, IFLA (kv. taso)– ANSI/NISO (Nat. Information Standards Org.)– W3C, IETF (Internet-standardit)– EditEUR, International DOI Foundation

(teollisuusstandardit)

Standardoinnin käytäntö

• ANSI/NISO:n rooli merkittävä– ISO hyväksyy muutoksitta NISO-standardeja,

esim. Z39.50 = ISO 23950

• Standardointiin osallistuvia ei tarpeeksi– Informaatioalan sanastostandardin valmisteluun

ei osallistunut yhtään henkilöä jonka äidinkieli olisi ollut englanti; suomentaminen vaikeaa alkuperäisen sanaston ongelmien vuoksi

• Eritoten ISO-standardointi ollut hidasta

Standardoinnin käytäntö (2)

• HYK aktiivisesti mukana standardoinnissa• Päällekkäiset standardit ongelma

– Lähiverkkostandardit 1980-luvulla

– Uniform Resource Name ja DOI

– Miten valita oikea järjestelmä?

• Miten vakuuttaa ohjelmistotalot standardien tärkeydestä?– Sovellusten kehittäminen keskittyy usein käytännön

parannuksiin (”perfecting the irrelevant”)

Metadataformaatit: muita näkökohtia

• Käytännön valinnassa formaatin statuksella ja ylläpitoratkaisulla on väliä– Kv. standardi vai ei?– Onko ylläpito-organisaatioon mahdollista

osallistua, vai onko se suljettu?• Esim. ONIXin kehitykseen ei voi vaikuttaa

– Onko formaatti käytössä vai vasta kehitteillä?• Dublin Coren osalta otettiin HYK:ssa riski

MAchine Readable Catalogue: taustaa

• Ylläpitäjä Library of Congress (LC)– ALA:n MARBI-komitea valvoo kehitystä

• Syntaksi kehitettiin nykymuotoon jo 1968; se on takuulla laitteisto- ja ohjelmistoriippumaton– Ms. Henriette Avram (95 v.) oli avainhenkilö kolmen

hengen tiimissä, josta yksi edelleen LoC:ssä töissä

• Lähes jokainen kirjastojärjestelmä tukee MARCia – Järjestelmän sisällä datan rakenne on aina jotain muuta,

uusissa järjestelmissä jotain XML-vetoista

MARC: taustaa (2)

• MARC (ISO 2709-standardi) on metakieli, jonka avulla luodaan MARC-formaatteja– 70- ja 80-luvun mittaan luotiin parikymmentä kansallista

formaattia; 90-luvun jälkipuolelta lähtien niistä on vähittäin hankkiuduttu eroon; monet maat ovat siirtyneet MARC 21 –formaattiin

• MARCin valta-asema jatkuu vielä vuosia

• Suomen yo-kirjastoissa ratkaisu edessä syksyllä 2005– MARC21-Fin vai puhdas MARC21?

– Yleisten kirjastojen dilemma: pitääkö kiinni FINMARCista jonka tuki lakkaa pian, vai siirtyäkö MARC21:een?

MARC: pragmatiikka

• MARC-formaatteja voidaan soveltaa mm: – Bibliografisen kuvailun, auktoriteettitietojen ja

(kausijulkaisujen) varastotietojen tallennukseen• Auktoriteettitietoja mm. tekijöiden nimenmuodot,

organisaatioiden nimet ja asiasanat eri kielillä

– Lisäksi: Classification, Community information

• Uusia soveltamiskohteita voidaan määritellä periaatteessa vapaasti; MARC-syntaksi ei aseta rajoja

MARC: pragmatiikka (2)

• Tarvitsemmeko uusia formaatteja:– Kokoelmien kuvailulle– Palvelujen (kuten Z39.50-serverien) kuvailulle– Pitkäaikaissäilytyksen metadatalle

• Riittäisikö näille uudet kentät/tietoelementit?• Peruskysymys: tallennetaanko nämä tiedot

kirjastojärjestelmään ja/tai muualle– Jos muualle, esim. kansallisbibliografiasta tulee useiden

tietokantojen / järjestelmien muodostama hajautettu kokonaisuus (tämä lienee edessä joka tapauksessa)

MARC: semantiikka

• Semantiikka määräytyy ns. Pariisin periaatteista, ISBD-standardeista ja luettelointisäännöistä, joita Euroopassa käytössä 18 (ml. Suomi)– Pariisin periaatteita modernisoidaan, tavoitteena ICC

(International Cataloguing Code) joka korvaisi AACR:n ja muut kansalliset / alueelliset säännöt

• Sääntöerojen taustalla kulttuurierot ja niistä syntyneet menetelmäerot– ”Saksan aatelisten ja aatelissukujen nimien hallinta”

MARC: semantiikka (2)

• Luettelointisääntöjen proliferaatio on synnyttänyt kasan formaatteja; erilaisia MARCeja on kehitetty vuosien mittaan noin 20– osa näistä on jo kuopattu (AUSMARC, CANMARC) ja

osaa ei enää kehitetä (UKMARC, FINMARC)

• Kaikilla sama syntaksi, tietosisältö vaihtelee• Lisäksi on kaksi epästandardia järjestelmää,

Saksan MAB ja Hollannin kansallinen formaatti joka kehitettiin jo 60-luvun lopulla

MARC: semantiikka (3)

• Formaattikonversiot voivat olla todella vaikeita tietosisällön erojen vuoksi– yo-kirjastot FINMARC - MARC 21-Fin– Pääkaupunkiseutu: FINMARC- MARC 21

• MARC 21 korvannee lähes kaikki kansalliset formaatit 5-10 vuoden sisällä– Ruotsi, Suomi, Englanti, Saksa, Kanada, Australia jo

luopuneet kansallisista formaateista

• Taustalla mm. tarve tehostaa kopioluettelointia– HYK: 95 % ulkomaisista hankinnoista, merkittävä osa

takautuvasta luetteloinnista kopioimalla

MARC: semantiikka (4)

• MARC 21:ssä on noin 2000 tietoelementtiä (kenttiä, osakenttiä ja koodeja)

• Vain pientä osaa käytetään usein; MARC-luettelointi voi olla joko yksinkertaista (Varastokirjasto) tai kattavaa (Fennica)

• MARC-formaatin ja luettelointisääntöjen opettelu ei ole helppoa– Kopioluetteloijankin on tiedettävä mitä tekee– Isoissa tieteellisissä kirjastoissa eniten aikaa

auktoriteettikontrolliin; auktoriteettitietueiden kopiointi kehitteillä (VIAF-projekti)

MARC-kentät

• Teoriassa 1000 kenttää (000-999); jaettu ryhmiin niin, että käytettävissä on vähemmän kenttiä

• MARC 21:ssä määritelty 211 kenttää– 2002 Concise ed., Update no. 3 Oct. 2002

• Kasvunvaraa on vielä kaikissa ryhmissä, mutta epätasaisesti

• Uusia ryhmiä ei voi perustaa, vaikka tulisi tarve kuvailla jotakin täysin uutta– 9XX-kentät määrittelemättä; sovelluskohtainen käyttö

MARC 21: kenttäryhmät

• Esimerkkejä: – 05X-08X: luokitukset (16 kenttää)– 1XX: pääkirjaukset (4)– 3XX: fyysinen kuvailu (13)– 4XX: sarjoja koskevat tiedot (2)– 5XX: huomautukset (49)– 6XX: asiasanakentät (13)– 70X-75X: lisäkirjaukset (9)– 76X-78X: linkkikentät (16)

MARC 21: kenttäryhmät (2)

• Sanastoille ja luokituksille kenttiä säästävät kaatoluokat (esim. YSA:lle ja YKL:lle)– Vain harvalla sanastolla oma luokka

• Tallennettavien tietojen monimuotoistuessa ryhmistä tullut Prokrusteen vuoteita– Sekaryhmät 250-270 (painostiedot), 3XX (Fyysinen

kuvailu ja varsinkin 841-88X (Varastotiedot)

• Lisäykset mietitty tarkoin; yhtään kenttää ei ole tarvinnut perua (vrt. ONIX)

MARC: syntaksi

• Kehitettiin MARC-pilottihankkeessa Kongressin kirjastossa 1966-1968

• Henriette Avramin johtamalla projektilla oli neljä tavoitetta:– Atk-luettelointi– (korttiluettelon) tuottamisen automatisointi– Kirjastojen välinen tietuevaihto– Näyttöluettelon tuottamisen mahdollistaminen

• Korttiluettelon tuottamisen tarpeet etusijalla?– Vasta FRBR soveltaa atk:ta ilman vanhaa painolastia

MARC: syntaksi (2)

• MARC I 1966-1967– Kentän pituus max. 999 merkkiä, tietueen pituus max.

1346 merkkiä, ei nimiötä/hakemistoa, vain 20 kenttää, kenttäkoodi 2 numeroa

• MARC II 1967– Kentän pituus 9999 merkkiä, tietueen pituus 99999

merkkiä, nimiö/hakemisto, kenttäkoodi 3 numeroa

• MARC II supplemented 1968– Nimiö 12 -> 24 merkkiä, ”moderni” kenttävalikoima

• Tämän jälkeen syntaksi pysynyt samana!

MARC: syntaksi (3)

• MARC-syntaksi suunniteltiin ohjelmisto- ja laitteistoriippumattomaksi; tässä onnistuttiin hyvin, sillä se ei ole muuttunut 35 vuoteen

• MARC eroaa monessa suhteessa siitä mitä 60-luvulla yleensä tehtiin – Vaihtuvamittaiset kentät– Laaja merkkivalikoima (MARC-8)– Ohjaustiedot upotettu tietueeseen (nimiö + hakemisto)

• Menestyksen taustalla myös LC:n suhdetoiminta

MARC: syntaksi (4)

• MARC/ISO 2709 jakaa tietueen kolmia:– Nimiö

• Tietuetta koskevaa ohjaustietoa; esim. merkistö

– Hakemisto• Vaihtuvamittaisten kenttien sijainti ja pituus

– Data• Vaihtuvamittaiset kentät

• Data ihmisen luettavissa, jos merkistö OK• Ohjaustiedon ansiosta myös koneluettavuus oli

hyvä; XML-vetoisessa maailmassa tilanne toinen

MARC: syntaksi (5)

• Merkistö riippuu formaatista– MARC 21: MARC-8 & Unicode (UTF-8)– FINMARC: ISO 6937/2– Merkkikonversio osa formaattikonversiota

• MARC 21 sallii kuvailutietojen esittämisen rinnakkain alkuperäisenä (vaikkapa venäjäksi) ja translitteroituna– Tämä helpottaa oleellisesti indeksointia ja näyttöjen

rakentamista; luettelointi vaikeampaa

Miksi MARC on yhä elossa?

• Hyvä tekninen suunnittelu– 35 vuoden jälkeenkään pullonkauloja ei ole

• Mahdollisia ongelmia: nimiön täyttyminen, kenttäkoodien loppuminen kesken

• Maksimaalinen tuki luettelointisäännöille– ”kirjastomainen näkökulma aineistoihin”

• Ylivoimainen markkina-asema– Käytännössä jokainen kirjastojärjestelmä tukee

MARC: kehitysnäkymiä

• MARC 21:stä tulee globaali formaatti– Miten varmistetaan että kaikki voivat osallistua

formaatin kehittämiseen?– Vaihtoehtona paikalliset soveltamistavat

• Kansallisten vastuutahojen nimeäminen ja heidän toimialansa määrittely

• Formaatin laajentaminen uusille sovellusalueille (pitkäaikaissäilytys)?

• MARC-syntaksia tukevat vain kirjastojärjestelmät; tähän ei muutosta tulossa (kustantajat: ONIX)

MARCXML/MARCXML+

• MARC 21-tiedon XML-muotoinen esitystapa• Skeeman ylläpitäjä LC; ei standardi (vielä)• MARCXML ei ole ISO 2709-standardia vastaava

metakieli (vaikkei se olekaan täysin MARC 21 –sidonnainen)

• XML-pohjainen vaihtomuotostandardi MARCXML+ tulossa ISO 2709:n seuraajaksi– DIS-versio julkaistaan 2005; standardi jo 2006? – Tiedon siirto muiden muistiorganisaatioiden ja

kustantajien/kirjakauppojen kanssa helpottunee(?)

Dublin Core

• Pyrkii määrittelemään sovellusympäristöstä riippumattomat keskeiset metadataelementit

• Kehitystyö alkoi 1995; formaatin versio 1.0 saatiin valmiiksi 1998– Taustalla kahvitaukokeskustelu Internet-tiedonhausta

WWW-kokouksessa

• Nykyinen versio 1.1; standardoitu ISO:ssa • Ylläpito-organisaatio OCLC; merkittävä

taloudellinen tuki mutta ei sisällön ohjausta

Dublin Core: hallinto

• DC Directorate: ”juoksevat” asiat

• DC Board of Trustees (johtokunta)

• DC Usage Board (semantiikka-asiat)

• DC Advisory Board (taktiikka)

• DC Working Groups (kehitystyö)

• DC National Affiliates (kansall. tuki)– HYK ensimmäinen national affiliate

Dublin Core workshopit

• Vuosittain järjestettävä käyttäjäkokous– 1995 40 osallistujaa, 2003 jo useita satoja– 1997 kokous Helsingissä; 2005 Madridissa

• Alkuvaiheessa kokoukset tekivät päätöksiä, nykyän niiden rooli on tiedottava, ja ohjelmaan kuuluu konferenssi jossa kerrotaan DC-hankkeista ja tutkimuksesta– Osallistuminen Suomesta ei kovin aktiivista

Dublin Core Suomessa

• Kansallinen SFS-standardi julkaistiin vuonna 2002; sisältää peruskentät ja eräitä keskeisiä tarkenteita ja merkintäjärjestelmiä

• HYK ylläpitää formaattia ja tukee käyttäjiä– Vastuut laajenneet kirjastoista muihin organisaatioihin;

jatkoa vaikea ennakoida

• Asiakirjojen kuvailuun tarkoitetusta DC-laajennuksesta valmistui versio 2.0 vuonna 2004; sitä sovelletaan esim. ministeriöissä

Dublin Core: pragmatiikka

• Alkuperäinen tavoite resurssien haku ja metadatan vaihto yli domain-rajojen

• Ei tiedetty ketkä DC:tä ryhtyvät käyttämään ja mihin tarkoitukseen– DC:tä ei kehitetty kirjastoille eikä se pyri kilpailemaan

MARCin kanssa

• Nykyisin DC:n käyttöala on paljon laajempi ja erilainen kuin alkuun osattiin arvioida; missiota on laajennettava hausta kuvailuun

Dublin Core: pragmatiikka (2)

• DC-työryhmät ovat laajentaneet formaattia tietyille erikoisaloille; application profiles– Administrative metadata, Citation, Collection

Description, Education, Government, Libraries

• Formaattia sovelletaan hyvin monenlaisissa organisaatioissa hyvin eri tarkoituksiin– Esim. Nokian dokumenttienhallintajärjestelmä,

valtioneuvoston asiakirjajärjestelmä

Dublin Core: semantiikka

• Ei sidoksissa mihinkään sääntöihin tai tietyn ryhmän ammatilliseen käytäntöön, vaan vain DC-kehittäjien konsensukseen– Monista kentistä kiisteltiin paljon

• DC-semantiikka on aksiomaattinen järjestelmä, sitä ei voi todistaa oikeaksi tai vääräksi– DC:n 15 elementtiä ovat uskon asia kuten 10 käskyä

• Peruskenttien lisäys/poisto mahdotonta, vaikka kentissä on epäloogisuuksia

Dublin Core –kentät

• Nimeke • Tekijä• Aihe• Kuvaus• Julkaisija• Muu tekijä• Aikamääre• Laji• Formaatti• Identifiointitunnus

• Lähde• Kieli• Suhde• Kattavuus• Oikeudet

Dublin Core –semantiikan kritiikkiä

• Päällekkäisyyskritiikki– Lähde ja Suhde kuuluvat yhteen– Tekijä, muu tekijä, julkaisija = Toimija + rooli

• Irrelelevanssikritiikki– Kattavuus ja Oikeudet eivät kuulu ytimeen

• Puutekritiikki– Versio-kenttä ehdottoman tarpeellinen

• Näkökulmakritiikki– Kirjastoilla liikaa valtaa (tekijä / muu tekijä)

Dublin Core: sovellusprofiilit

• Keino laventaa formaatin semanttista katetta

• Toisin kuin perus-DC, kehitetään ajatellen tiettyä erikoistarvetta; voivat laajentaa formaattia oleellisesti

• Suomessa tärkeimmät asiakirjojen kuvailun DC-sovellusprofiili sekä kokoelmien kuvailun DC-versio

DC Collection Description Application Profile

• Omat termit:– Accrual method

– Accrual periodicity

– Accrual policy

– Completeness

– Date contents created

– Is located at

– Is accessed via

– Logo

• Muut DC-termit:– Abstract

– Extent

– Access rights

– Provenance

– Audience

– Spatial / Temporal

– Created

– Own

– Has part / Is part of

– Is referenced by

Dublin Coren soveltamisesta

• Yksikään kenttä ei ole pakollinen (toisin kuin MARC-formaatissa)

• DC-käyttöohje ei tarjoa kovin paljon tukea, käytännössä DC-hankkeet tekevät omia

• Kukaan ei ole selvinnyt vain peruskentillä (paitsi OAI-PMH), hankkeet soveltavat tarkenteita ja omia lisäkenttiä– DC-projektit voivat olla semanttisesti yhteismitattomia

Dublin Core: käyttö kirjastoissa

• Ei tarvetta soveltaa bibliografisessa kuvailussa; MARC parempi vaihtoehto

• DC:n soveltaminen uusilla alueilla (esimerkiksi kokoelmien kuvailu) alkamassa; MARC ei näillä näkymin ole käytettävissä

• DC voi korvata MARC-formaatin DOMS-järjestelmissä ja mahdollisesti portaaleissa

• Tietojen vaihto muiden organisaatioiden kanssa (arkistot, museot)– Suomi: Kamut2-projekti

Dublin Core: muu käyttö

• DC:stä tullut yleinen valinta joillakin erikoisaloilla– Asiakirjojen metadata: Englanti, Tanska, Suomi

– Dokumenttien hallintajärjestelmät (ENCompass)

• Käytön ja implementoinnin helppous ja joustavuus, Web-pohjaisuus selittävät suosiota, kilpailun puutteen ohella– Ei muita domain-riippumattomia formaatteja

• Dublin Core ja Semantic Web?

Tulevaisuuden näkymiä

• MARCin asema on vahva, koska– Se vastaa kirjastojen tarpeita peruskuvailun

osalta hyvin– Kaikki kirjastojärjestelmät tukevat sitä, eikä

vaihtoehtoa ole edes näköpiirissä (ellei MARCXML+:aa lasketa sellaiseksi)

– Kirjastojen välisessä tiedonsiirrossa uuteen formaattiin siirtymisestä ei olisi hyötyä

Tulevaisuuden näkymiä (2)

• MARCiin asema on uhattuna, koska– Ei ole varmaa että uudet kuvailutarpeet kuten

pitkäaikaissäilytyksen metadata voidaan tai kannattaa hoitaa sen avulla

– Vaikka perinteinen integroitu kirjastojärjestelmä on MARC-vetoinen, uudet järjestelmät (portaali, DOMS) eivät todennäköisesti ole

– Koko muu maailma käyttää ennen pitkää XML-pohjaista metadataa, miksi emme me?

Tulevaisuuden näkymiä (3)

• MARCin asema on uhattuna, koska– Bibliografiseen kuvailuun tullaan käyttämään

ONIXia, MODSia, DC-Libraries –formaattia ja mahdollisesti muita järjestelmiä, ei välttämättä kirjastoissa mutta muissa organisaatioissa joiden kanssa teemme yhteistyötä

– Monet tahot voivat haluta formaatin jota voivat hallita itse, ilman MARCin byrokratiaa

Tulevaisuuden näkymiä (4)

• Kirjastot tulevat tuottamaan metadataa erilaisilla järjestelmillä, formaateilla ja säännöillä eri tarpeisiin– Tietokartta: kokoelmien kuvailut

– Portaali: palvelujen kuvailut

• Tietojen saumaton vaihto kirjastojen välillä ja laajemmin tulee edellyttämään uusia vaihtoformaatteja

• Koska metadataa on tallennettava aiempaa enemmän, rajat ylittävä yhteistyö on tarpeen– kustantajat (ISBN-yhteistyö), arkistot ja museot (kokoelmat),

julkishallinto yleensä (pitkäaikaissäilytys)

Lopuksi

• Syntaksimuutokset eivät ole dramaattisia; ne ovat pitkälti tekniikan kehityksen sanelemia eivätkä vaikuta kirjastojen toimintaan

• Pragmatiikan ja semantiikan muutokset liittyvät suoraan siihen mitä teemme; perinteisen kirjastojärjestelmän hajoaminen palasiksi synnyttää paineita ensisijaisesti käytänteisiin, mutta myös semantiikan tasolle– luettelointisääntöjen uudistus koskee toistaiseksi vain

perinteisiä bibliografisia tietoja

• Odotettavissa on usean vuoden kuohuntavaihe ennen uutta ”triangelisoitua” tasapainotilaa

Linkkejä

• MARC ja DC-formaatit ovat verkossa oheismateriaaleineen:– http://www.dublincore.org

• http://www.ukoln.ac.uk/metadata/dcmi/collection-ap-summary/

– http://www.loc.gov/marc

• Luettelointisäännöt, FRBR ja FRANAR: katso http://www.ifla.org

• ZeeRex– http://explain.z3950.org/