leeper / data-versioning

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

versiebeheer is een enorm onderdeel van reproduceerbaar onderzoek en open source softwareontwikkeling. Versiebeheer biedt een complete geschiedenis van een digitaal object (bijvoorbeeld een softwareprogramma, een onderzoeksproject, enz.) en, belangrijk, maakt het mogelijk om na te gaan welke wijzigingen zijn aangebracht aan dat object, wanneer die wijzigingen zijn aangebracht, en (met de juiste metadata) waarom die wijzigingen zijn aangebracht. Dit document bevat een aantal van mijn huidige denken over versiebeheer voor gegevens.

Achtergrondcontext

vooral in de sociale wetenschappen zijn onderzoekers afhankelijk van grote, openbare datasets (bijv. politiek, kwaliteit van de overheid, correlaties van oorlog, ANES, ESS, enz.) als bronmateriaal voor kwantitatief onderzoek. Deze datasets evolueren meestal (nieuwe gegevens worden in de loop van de tijd toegevoegd, correcties worden aangebracht aan gegevenswaarden, enz.) en nieuwe releases worden periodiek openbaar gemaakt. Soms zijn deze gegevens complexe gezamenlijke inspanningen (zie, bijvoorbeeld, kwaliteit van de overheid) en andere zijn openbare releases van single-institution gegevensverzameling inspanningen (bijvoorbeeld, ANES). Terwijl collaboratieve datasets een meer voor de hand liggende use case creëren voor versiebeheer, kunnen datasets van afzonderlijke instellingen ook worden verbeterd door versiebeheer. Dit is vooral belangrijk omdat oude versies van deze vitale datasets vaak niet worden gearchiveerd (bijvoorbeeld ANES) wat betekent dat het in wezen onmogelijk is om een eerdere versie van een bepaalde ANES dataset te herstellen nadat een nieuwe release heeft plaatsgevonden. Dit bericht is bedoeld om te sturen denken over hoe de creatie, curatie, revisie, en verspreiding van dit soort datasets te beheren. Hoewel de ideeën hier ook van toepassing kunnen zijn op hoe men denkt over het beheren van hun eigen gegevens, zijn ze waarschijnlijk meer van toepassing in het stadium van het maken van gegevens dan bij later gebruik van gegevens nadat een dataset in wezen volledig of bevroren is.

overzicht van bestaande Tools en benaderingen

het Open Data Institute heeft een mooie post waarin de uitdagingen worden beschreven van het gebruik van standaard softwaregeoriënteerde versiebeheersoftware (namelijk git) voor versiebeheer van gegevens. Het belangrijkste probleem is dat git, zoals bijna alle VC ‘ s, is ontworpen om veranderingen in regels in tekstbestanden te monitoren. Dit heeft veel zin voor code, maar ook voor artikelen, tekst, enz. Maar het begint minder logisch te worden voor digitale objecten waar een lijn geen zinvolle eenheid is. Dit wordt echt duidelijk wanneer we beginnen met de versie van iets als een komma-gescheiden waarden (CSV) bestand (zoals de ODI post beschrijft). Het veranderen van een enkel gegevensveld leidt tot een volledige verandering, hoewel slechts één cel daadwerkelijk is veranderd. Een soortgelijk probleem ontstaat in XML, JSON, of andere tekst gescheiden formaten (hoewel, merk op dat de Open Knowledge Foundation lijkt JSON als een opslagmodus te bevoordelen).

het gebruik van de linebreak \n als scheidingsteken om wijzigingen in een object te volgen werkt voor data. daff is een javascript tool die probeert om goed te maken voor die zwakte. Het biedt een diff (vergelijking van twee bestandsversies) die de tabelstructuur van veel gegevensbestanden respecteert door celspecifieke wijzigingen te markeren. Dit is echter geen volledig versiebeheersysteem, het is gewoon een diff tool die kan dienen als een nuttige add-on voor git.

een bericht op het blog van de Open Knowledge Foundation stelt dat er enige logica is aan lijngebaseerde wijzigingensets omdat een standaard CSV (of een gegevensbestand in tabelvorm) gewoonlijk een enkele waarneming op zijn eigen regel registreert. Line-based versiebeheer is dan zinvol voor het vastleggen van wijzigingen in observaties (waardoor rijen/observaties voorrang krijgen boven kolommen/variabelen).

dat probeert een “Git voor data” te zijn, maar de status van het project is een beetje onduidelijk, aangezien er niet erg actieve ontwikkeling is geweest op Github. Een Q / A op de Open Data StackExchange wijst naar een aantal andere bronnen voor data-geschikte Git alternatieven, maar er is niets uitgebreid.

