leeper / control de versiones de datos

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

El control de versiones es una gran parte de la investigación reproducible y el desarrollo de software de código abierto. El control de versiones proporciona un historial completo de algún objeto digital (por ejemplo, un programa de software, un proyecto de investigación, etc.).) y, lo que es más importante, permite rastrear qué cambios se han realizado en ese objeto, cuándo se hicieron esos cambios y (con los metadatos apropiados) por qué se hicieron esos cambios. Este documento contiene algunas de mis ideas actuales sobre el control de versiones para datos.

Contexto de fondo

Especialmente en las ciencias sociales, los investigadores dependen de grandes conjuntos de datos públicos (por ejemplo, Política, Calidad del Gobierno, Correlatos de Guerra, ANES, ESS, etc.).) como material de referencia para la investigación cuantitativa. Estos conjuntos de datos suelen evolucionar (se añaden nuevos datos con el tiempo, se hacen correcciones a los valores de los datos, etc.).) y los nuevos lanzamientos se hacen públicos periódicamente. A veces, estos datos son esfuerzos de colaboración complejos (véase, por ejemplo, Calidad del gobierno) y otros son publicaciones públicas de esfuerzos de recopilación de datos de una sola institución (por ejemplo, ANES). Si bien los conjuntos de datos colaborativos crean un caso de uso más obvio para el control de versiones, los conjuntos de datos de una sola institución también pueden mejorarse mediante el control de versiones. Esto es particularmente importante porque las versiones antiguas de estos conjuntos de datos vitales a menudo no se archivan (por ejemplo, ANES), lo que significa que es esencialmente imposible recuperar una versión anterior de un conjunto de datos ANES dado después de que se haya producido una nueva versión. Esta publicación está destinada a orientar el pensamiento sobre cómo administrar la creación, la curación, la revisión y la diseminación de este tipo de conjuntos de datos. Si bien las ideas aquí también pueden aplicarse a cómo uno piensa sobre la administración de sus propios datos, probablemente se apliquen más en la etapa de creación de datos que en el uso posterior de los datos después de que un conjunto de datos esté esencialmente completo o congelado.

Revisión de Herramientas y enfoques existentes

El Open Data Institute tiene un bonito post que describe los desafíos de usar software de control de versiones estándar orientado al software (a saber, git) para el control de versiones de datos. El problema principal es que git, como casi todos los VCS, está diseñado para monitorear los cambios en las líneas de los archivos de texto. Esto tiene mucho sentido para el código, así como para artículos, texto, etc. Pero comienza a tener menos sentido para objetos digitales donde una línea no es una unidad significativa. Esto se vuelve muy claro cuando empezamos a ver una versión de algo así como un archivo de valores separados por comas (CSV) (como describe la publicación ODI). Cambiar un solo campo de datos conduce a un cambio de línea completa, a pesar de que solo una celda realmente cambió. Un problema similar surge en XML, JSON u otros formatos delimitados por texto (sin embargo, tenga en cuenta que Open Knowledge Foundation parece favorecer a JSON como modo de almacenamiento).

Usar el salto de línea \n como delimitador para rastrear los cambios en un objeto funciona para los datos. daff es una herramienta de javascript que intenta compensar esa debilidad. Proporciona un diff (comparación de dos versiones de archivo) que respeta la estructura tabular de muchos archivos de datos resaltando los cambios específicos de la celda. Sin embargo, este no es un sistema de control de versiones completo, es simplemente una herramienta de diferencias que puede servir como un complemento útil para git.

Un post en el blog de Open Knowledge Foundation argumenta que hay cierta lógica en los conjuntos de cambios basados en líneas porque un CSV estándar (o cualquier archivo de datos tabulares) típicamente registra una sola observación en su propia línea. El control de versiones basado en líneas tiene sentido para registrar los cambios en las observaciones (privilegiando así las filas/observaciones sobre las columnas/variables).

dat intenta ser un «git para datos», pero el estado del proyecto no está claro, dado que no ha habido un desarrollo muy activo en Github. Una pregunta sobre Open Data StackExchange apunta a algunos recursos adicionales para alternativas de git apropiadas para datos, pero no hay nada completo.

