Kieli, aika ja avoin linkitetty data

Hakala J (2018). Kieli, aika ja avoin linkitetty data. Tietolinja, 2018(1). Pysyvä osoite: http://urn.fi/URN:NBN:fi-fe201802133367

Kirjastojen tuottamia kuvailutietoja on alettu tarjota avoimena linkitettynä datana. Riippumatta siitä, mihin kohdeformaattiin muunnos tehdään, kaikki kuvailuissa olevat tietoelementit pitäisi saada paitsi ylipäätään konvertoiduksi, myös Internetissä ja semanttisessa Webissä käytettävään muotoon. Tässä artikkelissa tarkastellaan aikaa ja kieltä koskevien koodimuotoisten kuvailutietojen muuntamista.

Taustaa

MARC-formaatti luotiin Kongressin kirjastossa Henriette Avramin johtamassa MARC Pilot Project -hankkeessa, joka päättyi kesäkuussa 1968[1]. Formaattia on käytetty kirjastoalalla laajasti jo 70-luvulta lähtien. Sen varhaishistorialle olivat tyypillisiä alkuperäiseen MARC-formaattiin perustuvat, mutta sitä kehittyneemmät ratkaisut kuten Iso-Britannian UKMARC ja Suomen FINMARC. Toisin kuin alkuperäisessä MARC-formaatissa, niissä ei esim. tallennettu välimerkkejä dataan (koska kirjastojärjestelmä voi tehdä sen) ja nimitiedot tallennettiin rakenteisesti (suku- ja etunimet eri osakenttiin).

90-luvulla Internet loi edellytykset kirjastojen kansainväliselle luettelointiyhteistyölle. Kansalliset MARC-variantit vaikuttivat poimintaluettelointia, minkä vuoksi Kongressin kirjasto, British Library ja Kanadan kansalliskirjasto alkoivat jo 1994 selvittää mahdollisuuksia CAN/MARCin, UKMARCin ja USMARCin yhdistämiseen[2]. Tämä selvitystyö johti lopulta MARC 21 -formaattiin, jolla on kirjastojärjestelmissä tätä nykyä lähes monopoliasema. Kanadan ja Iso-Britannian jälkeen monet muutkin maat, Suomi muiden muassa, ovat lopettaneet kansallisten formaattiensa käytön ja siirtyneet MARC 21 -formaatin käyttäjiksi, vaikka sitten vähän pitkin hampain.

Bibliografisen datan semantiikan määrittelevät luettelointisäännöt. Formaatit määrittelevät vain datan syntaksin, ja kirjastojärjestelmät voisivat periaatteessa tukea useita formaatteja rinnan datan vaihdettavuuden maksimoimiseksi. MARC-formaatin vahva asema perustuu siihen, että useimmat kirjastojärjestelmät on suunniteltu sen ehdoilla. Esimerkiksi Voyageriin ei Endeavorin lupauksista huolimatta saatu FINMARC-tukea, eikä edes MARC 21:n pohjalta kehitetyn, akuutit tarpeemme huomioon ottaneen MARC 21-Fin -formaatin toteutus ollut kaikin osin ongelmaton.

Ohjelmistokehityksen vaativuus voi olla osasyy siihen, että MARC 21:n todennäköisin seuraajakandidaatti, BIBFRAME, on yhä keskeneräinen. Projekti on ollut käynnissä jo vuosia, mutta sen päättymisajankohta ei ole vielä tiedossa. Koska uuden formaatin täytyy sisältää periaatteessa kaikki MARC-formaatin dataelementit, muualla kehitettyjä avoimen datan formaatteja kuten Schema.org –yhteisön skeemoja[3] ei voi käyttää luetteloinnissa, vaikka ne soveltuvatkin kirjastojen tuottamien metatietojen jakeluun ulkopuolisille tahoille.

MARC 21 -formaatin vahvuus on sen hyvin organisoitu kehittämisprosessi. Formaatista, samoin kuin sen edeltäjästä, ei ole julkaistu uusia versioita, mutta siihen on vähä vähältä lisätty vuosien mittaan koko ajan uusia ominaisuuksia. Kaikki muutosehdotukset ja niihin liittyvä dokumentaatio löytyy helposti verkosta[4]. Nykyinen MARC 21 sisältää noin 200 kenttää alkuperäisen MARC-formaatin 20 sijaan, mutta näiden 20 kentän osalta vanha ja uusi ovat keskenään yhteismitallisia – määritykset joko löytyvät uusimmastakin MARC 21 -formaatista, tai niitä ei ole otettu muuhun käyttöön.

Kaikki muutokset on mahdollista jäljittää myös formaatista. Englanninkielisen MARC 21 -formaatin kattavaan eli full-versioon sisältyy muutoshistoria. Esimerkiksi kenttä 045 (Ajankohta tai ajanjakso) lisättiin USMARCiin 1979 ja sitä muokattiin viimeksi vuonna 1987, jolloin osakenttä $b:n määritelmää muutettiin ja osakenttä $c lisättiin.

