# PRE_WP3-001 – Architekturübersicht Discovery Framework - **Status:** Accepted - **Version:** 0.2 - **Datum:** 30.07.2026 - **Autor:** ED - **Review:** LA - **Scope:** WP3 – Candidate Discovery - **Referenzen:** - ADR002 – Source Delivery Model - DM001 – Domain Model - DM002 – Persistence Model --- # 1. Ziel Dieses Dokument beschreibt die Architektur des Discovery Frameworks. Das Discovery Framework stellt Reconcilix einen einheitlichen Mechanismus zur Verfügung, um zu einem Quellwert geeignete Candidate Items aus einem Target Vocabulary zu ermitteln. Dabei trennt das Framework fachliche Discovery-Entscheidungen konsequent von deren technischer Umsetzung. Dieses Dokument beschreibt ausschließlich die Architektur des Discovery Frameworks sowie die Verantwortlichkeiten seiner Komponenten. Implementierungsdetails und konkrete Technologien sind ausdrücklich nicht Bestandteil dieses Dokuments. --- # 2. Ausgangslage Reconcilix soll langfristig unterschiedliche Target Vocabularies sowie verschiedene Verfahren zur Candidate Discovery unterstützen. Hierzu gehören beispielsweise: - xTree - Local Reconciliation Store - SPARQL-Endpunkte - Search Services (z. B. lobid, Nominatim oder Overpass) - Vector Databases - zukünftige KI-gestützte Discovery Services Obwohl sich diese Systeme technisch erheblich unterscheiden, soll die fachliche Arbeitsweise von Reconcilix unabhängig von der jeweiligen Implementierung bleiben. Die Application Layer soll Candidate Items anfordern können, ohne Kenntnisse über technische Schnittstellen, Kommunikationsprotokolle oder Antwortformate der angebundenen Systeme besitzen zu müssen. Das Discovery Framework trennt deshalb konsequent zwischen fachlichen Discovery-Entscheidungen und deren technischer Umsetzung. Dadurch können zusätzliche Discovery-Verfahren integriert werden, ohne die bestehende Anwendungslogik verändern zu müssen. --- # 3. Architekturübersicht Das Discovery Framework verarbeitet jede Discovery-Anfrage anhand einer konfigurierbaren Discovery Route. Eine Discovery Route beschreibt, wie Candidate Items für ein bestimmtes Target Vocabulary ermittelt werden. Hierzu kombiniert sie drei voneinander unabhängige Architekturbausteine: - Candidate Source - Discovery Method - Technical Adapter Die Application Layer übergibt ausschließlich das gewünschte Target Vocabulary. Das Discovery Framework ermittelt daraus die passende Discovery Route und delegiert die Anfrage an den zugehörigen Technical Adapter. ```text CandidateDiscoveryPort │ ▼ CandidateDiscoveryRouter │ ▼ DiscoveryConfigurationRegistry │ ▼ Discovery Route ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ Candidate Source Discovery Method Technical Adapter │ ▼ CandidateDiscoveryAdapter │ ▼ CandidateItem[] ``` Die technische Umsetzung der Candidate Discovery ist vollständig innerhalb der Technical Adapter gekapselt. Dadurch bildet das Discovery Framework die architektonische Grenze zwischen der fachlichen Domäne von Reconcilix und den angebundenen Vokabularsystemen. # 4. Discovery Route Eine Discovery Route beschreibt, wie Candidate Items für ein bestimmtes Target Vocabulary aus einer Candidate Source ermittelt werden. Jede Discovery Route besteht aus drei unabhängigen Bausteinen: - Candidate Source - Discovery Method - Technical Adapter Diese drei Bausteine können unabhängig voneinander kombiniert werden. Dadurch können unterschiedliche Discovery-Strategien konfiguriert werden, ohne Änderungen an der Application Layer oder der Fachlogik vornehmen zu müssen. Beispiele: | Target Vocabulary | Candidate Source | Discovery Method | Technical Adapter | |-------------------|------------------|------------------|-------------------| | MCT | xTree | Exact Lookup | xTree REST Adapter | | GND | lobid | Search | Lobid REST Adapter | | MCT | Local Reconciliation Store | Exact Lookup | Local Reconciliation Store Adapter | Die Discovery Route beschreibt ausschließlich die fachliche Konfiguration der Candidate Discovery. Die technische Umsetzung erfolgt vollständig innerhalb des jeweiligen Technical Adapters. --- # 5. Komponenten ## CandidateDiscoveryRouter Der CandidateDiscoveryRouter bildet den Einstiegspunkt des Discovery Frameworks. Er nimmt Discovery-Anfragen aus der Application Layer entgegen, ermittelt die passende Discovery Route und delegiert die Verarbeitung an den entsprechenden Technical Adapter. Der Router enthält keine Kenntnisse über technische Schnittstellen einzelner Vokabularsysteme. --- ## DiscoveryConfigurationRegistry Die DiscoveryConfigurationRegistry verwaltet sämtliche Discovery Routes. Für jedes unterstützte Target Vocabulary liefert sie die zugehörige Discovery Route. Dadurch werden Discovery-Konfigurationen zentral verwaltet und können unabhängig von der Programmlogik erweitert oder angepasst werden. --- ## Candidate Source Die Candidate Source beschreibt die fachliche Herkunft der Candidate Items. Sie beantwortet die Frage: > Aus welchem Wissensbestand sollen Candidate Items ermittelt werden? Beispiele sind xTree, Local Reconciliation Store oder externe Discovery Services. Die Candidate Source enthält keine technischen Implementierungsdetails. --- ## Discovery Method Die Discovery Method beschreibt das fachliche Verfahren zur Candidate Discovery. Sie beantwortet die Frage: > Mit welchem Verfahren sollen Candidate Items ermittelt werden? Beispiele sind: - Exact Lookup - Prefix Search - Fulltext Search - Vector Similarity Search Die konkrete technische Umsetzung bleibt Aufgabe des Technical Adapters. --- ## Technical Adapter Der Technical Adapter kapselt sämtliche technischen Details eines Discovery-Systems. Zu seinen Aufgaben gehören insbesondere: - Kommunikation mit externen Systemen - Authentifizierung - Protokolle und Datenformate - Fehlerbehandlung - Transformation der Antworten in Candidate Items Dadurch bleibt die Fachlogik vollständig von technischen Schnittstellen entkoppelt. --- # 6. Laufzeitablauf Zur Laufzeit verarbeitet das Discovery Framework eine Discovery-Anfrage in folgenden Schritten: 1. Die Application Layer übergibt das Target Vocabulary an den CandidateDiscoveryRouter. 2. Der CandidateDiscoveryRouter lädt aus der DiscoveryConfigurationRegistry die passende Discovery Route. 3. Die Discovery Route konfiguriert Candidate Source, Discovery Method und Technical Adapter. 4. Der Technical Adapter führt die Candidate Discovery aus. 5. Die Ergebnisse werden in Candidate Items transformiert. 6. Die Candidate Items werden an die Application Layer zurückgegeben. Damit bleibt der vollständige Discovery-Prozess unabhängig von den jeweiligen technischen Eigenschaften der angebundenen Discovery-Systeme. # 7. Erweiterbarkeit Die Architektur des Discovery Framework ist so konzipiert, dass neue Candidate Sources, Discovery Methods und Technical Adapter ergänzt werden können, ohne bestehende Application Services anzupassen. Die Erweiterung erfolgt durch das Hinzufügen neuer Discovery Routes sowie der zugehörigen Technical Adapter. Dadurch kann Reconcilix zukünftige Discovery-Technologien schrittweise integrieren, ohne die grundlegende Architektur des Frameworks zu verändern. --- # 8. Out of Scope Die folgenden Themen sind ausdrücklich nicht Bestandteil von WP3 und werden in diesem Dokument nicht betrachtet: - Kombination mehrerer Discovery Routes innerhalb einer Discovery-Anfrage - Ranking oder Fusion von Candidate Lists aus unterschiedlichen Candidate Sources - Parallele Ausführung mehrerer Discovery Methods - Bewertung der Qualität von Candidate Items - Provenance-Informationen zur Candidate Discovery - Konfiguration komplexer Discovery Pipelines Diese Themen können in zukünftigen Work Packages ergänzt werden, ohne die hier beschriebene Architektur grundlegend zu verändern. --- # 9. Auswirkungen auf WP3 Für die Implementierung von WP3 ergeben sich folgende Anforderungen: - Einführung eines CandidateDiscoveryRouter als Einstiegspunkt des Discovery Frameworks - Einführung einer DiscoveryConfigurationRegistry zur Verwaltung der Discovery Routes - Einführung des Architekturkonzepts Discovery Route - Trennung von Candidate Source, Discovery Method und Technical Adapter - Umsetzung der technischen Kommunikation ausschließlich innerhalb der Technical Adapter - Transformation externer Ergebnisse in Candidate Items innerhalb der Technical Adapter Mit diesen Architekturbausteinen steht eine erweiterbare Grundlage für die Candidate Discovery zur Verfügung, ohne die bestehende Application Layer an technische Details einzelner Vokabularsysteme zu koppeln.