- From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Nov 2021 01:00:36 +0000
- To: public-dxwg-wg@w3.org
The "correct" approach according to the scoping discussions would be to define a profile of DCAT that defines a canonical structural description. RDF-QB is probably the leading candidate for such a description - and the StatDCAT-AP profile is a potential starting point see : https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/statdcat-application-profile-data-portals-europe/release/100 The question is whether there should be a profile heirarchy: 1) DCAT-QB profile of DCAT and QB for any structural case (not just statistical data) 2) StatDCAT being a profile of DCAT-QB 3) StatDCAT-AP being a profile of StatDCAT and DCAT-AP (this would make simple declarative statements about the expected interoperability as well as provide logical extension points for new profiles to suits any similar requirements without re-inventing these patterns.) For each profile SHACL validations, JSON schema, JSON-LD contexts etc to support all these could be implemented in a modular fashion to simplify implementation. (This is just extending what the DCAT-AP community is already doing toward a scalable approach to support machine access and readability of interoperability requirements.) Note that publishing profiles of DCAT is explicitly out of scope of this working group - but there must be a sizeable community who would have an interest in doing that in a coherent way - it would be helpful if the DXWG could pass off these matters to an appropriate forum. -- GitHub Notification of comment by rob-metalinkage Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1418#issuecomment-955834171 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 November 2021 01:00:40 UTC