Enhancing DCAT support in CKAN (DCAT-AP v3, scheming integration, and more)
A review of the recent developments in CKAN's DCAT support, and how you can get involved
Tech strategy is all about finding ways to make using the technology easier but what's best? What functionalities do you think should be taken off the core and moved into plugins? Do you think it's possible to come up with an agreement on this? What if we highlight some of the most used features via UI while hiding less-used ones further down the user journey in order to make CKAN more focused?
Early on in the interviews, there was a discussion that CKAN should be cleaned up from edge usage cases to only consist of basic functionality that every user would need. If you follow this logic, additional functionality should be added via plugins (add-ons).
It sounded reasonable from the following standpoints:
If we agree that core is core and plugins are the only way to extend CKAN functionality, we face the following questions:
It is time to discuss our strategy around functionality and the best ways to make using CKAN more streamlined, so please share your ideas on this open-ended topic! We can take different directions here - but first, let’s have an engaging discussion! Share your ideas here: Excessive functionality and CKAN. Have your say!
We are currently in the middle of a research initiative led by Alex Gostev that will result in our CKAN 3.0 product strategy. Involving as many stakeholders as possible is essential to achieving this goal and we rely on input from many fronts: contributors, publishers, users, and vendors. Want to get involved? Read on: You’re Invited! Have Your Say on CKAN 3.0!
A review of the recent developments in CKAN's DCAT support, and how you can get involved
CKAN 2.11 introduces Table Designer: form builder and enforced validation for your data