leeper / data-versjonskontroll

(C) Thomas J. Leeper (2015), lisensiert CC-BY

Versjonskontroll er en stor del av reproduserbar forskning og åpen kildekode-utvikling. Versjonskontroll gir en komplett historie av noen digitale objekt(f. eks, et program, et forskningsprosjekt, etc.) og, viktigere, tillater en å spore hvilke endringer som har gjort til det objektet, når disse endringene ble gjort, og (med de riktige metadataene) hvorfor disse endringene ble gjort. Dette dokumentet inneholder noe av min nåværende tenkning om versjonskontroll for data.

Bakgrunnskontekst

spesielt i samfunnsvitenskapene er forskere avhengige av store, offentlige datasett (F. Eks. Politikk, Regjeringskvalitet, Korrelater Av Krig, ANES, ESS, etc.) som kildemateriale for kvantitativ forskning. Disse datasettene utvikler seg vanligvis (nye data legges til over tid, rettelser gjøres til dataverdier, etc.) og nye utgivelser blir periodisk offentliggjort. Noen ganger er disse dataene komplekse samarbeidsprosjekter (se For Eksempel Quality Of Government) og andre er offentlige utgivelser av datainnsamlingsarbeid for enkeltinstitusjoner (F.eks. Mens samarbeidende datasett skaper en mer åpenbar brukstilfelle for versjonskontroll, kan enkeltinstitusjonsdatasett også forbedres ved versjonskontroll. DETTE er spesielt viktig fordi gamle utgivelser av disse vitale datasettene ofte ikke arkiveres (F. eks. ANES), noe som betyr at det i hovedsak er umulig å gjenopprette en tidligere versjon av et gitt ANES-datasett etter at en ny utgivelse har skjedd. Dette innlegget er ment å styre å tenke på hvordan man skal håndtere opprettelse, kurering, revisjon og formidling av slike datasett. Mens ideene her også kan gjelde for hvordan man tenker på å administrere sine egne data, bruker de sannsynligvis mer på scenen av dataopprettelse enn ved senere databruk etter at et datasett er i hovedsak fullført eller frosset.

Gjennomgang Av Eksisterende Verktøy Og Tilnærminger

Open Data Institute har et fint innlegg som beskriver utfordringene ved å bruke standard, programvareorientert versjonskontrollprogramvare (nemlig git) for versjonskontroll av data. Hovedproblemet er at git, som nesten ALLE VCS, er designet for å overvåke endringer i linjer i tekstfiler. Dette gir mye mening for kode, så vel som for artikler, tekst, etc. Men det begynner å gi mindre mening for digitale objekter der en linje ikke er en meningsfull enhet. Dette blir veldig klart når vi begynner å versjon noe som en kommaseparert verdier (CSV) fil (som ODI post beskriver). Endring av et enkelt datafelt fører til en fulllinjeendring, selv om bare en celle faktisk endret seg. Et lignende problem oppstår I XML, JSON eller andre tekstseparerte formater (men merk At Open Knowledge Foundation ser ut TIL å favorisere JSON som en lagringsmodus).

bruke linebreak \n som skilletegn for å spore endringer i et objekt fungerer for data. daff er et javascript-verktøy som prøver å gjøre opp for den svakheten. Det gir en diff (sammenligning av to filversjoner) som respekterer tabellstrukturen til mange datafiler ved å markere cellespesifikke endringer. Dette er ikke et fullversjonskontrollsystem, men det er bare et diff-verktøy som kan tjene som et nyttig tillegg til git.

et innlegg på open Knowledge Foundation-bloggen hevder at det er noe logikk i linjebaserte endringssett fordi en STANDARD CSV (eller en hvilken som helst tabelldatafil) vanligvis registrerer en enkelt observasjon på sin egen linje. Linjebasert versjonskontroll gir da mening for å registrere endringer i observasjoner (dermed privilegere rader/observasjoner over kolonner/variabler).

dat har som mål å prøve å være en «git for data», men statusen til prosjektet er litt uklar, gitt at Det ikke har vært veldig aktiv utvikling på Github. En Q / A På Open Data StackExchange peker på noen ytterligere ressurser for data-passende git-alternativer, men det er ikke noe omfattende.

Universal Numeric Fingerprint (UNF) gir en potensiell strategi for versjonskontroll av data. Faktisk er det spesielt hva det var designet for å gjøre. Det er ikke et versjonskontrollsystem i seg selv, men det gir en hash som kan være nyttig for å bestemme når et datasett har endret seg. Den har noen fine funksjoner:

  • Uavhengig filformat (så bedre ENN EN MD5)
  • Kolonnerekkefølge uavhengig (et datasett der kolonner har blitt blandet produserer samme UNF hash)
  • Håndterer Konsekvent flyttall (avrunding og presisjonsproblemer er uproblematiske), MEN UNF er Ikke perfekt. Problemene inkluderer:
  • det er sorteringssensitivt (et identisk datasett som er radsortert produserer en annen UNF; dermed privilegerer kolonner / variabler over rader / observasjoner)
  • det er ingen håndtering av metadata (f. eks.»brede» og «lange» representasjoner av det samme datasettet produserer forskjellige UNFs)
  • Det er ikke et versjonskontrollsystem Og gir i hovedsak ingen innsikt i hva som er endret, bare at en endring skjedde

Alle disse verktøyene fokuserer også på dataene selv, i stedet for tilhørende metadata (f.eks. dataene). Mens noen dataformater (f .eks. proprietære formater som Stata.dta og SPSS .sav) kode denne metadata direkte i filen, er det ikke et vanlig trekk ved vidt tekstseparerte datastrukturer. Noen ganger kodebøker er endret uavhengig av dataverdier og vice versa, men det er heller å se store offentlige datasett gi detaljert informasjon om endringer i enten data eller kodeboken, unntatt i sporadiske utgivelser.

En annen stor utfordring til data versjonskontroll er at eksisterende verktøy versjonskontroll ikke er godt utformet for å håndtere proveniens. Når data genereres, lagres eller endres, har et programvareorientert versjonskontrollsystem ingen åpenbar mekanisme for å registrere hvorfor verdier i et datasett er hva de er eller hvorfor endringer gjøres i bestemte verdier. En commit-melding kan gi denne informasjonen, men så snart en verdi endres igjen, går historien om endringer til en bestemt verdi tapt i den bredere historien til datafilen som helhet.

Så det er tydeligvis ingen komplette verktøy for versjonering av data.

Noen Prinsipper For Dataversjonskontroll

det første prinsippet for dataversjonskontroll er at endringer i data har kilder eller forklaringer. Et system for versjonskontroll av data må kunne koble dataverdier, struktur og metadata (og endringer i disse funksjonene) til forklaringer av disse verdiene eller endringene i verdier på verdinivå (i stedet for på nivå med variabler, observasjoner eller filer).

det andre prinsippet er at dataversjonering skal være verdibasert, ikke variabel-eller observasjonsbasert. Et system kan ikke privilegere observasjoner over variabler eller variabler over observasjoner; en endring til en observasjon er nødvendigvis en endring til en variabel, og omvendt.

det tredje prinsippet om dataversjonering er at data eksisterer uavhengig av formatet. Hvis man endrer en dataverdi i EN CSV versus ET json-tre, er det innholdsekvivalente endringer. Som sådan bør ethvert system for versjonskontroll tillate databrukere å samhandle med data i hvilket filformat de velger uten nødvendigvis å bruke det underliggende datalagringsformatet.

det fjerde prinsippet om dataversjonering er at samarbeid er viktig for datagenerering og kurering. Et system av data versjonskontroll må være opprinnelig samarbeidende og logisk posten som genererer og endre data.

det femte prinsippet om dataversjon er at endringer i datastrukturen skal registreres uavhengig av dataverdier. Sorteringsrekkefølge av observasjoner, arrangement av kolonner/variabler, og arrangement av rader som saker versus saksår, etc. (altså., «bred» versus «lang» ordninger) er strukturelle trekk ved et datasett, ikke funksjoner av dataene per se. Disse er viktige, men en dataversjonsprosess bør kunne skille en endring i innholdet i et datasett fra en endring i organisasjonen eller strukturen til et datasett og, i sistnevnte tilfelle, korrekt gjenkjenne som identisk et datasett som er ordnet på to forskjellige måter.

det sjette prinsippet om dataversjonering er at metadata er viktig, men som struktur, bør håndteres separat fra endringer i data. To identiske datasett med forskjellige metadata skal gjenkjennes som innhold-identisk.

Tentative Konklusjoner

Data skal lagres på en nøkkelverdi måte, der en vilkårlig nøkkel har en bestemt dataverdi. En kartlegging kobler deretter disse bestemte dataverdiene til både observasjoner og variabler, slik at enhver vurdering av endringer i data er formatuavhengig og strukturuavhengig. Som sådan registreres en endring til en verdi først som en endring til en verdi, men kan sekundært gjenkjennes som en samtidig endring til både en observasjon og en variabel.

ethvert grensesnitt til en slik nøkkelverdibutikk bør komme i en kjent og fleksibel form: brukere bør samhandle med et dataversjonssystem via hvilken måte de for øyeblikket bruker data(for eksempel en tekstredigerer, dataanalyseprogramvare, et regnearkprogram, etc.). Endringer skal registreres i en hovedfil som kan importeres fra og eksportere til et hvilket som helst datafilformat (inkludert avgrensede filer, regneark, XML, JSON, etc.).

versjonssystemer for data må ha et mer sofistikert commit-system enn det som leveres av nåværende, programvareorienterte versjonskontrollsystemer. Inger bør ikke bare registrere endringen til en dataverdi, struktur eller metadata, men også strukturert informasjon som forklarer endringen, inkludert årsaken til endringen, kilden(e) til dataverdien og forfatteren av endringen. I hovedsak bør både endringssett og tilstander av de komplette dataene være fullt citable og bære citeringsrelevante metadata.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.