Open-data integration

CKAN Bridge — opt-in Pod→portal publication.

A decoupled microservice between the Solid Databox and a CKAN data portal. It lets agencies publish governed Pod data while preserving the natural person’s agency over personal information.

NewOpt-in profile

Pipeline

Read → validate → translate → publish → reconcile.

Solid Pod layer          CKAN Bridge              CKAN registry
(Solid-OIDC / DPoP) -->  SHACL + RDF→tabular  -->  Action API
                         webhook / HMAC           datastore upsert
                         reconciliation           metadata fields
                         correction propagate

Solid-OIDC client

DPoP-bound access tokens for reading Pods; short-lived, cached, fail-closed on expiry.

SHACL validator

Fail-closed validation before any data reaches CKAN; non-compliant payloads are quarantined.

RDF→tabular translator

Program-profile-driven field mapping with PII anonymisation (strip, hash, generalise) and evidence recording.

Publication pipeline

Idempotent via sha256(podIri:contentDigest); bounded retries with quarantine on max-retries-exceeded.

Webhook handler

HMAC-SHA256 signature verification, idempotent event deduplication for dataset lifecycle events.

Reconciliation & corrections

Periodic sweeps detect editor drift and orphaned datasets; Databox dispositions propagate back into CKAN.

CKAN plugin

Thin plugin, heavy lifting in the bridge.

What the plugin does

  • Emits webhooks on dataset created / updated / deleted / datastore changes
  • Exposes Action API endpoints for status synchronisation
  • Adds Databox metadata fields (provenance, policy, SHACL shape, consent receipt IRIs)
  • Restricts write access to the bridge service token; public users stay read-only

What it deliberately does not do

  • No Solid authentication or RDF parsing inside CKAN
  • No SHACL validation in the plugin process
  • No direct database manipulation
  • No change to CKAN defaults until databox_bridge is enabled

Related

Spec, plan and source.