FactGrid talk:GND-Daten-Import

2019-02-13: Gotha, Brainstorming

• Pagenhaus, Beteiligte: Mathias Manecke, Wolfgang Runschke, Olaf Simons

GND wie sie ist, GND neudenken, und eher pragmatisches Angebot an Forscher

Im freien Gespräch dachten wir in drei verschiedene Richtungen:

1. Ein Datenmodell zu wählen, das sehr nahe an der bestehenden GND-Ontologie entlangläuft. Die Vorteile liegt in der bereits etablierten Standardisierung, der guten Dokumentierung, der breiten Verbindlichkeit, die dafür sorgt, dass alle Datenbanknutzer dieselbe Sprache sprechen und damit Suchergebnisse erschöpfend erzielen. Der Nachteil ist, das dies nicht die interessanteste Nutzung der sehr flexiblem Software auf einer freieren Forschungsplattform sein wird.
2. Den Schritt in Wikibase hinein zu nutzen, um gänzlich neue Modelle zu riskieren - das Interesse von Mathias Manecke im GND4C-Projekt. Extrem interessant hier, eine Modellierung, die auf Ereignisse als zentrale Entitäten zwischen Orten, Personen, und Dokumenten in der raum-zeitlichen Dimension setzt.
3. 'Eine auf Schnelligkeit der Eingabe abzielende primär pragmatische Modellmischung, die irgendwo zwischen Wikidata und der GND-Ontologie steht. Das zentrale Anliegen des ganzen GND Imports ins FactGrid ist es, Benutzern das Eröffnen von Entitäten, wo immer möglich, zu ersparen. Sie werten Dokumente aus und müssen nicht erst in der GND nach Personen, Orten und Körperschaften recherchieren und Statements von dort übernehmen. Stattdessen verknüpfen sie gleich die bereits nach GND-Standard vorhandenen Datenbankobjekte und konzentrieren sich auf die Forschungsarbeit.

Wenn man nun zu Geburt, Tod, genealogischen Beziehungen fortwährend neue Ereignis-Entitäten anlegen muss, statt Information einfach als Statements notieren zu können, ginge der Vorteil der bereits die meisten Entitäten mit sich bringenden Ressource wieder verloren, so die Sorge hier.

Andererseits wird gerade die wissenschaftlich forschende Datenbank absehbar neue Entitätstypen einführen – wie den Entitätstyp „Verbindung zu einer Gesellschaft“, der wesentlich feiner granuliert Daten zu Mitgliedschaften aufnehmen kann als eine Personenbiographie das aktuell kann. Auf die neue Entität mit den Detailinformationen zu einer Mitgliedschaft wird dann von der Person und der Organisation aus verwiesen.

Das auf Schnelligkeit des Arbeitens zielende Datenmodell bleibt in der Forschungsplattform vielleicht ohne größeres Risiko, da die Datenbank (anders als ein Wiki) spätere Umstrukturierungen und das massenweisen Umbetten von Einträgen erlaubt. Eine offizielle GND-Ressource wird weniger frei sein, und gerade Stabilität der Modelle versprechen müssen. Vielleicht ist aber gerade dies der Reiz des Projektes: dass wir für unterschiedliche Anwendungen unterschiedliche Plattform mit unterschiedlichen Praktikabilitäten entwickeln, die aber miteinander kommunizieren können.

Mögliche Beziehungen des FactGrid zur GND

Die spezifische Forschungsplattform würde mit dem GND-Import standardisiert strukturierte Datenbankobjekte gewinnen, mit denen Forscher weiter arbeiten, ohne noch eigens in der GND recherchieren zu müssen. Für die GND kann dabei vor allem interessant werden, dass Benutzer hier Daten ohne Rückfrage korrigieren, Datensätze erweitern, neue Datensätze anlegen, Quellen liefern - ohne die GND berühren zu müssen.

• Denkbar ist einerseits eine enge Integration, bei der Benutzer GND-Stammdaten tatsächlich gar nicht im FactGrid, sondern in der GND verändern (von wo sie eingespielt werden).

• Denkbar ist andererseits eine flexiblere Anbindung, bei der das FactGrid eher eine Quelle ist aus der sich die GND und Wikidata nach unterschiedlichen Relevanzkriterien bedienen. Regelmäßie Datenabgleiche filtern heraus, ob etwa Informationen wie Geburtsdaten geändert wurden und übernehmen vom FactGrid ganze Forschungsstatements wie von einer fremden Quelle.

