# RX-P6-011 – WNK FULLTEXT/NATURAL Analysis Report v0.1 **Status:** Analysis / Baseline **Datum:** 2026-09-09 **Scope:** xTree / Wortnetz Kultur (WNK), Discovery Profile `wnk02-v0.1` **Zweck:** Dokumentation des aktuellen empirischen Stands vor weiteren Änderungen an Discovery, Interpretation oder Scoring. --- ## 1. Ziel und Abgrenzung Dieser Report dokumentiert den Ist-Stand der Untersuchung von `FULLTEXT / NATURAL` als zweitem Discovery Step für das Wortnetz Kultur (WNK). Ausgangspunkt ist das Discovery Profile: ```text LEXICAL / EXACT_STRING / ALWAYS ↓ ON_ZERO_RESULTS FULLTEXT / NATURAL ``` Die Analyse soll insbesondere klären: - welchen zusätzlichen Recall `FULLTEXT / NATURAL` gegenüber `EXACT_STRING` erzeugt, - welche fachlich brauchbaren und welche störenden Candidate Results entstehen, - welche wiederkehrenden Failure Modes erkennbar sind, - welche offenen Fragen sich für spätere Discovery Profiles und Interpretation ergeben. Der Report ist ausdrücklich **keine Specification für eine neue Implementierung**. Nicht Gegenstand dieses Reports sind: - eine `FULLTEXT / NATURAL` Scoring Rule, - Änderungen an `wnk02-v0.1`, - eine Entscheidung über konkrete NLP-/Morphology-Komponenten, - Solr, QLever oder VECTOR Discovery, - eine abschließende Bewertung der Vocabulary Coverage des WNK. --- ## 2. Technischer Baseline-Stand ### 2.1 Discovery Profile `wnk02-v0.1` ```text Step 1 family = LEXICAL method = EXACT_STRING condition = ALWAYS Step 2 family = FULLTEXT method = NATURAL condition = ON_ZERO_RESULTS ``` Für xTree wird `FULLTEXT / NATURAL` provider-spezifisch auf `searchMode=fulltextNatural` abgebildet. ### 2.2 Scoring und Evidence Für `LEXICAL / EXACT_STRING` gilt weiterhin `LEXICAL Score v0.1`. Für `FULLTEXT / NATURAL` wird derzeit bewusst **kein Reconcilix Score** erzeugt: ```text CandidateItem.score = NULL CandidateDiscoveryEvidence.step_score = NULL ``` Auch die normalisierte Match Evidence ist für FULLTEXT derzeit noch nicht materialisiert: ```text matched_value = NULL matched_value_role = NULL matched_value_language = NULL ``` Der `DiscoveryResponseSnapshot` bleibt die Raw Evidence des Provider Response. Diese Evidence-Lücke ist bekannt. Vor einer Scoring Rule soll zunächst verstanden werden, welche Match Information xTree/MySQL für FULLTEXT zuverlässig liefern kann. --- ## 3. Untersuchungsdesign Die Untersuchung erfolgte in zwei Stufen. ### 3.1 Exploratives Testset Zunächst wurden 20 gezielt ausgewählte SourceValues verwendet. Diese Fälle dienten der Hypothesenbildung und enthielten unter anderem: - Homonymy und Context, - längere Objektbezeichnungen, - Compounds, - Truncation-Fälle, - potenzielle Cross-Language Matches. ### 3.2 Zufallsstichprobe Anschließend wurden aus einer Liste von ca. 7.000 SourceValues zufällig ca. 200 unvorbereitete SourceValues ausgewählt und unverändert mit `wnk02-v0.1` reconciled. Ziel war ausdrücklich **keine Kuratierung auf bekannte oder erwartete WNK-Treffer**. Damit sollte geprüft werden, ob die im 20er Testset beobachteten Muster auch in realen, unvorbereiteten Daten auftreten. Im analysierten SQL-Dump wurden 201 SourceValues festgestellt. Für die hier betrachteten Größenordnungen ist diese Abweichung unerheblich; bei einer späteren formalen Evaluation sollte das Dataset eindeutig versioniert und die Record-Zahl festgeschrieben werden. --- ## 4. Quantitativer Baseline-Befund der Zufallsstichprobe Für 201 SourceValues ergab sich: | Ergebnis | SourceValues | Anteil | |---|---:|---:| | `EXACT_STRING` liefert Candidate(s) | 140 | 69,7 % | | EXACT = 0, `FULLTEXT / NATURAL` liefert Candidate(s) | 12 | 6,0 % | | EXACT = 0, FULLTEXT = 0 | 49 | 24,4 % | | **Gesamt** | **201** | **100 %** | Funnel: ```text 201 SourceValues │ ├── 140 EXACT_STRING hit │ → FULLTEXT skipped │ └── 61 EXACT_STRING zero │ ├── 12 FULLTEXT/NATURAL hit │ └── 49 FULLTEXT/NATURAL zero ``` ### 4.1 Erste Interpretation `EXACT_STRING` deckt in dieser Zufallsstichprobe bereits knapp 70 % der SourceValues ab. `FULLTEXT / NATURAL` erhöht den beobachteten Candidate Recall um weitere ca. 6 Prozentpunkte auf insgesamt ca. 75,6 %. Diese zusätzliche Candidate Coverage ist jedoch **nicht mit fachlicher Precision gleichzusetzen**. Unter den FULLTEXT Results befinden sich sowohl plausible Candidates als auch Mixed Results und deutlicher Noise. --- ## 5. Positive Referenz: Context-sensitive Homonym Disambiguation Die drei bewusst konstruierten `Bogen`-Fälle zeigen das gewünschte Verhalten besonders deutlich: ```text SourceValue = Bogen │ ├── kein Context │ → Bogen (Architektur) │ → Bogen (Schusswaffe) │ ├── Context = Bauwerk │ → 0 Candidates │ └── Context = Architektur → Bogen (Architektur) ``` Bewertung: - Ohne Context werden beide lexical homonyms geliefert. - Für `Bauwerk` wird kein Candidate erzwungen; ein entsprechender WNK Concept `Bogen (Bauwerk)` existiert nicht. - Mit `Architektur` wird korrekt auf `Bogen (Architektur)` disambiguiert. Diese Gruppe eignet sich als Referenz dafür, dass Reconcilix nicht lediglich einen Search Endpoint kapselt, sondern Context in der Candidate Discovery berücksichtigen kann. --- ## 6. Beobachtete Failure Modes und Discovery-Klassen Die bisherigen Tests zeigen mehrere voneinander unterscheidbare Ursachen für fehlende oder störende Candidate Results. ### 6.1 Function Words / Query Noise #### Fall A ```text Schachtel für ein Haarschneidegerät → 145 Treffer Schachtel Haarschneidegerät → 1 Treffer Schachtel → 1 Treffer Haarschneidegerät → 0 Treffer ``` Der sehr hohe Recall des vollständigen SourceValue wird durch `für` verursacht bzw. entscheidend geöffnet. #### Fall B ```text Medikamentenschachtel mit Ampullen → 12 Treffer Medikamentenschachtel Ampullen → 0 Treffer Medikamentenschachtel → 0 Treffer Ampullen → 0 Treffer mit → 12 Treffer ``` Hier stammen sämtliche FULLTEXT Treffer aus dem Function Word `mit`. Dasselbe Muster trat in der Zufallsstichprobe erneut auf, unter anderem bei: - `Überdecke für Bett` - `Tasse mit Untertasse` Damit ist der Effekt nicht auf die konstruierten Testfälle beschränkt. **Befund:** > Function Words können bei `FULLTEXT / NATURAL` einen hohen, fachlich irrelevanten Recall verursachen. Noch offen ist, auf welcher Ebene ein späteres Function-Word Handling sinnvoll wäre. Es wird derzeit ausdrücklich keine xTree-spezifische Regel wie das pauschale Entfernen einzelner Wörter festgelegt. --- ### 6.2 Language / Cross-Language Match Beispiel: ```text SourceValue: Span FULLTEXT/NATURAL → Match über "two-span" [en] → Candidate: zweischiffig ``` Der zunächst unerwartete Candidate ist technisch durch einen englischsprachigen lexical value erklärbar. Wird nur Deutsch betrachtet, entfällt dieser Candidate. **Befund:** > Cross-Language lexical values können den FULLTEXT Search Space über die Sprache des SourceValue hinaus erweitern und dadurch unerwartete Candidates erzeugen. Ob Language Compatibility später als Filter, Query Constraint oder Scoring Evidence behandelt wird, ist offen. --- ### 6.3 German Compound Decomposition Unter den 49 Fällen mit: ```text EXACT_STRING = 0 FULLTEXT / NATURAL = 0 ``` befindet sich eine auffällig große Gruppe deutscher Compounds, beispielsweise: ```text Regalbrett Unterteller Sägeblatt Steckschlüssel Haarwasser Heugabel Eisenring Schleifpapier Blitzwürfel Stoffband Tabakschneider Honigschleuder Werbebroschüre Tonfigur Seilrolle Ofenring Tellerbrett Bohraufsatz Aktentasche Diaprojektor ``` Weitere komplexere Beispiele sind: ```text Vulkanisierheizform Puppenkaufmannsladen Zahnersatzmittel Spielzeugkaufladenzubehör Nagellackentferner Sonnenschutzmittel Spielzeugmusikcorps ``` #### Kontrolltest mit zehn Compounds Für zehn charakteristische Fälle wurden die Bestandteile separat ausschließlich mit `EXACT_STRING` gegen WNK getestet: | SourceValue | Bestandteil 1 | EXACT | Bestandteil 2 | EXACT | |---|---|---:|---|---:| | Regalbrett | Regal | 2 | Brett | 2 | | Unterteller | Unter | 0 | Teller | 1 | | Sägeblatt | Säge | 1 | Blatt | 1 | | Steckschlüssel | Steck | 0 | Schlüssel | 1 | | Heugabel | Heu | 1 | Gabel | 3 | | Eisenring | Eisen | 1 | Ring | 4 | | Schleifpapier | Schleif | 0 | Papier | 1 | | Tonfigur | Ton | 1 | Figur | 1 | | Tellerbrett | Teller | 1 | Brett | 2 | | Diaprojektor | Dia | 2 | Projektor | 1 | In allen zehn Fällen existiert mindestens ein Bestandteil als EXACT lexical value im WNK. In sieben Fällen liefern sogar beide Bestandteile Treffer. Damit ist für diese Stichprobe gezeigt: ```text Vocabulary Coverage der Bestandteile ✓ Discovery über vollständiges Compound ✗ Discovery nach Compound Decomposition grundsätzlich möglich ``` Besonders relevant sind Fälle wie: ```text Unter + Teller 0 1 Steck + Schlüssel 0 1 Schleif + Papier 0 1 ``` Hier trägt insbesondere das Head Element einen vorhandenen WNK Concept. Andere Fälle können mehrere fachlich relevante Interpretations erzeugen: ```text Tonfigur ├── Ton └── Figur Eisenring ├── Eisen └── Ring ``` **Befund:** > German Compound Decomposition ist eine eigenständige, empirisch belegte Failure Class der aktuellen Discovery. Dies sollte nicht vorschnell als neuer xTree Discovery Method modelliert werden. Eine mögliche spätere Einordnung liegt auf der Interpretation-Ebene: ```text SourceValue "Tonfigur" ↓ Interpretation ├── "Ton" └── "Figur" ↓ Discovery ``` Das vorhandene `InterpretationGraph`-Modell bietet hierfür grundsätzlich eine passende architektonische Richtung. Eine konkrete Umsetzung wird mit diesem Report nicht festgelegt. --- ### 6.4 Morphology / Lemmatization Ein kleinerer Teil der Zero-Fälle deutet zusätzlich auf Morphology hin, beispielsweise: ```text Nieten Brausetabletten fünfteiliges Messerset ``` Hier können Singular/Plural, Flexion und Compound Structure zusammenwirken. Diese Klasse sollte von Compound Decomposition unterschieden werden: ```text Interpretation / Query Preparation ├── Compound Decomposition └── Morphology / Lemmatization ``` Es wird derzeit bewusst keine konkrete technische Lösung wie spaCy festgelegt. --- ### 6.5 Input Normalization / Punctuation In der Stichprobe traten SourceValues auf, die Anführungszeichen als Bestandteil des gespeicherten Strings enthalten, beispielsweise: ```text "Fotografie, schwarz-weiß" "Fotografie, s/w" ``` Beide lieferten weder EXACT noch FULLTEXT Candidates. Dies begründet eine weitere Untersuchungsrichtung: ```text Input Normalization / Punctuation ``` Auch hier wird noch keine Normalization Rule spezifiziert. --- ### 6.6 Vocabulary Coverage / Synonymy – unresolved Einige Zero-Fälle lassen sich anhand der String Structure nicht sinnvoll einer der bisherigen Klassen zuordnen, beispielsweise: ```text Stampfer Schraubzwinge Objektiv Reststück Drogerieartikel Eintrag Creme Schieblehre ``` Für diese Fälle ist bislang lediglich bekannt: ```text EXACT_STRING = 0 FULLTEXT / NATURAL = 0 ``` Nicht geklärt ist, ob: - ein fachlich geeigneter WNK Concept unter anderer Benennung existiert, - Synonymy eine Rolle spielt, - der Concept außerhalb des Scope liegt, - oder tatsächlich Vocabulary Coverage fehlt. Diese Fälle bleiben daher **unresolved**. --- ## 7. FULLTEXT / NATURAL: Useful, Mixed und Noise Bereits das explorative Testset zeigt, dass FULLTEXT unterschiedliche Result Quality erzeugt. ### Plausible / useful Beispiele ```text Ausgefüllter Fragebogen → Fragebogen Wählscheiben-Telefon → Telefon → Handy Fragebogen-Antworten → Fragebogen Wahlplakat, Hindenburg 1932 → Wahlplakat Schulwandbild Biologie → Biologie → Schulwandbild ``` ### Mixed Beispiel ```text Mechanisches Blechspielzeug → Mechanisches Musikinstrument → Verbindungselement → Blechspielzeug ``` `Blechspielzeug` ist fachlich naheliegend, während weitere Candidates zusätzlichen Noise darstellen. ### Noise Beispiele ```text Schachtel für ein Haarschneidegerät → hoher Recall durch "für" Medikamentenschachtel mit Ampullen → Treffer vollständig durch "mit" ``` Die Zufallsstichprobe reproduziert sowohl useful als auch noisy FULLTEXT Behavior. Daraus folgt: > Zusätzlicher Candidate Recall durch FULLTEXT darf nicht mit fachlicher Precision gleichgesetzt werden. Eine quantitative Precision-Messung wurde in dieser Phase noch nicht durchgeführt. --- ## 8. Mehrere sinnvolle Interpretations eines SourceValue Der Fall: ```text Schulwandbild Biologie ├── Schulwandbild └── Biologie ``` ist architektonisch besonders interessant. FULLTEXT findet hier zwei fachlich plausible Concepts, die unterschiedlichen Bestandteilen des SourceValue entsprechen. Ähnliche Strukturen zeigen die Compound Tests: ```text Tonfigur ├── Ton └── Figur ``` Damit entsteht eine Perspektive, in der ein SourceValue nicht zwingend genau eine Search Representation besitzt, sondern mehrere Interpretations erzeugen kann. Dies berührt die bereits vorgesehene Semantik des `InterpretationGraph 1..*`. **Für RX-P6-011 bleibt dies eine Beobachtung.** Es wird daraus noch keine neue Runtime Semantics abgeleitet. --- ## 9. Gesamtbild des aktuellen Search Space Die empirischen Beobachtungen zeigen unterschiedliche Arten, wie der aktuelle Search Space vom fachlich sinnvollen Search Space abweichen kann: ```text Function Words → Search Space zu weit Cross-Language Match → Search Space sprachlich zu weit German Compounds → Search Space zu eng Morphology → Search Representation unzureichend Input Normalization → technische String-Form verhindert/erschwert Match Vocabulary Coverage / Synonymy → noch ungeklärt ``` Dies spricht gegen die Annahme, dass eine einzelne „bessere Suche“ alle Failure Modes lösen kann. Stattdessen stützt der Befund die Reconcilix-Trennung von: - Interpretation, - Discovery Profile, - Discovery Method, - Provider Adapter, - Evidence, - Scoring. --- ## 10. Konsequenzen für Discovery Profile Design Aus RX-P6-011 wird **noch kein `wnk02-v0.2` abgeleitet**. Insbesondere werden vorerst nicht automatisch ergänzt: ```text Language Filter Function-Word Removal Truncation Compound Splitter Morphology ``` Die aktuelle Baseline bleibt: ```text EXACT_STRING ↓ ON_ZERO_RESULTS FULLTEXT / NATURAL ``` Die bisherige Analyse zeigt jedoch, dass spätere Profile den Search Space möglicherweise kontrolliert entlang unterschiedlicher Failure Classes erweitern oder begrenzen müssen. Ein wichtiges Designprinzip zeichnet sich ab: > Discovery Profiles sollten nicht lediglich „mehr suchen“, sondern den Search Space nachvollziehbar und evidenzbasiert verändern. --- ## 11. Offene Fragen ### FULLTEXT Evidence Zu klären ist, welche Information xTree/MySQL zuverlässig als FULLTEXT Evidence bereitstellen kann, insbesondere: ```text matched_value matched_value_language matched_value_role matched_field provider_relevance ``` Lexical Evidence Semantics dürfen nicht ungeprüft auf FULLTEXT übertragen werden. ### Language Zu untersuchen ist, wie Source Language und Vocabulary Term Language bei FULLTEXT kontrolliert werden können und welche Auswirkungen dies auf Recall und Precision hat. ### Function Words Zu klären ist, ob und wo Function-Word Handling stattfinden sollte: - Interpretation, - Query Preparation, - Discovery Profile, - Provider Configuration. Die bisherigen Daten rechtfertigen noch keine konkrete Implementation. ### Compound Decomposition Zu untersuchen sind: - Qualität automatischer Compound Decomposition, - Head/Modifier Semantics, - mehrere mögliche Splits, - Umgang mit Fugenmorphemen, - Evidence für abgeleitete Interpretations, - Verhältnis zum `InterpretationGraph`. ### Morphology Compound Decomposition und Morphology/Lemmatization sollten getrennt untersucht werden. ### Vocabulary Coverage / Synonymy Unresolved Zero-Fälle benötigen punktuelle fachliche Prüfung gegen das WNK, bevor sie als Discovery Failure klassifiziert werden. --- ## 12. Baseline-Fazit Die Kombination aus konstruiertem Testset und zufälliger Stichprobe liefert einen belastbaren ersten empirischen Stand. Für die Zufallsstichprobe gilt: ```text EXACT_STRING hit ≈ 69,7 % zusätzlicher FULLTEXT hit ≈ 6,0 % ZERO nach beiden Steps ≈ 24,4 % ``` Die Qualität der zusätzlichen FULLTEXT Candidates ist heterogen. Vier zentrale Failure Modes sind bereits empirisch sichtbar: 1. **Function Words / Query Noise** 2. **Language / Cross-Language Match** 3. **German Compound Decomposition** 4. **Morphology / Lemmatization** Hinzu kommen: 5. **Input Normalization / Punctuation** 6. **Vocabulary Coverage / Synonymy – unresolved** Besonders wichtig ist der kombinierte Befund: ```text FULLTEXT / NATURAL Function Words → teilweise sehr hoher irrelevanter Recall German Compounds → häufig weiterhin kein Recall, obwohl Bestandteile im Vocabulary vorhanden sind ``` Damit ist `FULLTEXT / NATURAL` als zusätzlicher Discovery Step fachlich interessant, aber nicht als generelle Lösung für lexical mismatch zu verstehen. ### Entscheidung für den Baseline-Stand `wnk02-v0.1` bleibt zunächst **unverändert**. Vor weiteren Änderungen an Discovery Profile oder Scoring sollen die beobachteten Failure Classes als Grundlage für gezielte, getrennte Experimente dienen. --- ## 13. Status nach RX-P6-011 ```text 20 konstruierte SourceValues ↓ Hypothesenbildung ↓ ~200 zufällige unvorbereitete SourceValues ↓ Hypothesen teilweise reproduziert ↓ kontrollierte Einzeltests (Function Words, Language, Compounds) ↓ RX-P6-011 Baseline ↓ NEXT: gezielte Experimente pro Failure Class ``` **RX-P6-011 markiert damit einen Analysis Freeze des aktuellen WNK `FULLTEXT / NATURAL` Baseline-Stands.**