Vier Wochen Prototype Fund: Was bisher geschah

Die ersten vier von 24 Wochen meiner Prototype-Fund-Zeit sind vergangen. Womit ich mich in der Zeit beschäftigt habe. Ein Überblick.

De-Duplication, Entity Resolving, …: Who is who?

• Als Basis-Daten dienen mir zwei Dumps aus der Citavi, einer Software zu Literaturverwaltung. Darin sind gespeichert: Bücher samt Autorenschaft, ISBN, Herausgaber und all die gängigen Bücher-Metadaten sowie Metadaten zur Postersammlung, inkl. „Autor:innen“, Jahr, Keywords. Also im Grunde das, was auch auf archiv.forummuenchen.org zu finden ist, mit dem Unterschied, dass ich auf die Webseite mehr oder weniger einfach die Citavi-Daten gekippt habe, ohne zu untersuchen, ob es Duplikate gibt. So finden sich dort auf der Webseite sowohl der Verlag rosa Winkel (als „Autor“ eines Posters) als auch rosa Winkel (als Verlag für Bücher). Es ist offensichlich, dass es sich um ein und dieselbe Organisation handelt.
• Als eine der ersten größeren Aufgaben habe ich mir deshalb gestellt, eine Methodik und einen Prozess festzulegen, um solche Duplikate systematisch finden zu können. Ich finde es einigermaßen witzig, dass diese Aufgabe, dieselben Entitäten (oder Texte) finden zu wollen, selbst unter verschiedenen Namen bekannt ist. Etwa: Data matching, record linkage, data linkage, entity resolution, object identification, ield matching, aligning, disambiguation, reconciliation…
• Zum jetzigen Zeitpunkt geht es dabei nur um Namen von Autor:innen, Herausgebern, Verlagen, also ein Vergleich von Texten, ohne zusätzliche Daten. Ich gehe dabei in drei Schritten vor:
  • Ich berechne die Cosinus-Ähnlichkeit und alle Kombinationen über 0.75 werden manuell geprüft. Die 0.75 sind recht großzügig.
  • In einer Webapp, die ich „Who is Who?“ getauft habe, kann man (ich) schnell entscheiden, ob es sich um dieselbe Entität handelt oder eben nicht.
  • Danach werden die Ergebnisse konsolidiert und ggf. neue IDs vergeben.

• Neben meiner Erfahrung bei Factfield war dabei auch besonders das Vorgehen von Friedrich Lindenberg bei Opensanctions hilfreich.
• Diese Aufgabe wird in verschiedenen Schattierungen immer wieder kommen in den nächsten Monaten.

Linked Data ist nicht gleich Linked Data

• RDF ist ein Standard um verlinkte Daten, wie sie ja Knowledge Graphs sind, abzubilden. Eines meiner Ziele für den ersten Monat war es, eine integrierte Sicht auf die oben genannten Kerndaten zu bekommen.
• Das habe ich geschafft, indem ich über YARRRML und RML sowie kglab die Daten in der relationalen Datenbank ins RDF-Format (ttl und jsonld) gebracht habe. Damit sind `SPARQL`-Abfragen möglich.
• Bei wem das Dropping dieser Abkürzungen kein inneres oder äußeres Gähnen getriggert hat: Ich hab so kurz es ging aufgeschrieben, wie das geht: RDF, RML, YARRRML: A basic tutorial to create Linked Data from a relational database table
• Was schön war: Ich habe das Tutorial auf Twitter gepostet und darauf ergab sich unter anderem, dass ich die Dokumentation des Python Packages kglab um diesen Aspekt ergänzt habe: Load data via Morph-KGC

Wikibase or no Wikibase

• Doch: Am Ende werde ich vermutlich nicht auf einen klassichen RDF-Triplestore als Speicherort setzen, sondern auf Wikibase, also der Software, die auch hinter Wikidata steht. Tut man das, handelt es sich streng genommen nicht mehr um verlinkte Daten nach W3C-Standard. Warum, das erklärt Harald Sack ohne müde zu werden immer und immer wieder. Etwa hier ab Minute 16.
• Doch für mich überwiegen die Vorteile. Ein paar davon:
  • Am Ende möchte ich ja (auch) Daten bzw. Relationen in die Wikidata zurückspielen.
  • Wikibase bietet eine ganze Reihe von Extensions, etwa Abfragen und vor allem, die Darstellung Ergebnissen als Karte, Graphen, Timelines… Also alles Dinge, um die ich mich nicht wirklich selbst kümmern möchte. I am not a Frontend Person.
  • Außerdem ist das Prinzip Wikidata vermutlich leichter zu vermitteln, wenn man bereits mal mit Wikipedia gearbeitet hat.
  • Kollaboratives Arbeiten an den Daten ist der Kerngedanke, genauso wie
  • Kurzum: Wikibase it is.