Suomenkielinen MARC 21 perustuu alkuperäisen formaatin Concise-versioon, josta muutoshistoria puuttuu. Luetteloidessa sitä ei toki tarvitsekaan, mutta toisinaan tieto siitä, milloin kenttää on muutettu, on hyödyllinen. Kun tietää että päivämäärän ja ajan tallennusmuodon määrittelevä standardi ISO 8601 ilmestyi 1988, eli vuosi sen jälkeen kun 045-kenttää viimeksi päivitettiin, ymmärtää miksi kenttä ei ole standardin mukainen. Sitä muutoshistoria ei kuitenkaan selitä, miksi kenttää ei ole viimeisten 30 vuoden aikana päivitetty ISO 8601:n tasalle. Onko se mahdollisesti jäänyt vanhentuneena pois käytöstä? Vai onko tietokannoissa katsottu olevan niin paljon vanhamuotoista dataa, ettei formaatin päivittämiseen ja sen edellyttämiin takautuviin ohjelmiston ja datan muutoksiin ole haluttu ryhtyä?

Avoimesta datasta

Avoin data on verkossa olevaa informaatiota, jota kuka tahansa saa ja voi käyttää vapaasti. Avoimena datana kirjastojen tuottamien metatietojen pitäisi siis olla vapaasti kaikkien ulottuvilla, mahdollisimman vapaasti lisensoitua mutta myös teknisesti tarkoitukseen soveltuvaa. Avoimen datan määritelmän[5] mukaan tämä tarkoittaa esimerkiksi seuraavaa:

The work must be provided in a convenient and modifiable form such that there are no unnecessary technological obstacles to the performance of the licensed rights. Specifically, data should be machine-readable, available in bulk, and provided in an open format (i.e., a format with a freely available published specification which places no restrictions, monetary or otherwise, upon its use) or, at the very least, can be processed with at least one free/libre/open-source software tool.

Metatietojen koneluettavuuteen vaikuttaa suuresti se, ovatko tallennetut tiedot vapaatekstiä vai koodeja. MARC 21 tarjoaa usein molemmat vaihtoehdot siten, että perustiedot annetaan koodeina, mutta niitä voidaan täydentää huomautuksilla. Esimerkiksi kieliä koskevat kooditiedot tallennetaan kenttiin 008 (koodipaikka 35-37) ja 041, mutta niitä voidaan täydentää kenttään 546 (Huomautus kielistä) tallennettavalla informaatiolla:

546 ## ‡3 John P. Harrington field notebooks ‡a Apache; ‡b Phonetic alphabet.

546 ## ‡3 Marriage certificate ‡a German; ‡b Fraktur.

Avoimen datan näkökulmasta paras vaihtoehto olisi tallentaa mahdollisimman paljon metatietoa muun muassa kielistä koodeina. MARC-formaattia modernimpi kirja-alan ONIX-formaatti käyttääkin koodeja paljon MARCia enemmän. Osittain MARCin ongelmat avoimuuden suhteen johtuvat sen iästä. 546-kenttää on viimeksi päivitetty 1990, jolloin avoimesta datasta sen nykyisessä merkityksessä ei vielä tiedetty mitään, eikä myöskään poimintaluettelointia tehty läheskään nykyiseen malliin. Ei siis ihme, että kenttä 546 on heikosti koneymmärrettävissä ja kansainvälistettävissä. Merkittävä parannus saataisiin aikaiseksi jo mahdollistamalla kielen ja b-osakenttään tallennettavan kirjaimiston esittäminen myös ISO-standardien ISO 639 ja ISO 15924 mukaisina koodeina vapaatekstin lisäksi tai asemesta. Tällöin jälkimmäinen 546-kenttä tallennettaisiin muodossa

546 ## ‡3 Marriage certificate ‡a German; ‡a ger; ‡b Fraktur; ‡b. Latf

Uusien 546-kentän osakenttien määritteleminen kooditiedoille parantaisi koneluettavuutta entisestään.

Kansainvälistäminen ja kotoistus

Kansainvälistäminen ja kotoistus ovat Wikipedian mukaan toimia, joilla julkaisuja tai ohjelmistoja sovitetaan vieraaseen kulttuuriympäristöön. Kansainvälistäminen tarkoittaa esimerkiksi ohjelmiston rakentamista siten, että se voidaan (helposti) ottaa käyttöön periaatteessa missä tahansa. Yksittäisistä atk-alan toimijoista Unicode-konsortio on kansainvälistämisen edelläkävijä. Sen kehittämän Unicode-merkkivalikoiman tuntevat kaikki tietokoneiden parissa töitä tekevät, mutta konsortio on tehnyt paljon muutakin.

Unicode-konsortion Common Locale Data Repository eli CLDR-tietovaranto[6] on eräänlainen kansainvälistäjän raamattu. Se päivitetään noin kerran vuodessa, 32. versio julkistettiin marraskuussa 2017. Tiivistelmä sen Suomea ja suomen kieltä koskevasta informaatiosta löytyy osoitteesta http://www.unicode.org/cldr/charts/32/summary/fi.html. Tiivistelmästä löytää mm. yli 600 kielen ja lähes 200 kirjoitusjärjestelmän suomenkieliset nimet. Tietovarannosta löytyy toki vastaavia tietoja myös ruotsiksi sekä vaikkapa inarinsaameksi ja pohjoissaameksi.

