Dazu haben sich heute, am 18.4.2024, neun Personen - @acka47, @adelpeuch, Florian Betz (DNB), @Hanna-Lena_Meiners, Jochen Rupp (DNB), @Klaus_Bulle, @Michael_Markert, Sarah Hartmann (DNB) und Simon Göllner (hil.hessen.de) - in einem ersten Treffen ausgetauscht. Es wurde verabredet, die weiteren Diskussionen und Entwicklungen hier im Forum zu dokumentieren und somit auch für weitere Interessierte zu öffnen.
Es sind ja einige verschiedene Komponenten und damit Akteur:innen an dem Ganzen beteiligt, neben der Software OpenRefine und womöglich dem Reconciliation-Protokoll sind das die Datendienste der DNB, insbesondere die SRU-Record-Update-Schnittstelle aber auch damit verbundene Dienste/Tools wie z.B. ein GND-MARC-Validator.
Deshalb soll in einem ersten Schritt erstmal der groben Workflow aus OpenRefine in die GND visualisiert werden, um eine Diskussionsgrundlage zu haben, welche Implementierungsoptionen es gibt und wer an welchen Punkten des Workflows mitarbeiten oder unterstützen kann.
Hier nun wie angekündigt ein mermaid-Diagramm für die grobe Darstellung des Workflows:
flowchart TD
load[Openrefine-Projekt anlegen];
load --> recon[Reconciliation mit GND];
recon --> neuanlage[Senden neuer nicht-reconcilter Entitäten]
recon --> update[Senden neuer Informationen zu bestehenden GND-Entitäten]
update --> validierung[MARC-Validierung]
validierung --> qa[Qualitätscheck und Dublettenprüfung]
neuanlage --> validierung
qa --> ende[GND-Entitäten sind aktualisiert/neu angelegt]
Viel konkreter können wir zu diesem Zeitpunkt nicht werden, es ließe sich höchstens noch die SRU Record Update API als Schreib-API spezifizieren, die MARC-Daten entgegennimmt.
Was die Validität der MARC-Daten angeht, arbeitet die DNB nach Sarahs Aussagen bereits an einem Validator. Ich habe in dem Kontext auf Avram hingewiesen, dass als sich etablierender Standard für die Erstellung von Schemas zur Validierung von MARC-Daten hier sinnvollerweise eingesetzt würde.
Bevor wir Implementierungsdetails besprechen, sollten wir m.E. offene Fragen und mögliche Umsetzungpfade sammeln. Hier sind schonmal die, die bereits angesprochen wurde, es gibt bestimmt noch mehr.
Wird die Update-Funktionalität auf Reconciliation-Protokollebene umgesetzt und genutzt?
Bisher wird das nicht unterstützt, das Thema wurde aber soweit ich weiß in der W3C Entity Reconciliation Community Group bereits andiskutiert. Da wir Vertreter aus der Gruppe mit an Bord haben, ließe sich so eine Protokollerweiterung durchaus realistischerweise im Kontext dieses Gemeinschaftsprojekts umsetzen.
An welcher Stelle wird aus dem OpenRefine-Output das für SRU Record Udpate benötigte MARC21?
Dazu gab es im heutigen Treffen bereits zwei Ideen (und es sind bestimmt weitere Optionen denkbar):
Eine entsprechende Export-Funktionalität könnte für OpenRefine entwickelt werden (was nicht sinnvoll/nötig wäre, wenn Updates über das Reconciliation-Protokoll standardisiert werden).
Ein Web-Service (etwa auf Basis des Metafacture Playground, der auch als API benutzt werden kann) transformiert den OpenRefine-Output nach MARC und gibt das Ergebnis weiter an die Update-Schnittstelle.
Wie werden die Updates auf Qualität und Dubletten geprüft?
Diese Frage lag Sarah Hartmann besonders am Herzen und es wurde heute erwähnt, dass in Wikidata bereits einige Dubletten durch OpenRefine-Updates entstanden sind. (Gibt es dafür irgendwo Zahlen oder eine Veröffentlichung?)
Es gibt bestimmt eine Menge weitere Fragen und Ansätze, die wir hier sammeln können, um uns dann für einen Ansatz zu entscheiden.
Ich habe aus dem Meeting mitgenommen, dass der Abgleich eigener Daten mit der Gemeinsame Normdatei (GND) so standardbasiert wie möglich sein sollte. D.h. die Weiterentwicklung von Schnittstellen und Features innerhalb von openrefine sollte sich daran orientieren, möglichst generisch und damit auch offen für andere Vokabulare zu sein. Das gleiche gilt umgekehrt für die GND: Werkzeuge zur Dublettenprüfung und Validierung sollten möglichst offen für alle anwendbar sein. Vorbild dafür ist die Verbindung zwischen OpenRefine und wikidata.