[data-shapes] Pull Request: Issue 189: Add support for node expressions in sh:node

mgberg has just submitted a new pull request for https://github.com/w3c/data-shapes:

== Issue 189: Add support for node expressions in sh:node ==
<!--
# Pull request instructions
(Note that text between the HTML comments will be recorded in this pull request's source for future editing, but will not render on Github.  Text is suggested with portions needing substitution enclosed in curly braces.  The curly braces also need to be removed when substituting.)

Please use "Closing keywords" for the associated Issue if this PR should close the Issue once merged.
https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

If this PR edits a document, please consider including a "Live render."  The non-comment template text suggests one mechanism.  If including the link line(s), please test-load the link(s) while drafting the PR.
-->

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](https://raw.githack.com/w3c/data-shapes/issue-189/shacl12-core/index.html)

See https://github.com/w3c/data-shapes/pull/408


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 19 June 2025 01:46:05 UTC