Issue 189: Add sh:nodeByExpression Constraint Component

[mgberg]

This is one potential approach to resolve #189.

In the original issue, I discuss an idea for a capability that would enable dynamic computation of a set of node shapes to which a particular value node should should conform. I originally suggested a capability that would behave similarly to sh:node except instead of specifying the URI of a node shape that value nodes must also conform to, it specifies a SHACL path; value nodes would also validated against any node shape(s) found at that path from each value node. Refer to #189 for more details, the motivation for this capability, and some example use cases.

After reading the current state of the SHACL 1.2 spec and the expanded use of Node Expressions, I realized it might be possible to add this capability with more expressiveness and less impact than originally proposed by following some of the patterns already appearing in some of the changes from 1.1.

This proposes to generalize sh:node to accept not a node shape, but rather a node expression. This change is similar to how sh:targetNode, sh:deactivated, and sh:defaultValue were generalized to accept node expressions. Additionally, this change would function in a manner quite like sh:expression. This would enable existing implementations to continue to use IRIs of specific node shapes as values of sh:node as prior to 1.2 and also could use more complex Node Expressions (if supported) to dynamically compute sets of node shapes to validate value nodes against using a mechanism similar to sh:expression.

Another minor addition is the requirement that validation results generated by sh:node must include the shape against which conformance checking failed as the value for sh:sourceConstraint. If this was not present, there would be no machine interpretable way to know which dynamically computed shape that caused the validation result. Before this change, the only place the URI of the shape appeared in the example validation results was in the generated value for sh:resultMessage.

The primary concern I currently see with this change is something I didn't think about until reviewing the test cases involving sh:node after putting together the rest of the PR. This change would prevent using a node shape that is a blank node as the value of sh:node, which would be a non-backward compatible change. While it is convenient to use blank nodes node shapes in test cases and examples, I'm not sure how often blank node values of sh:node are actually used in practice. Consequently, I'm not sure if this change would actually be acceptable based on what level of backwards compatibility is expected/required for SHACL 1.2 vs 1.1. Note that in SHACL 1.1 a blank node technically could have been specified as a value of sh:targetNode to be validated and or as a value of sh:defaultValue, neither of which would be possible in 1.2 when values for these properties would be node expressions, so there are some similar breaking changes being made elsewhere. However, I would assume these examples are almost certainly less likely to occur.

• See this document rendered online here

[HolgerKnublauch]

Hi Matt, you have mentioned the show-stopper problem at the end. We cannot switch to node expressions whenever a constraint component previously allowed blank nodes. Perhaps you need to introduce a new constraint component, and leave sh:node unchanged?

[mgberg]

I added this capability as a new constraint component instead as requested, called sh:nodeByExpression. I am not particularly attached to that name, so if anyone comes up with something that sounds better, I can definitely change it.