## Beleid en bestuurstukken We hebben gekeken naar de beleid en bestuursstukken van de lagere overheden, de gemeenten, de provincies en de waterschappen. De gemeenten en een aantal provincies maken hun stukken beschikbaar via [OpenRaadsinformatie](https://zoek.openraadsinformatie.nl/) en via eigen kanalen. De waterschappen alleen nog via eigen kanalen. We bespreken hier onze bevindingen wat betreft de gemeenten en [OpenRaadsinformatie](https://zoek.openraadsinformatie.nl/), en de waterschappen. Aangezien de provincies niet in de API van [OpenRaadsinformatie](https://zoek.openraadsinformatie.nl/) te vinden waren hebben we die buiten beschouwing gelaten. Wij hanteren een breed begrip van beleid en bestuursstukken: verslagen van raads- en commissie-vergaderingen, alsmede agendas en besluitenlijsten, plus alle stukken die op die vergaderingen besproken worden. Een mooi voorbeeld van een helder opgezette website met dit soort informatie is die van [Almelo](https://almelo.bestuurlijkeinformatie.nl/). Dit voorbeeld van een [Politiek Beraad](https://almelo.bestuurlijkeinformatie.nl/Agenda/Index/b4f3c1e1-fe05-4fad-a38c-65148a75c14d) geeft de complexiteit van zo'n vergadering weer. We hebben hier een sterk aan elkaar geknoopt geheel bestaande uit de [agenda](https://almelo.bestuurlijkeinformatie.nl/Agenda/Document/b4f3c1e1-fe05-4fad-a38c-65148a75c14d?documentId=022fffe5-8b0e-4ad2-8134-d301c0ea0dd8), de videotulen van de hele avond, en per agendapunt een titel, korte samenvatting, namen van belangrijke spelers op dat punt en de bijbehorende stukken. Wat in dit voorbeeld opvalt is dat de "stukken achteraf", bijvoorbeeld de gedane toezeggingen of genomen besluiten niet gekoppeld zijn aan deze gebeurtenis. ### Gemeenten De VNG en OpenState hebben in een gezamelijk project een soort eigen PLOOI voor de beleid en bestuursstukken van de gemeenten en de provincies ontwikkeld: [OpenRaadsinformatie](https://zoek.openraadsinformatie.nl/). Deze website wordt automatisch gevuld vanuit de zaaksystemen van de bestuursorganen, en dan min of meer in een gemeenschappelijk schema geplaatst. Informatie is zowel beschikbaar via de website als via een API. Via de website is er slechts weinig metadata per document beschikbaar, via de API is dat flink meer, maar valt de standaardisatie weg. De zogeheten "rapporten" (dit zijn eigenlijk dossiers met wat metadata en één of meer bijbehorende stukken) van alle gemeenten uit de API zijn verzameld. Dit waren 107 gemeenten. Dit zijn in totaal 158.378 rapporten met 251.185 verschillende documenten. Samen hebben deze 1.601.812 pagina's. Het blijkt dat er in totaal 262 verschillende termen worden gebruikt om deze rapporten te classificeren. Hieronder de top daarvan, met het aantal rapporten dat zo geklassificeerd is. De grote verscheidenheid valt op. Voor gebruik vanuit één bestuursorgaan geeft dit natuurlijk niets. Voor een overzichts website als PLOOI of Woogle en ook Openraadsinformatie is dit natuurlijk erg onhandig. `'Ingekomen stukken': 18395, 'Moties': 13918, 'Raadsbrieven': 10888, 'Raadsvragen': 9578, 'Schriftelijke vragen': 8251, 'Toezeggingen': 7733, 'Brieven aan de raad': 7465, 'Export': 6634, 'Raadsinformatiebrieven': 4602, 'Amendementen': 4358, 'RSS': 4036, 'Besluitenlijst B&W': 3141, 'Collegebrieven': 2970, 'Informatieve Stukken College': 1777, "Informatienota's": 1663, 'Post aan de raad': 1503, 'Collegebesluiten ter informatie': 1430, 'Verslagen Raad': 1238, 'Lijst Ingekomen Stukken': 1204, "Memo's": 1148, 'Besluitenlijsten college': 1108, 'Schriftelijke vragen en antwoorden': 1083, 'Ingekomen stukken - College': 1080, 'Uitnodigingen': 1054, 'Artikel 43 vragen': 1012, 'Technische vragen': 1005, 'Besluitenlijsten B&W': 996, 'Griffie-info documenten': 994, 'Ingekomen stukken Cluster Sociaal': 987, 'Artikel 44 vragen': 940, 'Raadsvragen Schriftelijke': 892, 'Raadsinfo': 876, 'Notities ter info': 872, 'Ingekomen stukken raad': 866, 'Raadsvragen en antwoorden': 864, 'Verslagen': 843, 'Raadsbesluiten': 810, 'export': 802, 'B&W besluiten': 776, 'Schriftelijke vragen art. 41': 729, "Raadsmemo's": 720, 'Collegebesluiten': 646, 'Toezeggingen Export': 645, 'Verslagen M&S': 576, 'Besluitenlijsten': 565, 'Openbare besluitenlijsten college': 533, 'Ingekomen stukken Cluster Bestuur': 487, 'Stukkenstroom': 481, 'Commissie informatiebrieven': 453, 'Schriftelijke vragen (artikel 41 RvO)': 435, 'Verslagen S&R': 406` **Figuur: Top meest gebruikte termen samen met het aantal keer dat ze gebruikt zijn in de openraadsinformatie API om rapporteren te klassificeren.** In de API wordt ook de machineleesbare tekst van de stukken meegegeven. Het valt op dat die vaak van prima kwaliteit is, maar dat we ook best veel gekke, half leesbare, met OCR fouten doorspekte stukken tekst tegenkomen. Naast de niet gestandaardiseerde metadata is hier dus ook de kwaliteit van de machineleesbare tekst een probleem. Om te kijken of de metadata niet makkelijk uniformer en rijker zou kunnen hebben we twee gemeentes, Hoorn en Utrecht, die beiden het ibabs bestuurlijkeinformatie systeem gebruiken dieper geanalyseerd. Het idee was dat allicht alle gemeentes met hetzelfde achterliggende systeem ook dezelfde terminologie zouden gebruiken. Jammer genoeg bleek dit, althans voor ibabs, een misvatting. Hoorn gebruikte 8 typen om hun documenten te klassificeren, en Utrecht 14. Slechts twee daarvan waren gedeeld: de *besluitenlijst B&W*, en *RSS*. Daarnaast hebben de documenten zelf ook weer metadata. Een motie heeft bijvoorbeeld indieners. Ook om die metadata aan te geven gebruiken deze twee gemeentes weer hun eigen terminologie. Hoorn heeft er 24 en Utrecht 18. Hiervan komen er 8 overeen: Gerelateerde items, Portefeuillehouder, Afgedaan, Deadline, Omschrijving, Onderwerp, Datum beantwoording en Opmerking. Dit inkijkje laat zien dat hier een wereld te winnen is. ### Waterschappen Van de 21 waterschappen gebruiken er 11 het *bestuurlijkeinformatie* systeem van ibabs, en 2 een notubiz systeem. Zoals in onderstaande tabel te zien is zijn de basisonderdelen overal wel aanwezig, maar verschillen de waterschappen nog best in de uitvoering. Ook de inrichting van de publicatielaag bovenop zo'n ibabs systeem kan op veel manieren gebeuren, en dat zien we ook. | Eigenschap | | |:-----------------------------------------------------|----:| | Videotulen per vergadering | 21 | | Agendas per vergadering | 21 | | Elke vergadering eigen url | 21 | | Alle agendas eigen URL | 14 | | Vergadering als meerdere files | 12 | | Staan ze handig bij elkaar? Makkelijk te downloaden? | 12 | | Besluitenlijsten per vergadering | 9 | | Elke besluitenlijst eigen url | 5 | | Sprekers aangegeven met naam en tijdsaanduiding | 1 | **Tabel: Eigenschappen van de beleids en bestuurstukken, hoe vaak komen ze voor? (N=21)** #### Aanbevelingen 1. Het deel voorafgaand aan een vergadering (de agenda, en de te bespreken stukken) is prima in orde, maar het deel achteraf (de besluitenlijst) kan in veel gevallen duidelijker gepresenteerd worden. 2. Videotulen hebben als grote voordeel dat ze meteen beschikbaar zijn, tegen lage kosten. Het nadeel is dan weer dat er veel minder makkelijk in te zoeken is dan in uitgeschreven notulen of *Handelingen*. Dit kan voor een groot deel opgelost worden door automatische spraakherkenning toe te passen, en het zo ontstane transcript op te lijnen met de video. Daarbij komt zoeken met Control F, maar dan in een video voor iedereen beschikbaar. Ook kan het automatische transcript beschikbaar gesteld worden. Maurice Silvério heeft zo'n systeem ontwikkeld voor de gemeente Buren en beschreven in [zijn sctiptie](https://wooverheid.nl/2023/06/30/zoeken-in-videotulen/). ### Conclusie De weerslag van de democratische processen in de lagere overheden gaat vaak heel goed op lokaal niveau. Maar om dit samen te brengen in één overkoepelend systeem waarin alles op dezelfde uniforme en rijke wijze beschikbaar is, zal nog een enorme klus zijn. Het openraadsinformatie initiatief laat zien dat het technisch mogelijk is alle stukken automatisch bij elkaar te brengen, en zo een soort PLOOI-achtig platform mogelijk te maken. Dat zou echter veel rijker kunnen als de metadata gestandaardiseerd zou zijn. De niet uniforme metadata zorgt dat de API van openraadsinformatie zowel voor *hergebruik* als voor het *koppelen van informatiebronnen* nog niet ideaal is. Hier is nog een wereld te winnen!