leeper / data-versioning

(C) Thomas J. Leeper (2015), licensed CC-BY

Version control is a huge part of reproducible research and open source software development. O Versioning fornece uma história completa de algum objeto digital (por exemplo, um programa de software, um projeto de pesquisa, etc.) e, o que é importante, permite rastrear as alterações feitas a esse objeto, quando essas alterações foram feitas, e (com os metadados apropriados) por que essas alterações foram feitas. Este documento contém alguns dos meus pensamentos atuais sobre o controle de versão para os dados.

Contexto

Especialmente nas ciências sociais, os pesquisadores dependem de grandes conjuntos de dados públicos (por exemplo, Política, Qualidade de Governo, Correlatos de Guerra, ANES, ESS, etc.) como material de base para a investigação quantitativa. Estes conjuntos de dados evoluem tipicamente (novos dados são adicionados ao longo do tempo, correções são feitas aos valores dos dados, etc.) e os novos lançamentos são publicados periodicamente. Por vezes, estes dados são complexos esforços de colaboração (ver, por exemplo, Qualidade do Governo) e outros são lançamentos públicos de esforços de coleta de dados de uma única instituição (por exemplo, ANES). Embora conjuntos de dados colaborativos criem um caso de uso mais óbvio para o controle de versões, conjuntos de dados de uma instituição também podem ser melhorados pelo controle de versões. Isto é particularmente importante porque as versões antigas destes conjuntos de dados vitais muitas vezes não são arquivadas (por exemplo, ANES) significando que é essencialmente impossível recuperar uma versão anterior de um dado conjunto de dados ANES após uma nova versão ter ocorrido. Este post destina-se a orientar o pensamento sobre como gerir a criação, Curação, revisão e disseminação deste tipo de conjuntos de dados. Embora as ideias aqui possam também aplicar-se à forma como se pensa gerir os seus próprios dados, provavelmente aplicam-se mais na fase de criação de dados do que posteriormente a utilização de dados depois de um conjunto de Dados estar essencialmente completo ou congelado.

Review of Existing Tools and Approaches

The Open Data Institute has a nice post outlining the challenges of using standard, software-oriented version control software (namely, git) for version control of data. A questão principal é que o git, como quase todos os VCS, é projetado para monitorar as alterações às linhas em arquivos de texto. Isso faz muito sentido para o código, bem como para artigos, texto, etc. Mas começa a fazer menos sentido para objetos digitais onde uma linha não é uma unidade significativa. Isto torna-se realmente claro quando começamos a versão algo como um arquivo de valores separados por vírgulas (CSV) (como o post ODI descreve). Mudar um único campo de dados leva a uma mudança de linha completa, mesmo que apenas uma célula realmente mudou. Um problema semelhante emerge em XML, JSON, ou outros formatos delimitados por texto (embora, note que a Open Knowledge Foundation parece favorecer JSON como um modo de armazenamento).

usando o linebreak \n como delimitador para acompanhar as alterações a um objecto, funciona para os dados. daff é uma ferramenta de javascript que tenta compensar essa fraqueza. Ele fornece um diff (comparação de duas versões de arquivos) que respeita a estrutura tabular de muitos arquivos de dados, destacando alterações específicas de células. Este não é um sistema de controle de Versão completo, no entanto, é simplesmente uma ferramenta diff que pode servir como um complemento útil para o git.

Um post sobre a Open Knowledge Foundation blog argumenta que há alguma lógica para a linha de base changesets porque um padrão CSV (ou qualquer tabular arquivo de dados), normalmente, os registros de uma única observação em sua própria linha. O controlo de Versão baseado em linhas faz sentido para registar alterações nas observações (privilegiando assim linhas/observações sobre colunas/variáveis).

dat tem como objetivo tentar ser um “git para dados”, mas o status do projeto é um pouco incerto, dado que não tem havido um desenvolvimento muito ativo no Github. Um Q / A no StackExchange de Dados Abertos aponta para alguns recursos adicionais para alternativas git adequadas a dados, mas não há nada abrangente.

a impressão digital universal numérica (UNF) fornece uma estratégia potencial para o controle de versão dos dados. De facto, foi especificamente para isso que foi projectado. Não é um sistema de controle de versão per se, mas fornece um hash que pode ser útil para determinar quando um conjunto de dados mudou. Tem algumas características agradáveis:

  • formato de Arquivo independente (por isso, é melhor do que um MD5)
  • ordem das Colunas independentes (um conjunto de dados em que as colunas foram embaralhadas produz o mesmo UNF hash)
  • Consistentemente lida com números em ponto flutuante (arredondamento e precisão problemas são problemas), Mas, UNF não é perfeito. Os problemas incluem:
  • é uma espécie sensível (idênticas de um conjunto de dados que é a linha classificados produz um diferente UNF; assim, privilegiando colunas/variáveis através de linhas/observações)
  • não Há manipulação de metadados (por exemplo,, nomes de variáveis não são parte do hash)
  • é bastante sensível à estrutura de dados (por exemplo, “grande” e “longo” representações do mesmo conjunto de dados de produzir diferentes UNFs)
  • não é um sistema de controle de versão e oferece praticamente nenhum insights sobre o que mudou, só que uma mudança ocorreu

