leeper / data-versionhallinta

(c) Thomas J. Leeper (2015), licensed CC-BY

versionhallinta on valtava osa toistettavaa tutkimusta ja avoimen lähdekoodin ohjelmistokehitystä. Versiointi tarjoaa täydellisen historian jostain digitaalisesta objektista (esim.ohjelmisto, tutkimusprojekti jne.) ja, mikä tärkeintä, mahdollistaa jäljittää, mitä muutoksia on tehty kyseiseen objektiin, kun nämä muutokset tehtiin, ja (asianmukaisella metatiedolla) miksi nämä muutokset tehtiin. Tämä asiakirja sisältää joitakin minun nykyinen ajattelu versiohallinta tietojen.

taustayhteys

erityisesti yhteiskuntatieteissä tutkijat ovat riippuvaisia laajoista, julkisista aineistoista(esim.) kvantitatiivisen tutkimuksen lähdeaineistona. Nämä tietokokonaisuudet kehittyvät tyypillisesti (uutta tietoa lisätään ajan myötä, tietoarvoihin tehdään korjauksia jne.) ja uusia julkaisuja julkaistaan ajoittain. Joskus nämä tiedot ovat monimutkaisia yhteistyöpyrkimyksiä (KS.esimerkiksi hallinnon laatu) ja toiset ovat julkisia julkaisuja yhden laitoksen tiedonkeruupyrkimyksistä (esim. ANES). Vaikka yhteistoiminnalliset tietokokonaisuudet luovat selkeämmän käyttötapauksen versionhallinnalle, yhden laitoksen tietokokonaisuuksia saatetaan myös parantaa versionhallinnalla. Tämä on erityisen tärkeää, koska näiden elintärkeiden tietokokonaisuuksien vanhoja julkaisuja ei usein arkistoida (esim.ANES), mikä tarkoittaa, että on periaatteessa mahdotonta palauttaa tietyn ANES-tietokokonaisuuden aikaisempaa versiota uuden julkaisun jälkeen. Tämä viesti on tarkoitettu ohjaamaan ajattelua siitä, miten hallita luomista, kuratointi, tarkistus, ja levittäminen tällaisia tietojoukkoja. Vaikka tässä esitetyt ajatukset saattavat koskea myös sitä, miten ajatellaan Oman datan hallinnasta, ne pätevät todennäköisesti enemmän tiedon luontivaiheessa kuin myöhemmässä datan käytössä sen jälkeen, kun tietokokonaisuus on olennaisesti valmis tai jäädytetty.

Review of Existing Tools and Approaches

the Open Data Institute on mukava viesti, jossa hahmotellaan haasteita standardoidun, ohjelmistosuuntautuneen versionhallintaohjelmiston (eli git: n) käyttämisessä datan versionhallinnassa. Pääasia on, että git, kuten lähes kaikki VCS, on suunniteltu seuraamaan rivien muutoksia tekstitiedostoissa. Tämä tekee paljon järkeä koodi, sekä artikkeleita, tekstiä, jne. Mutta siinä alkaa olla vähemmän järkeä digitaalisille kohteille, joissa viiva ei ole mielekäs yksikkö. Tämä tulee todella selväksi, kun alamme versio jotain pilkulla erotetut arvot (CSV) tiedosto (kuten ODI post kuvataan). Yhden tietokentän muuttaminen johtaa koko linjan muutokseen, vaikka vain yksi solu todella muuttui. Samanlainen ongelma ilmenee XML -, JSON-tai muissa tekstirajatuissa formaateissa (Huomaa kuitenkin, että Open Knowledge Foundation näyttää suosivan jsonia tallennustilana).

linebreakin \n käyttäminen erottimena objektin muutosten seuraamiseen toimii datalle. daff on javascript työkalu, joka yrittää hyvittää, että heikkous. Se tarjoaa vertailun (kahden tiedostoversion vertailu), joka kunnioittaa monien tiedostojen taulukkorakennetta korostamalla solukohtaisia muutoksia. Tämä ei kuitenkaan ole täysversionhallintajärjestelmä, vaan pelkkä vertailutyökalu, joka voi toimia hyödyllisenä lisäosana git: lle.

