feat(ontology): #499 Phase 2 — Virtue ClassMap + OWL generator (mono-corpus, aif:goodTenorOf)

[jsboige]

#499 Phase 2 — Virtue ClassMap + OWL pass ✅ READY (Part 1 + Part 2)

Status: READY — Part 1 (ClassMap) + Part 2 (Virtue OWL generator) both delivered.
Base 6e029a6f (#590 merged). Dispatch: msg-20260623T151404-vjbzs9.

---

Part 1 — ClassMap ✅ (commit e0be8911)

• Mapped the 12 feat(virtues): amener la taxonomie Virtues à parité (relationnel + AIF + export consommable) #499 columns onto Virtue / VirtueClassMap — the entity that loads
  the prod CSV (CsvType = typeof(Virtue)) and feeds the pipeline. All 12 .Optional().
• Entity-target correction (validated): the dispatch named ArgumentVirtueClassMap, but
  ArgumentVirtue is only the AutoMapper projection target — not a CSV loader. The prod
  Virtues CSV operates on Virtue.
• Tests +2 in VirtueClassMapRegressionTests (suite 533 → 535).

Part 2 — Virtue OWL generator ✅ (commit d5ce3228)

Discovery: OwlGeneratorConfig only emitted argumentum_fallacies.owl — no OWL pass
existed for Virtues. Part 2 therefore creates the generator from scratch, mirroring
OwlGeneratorConfig / OwlDocumentConfig (Fallacies):

• VirtueOwlGeneratorConfig + VirtueOwlDocumentConfig (Ontology/, new file) — emits
  argumentum_virtues.owl: a concept scheme with the 7-family hierarchy (skos:narrower
  via Path/Depth, same GetParent shape), one concept per Virtue node (prefLabel /
  definition FR+EN on Title*/Description*), and a custom AIF object property.
• Wired into the pipeline (AssetConverterConfig.cs): new property + invoked in the
  OwlGenerator mode block (sync + async), parallel to OwlGeneratorConfig.Apply.

Design decisions (jsboige interactive 2026-06-24)

1. AIF predicate = custom aif:goodTenorOf (DeclareObjectProperty), not a
   skos:*Match token. The Virtue AIF_skosMappingType column holds the FR-prose critical
   question, not a skos enum, so the Fallacies switch(AIFSkosMappingType) cannot fire.
   The prose is carried as an rdfs:comment annotation. The AIF namespace already exists
   in the Fallacies pass (http://www.arg.dundee.ac.uk/aif#) — no new namespace.
2. Cross-corpus crossLink_Opposes (PK→URI) DEFERRED to Phase 3. Resolving Fallacy PKs
   requires loading the Fallacies corpus (concept URIs derive from GetId(TextEn), not PK) —
   new architecture beyond this single-dataset pass. This pass is strictly mono-corpus.

Tests +5 (VirtueOwlGenerationContractTests)

• GetId mirrors the Fallacies IRI transform (byte-identical; asserted on the same proven
  inputs A-B / A, B / Appel à l'autorité).
• Generator defaults lock the ontology identity (argumentum_virtues.owl /
  VirtuesTaxonomy dataset / namespace / AIF namespace).
• aif:goodTenorOf URI construction pinned for Phase 3 reuse.

Verified: build 0 errors, 0 new warnings; suite 535 → 540 passed / 0 failed / 5 skipped.

---

Honesty note — E2E not yet exercised ⚠️

The generator compiles, is wired, and is covered by pure contract tests (transform /
defaults / URI). The actual end-to-end .owl file emission has NOT been run — that
needs the compute-heavy pipeline (CardPen harvest is not my lane solo). Flagged explicitly:
concept count, hierarchy depth, and aif:goodTenorOf triples should be byte-checked against
the 222 populated Virtue nodes on the next coordinated pipeline run. Cross-corpus Phase 3 +
E2E validation are the open tails.

DoD #499 coverage

• Relational + AIF columns added to the Virtue schema (Phase 1, feat(csv): #499 Phase 1 — add 12 relational/AIF columns to Virtues prod CSV #590)
• Export consommable documenté — argumentum_virtues.owl (this PR, mono-corpus)
• E2E generation verified (next coordinated pipeline run)
• Cross-corpus Virtue↔Fallacy links (Phase 3)
• 1 exemple de consommation EPITA (Phase 3 / consumer side)

🤖 Worker po-2024 · #499 Phase 2 · Part 1 (ClassMap) + Part 2 (OWL gen) delivered · 540/0/5

[clusterManager-Myia]

[NanoClaw] #499 Phase 2 Part 1 — reviewed at e0be8911a6. Small, clean ClassMap/entity diff (32 LOC) + 2 regression tests.

Scope note for future readers: the PR title says "OWL pass" but this branch ships only Part 1 (the 12 crossLink_* / AIF_skos* properties on Virtue + VirtueClassMap mappings, all .Optional()). The OwlAdapter pass itself is deferred to Part 2 pending the two design decisions flagged in the PR body (FR-prose skos:relatedMatch vs. enum token; cross-corpus PK→URI resolution for crossLink_Opposes). That's a reasonable split — nothing broken is hidden behind the WIP tag.

Correctness verified by hand: in Maps499RelationalAndAifColumns the 12 newCols headers align 1:1 with the 12 RFC4180-parsed newRow values (I counted — the four ,,,, segments plus 681;690, Argument from Sign, and the quoted FR-prose field land in the right slots; the internal comma in "Les résultats…cohérents ?" parses as a single field). The two tests together correctly pin CsvHelper's .Optional() contract: present-but-empty cell → "" (BeEmpty), absent column → null (BeNull) — a good regression pair. The entity-target correction (prod loader is Virtue, not ArgumentVirtue) is right; ArgumentVirtue is the AutoMapper projection target, not a CSV loader.

No path/secret leaks, no stubs/TODOs in the shipped code. Trivial nit: Virtue.cs ends without a trailing newline (pre-existing, not introduced here). Looking forward to Part 2 — the cross-corpus PK→URI resolution is the architecturally interesting piece.