Suomea koskevia CLDR-tietoja ylläpitää Kansalliskirjaston hallinnoima Kotoistus-hanke[7], jonka tavoitteena on edistää kielellistä yhdenvertaisuutta ja tasa-arvoa sekä käyttäjäystävällisyyttä, käytettävyyttä ja ymmärrettävyyttä. Sen tehtäväpiiri on toki paljon Unicode-yhteistyötä laajempi; hanke on huolehtinut esimerkiksi siitä, että Suomessa voidaan käyttää meidän oloihimme optimoitua näppäimistöä.

Kotoistus on erityispiirteiden lisäämistä tietyssä määrätyssä kohteessa (maassa) tapahtuvaa käyttöä varten. Kuulostaa yksinkertaiselta, mutta käytäntö on jotakin muuta. Kun Tieteellisten kirjastojen atk-yksikön koordinoimassa Linnea-hankkeessa otettiin 1990-luvun alussa VTLS-ohjelmisto käyttöön yliopistokirjastoissa ja muutamissa erikoiskirjastoissa, kotoistamisessa oli paljon haasteita, vaikka VTLS olikin aikanaan varsin edistyksellinen ohjelmisto. Esimerkiksi merkkivalikoima oli pakko vaihtaa, mutta se oli ylipäätään mahdollista siksi, että jokainen tietokantaan tallennettava merkki tarkistettiin. Ohjelmiston asiakasliittymä käännettiin suomeksi ja ruotsiksi siltä osin kuin se oli mahdollista. Tehtiin myös sellaista kotoistusta, jonka hyödyllisyys voidaan näin jälkikäteen asettaa myös kyseenalaiseksi, kuten ohjelmiston sovittaminen FINMARC-formaatille sopivaksi. Mutta 80-luvun lopulla useimmat maat käyttivät kansallisia MARC-versioita; USMARCin, CANMARCin ja UKMARCin yhdistymisen kautta luotu MARC 21 syntyi vasta 1999.

Linnea-hankkeessa käyttöön otettu, 327 merkkiä sisältävä ISO 6937/2 -merkkivalikoima[8] salli skandinaavisten merkkien syöttämisen, mutta ei kyrilliikan tallennusta. Sitä varten rakennettiin myöhemmin erillisratkaisu, mutta Unicode-luettelointi toteutui vasta paljon myöhemmin, Voyager-sovelluksen myötä. Moni 80-luvulla ongelmia aiheuttanut piirre on nykyisissä ohjelmistoissa jo kunnossa, mutta edelleenkin esimerkiksi päivämäärien, valuuttojen ja osoitteiden tallentaminen suomalaisessa asussa voi tuottaa haasteita. Jos ohjelmoija pystyy ottamaan kansainvälistämisen huomioon ja soveltaa esim. CLDR-tietokantaa, asiat ovat tältä osin kunnossa. Valitettavasti MARC 21 asettaa rajoja sille miten pitkälle kansainvälistämisessä ja kotoistuksessa voidaan mennä.

Kuvailun kansainvälistämisestä

Kirjastot ovat vuosikymmeniä pyrkineet siihen, että jokainen julkaisu luetteloitaisiin vain kerran. Voikin sanoa, että kirjastot ovat avoimen datan edelläkävijöitä, vaikka avoimuus koskikin vain muita kirjastoja. Yhteisten RDA-sääntöjen, muut MARC-formaatit peitonneen MARC 21:n sekä teknisten edistysaskeleiden (entistä merkittävästi laajemmat fyysiset yhteisluettelot ja nopeat verkkoyhteydet) ansiosta olemme edenneet kohti IFLA:n Universal Bibliographic Control -ihannetta. On mahdollista, että semanttinen Web ja linkitetty data vievät meidät vieläkin lähemmäksi maalia, kuten Mirna Willer ja Gordon Dunsire uskovat[9]. Ja kaupan päällisiksi saamme avoimen datan ansiosta hyvän mahdollisuuden tarjota metatietomme myös ulkopuolisten käyttöön.

Mutta jos lähtödata ei ole riittävän kansainvälistettyä, siitä ei synny kaikin osin käyttökelpoista avointa dataa. Luettelointisäännöt ja MARC-formaatti kehitettiin vuosikymmeniä ennen semanttista Webiä ja siinä sovellettavia ratkaisuja, joten olisi melkoinen onnenpotku, jos Webin ja kirjastojen käytänteet olisivat kaikilta osin yhteneviä.

Kansainvälistämisen laajasta kentästä otamme tässä tarkasteltavaksi kaksi osa-aluetta, julkaisuun liittyvien kielten ja aikamääreiden koodimuotoisen kuvaamisen. Kielten yhteydessä keskustellaan myös kirjaimistojen kuvaamisesta.

MARC21 ja kielet

MARC 21:ssä on useita kielen ilmaisemiseen liittyviä tietoelementtejä. Sivuutamme tässä luettelointikielen (040 $b), jo aiemmin käsitellyn huomautuksen kielestä (546) ja kielen sisällönkuvailun teemana.

Julkaisun pääasiallinen kieli tallennetaan 008-kentän koodipaikkoihin 35-37. Koodi valitaan Kansalliskirjaston ylläpitämältä listalta[10], joka perustuu Kongressin kirjaston kielikoodilistaan[11]. Se taas on käytännössä sama kuin ISO 639-2 -standardi. Kielten nimien käännöksistä, joita sovelletaan silloin kun koodi muunnetaan asiakkaalle ymmärrettävään muotoon, vastaa Kotoistus-hanke.

