leeper / data-versioning

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

Il controllo della versione è una parte enorme della ricerca riproducibile e dello sviluppo di software open source. Il controllo delle versioni fornisce una cronologia completa di alcuni oggetti digitali (ad esempio, un programma software, un progetto di ricerca, ecc.) e, soprattutto, consente di tracciare quali modifiche hanno apportato a quell’oggetto, quando sono state apportate tali modifiche e (con i metadati appropriati) perché sono state apportate tali modifiche. Questo documento contiene alcuni dei miei attuali pensieri sul controllo della versione per i dati.

Contesto di fondo

Soprattutto nelle scienze sociali, i ricercatori dipendono da grandi set di dati pubblici (ad esempio, Politica, Qualità del governo, Correlati di guerra, ANES, ESS, ecc.) come materiale di base per la ricerca quantitativa. Questi set di dati in genere si evolvono (nuovi dati vengono aggiunti nel tempo,vengono apportate correzioni ai valori dei dati, ecc.) e le nuove versioni vengono periodicamente rese pubbliche. A volte questi dati sono complessi sforzi di collaborazione (vedi, ad esempio, Quality of Government) e altri sono rilasci pubblici di sforzi di raccolta dei dati di un’unica istituzione (ad esempio, ANES). Mentre i set di dati collaborativi creano un caso d’uso più ovvio per il controllo di versione, i set di dati a singola istituzione potrebbero anche essere migliorati dal controllo di versione. Ciò è particolarmente importante perché le vecchie versioni di questi set di dati vitali spesso non vengono archiviate (ad esempio, ANES), il che significa che è essenzialmente impossibile recuperare una versione precedente di un dato set di dati ANES dopo che si è verificata una nuova versione. Questo post ha lo scopo di orientare il pensiero su come gestire la creazione, la cura, la revisione e la diffusione di questo tipo di set di dati. Mentre le idee qui potrebbero applicarsi anche a come si pensa di gestire i propri dati, probabilmente si applicano più nella fase di creazione dei dati che in un successivo utilizzo dei dati dopo che un set di dati è essenzialmente completo o congelato.

Revisione degli strumenti e degli approcci esistenti

L’Open Data Institute ha un bel post che delinea le sfide dell’utilizzo di software di controllo di versione standard e orientato al software (vale a dire, git) per il controllo di versione dei dati. Il problema principale è che git, come quasi tutti i VCS, è progettato per monitorare le modifiche alle righe nei file di testo. Questo ha molto senso per il codice, così come per articoli, testo, ecc. Ma inizia a fare meno senso per gli oggetti digitali in cui una linea non è un’unità significativa. Questo diventa molto chiaro quando iniziamo a eseguire la versione di qualcosa come un file CSV (valori separati da virgole) (come descrive il post ODI). La modifica di un singolo campo dati porta a una modifica a riga intera, anche se solo una cella è effettivamente cambiata. Un problema simile emerge in XML, JSON o altri formati delimitati da testo (tuttavia, si noti che Open Knowledge Foundation sembra favorire JSON come modalità di archiviazione).

L’utilizzo del linebreak \n come delimitatore per tenere traccia delle modifiche a un oggetto funziona per i dati. daff è uno strumento javascript che cerca di compensare questa debolezza. Fornisce un diff (confronto di due versioni di file) che rispetta la struttura tabulare di molti file di dati evidenziando le modifiche specifiche della cella. Questo non è un sistema di controllo della versione completa, però, è semplicemente uno strumento diff che può servire come un utile add-on per git.

Un post sul blog di Open Knowledge Foundation sostiene che esiste una logica per i changeset basati sulla linea perché un CSV standard (o qualsiasi file di dati tabulari) registra in genere una singola osservazione sulla propria linea. Il controllo della versione basato sulla linea ha quindi senso per registrare le modifiche alle osservazioni (privilegiando così righe/osservazioni su colonne/variabili).

dat mira a cercare di essere un “git per i dati” ma lo stato del progetto è un po ‘ poco chiaro, dato che non c’è stato uno sviluppo molto attivo su Github. Un Q / A su Open Data StackExchange punta ad alcune ulteriori risorse per alternative git appropriate ai dati, ma non c’è nulla di completo.

Universal Numeric Fingerprint (UNF) fornisce una potenziale strategia per il controllo della versione dei dati. In effetti, questo è specificamente ciò che è stato progettato per fare. Non è un sistema di controllo della versione di per sé, ma fornisce un hash che può essere utile per determinare quando un set di dati è cambiato. Ha alcune caratteristiche interessanti:

  • Indipendente dal formato file (quindi meglio di un MD5)
  • Indipendente dall’ordine delle colonne (un set di dati in cui le colonne sono state mescolate produce lo stesso hash UNF)
  • Gestisce costantemente i numeri in virgola mobile (i problemi di arrotondamento e precisione non sono problematici)Ma, UNF non è perfetto. I problemi includono:
  • È sensibile all’ordinamento (un set di dati identico che è ordinato in riga produce un UNF diverso, privilegiando così colonne/variabili su righe/osservazioni)
  • Non vi è alcuna gestione dei metadati (ad esempio i nomi di variabili che non sono parte dell’hash)
  • è abbastanza sensibile alla struttura di dati (ad esempio, “wide” e “lungo” rappresentazioni dello stesso set di dati di produrre diversi UNFs)
  • non è un sistema di controllo di versione e fornisce praticamente nessuna conoscenza di ciò che è cambiato, solo che si è verificato un cambiamento

