### ED-04-007 source_value.source_delivery_id
```text

in Tabelle source_value fehlt Spalte source_delivery_id

Prio: hoch
```

### ED-04-008 delivery_id aus OR übernehmen
```text
OpenRefine Request Integration
delivery_id sauber übernehmen
GET + POST unterstützen
Manifest dazu: http://localhost:8080/reconcile/v2/?api_key=zo6vyn51nbehons0&delivery_id=OR-TEST-20260725-001
Prio: mittel
```

### ED-05 SourceSystem Integration
```text
Prio: mittel
```

### ADR003 – Aggregate Identifier Strategy
```text
- docs/architecture/ADR003_Aggregate_Identifier_Strategy.md

Prio: hoch

bigint(20)  nach  VARCHAR(36) mit UUID für ids
```



### PRE_WP3-001 -- xTree Candidate Discovery Adapter
```text
- docs/workpackages/WP3/PRE_WP3-001_xTree_Candidate_Discovery_Adapter.md

Die Candidate Discovery funktioniert derzeit gegen den lokalen Store für
die MCT-Objektfacette. Der Zugriff über die xTree-API funktioniert noch
nicht.
```

### PRE_WP3-002 -- Interpretation Property Integration
```text
- docs/workpackages/WP3/PRE_WP3-002_Interpretation_Property_Integration.md

`interpretation_node_property` ist vorhanden, wird im Reconciliation
Flow aber noch nicht genutzt.
```


### PRE_WP3-003 -- Vocabulary Matching Pattern
```text
- docs/workpackages/WP3/PRE_WP3-003_Vocabulary_Matching_Pattern_Integration.md

`reconciliation_result.vocabulary_matching_pattern_uri` wird derzeit
noch nicht verwendet.
```

### Evolution des Target-Systems
```text
Das aktuelle Modell (targetVocabularyUri) reicht für reine Vocabulary-Reconciliation aus. Mit der Integration weiterer Wissensorganisationssysteme (z. B. Wikidata, GND), Suchtechnologien (QLever, Qdrant) und spezialisierter APIs ist eine eigenständige Modellierung der Zielseite erforderlich. Dabei sind mindestens die fachlichen Konzepte KnowledgeSource, DiscoveryChannel und deren Beziehung zu CandidateItem zu untersuchen.

Candidate Discovery
│
├── REST Search
├── SPARQL
├── Vector Search
├── Local Index
├── Vector Candidate Discovery
└── Hybrid Search


### Modell Mapping drüber nachdenken
Semantik	skos:closeMatch
MatchingMethod	LLM, Lexical, Embedding, RuleBased
ExecutionTool	OpenRefine, Reconcilix, Python, Silk, LIMES
ValidationStatus	Approved, Rejected, Reviewed, Proposed

Mapping
│
├── skos:closeMatch
├── MatchingMethod = LLM
├── ValidationStatus = Approved
├── ConfidenceScore = 0.93
├── prov:generatedAtTime
├── prov:wasGeneratedBy MatchingRun4711
└── prov:wasAttributedTo XYZ

MatchingRun4711
│
├── Tool = OpenRefine
├── Model = GPT-5.5
├── PromptVersion = v3
├── Vocabulary = xTree
├── RunDate = ...
└── Parameters = ...
```

### Controlled Vocabulary EntityType

```text

Status: Idee / zukünftige Architekturprüfung

Im aktuellen Projektstand wird EntityType bewusst als einfacher kontrollierter Code verwendet.

CONCEPT

Für zukünftige Ausbaustufen kann geprüft werden, ob Reconcilix interne Klassifikationen grundsätzlich als kleine SKOS-Vokabulare veröffentlicht.

Beispiel:

ConceptScheme
http://reconcilix.vocnet.org/entityType
Concept
http://reconcilix.vocnet.org/entityType/0001

skos:notation     "CONCEPT"
skos:prefLabel@de "Begriff"
skos:prefLabel@en "Concept"

preferredEntityType und CandidateItem.entityType würden dann weiterhin denselben fachlichen Wert verwenden. Intern kann dieser als Code (CONCEPT) gespeichert werden; optional kann später zusätzlich die URI des Concepts referenziert werden.

Nutzen

Linked-Data-kompatible Modellierung
versionierbare kontrollierte Wertelisten
Wiederverwendung in xTree
spätere Interoperabilität mit externen Modellen (z. B. SKOS, CIDOC CRM) über explizite Mappings, ohne das Domain Model direkt an ein externes Modell zu koppeln

Aktuelle Entscheidung

Für WP2/WP3 bleibt EntityType unverändert ein einfacher kontrollierter Code:

CONCEPT

Eine LOD-basierte Umsetzung ist kein aktueller Architekturauftrag und wird bei Bedarf in einem späteren ADR bewertet.


### Rules+Glossar-Dokument erstellen
Beispiel:# DM001 — Reconcilix Domain Model

**Version:** 0.6
**Status:** Final

**Created:** 2026-07-10
**Updated:** 2026-07-24

**Owner:** LA
**Review:** ED
**Approved by:** PL

**Scope:** Vocabulary and Entity Reconciliation

**Related:**
- ADR001
- ADR002
- DM002
- ME001
- ME002
```


### PL-001 – Dokumenttypen standardisieren

**Priorität:** Niedrig (vor nächster größerer Entwicklungsrunde)

**Beschreibung**

Während der Erarbeitung von PRE_WP3 und WP3 entstand ein konsistentes Muster für unterschiedliche Dokumenttypen. Dieses Muster soll vor der nächsten größeren Entwicklungsphase überprüft und in einer `DOCUMENTATION_GUIDELINES.md` dokumentiert werden.

**Zu klärende Fragen**

* Welche Rolle haben PRE-Dokumente?
* Welche Rolle haben Foundation-Dokumente?
* Sind Foundation-Dokumente künftig eher **Index- und Steuerungsdokumente**?
* Welche Informationen gehören ausschließlich in Work Packages?
* Welche Informationen gehören ausschließlich in Architekturdokumente?
* Welche Benennungsregeln gelten künftig für Dokumenttypen?

**Mögliche Zielstruktur**

| Dokumenttyp              | Zweck                                                       |
| ------------------------ | ----------------------------------------------------------- |
| PRE_*                    | Architekturentwurf und Architekturentscheidungen            |
| WP*                      | Index- und Steuerungsdokument eines Engineering-Workstreams |
| WP*-001 …                | Konkrete Engineering Work Packages                          |
| ADR*                     | Architekturentscheidungen                                   |
| DM*                      | Domänen- und Persistenzmodell                               |
| DOCUMENTATION_GUIDELINES | Dokumentationskonventionen und Namensregeln                 |

weitere. ME*, TR*

---

Möglichkeit überprüfen,  DOCUMENTATION_GUIDELINES.md als Teil einer Methodik-Dokumentation zu erarbeiten. z.B. 

/docs/methodology/

    DOCUMENTATION_GUIDELINES.md
    ENGINEERING_WORKFLOW.md
    REVIEW_PROCESS.md
    VERSIONING_GUIDELINES.md
```