008-kentässä annettu koodi ei riitä kielen ilmaisemiseen esim. silloin, jos teos on monikielinen, käännös tai siinä on jollakin muulla kielellä laadittu tiivistelmä. Tällöin voidaan käyttää kenttää 041, jossa voidaan ilmaista esimerkiksi monikielisen julkaisun kaikki kielet tai käännetyn teoksen alkuperäinen kieli. Lisäksi kenttään 377 (Kielimerkintö) voidaan tallentaa tietueessa kuvailtuun entiteettiin kuten henkilöön tai yhteisöön liittyvien kielten koodeja, kuten henkilön kirjoissaan käyttämä kieli tai kielet.

Toisin kuin 008, kentät 041 ja 377 eivät ole sidoksissa ISO 639-2 -standardiin. Kongressin kirjaston ohjeistuksen[12] mukaan näissä kentissä koodien valinnassa on mahdollista käyttää ISO 639-2:sta huomattavasti kattavampaa ISO 639-3 –standardia, joitakin kansallisia standardeja tai IETF:n (Internet Engineering Task Force) RFC-suosituksia (RFC 5646, RFC 4646 tai RFC 3066).

ISO 639-2 ja ISO 639-3 -standardien rinnakkaiskäyttö on periaatteessa ongelmatonta, koska koodilistoja ylläpitävän ISO 639/Joint Advisory Committeen kotisivun[13] mukaan:

The three-letter codes in ISO 639-2 and ISO 639-3 are complementary and compatible. The two codes have been devised for different purposes. The set of individual languages listed in ISO 639-2 is a subset of those listed in ISO 639-3. The codes differ in that ISO 639-2 includes code elements representing some individual languages and also collections of languages, while ISO 639-3 includes code elements for all known individual languages but not for collections of languages. Overall, the set of individual languages listed in ISO 639-3 is much larger than the set of individual languages listed in ISO 639-2.

Suomessa 041-kentässä on toistaiseksi sovellettu etupäässä ISO 639-2:sta ja vain tarvittaessa – jos kielellä ei ole ISO 639-2 koodia – ISO 639-3:sta.

MARC-formaatissa kielen kuvailun erikoispiirre on, että vaikka julkaisun kirjaimisto ei ole latinalainen, ”normaalien” MARC-kenttien tiedot tallennetaan aina romanisoituina. Alkuperäisessä kirjaimistossa metatiedot voidaan tallentaa 880-kenttään (Tiedot vaihtoehtoisella kirjaimistolla). Kansainvälistämisen näkökulmasta on erikoista, että julkaisun alkuperäisestä kirjaimistosta tehdään ”vaihtoehtoinen”. Kansainvälistämisen kannalta järkevin ratkaisu olisi käyttää ”normaaleissa” MARC-kentissä aina alkuperäistä kirjaimistoa. Silloin esimerkiksi Kiinassa luetteloitu kiinankielinen julkaisu olisi hyödynnettävissä Suomessa transkriboimalla alkuperäiset bibliografiset tiedot 880-kenttiin.

880-kentän nykyisestä tallennuskäytännöstä lisää tuonnempana.

ISO 639

ISO 639 –standardissa on viisi osaa. Osa 1 määrittelee kahden merkin mittaiset kielikoodit ja osa 2[14] yleisesti käytettyjen kielten ja kieliperheiden koodit. Osa 3[15] pyrkii kattamaan kaikki elävät ja kuolleet kielet, ja osassa 5 on kieliperheiden koodit, jotka sisältyvät myös osaan 2. Osa 4 määrittelee käsitteet ja koodien jakelun perusteet. Kielitieteilijöiden kritiikki kohdistuu voimakkaimmin osiin 3 ja 5; edellisen ylläpitoon ei olla täysin tyytyväisiä, kun taas jälkimmäisen ongelmana on etupäässä kieliperheen määrittelyn vaikeus.

ISO 639:een valittaville kielille ja kieliryhmille on määritelty selkeät kriteerit. Esimerkiksi ISO 639-2:n kriteerien[16] mukaan kielellä tulisi olla esimerkiksi virallinen asema ja kansallinen tai alueellinen tuki. Koska melkein kaikki tällaiset kielet ovat jo saaneet koodin, uusia koodeja lisätään varsin harvoin. Suurin osa muutoksista[17] on kohdistunut kielten nimiin.

Luetteloinnissa ISO 639:n soveltaminen on periaatteessa suoraviivaista. Jos kuvailtava teos on kirjoitettu kielellä jolla ei ole omaa koodia ISO 639-2:ssa, 008-kentässä käytetään soveltuvaa kieliperheen koodia. Sellaisia ovat esimerkiksi smi (saamelaiskielet) ja gem (germaaniset kielet). Koska 639-2:ssa on noin 500 koodia, suomalaisiin kirjastoihin hankitaan melko harvoin julkaisuja, joita se ei kata. Kun näin käy, 041-kenttään voidaan tallentaa teoksen kielen koodi, jos se löytyy ISO 639-3:sta tai muista standardeista, joiden käyttö on kyseisessä kentässä luvallista. Koska ISO 639-3:ssa on lähes 8000 koodia, se kattaa kielet erittäin hyvin, mutta ei lainkaan esimerkiksi murteita tai kielten kansallisia variantteja. Jos luettelointisäännöt edellyttäisivät niiden tallentamista 041-kenttään, se olisi mahdollista BCP 47:lla, josta enemmän alla. Käytännössä murteita koskeva tieto tallennetaan yleensä huomautuksena tai sisällönkuvailuun.

