CKAN: installatie, extensies, harvesting en API

CKAN 2.12.0 is de nieuwste stabiele release. Het wijzigingsoverzicht in de CKAN-documentatie noemt als datum 26 augustus 2026 en zegt dat CKAN 2.12 Python 3.10 en nieuwer ondersteunt. Dezelfde dag verschenen de patchreleases 2.11.6 en 2.10.11. De releasedata zijn gelijk aan die van de releases in de repository ckan/ckan op GitHub. De publieke demo-instantie op demo.ckan.org meldde via status_show op 11 oktober 2026 nog versie 2.11.5, de Canadese overheidsportal 2.10.8: beide dus zonder de beveiligingsfixes van augustus.

Nieuw in 2.12 zijn onder meer bestanden als zelfstandige entiteit, snellere paginering in de DataStore en een nieuw thema (Midnight Blue) dat in 3.0 de standaard moet worden. Voor een gemeente die een portaal beheert is het belangrijkste punt van deze periode echter de beveiliging, zoals hieronder.

De afweging of CKAN überhaupt de juiste keuze is, staat op CKAN of alternatief. Deze pagina gaat ervan uit dat u CKAN gekozen hebt en wilt weten hoe het werkt. De achtergrond bij het Nederlandse metadataprofiel staat op DCAT-AP-NL.

De patchreleases van 26 augustus 2026 repareren acht kwetsbaarheden. Het wijzigingsoverzicht van 2.11.6 noemt ze met GitHub-advisorynummer (GHSA) en de aantekening "CVE pending". In de advisorylijst van ckan/ckan staat bij zes ervan inmiddels een CVE-nummer, maar die records waren op 11 oktober 2026 nog niet gepubliceerd in cve.org of de NVD. Deze pagina gebruikt daarom de GHSA-nummers:

De API package_search staat voor iedereen open, dus de eerste regel is bij een publieke instantie de meest relevante. Ook de vorige ronde (2.11.5 en 2.10.10, 29 april 2026) bevatte een SQL-injectie zonder inlog in datastore_search_sql (CVE-2026-42031). Werk dus bij naar 2.10.11, 2.11.6 of 2.12.0, en leg vast wie updates inplant en binnen welke termijn. Dat hoort bij beheer en hosting.

CKAN kent drie officiële installatiewegen: pakket, broncode en Docker Compose. De documentatie beschrijft ze als volgt naast elkaar:

Let op de leeftijd van de pakketinstallatie. De pakketweg noemt alleen Ubuntu 20.04 en 22.04. Controleer vóór u kiest of dat besturingssysteem nog ondersteund wordt door de leverancier ervan en pas anders de Docker Compose- of de broncode-installatie toe. Het draaiende systeem bestaat in alle gevallen uit de CKAN-applicatie, PostgreSQL voor de database, Solr voor zoeken en Redis; de pakketinstallatie voegt daar de DataPusher aan toe, een aparte service die bestanden automatisch in de DataStore laadt.

Voor productie komt daar meer bij dan de installatie zelf: back-ups van PostgreSQL en de bestandsopslag, TLS, monitoring en een updatebeleid. Waar dit in de EU draait, speelt ook EU-cloud voor overheidsdata. De totale opzet voor een gemeente, inclusief catalogus en publicatie, staat bij open data-platform.

ckanext-dcat is de extensie die CKAN-metadata als DCAT-RDF aanbiedt en andere catalogi kan inlezen. De documentatie omschrijft het als volgt:

Ckanext-dcat is a CKAN extension that helps data publishers expose and consume metadata as serialized RDF documents using DCAT

Bron: documentatie van ckanext-dcat. De extensie valt, net als CKAN zelf, onder de AGPL; de laatste versie op PyPI is 2.4.4 van 11 augustus 2026. Over CKAN 2.12 spreken de bronnen elkaar tegen: de README en de documentatie zeggen nog "currently supported in CKAN 2.10 and CKAN 2.11", maar het changelog van 2.4.4 meldt "Support for CKAN 2.12" en de testworkflow van het project draait op 2.10, 2.11 en 2.12. Test bij een upgrade naar 2.12 daarom uw eigen profiel en harvesters in een kopie.

De installatie is kort:

pip install ckanext-dcat
# in uw CKAN-configuratiebestand:
ckan.plugins = dcat dcat_rdf_harvester structured_data

Volgens de documentatie biedt de extensie vooraf gebouwde schema's (voor ckanext-scheming) voor DCAT-AP versie 1.1, 2.1 en 3 en voor DCAT-US 3, DCAT-endpoints in verschillende RDF-serialisaties, en een RDF-harvester (dcat_rdf_harvester). Het standaardprofiel is euro_dcat_ap_3; voor automatisch harvesten installeert u daarnaast ckanext-harvest. In de basisprofielen die de documentatie noemt, staat geen DCAT-AP-NL; test daarom met uw eigen metadata of een Nederlands profiel van een derde of eigen aanpassing nodig is.

