Vorschläge für die Qualitätssicherung des Datenbestandes

Um aus einem Datensatz so viel wie möglich raus holen zu können, muss der Datensatz von einer bestimmten Qualität sein, da sonst die weitere Arbeit für denjenigen erschwert wird, der danach den Datensatz benutzten möchte. Da uns bei diesem Datensatz einige Inkonsistenzen aufgefallen sind, schreiben wir nun ungefähre „Richtlinien“ auf, wie ein guter Datensatz aussehen könnte, anhand der bisherigen Spalten der jetzigen CSV-Datei.

Somit einige allgemeine Voraussetzungen für den Datensatz beginnend. Bei so einen Datensatz ist es wichtig, dass jede Spalte in sich gleich formatiert ist, sprich wenn man eine Spalte hat, die zum Beispiel Zahlen beinhaltet, dass es dann in jeder Zelle dasselbe Zahlensystem ist und nicht plötzliche in einer Spalte römische, europäische oder ganz anderen Zahlensysteme vorkommen. Dies gilt auch für die Groß- und Kleinschreibung oder auch für das abkürzen und voll ausschreiben von Namen. Eine Spalte muss in sich eine gleiche Formatierung haben. Des weiteren sollte darauf geachtet werden, wenn einem ein Rechtschreibfehler in einer Zelle auffällt, wie zum Beispiel der Autorenname, sollte dieser Eintrag entweder korrigiert werden oder ein neuer erstellt werden, dann aber den alten mit dem Rechtschreibfehler löschen. Es gab einige Einträge die mehrfach vorgekommen sind und die sich meist nur durch einen Rechtschreibfehler unterschieden haben, daher den Rechtschreibfehler am besten gleich in der Zelle bearbeiten und nicht eine ganze neue Spalte dafür anlegen. Dadurch hat man dann einige Autoren mit ein und denselben Titel mehrfach in den Daten, obwohl dies nicht beabsichtigt ist.

Beispielhaft gehen wir nun einmal die Spalten des Datensatzes entlang und geben anhand derer Beispiele:

Sowohl bei den Autoren als auch bei den Editoren wäre es gut, wenn der Name ganz ausgeschrieben wird. Einige Namen waren der Vorname abgekürzt. Bei abgekürzten Namen kann man eventuell nicht den genauen Autoren bzw. Editoren ohne weitere Informationen herausfinden.

Bei der Spalte für die Typen kommt es darauf an wo und wie man am Ende die Daten benutzen möchte. Anhand unseres Beispiels mit Wikidata sind einige Typen dort nicht vorhanden. Zum Beispiel „paperr“ und „papern“ gibt es separat in Wikidata nicht, diese Typen stellen wir mit dem Typen „article“ dar. An sich ist es die Aufgabe des Entwicklers die Daten auf die Datenbank zu bringen und auf solches zu achten, aber wenn man eventuell von vorneherein gängigen Datentypen benutzt erleichtert man damit die Arbeit des Entwicklers. Als kleine Übersicht haben wir eine Tabelle mit den Datentypen aus dem Datensatz und den möglichen Datentypen auf Wikidata erstellt (https://github.com/code-openness/Data/issues/28).

Bei Startpage und Endpage sollte man sich entscheiden zwischen dem gängigen Zahlensystem oder dem römischen Zahlensystem. In einer Spalte nicht beide Systeme vermischt und außerdem keine Artikelnummern. Wenn Artikelnummern vorhanden sind, dann eine extra Spalte dafür anlegen, da Seitenzahlen nicht dasselbe sind wie Artikelnummern.

In der Spalte Year gibt es Einträge, die nur das Jahr der Publikation beinhalten, aber manche Einträge bestehen aus dem vollständigen Datum, also TT.MM.JJJJ. Wenn die Spalte schon Year und nicht Date genannt wird, dann wäre es für die Einheitlichkeit besser wirklich nur das Jahr hinzuschreiben, oder überall das ganze Datum, so wie es einem zur Verfügung steht, aber in der ganzen Spalte Einheitlich.

Für den Ort (Spalte place) wäre es am besten nicht nur das Land aufzulisten, sondern zur besseren Eingrenzung auch die Stadt.

In der Spalte X4 steht die DOI, bei der ist es wichtig das der vollständige DOI-Link vorhanden ist. Die fehlenden DOIs wurden von uns mithilfe von CrossRef Api ( oder Web of Science API) hinzugefügt.

Die beiden Spalten publisher und journal haben wir im Grunde gleich behandelt. Einträge, welche dasselbe aussagen sollen, aber unterschiedlich geschrieben wurden, wurden in ein identisches Format verwandelt. Als Beispiel Ökom. Für Ökom gab es 4 verschiedene Schreibweisen: Ökom, ökom, Oekom und oekom. Für solche Fälle wurde im Internet nach der offiziellen Schreibweise gesucht und in den Daten korrigiert. Also ist in den beiden Spalten wieder das Format der Daten wichtig gewesen, sprich die Rechtschreibung und außerdem die Groß- und Kleinschreibung, da es sich sonst um zwei verschiedene Einträge handelt.

Einige Spalten enthalten nur sehr wenig Daten, wie zum Beispiel Comment (ca. 88% leere Zellen), Link (ca. 88%), Relation (ca. 84%), Conference (ca. 95%), Issue (ca. 50%) und vol (ca. 50%). Diese weiter aufzufüllen ist per Hand für einen Entwickler sehr arbeits- und zeitaufwendig. Um die Daten gut zu visualisieren oder weiterzuverarbeiten sind es daher in einigen Spalten zu wenige. Es wäre besser, wenn solche Spalten angelegt werden, diese auch möglichst vollständig auszufüllen.

Dies sind jetzt einige Vorschläge, wie man die Daten von vorneherein dokumentieren kann. Das wichtigste, wie oben schon erwähnt, ist es, dass die Daten in einer Spalte einheitlich formatiert sind, damit keine Inkonsistenzen entstehen und möglichst keine Duplikate von Einträgen in der Datei vorhanden sind.