-
Notifications
You must be signed in to change notification settings - Fork 38
feat: Implement sequence processing improvements for SHACL Node Expressions (Issue #484) #526
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
…atMap, findFirst, matchAll)
…cification and examples
… shnex:remove in spec, examples, and vocabulary
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.
Small stuff
<div class="note"> | ||
<p><strong>Important:</strong> Note the distinction between <code>sh:path</code> and <code>shnex:pathValues</code>:</p> | ||
<ul> | ||
<li><code>sh:path</code> is used in <strong>property shapes</strong> to specify which property path should be constrained during validation. It defines what property or path the shape's constraints apply to.</li> |
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.
<li><code>sh:path</code> is used in <strong>property shapes</strong> to specify which property path should be constrained during validation. It defines what property or path the shape's constraints apply to.</li> | |
<li><code>sh:path</code> is used in <strong>property shapes</strong> to specify the property path that will be constrained during validation. It defines the property or path to which the shape's constraints apply.</li> |
<p><strong>Important:</strong> Note the distinction between <code>sh:path</code> and <code>shnex:pathValues</code>:</p> | ||
<ul> | ||
<li><code>sh:path</code> is used in <strong>property shapes</strong> to specify which property path should be constrained during validation. It defines what property or path the shape's constraints apply to.</li> | ||
<li><code>shnex:pathValues</code> is used in <strong>node expressions</strong> to specify which property path should be traversed to generate a sequence of values. It produces the actual values found by following the path.</li> |
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.
<li><code>shnex:pathValues</code> is used in <strong>node expressions</strong> to specify which property path should be traversed to generate a sequence of values. It produces the actual values found by following the path.</li> | |
<li><code>shnex:pathValues</code> is used in <strong>node expressions</strong> to specify the property path that will be traversed to generate a sequence of values. It produces the actual values found by following the path.</li> |
The <a>output nodes</a> of the <a>minus expression</a> are the <a>nodes</a> in <code>N</code> | ||
The <a>output nodes</a> of the <a>remove expression</a> are the <a>nodes</a> in <code>N</code> | ||
except those that are also in <code>M</code>, preserving the order of <code>N</code>. | ||
Nodes must be equal using <a>term equality</a>, i.e. <code>"01"^^xsd:integer</code> is distinct from <code>"1"^^xsd:integer</code>. |
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.
Nodes must be equal using <a>term equality</a>, i.e. <code>"01"^^xsd:integer</code> is distinct from <code>"1"^^xsd:integer</code>. | |
Nodes must be equal using <a>term equality</a>, i.e., <code>"01"^^xsd:integer</code> is distinct from <code>"1"^^xsd:integer</code>. |
This pull request implements comprehensive changes to address Issue #484 regarding sequence processing naming inconsistencies in SHACL Node Expressions. The changes align the vocabulary and documentation with the sequence-based nature of node expression processing while maintaining backward compatibility through deprecation notices.
Problem Statement
SHACL Node Expressions are fundamentally sequence-based but were using set-style operation names, creating confusion:
union
andminus
suggested set semantics despite working on ordered sequencespath
property conflicted conceptually with constraintsh:path
Solution
1. Vocabulary Renaming for Sequence Semantics
Renamed Operations:
shnex:union
→shnex:join
- Emphasizes sequence concatenation with order preservationshnex:minus
→shnex:remove
- Clearer operation name for sequence subtractionshnex:path
→shnex:pathValues
- Distinguishes from constraintsh:path
(needs to align with Rename shnex:path to shnex:pathValues and change its shnex:nodes to shnex:focusNode #514 )Deprecation Strategy:
shacl.ttl
with deprecation notices forsh:union
andsh:minus
2. Advanced Sequence Operations
New Operations Added:
shnex:flatMap
- Applies expression to each input node and flattens resultsshnex:findFirst
- Returns first node conforming to a given shapeshnex:matchAll
- Returns true if all nodes conform to a given shapeFiles Modified
Vocabulary Files
shacl12-vocabularies/shnex.ttl
shacl12-vocabularies/shacl.ttl
sh:union
andsh:minus
Documentation
shacl12-node-expr/index.html
New Advanced Operations:
Closes #484