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

1. Metadata ja sen hyödyntäminen verkkoympäristössä HY/Palmenia 2005-04-27 Juha Hakala, HYK

2. 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

3. 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)

4. 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

5. 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

6. 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)

7. 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

8. Metadatan missio: esimerkkinä Dublin Core • Developing metadata standards for discovery across domains; • Defining frameworks for the interoperation of metadata sets; • 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)

9. 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?

10. 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

11. 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”

12. 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

13. 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)

14. 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

15. 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

16. 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

17. 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

18. 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?

19. 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

20. 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

21. 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?

22. 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

23. 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

24. 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

25. 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ä

26. 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ä

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. ”Simppeli” ZeeRex-tietue • <explain> • <serverInfo> <host>helka.linneanet.fi</host> <port>210</port> <database>Helka</database> • </serverInfo> • </explain>

35. ”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.

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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+

42. 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)

43. 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)

44. 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

45. 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”)

46. 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

47. 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

48. 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?

49. 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

50. 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)