Het zal niemand verbazen dat de (meeste) Nederlandse gemeenten moderne ICT-gebruiken voor zowel hun interne bedrijfsvoering als voor de communicatie met haar “klanten” de burgers van de gemeente! En net als in de rest van de wereld is er in de loop van de tijd een wildgroei ontstaan in gebruikte software, databases, communicatie-protocollen en meer. De laatste jaren worden er ook steeds vaker apps voor allerlei doeleinden gemaakt en ingezet om de eigen burgers en/of “bezoekers” van de gemeente ten dienst te staan. Denk daarbij aan apps waarmee de raadsvergaderingen gevolgd kunnen worden, de besluiten van de gemeenteraad bekeken kunnen worden of waarmee de burgerij op hoogte gehouden kan worden van een gewijzigd vuilophaalschema ivm Pasen of Koningsdag. Door de “eigen” infrastructuur van iedere gemeente, moeten allerlei koppelingen steeds opnieuw gemaakt worden. En dat kost tijd en dus geld.

Nog lastiger wordt het wanneer men de gegevens van verschillende gemeenten wil vergelijken of combineren. Stel je wilt het stemgedrag van alle CDA-wethouders in de provincie Overijssel over bv. milieuproblematiek met elkaar vergelijken of de PvdA wil een app ontwikkelen waarmee leden kunnen zien hoe er door partijleden in naburige gemeenten gestemd is.

Huidige situatie bij de Nederlandse gemeenten. Anders dan men zou verwachten in het internettijdperk, is veel openbare informatie feitelijk onzichtbaar.

Tenslotte is er nog het probleem van de vendor-lockin: de gemeente heeft in het verleden gekozen voor het raads-ontsluitingssysteem van bedrijf X maar wil nu overstappen op dat van bedrijf Y. Als het een beetje tegen zit moet alles weer opnieuw ontwikkeld worden en dat kost een boel geld.

Het is een illusie (en wellicht onwenselijk) te denken dat alle gemeenten dezelfde software gaan gebruiken, maar het zou mooi zijn als ze wel allemaal dezelfde standaarden gaan gebruiken zodat het hergebruik van apps en andere software vergemakkelijkt wordt en de gegevens tussen de gemeenten veel makkelijker uitgewisseld en ook vergeleken kunnen worden.

Doel van de bijeenkomst

Na eenhartelijk welkom, ging Kees Groeneveld van KING nader in op het doel van de bijeenkomst: het bespreken van de wenselijkheid van open standaarden en de beste wijze om dit vervolgens te realiseren. Als dat lukt, dan kunnen alle (388) Nederlandse gemeenten via een portaal, op uniforme wijze worden ontsloten (zie afbeelding 2). Dat biedt mogelijkheden voor de verschillende overheden, maar maakt het ook mogelijk dat derde partijen allerlei diensten kunnen ontwikkelen die dan voor iedereen en overal beschikbaar komen. Vervolgens maakte Kees duidelijk dat KING werkt vanuit de “Digitale Agenda 2020” en het “Actieplan Open Overheid” van het ministerie van Binnenlandse Zaken. De focus ligt in eerste instantie op de ontsluiting van raadsinformatie als open data.

Men realiseert zich bij KING dat standaardisering voor sommige leveranciers een heikel punt zou kunnen worden omdat het de gebruikers (=gemeenten) veel makkelijker maakt om over te stappen op de systemen van de concurrent (maar ook het omgekeerde is natuurlijk ook het geval). Dit werd door de aanwezigen beaamd, maar uiteindelijk betwiste niemand (openlijk) de wenselijkheid om toch tot algemeen geaccepteerde open standaarden te komen.

Wie waren erbij?