Open Knowledge Foundationin blogissa julkaistussa kirjoituksessa väitetään, että linjapohjaisissa muutossarjoissa on jonkinlaista logiikkaa, koska tavallinen CSV (tai mikä tahansa taulukkotietokanta) tyypillisesti tallentaa yksittäisen havainnon omalle rivilleen. Rivipohjainen versionhallinta on silloin järkevää kirjata havaintoihin muutoksia (näin rivien/havaintojen privilegioiminen sarakkeiden/muuttujien yli).

dat pyrkii yrittämään olla ”Git for data”, mutta projektin tila on hieman epäselvä, koska GitHubilla ei ole ollut kovin aktiivista kehitystä. Q / A avoimen datan StackExchange osoittaa joitakin lisäresursseja dataan sopiville git-vaihtoehdoille, mutta mitään kattavaa ei ole.

Universal numeerinen sormenjälki (UNF) tarjoaa mahdollisen strategian tietojen versionhallintaan. Juuri sitä varten se suunniteltiin. Se ei ole versionhallintajärjestelmä sinänsä, mutta se tarjoaa hajautuksen, joka voi olla hyödyllinen määritettäessä, milloin tietojoukko on muuttunut. Se on joitakin mukavia ominaisuuksia:

  • File format independent (so better than an MD5)
  • Column order independent (a dataset where columns have been shuffled produces the same UNF hash)
  • käsittelee johdonmukaisesti liukulukuja (pyöristykset ja tarkkuusongelmat ovat ongelmattomia), mutta UNF ei ole täydellinen. Ongelmia ovat esimerkiksi:
  • se on lajitteluherkkä (identtinen tietojoukko, joka on rivilajiteltu, tuottaa eri UNF: n; näin privilegioidaan sarakkeita/muuttujia rivien/havaintojen yli)
  • metatietoja ei käsitellä (esim., muuttujien nimet eivät kuulu hash: iin)
  • se on melko herkkä tietorakenteelle (esim. ”leveät” ja ”pitkät” representaatiot samasta tietojoukosta tuottavat erilaisia UNF: iä)
  • se ei ole versionhallintajärjestelmä eikä anna olennaisilta osin tietoa siitä, mikä muuttui, vain että muutos tapahtui

kaikki nämä työkalut keskittyvät myös itse dataan eikä siihen liittyvään metatietoon (esim. koodikirja, joka kuvaa data). Vaikka jotkut tietomuodot (esim., oma formaatteja kuten Stata n.dta: n ja SPSS: n .sav) koodaa tämän metatiedon suoraan tiedostoon, se ei ole yleinen piirre laajasti tekstirajatuissa tietorakenteissa. Joskus koodikirjoja muokataan tietoarvoista riippumatta ja päinvastoin, mutta se on pikemminkin nähdä suuret julkiset tietokokonaisuudet tarjoavat yksityiskohtaista tietoa muutoksista joko tietoihin tai koodikirjaan, lukuun ottamatta satunnaisia julkaisuja.

toinen suuri haaste tietojen versioinnille on se, että olemassa olevien työkalujen versionhallinta ei ole hyvin suunniteltu käsittelemään lähtökohtia. Kun tietoja luodaan, tallennetaan tai muokataan, ohjelmistosuuntautuneella versionhallintajärjestelmällä ei ole selvää mekanismia sen kirjaamiseksi, miksi tietojoukon arvot ovat mitä ovat tai miksi tiettyihin arvoihin tehdään muutoksia. Toimitusviesti saattaa antaa nämä tiedot, mutta heti kun arvoa muutetaan uudelleen, tiettyyn arvoon tehtyjen muutosten historia katoaa koko tiedoston laajemmasta historiasta.

ei siis ole olemassa täydellisiä työkaluja tietojen versiointiin.

jotkut tiedon versioinnin periaatteet

tietojen versioinnin ensimmäinen periaate on, että tietojen muutoksilla on lähteitä tai selityksiä. Tietojen versiointijärjestelmän on kyettävä yhdistämään tietoarvot, rakenne ja metatiedot (ja näiden ominaisuuksien muutokset) näiden arvojen selityksiin tai arvojen muutoksiin arvotasolla (eikä muuttujien, havaintojen tai tiedostojen tasolla).

