# ME002 — Interpretation-driven Reconciliation

**Version:** 0.6  
**Status:** Draft  
**Scope:** Processing model for Reconcilix  
**Related:** DM001, DM002, ME001

## 1. Purpose

ME002 beschreibt, wie Reconcilix einen `SourceValue` verarbeitet. Die Verarbeitung ist nicht rein linear. Reconcilix exploriert mögliche Interpretationen und wählt schrittweise passende `MatchingStrategy`-Varianten.

Leitsatz:

> Reconcilix does not immediately search for the best Candidate Item. Reconcilix first explores possible interpretations of a Source Value and selects an appropriate Matching Strategy.

## 2. Processing Objects

ME002 verwendet die Domain Objects aus DM001:

```text
SourceValue
→ InterpretationGraph
→ InterpretationNode
→ ReconciliationResult
→ CandidateItem
→ MatchDecision
```

Die Persistenz erfolgt gemäß DM002 in MySQL.

## 3. High-level Workflow

```text
1. Receive SourceValue and ContextItems
2. Determine one or more interpretable spans
3. Create InterpretationGraph per span
4. Create initial InterpretationNode
5. Assign InterpretationProperties where observable
6. Execute MatchingStrategy
7. Persist ReconciliationResult and CandidateItems
8. Classify the result with 0..1 VocabularyMatchingPattern
9. Evaluate result quality
10. If insufficient, create additional InterpretationNode or select another MatchingStrategy
11. Create MatchDecision
```

## 4. Iterative Interpretation Loop

```mermaid
flowchart TD
    A[SourceValue] --> B[Identify interpretable span]
    B --> C[Create InterpretationGraph]
    C --> D[Create initial InterpretationNode]
    D --> E[Assign InterpretationProperties]
    E --> F[Select MatchingStrategy]
    F --> G[Candidate Discovery]
    G --> H[Create ReconciliationResult]
    H --> I[Classify VocabularyMatchingPattern]
    I --> J{Success sufficient?}
    J -->|yes| K[Create MatchDecision]
    J -->|no| L{Further interpretation possible?}
    L -->|yes| M[Create derived InterpretationNode]
    M --> E
    L -->|no| N[Manual Review / Needs Context / No Suitable Candidate]
    N --> K
```

## 5. Candidate Discovery

`Candidate Discovery` bezeichnet die systematische Suche nach bereits existierenden `CandidateItem`-Ressourcen.

Mögliche Techniques:

- exact lookup über preferred Term
- exact lookup über alternative Term
- Qualifier-aware lookup
- hierarchy traversal (`broader`, `narrower`, `related`)
- xTree/MCT lookup
- OpenRefine Reconciliation API
- cross Concept Scheme matching
- vector search, z. B. Qdrant
- embedding-based evaluation, z. B. BGE
- LLM-assisted disambiguation oder expansion

Diese Techniques sind keine eigenen Pipeline Stages. Sie werden innerhalb einer `MatchingStrategy` eingesetzt.

## 6. Matching Strategy Selection

Die Wahl der Strategie kann sich stützen auf:

- `preferredEntityType`
- vorhandene `ContextItem`
- erkannte `InterpretationProperty`
- bisherige `ReconciliationResult`
- Candidate-Verteilung und Scores
- Target Vocabulary-Struktur

Beispiele:

| Interpretation Property / Result | Possible next MatchingStrategy |
|---|---|
| `ORTHOGRAPHIC_VARIANT` | orthographic normalization, danach erneuter lookup |
| `COMPOSITE_TERM` | component analysis, head detection, broader search |
| `MULTI_CONCEPT_EXPRESSION` | Segmentierung in mehrere InterpretationGraph-Instanzen |
| `CONTEXT_DEPENDENT` | Context Enrichment und erneute Candidate Discovery |
| `SEMANTIC_GENERALIZATION` | hierarchy traversal und broader Candidate Evaluation |
| `NO_SUITABLE_CANDIDATE` | anderes Concept Scheme, Vocabulary Extension oder Manual Review |

## 7. Examples

### 7.1 `Altrarretabel`

```text
SourceValue: Altrarretabel
InterpretationGraph[0]: full span
InterpretationNode[0]: Altrarretabel
  InterpretationProperty: ORTHOGRAPHIC_VARIANT
ReconciliationResult[0]: success = false
InterpretationNode[1]: Altarretabel
ReconciliationResult[1]: CandidateItem found
VocabularyMatchingPattern: EXACT_MATCH or SEMANTIC_GENERALIZATION
MatchDecision: ACCEPTED / REVIEW
```

### 7.2 `Abendmahlsrelief`

```text
InterpretationNode: Abendmahlsrelief
InterpretationProperty: COMPOSITE_TERM
CandidateItem: Relief
VocabularyMatchingPattern: SEMANTIC_GENERALIZATION
```

### 7.3 Text with repeated spans

```text
SourceValue: Der Herr von Bogen geht mit dem Bogen über den Bogen
preferredEntityType: MULTIPLE

InterpretationGraph[0]: erstes Bogen
InterpretationGraph[1]: zweites Bogen
InterpretationGraph[2]: drittes Bogen

Jeder Graph besitzt eigene InterpretationNodes, ReconciliationResults,
CandidateItems und MatchDecisions.
```

## 8. Initial Implementation Scope

Die nächste Reconcilix-Version implementiert zunächst:

- `CONCEPT`
- genau einen `InterpretationGraph` pro `SourceValue`
- eine initiale `InterpretationNode`
- lineare Ableitung weiterer Nodes
- xTree/MCT Candidate Discovery
- MySQL-Persistenz aller fachlichen Objekte
- bestehende OpenRefine-Kompatibilität
- Speicherung von `InterpretationProperty`, `VocabularyMatchingPattern` und `MatchDecision`

Nicht Teil dieser Phase:

- `PERSON`, `PLACE`, `MULTIPLE`
- mehrere Graphen pro SourceValue in der Runtime
- Qdrant, BGE, LLM
- automatische Cross-Concept-Scheme-Exploration
- echte konvergierende Graphpfade