Ok, even wat leuks. Stel je wil je eigen bijdrage leveren aan een open rijksoverheid, dan begrijp je al dat een open en transparante overheid natuurlijk nimmer door een gepolitiseerd orgaan zelf kan worden georganiseerd! En als decentralist denk ik dan: ieder z’n eigen transparantieserver! Een recept.
Men neme: https://tweakers.net/pricewatch/1834992/synology-diskstation-ds1522+-zonder-harde-schijven.html. Wat harde schijven erbij https://tweakers.net/pricewatch/2069470/wd-red-pro-6005ffbx-6tb.html en extra geheugen (dubbel zoveel).
Dan heb je dus een “Linux <naam> 4.4.302+ #72806 SMP Mon Jul 21 23:12:58 CST 2025 x86_64 GNU/Linux synology_r1000_1522+”. Die komt met Python 3.8.15 en DSM 7. En ook Docker version 24.0.2, build 610b8d0. Daarnaast gebruik ik Portainer 2.33.0 LTS. Dan draait er postgres:latest waarbij het extra geheugen van de server voor 80% beschikbaar is voor de database en ook andere parameters opgeplust zijn. En wie een beetje oplet snapt dat om het even welke andere Linux variant met python3.8 of hoger en postgres dus ook wel werkt.
De SQL inrichting voor de database vind je hier als een sql bestand. Dat is een dump van alle tabellen, views, materialized views, functies en triggers die op de Wookey database geconfigureerd zijn.
Het python script wookey.py leest de site open.minvws.nl uit (via parameter –search en daarna –eval) en dumpt de gegevens in een .txt bestand waarin een iteral zit opgesloten met de kenmerken van een verzoek of daaraan gekoppeld document als tags. De tag sleutels worden live uitgelezen vanaf de site en zijn gebaseerd op de toegekende omschrijvingen aan een specifieke waarde. Klinkt dat logisch? Voorbeeldje:
De gegevens van die pagina worden als volgt geregistreerd, onder vermelding van de URL, in de tags tabellen om historische redenen aangeduid met “Title”:
Dus wookey.py dumpt gegevens in .txt bestanden met een python iteral erin. En wookey-import.py importeert vervolgens deze .txt bestanden in de juiste tabellen, waarbij gegevens worden verrijkt en gecontroleerd wordt op dubbelingen.
De –download functie van wookey.py download geregistreerde bestanden op basis van hun download URL in de lokale folders. Die functionaliteit werkt door bijvoorbeeld een volgende SQL querie te gebruiken:
SELECT DISTINCT ON (dt."Title", dt.tag_key, COALESCE(dt.tag_value, '--'))
dt."Title" AS title
, dt.tag_key AS tag_key
, COALESCE(dt.tag_value, '--') AS download_url
, dt2.tag_value AS bestandsnaam
, dt."CreatedDate"
FROM documents_tags dt JOIN documents d ON d."Locatie open.minvws.nl" = dt."Title"
LEFT OUTER JOIN documents_tags dt2 ON dt."Title" = dt2."Title"
WHERE dt.tag_key LIKE 'DocumentDownload_linkhref%'
AND dt2.tag_key LIKE 'DocumentDownload_proposed_filename%'
AND NOT dt.tag_value IS NULL
AND NOT dt2.tag_value IS NULL
AND d."DigestLaatsteControleDatum" IS NULL
AND dt2.tag_value NOT LIKE '%Woo-besluit%' -- geen besluiten
AND dt2.tag_value NOT LIKE 'wob-besluit%' -- geen besluiten
AND dt2.tag_value NOT IN (<..lijst..>) -- deze ook niet
AND dt2.tag_value NOT LIKE 'besluit-op%' -- geen besluiten
AND dt2.tag_value NOT LIKE 'besluit-wob-verzoek%' -- geen besluiten
AND dt2.tag_value NOT LIKE 'op-woo-verzoek%' -- geen besluiten
AND dt."validUntil" = '9999-12-31' -- alleen geldige
AND dt2."validUntil" = '9999-12-31' -- alleen geldige
Moet ik dat uitleggen? Uit documents_tags worden die tags geselecteerd met download urls, de voorgestelde bestandsnaam (proposed_filename) wordt gebruikt als lokale bestandsnaam (… yep, dat levert natuurlijk problemen op als de download bestanden in dezelfde folder terechtkomen) en alleen de laatst geldige URLs worden gebruikt. In het hiergenoemde voorbeeld wordt dus dit bestand lokaal gebracht.
Als je tot hier gelezen hebt, chapeau! Op de beta pagina’s meer inhoudelijke data. Dat is de werkwijze: er is data, er zijn logs, er zijn alerts, nu nog een kwestie van samenbrengen. En dat doen we dan live, terwijl iedereen meekijkt. Chatten? Op https://chat.wookey.nl/.