Huella Digital Numérica Universal (UNF) proporciona una estrategia potencial para el control de versiones de datos. De hecho, eso es específicamente para lo que fue diseñado. No es un sistema de control de versiones per se, pero proporciona un hash que puede ser útil para determinar cuándo ha cambiado un conjunto de datos. Tiene algunas características agradables:

  • Independiente del formato de archivo (así que mejor que un MD5)
  • Independiente del orden de las columnas (un conjunto de datos donde las columnas se han barajado produce el mismo hash UNF)
  • Maneja de forma consistente los números de coma flotante (los problemas de redondeo y precisión no son problemáticos), pero UNF no es perfecto. Los problemas incluyen:
  • Es sensible a la ordenación (un conjunto de datos idéntico que está ordenado por filas produce un UNF diferente; por lo tanto, privilegia columnas/variables sobre filas/observaciones)
  • No hay manejo de metadatos (p. ej.
  • Es bastante sensible a la estructura de datos (por ejemplo, las representaciones «anchas» y «largas» del mismo conjunto de datos producen diferentes UNFs)
  • No es un sistema de control de versiones y esencialmente no proporciona información sobre lo que cambió, solo que se produjo un cambio

Todas estas herramientas también se centran en los datos en sí, en lugar de los metadatos asociados (por ejemplo, el libro de códigos que describe datos). Mientras que algunos formatos de datos (por ejemplo, formatos propietarios como Stata .dta y SPSS .sav) codifica estos metadatos directamente en el archivo, no es una característica común de las estructuras de datos ampliamente delimitadas por texto. A veces, los cuadernos de códigos se modifican independientemente de los valores de los datos y viceversa, pero es más bien para ver grandes conjuntos de datos públicos que proporcionan información detallada sobre los cambios en los datos o en el libro de códigos, excepto en versiones ocasionales.

Otro desafío importante para el control de versiones de datos es que el control de versiones de las herramientas existentes no está bien diseñado para manejar la procedencia. Cuando se generan, almacenan o modifican datos, un sistema de control de versiones orientado al software no tiene un mecanismo obvio para registrar por qué los valores en un conjunto de datos son lo que son o por qué se realizan cambios en valores particulares. Un mensaje de confirmación puede proporcionar esta información, pero tan pronto como un valor se cambia de nuevo, el historial de cambios a un valor en particular se pierde en el historial más amplio del archivo de datos en su conjunto.

Por lo tanto, es evidente que no existen herramientas completas para el control de versiones de datos.

Algunos principios del control de versiones de datos

El primer principio del control de versiones de datos es que los cambios en los datos tienen fuentes o explicaciones. Un sistema de control de versiones de datos debe poder conectar los valores de datos, la estructura y los metadatos (y los cambios en esas características) con explicaciones de esos valores o los cambios en los valores a nivel de valor (en lugar de a nivel de variables, observaciones o archivos).

El segundo principio es que el control de versiones de datos debe basarse en valores, no en variables u observaciones. Un sistema no puede privilegiar observaciones sobre variables o variables sobre observaciones; un cambio a una observación es necesariamente un cambio a una variable, y viceversa.

El tercer principio del control de versiones de datos es que los datos existen independientemente de su formato. Si se cambia un valor de datos en un árbol CSV en comparación con un árbol JSON, se trata de cambios equivalentes al contenido. Como tal, cualquier sistema de control de versiones debe permitir a los usuarios de datos interactuar con los datos en cualquier formato de archivo que elijan sin utilizar necesariamente el formato de almacenamiento de datos subyacente.

El cuarto principio del control de versiones de datos es que la colaboración es esencial para la generación y conservación de datos. Un sistema de control de versiones de datos debe ser colaborativo de forma nativa y registrar lógicamente quién está generando y modificando datos.

El quinto principio del control de versiones de datos es que los cambios en la estructura de datos deben registrarse independientemente de los valores de los datos. Ordenar el orden de las observaciones, la disposición de columnas / variables y la disposición de filas como casos versus años de caso, etc. (i. e., arreglos» amplios «versus» largos») son características estructurales de un conjunto de datos, no características de los datos per se. Estos son importantes, pero un proceso de control de versiones de datos debe ser capaz de distinguir un cambio en el contenido de un conjunto de datos de un cambio en la organización o estructura de un conjunto de datos y, en este último caso, reconocer correctamente como idéntico un conjunto de datos que está organizado de dos maneras diferentes.

El sexto principio del control de versiones de datos es que los metadatos importan, pero, al igual que la estructura, deben manejarse por separado de los cambios en los datos. Dos conjuntos de datos idénticos con metadatos diferentes deben reconocerse como contenidos idénticos.

Conclusiones provisionales

Los datos deben almacenarse de manera clave-valor, cuando una clave arbitraria contenga un valor de datos particular. A continuación, un mapeo conecta esos valores de datos particulares con observaciones y variables, de modo que cualquier evaluación de los cambios en los datos sea independiente del formato y de la estructura. Como tal, un cambio a un valor se registra primero como un cambio a un valor, pero se puede reconocer secundariamente como un cambio simultáneo tanto a una observación como a una variable.

Cualquier interfaz para un almacén de clave-valor de este tipo debe venir de una forma familiar y flexible: los usuarios deben interactuar con un sistema de control de versiones de datos a través de cualquier forma en que utilicen los datos actualmente (por ejemplo, un editor de texto, un software de análisis de datos, una aplicación de hoja de cálculo, etc.).). Los cambios deben registrarse en un archivo maestro que pueda importar y exportar de forma nativa e inmediata a cualquier formato de archivo de datos (incluidos archivos delimitados, hojas de cálculo, XML, JSON, etc.).).

Los sistemas de control de versiones de datos deben tener un sistema de confirmación más sofisticado que el proporcionado por los sistemas de control de versiones actuales orientados al software. En particular, las confirmaciones deben registrar no solo el cambio en un valor de datos, estructura o metadatos, sino también información estructurada que explique ese cambio, incluida la razón del cambio, la fuente o fuentes del valor de datos y el autor del cambio. En esencia, tanto los conjuntos de cambios como los estados de los datos completos deben ser totalmente citables y llevar metadatos relevantes para las citas.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.