feat: Node Contraint Component

[jeswr]

It would be great if support for the NodeContraintComponents were added to the generate functionality of this tool.

Amongst others, I think it would be beneficial to have a shacl rule with the following construct query.

CONSTRUCT {
  ?property sh:node ?shape .
} WHERE {
  ?property sh:class ?class .
  ?shape sh:targetClass ?class .
} .

My use-case for wanting this triple is in tooling which generates software artefacts from shapes, and makes use of sh:node in generating such artefacts.

[tfrancart]

Ha, I think this difference between sh:node and sh:class is an ambiguous aspect of the SHACL spec.
I started using sh:node a lot (and exclusively), but then backtracked for sh:class.
The point is that, if you both use a sh:targetClass + sh:node, your node shape will be validated multiple times (once for its original targets, and once when being referred to with sh:node). Besides, it creates recursive validation where the original error then create cascading errors, that become practicaly very hard to debug.

So, I'm not a big fan of sh:node. I think it should be restricted to very local constraints (ones for which there is no target defined on the node shape)

[jeswr]

Would opt-in support for this behavior be an option?

The point is that, if you both use a sh:targetClass + sh:node, your node shape will be validated multiple times (once for its original targets, and once when being referred to with sh:node).

It would seem to me that this is something that a good validation engine should be able to avoid with caching.

Besides, it creates recursive validation where the original error then create cascading errors, that become practicaly very hard to debug.

Understood, is there is also a role for improved error logging by validation engines here?