Waarom twee Manifestation-tabellen

Dit hoofdstuk vertelt het verhaal van een discussie die op 2026-05-12 gevoerd is, omdat de uitkomst — twee aparte Manifestation-tabellen plus een junction — niet de eerste reflex was. Het narratief helpt om later de keuze te begrijpen.

Aanleiding — een data-anomalie

canonical.publications (de voorganger van publicatie.publicaties) had sinds de FRBR-overhaul twee polymorphic FKs: decision_id naar canonical.decisions, en refers_to_instrument_version_id naar canonical.instrument_versions. Een data-audit op 2026-05-12 toonde:

• 12.247 rijen met alleen decision_id ingevuld
• 3.011 rijen met alleen refers_to_instrument_version_id ingevuld
• 637 rijen met beide ingevuld

ADR-0034 had ondertussen publicatie.publicaties.besluit_id als de enige substantieve FK gemodelleerd. Dat betekende: de 3.011 "alleen-instrument"-rijen pasten niet in het nieuwe schema.

Eerste reflex — polymorphic fix

De handoff van 2026-05-12 noteerde een voorstel:

ALTER TABLE publicatie.publicaties
  ADD COLUMN instrument_version_id UUID REFERENCES instrument.versies(id),
  ADD CONSTRAINT publicaties_target_required CHECK (
    besluit_id IS NOT NULL OR instrument_version_id IS NOT NULL
  );

Polymorphic targets: een publicatie-rij wijst naar óf een besluit, óf een instrument-versie, óf beide. Argumenten voor: gemakkelijk, één tabel, alle Manifestations bij elkaar.

De pushback — twee uur later

Bij het uitwerken van het instrument-stack Expression-model bleek het probleem: er bestaat al een Manifestation-tabel voor de instrument-stack — canonical.instrument_renderings, gemaakt in migratie 150 (FRBR-fase 1) als onderdeel van ADR-0031's two-stack-pijler-ontwerp. De polymorphic fix zou impliciet een tweede Manifestation-tabel voor dezelfde stack creëren, plus de pijler-scheiding uit ADR-0031 ondergraven.

De gebruikers-correctie verbatim:

"Voor iets wat een manifestatie is van een instrument zonder besluit eromheen is het direct al op te slaan als instrument met provenantie en dergelijke erbij."

Dat is structureel correct. Een Manifestation van een instrument-versie hoort thuis in instrument.manifestaties (de instrument-stack Manifestation-tabel), niet in publicatie.publicaties met een polymorphic-FK-shortcut.

De juiste structuur — twee aparte tabellen + junction

publicatie.publicaties        Manifestation voor decision-stack
  └── één rij per OB-publicatie / officiële publicatie van een besluit

instrument.manifestaties      Manifestation voor instrument-stack
  └── één rij per fysieke embodiment van een instrument-versie

verbinding.publicatie_bevat_manifestatie    Junction voor "draagt als bijlage"
  └── één rij per (publicatie, instrument-manifestatie, bijlage-rol)

Eén OB-pagina (Manifestation van een besluit) kan meerdere instrument-Manifestations als bijlage dragen — bv. de regel-tekst-PDF + de werkingsgebieden-GML + de verbeelding. Dat is geen polymorphic-FK-mess; het is een natuurlijke many-to-many-relatie tussen twee FRBR-pijlers.

Wat gebeurt er met de 3.011 alleen-instrument rijen?

Per gebruikers-instructie 2026-05-12 ("backward compatibility is niet relevant; we kunnen her-ingestren") worden deze rijen niet gemigreerd maar her-ingest. Bij her-ingest:

• Een Manifestation van een instrument-versie → rij in instrument.manifestaties
• Als die Manifestation via een OB-publicatie bekend is gemaakt → óók een rij in publicatie.publicaties voor het bijbehorende vaststellingsbesluit, plus een rij in verbinding.publicatie_bevat_manifestatie om de bijlage-relatie te leggen
• Als de Manifestation puur op een ander register staat (LVBB-only, CVDR-only, etc.) → alleen de instrument.manifestaties-rij + instrument.manifestatie_herkomsten-rij voor de vindplaats; geen publicatie.publicaties-rij

Schoner dan een polymorphic-shortcut, en geen verlies van semantiek.

Wat dit illustreert

Een goed schema-ontwerp stelt geen polymorphic-FK-shortcuts in als oplossing voor "deze rijen passen niet" — het splitst dan de tabellen langs de FRBR-pijler die ze hadden moeten respecteren. De polymorphic-fix zou een vorm van toegevoegde technische schuld zijn die de FRBR-tweedeling actief saboteert.

Algemeen patroon: als een tabel polymorphic targets blijkt te willen, is dat vaak een aanwijzing dat er twee verschillende soorten entiteiten in worden gestopt die eigen tabellen verdienen.

Onderliggende ADRs

• ADR-0031 — Two-stack FRBR
• ADR-0034 — publicatie als Manifestation (de polymorphic-fix is hier voorgesteld en daarna afgewezen)
• ADR-0037 — Instrument-stack Manifestation + Expression model (formaliseert de definitieve keuze)