leeper / dataversionering

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

versionskontroll är en stor del av reproducerbar forskning och utveckling av öppen källkod. Versionshantering ger en fullständig historik över vissa digitala objekt (t.ex. ett program, ett forskningsprojekt, etc.) och, viktigare, tillåter en att spåra vilka ändringar som har gjorts i det objektet, när dessa ändringar gjordes och (med lämpliga metadata) varför dessa ändringar gjordes. Detta dokument innehåller några av mina nuvarande tankar om versionskontroll för data.

Bakgrundskontext

särskilt inom samhällsvetenskapen är forskare beroende av stora, offentliga dataset (t.ex. politik, Regeringskvalitet, Krigskorrelater, ANES, ESS, etc.) som källmaterial för kvantitativ forskning. Dessa datamängder utvecklas vanligtvis(nya data läggs till över tiden, korrigeringar görs till datavärden etc.) och nya utgåvor offentliggörs regelbundet. Ibland är dessa data komplexa samarbetsinsatser (se till exempel regeringens kvalitet) och andra är offentliga utgåvor av datainsamlingsinsatser för enskilda institutioner (t.ex. ANES). Medan samarbetsdatauppsättningar skapar ett mer uppenbart användningsfall för versionskontroll, kan datauppsättningar för enskilda institutioner också förbättras genom versionskontroll. Detta är särskilt viktigt eftersom gamla utgåvor av dessa viktiga datamängder ofta inte arkiveras (t.ex. ANES) vilket innebär att det i huvudsak är omöjligt att återställa en tidigare version av en given ANES-dataset efter att en ny version har inträffat. Det här inlägget är tänkt att styra tänkande om hur man hanterar skapandet, curation, revision, och spridning av dessa typer av datamängder. Medan ideerna här också kan gälla för hur man tänker på att hantera sina egna data, tillämpar de förmodligen mer på scenen av dataskapande än vid senare dataanvändning efter att en dataset är väsentligen komplett eller frusen.

granskning av befintliga verktyg och tillvägagångssätt

Open Data Institute har ett bra inlägg som beskriver utmaningarna med att använda standard, mjukvaruorienterad versionskontrollprogramvara (nämligen git) för versionskontroll av data. Huvudproblemet är att git, som nästan alla VCS, är utformad för att övervaka ändringar av linjer i textfiler. Detta är mycket meningsfullt för kod, såväl som för artiklar,text etc. Men det börjar ge mindre mening för digitala objekt där en linje inte är en meningsfull enhet. Detta blir riktigt tydligt när vi börjar version något som en kommaseparerad värden (CSV) fil (som ODI post beskriver). Ändra ett enda datafält leder till en full-line förändring, även om endast en cell faktiskt ändras. Ett liknande problem uppstår i XML, JSON eller andra textavgränsade format (Observera dock att Open Knowledge Foundation verkar gynna JSON som lagringsläge).

att använda radbrytningen \n som avgränsare för att spåra ändringar i ett objekt fungerar för data. daff är ett javascript-verktyg som försöker kompensera för den svagheten. Det ger en diff (jämförelse av två filversioner) som respekterar tabellstrukturen för många datafiler genom att markera cellspecifika ändringar. Detta är inte ett fullständigt versionskontrollsystem, men det är helt enkelt ett diff-verktyg som kan fungera som ett användbart tillägg till git.

ett inlägg på Open Knowledge Foundation-bloggen hävdar att det finns viss logik för linjebaserade ändringsuppsättningar eftersom en vanlig CSV (eller någon tabelldatafil) vanligtvis registrerar en enda observation på sin egen rad. Linjebaserad versionskontroll är då meningsfull för inspelning av ändringar i observationer (därmed privilegierar rader/observationer över kolumner/variabler).

dat syftar till att försöka vara en ”git för data” men projektets status är lite oklart, eftersom det inte har varit mycket aktiv utveckling på Github. En Q / A på Open Data StackExchange pekar på några ytterligare resurser för data-lämpliga git-alternativ, men det finns inget omfattande.

