# RX-DP-001 – Phase 1+2: Regelinventar und Dehio-Mapping **Projekt:** Reconcilix **Stand:** 2026-09-05 **Basis:** `reconcile_20260905_0.zip` + aktuelles Dehio-Hilfsvokabular **Status:** Analyse / noch keine Runtime-Änderung ## 1. Ziel Ziel des Refactorings ist: > **Keine fachlichen Sonderregeln im Reconcilix-Quellcode.** Der heutige RxStore enthält im Verfahren `exact-with-token-fallback` generische Textnormalisierung, heuristische linguistische Verarbeitung, Dehio-spezifisches Fachwissen und Rankinglogik in einem Ablauf. Diese Bestandteile werden getrennt. Zielstruktur: ```text A GENERIC_NORMALIZATION providerunabhängig, fachlich neutral B GENERIC_DISCOVERY providerunabhängige Discovery Methods C DEHIO_MAPPING intellektuell erzeugtes Fachwissen in externer Mapping Resource D RANKING getrennte technische Bewertung / Sortierung E LEGACY_UNCLEAR nicht übernehmen, bevor die Semantik geklärt ist ``` Die erste produktive Zielstrategie für Dehio bleibt: ```text Step 1 family: LexicalDiscoveryMethod method: EXACT_STRING condition: ALWAYS Step 2 family: MappingDiscoveryMethod method: MAPPED_VOCABULARY resource: Dehio-Hilfsvokabular condition: ON_ZERO_RESULTS ``` `Mapping` bezeichnet dabei den intellektuellen Prozess der fachlichen Zuordnung. `MAPPED_VOCABULARY` ist die automatische Discovery Method, die eine bereits erzeugte Mapping Resource nutzt. --- ## 2. Ist-Bestand im Quellcode Relevante Klassen: ```text src/Util/TextNormalizer.php src/ReconciliationStore/QueryTokenizer.php src/Provider/LocalStore/ReconciliationStoreProvider.php ``` Der aktuelle Ablauf lautet vereinfacht: ```text SourceValue ↓ TextNormalizer::normalize() Exact lookup im lokalen terms.json ↓ bei 0 Treffern QueryTokenizer::analyze() ├─ Abkürzungsexpansion ├─ Bindestrichzerlegung ├─ Tokenisierung ├─ Weak-token filtering ├─ manuelle Singularformen ├─ pauschale s-Singularisierung ├─ Dehio-/Objekttyp-spezifische Compound-Suffixe └─ Gewichte 0.55 / 0.68 / 0.78 ↓ Candidate grouping + ranking ↓ Qualifier filter ``` `exact-with-token-fallback` ist daher bereits eine versteckte Strategy und keine einzelne Discovery Method. --- ## 3. Regelmatrix ### 3.1 `TextNormalizer` | Ist-Regel | Beispiel | Klassifikation | Ziel | |---|---|---|---| | `trim()` | Leerraum außen | GENERIC_NORMALIZATION | behalten | | Kleinschreibung | `Kirche` → `kirche` | GENERIC_NORMALIZATION | behalten | | Umlaut-/ß-Transliteration | `Türme` → `tuerme` | GENERIC_NORMALIZATION | behalten, aber als explizite Normalization Policy dokumentieren | | Mehrfach-Whitespace | `a b` → `a b` | GENERIC_NORMALIZATION | behalten | | Sonderzeichen entfernen | Interpunktion → Leerraum | GENERIC_NORMALIZATION mit Prüfung | nur klar definierte Zeichenbehandlung behalten | | Klammerinhalt vollständig entfernen | `Magazin (Bauwerk)` → `magazin` | LEGACY_UNCLEAR | **nicht als generische Regel festschreiben**; Klammerinhalt kann semantisch relevant sein | | Bindestrich erhalten | `Pfarr-Kirche` | GENERIC_NORMALIZATION | konsistent mit Discovery Methods definieren | **Bewertung:** Der `TextNormalizer` ist fast generisch, aber das Entfernen kompletter Klammerinhalte ist eine semantisch riskante Sonderregel und sollte nicht unbesehen Teil von `EXACT_STRING` bleiben. ### 3.2 Abkürzungsexpansion Aktuell hart codiert: ```text kath → katholisch ev → evangelisch evang → evangelisch st → sankt hl → heilig hll → heilig ehem → ehemalig ``` Klassifikation: **LINGUISTIC_NORMALIZATION / DOMAIN NORMALIZATION**, nicht Dehio-Mapping auf ein Zielkonzept. Empfehlung: - aus `QueryTokenizer` entfernen; - nicht ins MCT-Mappingvokabular verschieben; - später als externe/konfigurierbare Abbreviation Resource oder definierte Normalization Method behandeln; - bis dahin nicht Voraussetzung für `EXACT_STRING` machen. ### 3.3 Bindestrichzerlegung und Tokenisierung Aktuell: ```text Pfarr-Kirche → Pfarr Kirche Whitespace → Tokens ``` Klassifikation: **LINGUISTIC_NORMALIZATION / TOKENIZATION**. Empfehlung: - nicht fachlich im RxStore verdrahten; - als generisches linguistisches Verfahren behandeln; - keine Dehio-spezifischen Wörter in der Tokenizer-Implementierung. ### 3.4 Weak Tokens / Stopword-Liste Aktuell u. a.: ```text der die das ... und oder mit ohne von vom ... sankt heilig katholisch evangelisch ehemalig hoch seiten ``` Klassifikation: **gemischt**. - grammatische Funktionswörter: potenziell generische Stopword Resource; - `sankt`, `heilig`, `katholisch`, `evangelisch`, `ehemalig`, `hoch`, `seiten`: fachlich/linguistisch kontextabhängig und nicht generisch als „wertlos“ anzusehen. Empfehlung: aktuelle Liste **nicht** 1:1 übernehmen. Stopwords müssen extern konfigurierbar bzw. sprachbezogen sein. Keine Dehio-Sonderliste im Code. ### 3.5 Manuell gepflegte Singular-/Normalisierungsformen Aktuell: ```text altaere → altar seitenaltaere → altar hochaltaere → altar kapellen → kapelle kirchen → kirche tuerme → turm fenster → fenster figuren → figur reliefs → relief denkmaeler → denkmal brunnen → brunnen ``` Klassifikation: überwiegend **DEHIO_MAPPING bzw. fachlich kuratierte Normalisierung**, nicht generische Morphologie. Besonders deutlich: ```text Seitenaltäre → Altar Hochaltäre → Altar ``` Dies ist eine fachliche Generalisierung, keine bloße Singularbildung. Empfehlung: - aus dem Quellcode entfernen; - wo ein entsprechender Begriff im Dehio-Hilfsvokabular bereits existiert, Varianten dort als `altLabel`/Pattern pflegen; - fehlende Zielkonzepte nicht automatisch erzeugen, sondern in Mapping Review aufnehmen; - echte morphologische Normalisierung später generisch lösen. ### 3.6 Pauschales Entfernen von finalem `s` Aktuell: ```text wenn Länge > 5 und Token endet auf s: entferne s ``` Klassifikation: **LEGACY_HEURISTIC**. Empfehlung: **nicht** in das generische Zielmodell übernehmen. Die Regel ist für Deutsch zu grob und kann valide Lexeme beschädigen. Künftig entweder echte linguistische Normalisierung/Lemmatisierung oder explizite Mapping-/Labelvarianten. ### 3.7 Compound-Suffix-Liste Aktuell hart codierte Suffixe: ```text krankenhaus, kirche, kapelle, dom, muenster, kloster, kreuzgang, chorhalle, chor, turm, tor, portal, altar, seitenaltar, hochaltar, kanzel, orgelprospekt, prospekt, fenster, figur, relief, denkmal, brunnen, grabmal, epitaph, statue, skulptur, bildstock, kreuz, madonna, engel, krone ``` Semantik: ```text → ``` Klassifikation: **DEHIO_MAPPING / semantische Heuristik**, nicht generische linguistische Normalisierung. Begründung: Eine Compound-Zerlegung allein beweist nicht, dass der Suffixbegriff der fachlich gewünschte Zielbegriff ist. Das bereits diskutierte Muster `Wolfsburg → Burg` zeigt das Risiko. Empfehlung: **komplette Suffixliste aus dem generischen Quellcode entfernen.** Nur intellektuell bestätigte Regeln gehören in die Mapping Resource. ### 3.8 Gewichte und Ranking Aktuell: ```text raw token 0.55 singular 0.68 compound_suffix 0.78 ``` Anschließend Sortierung nach: ```text 1. Anzahl Token-Treffer 2. Gewicht ``` Klassifikation: **RANKING / LEGACY_HEURISTIC**. Empfehlung: nicht in die neuen Discovery Methods hineinziehen. Für `EXACT_STRING` und `MAPPED_VOCABULARY` zunächst deterministische, nachvollziehbare Semantik verwenden. Ranking separat modellieren, wenn es benötigt wird. --- ## 4. Abgleich mit dem bestehenden Dehio-Hilfsvokabular Das aktuelle Hilfsvokabular enthält 72 Concepts. Es enthält bereits zahlreiche intellektuell gepflegte Varianten und Wildcard-Muster mit Mappings auf MCT, u. a. für `Kirche`, `Burg`, `Schloss`, `Kapelle`, `Siedlung`, `Krankenhaus`, `Turm`, `Tor`, `Denkmal` usw. Damit ist ein erheblicher Teil der heutigen Compound-Suffix-Sonderlogik **bereits als externe fachliche Ressource modellierbar**. ### 4.1 Bereits durch das Hilfsvokabular abgedeckte Code-Suffixe Nach aktuellem Bestand sind mindestens folgende hart codierten RxStore-Suffixe bereits als gemappte Hilfsvokabular-Concepts vorhanden: | Code-Suffix | Hilfsvokabular | MCT-Ziel | Konsequenz | |---|---|---|---| | `krankenhaus` | Krankenhaus | `49898400` | aus Code entfernbar | | `kirche` | Kirche | `49730400` | aus Code entfernbar | | `kapelle` | Kapelle | `49739000` | aus Code entfernbar | | `kloster` | Kloster | `49704800` | aus Code entfernbar | | `chor` | Chor | `49720300` | aus Code entfernbar; Pattern ggf. ergänzen/prüfen | | `turm` | Turm | `49661100` | aus Code entfernbar | | `tor` | Tor | `49598500` | aus Code entfernbar | | `portal` | Portal | `49610000` | aus Code entfernbar | | `denkmal` | Denkmal | `49381800` | aus Code entfernbar | | `brunnen` | Brunnen | `49397700` | aus Code entfernbar | Bei mehreren dieser Concepts sind die benötigten Wildcard-Muster bereits vorhanden, z. B. `*kirche`, `*kapelle`, `*krankenhaus`, `*turm`, `*tor`, `*denkmal`, `*brunnen`. ### 4.2 Code-Suffixe ohne aktuell gesichertes Mapping im Hilfsvokabular Folgende hart codierte Code-Regeln dürfen **nicht automatisch** in neue Mappings übersetzt werden, solange kein intellektuell bestätigtes Ziel vorliegt: ```text dom muenster kreuzgang chorhalle altar seitenaltar hochaltar kanzel orgelprospekt prospekt fenster figur relief grabmal epitaph statue skulptur bildstock kreuz madonna engel krone ``` Diese Einträge bilden die **Mapping Review List**. Wichtig: Das Entfernen aus dem Quellcode bedeutet nicht, dass die fachliche Information verworfen wird. Sie wird als historisch verwendete Hypothese dokumentiert und kann intellektuell geprüft und anschließend als Mapping Resource übernommen werden. --- ## 5. Konkrete Übernahmen ins Dehio-Mappingvokabular ### 5.1 Ohne neue fachliche Entscheidung übernehmbar Wo das Hilfsvokabular bereits dasselbe Concept und MCT-Ziel enthält, können die im Code enthaltenen Eingangsformen als zusätzliche Varianten geprüft und ggf. ergänzt werden. Priorität: ```text kirchen → Kirche kapellen → Kapelle tuerme / Türme → Turm denkmaeler / Denkmäler → Denkmal ``` Dabei sollen im Vokabular die **lesbaren Originalformen** (`Kirchen`, `Kapellen`, `Türme`, `Denkmäler`) gepflegt werden, nicht die interne ASCII-Normalform (`kirchen`, `tuerme`, `denkmaeler`). Die technische Normalisierung darf keine fachlichen Labels erzeugen. `Brunnen` und `Fenster` sind formgleich Singular/Plural und benötigen keine künstliche Normalisierungsregel. ### 5.2 Nicht automatisch übernehmen ```text Altäre / Seitenaltäre / Hochaltäre → Altar Figuren → Figur Reliefs → Relief ``` Diese Regeln stammen zwar aus dem Juni-Code, aber ein aktuell gesichertes entsprechendes Hilfsvokabular-Concept mit MCT-Mapping ist in der vorliegenden Dehio-Mapping Resource nicht nachgewiesen. Sie bleiben Review-Fälle. ### 5.3 Compound-Regeln Code-Regeln wie: ```text *kirche *kapelle *krankenhaus *turm *tor *denkmal *brunnen ``` sind im Hilfsvokabular bereits ganz oder weitgehend als Pattern enthalten. Sie sollen künftig ausschließlich dort gesteuert werden. Für `chor` ist ein gemapptes Concept vorhanden; konkrete Varianten wie `Choranbau` und `Chorneubau` sind bereits gepflegt. Ob zusätzlich eine generische Regel `*chor` gewünscht ist, ist eine **fachliche Entscheidung** und keine Codeentscheidung. --- ## 6. Was als generischer Kern übrig bleiben soll Nach Entfernung der Sonderregeln soll der RxStore nicht mehr „Dehio verstehen“. Minimaler generischer Kern: ```text Generic normalization ├── trim ├── case normalization ├── whitespace normalization ├── definierte Unicode/diacritic normalization └── definierte punctuation policy Discovery Methods ├── EXACT_STRING ├── RIGHT_TRUNCATED ├── LEFT_TRUNCATED ├── BOTH_TRUNCATED ├── LEVENSHTEIN [später] └── weitere generische Methods ``` Linguistische Verfahren wie Tokenisierung, Lemmatisierung und morphologische Normalisierung werden separat definiert und dürfen keine fest codierten Dehio-Wortlisten enthalten. Dasselbe fachliche Methodenset soll perspektivisch durch RxStore und xTree implementiert werden. --- ## 7. No-Sonderlocken-Regel Für den weiteren Umbau gilt: > Eine Regel darf nur im Runtime-Code stehen, wenn sie unabhängig vom Projekt, Vokabular und konkreten Fachbestand als generisches Verfahren definiert werden kann. Daraus folgen drei Prüffragen für jede neue Regel: ```text 1. Würde dieselbe Regel unverändert auch bei einem anderen Kunden gelten? 2. Benötigt die Regel Wissen über einen konkreten Fachbegriff oder ein Zielvokabular? 3. Könnte eine Fachperson die Regel korrigieren wollen, ohne dass Reconcilix deployed wird? ``` Wenn 2 oder 3 mit Ja beantwortet wird, gehört die Information **nicht in den Quellcode**, sondern in eine externe Resource / Konfiguration / kontrolliertes Vokabular. --- ## 8. Ergebnis Phase 1+2 ### Aus dem Runtime-Code herauszulösen ```text - komplette manuelle knownForms-Liste - pauschale Compound-Suffix-Liste - Dehio-/fachspezifische Weak Tokens - fachlich motivierte Gewichtung token/singular/compound - pauschales finales-s-Fallback nicht in das neue generische Modell übernehmen ``` ### In externe fachliche Ressourcen zu überführen ```text - bestätigte Dehio-Compound-Muster → Dehio-Hilfsvokabular - bestätigte historische Begriffsvarianten → altLabel / Pattern - MCT-Zielrelationen → MapItem - noch nicht bestätigte Regeln → Mapping Review List ``` ### Generisch weiterzuentwickeln ```text - Text normalization - Tokenization - Morphological normalization / Lemmatization - EXACT_STRING - *_TRUNCATED - LEVENSHTEIN ``` --- ## 9. Nächster Umsetzungsschritt Vor der Runtime-Änderung wird eine kleine Mapping-Ergänzungsliste für das Hilfsvokabular finalisiert: 1. bereits vorhandene Pattern nicht duplizieren; 2. sichere Flexionsvarianten (`Kirchen`, `Kapellen`, `Türme`, `Denkmäler`) prüfen/ergänzen; 3. historische Code-Suffixe ohne gesichertes Mapping in Review-Liste übernehmen; 4. keine neue fachliche Relation allein aus dem PHP-Code ableiten. Danach kann der Runtime-Umbau beginnen: ```text Legacy exact-with-token-fallback ↓ Refactoring EXACT_STRING ↓ ON_ZERO_RESULTS MAPPED_VOCABULARY ``` Die 150 E004-SourceValues dienen anschließend als Regression-/Differenztest. Ergebnisabweichungen zum Legacy-Verfahren sind zulässig, müssen aber erklärbar sein.