leeper/data-versioning

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

Le contrôle de version est une grande partie de la recherche reproductible et du développement de logiciels open source. La gestion des versions fournit un historique complet de certains objets numériques (par exemple, un logiciel, un projet de recherche, etc.) et, surtout, permet de tracer les modifications apportées à cet objet, quand ces modifications ont été apportées et (avec les métadonnées appropriées) pourquoi ces modifications ont été apportées. Ce document contient une partie de ma réflexion actuelle sur le contrôle de version pour les données.

Contexte

En particulier dans les sciences sociales, les chercheurs dépendent de grands ensembles de données publiques (p. ex. Politique, Qualité du gouvernement, Corrélats de la guerre, ANES, ESS, etc.) comme matériau de base pour la recherche quantitative. Ces ensembles de données évoluent généralement (de nouvelles données sont ajoutées au fil du temps, des corrections sont apportées aux valeurs des données, etc.) et les nouvelles versions sont périodiquement rendues publiques. Parfois, ces données sont des efforts de collaboration complexes (voir, par exemple, Qualité du gouvernement) et d’autres sont des communiqués publics des efforts de collecte de données d’une seule institution (p. ex., ANES). Alors que les ensembles de données collaboratifs créent un cas d’utilisation plus évident pour le contrôle de version, les ensembles de données d’une seule institution peuvent également être améliorés par le contrôle de version. Ceci est particulièrement important car les anciennes versions de ces ensembles de données vitaux ne sont souvent pas archivées (par exemple, ANES), ce qui signifie qu’il est essentiellement impossible de récupérer une version antérieure d’un ensemble de données ANES donné après qu’une nouvelle version a eu lieu. Cet article vise à orienter la réflexion sur la façon de gérer la création, la conservation, la révision et la diffusion de ce type d’ensembles de données. Bien que les idées ici puissent également s’appliquer à la façon dont on pense à la gestion de ses propres données, elles s’appliquent probablement davantage au stade de la création des données qu’à l’utilisation ultérieure des données après qu’un ensemble de données est essentiellement complet ou gelé.

Revue des outils et approches existants

L’Open Data Institute a un article intéressant décrivant les défis de l’utilisation d’un logiciel de contrôle de version standard et orienté logiciel (à savoir git) pour le contrôle de version des données. Le problème principal est que git, comme presque tous les VC, est conçu pour surveiller les modifications apportées aux lignes dans les fichiers texte. Cela a beaucoup de sens pour le code, ainsi que pour les articles, le texte, etc. Mais cela commence à avoir moins de sens pour les objets numériques où une ligne n’est pas une unité significative. Cela devient vraiment clair lorsque nous commençons à versionner quelque chose comme un fichier CSV (valeurs séparées par des virgules) (comme le décrit le post ODI). La modification d’un seul champ de données entraîne une modification complète de la ligne, même si une seule cellule a réellement changé. Un problème similaire apparaît dans XML, JSON ou d’autres formats délimités par du texte (cependant, notez que l’Open Knowledge Foundation semble privilégier JSON comme mode de stockage).

L’utilisation du saut de ligne \n comme délimiteur pour suivre les modifications apportées à un objet fonctionne pour les données. daff est un outil javascript qui tente de compenser cette faiblesse. Il fournit un diff (comparaison de deux versions de fichiers) qui respecte la structure tabulaire de nombreux fichiers de données en mettant en évidence les modifications spécifiques aux cellules. Ce n’est pas un système de contrôle de version complet, cependant, c’est simplement un outil de diff qui peut servir d’add-on utile à git.

Un article sur le blog de l’Open Knowledge Foundation soutient qu’il existe une certaine logique pour les ensembles de modifications basés sur des lignes, car un fichier CSV standard (ou tout fichier de données tabulaires) enregistre généralement une seule observation sur sa propre ligne. Le contrôle de version basé sur une ligne est alors logique pour enregistrer les modifications apportées aux observations (privilégiant ainsi les lignes / observations par rapport aux colonnes / variables).

dat vise à essayer d’être un « git pour les données » mais le statut du projet est un peu flou, étant donné qu’il n’y a pas eu de développement très actif sur Github. Un Q /A sur l’Open Data StackExchange pointe vers d’autres ressources pour des alternatives git adaptées aux données, mais il n’y a rien de complet.

L’empreinte numérique universelle (UNF) fournit une stratégie potentielle pour le contrôle de version des données. En effet, c’est précisément ce pour quoi il a été conçu. Ce n’est pas un système de contrôle de version en soi, mais il fournit un hachage qui peut être utile pour déterminer quand un ensemble de données a changé. Il a quelques fonctionnalités intéressantes:

  • Indépendant du format de fichier (donc meilleur qu’un MD5)
  • Indépendant de l’ordre des colonnes (un ensemble de données où les colonnes ont été mélangées produit le même hachage UNF)
  • Gère systématiquement les nombres à virgule flottante (les problèmes d’arrondi et de précision ne posent aucun problème) Mais, UNF n’est pas parfait. Les problèmes incluent :
  • Il est sensible au tri (un ensemble de données identique trié par ligne produit un UNF différent ; privilégiant ainsi les colonnes /variables par rapport aux lignes /observations)
  • Il n’y a pas de gestion des métadonnées (par ex., les noms de variables ne font pas partie du hachage)
  • Il est assez sensible à la structure des données (par exemple, les représentations « larges » et « longues » du même ensemble de données produisent des UNFS différents)
  • Ce n’est pas un système de contrôle de version et ne fournit essentiellement aucune idée de ce qui a changé, seulement qu’un changement s’est produit

