leeper / data-versioning

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

Version control a reprodukálható kutatás és a nyílt forráskódú szoftverek fejlesztésének hatalmas része. A verziószámozás egy digitális objektum teljes történetét tartalmazza (pl. egy szoftverprogram, egy kutatási projekt stb.), és ami a legfontosabb, lehetővé teszi, hogy nyomon követhessük, milyen változások történtek az objektumon, mikor történtek ezek a változások, és (a megfelelő metaadatokkal) miért történtek ezek a változások. Ez a dokumentum tartalmazza az adatok verziókezelésével kapcsolatos jelenlegi gondolkodásomat.

Háttérkörnyezet

különösen a társadalomtudományokban a kutatók nagy, nyilvános adatkészletektől függenek (pl.) a kvantitatív kutatás forrásanyagaként. Ezek az adatkészletek általában fejlődnek (idővel új adatok kerülnek hozzáadásra, az adatértékek korrekciói stb.) és az új kiadásokat rendszeresen nyilvánosságra hozzák. Néha ezek az adatok összetett együttműködési erőfeszítések (lásd például a kormányzat minőségét), mások pedig egy intézmény adatgyűjtési erőfeszítéseinek (például ANES) nyilvános közzététele. Míg az együttműködő adatkészletek nyilvánvalóbb felhasználási esetet hoznak létre a verziókezeléshez, az egy intézményből álló adatkészletek javíthatók a verziókezeléssel is. Ez különösen azért fontos, mert ezeknek a létfontosságú adatkészleteknek a régi kiadásait gyakran nem archiválják (például ANES), ami azt jelenti, hogy lényegében lehetetlen helyreállítani egy adott ANES adatkészlet korábbi verzióját egy új kiadás bekövetkezése után. Ez a bejegyzés célja, hogy irányítsa az ilyen típusú adatkészletek létrehozásának, gondozásának, felülvizsgálatának és terjesztésének kezelését. Míg az itt szereplő ötletek arra is vonatkozhatnak, hogy miként gondolkodnak a saját adataik kezeléséről, valószínűleg inkább az adatok létrehozásának szakaszában vonatkoznak, mint a későbbi adathasználatra, miután az adatkészlet lényegében teljes vagy befagyott.

a meglévő eszközök és megközelítések áttekintése

Az Open Data Institute egy szép bejegyzéssel ismerteti a szabványos, szoftver-orientált verziókezelő szoftver (nevezetesen a git) használatának kihívásait az adatok verziókezeléséhez. A fő kérdés az, hogy a git, mint szinte minden VC, a szöveges fájlok sorainak változásainak figyelemmel kísérésére szolgál. Ennek sok értelme van a kódnak, valamint a cikkeknek, szövegeknek stb. De kezd kevésbé értelmesnek lenni a digitális objektumok esetében, ahol a vonal nem értelmes egység. Ez akkor válik igazán világossá, amikor elkezdünk valami olyan verziót készíteni, mint egy vesszővel elválasztott értékek (CSV) fájl (ahogy az ODI bejegyzés leírja). Egyetlen adatmező módosítása teljes sorváltozáshoz vezet, annak ellenére, hogy valójában csak egy cella változott. Hasonló probléma merül fel XML, JSON, vagy más szöveggel tagolt formátumok (bár vegye figyelembe, hogy az Open Knowledge Foundation úgy tűnik, hogy a JSON-t támogatja tárolási módként).

A \n sortörés használata határolóként az objektum változásainak nyomon követéséhez működik az adatok esetében. a daff egy javascript eszköz, amely megpróbálja pótolni ezt a gyengeséget. Ez biztosítja a diff (két fájlverzió összehasonlítása), amely tiszteletben tartja számos adatfájl táblázatos szerkezetét a cellaspecifikus változások kiemelésével. Ez nem egy teljes verziókezelő rendszer, bár egyszerűen egy diff eszköz, amely hasznos kiegészítőként szolgálhat a git-hez.

