Diese Tage habe ich den ersten großen Schwung an Daten in Factgrid geladen, der Datenbank für strukurierte, historische Daten. Das was anstrengender als gedacht, ein paar Punkte, möchte ich deshalb hier notieren.
Grundsätzlich gilt auch hier:
Factgrid als Datenbank
Factgrid ist eine Art Wikidata für historische Daten und Projekte. Mehr dazu hier.
Optionen für den Import
Um Daten in eine Wikibase-Instanz zu bekommen, gibt es mehrere Varianten:
- manuell auf der Webseite: Das ist langwierig und in meinem Ansatz – maschinell so viele Daten wie möglich erfassen und modellieren – nur dann sinnvoll, um spezielle Abweichungen von Einzelfällen abzubilden
- Quickstatements/API: Das ist die gängiste Variante, um Daten etwas aus Tabellen oder Datenbanken zu importieren. Dabei müssen im Großen und Ganzen die Daten entweder als Quickstatements formuliert werden oder in einem bestimmten csv-Format vorliegen:
- Quickstatements: Das entspricht mehr oder weniger den Statements und besteht in der Grundform aus drei Aussagen: Objekt – Prädikat – Subjekt, Item Property Item, definierte Beziehung zwischen Objekt 1 und Objekt 2 oder wie auch immer man es sich vorstellt. Ein Beispiel: Die Deutsche Eiche ist eine Gaststätte heißt: Q399986 P2 Q40454. All diese Aussagen werden dann in einer tab-separierten longform Version in das Quickstatements-Interface oder über die API eingespielt.
- csv-Datei: Zugänglicher für weniger datenaffine Personen ist die csv-Variante, die mehr oder weniger Tabellen entspricht. Der Nachteil daran: Die Daten müssen ganz gleichförmig sein. Wenn auch nur ein Wert, sei es weil er vergessen wurde oder die Information einfach nicht exisiert oder vorliegt, bricht der Import und es müsste für all diese Fälle mit genau dem gleichen fehlenden Werten eine neue Datei erstellt werden. Das ist mühsam und unnötig kompliziert.
- Direkt in die Datenbank: Hinter Wikibase steht keine fancy Datenbank, sondern eine gute alte MySQL-Datenbank. Dort können die Daten natürlich auch ohne Umwege importiert werden. Das war keine Option für mich, so groß sind meine Datenmengen nicht. Denn der größte Vorteil ist die deutlich höhere Geschwindigkeit gegenüber der Quickstatements-API-Variante. Je mehr Daten, desto interessanter wird also diese Option. Mehr dazu hier.
Von R nach Factgrid/Wikibase
Datenmodellierung: Breite statt Tiefe
Stand jetzt habe ich 3519 Entitäten in Factgrid importert: Personen, Orte verschiedenster Art, etwa konkrete Adressen, aber auch Lokale und Gaststätte, Vereine, Chöre, Gesetze… Insgesamt sind das fast als 95 Prozent aller Entitäten in meiner Datenbank.
Eine Tabelle aller Remove-NA-Entitäten:
Hier eine Tabelle aller Personen:
Wer drüberscrollt wird sehen, immer wieder sind dort Personen, bei denen steht, dass sie emigierte sind aus dem Nazi-Deutschland. Das kommt nicht von mir. Ich weiß das nur anekdotisch aus dem Kopf, etwa bei Erika Mann oder Therese Giese, auf Datenebene habe ich das natürlich nicht hinterlegt.
Doch hier kommt die Kraft des kollaborativen Arbeitens zu tragen: Olaf Simons von Factgrid hatte mal eine Liste von Personen importiert, deren Gemeinsamkeit es eben war, dass sie aus Deutschland fliehen mussten. Und dass es da jetzt Überschneidungen mit Personen aus dem LGBTIQ*-Spektrum gibt, ist nicht nicht überraschend, auf dem Schirm hatte ich es aber dennoch nicht.
Die 35 Personen aus dem Remove-NA-Datensatz, die als Flüchtende bereits in Factgrid hinterlegt waren:
LGBT-Lokale in München
Was fehlt sind die Verbindungen
Was aber noch komplett fehlt sind die konkreten Bücher, Poster, Vorkommnisse, die sich aus diesen knapp 4000 Entitäten konstruieren lassen. Das werde ich vermutlich den restlichen Mai über machen. Dann werden auch die Abfragen interessanter, die momentan noch relativ eindimensional daherkommen.
Grundsätzlich habe ich in diesem Stadium relativ wenige Informationen zu vielen Personen. Es ist nicht zu leisten – und nicht der Anspruch noch der Kern meines Projekts – zu jeder Person Detailinformationen zu finden. Sondern es geht darum, all diese Entitäten zu verknüpfen und miteinander abzugleichen. Und dabei möglichst lange auf maschinelle Verfahren zu setzen. Breite statt Tiefe also.
Die Bücher und Poster werden einfach. Daten nehmen, simple Modellierung, rein damit. Komplexer werden die Events aus der Chronik: Wie viel gehe ich da händisch rein? Wann belasse ich bei einer bewussten gröberen Systematik, die dafür für viele korrekt ist, auch wenn es eine präzisere Bezeichnung geben kann?
Reconciliation: Was kennen Factgrid, Wikidata oder die GND schon, was bringe ich neu rein?
Diesen Abgleich habe ich bisher an verschiedenen Stellen gemacht, etwa hier über die lobid API. Es stellt sich jedoch raus: Schlauer ist der Weg über die Webapp OpenRefine und deren Funktion der Reconciliation.
Reconciliation is the process of matching your dataset with that of an external source
Open Refine Documentation
Alle drei meiner externen Quellen gegen die ich prüfen will, stellen eine API dazu zur Verfügung. Ganz grob funktioniert das so:
- Ich habe eine Spalten mit Personennamen.
- Ich möchte wissen: Gibt es diese Person schon in Wikidata
- Es wird in Wikidata nach dieser Person gesucht, auch in den Aliasen.
- Ich kann die Menge der Kandidaten einschränken, indem ich von vornherein nur gegen Menschen checken lasse oder Schriftstellerinnen usw.
- Open Refine vergibt Scores und nach denen kann ich zB auch sagen: Immer der höchste wird als Treffer gewertet.
- Kandidaten können dort auch begutachtet und manuell ausgewählt werden
Es ist genau dieser letzte Punkt, der mich dazu gebracht hat, Open Refine zu nutzen. Alle vorherigen Punkte: Das Datenschieben, gegen eine API werfen, ein Ergebnis zurückbekommen ist einfach. Doch was mache ich dann damit? Wie kann ich effizient Entscheidungen treffen?
Das war schon bei der Duplikateerkennung vor einigen Wochen ein zentraler Punkt, für den ich mir eine kleine Webapp baute.
Noch ein Punkt zu Open Refine: Ich kenne die Software noch als sie Google Refine hieß und optisch hat sie sich seit den frühen 2010er Jahren kaum verändert. Davon hatte ich mich etwas trügen lassen. Denn die Software ist super für genau solche Übergaben von automatisiertem Säubern und Auswerten und manuellen Entscheidungen zum Linken auf externe Datensätze (für andere Use-Cases habe ich sie nicht genutzt). Das ist ja häufig die Sollbruchstelle.
Wenn jetzt noch die Optik, UX usw. auf Stand gebracht werden würde, dann würde das ganze noch besser funktionieren. Denn die Engstelle ist momentan nicht die Funktionalität, sondern ein veraltetes Aussehen und User Experience, die verzögert. Looking at you, mini-Schriften und langsame Pop-Ups.
Factgrid Systematik: Die Properties für meine Daten
Factgrid ist ein bestehendes System mit einer Infrastruktur und gewachsenen Datenstrukturen, an die ich meine Daten anpasse. Das heißt: Ich setze Statements wie „Ist ein Mensch“, „ist männlich“, „ist trans“ usw. usf. Diese Eigenschaften sind in Wikibase-Systemen in sogenannten Properties codiert, genauso wie die Antworten darauf:
- Ist ein(e) bedeutet
P2, ein MenschQ7 - Gehört zu meinem RemoveNA-Projekt braucht die Kombination aus
P131Q400012.
Ich will mir das nicht merken. Eine offensichtliche Fehlerquelle. Ich habe mir deshalb eine Tabelle erstellt, in der ich meine benutzten Statements hinterlege und dann im Code nur mehr schreiben muss: add_statements(statements, research_project). Die zur Verfügung stehenden Statements hinterlege ich in einem Googlesheet. Neue füge ich dann dort hinzu und kann sie dann verwenden.
Schnell wird das ganze natürlich beliebig komplex. Es gibt Überklassen und Unterklassen, etwa ein Chor ist eine Unterklasse von Organisation.
Wenn ich mir ein einzelnes Objekt ansehe, wird bei fast allen offensichtlich: Da fehlt noch viel Futter, manuelles Nachrecherchieren würde das einzelne besser machen. Gleichzeitig habe ich ja noch nicht mal alle mir vorliegenden Informationen und insbesondere die Beziehungen untereinander importiert. Wie viel Sinn macht deshalb zu viel händisches Reingehen zu diesem Zeitpunkt?
Duplikate
Duplikate finden sich überall: Natürlich über die Ähnlichkeitsmessungen der Namen, etwa um August Platen und August von Platen zu finden. Doch was ich unterschätzt habe, sind Pseudonyme. Es gibt einige Personen, die vor allem im 20. Jahrhundert zu LGBT-Themen nicht unter ihrem Realnamen veröffentlichten. Ein Beispiel dafür ist Patricia Highsmith, die als Claire Morgan in den 1950er Jahren einen Roman veröffentlichte, in dem sich zwei Frauen verlieben und trotzdem kein nicht nur ein schlechtes Ende nahm.
Diese Konstellationen – Realname und Pseudoynm – habe ich erstmal als ein Objekt importiert und den Realnamen als Label und das Pseudonym als Alias gesetzt. Ganz ideal ist das nicht, denn sauber kann ich diese Fälle nun nicht abfragen; dafür ist der Aufwand für den initalen Import geringer. #backlog
Gender und Geschlecht
Geht es um nicht-heterosexuelle Personen und deren Abbildung, landet man unweigerlich schnell bei Gender und Geschlecht. Tja, eine schweirige, weil höchst individuelle Sache. Im Kern geht’s um Fragen wie diese: Was trumpft: Selbst- oder Fremdeinschätzung? Wird eine trans Frau als weiblich hinterlegt oder nicht? Kann man historische Personen mit Begrifflichkeiten der Gegenwart belegen?
In der Frage schlagen zwei Herzen in meiner Brust: Jawohl, eine trans Frau ist eine Frau. Gleichwohl will die besondere Eigenschaft hinterlegen, denn wer nicht gezählt wird, ist nicht existent. Und am Ende geht es bei Remove NA ja gerade darum, Personen, Ereignisse, Orte aus dem Ungefähren, Unscharfen oder Unbekannten sichtbar zu machen.
Um die (angenommene) Geschlechtsidentität abzubilden, arbeite ich deshalb nach diesem schematischen Modell:
Eine trans Frau ist demnach nicht als trans Frau hinterlegt, sondern als beides, Frau und trans. Nichtbinär ist eine Unterklasse von trans. Intersex, das wissen ja die meisten seit der Gesetzesänderung, eine weitere, für sich stehende Variante.
Grundsätzlich habe ich Geschlechtsangaben und solche zur sexuellen Orientierung 1:1 aus Wikidata übernommen.
Eine automatiserte Geschlechtszuweisung auf Grund des Vornamens habe ich nicht gemacht, das ist zu heikel und unsicher. Beispiel dafür, das die automatische Zuweisung nach Vornamen nicht funktioniert: Tony Sender, die während der Nazi-Zeit in die USA emigierte. War in Factgrid ein Mann, stimmt aber nicht.
Grundsätzlich das Arbeiten mit Namen und unsere impliziten Annahmen und Gewohnheiten dazu prädistiniert, automatisierte Fehlklassifikationen zu generieren. Die Fehlerquellen sind vielfältigst und machen keine Lust auf automatisierte Verabeitung. Wer mehr über die faszinierende Welt, der Falschannahmen zu Namen wissen will: Falsehoods Programmers Believe About Names – With Examples
Import: So viel Skript wie möglich, so wenig manuell wie nötig
Ich will möglichst lange in R die Daten transformieren und in die richtige Form bringen und nur im letzten Schritt über Quickstatements importieren. Es bietet sich dafür das Package WikidataR an, mit dem man sowohl Daten aus Wikidata holen als auch schreiben und verändern kann. Allerdings funktioniert das nur mit Wikibase, die aber auch nur die initiale, größte und bekannteste Wikibase-Installation ist. Ich habe deshalb die write_wikidata()-Funktion so umgebaut, dass sie für jede Wikibase-Installation, also auch Factgrid, funktioniert. Eine Funktion, die vermutlich auch andere brauchen können, ich habe also einen Pull Request erstellt, der aber noch unbeantwortet ist.
Die Daten können direkt über einen API-Call importiert werden, klappt dabei aber etwas nicht, ist es umständlich, herauszufinden, an welcher Stelle das nicht geklappt hat. Deshalb exportiere ich an geeigneter Stelle eine `csv`-Datei, von denen ich dann auch 40 000 Zeilen am Stück in das Quickstatements-Interface copy-pasten kann und direkt Feedback bekomme, ob der Import erfolgreich war oder wann nicht und warum nicht.
Diesen Workflow werde ich nochmal gesondert anhand eines kleines Beispiels als Tutorial aufzeigen. Ein Skript, das ein paar Iterationen hinter sich hat, ist schon mal hier zu finden.
Was steht an?
- restliche Entitäten importieren
- Tutorial dazu schreiben
- Items für alle Bücher und Poster erstellen
- Relationen zwischen Entitäten