Tutti questi strumenti, inoltre, concentrare l’attenzione sui dati stessi, piuttosto che i metadati associati (ad esempio, il cifrario che descrive i dati). Mentre alcuni formati di dati (ad esempio, formati proprietari come Stata .dta e SPSS .sav) codificare questi metadati direttamente nel file, non è una caratteristica comune di strutture dati ampiamente delimitate dal testo. A volte i codebook vengono modificati indipendentemente dai valori dei dati e viceversa, ma è piuttosto vedere grandi set di dati pubblici fornire informazioni dettagliate sulle modifiche ai dati o al codebook, tranne che nelle versioni occasionali.

Un’altra grande sfida per il controllo delle versioni dei dati è che gli strumenti esistenti di controllo delle versioni non sono ben progettati per gestire la provenienza. Quando i dati vengono generati, archiviati o modificati, un sistema di controllo della versione orientato al software non ha alcun meccanismo ovvio per registrare il motivo per cui i valori in un set di dati sono ciò che sono o perché vengono apportate modifiche a valori particolari. Un messaggio di commit potrebbe fornire queste informazioni, ma non appena un valore viene modificato di nuovo, la cronologia delle modifiche a un particolare valore viene persa nella cronologia più ampia del file di dati nel suo complesso.

Quindi, non esistono chiaramente strumenti completi per il controllo delle versioni dei dati.

Alcuni principi di Versioning dei dati

Il primo principio di versioning dei dati è che le modifiche ai dati hanno origini o spiegazioni. Un sistema di controllo delle versioni dei dati deve essere in grado di collegare i valori dei dati, la struttura e i metadati (e le modifiche a tali funzionalità) alle spiegazioni di tali valori o alle modifiche ai valori a livello di valore (anziché a livello di variabili, osservazioni o file).

Il secondo principio è che il controllo delle versioni dei dati dovrebbe essere basato sul valore, non su variabili o osservazioni. Un sistema non può privilegiare le osservazioni sulle variabili o le variabili sulle osservazioni; una modifica a un’osservazione è necessariamente una modifica a una variabile e viceversa.

Il terzo principio del controllo delle versioni dei dati è che i dati esistono indipendentemente dal loro formato. Se si modifica un valore di dati in un CSV rispetto a un albero JSON, si tratta di modifiche equivalenti al contenuto. In quanto tale, qualsiasi sistema di controllo della versione dovrebbe consentire agli utenti di interagire con i dati in qualsiasi formato di file che scelgono senza necessariamente utilizzare il formato di archiviazione dei dati sottostante.

Il quarto principio del controllo delle versioni dei dati è che la collaborazione è essenziale per la generazione e la gestione dei dati. Un sistema di controllo delle versioni dei dati deve essere nativamente collaborativo e registrare logicamente chi sta generando e modificando i dati.

Il quinto principio del controllo delle versioni dei dati è che le modifiche alla struttura dei dati devono essere registrate indipendentemente dai valori dei dati. Ordinamento delle osservazioni, disposizione delle colonne / variabili e disposizione delle righe come casi rispetto agli anni dei casi, ecc. (ossia., “wide “versus” long ” arrangements) sono caratteristiche strutturali di un set di dati, non caratteristiche dei dati di per sé. Questi sono importanti, ma un processo di versioning dei dati dovrebbe essere in grado di distinguere una modifica al contenuto di un set di dati da una modifica all’organizzazione o alla struttura di un set di dati e, in quest’ultimo caso, riconoscere correttamente come identico un set di dati disposto in due modi diversi.

Il sesto principio del controllo delle versioni dei dati è che i metadati sono importanti ma, come la struttura, devono essere gestiti separatamente dalle modifiche ai dati. Due set di dati identici con metadati diversi dovrebbero essere riconosciuti come identici al contenuto.

Conclusioni provvisorie

I dati devono essere memorizzati in modo chiave-valore, in cui una chiave arbitraria contiene un particolare valore di dati. Una mappatura collega quindi quei particolari valori di dati sia alle osservazioni che alle variabili, in modo che qualsiasi valutazione delle modifiche ai dati sia indipendente dal formato e dalla struttura. Come tale, una modifica a un valore viene registrata prima come una modifica a un valore, ma può essere riconosciuta secondariamente come una modifica simultanea sia a un’osservazione che a una variabile.

Qualsiasi interfaccia per un tale archivio chiave-valore dovrebbe avere una forma familiare e flessibile: gli utenti dovrebbero interagire con un sistema di versioning dei dati tramite qualsiasi modo utilizzino attualmente i dati (ad esempio, un editor di testo, un software di analisi dei dati, un’applicazione di fogli di calcolo, ecc.). Le modifiche devono essere registrate in un file master che può nativamente e immediatamente importare ed esportare in qualsiasi formato di file di dati (inclusi file delimitati, fogli di calcolo, XML, JSON, ecc.).

I sistemi di controllo delle versioni dei dati devono avere un sistema di commit più sofisticato di quello fornito dagli attuali sistemi di controllo delle versioni orientati al software. In particolare, i commit dovrebbero registrare non solo la modifica a un valore di dati, una struttura o metadati, ma anche informazioni strutturate che spieghino tale modifica, inclusi il motivo della modifica, l’origine o le origini del valore di dati e l’autore della modifica. In sostanza, sia i changeset che gli stati dei dati completi dovrebbero essere completamente citabili e contenere metadati rilevanti per le citazioni.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.