Universal Numeric Fingerprint (UNF) ger en potentiell strategi för versionskontroll av data. Det är faktiskt specifikt vad det var utformat för att göra. Det är inte ett versionskontrollsystem i sig, men det ger en hash som kan vara användbar för att bestämma när en dataset har ändrats. Den har några trevliga funktioner:

  • filformat oberoende (så bättre än en MD5)
  • Kolumnordningsoberoende (en dataset där kolumner har blandats producerar samma UNF-hash)
  • hanterar konsekvent flyttal (avrundnings-och precisionsproblem är oproblematiska)men UNF är inte perfekt. Problemen inkluderar:
  • det är sorteringskänsligt (en identisk dataset som är radsorterad ger en annan UNF; därmed privilegierar kolumner/variabler över rader/observationer)
  • det finns ingen hantering av metadata (t. ex. 7235>
  • det är ganska känsligt för datastruktur (t.ex. ”breda” och ”långa” representationer av samma dataset producerar olika UNFs)
  • det är inte ett versionshanteringssystem och ger i huvudsak ingen inblick i vad som ändrats, bara att en förändring inträffade

alla dessa verktyg fokuserar också på själva data, snarare än tillhörande metadata (t. ex. kodboken som beskriver hur data). Medan vissa dataformat (t .ex. proprietära format som statas.dta och SPSS .sav) koda denna metadata direkt i filen, det är inte ett vanligt inslag i allmänt textavgränsade datastrukturer. Ibland ändras kodböcker oberoende av datavärden och vice versa, men det är snarare att se stora offentliga datamängder ge detaljerad information om ändringar av antingen data eller kodboken, utom i tillfälliga utgåvor.

En annan stor utmaning för dataversionering är att befintliga verktyg versionskontroll inte är väl utformade för att hantera härkomst. När data genereras, lagras eller modifieras har ett programvaruorienterat versionskontrollsystem ingen uppenbar mekanism för att registrera varför värden i en dataset är vad de är eller varför ändringar görs i vissa värden. Ett commit-meddelande kan ge den här informationen, men så snart ett värde ändras igen, förloras historiken för ändringar av ett visst värde i den bredare historiken för datafilen som helhet.

så det finns helt klart inga kompletta verktyg för versionshantering av data.

vissa principer för Dataversionering

den första principen för dataversionering är att ändringar av data har källor eller förklaringar. Ett system för dataversionering måste kunna koppla datavärden, struktur och metadata (och ändringar av dessa funktioner) till förklaringar av dessa värden eller ändringar av värden på värdenivå (snarare än på nivå med variabler, observationer eller filer).

den andra principen är att dataversionering ska vara värdebaserad, inte variabel-eller observationsbaserad. Ett system kan inte privilegiera observationer över variabler eller variabler över observationer; en ändring av en observation är nödvändigtvis en ändring av en variabel och vice versa.

den tredje principen för dataversionering är att data existerar oberoende av deras format. Om man ändrar ett datavärde i en CSV kontra ett JSON-träd är det innehållsekvivalenta ändringar. Som sådan bör alla system för versionskontroll tillåta dataanvändare att interagera med data i vilket filformat de väljer utan att nödvändigtvis använda det underliggande datalagringsformatet.

den fjärde principen för dataversionering är att samarbete är viktigt för datagenerering och curation. Ett system för dataversionering måste vara inbyggt samarbete och logiskt registrera vem som genererar och modifierar data.

den femte principen för dataversionering är att ändringar i datastrukturen ska registreras oberoende av datavärden. Sorteringsordning för observationer, arrangemang av kolumner / variabler och arrangemang av rader som fall kontra fallår etc. (dvs., ”breda ”kontra” långa ” arrangemang) är strukturella egenskaper hos en dataset, inte funktioner i data i sig. Dessa är viktiga, men en dataversionsprocess bör kunna skilja en ändring av innehållet i en datauppsättning från en ändring av organisationen eller strukturen i en datauppsättning och i det senare fallet korrekt känna igen en datauppsättning som är identisk på två olika sätt.

den sjätte principen för dataversionering är att metadata är viktiga men, som struktur, bör hanteras separat från ändringar av data. Två identiska datamängder med olika metadata ska identifieras som innehållsidentiska.

preliminära slutsatser

Data ska lagras på ett nyckelvärde sätt, där en godtycklig nyckel har ett visst datavärde. En kartläggning kopplar sedan dessa specifika datavärden till både observationer och variabler, så att varje bedömning av ändringar av data är formatoberoende och strukturoberoende. Som sådan registreras en förändring till ett värde först som en förändring till ett värde men kan sekundärt erkännas som en samtidig förändring av både en observation och en variabel.

alla gränssnitt till en sådan nyckelvärdesbutik bör komma i en bekant och flexibel form: användare bör interagera med ett dataversionssystem via vilket sätt de för närvarande använder data (t.ex. en textredigerare, dataanalysprogramvara, ett kalkylprogram etc.). Ändringar bör registreras i en huvudfil som kan inbyggt och omedelbart importera från och exportera till alla datafilformat (inklusive avgränsade filer, kalkylblad, XML, JSON, etc.).

dataversionssystem måste ha ett mer sofistikerat commit-system än det som tillhandahålls av nuvarande, programvaruorienterade versionshanteringssystem. I synnerhet bör åtaganden registrera inte bara ändringen till ett datavärde, struktur eller metadata utan också strukturerad information som förklarar den ändringen, inklusive orsaken till ändringen, källan / källorna till datavärdet och författaren till ändringen. I huvudsak bör både förändringsuppsättningar och tillstånd för de fullständiga uppgifterna vara fullständigt citerbara och bära citatrelevanta metadata.

Lämna ett svar

Din e-postadress kommer inte publiceras.