Skip to main content

Classes of Software

A catalog type says what is published. A software class says who updates it, whether a feature can be added and what it costs to leave. Within one class, platforms differ in extensions: see extension ecosystems.

Classes​

ClassExamplesWhen it fits
Open source portal platformCKAN, DKAN, uData, Piveauthere is your own team or a contractor, and you need your own schema and extensions
Research repositoryDataverse, DSpace, InvenioRDMDOIs, versions and citation are needed
GeocatalogGeoNetwork, GeoNode; the cloud-based ArcGIS Huba catalog of layers and services
Indicator platformPxWeb, .Stat Suite, OpenSDGofficial statistics and indicators
Microdata catalogNADAsurveys with different access levels
Cloud serviceHuwise (OpenDataSoft), Socrata, Figshareno operations of your own, a subscription fee instead
A site on a CMSWordPress, Drupalthe catalog is a section of an existing site, and the CMS can serve descriptions to machines
Protocol serverTHREDDS, ERDDAP, a STAC server, SPARQLprograms read the data; a showcase site is secondary
Map serverGeoServer, MapServer, QGIS Serverserves layers; is not a catalog by itself
Domain systemGBIF IPT and similar networksdata of one scientific discipline
Custom builda site written for one organisationno platform covers a mandatory feature

A map server often sits next to a geocatalog, not instead of it. GeoServer serves the map, GeoNetwork describes the layers so they can be found. A protocol server likewise sits next to a catalog: THREDDS and ERDDAP serve arrays and tables to programs, while the page for people is kept by another site.

Four questions for a class​

Brands are compared after the class has answered four questions. The answers by brand are in the profiles and in the chapter on build models.

QuestionOpen source platformCloud serviceStatic site or GitCustom build
Who updatesyour own team or a contractorthe providerwhoever edits the filesyour own team, entirely
Can a feature be addedyes, with an extension or customisationonly what is in the subscriptionby editing the template; a search API does not appear that wayyes, at the cost of maintenance
What you take with you when leavingyour files and database, if backups were madewhat the provider gives as an exportthe files, which you already havewhatever you planned to export yourself
What the class does not dodoes not run itself while there is no administratordoes not accept your moduledoes not serve a search API or harvest other catalogsdoes not know other people's standards until someone writes them in

A CMS site and a protocol server are not in this table, because they are chosen not instead of a portal but alongside one. A CMS fits when the catalog is a section of an already living site and the engine can serve descriptions to machines. A protocol server fits when programs read the data and pages for people are secondary.

A class mistake is more expensive than a brand mistake. CKAN with a DOI extension does not become a research repository: the ckanext-doi extension has not been tested on CKAN 2.11 and 2.12. Dataverse does not become an open data portal with daily DCAT-AP federation. ArcGIS Hub does not issue DOIs. These boundaries are written in the profiles, and a shortlist respects them.

What live catalogs show​

According to the dataportals-registry export (release 1.27.0 of 15 October 2026):

  • custom-built catalogs are about 16%. Among geoportals they are 4%: ready-made platforms won there, ArcGIS above all. Among indicator catalogs, 44% are custom-built, and this type is the least likely to have an API;
  • the ArcGIS ecosystem is about a third of geoportals;
  • a municipality often does not choose its platform itself. Russia's Gosweb is a state platform: a city is left to publish where the country already collects data. Poland's e-mapa is a commercial product from Geo-System that each gmina buys, but the vendor serves more than half the gminas in the country, and the choice is in effect made by the market.

A change of owner of a cloud platform or the end of a product hits hundreds of catalogs at once. This happened to microdata catalogs with Nesstar: in 2015, with version 4.0, the product was declared obsolete, by 2022 it was finally withdrawn, and archives moved their collections to other platforms; for example, Canada's ODESI chose Borealis, built on Dataverse, for its move. Even a rename of the vendor without a change of product, as when OpenDataSoft became Huwise in 2025, is a reason to reread the contract. That is why the "cloud service" class in the comparison table always comes with the question: how to take the data out if the subscription ends. This is covered in the chapter on build models.

How to choose a class, not a brand​

  1. If there is little data and it is updated rarely: someone else's catalog or a static site, not a platform.
  2. If there is no team of your own: a cloud service or publishing in an existing catalog.
  3. If DOIs and citation are needed: a research repository, not an open data portal with customisations.
  4. If the main product is map layers: a geocatalog. A map server is added to it, not installed instead of the catalog.
  5. If the main product is indicators with dimensions: an indicator platform, not CKAN with a thousand tiny datasets.
  6. If there is a team and mandatory features that the cloud does not have: an open source platform and a list of extensions.
  7. A custom build only when points 1–6 do not cover a mandatory feature. The test questions are in the same chapter on build models.

Then specific platforms are compared using the profiles and the matrix in the chapter "From Features to a Platform". A class that has not answered the question "who will be on duty two years from now" drops off the list before its features are counted.

Sources​