leeper / data-versioning

(C) Thomas J. Leeper (2015), licențiat CC-BY

controlul versiunii este o parte uriașă a cercetării reproductibile și a dezvoltării de software open source. Versionarea oferă o istorie completă a unui obiect digital (de exemplu, un program software, Un proiect de cercetare etc.) și, important, permite urmărirea modificărilor aduse acelui obiect, când au fost făcute aceste modificări și (cu metadatele corespunzătoare) de ce au fost făcute aceste modificări. Acest document deține o parte din gândirea mea actuală despre controlul versiunii pentru date.

context context

în special în științele sociale, cercetătorii depind de seturi de date publice mari (de exemplu, politică, calitatea guvernării, corelații de război, ANES, ESS etc.) ca material sursă pentru cercetarea cantitativă. Aceste seturi de date evoluează de obicei (se adaugă date noi în timp, se fac corecții la valorile datelor etc.) și noile versiuni sunt făcute publice periodic. Uneori, aceste date sunt eforturi complexe de colaborare (a se vedea, de exemplu, calitatea Guvernului), iar altele sunt comunicate publice ale eforturilor de colectare a datelor cu o singură instituție (de exemplu, ANES). În timp ce seturile de date colaborative creează un caz de utilizare mai evident pentru controlul versiunii, seturile de date cu o singură instituție ar putea fi, de asemenea, îmbunătățite prin controlul versiunii. Acest lucru este deosebit de important, deoarece versiunile vechi ale acestor seturi de date vitale nu sunt adesea arhivate (de exemplu, ANES), ceea ce înseamnă că este în esență imposibil să se recupereze o versiune anterioară a unui set de date Anes dat după ce a avut loc o nouă versiune. Acest post este menit să orienteze gândirea despre modul de gestionare a creării, curării, revizuirii și diseminării acestor tipuri de seturi de date. În timp ce ideile de aici s-ar putea aplica și modului în care cineva se gândește la gestionarea propriilor date, probabil că se aplică mai mult în etapa de creare a datelor decât la utilizarea ulterioară a datelor după ce un set de date este în esență complet sau înghețat.

revizuirea instrumentelor și abordărilor existente

Institutul de date deschise are un post frumos care prezintă provocările utilizării software-ului standard de control al versiunilor (și anume, Git) pentru controlul versiunilor datelor. Problema principală este că git, la fel ca aproape toate VC-urile, este conceput pentru a monitoriza modificările liniilor din fișierele text. Acest lucru are mult sens pentru cod, precum și pentru articole, text etc. Dar începe să aibă mai puțin sens pentru obiectele digitale în care o linie nu este o unitate semnificativă. Acest lucru devine foarte clar atunci când începem să versiunii ceva de genul unui fișier valori separate prin virgulă (CSV) (așa cum descrie postarea ODI). Schimbarea unui singur câmp de date duce la o schimbare de linie completă, chiar dacă doar o singură celulă s-a schimbat de fapt. O problemă similară apare în XML, JSON sau alte formate delimitate de text (totuși, rețineți că Open Knowledge Foundation pare să favorizeze JSON ca mod de stocare).

utilizarea liniei \n ca delimitator pentru a urmări modificările unui obiect funcționează pentru date. daff este un instrument javascript care încearcă să compenseze această slăbiciune. Acesta oferă un dif (compararea a două versiuni de fișiere) care respectă structura tabelară a multor fișiere de date prin evidențierea modificărilor specifice celulei. Acesta nu este un sistem complet de control al versiunii, totuși, este pur și simplu un instrument dif care poate servi ca un add-on util pentru git.

o postare pe blogul Open Knowledge Foundation susține că există o anumită logică pentru seturile de modificări bazate pe linie, deoarece un CSV standard (sau orice fișier de date tabulare) înregistrează de obicei o singură observație pe propria linie. Controlul versiunii bazat pe linie are apoi sens pentru înregistrarea modificărilor observațiilor (privilegiind astfel rândurile/observațiile asupra coloanelor/variabilelor).

dat își propune să încerce să fie un „git pentru date”, dar starea proiectului este puțin neclară, având în vedere că nu a existat o dezvoltare foarte activă pe Github. Un Q / A pe Open Data StackExchange indică câteva resurse suplimentare pentru alternative git adecvate datelor, dar nu există nimic cuprinzător.

amprenta numerică universală (UNF) oferă o strategie potențială pentru controlul versiunii datelor. Într-adevăr, asta este exact ceea ce a fost conceput să facă. Nu este un sistem de control al versiunii în sine, dar oferă un hash care poate fi util pentru a determina când s-a schimbat un set de date. Ea are unele caracteristici frumos:

  • format de fișier independent (deci mai bine decât un MD5)
  • ordine coloană independent (un set de date în cazul în care coloanele au fost amestecate produce același hash UNF)
  • se ocupă în mod constant numere în virgulă mobilă (rotunjire și probleme de precizie sunt fără probleme), dar, UNF nu este perfect. Problemele includ:
  • este sensibil la Sortare (un set de date identic care este sortat pe rând produce un alt UNF; privilegiind astfel coloanele/variabilele peste rânduri/observații)
  • nu există nicio manipulare a metadatelor (de ex., numele variabilelor nu fac parte din hash)
  • este destul de sensibil la structura datelor (de exemplu, reprezentările „largi” și „lungi” ale aceluiași set de date produc diferite UNFs)
  • nu este un sistem de control al versiunii și nu oferă, în esență, nicio perspectivă asupra a ceea ce s-a schimbat, doar că a avut loc o modificare