ISO 639:n eri osille on nimetty vastuuorganisaatiot (Registration authority). Osia 2 ja 5 ylläpitää Kongressin kirjasto ja vuonna 2007 julkaistua osaa 3 SIL International[18], mutta portinvartija osaan 2 lisättäville uusille koodeille on ISO 639/Joint Advisory Committee[19]. Siinä on mukana edustajia ISO TC 46/SC 4:stä sekä ISO TC 37/SC 2:sta, jotka ovat yhteisvastuussa standardista. ISO TC 46/SC 4:n puheenjohtajana olen yksi kirjastosektorin edustajista komiteassa.

Osat 1 ja 2 ovat kattaneet lähes samat kielet muutamin poikkeuksin, mutta koska osaa 1 ei enää ylläpidetä, standardien välinen ero kasvaa vähittäin. Osan 2 jäädyttämisellä halutaan ohjata käyttäjiä kolmen merkin mittaisiin kielikoodeihin, jotka eivät voi edes periaatteessa sekoittua ISO 3166 -standardin mukaisiin, kahden merkin mittaisiin maiden tunnuksiin, jotka tallennetaan yleensä isoin kirjaimin sekaannusten välttämiseksi. Niinpä ISO 639-1:ssä on vielä koodit 2000-luvulla lisätyille bosnian ja kroatian kielille, mutta ei enää vuonna 2012 639-2:een lisätylle tamazight-berberikielelle eikä loppuvuodesta 2017 hyväksytylle montenegrolle.

Periaatteessa kielikoodeja myönnetään pelkästään kielitieteellisin perustein. Toki nekään eivät ole täysin yksiselitteiset, mutta monimutkaiseksi standardin ylläpito tulee vasta sitten kun politiikka sotkeutuu kuvioihin. Selkein tuote esimerkki on, että Jugoslavian hajoamiseen asti sen alueella puhuttiin vain sloveniaa ja serbokroatiaa, mutta ISO 639-2:n mukaan Jugoslavian tuhkasta nousseiden valtioiden kielet ovat slovenia, serbia, kroatia, bosnia ja montenegro, joista viimeisin lisättiin standardiin muun muassa sillä perusteella, että se on Montenegron virallinen kieli. Montenegroa kuten myös bosniaa ja kroatiaa voidaan pitää paitsi itsenäisinä kielinä, myös serbian murteina, mutta aikaa myöten Balkanilla käytettävät kielet voivat erota toisistaan yhtä selkeästi kuin skandinaaviset kielet, joiden itsenäisyyttä ei kukaan epäile.

BCP 47

Internetin ja semanttisen Webin suositus dokumentin kielen ilmaisemiseen on IETF:n Best Current Practice 47 eli BCP 47[20]. Sen nykyinen versio koostuu kahdesta Internet-standardista: RFC 5646 määrittelee koodit ja RFC 4647 kuvaa koodien vertailua ja tulkintaa. Jos nämä RFC-julkaisut päivitetään, myös BCP 47:ää päivitetään siten, että se viittaa uudempiin standardeihin. Koska 041 ja 377 sallivat RFC 5646:n soveltamisen, ne mahdollistavat Internetin vaatimusten mukaisen kielikoodin tallentamisen niin kauan kunnes RFC 5646 korvataan.

Best Current Practice 47 on ISO 639:ää monipuolisempi standardi, sillä sen avulla voidaan kielen ohella kuvata myös kirjaimisto ja alue, jolla kieltä käytetään. Lisäksi koodeihin voidaan tehdä paikallisia tai omia laajennuksia tarpeen mukaan. Ensimmäinen johtopäätös tästä on, että kuvailijoille tulisi antaa ohjeistus RFC 5646:n / BCP 47:n käyttämisestä.

BCP 47 edellyttää kielen ilmaisemista ISO 639-1 -standardin mukaisena kahden kirjaimen koodina jos se on mahdollista. Useimmat ISO 639-2 -koodit ovat helposti muunnettavissa BCP 47 –muotoon. Esimerkiksi kielikoodi fin korvataan koodilla fi. Jos kielellä ei ole ISO 639-1 –koodia, voidaan koodi ottaa ISO 639 –standardin muista osista. Karjalan BCP 47 –koodi on siis krl, eikä esim. fi-RU, joka olisi varsin harhaanjohtava. Mutta kun montenegron koodista keskusteltiin ISO 639/JAC:ssa, ryhmän Unicode-jäsen sanoi ettei uutta koodia tarvita, koska kielellä on jo koodi. Se on sr-ME, eli kieli on Montenegrossa puhuttua serbiaa, mitä se joidenkin kielitieteilijöiden mukaan onkin. Mutta Montenegron virallinen kieli ei parlamentin päätöksellä ole serbia vaan montenegro[21].