Universal Numeric Fingerprint (UNF) biedt een potentiële strategie voor versiebeheer van gegevens. Inderdaad, dat is precies waarvoor het is ontworpen. Het is niet per se een versiebeheersysteem, maar het biedt een hash die nuttig kan zijn om te bepalen wanneer een dataset is gewijzigd. Het heeft een aantal leuke functies:

  • bestandsformaatonafhankelijk (dus beter dan een MD5)
  • kolomvolgorde onafhankelijk (een dataset waarin kolommen zijn geschud produceert dezelfde UNF hash)
  • verwerkt consistent floating point getallen (afronding en precisie problemen zijn probleemloos)maar UNF is niet perfect. De problemen zijn onder meer:
  • het is sorteergevoelig (een identieke dataset die rij gesorteerd is, produceert een andere UNF; waardoor kolommen/variabelen voorrang krijgen boven rijen/waarnemingen)
  • er is geen afhandeling van metagegevens (bijv.
  • het is vrij gevoelig voor gegevensstructuur (bijvoorbeeld “brede” en “lange” representaties van dezelfde dataset produceren verschillende UNFs)
  • het is geen versiebeheersysteem en geeft in wezen geen inzicht in wat er is veranderd, alleen dat er een verandering is opgetreden

Al deze hulpmiddelen richten zich ook op de gegevens zelf, in plaats van geassocieerde metagegevens (bijvoorbeeld het codeboek dat de gegevens beschrijft). Terwijl sommige data formaten (bijvoorbeeld, eigen formaten zoals Stata ‘ s .dta en SPSS ‘ s .sav) coderen deze metadata direct in het bestand, het is niet een gemeenschappelijk kenmerk van breed tekst gescheiden datastructuren. Soms worden codebooks aangepast onafhankelijk van gegevenswaarden en vice versa, maar het is eerder om te zien dat grote openbare datasets gedetailleerde informatie bieden over wijzigingen in de gegevens of het codeboek, behalve bij occasionele releases.

een andere grote uitdaging voor data versioning is dat bestaande tools versiebeheer niet goed zijn ontworpen om de herkomst te verwerken. Wanneer gegevens worden gegenereerd, opgeslagen of gewijzigd, heeft een software-georiënteerd versiebeheersysteem geen voor de hand liggend mechanisme om vast te leggen waarom waarden in een dataset zijn wat ze zijn of waarom er wijzigingen worden aangebracht in bepaalde waarden. Een commit-bericht kan deze informatie verschaffen, maar zodra een waarde opnieuw wordt gewijzigd, gaat de geschiedenis van wijzigingen in een bepaalde waarde verloren in de bredere geschiedenis van het gegevensbestand als geheel.

er bestaan dus duidelijk geen complete tools voor versiegegevens.

sommige principes van data Versioning

het eerste principe van data versioning is dat wijzigingen in data bronnen of verklaringen hebben. Een systeem van data versioning moet in staat zijn om data waarden, structuur, en metadata (en veranderingen aan die functies) te verbinden met verklaringen van die waarden of de veranderingen in waarden op het niveau van de waarde (in plaats van op het niveau van variabelen, waarnemingen, of bestanden).

het tweede principe is dat versiebeheer gebaseerd moet zijn op waarden, niet op variabelen of waarnemingen. Een systeem kan waarnemingen niet Voorrang geven boven variabelen of variabelen boven waarnemingen; een verandering in een waarneming is noodzakelijkerwijs een verandering in een variabele, en vice versa.

het derde principe van data versioning is dat gegevens onafhankelijk van hun formaat bestaan. Als men een gegevenswaarde in een CSV ten opzichte van een JSON-boom wijzigt, zijn dat inhoudelijke wijzigingen. Als zodanig moet elk systeem van versiebeheer gegevensgebruikers in staat stellen om te interageren met gegevens in welk bestandsformaat ze kiezen zonder noodzakelijkerwijs gebruik te maken van de onderliggende data-opslag formaat.

het vierde principe van data versioning is dat samenwerking essentieel is voor het genereren en cureren van data. Een systeem van data versioning moet native collaborative zijn en logischerwijs vastleggen wie data genereert en wijzigt.

het vijfde principe van data versioning is dat wijzigingen in de gegevensstructuur onafhankelijk van gegevenswaarden moeten worden geregistreerd. Sorteervolgorde van observaties, de rangschikking van kolommen / variabelen, en de rangschikking van rijen als cases versus case-years, enz. (namelijk., “brede “versus” lange ” arrangementen) zijn structurele kenmerken van een dataset, niet kenmerken van de gegevens op zich. Deze zijn belangrijk, maar een dataversieproces moet in staat zijn een verandering in de inhoud van een dataset te onderscheiden van een verandering in de organisatie of structuur van een dataset en, in het laatste geval, een dataset die op twee verschillende manieren is gerangschikt, correct als identiek te herkennen.

het zesde principe van data versioning is dat metagegevens belangrijk zijn, maar, net als structuur, gescheiden moeten worden behandeld van wijzigingen in gegevens. Twee identieke datasets met verschillende metadata moeten worden herkend als inhoud-identiek.

voorlopige conclusies

gegevens moeten worden opgeslagen op een sleutelwaarde-manier, wanneer een willekeurige sleutel een bepaalde gegevenswaarde bevat. Een mapping verbindt vervolgens die specifieke gegevenswaarden met zowel observaties als variabelen, zodat elke beoordeling van wijzigingen aan gegevens format-onafhankelijk en structuur-onafhankelijk zijn. Als zodanig wordt een verandering in een waarde eerst geregistreerd als een verandering in een waarde, maar kan in de tweede plaats worden herkend als een gelijktijdige verandering in zowel een waarneming als een variabele.

elke interface naar een dergelijke sleutelwaardeopslag moet in een vertrouwde en flexibele vorm beschikbaar zijn: gebruikers moeten interageren met een data versioning systeem via de manier waarop ze momenteel gegevens gebruiken (bijvoorbeeld een teksteditor, software voor gegevensanalyse, een spreadsheettoepassing, enz.). Wijzigingen moeten worden opgenomen in een hoofdbestand dat native en onmiddellijk kan importeren uit en exporteren naar elk gegevensbestand formaat (met inbegrip van gescheiden bestanden, spreadsheets, XML, JSON, enz.).

dataversiesystemen moeten een geavanceerder commit-systeem hebben dan dat van de huidige, softwaregeoriënteerde versiebeheersystemen. In het bijzonder moeten commits niet alleen de wijziging in een gegevenswaarde, structuur of metadata registreren, maar ook gestructureerde informatie die die wijziging uitlegt, inclusief de reden voor de wijziging, de bron(nen) van de gegevenswaarde en de auteur van de wijziging. In wezen moeten zowel wijzigingensets als toestanden van de volledige gegevens volledig citeerbaar zijn en citatie-relevante metagegevens bevatten.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.