toate aceste instrumente se concentrează, de asemenea, pe datele în sine, mai degrabă decât pe metadatele asociate (de datele). În timp ce unele formate de date (de exemplu, formate proprietare precum Stata .dta și SPSS .sav) codifică aceste metadate direct în fișier, nu este o caracteristică comună a structurilor de date delimitate pe scară largă de text. Uneori, cărțile de cod sunt modificate independent de valorile datelor și invers, dar este mai degrabă să vedem seturi de date publice mari care oferă informații detaliate despre modificările fie ale datelor, fie ale cărții de cod, cu excepția lansărilor ocazionale.

o altă provocare majoră pentru controlul versiunilor de date este că instrumentele existente controlul versiunilor nu sunt bine concepute pentru a gestiona proveniența. Când datele sunt generate, stocate sau modificate, un sistem de control al versiunilor orientat către software nu are un mecanism evident pentru înregistrarea motivului pentru care valorile dintr-un set de date sunt ceea ce sunt sau de ce se fac modificări la anumite valori. Un mesaj de comitere ar putea furniza aceste informații, dar de îndată ce o valoare este modificată din nou, istoricul modificărilor la o anumită valoare se pierde în istoricul mai larg al fișierului de date în ansamblu.

deci, nu există în mod clar instrumente complete pentru datele de versionare.

unele principii ale versiunilor de date

primul principiu al versiunilor de date este că modificările aduse datelor au surse sau explicații. Un sistem de versionare a datelor trebuie să poată conecta valorile datelor, structura și metadatele (și modificările acestor caracteristici) la explicațiile acelor valori sau la modificările valorilor la nivel de valoare (mai degrabă decât la nivelul variabilelor, observațiilor sau fișierelor).

al doilea principiu este că versionarea datelor ar trebui să se bazeze pe valori, nu pe variabile sau pe observații. Un sistem nu poate privilegia observațiile asupra variabilelor sau variabilele asupra observațiilor; o schimbare la o observație este neapărat o schimbare la o variabilă și invers.

al treilea principiu al versiunilor de date este că datele există independent de formatul lor. Dacă se modifică o valoare de date într-un CSV față de un arbore JSON, acestea sunt modificări echivalente conținutului. Ca atare, orice sistem de control al versiunii ar trebui să permită utilizatorilor de date să interacționeze cu datele în orice format de fișier pe care îl aleg, fără a utiliza neapărat formatul de stocare a datelor subiacente.

al patrulea principiu al versiunilor de date este că colaborarea este esențială pentru generarea și Curarea datelor. Un sistem de versionare a datelor trebuie să fie nativ colaborativ și să înregistreze logic cine generează și modifică Date.

al cincilea principiu al versiunilor datelor este că modificările structurii datelor trebuie înregistrate independent de valorile datelor. Ordinea de sortare a observațiilor, dispunerea coloanelor/variabilelor și dispunerea rândurilor ca cazuri versus caz-ani etc. (adică., aranjamente” largi „versus” lungi”) sunt caracteristici structurale ale unui set de date, nu caracteristici ale datelor în sine. Acestea sunt importante, dar un proces de versionare a datelor ar trebui să poată distinge o modificare a conținutului unui set de date de o modificare a organizației sau structurii unui set de date și, în ultimul caz, să recunoască corect ca identic Un set de date care este aranjat în două moduri diferite.

al șaselea principiu al versiunilor datelor este că metadatele contează, dar, la fel ca structura, ar trebui tratate separat de modificările aduse datelor. Două seturi de date identice cu metadate diferite ar trebui recunoscute ca fiind identice cu conținutul.

concluzii provizorii

datele trebuie stocate într-o manieră cheie-valoare, unde o cheie arbitrară deține o anumită valoare a datelor. O mapare conectează apoi acele valori de date particulare atât la observații, cât și la variabile, astfel încât orice evaluare a modificărilor datelor să fie independentă de format și independentă de structură. Ca atare, o modificare a unei valori este înregistrată mai întâi ca o modificare a unei valori, dar poate fi recunoscută secundar ca o modificare simultană atât a unei observații, cât și a unei variabile.

orice interfață pentru un astfel de magazin de valori cheie ar trebui să vină într-o formă familiară și flexibilă: utilizatorii ar trebui să interacționeze cu un sistem de versiuni de date prin orice mod folosesc în prezent date (de exemplu, un editor de text, software de analiză a datelor, o aplicație de calcul tabelar etc.). Modificările trebuie înregistrate într-un fișier master care poate importa și exporta în mod nativ și imediat în orice format de fișier de date (inclusiv fișiere delimitate, foi de calcul, XML, JSON etc.).

sistemele de versionare a datelor trebuie să aibă un sistem de comitere mai sofisticat decât cel furnizat de sistemele actuale de control al versiunilor orientate către software. În special, angajamentele ar trebui să înregistreze nu numai modificarea unei valori, structuri sau metadate de date, ci și informații structurate care explică modificarea respectivă, inclusiv motivul modificării, sursa(sursele) valorii datelor și autorul modificării. În esență, atât seturile de modificări, cât și stările datelor complete ar trebui să fie pe deplin citabile și să conțină metadate relevante pentru citare.

Lasă un răspuns

Adresa ta de email nu va fi publicată.