Toegang voor onderzoek (open data)

[MarcoKlerks]

Stakeholders

• Product Owner:
• Lead Designer:
• Tech Lead:

---

Bounded Context

Primair de Publicatiebank-context (GPP-publicatiebank) — hier komt het alleen-lezen toegangspunt voor Hergebruikers, omdat zij hun eigen full-text indexering op de brondocumenten uitvoeren (besloten door Marco & Sergei, i.p.v. bouwen op GPP-Zoeken). Raakvlak: externe Hergebruikers (bijv. onderzoekspartijen zoals UvA/WooPush) die uitsluitend openbare data consumeren, los van de bestaande gemeente-/burgerkanalen (GPP-app, GPP-burgerportaal, GPP-Zoeken).

---

Context

Externe partijen willen geautomatiseerd, op schaal, gebruik maken van de openbare (reeds gepubliceerde) onderwerpen, publicaties, documenten en metadata die via GPP-Woo ontsloten worden — bijvoorbeeld voor onderzoek, indexering of AI-toepassingen. Een concreet voorbeeld is het WooPush-initiatief van de UvA & ICAI OpenGov Lab, dat een aanbevelingssysteem wil bouwen dat burgers proactief naar relevante overheidspublicaties leidt (zie Design Artifacts voor het volledige voorstel).

Vandaag bestaat er geen apart toegangspunt voor dit soort Hergebruikers: de huidige APIs geven alle informatie terug, ongeacht publicatiestatus, en zijn niet gescheiden van het verkeer voor gemeenten en burgers. Een Hergebruiker die op schaal bevraagt, loopt daardoor het risico de dienstverlening aan gemeenten en burgers te verstoren.

Goal

Een Hergebruiker kan geautomatiseerd, alleen-lezen toegang krijgen tot uitsluitend de openbare (gepubliceerde) onderwerpen, publicaties, documenten en hun metadata — inclusief een manier om nieuwe publicaties te ontdekken — zonder dat dit ten koste gaat van de beschikbaarheid van het platform voor gemeenten en burgers.

Success Metrics

• Een Hergebruiker kan via een apart, alleen-lezen toegangspunt uitsluitend gepubliceerde (openbare) onderwerpen, publicaties en documenten raadplegen — nooit concept- of ingetrokken publicaties.
• Een Hergebruiker kan nieuwe publicaties ontdekken zonder steeds de volledige dataset opnieuw te moeten doorzoeken.
• Bronpublicaties zijn direct te benaderen via een publieke URL, zonder account of inlog, zodat externe verwijzingen altijd naar een geldige bron leiden.
• Bulkbevragingen door Hergebruikers hebben aantoonbaar geen merkbare impact op de beschikbaarheid van het platform voor gemeenten en burgers.
• Na realisatie van deze Epic zijn de aanbevolen en/of vereiste hosting-specificaties (bijv. minimale resources, rate-limiting-capaciteit, read-replica-ondersteuning) voor het alleen-lezen toegangspunt gedocumenteerd in de GPP-publicatiebank-documentatie, zodat ook andere hosting-partijen dan Dimpact hiernaar kunnen handelen.

---

Design Artifacts

