Technische wensen

Ontwerp-beslissingen en toekomstplannen

Data provenance: 1st-party vs 3rd-partygepland

Hoe weten we waar data vandaan komt, en wat we ermee mogen?

Probleem

Naarmate het systeem rijker wordt, komen er koppelingen naar externe API's (PDOK, Natura 2000, Google Maps, CBS). Niet alle externe data mag opgeslagen worden — licentievoorwaarden verschillen per bron. Het systeem moet per veld zichtbaar maken waar data vandaan komt, en per bron afdwingen wat mag.

Bron-profielen

Elke externe API is een "bron" met licentie- en cache-instellingen:

DataSource { id: "pdok" | "google_maps" | "natura2000" name: "PDOK Locatieserver" license_type: "open" | "restricted" | "display_only" cache_policy: "store" | "cache_ttl" | "live_only" cache_ttl_hours: 720 (alleen bij cache_ttl) attribution: "Bron: PDOK" fields_provided: ["lat", "lng", "province"] }

Licentie-types

TypeOpslaanBewerkenVoorbeeld
openJaJaPDOK open data
restrictedCache met TTLNeeNatura 2000 gebiedsgrenzen
display_onlyNeeNeeGoogle Maps data

Per-veld herkomst

Elk datapunt op een entiteit krijgt een optionele herkomst-annotatie. Geen bron = eigen invoer (1st-party). Met bron = extern (3rd-party).

entities.data: lat: 52.3 ← PDOK (opgehaald 15 mrt) province: "Gelderland" ← PDOK (opgehaald 15 mrt) description: "Heideveld" ← eigen invoer entities.data_sources: lat: { source: "pdok", fetched_at: "2026-03-15" } province: { source: "pdok", fetched_at: "2026-03-15" } description: null

UI

Zowel Henk als Bram zien waar data vandaan komt:

Afdwinging

Bij opslaan: display_only velden → weigeren cache_ttl velden → opslaan met vervaldatum open velden → opslaan als eigen data Bij weergeven: display_only → live ophalen via API cache_ttl → tonen + markeren als cache eigen data → normaal tonen

Status

Dit model is ontworpen maar wordt pas gebouwd als er een concrete API-integratie komt (PDOK, Natura 2000, etc.). De database-migratie (data_sources kolom) kan alvast draaien zonder bestaande data te breken.