-
Notifications
You must be signed in to change notification settings - Fork 1
Description
section 4.4 step 1b merely says: "A machine-actionable set of validation rules using SHACL shapes". It does not go into detail how to design the shacl shapes.
If we look at different existing DCAT-AP profiles we see different approaches:
-
GeoDCAT-AP creates a 'complete copy' of a profile with all DCAT-AP properties as well as the GeoDCAT-AP properties: https://semiceu.github.io/GeoDCAT-AP/releases/3.0.0/shacl/geodcat-ap-SHACL.ttl
-
HealthDCAT-AP states:
# This file defines SHACL shapes for all classes included in the HealthDCAT-AP PUBLIC data specification.
# It includes all constraints to be satisfied, except for class range constraints, which are defined separately.
# By importing DCAT-AP shapes via owl:imports, this file ensures clear distinction between reused and extended constraints, promoting reusability and easing future upgrades.
-
mobilityDCAT-AP seems to be less explicit, but also only extends DCAT-AP:
https://github.com/mobilityDCAT-AP/mobilityDCAT-AP/blob/gh-pages/drafts/latest/validationFiles/mobilitydcat-ap_shacl_shapes.ttl -
MLDCAT-AP seems again to redefine all DCAT-AP properties: https://github.com/SEMICeu/MLDCAT-AP/blob/main/releases/3.0.0/shacl/mldcat-ap-SHACL.ttl
I realize this probably has a lot to do with tooling and we would like to cater for flexibility in the usage of different tools to craft a profile. However, I think it would be beneficial to provide best practices on how to craft the shacl files for a profile.