-
Notifications
You must be signed in to change notification settings - Fork 30
Issue 189: Add sh:nodeByExpression
Constraint Component
#408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: gh-pages
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
I added this capability as a new constraint component instead as requested, called |
nodeByExpression
Constraint Component
nodeByExpression
Constraint Componentsh:nodeByExpression
Constraint Component
@TallTed I accepted your suggestion, but I didn't modify the formatting of body text throughout the remainder of the document. I assume it would be more appropriate to reformat the entire document as a separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to go.
shacl12-test-suite/tests/core/property/nodeByExpression-001.ttl
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tentatively approving but it would be best to wait with the merge until next week, when it was presented to the meeting for everyone's awareness.
…ng spaces for body text Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
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 howsh:targetNode
,sh:deactivated
, andsh:defaultValue
were generalized to accept node expressions. Additionally, this change would function in a manner quite likesh:expression
. This would enable existing implementations to continue to use IRIs of specific node shapes as values ofsh: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 tosh: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 forsh: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 forsh: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 ofsh: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 ofsh: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 ofsh:targetNode
to be validated and or as a value ofsh: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.