Tous ces outils se concentrent également sur les données elles-mêmes, plutôt que sur les métadonnées associées (par exemple, le livre de codes décrivant données). Alors que certains formats de données (par exemple, des formats propriétaires comme ceux de Stata.dta et SPSS.sav) codent ces métadonnées directement dans le fichier, ce n’est pas une caractéristique commune des structures de données largement délimitées par du texte. Parfois, les livres de codes sont modifiés indépendamment des valeurs des données et vice versa, mais il s’agit plutôt de voir de grands ensembles de données publics fournir des informations détaillées sur les modifications apportées aux données ou au livre de codes, sauf dans des versions occasionnelles.

Un autre défi majeur pour le contrôle des versions de données est que le contrôle de version des outils existants n’est pas bien conçu pour gérer la provenance. Lorsque des données sont générées, stockées ou modifiées, un système de contrôle de version orienté logiciel ne dispose d’aucun mécanisme évident pour enregistrer pourquoi les valeurs d’un ensemble de données sont ce qu’elles sont ou pourquoi des modifications sont apportées à des valeurs particulières. Un message de validation peut fournir ces informations, mais dès qu’une valeur est à nouveau modifiée, l’historique des modifications apportées à une valeur particulière est perdu dans l’historique plus large du fichier de données dans son ensemble.

Il n’existe donc clairement aucun outil complet pour les données de versionnage.

Quelques principes du versionnage des données

Le premier principe du versionnage des données est que les modifications apportées aux données ont des sources ou des explications. Un système de gestion des versions de données doit pouvoir connecter les valeurs de données, la structure et les métadonnées (et les modifications apportées à ces fonctionnalités) aux explications de ces valeurs ou aux modifications apportées aux valeurs au niveau de la valeur (plutôt qu’au niveau des variables, des observations ou des fichiers).

Le deuxième principe est que la gestion des versions des données doit être basée sur la valeur, et non sur les variables ou les observations. Un système ne peut pas privilégier les observations sur les variables ou les variables sur les observations ; une modification d’une observation est nécessairement une modification d’une variable, et vice versa.

Le troisième principe du versionnage des données est que les données existent indépendamment de leur format. Si l’on modifie une valeur de données dans un CSV par rapport à une arborescence JSON, il s’agit de modifications équivalentes au contenu. En tant que tel, tout système de contrôle de version devrait permettre aux utilisateurs de données d’interagir avec les données dans le format de fichier qu’ils choisissent sans nécessairement utiliser le format de stockage de données sous-jacent.

Le quatrième principe du versionnage des données est que la collaboration est essentielle à la génération et à la conservation des données. Un système de gestion des versions de données doit être nativement collaboratif et enregistrer logiquement qui génère et modifie les données.

Le cinquième principe du versionnage des données est que les modifications apportées à la structure des données doivent être enregistrées indépendamment des valeurs des données. Trier l’ordre des observations, la disposition des colonnes/variables et la disposition des lignes en tant que cas par rapport aux années-cas, etc. (c.-à-d., arrangements « larges » contre « longs ») sont des caractéristiques structurelles d’un ensemble de données, pas des caractéristiques des données en soi. Ceux-ci sont importants, mais un processus de gestion de versions de données devrait pouvoir distinguer une modification du contenu d’un ensemble de données d’une modification de l’organisation ou de la structure d’un ensemble de données et, dans ce dernier cas, reconnaître correctement comme identique un ensemble de données organisé de deux manières différentes.

Le sixième principe du versionnage des données est que les métadonnées sont importantes mais, comme la structure, doivent être traitées séparément des modifications apportées aux données. Deux ensembles de données identiques avec des métadonnées différentes doivent être reconnus comme identiques au contenu.

Conclusions provisoires

Les données doivent être stockées de manière clé-valeur, lorsqu’une clé arbitraire contient une valeur de données particulière. Un mappage relie ensuite ces valeurs de données particulières aux observations et aux variables, de sorte que toute évaluation des modifications apportées aux données soit indépendante du format et de la structure. En tant que tel, une modification d’une valeur est enregistrée d’abord comme une modification d’une valeur, mais peut être reconnue secondairement comme une modification simultanée à la fois d’une observation et d’une variable.

Toute interface vers un tel magasin clé-valeur doit se présenter sous une forme familière et flexible : les utilisateurs doivent interagir avec un système de gestion des versions de données de la manière dont ils utilisent actuellement les données (par exemple, un éditeur de texte, un logiciel d’analyse de données, un tableur, etc.). Les modifications doivent être enregistrées dans un fichier maître qui peut nativement et immédiatement importer et exporter vers n’importe quel format de fichier de données (y compris les fichiers délimités, les feuilles de calcul, XML, JSON, etc.).

Les systèmes de gestion des versions de données doivent disposer d’un système de validation plus sophistiqué que celui fourni par les systèmes actuels de contrôle de version orientés logiciel. En particulier, les validations doivent enregistrer non seulement la modification d’une valeur de données, d’une structure ou de métadonnées, mais également des informations structurées expliquant cette modification, y compris la raison de la modification, la ou les sources de la valeur de données et l’auteur de la modification. Essentiellement, les ensembles de modifications et les états des données complètes doivent être entièrement citables et comporter des métadonnées pertinentes pour les citations.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.