We however want to use the SHACL shapes, not only for validation, but also for source selection and for declaring what will be in an update of a DCAT-AP Feeds (an LDES).
Therefore, we need to start with a Create, Update Remove nodeshape, that then can link to one of the many standalone entities (see the DCAT-AP Feeds spec for what they are), that in their turn can refer to nodeshapes of the embedded entities.
Some properties will need special attention. E.g.,
both a Dataset and a Distribution are standalone entities. But, do you also need to update the dct:modified on top of the Dataset when a distribution changed? If this is the case, wouldn’t it be more interesting to make this a property in control of the harvester instead of in control of the publisher?
dcat:distribution is on top of a Dataset, which means that when you add a standalone distribution to the catalog, you’d also have to update the dataset itself with an extra triple indicate a link to the distribution. I think it might be a better idea to instead include the dataset → distribution link in the distribution event. The shapes need to represent that.
The task in this ticket is to create a script to automatically process the official SHACL shapes, and include well-defined rules of how the shapes will be translated into the shapes we need for the DCAT-AP Feeds specification.
The script must be pull requested in this repository and executed, so that the shacl shapes are available here, and published on github pages, so the shape can be referenced by the tree:shape property.
pietercolpaert
commented
3 months ago
The DCAT-AP specification has SHACL shapes are available from the specification: https://semiceu.github.io/DCAT-AP/releases/3.0.0/#validation-of-dcat-ap These shapes will validate a full catalog graph for entities to be available.
We however want to use the SHACL shapes, not only for validation, but also for source selection and for declaring what will be in an update of a DCAT-AP Feeds (an LDES).
Therefore, we need to start with a Create, Update Remove nodeshape, that then can link to one of the many standalone entities (see the DCAT-AP Feeds spec for what they are), that in their turn can refer to nodeshapes of the embedded entities.
Some properties will need special attention. E.g.,
dct:modifiedon top of the Dataset when a distribution changed? If this is the case, wouldn’t it be more interesting to make this a property in control of the harvester instead of in control of the publisher?dcat:distributionis on top of a Dataset, which means that when you add a standalone distribution to the catalog, you’d also have to update the dataset itself with an extra triple indicate a link to the distribution. I think it might be a better idea to instead include the dataset → distribution link in the distribution event. The shapes need to represent that.The task in this ticket is to create a script to automatically process the official SHACL shapes, and include well-defined rules of how the shapes will be translated into the shapes we need for the DCAT-AP Feeds specification.
The script must be pull requested in this repository and executed, so that the shacl shapes are available here, and published on github pages, so the shape can be referenced by the
tree:shapeproperty.