FactGrid talk:GND-Daten-Import

From FactGrid
Jump to navigation Jump to search

2019-02-13: Gotha, Brainstorming

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äßige 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 alle 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 und Aktualisierungen automatisch bewerkstelligen 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 einmal in einem Dutzend ausgewählter 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 selbst 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 diese immer exaktes Wissen über die Ontologie verlangen)?
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. --Wolfgang Runschke (talk) 14:37, 14 February 2019 (CET))
Habe unten einen eigenen Abschnitt mit den aktuellen Lösungen von User:Adrian Heine und User:Magnus Manske eröffnet. --Olaf Simons (talk) 15:01, 14 February 2019 (CET)

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.

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

Formualbaukasten

Wir finanzierten vom Forschungszentrum aus eine Entwicklung für einen Formularbaukasten - hier die Vorgabe Web Forms. User:Adrian Heine war damals unser Projektpartner - auf dieser Seite gibt es den Überblick zu seiner Problemlösung Talk:Web Forms

Wenig später legte Magnus Manske das "Cradle Tool" vor, das genau das skizzierte Problem anging: Hier gibt es Formularideen Wikidata:Cradle - und hier die Werkzeuge selbst auf Wikidata ausgerichtet wikidata-todo/cradle/#/.

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)

2019-05-13 Planungsgespräch