toinen periaate on, että tietojen versioinnin tulee olla arvoperusteista, ei muuttuja-tai havaintoperusteista. Systeemi ei voi erottaa havaintoja muuttujista tai muuttujista havaintojen edelle; havainnon muutos on välttämättä muuttujan muutos, ja päinvastoin.

kolmas tiedon versioinnin periaate on, että tieto on olemassa muodosta riippumatta. Jos yksi muuttaa tietojen arvo CSV vs. JSON puu, ne ovat sisältöä vastaavia muutoksia. Näin ollen minkä tahansa versionhallintajärjestelmän olisi sallittava tietojen käyttäjien olla vuorovaikutuksessa tietojen kanssa valitsemassaan tiedostomuodossa käyttämättä välttämättä taustalla olevaa tietojen tallennusmuotoa.

tiedon versioinnin neljäs periaate on, että yhteistyö on olennaista tiedon tuottamisessa ja kuratoinnissa. Tiedon versiointijärjestelmän tulee olla natiivisti yhteistoiminnallinen ja loogisesti kirjattava, kuka dataa tuottaa ja muokkaa.

tietojen versioinnin viides periaate on, että tietorakenteen muutokset kirjataan tietoarvoista riippumatta. Lajittele havaintojen järjestys, sarakkeiden/muuttujien järjestely ja rivien järjestely tapauksina tapausvuosia vastaan jne. (eli., ”wide ”versus” long ” arrangements) ovat datajoukon rakenteellisia ominaisuuksia, eivät datan ominaisuuksia sinänsä. Nämä ovat tärkeitä, mutta tietojen versiointiprosessin pitäisi pystyä erottamaan aineiston sisällön muutos aineiston organisaation tai rakenteen muutoksesta ja jälkimmäisessä tapauksessa tunnistamaan oikein identtiseksi aineisto, joka on järjestetty kahdella eri tavalla.

tietojen versioinnin kuudes periaate on, että metatiedolla on merkitystä, mutta kuten rakenteellakin, sitä tulee käsitellä erillään tietojen muutoksista. Kaksi identtistä tietokokonaisuutta, joissa on erilaisia metatietoja, olisi tunnustettava sisällöltään identtisiksi.

alustavat päätelmät

tiedot on tallennettava avainarvomaisesti, jos mielivaltaisella avaimella on tietty tietoarvo. Kartoitus yhdistää sitten nämä tietyt tietoarvot sekä havaintoihin että muuttujiin niin, että kaikki tietojen muutosten arviointi on muoto-ja rakenne-riippumatonta. Tällöin arvon muutos kirjataan ensin arvon muutoksena, mutta se voidaan toissijaisesti tunnistaa sekä havainnon että muuttujan samanaikaiseksi muutokseksi.

tällaisen avainarvosäilön käyttöliittymän tulisi olla tutussa ja joustavassa muodossa: käyttäjien tulisi olla vuorovaikutuksessa tietojen versiointijärjestelmän kanssa millä tahansa tavalla, jolla he tällä hetkellä käyttävät tietoja (esim.tekstieditori, tietojen analysointiohjelmisto, taulukkolaskentasovellus jne.). Muutokset kirjataan päätiedostoon, joka voi tuoda ja viedä suoraan mihin tahansa tiedostomuotoon (mukaan lukien erotetut tiedostot, laskentataulukot, XML, JSON jne.).

tietojen versiointijärjestelmissä on oltava kehittyneempi commit-järjestelmä kuin nykyisissä, ohjelmistosuuntautuneissa versionhallintajärjestelmissä. Toimitusten olisi erityisesti tallennettava paitsi muutos tietoarvoon, rakenteeseen tai metatietoihin myös jäsenneltyä tietoa, joka selittää muutoksen, mukaan lukien muutoksen syy, tietoarvon lähde(lähteet) ja muutoksen tekijä. Olennaisilta osiltaan sekä koko datan muutosjoukkojen että-tilojen olisi oltava täysin siteerattavia ja niissä olisi oltava viittaukseen liittyvää metatietoa.

Vastaa

Sähköpostiosoitettasi ei julkaista.