1 / 85

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

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

shufang-chi
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related