Kirjaimistojen määrittely perustuu BCP 47:ssa ja yleisemminkin ISO 15924 -standardiin[22], jonka Registration authority eli kansainvälinen vastuutaho on Unicode-konsortio. Konsortio ylläpitää kirjaimistoluetteloa[23], joka sisältää mm. kirjaimiston nimen englanniksi ja ranskaksi, niiden neljän kirjaimen mittaiset koodit (esim. Latn normaalille suomalaiselle kirjaimistolle ja Latf sen fraktuuraversiolle),  sekä mm. päivämäärän, jolloin kirjaimisto on lisätty koodilistaan.

Alue, jolla kieltä puhutaan, voidaan kuvata paitsi ISO 3166 -standardin mukaisena maa- tai aluekoodina[24], myös alueen nimenä tai YK:n ylläpitämän UN M.49 tilastokoodin avulla.

Luetteloinnin apuvälineenä BCP 47 on haasteellinen monipuolisuutensa vuoksi. Jos kuvailtavana on esimerkiksi suomenkielinen fraktuurateksti, kielikoodiksi voidaan antaa pelkkä fi, fi-Latf jos halutaan kertoa myös kirjaimisto ja fi-FI-Latf jos myös alue kuvataan. Vastaavasti meänkielisen tekstin koodiksi tulisi fi-SE tai vaihtoehtoisesti joko fi-SE-BD tai fi-SE-25, jos halutaan korostaa sitä, että kyseessä on Norrbottenissa puhuttu kieli.

Italiankielinen käsikirjoitus, josta osa on kirjoitettu heprealaisella kirjaimistolla, saisi ISO 639-2:lla koodin ita, mutta BCP 47:n nojalla koodiksi voitaisiin antaa it-Hebr. Vastaavasti skottimurteella laadittu teksti joka on kirjoitettu foneettisin aakkosin, saisi koodin en-scotland-fonipa.

880-kentässä käytetty kirjaimisto määritellään kentän 066 (Merkistöt) osakentässä $c. 066 on luetteloijan kannalta hieman haasteellinen kenttä, koska suomennos on varsin pelkistetty. Alkuperäinen formaatti taas on harhaanjohtava, koska se kertoo tallennettavasta tiedosta seuraavaa:

Information that indicates that the records were encoded with characters from sets other than ISO 10646 (or Unicode).

Unicoden 90-luvun alussa julkaistut varhaiset versiot eivät välttämättä sisältäneet kaikkia kuvailussa tarvittavia merkkejä ja kirjaimistoja. Mutta nykyään kaikki kuvailussa tarvittava informaatio voidaan tallentaa Unicode-merkkivalikoimalla tai sitä vastaavalla ISO-standardilla ISO 10646. 066-kentässä ei kuitenkaan ole kyse Unicoden soveltamisesta vaan siitä, että 880:ssa käytetään jotakin muuta kuin latinalaista kirjaimistoa.

Kirjaimiston koodi toistetaan 880 $6:ssa, jotta kentässä oleva informaatio pystytään esittämään oikein. MARC-formaatilla on valitettavasti omintakeinen, ISO 15924 –standardia edeltävä ja siitä täysin poikkeava tapa esittää kirjaimisto. Esimerkiksi Kiinan kansantasavallassa käytetty yksinkertaistettu kiinan kirjaimisto esitetään koodilla $1.

066 ## ‡c $1

880 00 ǂ6245-01/$1 ǂa 新诗三百首百年新编 / ǂc 张默, 萧萧主编.

Samaa $1-koodia käytetään myös Taiwanissa käytetylle perinteisemmälle kirjaimistolle ja Japanin kanji-merkeille. ISO 15924:n mukaan yksinkertaistetun kiinan kirjaimiston koodi on kuitenkin Hans, ja sen varianteilla on omat koodinsa; esimerkiksi perinteiselle kiinan kirjaimistolle Hant ja kanji-merkeille Hani.

Omien koodien käyttö on jo sinänsä ongelma, mutta vakavampaa on että ISO-standardiin verrattuna 880-kentässä määriteltyjen / sallittujen kirjaimistojen[25] määrä on todella pieni. On olemassa jo satoja Unicodeen lisättyjä kirjaimistoja, joita MARC 21 ei tue.

OCLC on WorldCat-tietokannassa ratkaissut tämän ongelman sallimalla ISO 15924 –koodien käytön niille kirjaimistoille, joilla ei ole omaa MARC 21 -koodia:

066 ## ‡c Deva

880 #1 ‡6 264-04/Deva ǂa दिल्ली : ǂb अक्षर पब्लिशर्स एण्ड डिस्ट्रीब्यूटर्स, ǂc 2017

ISO 15924 -tuki pitäisi pikimmiten saada myös virallisesti MARC 21:een, ja mieluiten siten, että formaattikohtaisista kirjaimistokoodeista ja 880-kentän erityiskooodauksista luovutaan.

MARC 21 ja aika

Aika voi olla kuvailun kohteena esimerkiksi julkaisuaikana, tekijän syntymä- ja kuolinaikana tai julkaisun aiheena. Myös lisensointiin voi liittyä erilaisia aikamääreitä. MARC 21 -formaatissa onkin runsaasti aikaan liittyviä tietoelementtejä, ja niihin tallennettava informaatio voi olla monimuotoista. Aikamääreet voivat olla epävarmoja tai tuntemattomia, ajanjaksot epämääräisiä.