• Nachteile von Wikibase:
  • Ich muss mich um Infrastruktur kümmern. Klar, es gibt einen Docker-Container, der das alles schon mal für das Grundsetup ganz bequem macht: removena.katharinabrunner.de läuft immerhin schon.
  • Doch es tun sich mir viele Fragen auf, insbesondere was Zusammenspiel von Wikidata und eigenen Wikibase-Installationen angeht.
  • Zum Beispiel ist eine zentrale Property P31: Instance of. Jede:r, die/der mehr als drei Abfragen auf Wikidata gemacht hat, kennt das. Wieso sollte bei eigenen Wikibase-Instanzen nicht das gleiche sein?
  • Toll ist ja, die Idee der federated Daten: Das heißt, ein Teil liegt bei mir, der Rest in Wikidata und ich kann Abfragen bauen, die das zusammen bringen. Quasi der „Do what you do best and link to the rest“-Gedanken auf Datenebene. Aber: Sind damit in den verlinkten Daten zur queeren Geschichte zu wenige, damit sie für Personen, die nicht so PID-, QID-affin sind, unbrauchbar, weil zu wenige? Muss/Sollte ich also Daten kopieren/importieren? Und kann ich die in Sync halten? Theoretisch ja, aber gibt’s Kollisionen mit den Property IDs?
  • Ich werde also in der nächsten Zeit in der Wikibase-Community auskundschaften, wie solche Fragestellungen bisher gelöst wurden.
• Am besten wäre es also, Wikibase zu nutzen und jemand anderes kümmert sich um das Hosting. Tatsächlich gibt es seit Kurzem genauso ein Angebot von Wikimedia Deutschland: Wikibase Cloud. Ich habe nachgefragt, ob ich daran teilnehmen kann, aber leider haben sie momentan keine Kapazitäten. Das ist schade; dadurch wird natürlich einige Arbeitszeit für die Datenanalyse etc. nicht zur Verfügung stehen.

NLP: Entities in Fließtexten finden

• Nun sind die oben genannten Daten zu Büchern und Postern schon ganz gut: Etwa lässt sich vermutlich schon eine Liste von queeren Verlagen (annotiert von einer Expertin aus dem Forum) erstellen und prüfen, ob und wie diese in der Wikidata oder der GND abgebildet sind (eine Aufgabe für die nächsten vier Wochen).
• Ich möchte aber unbedingt einen Schritt weiter gehen und mindestens zwei weitere Quellen einbinden:
  • Die Münchner LGBTIQ*-Chronik
  • den Themengeschichtspfad (pdf): Ein Heftchen von mehr als 100 Seiten, geschrieben vom Forum Queeres Archiv und herausgegeben von der Stadt München im Jahr 2015.
• Der Text der Chronik ist unglaublich dicht: Mehr als 200 Einträge, die nur so wimmeln von Organisationen, Personen, Zeit- und Ortsangaben. Meine bisherigen Entitäten, die sich bisher vor allem um publizierte Werke drehen, werden damit ergänzt um politische und historische Entwicklungen und deren Akteure.
• Dieses Extrahieren von Entitäten ist eine Standardaufgabe im Natural Language Processing (NLP) und nennt sich Named Entity Recognition (NER).
• Im NLP-Bereich habe ich mich an NER mit drei verschiedenen Frameworks bzw. Modellen herangetastet, um ein Gefühl dafür zu bekommen, wie ich weiter vorgehen kann: Spacy, Flair und einem transformers aus dem Hugging-Face-Hub.
• Um die Ergebnisse anzusehen und weiter zu annotieren, nutze ich Rubrix.
• Alle drei Varianten funktionieren so mittel, auf unterschiedliche Arten. Es ist klar, dass ich da nachhelfen muss. Aber das ist ja total normal, bei domänenspezifischen Texten.

• Beim Nachhelfen habe ich nun verschiedene Möglichkeiten:
  • Ich annotiere wie die NER-Modelle nach LOC, MISC, ORG, PER
  • Oder ich labelle von vorneherein feiner, weil das vermutlich für das Endziel, dem Knowledge Graph, zu grob ist. Etwa auch EVENT oder LOCATION.
• Evtl. trainiere ich dann eines der Modelle nach. Bei dieser Aufgabe muss ich aufpassen: Das Potenzial viel Zeit zu versenken.
• Das heißt: Ich optimiere die Extraktion bei der Chronik und wende das dann anschließend auf den Themengeschichtspfad an.
• Naheliegend wäre danach, modellbasiert die Relationen zwischen den Entitäten zu finden. Realistisch gesehen, sollte ich das aber in Anbetracht einer begrenzten Zeit, lieber lassen.

Was kommt als nächstes?

• Mit Expert:innen im Forum Queeres Archiv sprechen, welche (Gruppen von) Entitäten sie sehen in Bezug auf die Emanzipationsgeschichte.
• Das Entity Linking beginnen: Welche Entiäten finde ich in Wikidata oder der Normdatei der GND über die lobid-API? Vermutlich ist letzteres sinnvoller, vor allem bei den Entitäten, die aus Büchern kommen, weil die Domäne schon mal ähnlich ist und damit zumindest ein paar False Positives bei unbekannteren Personen oder Verlagen vermieden werden können.
• Nebenbei Wikibase auf die Beine stellen und ausprobieren, was funktionieren könnte, um in vielleicht zwei Monaten einen Plan zu haben, wie ich sie einspielen kann.
• Der Protoype Fund bietet ein Coaching an. Einen recht motivierenden Termin hatte ich schon, die nächsten stehen bald an. Inhaltlich wird’s vermutlich um User Research gehen. Denn um das technische Klein-Klein kümmere ich mich schon genug.