# Kurzanalyse LA zu Dante Reconciling https://gitlab.gwdg.de/mmarker/dante-reconciliation created_at: 2026-08-04 Sehr interessant – und aus LA-Sicht fast spannender als ich erwartet hatte. Nach Analyse des README und des Python-Skripts komme ich zu folgendem Eindruck: > **DANTE-Reconciliation ist kein eigenständiges Reconciliation-Framework, sondern ein sehr sauber implementierter OpenRefine-Wrapper um die DANTE Search API.** Das ist überhaupt keine Kritik. Der Anspruch des Projekts ist ein völlig anderer als bei Reconcilix. --- # LA-Analyse: DANTE Reconciliation ## 1. Projektziel Das Ziel des Projekts ist ausgesprochen klar: > Bereitstellung der DANTE-Vokabulare als lokaler OpenRefine-Reconciliation-Service. Der eigentliche fachliche Mehrwert liegt in der DANTE Search API. Das Python-Skript übernimmt lediglich * die Manifest-Auslieferung, * die Übersetzung der DANTE-API in den OpenRefine-Standard, * Fuzzy-Ranking, * Data Extension, * Suggest-Services. Damit ist die Architektur ausgesprochen schlank. --- # 2. Architektur Die Architektur lässt sich praktisch auf vier Komponenten reduzieren. ```text OpenRefine ↓ Flask Wrapper ↓ DANTE Search API ↓ JSKOS Daten ``` Der Wrapper besitzt keine Persistenz. Kein Domänenmodell. Keine Runtime. Keine Interpretation. Keine Reconciliation History. Er arbeitet vollständig requestbasiert. --- # 3. Manifest Das Manifest ist erfreulich vollständig. Unterstützt werden: * Reconciliation API Version 0.2 * defaultTypes * Suggest Entity * Suggest Type * Suggest Property * Property Proposal * Data Extension * View URL Nicht vorhanden sind beispielsweise: * Preview * Batch Evaluation * eigene Match-Strategien * erklärbare Scores Das Manifest ist also nahezu das klassische Minimal-Manifest eines modernen OpenRefine-Reconciliation-Services. --- # 4. Typenmodell Positiv überrascht hat mich, dass die verfügbaren Typen nicht fest kodiert sind. Beim Start wird ```python https://api.dante.gbv.de/voc?limit=0 ``` abgerufen. Aus den vorhandenen Vokabularen entstehen automatisch ```text defaultTypes ``` im Manifest. Das ist elegant, weil neue Vokabulare ohne Codeänderung erscheinen. Reconcilix verfolgt hier einen anderen Ansatz, nämlich VocabularyRegistry + DiscoveryConfiguration. Beide Lösungen sind für ihren jeweiligen Einsatzzweck sinnvoll. --- # 5. Ranking Hier wird es interessant. Die Candidate-Ergebnisse kommen vollständig aus der DANTE Search API. Danach erfolgt lediglich ```python fuzz.token_sort_ratio(...) ``` über FuzzyWuzzy (Levenshtein). Also ungefähr ```text API Treffer ↓ Fuzzy Ranking ↓ OpenRefine ``` Das bedeutet: Es existiert keine eigentliche Interpretation. Keine Kontextbewertung. Keine Provenienz. Keine mehrstufige Discovery. --- # 6. Data Extension Der Extend-Teil ist sauber umgesetzt. Nach erfolgreichem Reconciling fragt OpenRefine ```text https://api.dante.gbv.de/data?uri=... ``` ab. Die JSKOS-Daten werden anschließend in das OpenRefine-Format transformiert. Unterstützt werden erstaunlich viele Properties. Das ist für Anwender durchaus komfortabel. --- # 7. Suggest Services Implementiert sind: ```text suggest/entity suggest/type suggest/property ``` Alle drei greifen direkt auf DANTE zurück. Hier findet praktisch keine zusätzliche Logik statt. --- # 8. Bekannte Einschränkungen Der README nennt zwei Punkte, die ich architektonisch interessant finde. ## Additional Properties Properties, die OpenRefine beim Reconciling mitschickt, werden ignoriert. Das heißt, OpenRefine kann zwar ```text Ort Person Datierung ``` mitsenden, der Wrapper verwendet diese Informationen jedoch nicht. Genau hier beginnt Reconcilix. --- ## Data Extension Einige JSKOS-Felder (z.B. broader) werden von der DANTE Search API nicht geliefert, obwohl sie in den Datensätzen vorhanden sind. Das ist keine Einschränkung des Wrappers, sondern der zugrunde liegenden API. --- # 9. Vergleich zu Reconcilix Hier wird der Unterschied besonders deutlich. | Thema | DANTE | Reconcilix | | ------------------------- | ----------------- | ------------------------ | | Ziel | Wrapper für DANTE | Reconciliation Framework | | Persistenz | nein | ja | | Provenienz | nein | ja | | Kontextmodell | nein | ja | | Interpretation | nein | ja | | Discovery Framework | nein | ja | | mehrere Candidate Sources | nein | ja | | Ranking | FuzzyWuzzy | Framework | | Evaluation | nein | ja | | Lernfähigkeit | nein | ja | --- # 10. Was könnte Reconcilix übernehmen? Einige Dinge gefallen mir ausgesprochen gut. ## a) Sehr kleiner Wrapper Das Projekt besitzt praktisch keine unnötige Architektur. Das ist angenehm. Reconcilix sollte bei zukünftigen Adaptern denselben Pragmatismus beibehalten. --- ## b) Dynamische Typen Das automatische Erzeugen der ```text defaultTypes ``` ist elegant. Etwas Ähnliches könnte später für xTree, GND, QLever interessant werden. --- ## c) Saubere JSKOS-Unterstützung Der Extend-Teil ist ordentlich geschrieben. Falls Reconcilix einmal JSKOS direkt anbietet, lohnt sich ein zweiter Blick. --- # 11. Wo Reconcilix deutlich weiter geht Aus meiner Sicht liegen die eigentlichen Innovationen von Reconcilix nicht im OpenRefine-Protokoll. Sie liegen davor. ```text OpenRefine ↓ Reconcilix Interpretation ↓ Discovery ↓ mehrere Candidate Sources ↓ Ranking ↓ Evaluation ↓ Lernschleife ``` DANTE besitzt im Grunde nur ```text OpenRefine ↓ API Wrapper ↓ DANTE ``` Das ist ein grundsätzlich anderer Lösungsansatz. --- # 12. LA-Fazit Ich würde DANTE **nicht als Konkurrenz** ansehen. Ich sehe es eher als > **einen sehr guten Referenz-Wrapper für den OpenRefine-Reconciliation-Standard.** Reconcilix bewegt sich inzwischen auf einer anderen Ebene. Während DANTE einen einzelnen Suchdienst für OpenRefine verfügbar macht, entwickelt Reconcilix eine Plattform zur Interpretation, Discovery und nachvollziehbaren Bewertung von Kandidaten aus mehreren Wissensquellen. ## LA-Empfehlung Ich würde für Reconcilix dennoch zwei Dinge aus DANTE übernehmen: * **Konsequente Einfachheit der Adapter**: Ein Adapter sollte möglichst wenig Logik enthalten und sich auf Protokollumsetzung und Datenabbildung beschränken. * **Vollständige Unterstützung des OpenRefine-Standards**: DANTE zeigt, dass ein schlanker Dienst trotzdem Manifest, Suggest und Data Extension sauber implementieren kann. Alles, was darüber hinausgeht – Interpretation, Provenienz, Evaluation und lernende Strategien – bleibt aus meiner Sicht der eigentliche Mehrwert von Reconcilix.