Kirjastojen vaatimusten haasteellisuutta kuvaa hyvin se, että ISO:n päivämäärästandardi ISO 8601 ei riittänyt kuvailun tarpeisiin. Mutta toisaalta standardia ei aina ole käytetty silloinkaan, kun se olisi mahdollista. Ajanjaksojen tallentaminen on tästä hyvä esimerkki.

Jo edellä on mainittu kenttä 045, joka monografiajulkaisuissa kuvaa kirjan sisällön ajallista katetta. Sen a-osakenttään voidaan tallentaa aikakauden koodi, jolla ei ole vastinetta ISO-standardissa. Sama asia voidaan ilmaista b-osakentässä siten, että kauden alku ja loppu ilmoitetaan eri osakentissä. 1500-luvun tallennusvaihtoehdot ovat 045 ##$at-t ja 045 2#$bd1500$bd1599.

Molemmat tallennustavat ovat vaikeasti ymmärrettävissä MARC-formaatin saloihin perehtymättömälle sovellukselle, ja muunnettaessa MARC-tietueita avoimeksi dataksi ne olisi suotavaa muuttaa ISO 8601 –muotoon, joka on 1500/1599 tai – jos sovelletaan standardin osaa 2 – vain 15.

ISO-standardissa kauttaviiva erottaa toisistaan ajanjakson alun ja lopun. Tämä on pieni haaste kaikille MARC-kentille joissa ajanjaksoja käytetään, koska niissä erotinmerkki on tavuviiva. Koska ISO-standardissa tavuviiva erottaa toisistaan päivän, kuukauden ja vuoden, sitä haluttiin välttää ajanjaksoja esitettäessä. Onhan 2018-01-01-2018-12-31 vaikeammin (kone)luettavissa kuin 2018-01-01/2018-12-31. Uusi standardi mahdollistaa myös sen osoittamisen, onko ajanjakson alku tai loppu avoin tai tuntematon. Koodaustavat ovat YYYY/.. ja YYYY/ , ei siis esimerkiksi YYYY-.

ISO 8601:n nykyinen versio julkaistiin 2004. Kirjastojen kannalta siinä oli paljon puutteita, ja niinpä Kongressin kirjasto laati Extended Date/Time Profilen eli EDTF-profiilin[26], jolla puutteita paikattiin. Mutta kuten sivun tammikuussa 2018 päivitetty versio kertoo:

This draft specification is superceded; EDTF functionality has been integrated into a draft revision of ISO 8601 to be published in 2018.

The revision of ISO 8601 consists of two parts. Part 2 is Extensions, one of which is EDTF. (The full functionality of this draft specification is retained, however several syntactic changes were necessary, to satisfy international requirements.)

Tästä ei voi päätellä, soveltaako MARC 21 jatkossa edelleen amerikkalaisvaikutteista EDTF:ää kaikkine syntaktisine erikoisuuksineen, vai onko tarkoitus siirtyä ISO 8601-2:n mukaiseen tallennuskäytäntöön. Avoimuuden nimissä jälkimmäinen ratkaisu olisi toivottava, ainakin siltä osin kuin se on järkevällä vaivalla toteutettavissa. Uusi ISO 8601-2 mahdollistaa esimerkiksi vuosilukujen tallentamisen standardimuodossa silloinkin, kun vuosiluvussa on enemmän kuin neljä numeroa, kun nykyisin tieto on tallennettava sekä vapaatekstinä 260- ja 264-kenttiin sekä MARC 21:n formaattikohtaisena koodina 045-kenttään.

Vuosi 10000 eaa voidaan jatkossa tallentaa kahdella eri tavalla. ISO 8601-1 sallii sen, että aikamääre ilmaistaan niin monella merkillä kuin tarvitaan, minkä lisäksi sen eteen tallennetaan +- tai – osoittamaan aikakautta. Vuosi 10000 eaa olisi tällöin esimerkiksi -010000. ISO 8601-2 määrittelee toisenkin tavan, jossa vuosiluvun eteen tallennetaan Y- tai Y+. Vuosi 10000 eaa olisi tällöin Y-10000 ja vuosi 10000 kaukaisessa tulevaisuudessa vastaavasti Y+10000. Kiinteämittaisissa kentissä tätä tallennustapaa ei voi soveltaa, mutta tuskinpa siihen on tarvettakaan esimerkiksi julkaisuajan osalta.

Jos luetteloinnissa saadaan lupa ISO 8601 –tallennukseen, joudutaan ojasta allikkoon BCP 47:n viitoittamalla tiellä. ISO 8601:n seuraava versio, joka siis todennäköisesti ilmestyy tänä vuonna, on hyvin rikas standardi. Se toiminnallisuus joka standardissa on nyt, on periaatteessa kaikki uuden standardin osassa 1. Osa 2 sisältää kirjastojen kaipaamien piirteiden lisäksi paljon muuta, jonka soveltamisesta voi olla tarpeen sopia erikseen. Esimerkiksi aikamääre voi olla joko epävarma, arvio tai molempia. Koodaustavat ovat 2018?, 2018~ ja 2018%. Ja jos tiedetään esimerkiksi vuosikymmen, mutta vuosi on tuntematon, vuosiluku voidaan esittää muodossa YYYX eli esim. 201X. Ennen kuin näitä ominaisuuksia aletaan soveltaa vaikkapa henkilöiden syntymä- ja kuolinaikojen kuvaamiseen, olisi hyvä selvittää osaavatko kirjastojen käyttämät järjestelmät käsitellä niitä oikein.

