Feedback wanted: ckanext-actor-registry (beta), reusable publishers and contact points for CKAN metadata

[bjornhagstrom]

We are looking for feedback on ckanext-actor-registry, an extension for centrally managed, reusable publishers and contact points in CKAN metadata. It is now in beta (0.4.1) and installs with pip install ckanext-actor-registry.

A 90-second overview video explains a good deal of it: https://youtu.be/QOKnf9N6dPg

The problem we are exploring is simple: publisher and contact details are often repeated across many datasets, which makes both data entry and later maintenance unnecessarily expensive. The extension stores publishers and contact points once, references them from datasets by stable IDs, and resolves the current registry data for display and DCAT export. CKAN organizations remain a separate ownership and authorization concept.

What it includes:

• publisher and contact point management for logged-in editors, with merging of duplicates and permanent deletion for sysadmins;
• Scheming selectors, inline creation and editing while editing a dataset, record previews, the latest publisher and three recent contact points per user;
• a migration page that turns CKAN's free-text Maintainer and Author fields into shared contact points, grouped by email address, in rounds, without ever changing the original fields, and a cleanup page for deactivated records that are still in use;
• dataset pages that show the publisher and contact points with their details, and a page per publisher and contact point that lists its datasets (paginated, and respecting private datasets);
• a worklist of datasets that are missing a publisher and/or a contact point;
• unique identifiers per identifier scheme, and one shared validation layer for the forms, the inline dialogs and the merge action;
• optional foaf:Agent and vcard:Kind output through ckanext-dcat, including vcard:hasTelephone, validated against the official DCAT-AP 3 SHACL shapes;
• an English interface with Swedish translations, and a simple way to add your own language (one .po file), and a runnable Docker Compose example with a smoke test.

The extension grew out of a Swedish municipal proof of concept, but the registry model is intended to be useful across sectors, countries and organization types. The automated suite runs on CKAN 2.11.1 and later 2.11 releases and on CKAN 2.12 (with ckanext-scheming 3.1.0). It is beta software: there is no formal security review or browser-based test suite yet, and no Action API for registry administration (a deliberate choice; the reasoning is in the repository's docs/BACKLOG.md). Parts of it were developed with AI assistance, which is disclosed in AI_ASSISTANCE.md.

Feedback we would value:

1. Is this extension interesting to you at all? A short "yes, this is a problem we have" or "no, because..." helps a lot.
2. Even better: have you tried it for real, on a test or production catalog? What worked, what didn't, and what was missing?
3. Are you aware of an existing extension that already provides a comparable reusable publisher and contact point registry? (The Ecosystem Catalog entry is here: https://ecosystem.ckan.org/extension/ckanext-actor-registry)
4. Does the separation between CKAN organization, publisher and contact point fit your catalog's model?
5. Which of these matter most for the next release: a search box on the registry's list pages, an Action API, import/export, authorization, or multilingual workflows?
6. Should this, or equivalent functionality, be part of CKAN core?

Repository: https://github.com/bjornhagstrom/ckanext-actor-registry
Latest release: https://github.com/bjornhagstrom/ckanext-actor-registry/releases/tag/v0.4.1

[jqnatividad]

Hi @bjornhagstrom ,

Thanks for sharing this extension. IMHO, it solves a common problem in CKAN.

Two questions:

• is the actor registry searchable?
• is the translation mechanism extensible so other users can easily localize it?

As for similar extension - have you checked the Ecosystem Catalog - ecosystem.ckan.org?

Speaking of which - the Ecosystem Catalog Crawler did find your extension and registered it automatically - https://ecosystem.ckan.org/extension/ckanext-actor-registry.

If there are any mistakes in the entry, please feel free to edit it - the Ecosystem Catalog runs on CKAN after all :)

Thanks!

[bjornhagstrom]

Thanks for the kind words, and for the questions!

Since I first posted this, the extension has moved on: it is now in beta, the README is much better, and there is a 90-second overview video that explains a good deal of it: https://youtu.be/QOKnf9N6dPg. It may answer some of your questions already; the README is here: https://github.com/bjornhagstrom/ckanext-actor-registry

Yes, this has been my biggest problem with using CKAN in production. The maintenance cost, including the cost of bad data, for this is much bigger than most realize.

I think this, or equivalent functionality, should be part of CKAN core. Core stores contact details as free text on every dataset (Author and Maintainer), while DCAT-AP expects the publisher and the contact point to be entities of their own. I'd be glad to see this extension used as a starting point or a prototype for that discussion.

Is it searchable? In the dataset form both pickers are searchable (CKAN's autocomplete, you type to filter). The two list pages (Publishers at /actors and Contact points at /contactpoints) have no search box yet: the records live in the database rather than in Solr, and there is no search action. Each publisher and contact point has its own page listing its datasets. A search box on the list pages is on my backlog. Would that cover what you had in mind, or did you mean search through the API?

Can others localize it? Yes. English is the source language and Swedish ships with it; another language is one .po file, and the extension offers every language that has a compiled catalogue. The steps are in docs/TRANSLATIONS.md.

Ecosystem Catalog: thanks for the pointer! I submitted the extension there at about the same time as you commented :) I used AI to look for similar extensions when I designed this (the older ckanext-contactpoints turned up, for example), but the AI can't read the Ecosystem Catalog (automated requests get a 403), so I may well have missed something there. An MCP server for reading the Ecosystem Catalog would be a great thing to have, so that AI assistants can search it. Maybe worth considering? I'm not sure where to address this tho:/

[a5dur]

Hey @bjornhagstrom thanks for submitting it to the Ecosystem Catalog! I got the request and it’s now listed there, so thanks again.
And yeah an MCP server for the Ecosystem Catalog is definitely worth considering. Being able to have AI assistants search the catalog directly would make it a lot easier to find existing extensions before building something new, which is exactly the situation you ran into. I’ve added it to the backlog.