De Canadese portal draait ckanext-dcat (zichtbaar in status_show). Daar geeft /data/en/dataset/<id>.ttl één dataset als Turtle (status 200, mediatype text/turtle, met één dcat:Dataset en twee dcat:Distribution's) en geeft /data/en/catalog.ttl de catalogus gepagineerd met hydra:PagedCollection, 100 datasets per pagina en in totaal 48.071 datasets (481 pagina's). Een valkuil: de paginalinks in die catalogus verwijzen naar https://open.canada.ca/catalog.ttl?page=… zonder het deel /data/en, en dat adres gaf op 11 oktober 2026 status 404. Een harvester die de links blind volgt, loopt vast; zet bij een eigen portaal achter een proxy de site-URL dus correct.

De CKAN-API werkt met acties onder /api/3/action/ en geeft JSON terug. Lezen vraagt voor publieke gegevens geen inlog. De twee acties die u het meest gebruikt zijn package_search om te zoeken en package_show om één dataset in te zien. De API-documentatie zegt over de eerste dat ze solr-zoekparameters accepteert en daarnaast zoekresultaten, een aantal en facetten teruggeeft.

Het voorbeeld hieronder draait tegen de openbare Canadese portal, omdat die op 11 oktober 2026 met een open API en uitgebreide data beschikbaar was. De portal is zelf geen Nederlandse bron; het gaat om de werking van de API. Zoeken met curl:

curl -s -G "https://open.canada.ca/data/en/api/3/action/package_search" \
  --data-urlencode "q=hydrology" --data-urlencode "rows=1" \
  --data-urlencode "fl=name,license_id,metadata_modified"

Antwoord op 11 oktober 2026, ingekort:

{"success": true, "result": {"count": 396,
 "results": [{"name": "725d34b9-59b2-4dc8-8068-0a5a1d770380",
  "license_id": "ca-ogl-lgo", "metadata_modified": "2024-12-09T17:14:40.219Z"}], ...}}

Dezelfde stappen in Python, met alleen de standaardbibliotheek. Het script zoekt, haalt de eerste dataset op en toont de naam, de licentie en de formaten van de resources:

import json, urllib.parse, urllib.request

BASE = "https://open.canada.ca/data/en/api/3/action/"

def action(name, **params):
    url = BASE + name + "?" + urllib.parse.urlencode(params)
    with urllib.request.urlopen(url, timeout=30) as resp:
        body = json.load(resp)
    if not body["success"]:
        raise RuntimeError(body.get("error"))
    return body["result"]

zoek = action("package_search", q="hydrology", rows=1)
print("treffers:", zoek["count"])
ds = action("package_show", id=zoek["results"][0]["id"])
print(ds["name"], ds["license_id"], [r["format"] for r in ds["resources"]])

De uitvoer was treffers: 396 en daarna 725d34b9-59b2-4dc8-8068-0a5a1d770380 ca-ogl-lgo ['CSV', 'CSV']. Het aantal treffers verandert met de inhoud van de portal. Voor een eigen portaal vervangt u alleen de BASE-URL.

Schrijven (datasets aanmaken of wijzigen) vraagt een API-token in de header Authorization, en dat token hoort niet in broncode of in een repository. Hoe u die publicatie in een gemeente inricht, staat bij open data publiceren als gemeente.

De valkuilen zitten minder in de installatie dan in het onderhoud en in de verwachtingen over metadata.

• Parameter rows. Het verzoek package_search?rows=-1 gaf op de Canadese portal status 409 (conflict). Vraag dus altijd een positief aantal op en loop met start door de resultaten; de catalogusendpoints pagineren per 100.
• Veldfilter fl. Op dezelfde portal gaf fl alleen de gevraagde velden terug. Dat spaart bandbreedte, maar het veld title_translated kwam er niet uit, ook niet toen het in fl stond. Haal titels en andere extensievelden daarom op met package_show.
• Versieverschillen tussen portalen. De demo draaide op 2.11.5, de Canadese portal op 2.10.8. Een script dat tegen één versie is getest, kan anders reageren op een ander. Lees status_show om te zien welke versie en welke extensies er draaien.
• Zoekmachine en database. Het zoeken loopt via Solr, niet via PostgreSQL. Een dataset die net is aangemaakt, kan even niet vindbaar zijn als de index achterloopt.
• AGPL. Wijzigt u CKAN of een extensie en biedt u die als netwerkdienst aan, dan moet u de broncode van die wijzigingen aan de gebruikers beschikbaar stellen. De consequenties staan op CKAN of alternatief.

Voor een gemeente met een handvol datasets is een volledig CKAN-portaal vaak meer dan nodig: een statische DCAT-catalogus kan volstaan, zoals beschreven op de pagina over alternatieven, en u bespaart het beheer van PostgreSQL, Solr en Redis. Kies ook niet voor CKAN als u vooral een kaartviewer zoekt; daarvoor is een viewer als de GIS-viewer voor gemeenten bedoeld. Zoekt u geodata-API's naast uw catalogus, dan past pygeoapi of GeoServer er goed naast, met CKAN als catalogus erboven.

Kies CKAN ook niet als niemand het patchritme kan dragen. Deze pagina laat twee beveiligingsrondes in vier maanden zien, met elke keer een database- of DataStore-onderdeel erin, en een portaal dat een jaar niet is bijgewerkt is dan een risico. Hebt u die capaciteit niet, dan is een statische DCAT-catalogus die data.overheid.nl kan harvesten vaak verstandiger. De rol van CKAN binnen een groter dataplatform, naast opslag en API's, staat bij dataplatforms.