Az Open Knowledge Foundation blog egyik bejegyzése azt állítja, hogy van némi logika a vonalalapú váltókészletekben, mert egy szabványos CSV (vagy bármely táblázatos adatfájl) általában egyetlen megfigyelést rögzít a saját vonalán. A vonalalapú verzióvezérlésnek akkor van értelme a megfigyelések változásainak rögzítésére (ezáltal a sorok/megfigyelések kiváltsága az oszlopok/változók felett).

a dat célja, hogy “Git for data” legyen, de a projekt állapota kissé tisztázatlan, mivel a Github-on nem volt túl aktív fejlesztés. A nyílt adatok cseréjére vonatkozó Q/A rámutat néhány további forrásra az adatoknak megfelelő git alternatívákhoz, de nincs semmi átfogó.

Az univerzális numerikus ujjlenyomat (UNF) potenciális stratégiát biztosít az adatok verziókezeléséhez. Valóban, pontosan erre tervezték. Ez önmagában nem verziókezelő rendszer, de tartalmaz egy kivonatot, amely hasznos lehet annak meghatározásához, hogy egy adatkészlet megváltozott-e. Van néhány szép tulajdonsága:

  • fájlformátum független (tehát jobb, mint egy MD5)
  • Oszloprend független (olyan adatkészlet, ahol az oszlopokat összekeverik, ugyanazt az UNF kivonatot eredményezi)
  • következetesen kezeli a lebegőpontos számokat (a kerekítési és pontossági problémák problémamentesek), de az UNF nem tökéletes. A problémák a következők:
  • rendezésre érzékeny (egy azonos adatkészlet, amely sorrendezett, eltérő UNF-et eredményez; így előnyben részesítve az oszlopokat/változókat a sorok/megfigyelések felett)
  • a metaadatokat nem kezelik (pl.
  • meglehetősen érzékeny az adatstruktúrára (például ugyanazon adatkészlet “széles” és “hosszú” ábrázolása különböző UNF-eket eredményez)
  • ez nem verziókezelő rendszer, és lényegében nem nyújt betekintést abba, hogy mi változott, csak az, hogy változás történt

ezek az eszközök maguk az adatokra is összpontosítanak, nem pedig a kapcsolódó metaadatokra (például a kódkönyv, amely leírja a ADATOK). Míg egyes adatformátumok (például saját formátumok, például Stata-k .dta és SPSS .sav) kódolja ezt a metaadatot közvetlenül a fájlba, ez nem a széles körben szöveggel elválasztott adatstruktúrák közös jellemzője. Néha a kódkönyveket az adatértékektől függetlenül módosítják, és fordítva, de inkább azt látjuk, hogy a nagy nyilvános adatkészletek részletes információkat nyújtanak az adatok vagy a kódkönyv változásairól, kivéve az alkalmi kiadásokat.

Az adatok verziószámozásának másik nagy kihívása, hogy a meglévő eszközök verziókezelése nem megfelelő a származás kezelésére. Az adatok létrehozásakor, tárolásakor vagy módosításakor a szoftver-orientált verziókezelő rendszernek nincs nyilvánvaló mechanizmusa annak rögzítésére, hogy az adatkészlet értékei miért olyanok, amilyenek, vagy miért változtatnak bizonyos értékeken. A commit üzenet szolgáltathatja ezt az információt, de amint egy érték ismét megváltozik, az adott érték változásainak előzményei elvesznek az adatfájl egészének tágabb előzményeiben.

tehát nyilvánvalóan nincsenek teljes eszközök az adatok verziószámozására.

az adatok Verziószámozásának néhány elve

Az adatok verziószámozásának első elve az, hogy az adatok változásainak forrása vagy magyarázata van. Az adatverziós rendszernek képesnek kell lennie arra, hogy az adatértékeket, a struktúrát és a metaadatokat (és ezen jellemzők változásait) összekapcsolja az értékek magyarázatával vagy az értékek változásaival az érték szintjén (nem pedig a változók, megfigyelések vagy fájlok szintjén).

a második alapelv az, hogy az adatok verziószámozása értékalapú, nem változó vagy megfigyelés alapú. Egy rendszer nem részesítheti előnyben a megfigyeléseket a változókkal szemben, vagy a változókat a megfigyelésekkel szemben; a megfigyelés megváltoztatása szükségszerűen változó változása, és fordítva.

Az adatverzió harmadik elve az, hogy az adatok formátumuktól függetlenül léteznek. Ha egy CSV-ben egy adatértéket módosít egy JSON-fával szemben, akkor ezek tartalom-egyenértékű változások. Mint ilyen, bármely verziókezelő rendszernek lehetővé kell tennie az adatfelhasználók számára, hogy bármilyen fájlformátumban interakcióba lépjenek az adatokkal anélkül, hogy szükségszerűen használnák az alapul szolgáló adattárolási formátumot.

Az adatok verziószámozásának negyedik alapelve az, hogy az együttműködés elengedhetetlen az adatok előállításához és kurálásához. Az adatverziós rendszernek natív módon együttműködőnek kell lennie, és logikusan rögzítenie kell, hogy ki generálja és módosítja az adatokat.

Az adatok verziószámozásának ötödik elve az, hogy az adatszerkezet változásait az adatértékektől függetlenül kell rögzíteni. A megfigyelések rendezési sorrendje, az oszlopok/változók elrendezése, valamint a sorok elrendezése esetként az esetévekkel szemben stb. (pl., “széles” versus “hosszú” elrendezések) az adatkészlet szerkezeti jellemzői, nem pedig az adatok jellemzői önmagában. Ezek fontosak, de az adatverziós folyamatnak képesnek kell lennie arra, hogy megkülönböztesse az adatkészlet tartalmának változását az adatkészlet szervezetének vagy szerkezetének változásától, és az utóbbi esetben helyesen felismerje azonosnak a két különböző módon elrendezett adatkészletet.

Az adatok verziószámozásának hatodik elve az, hogy a metaadatok számítanak, de a struktúrához hasonlóan az adatok módosításaitól elkülönítve kell kezelni. Két azonos, különböző metaadatokkal rendelkező adatkészletet tartalom-azonosnak kell tekinteni.

kísérleti következtetések

az adatokat kulcs-érték módon kell tárolni, ahol egy tetszőleges kulcs egy adott adatértéket tartalmaz. A leképezés ezután összekapcsolja ezeket a konkrét adatértékeket mind a megfigyelésekkel, mind a változókkal, így az adatok változásainak bármilyen értékelése formátumfüggetlen és szerkezetfüggetlen. Mint ilyen, egy érték változását először egy érték változásaként rögzítik, de másodlagosan felismerhető mind a megfigyelés, mind a változó egyidejű változásaként.

Az ilyen kulcsérték-tároló bármely interfészének ismerős és rugalmas formában kell lennie: a felhasználóknak bármilyen módon kell interakcióba lépniük az adatverziós rendszerrel, bármilyen módon használják az adatokat (pl. szövegszerkesztő, adatelemző szoftver, táblázatkezelő alkalmazás stb.). A változásokat egy törzsfájlban kell rögzíteni, amely natív módon és azonnal importálhat és exportálhat bármilyen adatfájlformátumba (beleértve a tagolt fájlokat, táblázatokat, XML-t, JSON-t stb.).

Az Adatverziós rendszereknek kifinomultabb commit rendszerrel kell rendelkezniük, mint a jelenlegi, szoftver-orientált verziókezelő rendszerek. Különösen a kötelezettségvállalásoknak nemcsak az adatérték, szerkezet vagy metaadat változását kell rögzíteniük, hanem olyan strukturált információkat is, amelyek megmagyarázzák ezt a változást, beleértve a változás okát, az adatérték forrását(forrásait) és a változás szerzőjét. Lényegében mind a változókészleteknek, mind a teljes adatok állapotainak teljes mértékben idézhetőnek kell lenniük, és hivatkozással kapcsolatos metaadatokat kell tartalmazniuk.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.