leeper / data-versionering

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

versionskontrol er en stor del af reproducerbar forskning og udvikling af open source-programmer. Versionsstyring giver en komplet historie af nogle digitale objekt (f.eks et program, et forskningsprojekt, etc.) og vigtigst af alt tillader man at spore, hvilke ændringer der er foretaget i det objekt, hvornår disse ændringer blev foretaget, og (med de relevante metadata) hvorfor disse ændringer blev foretaget. Dette dokument indeholder nogle af mine nuværende tanker om versionskontrol for data.

Baggrundskontekst

især inden for samfundsvidenskab er forskere afhængige af store, offentlige datasæt (f.eks.) som kildemateriale til kvantitativ forskning. Disse datasæt udvikler sig typisk (nye data tilføjes over tid, korrektioner foretages til dataværdier osv.) og nye udgivelser offentliggøres med jævne mellemrum. Nogle gange er disse data komplekse samarbejdsindsatser (se for eksempel regeringens kvalitet), og andre er offentlige udgivelser af dataindsamlingsindsatser for en enkelt institution (f.eks. Mens kollaborative datasæt skaber en mere indlysende brugssag til versionskontrol, kan datasæt med en enkelt institution også forbedres ved versionskontrol. Dette er især vigtigt, fordi gamle udgivelser af disse vitale datasæt ofte ikke arkiveres (f.eks. ANES), hvilket betyder, at det i det væsentlige er umuligt at gendanne en tidligere version af et givet ANES-datasæt, efter at en ny udgivelse er sket. Dette indlæg er beregnet til at styre tankerne om, hvordan man styrer oprettelsen, kuration, revision, og formidling af denne slags datasæt. Mens ideerne her også kan gælde for, hvordan man tænker på at styre deres egne data, anvender de sandsynligvis mere på tidspunktet for dataoprettelse end ved senere dataanvendelse, efter at et datasæt i det væsentlige er komplet eller frosset.

gennemgang af eksisterende værktøjer og tilgange

Open Data Institute har et godt indlæg, der beskriver udfordringerne ved at bruge standard, programorienteret versionsstyringsprogram (nemlig git) til versionskontrol af data. Hovedproblemet er, at git, som næsten alle VC ‘ er, er designet til at overvåge ændringer i linjer i tekstfiler. Dette giver meget mening for kode såvel som For artikler, tekst osv. Men det begynder at give mindre mening for digitale objekter, hvor en linje ikke er en meningsfuld enhed. Dette bliver virkelig klart, når vi begynder at versionere noget som en kommasepareret værdi (CSV)-fil (som ODI-indlægget beskriver). Ændring af et enkelt datafelt fører til en fuldlinjeændring, selvom kun en celle faktisk ændrede sig. Et lignende problem opstår i JSON, JSON eller andre tekstafgrænsede formater (Bemærk dog, at Open Vidensfonden synes at favorisere JSON som en lagringstilstand).

brug af linebreak \n som afgrænser til at spore ændringer i et objekt fungerer for data. daff er et javascript-værktøj, der forsøger at kompensere for den svaghed. Det giver en diff (sammenligning af to filversioner), der respekterer tabelstrukturen i mange datafiler ved at fremhæve cellespecifikke ændringer. Dette er ikke et komplet versionskontrolsystem, men det er simpelthen et diff-værktøj, der kan tjene som en nyttig tilføjelse til git.

et indlæg på bloggen Open vidensfundament hævder, at der er en vis logik i linjebaserede ændringssæt, fordi en standard CSV (eller en hvilken som helst tabelfil) typisk registrerer en enkelt observation på sin egen linje. Linjebaseret versionskontrol giver derefter mening til registrering af ændringer i observationer (således privilegerer rækker/observationer over kolonner/variabler).

dat sigter mod at forsøge at være en “git for data”, men projektets status er lidt uklar, da der ikke har været meget aktiv udvikling på Github. Et spørgsmål / en på Open Data Stackudveksling peger på nogle yderligere ressourcer til data-passende git-alternativer, men der er ikke noget omfattende.

Universal Numeric Fingerprint (UNF) giver en potentiel strategi for versionskontrol af data. Faktisk er det specifikt, hvad det var designet til at gøre. Det er ikke et versionsstyringssystem i sig selv, men det giver en hash, der kan være nyttig til at bestemme, hvornår et datasæt er ændret. Det har nogle gode funktioner:

  • filformat uafhængig (så bedre end en MD5)
  • Kolonneordre uafhængig (et datasæt, hvor kolonner er blevet blandet, producerer den samme UNF-hash)
  • håndterer konsekvent flydende punktnumre (afrundings-og præcisionsproblemer er uproblematiske), men UNF er ikke perfekt. Problemerne inkluderer:
  • det er sorteringsfølsomt (et identisk datasæt, der er rækkesorteret, producerer en anden UNF; således privilegerer kolonner/variabler over rækker/observationer)
  • der er ingen håndtering af metadata (f. eks. er variabelnavne ikke en del af hash)
  • det er ret følsomt over for datastruktur (f.eks. “brede” og “lange” repræsentationer af det samme datasæt producerer forskellige UNFs)
  • det er ikke et versionskontrolsystem og giver i det væsentlige ingen indsigt i , hvad der ændrede sig, kun at der skete en ændring

alle disse værktøjer fokuserer også på selve dataene snarere end tilknyttede metadata (f. eks. kodebogen, der beskriver data). Mens nogle dataformater (f .eks.dta og SPSS .sav) koder disse metadata direkte i filen, det er ikke et fælles træk ved bredt tekstafgrænsede datastrukturer. Nogle gange ændres kodebøger uafhængigt af dataværdier og omvendt, men det er snarere at se store offentlige datasæt give detaljerede oplysninger om ændringer i enten dataene eller kodebogen, undtagen i lejlighedsvise udgivelser.

en anden stor udfordring for dataversionering er, at eksisterende værktøjer versionskontrol er ikke godt designet til at håndtere herkomst. Når data genereres, gemmes eller ændres, har et programorienteret versionsstyringssystem ingen indlysende mekanisme til at registrere, hvorfor værdier i et datasæt er, hvad de er, eller hvorfor der foretages ændringer i bestemte værdier. En commit-meddelelse kan give disse oplysninger, men så snart en værdi ændres igen, går historien om ændringer til en bestemt værdi tabt i datafilens bredere historie som helhed.

så der findes tydeligvis ingen komplette værktøjer til versionsdata.

nogle principper for Dataversionering

det første princip for dataversionering er, at ændringer i data har kilder eller forklaringer. Et system med dataversionering skal være i stand til at forbinde dataværdier, struktur og metadata (og ændringer af disse funktioner) til forklaringer af disse værdier eller ændringer i værdier på værdiniveauet (snarere end på niveauet for variabler, observationer eller filer).

det andet princip er, at dataversionering skal være værdibaseret, ikke variabel-eller observationsbaseret. Et system kan ikke privilegere observationer over variabler eller variabler frem for observationer; en ændring af en observation er nødvendigvis en ændring af en variabel og omvendt.

det tredje princip i dataversionering er, at data eksisterer uafhængigt af deres format. Hvis man ændrer en dataværdi i en CSV versus et JSON-træ, er det ændringer, der svarer til indholdet. Som sådan bør ethvert system med versionskontrol give databrugere mulighed for at interagere med data i det filformat, de vælger, uden nødvendigvis at bruge det underliggende datalagringsformat.

det fjerde princip i dataversionering er, at samarbejde er afgørende for datagenerering og kuration. Et system med dataversionering skal være indbygget samarbejdende og logisk registrere, hvem der genererer og ændrer data.

det femte princip for dataversionering er, at ændringer i datastrukturen skal registreres uafhængigt af dataværdierne. Sorter rækkefølge af observationer, arrangementet af kolonner/variabler og arrangementet af rækker som tilfælde versus case-år mv. (dvs., “brede “versus” lange ” arrangementer) er strukturelle træk ved et datasæt, ikke funktioner i dataene i sig selv. Disse er vigtige, men en dataversionsproces skal være i stand til at skelne en ændring af indholdet af et datasæt fra en ændring af organisationen eller strukturen i et datasæt og i sidstnævnte tilfælde korrekt genkende som identisk et datasæt, der er arrangeret på to forskellige måder.

det sjette princip for dataversionering er, at metadata betyder noget, men som struktur skal håndteres separat fra ændringer i data. To identiske datasæt med forskellige metadata skal anerkendes som indhold-identiske.

foreløbige konklusioner

Data skal gemmes på en nøgleværdi måde, hvor en vilkårlig nøgle har en bestemt dataværdi. En kortlægning forbinder derefter disse bestemte dataværdier med både observationer og variabler, så enhver vurdering af ændringer i data er formatuafhængig og strukturuafhængig. Som Sådan registreres en ændring til en værdi først som en ændring til en værdi, men kan sekundært genkendes som en samtidig ændring af både en observation og en variabel.

enhver grænseflade til en sådan nøgleværdibutik skal komme i en velkendt og fleksibel form: brugere skal interagere med et dataversionssystem via den måde, de i øjeblikket bruger data (f.eks.). Ændringer skal registreres i en masterfil, der kan importeres fra og eksporteres til ethvert datafilformat (herunder afgrænsede filer, regneark, JSON osv.).

dataversionssystemer skal have et mere sofistikeret commit-system end det, der leveres af nuværende, programorienterede versionsstyringssystemer. Forpligtelserne skal navnlig ikke kun registrere ændringen til en dataværdi, struktur eller metadata, men også strukturerede oplysninger, der forklarer ændringen, herunder årsagen til ændringen, kilden(E) til dataværdien og ophavsmanden til ændringen. I det væsentlige bør både ændringssæt og tilstande af de komplette data være fuldt citerbare og bære citationsrelevante metadata.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.