Todas essas ferramentas também incidem sobre os dados em si, ao invés de incluir metadados associados (por exemplo, o livro de códigos que descrevem os dados). Enquanto alguns formatos de dados (por exemplo, formatos proprietários como o Stata .dta e SPSS’s.sav) codificar esses metadados diretamente no arquivo, não é uma característica comum de estruturas de dados amplamente delimitadas pelo texto. Por vezes, os livros de código são modificados independentemente dos valores dos dados e vice-versa, mas é preferível ver grandes conjuntos de dados públicos fornecerem informação detalhada sobre alterações nos dados ou no livro de códigos, excepto em lançamentos ocasionais.

outro grande desafio para a versão de dados é que o controle de versão de ferramentas existentes não são bem projetados para lidar com a proveniência. Quando os dados são gerados, armazenados ou modificados, um sistema de controle de versão orientado para software não tem nenhum mecanismo óbvio para registrar Por que os valores em um conjunto de dados são o que eles são ou por que as mudanças são feitas para valores particulares. Uma mensagem de commit pode fornecer esta informação, mas assim que um valor é alterado novamente, o histórico de mudanças a um determinado valor são perdidos no histórico mais amplo do arquivo de dados como um todo.

Portanto, não existem claramente ferramentas completas para dados de versão.

Some Principles of Data Versioning

The first principle of data versioning is that changes to data have sources or explanations. Um sistema de versionamento de dados deve ser capaz de conectar os valores de dados, estrutura e metadados (e alterações a essas características) para explicações desses valores ou as mudanças de valores ao nível de valor (em vez de ao nível de variáveis, observações ou arquivos).

o segundo princípio é que a versionação de dados deve ser baseada no valor, não na variável ou na observação. Um sistema não pode privilegiar observações sobre variáveis ou variáveis sobre observações; uma mudança para uma observação é necessariamente uma mudança para uma variável, e vice-versa.

o terceiro princípio de versionamento de dados é que os dados existem independentemente de seu formato. Se alguém muda um valor de dados em um CSV versus uma árvore JSON, essas são alterações equivalentes a conteúdo. Como tal, qualquer sistema de controle de Versão deve permitir que os usuários de dados interajam com os dados em qualquer formato de arquivo que eles escolherem sem necessariamente usar o formato de armazenamento de dados subjacente.

o quarto princípio de versionamento de dados é que a colaboração é essencial para a geração e Curação de dados. Um sistema de versionamento de dados deve ser nativamente colaborativo e logicamente registrar quem está gerando e modificando dados.

O quinto princípio da versionação de dados é que as alterações na estrutura de dados devem ser registadas independentemente dos valores dos dados. Ordem de ordenação de observações, o arranjo de colunas/variáveis, e o arranjo de linhas como casos versus casos-anos, etc. (seja., “wide “versus” long ” arrangements) são características estruturais de um conjunto de dados, não características dos dados em si. Estes são importantes, mas um processo de versionamento de dados deve ser capaz de distinguir uma mudança para o conteúdo de um conjunto de dados de uma mudança para a organização ou estrutura de um conjunto de dados e, neste último caso, reconhecer corretamente como idêntico um conjunto de dados que é organizado de duas maneiras diferentes.

o sexto princípio da versionação de dados é que os metadados são importantes, mas, tal como a estrutura, devem ser tratados separadamente das alterações aos dados. Dois conjuntos de dados idênticos com metadados diferentes devem ser reconhecidos como conteúdos idênticos.

conclusões preliminares

Os dados devem ser armazenados de uma forma de valor-chave, onde uma chave arbitrária contém um determinado valor de dados. Um mapeamento então conecta esses valores de dados particulares a observações e variáveis, de modo que qualquer avaliação de alterações aos dados são independentes do formato e da estrutura. Como tal, uma mudança para um valor é registrada primeiro como uma mudança para um valor, mas pode ser secundariamente reconhecida como uma mudança simultânea para uma observação e uma variável.

qualquer interface para tal loja de valores-chave deve vir de uma forma familiar e flexível: os usuários devem interagir com um sistema de versionamento de dados através de qualquer maneira que eles atualmente usam dados (por exemplo, um editor de texto, software de análise de dados, uma aplicação de planilha, etc.). As alterações devem ser registadas num ficheiro principal que possa importar e exportar de forma nativa e imediata de qualquer formato de ficheiro de dados (incluindo ficheiros delimitados, folhas de cálculo, XML, JSON, etc.).).

Os sistemas de versionamento de dados devem ter um sistema de commit mais sofisticado do que o fornecido pelos sistemas de controle de versões atuais e orientados por software. Em particular, os commits devem registrar não só a mudança para um valor de dados, estrutura ou metadados, mas também informações estruturadas que expliquem essa mudança, incluindo a razão para a mudança, A(S) Fonte (s) do valor dos dados, e o autor da mudança. No essencial, tanto os conjuntos de alterações como os estados dos dados completos devem ser totalmente passíveis de processamento e conter metadados relevantes para a citação.

Deixe uma resposta

O seu endereço de email não será publicado.