Näiden uusien ominaisuuksien vuoksi kuvailusäännöissä ja formaatissa ei pitäisi vain viitata standardiin. Kuvailun helpottamiseksi on tarpeen määritellä, mitä ominaisuuksia voi käyttää. ISO 8601-2 on jaettu kahteen tasoon, ja Level 2 on ainakin allekirjoittaneen mielestä jo liiankin monimutkainen kirjastojen kuvailutarpeita ajatellen.

Aikamääreiden tallentamisen osalta kirjastot ovat avoimen datan yleisiä linjauksia huomattavasti edellä. Web-ohjeistuksessa näkee usein viitattauksia W3C:n Date and time formats -ohjeeseen[27]. Se on kirjoitettu 1997, ja ohjeistaa tallentamaan vuosiluvun muodossa YYYY. Syy ohjeen laatimiselle oli vanha ISO 8601 –versio, joka salli vuosiluvun tallentamisen myös kahdella merkillä, eli vuosi 1984 voitiin antaa myös muodossa 84. Nykyinen ISO 8601 sallii vain YYYY-tallennusmuodon, minkä vuoksi W3C-ohje on käytännössä tarpeeton. Mutta olisi hyödyksi laatia päivitetty ohje, joka kertoisi mitä uuden ISO 8601 –standardin piirteitä tulisi tukea kaikissa verkkosovelluksissa.

Lopuksi

The devil is in the detail, sanotaan. Ja siltä tuntuu, kun vertaa MARC-formaattia ja avoimen datan vaatimuksia. Vaikka MARC on jatkuvasti kehittynyt, muu maailma on joillakin alueilla saanut meidät kiinni ja kirinyt ohi. Mahdollisuus kuvailla aineistoa kaikilla kielillä oli mukana MARC-formaatin kehittämisessä jo ammoisista ajoista, mutta Kongressin kirjaston rahkeet eivät tuolloin riittäneet universaalin merkkivalikoiman kehittämiseen. Nyt kun Unicode on olemassa ja sitä sovelletaan laajasti muualla, MARC-formaatti mahdollistaa sen käytön kirjastoissa vain saumat natisten. MARC-formaatin seuraajan pitäisi olla tässä suhteessa parempi, vaikka se vaikeuttaisi tietojen konvertointia takaisin MARC-muotoon.

Aika- ja päivämäärätietojen tallennuksen osalta olemme vähän samassa tilanteessa. Muun muassa aineistojen tekijänoikeudellisen statuksen kuvaaminen edellyttää koneymmärrettävää ja –luettavaa aikatietoa (ja lisenssitietoa), mutta kuvailutiedoissa on vielä puutteita, joista ainakin osa on toivon mukaan korjattavissa ohjelmallisesti. Uudet kuvailut pitäisi kuitenkin tehdä niin, ettemme luo enää lisää tulkintaongelmia metatietojemme käyttäjille, olivatpa ne ihmisiä tai sovelluksia.

Lähdeviitteet

[1] https://en.wikipedia.org/wiki/Henriette_Avram

[2] http://dx.doi.org/10.5860/lrts.44n3.135

[3] http://schema.org/docs/schemas.html

[4] https://www.loc.gov/marc/mac/list-p.html

[5] http://opendefinition.org/od/2.0/en/

[6] http://cldr.unicode.org/

[7] https://kotoistus.fi/

[8] https://en.wikipedia.org/wiki/ISO/IEC_6937

[9] http://library.ifla.org/817/1/086-dunsire-en.pdf

[10] https://www.kansalliskirjasto.fi/extra/marc21/kielet.htm

[11] http://www.loc.gov/marc/languages/

[12] https://www.loc.gov/standards/sourcelist/language.html

[13] http://www.loc.gov/standards/iso639-2/iso639jac.html

[14] https://www.loc.gov/standards/iso639-2/iso639-2ra.html

[15] http://www-01.sil.org/iso639-3/

[16] http://www.loc.gov/standards/iso639-2/criteria2.html

[17] http://www.loc.gov/standards/iso639-2/php/code_changes.php

[18] https://www.sil.org/

[19] https://www.loc.gov/standards/iso639-2/iso639jac.html

[20] https://tools.ietf.org/html/bcp47

[21] https://en.wikipedia.org/wiki/Montenegrin_language

[22] http://www.unicode.org/iso15924/

[23] http://www.unicode.org/iso15924/codelists.html

[24] https://en.wikipedia.org/wiki/ISO_3166-2:FI

[25] https://www.loc.gov/marc/specifications/speccharmarc8.html

[26] http://www.loc.gov/standards/datetime/pre-submission.html

[27] https://www.w3.org/TR/NOTE-datetime

Kirjoittajan yhteystiedot

Juha Hakala, erityisasiantuntija
Kansalliskirjasto, kirjastoverkkopalvelut
PL 26 (Kaikukatu 4) 00014 HELSINGIN YLIOPISTO
sähköposti: juha.hakala [at] helsinki.fi

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Theme by Anders Norén