Skip to main content

From Features to a Platform

A shortlist of two to four platforms is compared on mandatory features. A platform for which a mandatory feature is impossible drops out before any talk of price or the number of ticks.

By this point the feature list already exists: it is built in the chapter "Selecting Features". Here it is applied to platforms.

Step 1. The approach, then the brand​

First not CKAN or Dataverse, but the approach: someone else's catalog, a static site, a cloud service, open source, a custom build. The criteria and the cost of leaving are in the chapter "Build, Open Source or SaaS". If there is little data and no team, a comparison of CKAN with Dataverse is not needed: publish in an existing catalog.

Step 2. The shortlist​

Two to four platforms of the class that matched the data type and the approach. Guidance: classes of software and profiles.

What you publishUsual shortlist
A public authority's datasets, with its own teamCKAN, DKAN, udata
A public authority's datasets, no teamHuwise, Socrata, publishing in a regional or national portal
Research data with DOIsDataverse, InvenioRDM, publishing in Zenodo
Map layers and servicesGeoNetwork, ArcGIS Hub
IndicatorsPxWeb, .Stat Suite, OpenSDG
Survey microdataNADA, Dataverse
A dozen files, no teama static site or a Git repository

A platform from the neighbouring row does not get on this list. A research repository does not cover a daily open data portal, and CKAN with an untested DOI extension does not replace Dataverse.

Step 3. The matrix​

For each mandatory and desirable feature, put one of four marks:

  • core: present in the platform itself;
  • extension: present in a named module, and you have checked who maintains it and which core version it works with;
  • customisation: the platform has a place to build it in, and a developer estimates the effort;
  • impossible: the platform cannot do it and cannot be extended to.

A platform with "impossible" on a mandatory feature drops out. The rest are compared on launch and maintenance cost, not on the number of ticks.

"Customisation" and "impossible" belong only to this comparison. The platform summary in the appendix uses different words: core, extension, no, not checked. A "no" cell goes into the matrix as "impossible" only if the feature cannot be added. A "not checked" cell does not go into the matrix: it is closed from the documentation before the platform gets on the shortlist.

An example for a region that needs a DCAT dump for the national portal, harvesting of municipal catalogs and staff login through the organisation's accounts. A DOI is not mandatory for the region.

FeatureCKANHuwiseSocrataYour own site on a generator
DCAT dumpthe ckanext-dcat extension, DCAT-AP 3 by defaultcore; the national profile is not available on every installation and has to be checkedcore: a data.json file per DCAT-US, not DCAT-APtemplate customisation
Search APIcorecorecoreimpossible without a separate program
Custom fields required by lawthe ckanext-scheming extensioncore (field templates)core (fieldsets)customisation
Harvesting municipal catalogsthe ckanext-harvest extensioncore: harvesters for CKAN, Socrata, ArcGIS, data.json and other Huwise portals; CSW enabled on request through supportcore: the Catalog Connector takes data.json and a public ArcGIS Serverimpossible
Login through the organisation's accountsextension (SAML or OpenID Connect)core: SAML and OpenID Connectcore: OpenID Connect; SAML through supportno
DOIextension; not tested on CKAN 2.11 and 2.12nonono

A cloud service sets up custom fields in templates without a programmer, but they reach the DCAT dump only if the provider has provided a mapping. In Socrata, fields with names known in advance go into the data.json file.

If the national portal expects DCAT-AP, Socrata drops out of this list: its standard file is DCAT-US. Huwise stays until the pilot shows whether the needed profile is there. CKAN stays if ckanext-dcat and the login extension have been checked on the core version that is going to be installed. If a DOI suddenly becomes mandatory, nobody in this four remains: a research repository is taken, not "CKAN plus an unknown extension".

Step 4. Testing on real data​

Set up a pilot or open a demo instance and publish five to ten real datasets, including an awkward one: without a licence in the source, with a large file, with daily updates. Then check as described in the chapters on capabilities.

  • The DCAT dump opens without a login and passes the validator of the profile the higher-level portal expects.
  • The dataset page has schema.org markup, if search engines are supposed to find the dataset.
  • The dataset address does not change when the title is corrected.
  • The file downloads via a direct link.
  • If the matrix says "extension", exactly that extension is installed on the instance, and its version is visible.

A pilot on the provider's demo data does not replace this check. For a cloud service, the pilot also covers the question of leaving: all descriptions and files can be exported in full.

When a custom build is justified​

All four statements are true at the same time:

  • no platform on the shortlist covers a mandatory feature, even with a living extension;
  • the feature does not go away if the task is narrowed (for example, publishing research data in Dataverse and operational data on the portal);
  • there is a team not only for the launch but for five years of maintenance;
  • your own system will still have persistent addresses, a licence per dataset, a metadata dump and schema.org.

If the fourth is "we'll do it later", the custom build will repeat the most common problem of custom-built catalogs: people use the site, but programs cannot see it. According to the dataportals-registry export (release 1.27.0 of 15 October 2026), among indicator catalogs, where custom builds are most common, only 37% have an API.

Step 5. Record the decision​

Every fork in the road (platform, extension, rejecting a feature, custom build) is set out as a decision record. Four complete examples of such a chain are in the chapter "Worked Examples".

Common mistakes​

  • Eight platforms in one table. A shortlist longer than four can no longer be compared: the differences drown. First the class is cut off, then brands are compared.
  • A "not checked" cell rewritten as "no". In an earlier version of this chapter, Huwise's harvesting was listed as not checked, although the service's documentation has harvesters. An open cell is closed from the documentation, not by crossing out the platform.
  • An extension recorded as a weakness. ckanext-dcat is an ordinary part of a mature CKAN portal. It becomes a weakness when it has not been tested on the needed core version.
  • A pilot on the provider's data. Ten demo datasets from someone else do not show your large file, your DCAT profile and your login.

Sources​