Er waren 3 leverancier van webcasting systemen (Company Webcast, GemeenteOplossingen, NotuBiz), een aantal leveranciers van Document-Managementsystemen, een webbouwer, een TaalTech bedrijf (TM7, voormalig CARP) en een bedrijf dat Spraaktechnologie ontwikkelt en inzet (Telecats). Nadat iedereen zich had voorgesteld, hield Tom Kunzler (pilotmanager van KING) een duidelijk verhaal over de voordelen van Open Data en het belang ervan voor “de” maatschappij.
Na Tom’s verhaal was er ruimte voor wat vragen.

Vragen

Er kwamen veel vragen over de beste aanpak om gemeenten mee te krijgen. Het gebruik van Open Standaarden kan niet worden afgedwongen (dus geen stok) en dus moeten de gemeenten “verleid” worden (de wortel) om mee te doen. Zeker als de gemeenten alle data moeten overzetten naar de nieuwe standaarden, kan het een behoorlijke inspanning en dus kostenpost worden: iets waar met name de kleinere gemeenten niet op zitten te wachten. Ook waren er redelijk wat vragen over welke standaard dan gekozen zou moeten worden. Deze discussie werd vrij snel behoorlijk technisch met allerlei JSON voorbeelden, en dat was nu ook weer niet de bedoeling.

Duurzaamheid

Wat mij opviel was de afwezigheid van het onderwerp “duurzame opslag”. Een papieren document gaat, mits goed beheerd, tientallen jaren mee en kan hoogstwaarschijnlijk ook over 100-jaar nog gewoon gelezen worden. Met digitale data ligt dat anders. Zijn de databestanden over 10 jaar nog leesbaar (bit-rot) en is er over 10 jaar nog software die de huidige dataformaten aankunnen?

Beheer

En hieraan gekoppeld: wie gaat dat beheer en in de luchthouden betalen? De meeste aanwezigen vonden dat dit een taak is van de individuele gemeenten, maar zelf denk ik dat dat niet verstandig is: die hebben noch de mankracht noch de kennis om dit goed te kunnen doen. Bovendien is er voor de gemeenten ook geen duidelijke incentive. Het is waarschijnlijk verstandig te kijken naar een meer centrale opslag zoals het NA e-depot: een elektronisch depot van het Nationaal Archief dat de data niet alleen opslaat, maar ook de houdbaarheid en vindbaarheid van de digitale informatie voor langere tijd garandeert.

Open Standaarden

Daarna kwam de presentatie van Arjan Kloosterboer van KING. Een goed verhaal over de verschillende bestaande datamodellen en bijbehorende standaarden.

Popolo

Een interessant en voor mij onbekend initiatief dat Arjan noemde was de zgn Popolo-standaard: een datastandaard waarmee democratische organisaties en hun besluitvormingsprocessen gecontroleerd kunnen worden. Het richt zich met namen op bijeenkomsten, verkozen vertegenwoordigers en andere medewerkers, debatten en processen, zoals het stemmen of indienen van moties van democratisch gekozen organisaties (nationale parlementen, gemeenten, verenigingen en politieke partijen).

CMDI

Schema van een CMDI registry met verschillende profielenDe discussie kwam niet echt op gang dus probeerde ik het maar eens een voorbeeld uit de Geesteswetenschap: CMDI. Ook daar zien we grote hoeveelheden tools en data die elk hun eigen formaat hebben cq. gebruiken waardoor je eerst allerlei data moet herschrijven voordat je er met een tool mee aan de slag kunt gaan. Sommige data staat in Excel, andere in PDF of MS-word en weer andere data zit verborgen in MySQL-databases.

CMDI, onder andere in gebruik bij CLARIN-EU, staat voor “Component Meta Data Infrastructure” en is een poging om standaarden te ontwikkelen die flexibel genoeg zijn om, indien noodzakelijk, nieuwe metadata-velden toe te kunnen voegen, zonder dat alle oude metadata herschreven moet worden. Voor meer info zie hier.

De totale verzameling metadatacomponenten is verdeeld in zogeheten profielen. Een van die profielen zou bv “Raadsvergadering” of “Verkiezingen” kunnen zijn. Binnen zo’n profiel zijn dan verschillende componenten aanwezig die de data in zo’n profiel zo goed mogelijk beschrijven. Bij “raadsvergaderingen” zou je bv kunnen denken aan “sprekers”, “partijen”, “gender”, “topic”, “stemming”, etc.

