Replies: 9 comments 1 reply
-
I strongly back this proposal. Prioritizing support for first-class entities—datasets, dataset series, data services—as per DCAT 3 is crucial for CKAN's relevance. This shift is not just an enhancement; it's essential to meet the evolving needs of users and align with standard metadata practices. It's a deal-breaker for many catalogues, and addressing it shouldn't be delayed. |
Beta Was this translation helpful? Give feedback.
-
FYI, DCAT-US is also being updated to align with DCAT 3. IMHO, this should further lend weight to prioritizing synching our efforts with both initiatives so CKAN will be DCAT 3 ready by the time both the DCAT-AP v3 and DCAT-US v3 specifications are published. |
Beta Was this translation helpful? Give feedback.
-
Has anyone tried implementing dataset, dataset series and data service as separate package types using ckanext-scheming? Are there any features missing for fully implementing series and data services records? |
Beta Was this translation helpful? Give feedback.
-
IMHO, this is a good topic to convene a Working Group/Community of Practice as envisioned for Phase II of the NSF CKAN POSE project (https://civicdataecosystem.org/). And I don't think we need to wait for POSE Phase II to be approved given the importance of the topic. Speaking of which, DCAT-US v3 has an open comment period till Nov 17. This might be a good time to put in your 2 cents and to take a pulse of what data publishers need. Given that the spec aims to "provide a single metadata standard able to support most requirements for documentation of business, technical, statistical, and geospatial data consistently", it will greatly expand CKAN's utility and addressable use cases. cc @thegostev @anuveyatsu @gavram @rgradeck @drw @saylorsd @rossreillypitt @samibaig |
Beta Was this translation helpful? Give feedback.
-
Just to note here as well, we've implemented datasets and data services in our DCAT profile with ckan extensions using scheming, the extension is available here https://github.com/vrk-kpa/ckanext-apis which then is parsed in the profile as data services. For example https://www.avoindata.fi/data/fi/dataset/50bf822d-31d4-450c-917d-c974af92fab6.xml |
Beta Was this translation helpful? Give feedback.
-
Following up on the DCAT 3 discussion during the Tech Team call this morning - here's a wonderful overview of the DCAT 3 Standard by @fellahst. Though it is through the DCAT-US 3 lens, its gives the "Big Picture" and covers the DCAT-AP/GeoDCAT-AP initiatives in Europe as well. |
Beta Was this translation helpful? Give feedback.
-
This sounds related to #7489 where we started discussion based on DCAT-AP v2. This comment from @amercader already indicates some constraints with Based on above discussion and ideas about the approach, I believe it would be good to consider this under CKAN 3.0 Taskforce. cc @thegostev @gavram |
Beta Was this translation helpful? Give feedback.
-
@anuveyatsu thanks for the suggestion, it is a great addition to the scope of CKAN 3.0: #7896 I do agree that it's a high priority. |
Beta Was this translation helpful? Give feedback.
-
Great! DCAT 3.0 + CKAN 3.0 would make for a compelling upgrade and present an opportunity to revisit/modernize architectural choices. Taking a cue from the DCAT-US 3.0 abstract note:
Perhaps, CKAN 3 can introduce first class support for key DCAT 3 novel elements - i.e. versioning, dataset series, inverse properties, geospatial/temporal data, etc. that may require breaking changes? That is, instead of depending on the ckanext-dcat extension, bring these DCAT 3 novel elements into CKAN 3.0 core? So long as we have a CKAN 2.x to 3.0 migration path and "DCAT 3.0-light" is available on CKAN 2.x by building on the existing ckanext-dcat extension... Doing so, IMHO, will give architectural impetus to CKAN 3.0 given DCAT-US 3.0's future-proof ambitions. Again, per the last paragraph of the DCAT-US 3.0 abstract:
Of course, I realize these quotes are from the DCAT-US 3.0 draft spec which is but one profile. But what if by aligning CKAN 3.0 to DCAT 3.0, CKAN 3.0 can load any DCAT 3.0 profile? https://www.w3.org/TR/vocab-dcat-3/#profiles IMHO, DCAT 3.0's alignment with FAIR initiatives also help further widen CKAN's addressable market beyond traditional government data portals - specifically, scientific/research data portals and enterprise data catalogs - possibly, with their own corresponding, industry/domain/organization-specific DCAT 3.0 profiles. Just my 2 cents 😉 |
Beta Was this translation helpful? Give feedback.
-
DCAT 3 (and the European draft DCAT-AP 3) changes the structure of metadata significantly. Instead of dataset → distribution (or package → resource in CKAN terms) we now have datasets, dataset series and data services as first-class citizen entities. We are thus getting closer to the geo-world and ISO metadata. I wonder if we can even model this with the current structures in CKAN.
Data services have already been introduces in DCAT 2. However, it seems to me that they are not yet first-class citizen entities with an own entry in the
package
table. Instead they can just be found as JSON data in thepackage_extra
table entry of a dataset.The
package
table already contains a columntype
that might be used to distinguish between dataset, dataset series and data service. CKAN even uses the termdataset
at this point today. The column is also used to indicate harvest sources (that are stored in thepackage
table, too). I suspect, however, that major modifications to CKAN itself will be necessary to display these different entities.I have also created an issue for the DCAT extension but this place is maybe more appropriate.
Beta Was this translation helpful? Give feedback.
All reactions