• Volledige oorspronkelijke aanvraag ("WooPush x GPP-Woo voorstel", UvA & ICAI OpenGov Lab, 10 feb 2026) — bevat de onderzoeksmotivatie, het WooPush-ontwerp (buiten scope van GPP-Woo) en de voorgestelde tijdlijn/financiering (MCOIG). Gearchiveerd als PDF en gedeeld met Marco Klerks; oorspronkelijk geplaatst als bijlage in de comments van deze Epic.
• Onderzoek van de provisioning-repo (Dimpact's eigen Azure/AKS-hosting), geraadpleegd 2026-08-07 — bevat de huidige Traefik-, CNPG- en resource-quota-configuratie waarop de risico's hieronder zijn gebaseerd. Let op: dit is Dimpact's eigen hostingkeuze, niet per se representatief voor andere hosting-partijen (zie Risks).

Out of Scope

• De WooPush-oplossing zelf (aanbevelingssysteem, burgerprofielen, matching-logica, burger-voorkant/portal) — wordt volledig door de UvA gebouwd en beheerd; GPP-Woo levert alleen toegang tot openbare data.
• Financiering, onderzoeksethiek (DPIA/ERB) en projecttijdlijn van WooPush — verantwoordelijkheid van de UvA.
• Privacy/profilering van burgers door externe Hergebruikers — buiten de invloedssfeer van GPP-Woo.

Risks

• Een apart toegangspunt voor Hergebruikers kan, zonder waarborgen, zwaar bevraagd worden (bijv. herhaaldelijk ophalen van alle onderwerpen, publicaties, documenten en bestanden t.b.v. indexering of AI-toepassingen) — dit mag de dienstverlening aan gemeenten en burgers niet verstoren.
• Onduidelijk of gedupliceerde data/bestanden nodig zijn voor bulkbevragingen, of dat rate-limiting en schaalstrategie op de bestaande dataset volstaan — te bepalen tijdens een haalbaarheidsanalyse.
• (technisch — besproken door Marco & Sergei) De toegang wordt gebouwd op de Publicatiebank, niet op GPP-Zoeken, omdat Hergebruikers zelf hun eigen full-text indexering uitvoeren. De Publicatiebank is een goede kandidaat voor horizontale schaling (meerdere instanties op dezelfde database, evt. met een read-replica); bestandslevering gebeurt al via streaming. Onderzoek van de provisioning-repo bevestigt dat elke gemeente-instantie in productie al standaard een 3-instance CloudNativePG-cluster draait (1 primary + 2 replica's; 2 in acceptatie) — read-replica's zijn dus al gangbare praktijk bij Dimpact, geen nieuw te bouwen mechanisme. Of GPP-publicatiebank leesverkeer daadwerkelijk naar replica's routeert, is nog niet bevestigd.
• (technisch) Rate-limiting met tiers is nodig zodat het toegangspunt voor Hergebruikers altijd minder capaciteit mag opeisen dan de toegangspunten voor burgerportaal en GPP-Zoeken. Load testing en profiling zijn nodig om de juiste tiers en schaalstrategie te bepalen. In de provisioning-repo bestaat vandaag nog geen rate-limiting op de gedeelde Traefik-ingress bij Dimpact; dit moet dus nieuw gebouwd worden, niet slechts geconfigureerd.
• Horizontale/elastische autoscaling van het cluster bestaat nog niet in Dimpact's hosting — schalen gebeurt vandaag handmatig (node_count ophogen + pipeline opnieuw draaien). Een schaalstrategie voor deze Epic moet hiermee rekening houden, of expliciet autoscaling als randvoorwaarde benoemen.
• Elke gemeente-instantie draait bij Dimpact binnen een eigen ResourceQuota (max. ~9 CPU / 15Gi geheugen totaal per gemeente; individuele pod max. 3 CPU / 8Gi). Een piek in Hergebruiker-verkeer op één gemeente kan dit plafond snel raken, los van clusterbrede capaciteit.
• Bovenstaande technische bevindingen zijn gebaseerd op de provisioning-repo, die specifiek Dimpact's eigen Azure/AKS-hosting beschrijft. Andere hosting-partijen die GPP-Woo draaien, kunnen een andere configuratie gebruiken (andere quota's, wel/geen autoscaling, wel/geen rate-limiting). Deze Epic mag geen aannames baseren op de Dimpact-specifieke setup als zijnde universeel — vandaar de nieuwe Success Metric en het Feature Breakdown-item om de aanbevolen/vereiste specs generiek te documenteren.

Feature Breakdown

• Alleen-lezen toegangspunt op de Publicatiebank dat uitsluitend gepubliceerde onderwerpen, publicaties, documenten en metadata ontsluit
• Manier om nieuwe/gewijzigde publicaties te ontdekken (bijv. chronologische bevraging of feed) t.b.v. Hergebruikers
• Rate-limiting met tiers en schaalstrategie (incl. load testing) om bulkbevraging door Hergebruikers te scheiden van burger-/gemeenteverkeer
• Publieke, login-vrije directe URLs naar bronpublicaties t.b.v. verwijzing door Hergebruikers
• Aanbevolen/vereiste hosting-specs voor het Hergebruikers-toegangspunt documenteren in de GPP-publicatiebank-documentatie (generiek, voor alle hosting-partijen — niet Dimpact-specifiek)

[MarcoKlerks]

Marco Klerks
[Wednesday at 2:08 PM]
Maandag heb ik met David Graus van de UvA gesproken over een onderzoek dat hij wil gaan doen, gebruik makend van openbare documenten en metadata op het GPP-Woo. We hebben even gebrainstormd over wat wij voor hem zouden kunnen betekenen en ik heb hem gevraagd om zijn wensen en ideeën even kort op te schrijven. Dat heeft hij buitengewoon netjes gedaan! Zie bijlage.

Volgende week woensdag, wanneer we fysiek bijeen zijn, wil ik even bespreken of en hoe wij aan de geuite wens kunnen gaan voldoen. Ik maak alvast een epic aan....
PDF

Bijlage: WooPush x GPP-Woo voorstel.pdf

Marco Klerks
[Wednesday at 2:08 PM]
We zijn vergeten hierover te babbelen!

Ik neig naar een publieke API met een ander end-point dan de huidige API's. De publieke API kan gepubliceerde onderwerpen, publicaties en documenten raadplegen (GET).

Aandachtspunt is de robuustheid. We moeten er rekening mee houden dat de publieke API veel bevraagd gaat worden. Vaak zullen álle onderwerpen, publicaties en documenten opgehaald worden. Ook de bestanden zullen massaal opgevraagd worden t.b.v. indexering en voor AI-toepassingen.

Een externe uitvraag mag er niet toe leiden dat het GPP-Woo (tijdelijk) onbruikbaar wordt voor de gemeente en haar burgers. Ik vraag mij daarom af of we een duplicaat van de data en/of bestanden moeten maken voor bulk-uitvragen.

Daarnaast vraag ik mij af of we de oplossing op de GPP-publicatiebank of op het GPP-Zoeken moeten bouwen. Wat vinden jullie?

(Heeft geen bloedspoed...)

Sergei
[Wednesday at 2:37 PM]
op publicatiebank m.i. - ze gaan zelf de full-text indexing doen op basis van de documenten zelf.

qua performance - dit is een goede kandidaat voor horizontaal schalen. Meerdere instanties op basis van dezelfde database helpen met beschikbaarheid, in het slechtste geval kan een read-replica van de database bijgeplust worden om het helemaal van elkaar te scheiden

het serveren van de bestanden maakt nu al gebruik van streaming en zou behoorlijk efficient moeten zijn

echter - load testing en profiling + tweaken van infrastructuur om te kijken wat wel/niet wenselijk is, lijkt me verstandig

we kunnen ook rate-limiting toepassen op de endpoints hiervoor bedoeld zodat we niet alle capaciteit kunnen opeisen. Ook hier kunnen we tiers gebruiken zodat de rate limits voor een burgerportaal/gpp-zoeken een stuk meer toelaten dan de nieuwe endpoints voor research doeleinden

[MarcoKlerks]

Refinement — 2026-08-07

Insights incorporated:

• Narrowed the Epic to GPP-Woo's own actionable scope: a read-only access path for external data re-users, built on the Publicatiebank. The full external WooPush pitch (UvA & ICAI OpenGov Lab) was extracted verbatim to a PDF and shared directly with Marco Klerks rather than reproduced in the issue body; it's referenced from Design Artifacts.
• Folded the Marco/Sergei discussion thread into the Epic body: build on Publicatiebank (not GPP-Zoeken) since re-users do their own full-text indexing; horizontal-scaling and rate-limit-tiering as the mitigation for bulk-query load; load testing/profiling as an open follow-up.
• Introduced the domain actor Hergebruiker ("re-user" — the established Woo/open-data legal reuse-right term) in place of "onderzoekspartij"/generic "user."
• Added an explicit Out of Scope section excluding WooPush's own build (recommendation engine, citizen profiles/portal, funding, research ethics/DPIA) — that responsibility sits with the UvA, not GPP-Woo.

Sections updated: Stakeholders, Bounded Context, Context, Goal, Success Metrics, Design Artifacts, Out of Scope, Risks, Feature Breakdown (full restructure — original body was the external pitch pasted with no template headers)

Validations re-run: DDD Language Guard (Hergebruiker terminology, removed tech jargon like "REST API endpoint"); vertical-slice/scope gate — no split signals (single objective, single primary bounded context, 4 features, one beneficiary group)

Labels affected: none (Epic has no lifecycle labels)

Children that may need refinement: none — no child Features exist yet

[MarcoKlerks]

Refinement — 2026-08-07 (#2)

Insights incorporated: onderzoek van de provisioning-repo (Dimpact's eigen Azure/AKS-hostingconfiguratie), met als expliciete kanttekening van de auteur dat andere hosting-partijen mogelijk een andere configuratie gebruiken:

• CNPG-read-replica's zijn al standaardpraktijk in productie (3-instance cluster) — verduidelijkt het bestaande "horizontale schaling"-risico.
• Rate-limiting bestaat nog niet op de gedeelde Traefik-ingress — bevestigt dat dit nieuw gebouwd moet worden.
• Twee nieuwe risico's toegevoegd: geen cluster-autoscaling (schalen is vandaag handmatig) en per-gemeente ResourceQuota-plafonds.
• Belangrijkste toevoeging: een expliciet risico dat deze technische bevindingen Dimpact-specifiek zijn en niet als universeel voor elke hosting-partij mogen gelden.
• Nieuwe Success Metric + Feature Breakdown-item: na deze Epic moeten de aanbevolen/vereiste hosting-specs generiek gedocumenteerd worden in de GPP-publicatiebank-documentatie (voor alle hosting-partijen, niet alleen Dimpact).

Sections updated: Success Metrics, Design Artifacts, Risks, Feature Breakdown

Validations re-run: geen — verrijking van bestaande risico's en één nieuw Feature Breakdown-item, geen scope-uitbreiding die een nieuwe scope-gate-toets vereist

Labels affected: none

Children that may need refinement: none — nog geen child Features onder #88