# Discovery Profiles v0.1 -- Konzeptentwurf **Projekt:** Reconcilix\ **Status:** Diskussionspapier / Architekturentwurf\ **Scope:** Dehio -- einfache SourceValues, IG=1\ **Stand:** 2026-09-04 ## 1. Ziel und aktueller Scope Reconcilix soll Candidate Discovery nicht als fest im jeweiligen Adapter verdrahtete Logik behandeln, sondern schrittweise über konfigurierbare Discovery Profiles steuern. Für den nächsten Dehio-Anwendungsfall gilt bewusst eine KISS-Einschränkung: - pro SourceValue wird zunächst mit genau einem InterpretationGraph (IG=1) gearbeitet; - der SourceValue bleibt der zentrale Discovery-Eingang; - ContextItems können abhängig vom Discovery-Verfahren als zusätzliche Evidenz verwendet werden; - Compound Terms, freie Texte und mehrere InterpretationGraphs pro SourceValue werden architektonisch mitgedacht, sind aber nicht Gegenstand der ersten Umsetzung. **IG=1 ist eine Laufzeitkonvention des aktuellen Use Cases, keine Beschränkung des Domänenmodells.** ## 2. Ausgangslage: Discovery darf nicht an RxStore gebunden sein Die bisherige RxStore-Logik enthält fachlich bzw. empirisch gewonnene Matching-Erkenntnisse teilweise direkt im Quellcode. Daneben existiert mit dem historischen Dehio-Hilfsvokabular ein Verfahren, bei dem über kuratierte Begriffe und Mappings eine Normalisierung auf MCT-Ziele erfolgt. Ziel ist nicht, dauerhaft „RxStore A" und „RxStore B" als getrennte Verfahren zu etablieren. Stattdessen soll die fachliche und prozedurale Steuerung soweit sinnvoll aus dem Quellcode herausgelöst werden. Discovery Profiles sollen grundsätzlich provider- bzw. adapterunabhängig beschreibbar sein. Ein Adapter implementiert die technische Ausführung; das Profil beschreibt den fachlich/prozedural gewünschten Ablauf. Beispielhafte Adapter: - RxStore - xTree API - Qdrant - Lobid GND Nicht jede Discovery Method muss von jedem Adapter unterstützt werden. ## 3. Trennung der Ebenen Für die weitere Modellierung werden zunächst folgende Ebenen getrennt: ``` text SourceValue ↓ InterpretationGraph (aktuell IG=1) ↓ InterpretationNode ↓ Discovery Profile ↓ Discovery Step(s) ↓ Adapter / Provider ↓ ReconciliationResult ↓ CandidateItems ``` Dabei gilt: **Interpretation** beschreibt, welche semantische Lesart eines SourceValues untersucht wird. **Discovery Profile** beschreibt, wie für diese Interpretation Kandidaten gesucht werden sollen. **Discovery Method** bezeichnet ein einzelnes Such-/Ermittlungsverfahren. **Discovery Strategy** beschreibt Reihenfolge und Bedingungen mehrerer Discovery Steps. **Adapter** realisiert einen Discovery Step technisch gegenüber einem konkreten Dienst oder lokalen Bestand. Diese Trennung soll verhindern, dass technische Provider, fachliche Interpretation und Ablaufsteuerung semantisch miteinander vermischt werden. ## 4. Input eines Discovery Steps Der Discovery Input wird aus dem Rx-Datenmodell heraus beschrieben und nicht aus Sicht eines einzelnen Providers. Arbeitsmodell: ``` text DiscoveryStep │ ├── INPUT │ ├── SOURCE_VALUE │ │ ├── VALUE │ │ ├── [LANG] │ │ └── PREF_ENTITY_TYPE │ │ │ └── CONTEXT │ ├── ROLE │ ├── TYPE │ └── VALUE │ ├── METHOD ├── CONDITION └── ADAPTER ``` `SOURCE_VALUE` und `CONTEXT` sind Input-Quellen. `LANG`, `PREF_ENTITY_TYPE`, `ROLE` und `TYPE` beschreiben Eigenschaften bzw. Auswahlkriterien des Inputs. `VALUE` ist die jeweilige Nutzlast. Die genaue Modellierung von `LANG` bleibt für v0.1 offen. Insbesondere ist noch nicht entschieden, ob Sprache langfristig als Eigenschaft des SourceValue, des Values oder einer Representation modelliert wird. ## 5. Aktuelle Discovery-Situationen im Dehio-Kontext ### 5.1 Qdrant Qdrant verwendet: ``` text SOURCE_VALUE ├── VALUE ├── [LANG] └── PREF_ENTITY_TYPE CONTEXT ├── ROLE ├── TYPE = Text Context └── VALUE = TEI-Kontext ``` Arbeitsannahme für den aktuellen Auftrag: **Qdrant = SourceValue + TEI-Kontext** TEI ist dabei nicht der semantische Context Type. Der Context Type ist beispielsweise `Text Context`; TEI beschreibt die Repräsentation des Context Values. ### 5.2 RxStore / xTree RxStore und xTree verwenden im aktuellen Dehio-Szenario: ``` text SOURCE_VALUE ├── VALUE └── PREF_ENTITY_TYPE CONTEXT ├── ROLE ├── TYPE = Qualifier └── VALUE ``` Arbeitsannahme: **RxStore / xTree = SourceValue + Qualifier-Kontext** Die bisher im RxStore fest eingebaute Logik soll perspektivisch soweit sinnvoll über Discovery Profiles bzw. externe fachliche Konfiguration steuerbar werden. ### 5.3 Lobid GND Lobid verwendet zunächst: ``` text SOURCE_VALUE ├── VALUE └── PREF_ENTITY_TYPE ``` Arbeitsannahme: **Lobid = SourceValue** ## 6. Discovery Methods und Discovery Strategy Bereits jetzt ist zwischen einzelner Methode und Ablaufstrategie zu unterscheiden. Beispielhafte Methods: ``` text EXACT TOKEN MAPPED_VOCABULARY VECTOR_SIMILARITY ``` Beispielhafte Conditions für eine erste KISS-Version: ``` text ALWAYS ON_ZERO_RESULTS ``` Eine Strategy könnte damit beispielsweise ausdrücken: ``` text Step 1: EXACT condition = ALWAYS Step 2: MAPPED_VOCABULARY condition = ON_ZERO_RESULTS Step 3: TOKEN condition = ON_ZERO_RESULTS ``` Die Reihenfolge ist ausdrücklich noch keine fachliche Festlegung. Insbesondere soll die aktuelle Bezeichnung `exact-with-token-fallback` perspektivisch überprüft werden: Sie verbindet bereits Methode und Strategie in einem technischen Methodennamen. ## 7. Externe fachliche Steuerung und Mapping Das historische Dehio-Hilfsvokabular zeigt einen zweiten Typ fachlicher Steuerung: ``` text SourceValue ↓ Matching gegen kuratierte Terme / Regeln ↓ Mapping ↓ Zielbegriff in MCT ``` Beispiele: ``` text Wohntrakt → Wohnflügel → MCT Hauptburg → Burg → MCT Glashüttensiedlung → Siedlung → MCT ``` Diese Logik soll nicht einfach als weiterer Block in den RxStore-Quellcode übernommen werden. Zielrichtung ist vielmehr: ``` text Discovery Engine + Discovery Profile + externe fachliche Daten / Mappings ``` Dabei muss ein Mapping-Verfahren grundsätzlich 0..n Kandidaten liefern können. Ein lexical pattern darf nicht implizit genau einen fachlich richtigen Candidate erzwingen. Die konkrete Repräsentation externer Mappingregeln und die Semantik historischer Wildcards werden vor einer Implementierung separat festgelegt. ## 8. Use Cases für die Konzeptprüfung ### UC-01 -- einfacher SourceValue ``` text SourceValue: "Kirche" IG: 1 ``` Zweck: Baseline für direkte Discovery ohne notwendige Zerlegung. ### UC-02 -- kuratierte Normalisierung ``` text SourceValue: "Wohntrakt" mögliche Normalisierung: "Wohnflügel" IG: 1 ``` Zweck: Abgrenzung zwischen SourceValue, fachlicher Normalisierung und Candidate Discovery. ### UC-03 -- Compound / historische Mappingregel ``` text SourceValue: "Hauptburg" mögliche Normalisierung: "Burg" IG: 1 im aktuellen Scope ``` Zweck: Prüfung von Mapping-/Pattern-basierten Discovery Steps. ### UC-04 -- mehrdeutige Compound-Regel ``` text SourceValue: "Burgtor" mögliche Treffer: - Burg - Tor ``` Zweck: Sicherstellen, dass Mapping Discovery 0..n Kandidaten erzeugen kann und keine Regel automatisch fachliche Eindeutigkeit behauptet. ### UC-05 -- SourceValue + Qualifier Context ``` text SourceValue: einfacher Dehio-Sachbegriff Context Type: Qualifier IG: 1 Discovery: RxStore / xTree ``` Zweck: Profilgesteuerte Auswahl semantisch typisierten Contexts. ### UC-06 -- SourceValue + Text Context ``` text SourceValue: einfacher Dehio-Sachbegriff Context Type: Text Context Representation: TEI IG: 1 Discovery: Qdrant ``` Zweck: semantische/vectorbasierte Discovery mit zusätzlicher Kontextevidenz. ## 9. Future Architecture Test Cases -- ausdrücklich nicht v0.1 ### FAC-01 -- „Schulwandbild Biologie" ``` text SourceValue: "Schulwandbild Biologie" Expected: IG > 1 möglich Known: mindestens drei fachlich plausible IG-Varianten ``` Dieser Fall wird derzeit nicht gelöst. Er dient als Architekturtest für die spätere Abgrenzung von InterpretationGraphs, InterpretationNodes und Discovery Profiles. ### FAC-02 -- „Der Herr von Bogen ..." ``` text "Der Herr von Bogen geht im Bogen mit dem Bogen über den Bogen." ``` Die identische Zeichenfolge `Bogen` kann abhängig von syntaktischem und semantischem Kontext unterschiedliche Bedeutungen bzw. Entitäten repräsentieren. Auch „über den Bogen" kann beispielsweise auf einen geographischen Eigennamen bzw. ein Gebirge referieren. Der Fall dient als Stress-Test für: - mehrere Interpretationen innerhalb eines SourceValues; - Span-/Segmentbezug; - IG \> 1; - Context-Abhängigkeit; - unterschiedliche Entity Types und Zielvokabulare. Keine Umsetzung im aktuellen Dehio-Scope. ## 10. Controlled Vocabulary / Ontology Outlook Es ist wahrscheinlich, dass die Beschreibung von Discovery Profiles mittelfristig ein kontrolliertes Vokabular und möglicherweise eine kleine Ontologie benötigt. Für v0.1 wird **keine Ontologie auf Vorrat entwickelt**. Stattdessen werden Begriffe und Relationen aus realen Use Cases gesammelt und fachlich stabilisiert. Erste erkennbare Begriffsklassen: ``` text Input Source ├── SOURCE_VALUE └── CONTEXT Input Property ├── VALUE ├── LANG ├── PREF_ENTITY_TYPE ├── ROLE └── TYPE Discovery Method ├── EXACT ├── TOKEN ├── MAPPED_VOCABULARY └── VECTOR_SIMILARITY Execution Condition ├── ALWAYS └── ON_ZERO_RESULTS ``` Bestehende kontrollierte Vokabulare sollen wiederverwendet werden. Insbesondere werden Context Types nicht innerhalb des Discovery-Profile-Vokabulars neu definiert. Provider-/Adapterbezeichnungen sind zunächst technische Konfiguration und nicht automatisch Bestandteil eines fachlichen kontrollierten Vokabulars. Architekturprinzip: > Erst belastbare Anwendungsfälle, daraus stabiles Vokabular, > anschließend Formalisierung. ## 11. Offene Fragen vor einer Implementierung 1. Was ist die genaue fachliche Grenze zwischen Interpretation und Discovery-basierter Normalisierung? 2. Welche heutigen Bestandteile von `exact-with-token-fallback` sind einzelne Methods, welche Strategy und welche fachliche Heuristik? 3. Welche Discovery Methods können providerunabhängig definiert werden? 4. Wie erklärt ein Adapter, welche Methods und Inputtypen er unterstützt? 5. Wie wird Context-Auswahl im Profil referenziert: über Role, Type oder Kombinationen? 6. Wie wird Representation -- insbesondere TEI -- sauber vom semantischen Context Type getrennt? 7. Wie werden externe Mappingbestände versioniert und in einem Run reproduzierbar referenziert? 8. Wie werden mehrere Mappingtreffer, Scores, Rank und Provenienz in CandidateItems abgebildet? 9. Welche Bestandteile eines Discovery Profiles gehören in ein kontrolliertes Vokabular, welche in Konfiguration? 10. Welche Minimalstruktur benötigen wir, damit IG=1 heute einfach bleibt, ohne IG\>1 morgen zu verbauen? ## 12. Nächster Arbeitsschritt Vor Codeänderungen: 1. Ist-Verhalten von RxStore `exact-with-token-fallback` technisch analysieren. 2. Dasselbe Raster auf xTree anwenden. 3. Methods, Strategy, Input-Auswahl und adaptertechnische Details voneinander trennen. 4. Die Use Cases UC-01 bis UC-06 gegen den Entwurf prüfen. 5. Erst danach eine minimale persistierbare/konfigurierbare Struktur für Discovery Profiles festlegen. Damit bleibt die nächste Umsetzung klein, während die Architektur offen genug für Compound Terms, IG\>1 und komplexere Interpretation bleibt.