# RX-P6-013 – Cross-Source Candidate Discovery Comparison v0.1 **Status:** Analysis / Experiment **Datum:** 2026-09-10 **Dataset:** 200 zufällig ausgewählte, nicht vorbereitete SourceValues **Candidate Sources:** WNK, OBG, GND **Reconcilix Profile:** `rx-p-0003` für WNK und OBG **GND Access:** Lobid Subject Heading API **Zweck:** Vergleich unterschiedlicher Candidate Sources bei identischem Input als Grundlage für weitere Discovery-Experimente, Vorträge und die spätere Einbeziehung von Vector- und LLM-basierten Verfahren. --- ## 1. Fragestellung Das Experiment untersucht, wie sich unterschiedliche Candidate Sources bei identischen, realen SourceValues verhalten. Verglichen wurden: ```text SourceValue │ ├── WNK │ └── xTree API / rx-p-0003 │ ├── OBG │ └── xTree API / rx-p-0003 │ └── GND └── Lobid Subject Heading API ``` Für WNK und OBG wurde dasselbe Discovery Profile eingesetzt: ```text rx-p-0003 1. LEXICAL / EXACT_STRING / ALWAYS 2. FULLTEXT / NATURAL / ON_ZERO_RESULTS ``` Damit wird nicht nur der Provider verglichen, sondern bei WNK und OBG auch derselbe Discovery-Prozess auf zwei unterschiedliche Vocabularies angewendet. --- ## 2. Methodische Abgrenzung Die SourceValues wurden nicht für das Experiment vorbereitet oder kuratiert. Nicht verglichen wurden: - Provider Scores als gemeinsame fachliche Confidence, - ein einheitliches Reconcilix Scoring über alle Candidate Sources, - eine abschließende fachliche Precision, - Vector Search, - LLM-basierte Reconciliation. Der Versuch misst zunächst insbesondere: - Candidate Hit / Zero Result, - Candidate Count, - Überschneidungen zwischen Candidate Sources, - qualitative Unterschiede einzelner Result Sets, - wiederkehrende Failure Modes. Provider Scores dürfen nicht unmittelbar gegeneinander interpretiert werden, da ihre Semantik unterschiedlich ist. --- ## 3. Quantitativer Gesamtbefund | Candidate Source | SourceValues mit Candidate | Zero | Hit Rate | Candidates gesamt | |---|---:|---:|---:|---:| | **WNK** | **154** | 46 | **77 %** | 235 | | **OBG** | **148** | 52 | **74 %** | 195 | | **GND** | **130** | 70 | **65 %** | 412 | ### Erste Interpretation WNK weist in dieser Stichprobe die höchste Hit Rate auf, dicht gefolgt von OBG. GND liefert für weniger SourceValues Candidates, erzeugt bei Treffern aber deutlich größere Candidate Sets. Durchschnittliche Candidate-Anzahl pro Hit: ```text WNK ≈ 1,53 OBG ≈ 1,32 GND ≈ 3,17 ``` Damit zeigt GND ein breiteres Candidate-Verhalten als WNK und OBG. --- ## 4. Union und Überschneidung der Candidate Sources Die Kombinationen verteilen sich wie folgt: | Kombination | SourceValues | |---|---:| | **WNK + OBG + GND** | **104** | | WNK + OBG, nicht GND | 26 | | WNK + GND, nicht OBG | 13 | | OBG + GND, nicht WNK | 9 | | nur WNK | 11 | | nur OBG | 9 | | nur GND | 4 | | **kein Candidate bei allen drei** | **24** | Damit liefern die drei Candidate Sources gemeinsam für: ```text 176 / 200 = 88 % ``` mindestens einen Candidate. WNK und OBG allein decken bereits ab: ```text 172 / 200 = 86 % ``` GND erhöht die reine Hit Coverage damit um weitere vier SourceValues. Diese Zahl sagt jedoch noch nichts über die fachliche Qualität der GND Candidates bei den vielen gemeinsamen Treffern aus. --- ## 5. Verhalten von `rx-p-0003` bei WNK und OBG Das gleiche Discovery Profile verhält sich gegen beide xTree Vocabularies strukturell ähnlich: | Discovery Result | WNK | OBG | |---|---:|---:| | `EXACT_STRING` Hit | 140 | 135 | | zusätzlicher `FULLTEXT / NATURAL` Hit | 14 | 13 | | Gesamt | 154 | 148 | Der FULLTEXT Step erhöht die Candidate Coverage damit: ```text WNK: 140 → 154 OBG: 135 → 148 ``` Dies ist ein wichtiger Befund für die Profile-Semantik: Dasselbe Profile kann gegen unterschiedliche Vocabularies eingesetzt und vergleichbar beobachtet werden. --- ## 6. EXACT Complementarity zwischen WNK und OBG Für `EXACT_STRING` ergibt sich: ```text EXACT in WNK + OBG 114 EXACT nur WNK 26 EXACT nur OBG 21 EXACT in keinem 39 ``` WNK und OBG liefern zusammen für: ```text 161 / 200 = 80,5 % ``` mindestens einen EXACT Match. ### Interpretation Die beiden Vocabularies sind nicht redundant. Sie ergänzen sich bereits auf der einfachsten Discovery-Stufe deutlich. Dies stützt eine zentrale Reconcilix-Annahme: > Candidate Discovery sollte mehrere Candidate Sources kombinieren können, statt ein einzelnes Vocabulary als alleinige Suchbasis zu behandeln. --- ## 7. Vocabulary Coverage versus Discovery Failure Ein wichtiger Befund ergibt sich aus dem Vergleich mit der vorherigen WNK-Analyse. Mehrere SourceValues, die bei WNK als Compound-/Zero-Fälle auffällig waren, werden in OBG als vollständiger Begriff per `EXACT_STRING` gefunden, unter anderem: ```text Schleifpapier Blitzwürfel Kneifzange Seilrolle Heugabel Honigschleuder Steckschlüssel Tabakschneider Schraubzwinge ``` Beispiel: ```text SourceValue: Steckschlüssel WNK → Compound als Ganzes nicht gefunden → Bestandteil "Schlüssel" vorhanden OBG → "Steckschlüssel" als Concept vorhanden → EXACT_STRING ``` ### Konsequenz Ein Zero Result darf nicht automatisch als technische Discovery-Schwäche interpretiert werden. Es sind mindestens zwei Fälle zu unterscheiden: ```text A) Concept ist im Vocabulary vorhanden, wird aber durch die aktuelle Query nicht gefunden B) Concept ist im Vocabulary nicht in dieser Form vorhanden, ein anderes Vocabulary besitzt ihn jedoch ``` Damit gewinnt die Trennung von **Vocabulary Coverage** und **Discovery Behavior** an Bedeutung. --- ## 8. GND als semantisch andersartige Candidate Source Die vier GND-only Fälle zeigen besonders deutlich, dass GND nicht lediglich zusätzliche lexikalische Treffer liefert: ```text Nieten → Nieten Unterteller → Untertasse Tonfigur → Terrakotta Restholz → Holzabfall ``` Diese Beispiele repräsentieren unterschiedliche Beziehungen: ```text Nieten → Nieten lexical sehr nah Unterteller → Untertasse Synonymy / begriffliche Nähe Restholz → Holzabfall semantische Normalisierung Tonfigur → Terrakotta stärkere fachliche Interpretation ``` ### Interpretation Candidate Sources unterscheiden sich nicht nur in der Menge ihrer Treffer. Sie unterscheiden sich auch darin, **welche semantische Beziehung zwischen SourceValue und Candidate hergestellt wird**. Dies ist für spätere Scoring- und Decision-Verfahren wichtiger als eine reine Hit Rate. --- ## 9. FULLTEXT / NATURAL – reproduzierte Befunde Auch im Cross-Source Experiment bestätigen sich Erkenntnisse aus RX-P6-011. ### Positive Beispiele ```text Türschloß → Türschloss ``` oder bei längeren Source Strings sinnvolle Teilmatches. ### Mixed Results Ein SourceValue kann gleichzeitig sinnvolle und irrelevante FULLTEXT Candidates erzeugen. Beispiel: ```text Tasse mit Untertasse → Tasse → Untertasse → zusätzlich fachlich irrelevante Candidates ``` ### Function Words / Query Noise Das bereits bekannte Verhalten von Function Words reproduziert sich auch gegen ein zweites xTree Vocabulary. Beispiel: ```text Überdecke für Bett ``` führt sowohl gegen WNK als auch gegen OBG zu stark verbreiterten FULLTEXT Result Sets. Damit ist der Befund: > Function-Word Noise ist kein WNK-spezifisches Phänomen, sondern entsteht im verwendeten FULLTEXT/NATURAL Discovery-Verhalten provider-/queryseitig. --- ## 10. Gemeinsame Zero-Gruppe Bei 24 SourceValues liefern weder WNK noch OBG noch GND einen Candidate. Diese Gruppe ist besonders interessant für weitere Experimente. Sie enthält unter anderem erneut komplexe oder zusammengesetzte Bezeichnungen. Für kommende Vector- und Interpretation-Experimente eignet sich diese Gruppe als Kontrollmenge: ```text WNK = ZERO OBG = ZERO GND = ZERO ↓ Vector Candidate Discovery? LLM-assisted Reconciliation? Compound Interpretation? ``` Die Frage lautet dabei nicht nur: > Findet ein weiteres Verfahren überhaupt etwas? sondern vor allem: > Liefert es einen fachlich plausiblen Candidate, obwohl drei etablierte Candidate Sources leer bleiben? --- ## 11. Runtime Evidence Mit RX-P6-012 und RX-P6-012b wird nun auch für Direct Discovery über Lobid/GND grundlegende Runtime Evidence gespeichert. Damit stehen providerübergreifend unter anderem zur Verfügung: ```text ReconciliationRunItem DiscoveryStepExecution CandidateDiscoveryEvidence CandidateItem ``` Dies ist eine wichtige Voraussetzung für systematische Cross-Source Experimente. Die Evidence-Semantik bleibt dennoch providerabhängig: - WNK / OBG besitzen profile-basierte Step Evidence. - GND wird aktuell als `direct-discovery` ausgeführt. - Provider Scores besitzen unterschiedliche Bedeutungen. - `matched_value*` ist nicht für alle Candidate Sources verfügbar. --- ## 12. Zentrale Ergebnisse ### Ergebnis 1 – Multi-Source Discovery erhöht Coverage ```text WNK 77 % OBG 74 % GND 65 % Union 88 % ``` Kein einzelner Candidate Source erreicht die Coverage der Kombination. --- ### Ergebnis 2 – WNK und OBG sind komplementär Obwohl beide über dieselbe xTree API und dasselbe Profile abgefragt werden, ergänzen sie sich deutlich. Bereits auf EXACT-Ebene: ```text nur WNK EXACT 26 nur OBG EXACT 21 ``` --- ### Ergebnis 3 – Vocabulary Coverage und Discovery Behavior müssen getrennt werden Ein Zero in einem Vocabulary kann bedeuten: ```text kein Concept vorhanden ``` oder: ```text Concept vorhanden, aber aktuelle Discovery Representation reicht nicht ``` Der Vergleich WNK ↔ OBG macht diese Trennung sichtbar. --- ### Ergebnis 4 – GND liefert andere semantische Beziehungen GND ergänzt nicht nur weitere Treffer, sondern teilweise alternative begriffliche Normalisierungen und semantische Beziehungen. --- ### Ergebnis 5 – FULLTEXT erhöht Recall, aber nicht automatisch Precision `FULLTEXT / NATURAL` liefert zusätzliche sinnvolle Candidates, reproduziert aber zugleich bekannte Noise-Mechanismen. --- ### Ergebnis 6 – 24 gemeinsame Zero-Fälle bilden eine wertvolle Kontrollgruppe Diese Fälle sind besonders geeignet, um Vector Search, LLM-Verfahren und Interpretation-Methoden gegen die bestehende Baseline zu testen. --- ## 13. Visualisierbare Kernaussagen für Vorträge ### Candidate Coverage ```text WNK ███████████████████████████████████████ 77 % OBG █████████████████████████████████████ 74 % GND ████████████████████████████████ 65 % UNION ████████████████████████████████████████████ 88 % ``` ### Kernaussage > Nicht die beste einzelne Suchmaschine ist das Ziel, sondern die kontrollierte Kombination unterschiedlicher Candidate Sources. ### Zweite Kernaussage > Unterschiedliche Candidate Sources liefern nicht nur unterschiedlich viele Treffer – sie bilden unterschiedliche Vocabulary Coverage und unterschiedliche semantische Beziehungen ab. ### Dritte Kernaussage > Reconcilix trennt Candidate Discovery, Runtime Evidence und spätere fachliche Bewertung. Dadurch können unterschiedliche Discovery-Verfahren vergleichbar experimentiert werden. --- ## 14. Nächste Experimente ### Experiment A – MCT-Tag Vergleich innerhalb des MCT-Kontexts: ```text xTree API / WNK / rx-p-0003 vs. RxStore / MappedVocabulary / MCT vs. VectorSearch / MCT / TEI Context ``` Ziel: > Unterschiede zwischen lexical API Discovery, lokalem MappedVocabulary und Vector Candidate Discovery verstehen. --- ### Experiment B – Cross-Source Erweiterung um MCT Die 200 SourceValues können zusätzlich gegen MCT ausgewertet werden. Damit entsteht: ```text WNK OBG GND MCT ``` und insbesondere die Frage: ```text Was liefert MCT für die 24 bisherigen Triple-Zero-Fälle? ``` --- ## 15. Perspektive: LLM-basierte Reconciliation Das Cross-Source Experiment schafft eine sehr gute Grundlage für einen späteren LLM-basierten Versuch. Wichtig ist dabei die methodische Einordnung: Wenn ein LLM die bereits gefundenen Candidates aus WNK, OBG und GND sowie deren Metadaten/Definitionen erhält und daraus ein Matching auswählt, handelt es sich zunächst **nicht um eine zusätzliche Candidate Discovery Source**. Es handelt sich vielmehr um: ```text Candidate Sources │ ├── WNK ├── OBG └── GND ↓ Candidate Set + Evidence ↓ LLM-based Candidate Evaluation / Decision ↓ Match / No Match / Uncertain ``` Das wäre ein sehr interessantes eigenständiges Reconcilix-Verfahren. ### Möglicher Input pro SourceValue ```text SourceValue ContextItems, falls vorhanden WNK Candidates - URI - label - qualifier - definition - discovery evidence - rank / score OBG Candidates - URI - label - qualifier - definition - discovery evidence - rank / score GND Candidates - URI - label - available metadata - provider rank / score ``` Für WNK und OBG können dabei die vorhandenen xTree JSON-Daten inklusive Definitions verwendet werden. ### Erwarteter strukturierter Output Beispielsweise: ```json { "decision": "MATCH", "candidateUri": "...", "candidateSource": "WNK", "confidence": 0.0, "reason": "...", "alternativeCandidateUris": [], "evidenceUsed": [], "abstainReason": null } ``` Wichtig wäre ein explizites: ```text MATCH NO_MATCH UNCERTAIN ``` Das LLM darf also nicht gezwungen werden, immer einen Candidate auszuwählen. ### Zwei Experimente sollten getrennt werden #### LLM-01 – Candidate Evaluation Das LLM darf ausschließlich aus den durch WNK, OBG und GND gelieferten Candidates auswählen oder `NO_MATCH / UNCERTAIN` zurückgeben. ```text closed candidate set ``` Damit lässt sich testen: > Kann ein LLM aus mehreren Candidate Sources einen fachlich besseren resultierenden Match ableiten? #### LLM-02 – Candidate Expansion Erst in einem späteren Experiment darf das LLM einen neuen Candidate vorschlagen, der nicht in den gelieferten Candidate Sets enthalten ist. ```text open candidate set ``` Dies wäre methodisch deutlich riskanter und sollte getrennt evaluiert werden. --- ## 16. Gesamtfazit Das Experiment ist als erster Cross-Source Vergleich erfolgreich. Es zeigt gleichzeitig: ```text Multi-Source Candidate Discovery ↓ höhere Coverage + unterschiedliche Vocabulary Coverage + unterschiedliche semantische Beziehungen + unterschiedliches Noise-Verhalten ``` Damit entsteht eine belastbare Grundlage für die nächsten Reconcilix-Phasen: ```text lexical / fulltext ↓ multi-source comparison ↓ vector discovery ↓ LLM-based candidate evaluation ``` Die zentrale architektonische Stärke liegt dabei nicht darin, einen einzelnen „besten“ Matcher festzulegen, sondern unterschiedliche Verfahren mit expliziter Runtime Evidence systematisch vergleichen, kombinieren und evaluieren zu können.