http://sange.fi/~atehwa/cgi-bin/piki.cgi/ Recent changes in metatiedot, osa 1,5: rekisteriaineistojen metatietostandardeja http://sange.fi/~atehwa/cgi-bin/piki.cgi/metatiedot%2C%20osa%201%2C5%3A%20rekisteriaineistojen%20metatietostandardeja http://sange.fi/~atehwa/cgi-bin/piki.cgi/#1415712206 <p><ins>Ihmiset ja sitä myötä projektit palailevat pikku hiljaa kesälomilta, ja sitä myötä blogiakin voisi päivittää. En kuitenkaan kirjoita tällä kertaa kovin yleisellä tasolla, vaan kerron niistä käytännön metatietoasioista, joista on puhuttu ennen ja jälkeen kesälomien. Erityisesti tarkastelen matriisimuotoisten aineistojen kuvailun standardeja.</ins> <p><ins>* ([Tiedot käyttöön -blogi])</ins> <p><ins>-- kirjoitettu: perjantai 06. elokuuta 2010, 09.51 -- viimeisin muutos: maanantai 16. elokuuta 2010, 09.07</ins> <p><ins>Kuten aiemmin kirjoitin, [MIDRAS-pilottijärjestelmä]ssä tarvittaisiin jonkinlainen katalogi olemassaolevien aineistojen kuvailemiseksi.  Koska aineistojen on tarkoitus tulla useammalta rekisteriorganisaatiolta, pitää sopia osapuolten kesken vähintään, mitä metatietoja aineistoista annetaan katalogia varten, ja mielellään myös, missä muodossa nämä tiedot annetaan.  Yhdessä rekisteriorganisaatioiden kanssa on jo sovittu siitä, mihin tarkoitukseen (ainakin) metatietoja kerätään eli mitä tavoitteita metatietojen keruulla on tarkoitus saavuttaa:</ins> <p><ins># aineistojen julkaisu ja mainostaminen # aineistojen luokittelu ja etsintä # käyttölupahakemusten laadun parantaminen # aineistojen käsittelyn (tutkimuksen) tuki # alkuperäisten aineistojen tietosuojan säilyttäminen</ins> <p><ins>3. ja 5. kohta saattavat kaivata avaamista.  Koska henkilörekisteriaineistojen tietosuojavaatimukset ovat suuret, tutkijat eivät tietenkään voi selailla näitä aineistoja noin vain.  Tarvitaan tietojen käyttölupa, joka perustuu tutkimussuunnitelmaan.  Mutta miten hakea käyttölupaa, jos ei tiedä, mitä aineistoja on tarjolla?  Korkealaatuisilla aineistojen metatiedoilla voidaan suuresti helpottaa tutkimussuunnitelman laatimista ja kaikkien, sekä rekisteriorganisaatioiden että tutkijoiden, kommunikaatio- ja sopimistyö helpottuu.</ins> <p><ins>Joka tapauksessa, kevään ja kesän mittaan on hiottu MIDRAS-järjestelmän metatiedon vaatimusmäärittelyä, eli määritystä siitä, mitä metatietoja pitäisi mistäkin aineistosta antaa ja kuinka keskeinen mikin on.  Vaatimusmäärittely alkaakin olla jo aika hyvässä jamassa.  Tämän työn esittely on kuitenkin niin laaja aihe, että se vaatisi oman artikkelinsa.</ins> <p><ins>Sen sijaan haluan kertoa tarkemmin siitä, millaisia haasteita olemme kohdanneet, kun olemme yrittäneet löytää hyvän metatietojenesitysmuodon.  Tämä on malliesimerkki asiasta, jossa ei kannata keksiä pyörää uudelleen: mitä laajemmin jotain tiettyä metatiedon esitysmuotoa käytetään, sitä todennäköisempää on, että kahden aineiston eri tarkoituksia varten kirjoitetut metatietokuvaukset ovat edes jossain määrin yhteismitallisia, ja sitä enemmän laajasti käytetyn metatietomuodon työkaluja kehitetään ja on saatavilla.  Esimerkiksi, jos pohjoismaiden tilastokeskukset joskus päättävät yhdistää tuottamiensa aineistojen tiedot suureksi aineistokatalogiksi, työ onhuomattavasti helpompaa jos metatiedot on alun alkaen esitetty samassa muodossa tai ne sisältävät edes suunnilleen samaan tapaan jaotellut tiedot, jolloin automaattinen muuntaminen muodosta toiseen on mahdollista.</ins> <p><ins>Jos ei välitä ollenkaan aineiston sisäisestä rakenteesta vaan kiinnittää huomiota vain sen yleisiin ominaisuuksiin (kuten kirjoittajaan, julkaisupäivään ja kuvaukseen), tarjolla on monia standardeja siitä, kuinka metatiedot esitetään; kansainvälisesti prominentein on ilman muuta (http://dublincore.org) Dublin core ja Suomessa on olemassa myös sille pohjautuva asiakirjojen kuvailusuositus (http://www.jhs-suositukset.fi/suomi/jhs143) JHS143.  Rekisteriaineistoilla on kuitenkin metatiedoille asettamiemme tavoitteiden kannalta tärkeä rakenne, jota näillä standardeilla ei pysty kuvailemaan.  Tyypillinen rekisteriaineisto on matriisimuotoista (eli relationaalista / taulukkomaista yksilödataa), jossa yksi rivi vastaa jotain havaintoyksikköä kuten henkilöä, kiinteistöä tai lääkeostotapahtumaa, ja jokaisella rivillä on samat tiedot, kuten nimi, osoite ja sormien määrä.  Näitä eri tietoja kutsutaan aineistonmuuttujiksi.  Erityisesti näiden muuttujien tiedot, kuten selitys, kattavuus aineistossa, esitystapa ja niin edelleen, ovat keskeisiä tavoitteidemme kannalta.</ins> <p><ins>Yllättävää kyllä, vaikka matriisimuotoinen tieto on erittäin yleistä ja sille on vakiintuneita esitys- ja talletusmuotoja kuten CSV ja HTML-taulukot, emme ole onnistuneet löytämään mitään laajassa käytössä olevaa tapaa esittää matriisimuotoisten aineistojenmetatietoja.  Niinpä matriisimuotoisten aineistojen kuvailustandardeihin tutustuminen on ollut hämmentävä seikkailu, jossa vähintään puolet tuntuu olevan politiikkaa: erilaisten metatietostandardien esittelijät tuovat esiin omien ratkaisujensa hyviä puolia, joskus moittivat toisiaan, ja tilasto- ja rekisteriviranomaiset eri puolilla maailmaa suunnittelevat ja tekevät periaatepäätöksiä siitä, mihin suuntaan ollaan menossa.  Tässä viidakossa pienen teknisen asiantuntijan pää menee pyörälle, mutta on myös korvaamattoman arvokasta oikeasti katsoa, millaisia eri standardit ovat, ja esittää oma, ehkä valistumaton arvionsa siitä, millaisia hyviä ja huonoja puolia niillä on.  Matriisimuotoisen aineiston metatietostandardit näyttävät myös olevan sen verran esoteerinen aihe, että juuri kukaan ei uskalla julistautua asiassa varsinaiseksi asiantuntijaksi.  Tarkastelen tässä niitä vaihtoehtoja, joista olen tietoinen: näitä ovat yhteiskuntatieteilijöiden (http://www.ddialliance.org/specification/ddi2.1) DDI2.1 ja (http://www.ddialliance.org/specification/ddi3.1) DDI3, Eurostatin (http://sdmx.org/?page_id=10) SDMX ja Suomen tilastokeskuksen (http://www.stat.fi/org/tut/dthemes/drafts/cossi_en.html) CoSSI.  Näillä kaikilla on XML-pohjaiset talletus- tai lähetysmuodot.</ins> <p><ins>DDI2.1 on näistä vakiintunein ja ollut pisimpään käytössä.  Dokumentaatio jättää toivomisen varaa ja varsinkin käyttöesimerkkejä on vaikea löytää, mutta Suomessa yhteiskuntatieteellinen tietoarkisto (http://www.fsd.uta.fi/) FSD käyttää DDI2.1:a aineistojensa kuvailuun.  Jostain syystä DDI-muotoiset kuvailut eivät ole julkisesti saatavilla muutamaa esimerkkiä lukuun ottamatta, vaan FSD käyttää niitä sisäisiin tarkoituksiin ja tuottaa niiden perusteella aineistojen hakupalvelun sekä ihmisten luettavaksi tarkoitetun aineistokuvailun, "koodikirjan".  DDI2.1 on kohtuullisen yksinkertainen ja rakenteeltaan melko intuitiivinen tiedostomuoto; se on suunniteltu kuvaamaan erityisesti kyselylomakkeilla kerättyä dataa ja siksi siinä on joitain rekisteritietojen kannalta hankalia piirteitä, kuten turhaa infrastruktuuria alkuperäisten kyselylomakkeiden kuvaamiseen ja puuttuvia elementtejä, joita tarvittaisiin aineiston tietosuojan, keruutavan muutosten yms. kuvaamiseen.  DDI2.1:stä voisi laajentamalla saada vaatimusmäärittelyn mukaisen metatietostandardin.  Yksi DDI2.1:n ongelma on se, että jäyhän rakenteensa vuoksi siinä on vaikeaa uudelleenkäyttää tietoa: esimerkiksi, jos aineistossa käytetään kahden muuttujan koodaamiseen (esim. pää- ja sivudiagnoosi) samaa koodia (esim. jotain kansainvälistä tautiluokitusta), koodaus pitää määritellä molemmissa muuttujissa erikseen.</ins> <p><ins>DDI3 on standardi, joka on suunniteltu korjaamaan DDI2.1:n puutteet.  Samalla rakenne on pantu täydellisen uusiksi.  DDI3-kuvailuista ei ole esimerkkejä ollenkaan ja sen dokumentaatiosta on todella vaikeaa yrittää päätellä, miten sitä olisi tarkoitus käyttää.  DDI3-kuvailuja on raskasta kirjoittaa käsin ja erittäin hankalaa lukea ilman apuohjelmia, koska ne ovat täynnä viittauksia paikasta toiseen.  Esimerkiksi muuttujan tiedoissa ei lue enää, mitä mikin muuttujan arvo tarkoittaa, vaan sieltä on viittaus koodausmäärittelyyn josta taas on viittaus asioiden kategorisointimäärittelyyn.  Projektimme tekisi mitä ilmeisimmin suuren hyvän työn, jos tuottaisimme DDI3:n käytöstä esimerkkejä ja työkaluja, joilla DDI3:a voi työstää.</ins> <p><ins>SDMX on uusin tulokas, euroopanlaajuiseen tilastotietojen siirtoon ja kuvailuun tarkoitettu, kalliilla kehitetty standardi.  En ole tutustunut siihen vielä kovin perinpohjaisesti, mutta eräs SDMX:n hämmentävä piirre on se, että siinä voi esittää asiat varsin monella tavalla.  Erilaisille tietotyypeille (joita SDMX:ssä kutsutaan "viesteiksi") on monta eri koodausta, joiden peruste näyttää lähinnä olevan yleiskäyttöisyys vs. viestin lyhyys.  Koska ihan hyviä pakkaustapojakin on keksitty, ei olisi tullut minulle ensimmäiseksi mieleen, että tilastotietojen kuvailua suunnittelevien ihmisten tarvitsisi kiinnittää huomiota kuvailujen tilankulutukseen.  Dokumentaatio on kohtalaista, jopa käyttöesimerkkejä löytyy.  Tilastodatan kuvailu on jonkin verran erilaista kuin yksilödatan kuvailu, mikä vaikeuttaa SDMX:n soveltamista rekisteriaineistoihin.</ins> <p><ins>CoSSI on hengeltään jonkin verran samanlainen mutta tietomalliltaan erilainen kuin DDI2.1.  Tilastokeskus käyttää sitä aineistojensa kuvailussa, mutta kovin kattavia kuvailuja CoSSIlla ei ilmeisesti ole vielä tehty.  CoSSI on kuitenkin käyttökelpoinen ja kattaa aineistojen perustiedot oikein hyvin.  CoSSIlle on jonkin verran työkaluja ja käyttöesimerkkejä, mutta kaikki näistä eivät ole julkisesti saatavilla.</ins> <p><ins>!!! Tietoarkiston DDI-muotoinen metadata nyt saatavilla</ins> <p><ins>tiistai 07. joulukuuta 2010, 13.11</ins> <p><ins>Tietoarkisto on nyt julkaissut kuvailunsa DDI-XML-tiedostoina: // http://www.fsd.uta.fi/aineistot/taustatietoa/ddi-records.html</ins> <p><ins>Aiemmin näitä ei ole julkaistu siitä yksinkertaisesta syystä, että kysyntää ei ole ollut! Tilanne on nyt kuitenkin muuttunut ja kiinnostus metadataa kohtaan lisääntynyt huomattavasti viimeisen parin vuoden aikana, mistä olen enemmän kuin iloinen. Metadataratkaisuja kannattaa ehdottomasti hakea yhteistyöllä (kansallisella ja kansainvälisellä), monet kysymykset kun ovat samoja alasta tai kuvailtavasta datasta riippumatta. MIDRAS-loppuraporttia odotan suurella mielenkiinnolla.</ins> Tue, 11 Nov 2014 13:23:26 +0000