Die entscheidende Frage ist vielleicht gar nicht, ob wir auf allen Plattformen nach denselben Modellen laufen lassen. Wichtiger wäre vielleicht die Frage, ob wir die verschiedenen Instanzen so transparent organisieren können, dass sie sie trotzdem miteinander kommunizieren können, und Wissen in Aktualisierungenm voneinander beziehen können.

Praktische Schritte

Wir kamen darin überein, dass es spannend wäre, wenn Mathias Manecke seine GND4C Ideen, einmal im FactGrid mit Musterlösungen ausprobieren würde. Es ist dabei aktuell kein Problem, wenn speziell für ein solches Experiment neue Properties geschaffen werden oder bestehende Properties ganz anders organisiert in einem Dutzend Biographien genutzt werden.

Wesentliche Fragen des Experiments wären:

• Wie schwierig wird es, eine innovativere Ontologie Laien zu vermitteln? (Forscher sind was Ontologien anbetrifft Laien, die am ehesten kennen, was sie schon mal in Fragebögen gesehen haben)
• Wie mühsam wäre die innovativere Ontologie im Tagesgeschäft, wenn Dokumente ausgewertet werden, und Forscher neue Aussagen zu Personen, Orten, Ereignissen und Beziehungsgefügen machen wollen.
• Wie gestalten sich SPARQL-Recherchen (nachdem klar ist, dass man diese viel Wissen über doe Ontologie verlangen)?

(Wolfgang: für die Dateneingabe wäre doch ein Formular hilfreich. Oder besser: ein Baukasten mit zusammenklickbaren Elementen, mit denen ein User ein vorgegebenes Muster für seine Zwecke aus- und umbauen und zur Verfügung stellen könnte. Ideal wäre dann noch, eine CSV-Datei mit Massendaten über dieses Formular einlesen zu können.)

Terminplan

...besteht erstmal nicht. Interessant wäre es bis Ende März Ideen am Beispielen demonstrieren zu können.

Reasonator, SQID und Scholia

Beim Auslesen von Daten aus der Datenbank sind drei auf Wikibase ausgerichtete Tools besonders spannend.

• Magnus Manske's Reasonator: Vergleiche Johann Sebastian Bach in Wikidata und die Reasonator Darstellung der Wikidata Information

• Magnus Manske dazu im eigenen Blog

• Markus Krötschs' SQID Darstellung zu Johann Sebastian Bach

Der Denkanstoß kann hier sein, die Datenbank von der Darstellung der Ergebnisse zu entkoppeln. Auf Datenmodelle mit wenigen reziproken Informationen zu setzen, die von einer Software intelligent ausgebeutet werden.

• Scholia zeigt hier wie eine Benutzeroberfläche speziell auf die Ausbeutung einer Wikibase-Instanz ausgerichtet werden kann

weiteres Nachdenken

Nur mal so ins Unreine gesprochen: Neben der Option, vermehrt auf Ereignisse zu setzten gäbe es noch eine ganz andere - erkenntnistheoretisch interessante und vielleicht auch arbeitssparende: Die Quellen ins Zentrum zu rücken. Jedes Dokument erhält ein Item. Aussagen zu Personen, Ereignissen, Orten etc. werden auf zum Item des Dokuments gemacht. Vorteil: Quellenverweise fallen hier weg.

Zentrales Erfordernis allerdings hier: Eine Datenbanksoftware, die Informationen zu Personen, Orten und Ereignissen aus der Durchsicht der Dokumente zusammenstellt. Sichtbarer würde nun, wo Massen an Aussagen heute einfach nur öffentlich flottieren mit einer einzigen Quelle wie GND oder Wikipedia. Sichtbarer würden nun zweitens Widersprüche als Quellenbedingt.

Wir müssten nun trennen zwischen der Datenbank einerseits und der Oberfläche, die Informationen nach Interessen an Personen Orten und Ereignissen generiert. Reziproke Informationen könnten weitgehend vermieden werden, da sie aus Quellen ausgelesen an verschiedenen Orten (als Informationen zu Personen und zu Institutionen etwa) erscheinen. --Olaf Simons (talk) 11:51, 14 February 2019 (CET)