Nur eine summarische Zusammenfassung:

  • Das FactGrid kann grundsätzlich für Experimente mit Eingaben und alternativen Datenmodellen genutzt werden - Projektinteressierte erhalten Accounts (vergebe ich Olaf Simons mit einer Namensliste)
  • Wir müssen nachdenken, wie man ohne Quickstatements die Datenbefüllung vornimmt - 5 Millionen Datensätze über QuickStatements sind nicht sinnvoll zu bearbeiten.
  • Ein großes Problem sind Binnenreferenzen in den Datensätzen, die jeweils existierende Q-Nummern voraussetzen, die noch nicht vergeben sind. (Hier behalfen wir uns im FactGrid bislang mit Excel und Hilfsnummern, die wir vorweg vergaben und nachher durch Q-Nummern austauschten - eine, was Excel als Zwischenmedium anbetrifft, bei 5 Millionen Datensätzen nicht gangbare Option.
  • Unklar ist, wie wir die Namen abbilden - und zwar so, dass nachher der Informationsfluss in die GND gewährleistet ist. Hier ist zu klären, welche Vor- und Nachteile die jetzige Erfassung der Namen als Items hat.
  • Wir sollten in das Projekt nicht ohne eine Gruppe an Mitspielern aus dem Wikidata-Bereich gehen. Unter ihnen sind Mitspieler nötig, die sich bis auf die Software-Code-Stufe hinab mit Wikidata auskennen.
  • Wir treffen uns in einer kleineren Gruppe, um die DNB Versuche und FactGrid-Realitäten eingehender zu betrachten.

--Olaf Simons (talk) 15:07, 13 May 2019 (CEST)

Testlauf 803 Datensätze zu Freimaurer-Logen der GND

Testweise spielte ich die Datensätze zu allen GND-gelisteten Freimaurerlogen ins FactGrid ein - mehr oder minder manuell mit Zwischenschritt über ein Google Spreadsheet und QuickStatements, um zu sehen, wie die Dinge praktisch aussehen. Das Projekt kostete zwei Arbeitstage mit und hat ein paar lose Enden:

Datenauswahl

Die erste Frage war die der besten Ausführung der Datenquelle. Ich entschied mich für die Aufstellung, die sich per Email beziehen ließ, da sie leichter in QuickStatements-Formate zu bringen war. In dieser Google-Satein sind alle Versionen der Arbeit abgelegt:

  1. Data Extract (Hans-Jürgen Becker)
  2. Data by E-Mail
  3. Input - die Liste für die Dateneingabe.

Überführung in Quickstatements

Die Umsetzung für QuickStatements im obigen dritten Blatt brachte die üblichen Hürden, die es attraktiv machen, so eine Arbeit allen Menschen zu ersparen.

  • Anführungszeichen sind hier noch $-Zeichen. $+ muss mit + (bei Daten) im letzten Schritt ersetzt werden, da Kalkulationssoftware hier sonst eigene Tätigkeiten entfaltet.
  • Städte mussten in Q-Nummern verwandelt werden (die letzte, grüne Spalte zeigt die originären Stadtnamen)
  • Manuell mussten die Datumsangaben bearbeitet werden, da GND-Datierungen als Strings abgelegt zu sein scheinen (mal 10.05.1887, mal anders). Hier musste fallspezifisch adaptiert werden. Das Spreadsheet beherrscht zwar Adaptionen, doch agiert es bei verschiedenen Formaten unvorhersehbar und änderte einiges eigenmächtig falsch, was ich erst nachher sah; hier sind jetzt unauffindbare Fehler in den Daten.
  • Die bereits bestehenden 90 FactGrid-Datensätzen zu Logen forderten ein manuelles Matching ein, da die Namenskonventionen von Logen wirr sind.
  • Unklar blieb mir, wie ich am elegantesten mit den Verschachtelungen verfahren soll (Nennungen übergeordneter Organisationen, die ihrerseits bei der Eingabe noch keine Q-Nummer hatten, desgleichen Nennungen von Vorgänger- und Folge-Institutionen). Diese Eingaben sind im Moment zurückgestellt in den drei beigen Spalten.
  • Hab ich zwei Tage später dann doch noch hingekriegt --Olaf Simons (talk) 11:09, 13 September 2019 (CEST)

Fehlermeldungen bei Eingabe

Bei der Eingabe über QuickStatements gab es Fehlermedlungen:

  • Einzelne freie Notizen (P73) sprengten das Zeichenlimit.
  • Bei einzelne Daten waren Tag und Monat vertauscht, hier monierte Wikibase freundlich die unmöglichen Datierungen.

Datenkonsistenz

Mit der Eingabe zeigten sich Daten-Probleme

  • Die GND birgt (wie alle Datenbanken) Doubletten: siehe unsere Item:Q22439, Item:Q81686, Item:Q81716 (dort stehen jetzt jeweils zwei GND-Nummern), oder GND:2089620-7 und 127434-X.
  • Unter den bezogenen Datensätzen befanden sich diverse Nicht-Logen - etwa Bibliotheken von einzelnen Logen oder der Wilhelmsbader Konvent, eigentlich ein Ereignis. Hier müsste überprüft werden, ob man gleich präzise feststellen kann, was für Objekte man erzeugt.
  • Unter den Datensätzen fehlen gleichzeitig Logen, die die GND kennt - prominent die Royal York: GND:251912-4 (von Hand nachgearbeitet) - hier mag die Abfrage nicht die beste gewesen sein.
  • Unter den Datensätzen befinden sich zudem Quasi-Doubletten: Royal York wurde im 1. Weltkrieg umbenannt und erhielt dafür eine neue GND-Nummer. Andererseits erhielt der sehr viel andere Name, der für die Anfangsjahre des Dritten Reichs gewählt wurde keine eigene Nummer. Die GND-Nummern stehen mal für identische Organisationen, mal für wechselnde Namen.
  • https://tinyurl.com/y26vxcku eine Abfrage nach Dubletten

Reflexion

Alles in allem sind genau diese Haken der Grund, weshalb man die GND lieber komplett im FactGrid haben möchte als in fallweisen Daten-Importen. Man kann Menschen, die sowas noch nie gemacht haben, den Import über QuickStatements eigentlich nicht zumuten. Ich vermute, Ihr werdet ähnliche Erfahrungen bei ersten Wikibase-Tests gemacht haben...

Andererseits kann man nun Dinge abbilden. Folgend eine Karte der GND-erfassten Logen (und auch wieder nicht, denn bei gut 300 Orten fehlen Geo-Koordinaten), und ein Tabellen-Auszug:

Unklar ist mir im Moment, wie wir die Datensätze am besten markieren, um sie für einen Austausch mit der GND passend zu machen.

--Olaf Simons (talk) 11:01, 30 August 2019 (CEST)

2019-10-25 WikidataCon Presentation Berlin

Event's website: https://www.wikidata.org/wiki/Wikidata:WikidataCon_2019/Program


  • not a Wikidata tool
  • but our data are openly accessible, really, so someone can feed them into a program - and that's good!
  • Why "our own" Wikibase?
  • Original Research
  • Q-Items for research statements - which allow it projects to present data sets they have created/augmented on a simple SPARQLE-query.
  • We encourage the working hypothesis (on the "how sure is this?" Property we have on each statement.
  • FactGrid is a working tool for research.
  • Our accounts are all clear name, we try to offer them with contact data (easy for academic research where you might have an institute's address to present.
  • First meeting on Dec 1, 2017. We immediately felt that we would want to have the early modern book production in the source - and that required a GND input in the first place.
  • Talks with the DNB started in August and ended in a Memorandum of Understanding in March 2019. FG-Blog
  • ...we are still trying to understand all the problems we are facing with this
  • How is the input done?
  • How do you get from a string- to an item-based resource?
  • How do we match data with Wikidata before doing the input?
  • How do we get rid of duplicate/overlapping data sets?)

Invitation

  1. We need to become part of the Wikidata or rather Wikibase community
  2. You will get data in big masses - so join us if you need a challenge
  3. We will be interesting for special communities - dealing with historical data and with academic institutions
  4. You can do strange things on our database that would otherwise be "original research" - we are a tool. Use us to orgnaise your research (and only in a last step to present it)

Some things on the list - we do need a team for the data input

  • run the database
  • get a better design
  • create new tools
  • get tools working (like the Magnus Manske's reasonator)
Retrieved from "https://database.factgrid.de/w/index.php?title=FactGrid_talk:GND-Daten-Import&oldid=2064769"