Registry

Stel dat in een raadsvergadering tzt ook burgers mogen meepraten, dan zou er een nieuw metadataveld kunnen worden toegevoegd rol:= [politicus 1 burger 1 anders]. Om nu te voorkomen dat er een enorme wildgroei optreedt, moet er ergens een soort regie moeten zijn. In dit geval zou KING daar uitermate geschikt voor zijn. Mensen die nieuwe metadata componenten willen gebruiken, moeten die eerst goed beschrijven en vervolgens aanbieden aan KING. Die moet dan bekijken of de er niet al een vergelijkbare component bestaat (bv type:= [B&W 1 politieke-partij 1 burger 1 ambtenaar 1 anders]). Alle informatie in rol kan beschreven worden met type en dus voegt rol niets toe en wordt het afgewezen. Bestond type niet, dan zou rol kunnen worden geaccepteerd en kan het in de registry worden toegewezen. Voortaan kan iedereen dan ook rol als metadataveld toevoegen aan zijn data. Het formaat van de metadatacomponent rol ligt vast, de inhoud niet.

Een voorbeeld van zo’n CMDI component is het volgende:

<!-- metadata about a person -->
<component-actor>
   <!-- Note the support for multilingual fields, using the xml:lang attribute -->
   <title xml:lang="eng">mister</title>
   <title xml:lang="fra">monsieur</title>
   <title xml:lang="nld">mijnheer</title>
   <firstName>Willemien</firstName>
   <lastName>Luimes</lastName>
   <sex>female</sex>
   <age>55</age>
   <ActorLanguage>
    <ActorLanguageName>Dutch</ActorLanguageName>
  </ActorLanguage>
</component-actor>

voor meer info zie hier

Het voorbeeld van CMDI sloeg aan en beloofde er eens over na te gaan denken: we wachten af ?

Legacy

Moet nu alle oude data in zo’n CMDI-formaat gezet worden? Nee, niet per se. Ideaal gesproken gaat iedereen over op de nieuwe standaard, maar dat is een enorme hoop werk en het is dus niet realistisch te verwachten dat de gemeenten dat gaan doen.

Wat wel gedaan kan worden is het bouwen van schillen rond de bestaande data. Deze schillen zijn vertaal-tabellen die de vraag van buiten “<component-actor>” omzetten in bv <persoon> en dan in de oorspronkelijke data opzoek gaan naar een persoon, en vervolgens de gegevens ophalen. Voor de export naar buiten worden de gegevens dan eerst omgezet naar de gegevens die “<component-actor>” verwacht. Het creëren van deze schillen is natuurlijk ook werk, maar het moetmaar een keer gedaan te worden en kan vervolgens voor alle metadata van de raadsvergaderingen gedaan worden. Natuurlijk bestaat de kans dat er op deze manier data verloren gaat. De tag <persoon> bevat meer informatie dan de <component-actor> en die extra informatie komt op deze manier niet mee. Je kunt het daar dan bij laten of kijken of je de <component-actor> kunt upgraden zodat de extra informatie uit <persoon> er wel bij kan.

Conclusie

Voor een bedrijf als Telecats is het gebruik van Open Data zeer relevant. Het scheelt een enorme hoop werk wanneer we ervan uit kunnen gaan dat de

1. Data (audio, video, transcripties, metadata voor het taalmodel, etc.) op een uniforme wijze wordt aangeboden
2. Resultaten maar op een manier naar buiten gebracht moeten worden.

Als de Open Overheidsdata er komen, dan kunnen met een service, alle gemeente bediend worden. Nu moet er nog per gemeente een vertaalslag gemaakt worden en dat is onhandig, tijdrovend en duur. De keuze van de metadata standaarden is minder relevant, zolang de metadata maar rijk genoeg zijn om alles te beschrijven.