Issue 875: handling disallowing recursive constraints - #978
Conversation
Co-authored-by: Yousouf Taghzouti <48333491+YoucTagh@users.noreply.github.com>
| sh:targetObjectsOf sh:property ; | ||
| sh:targetObjectsOf rdf:first ; | ||
|
|
||
| sh:sparql nrcp:NoRecursiveShapeReferencesConstraint |
| </ul> | ||
| </p> | ||
| <p> | ||
| At minimum, implementations <em>MUST</em> treat the following as shape reference for conformance with |
There was a problem hiding this comment.
Is it valid to say "at minimum" here? Wouldn't we want this to specify a specific closed set of features to check for? If another system wanted to add additional things to check then I assume that would be treated as a different profile.
There was a problem hiding this comment.
Also, I'm not sure what "treat the following as shape reference" means. Perhaps there are some missing words, or a reordering of these, that would make it more sensible?
| </div> | ||
| </aside> | ||
| <h5>Recursive tree example</h5> | ||
| <aside class="example" title="Two shapes that reference each other, creating a cycle."> |
There was a problem hiding this comment.
This example has one shape that references itself
| ex:FolderA a ex:Folder ; ex:containsFolder ex:FolderB . | ||
| ex:FolderB a ex:Folder ; ex:containsFolder ex:FolderA . |
There was a problem hiding this comment.
This example is only recursive because a folder can contain other folders and there exists create a loop in the folder tree. In other words, this particular case could be considered a problem because the data is constructed improperly. Is the intent for this profile to catch this case too, i.e. that it wouldn't be allowable under this profile that a folder could contain other folders?
| <li><code>sh:node</code></li> | ||
| <li><code>sh:property</code> (edge to the referenced property shape)</li> | ||
| <li><code>sh:qualifiedValueShape</code></li> | ||
| <li>the list members of <code>sh:and</code>, <code>sh:or</code>, and <code>sh:xone</code></li> | ||
| <li><code>sh:not</code></li> |
There was a problem hiding this comment.
I'm wondering if this is actually the full set of predicates that would be in scope, or if there are others (e.g. perhaps sh:condition, sh:expression, sh:filterShape if rules are in play?)
|
|
||
| # Capture shapes that appear only as list members or property shapes: | ||
| sh:targetObjectsOf sh:property ; | ||
| sh:targetObjectsOf rdf:first ; |
There was a problem hiding this comment.
Might need to be careful with this, as it would target every list regardless of context. Maybe a SPARQL-based target would be necessary here. And if it was a SPARQL-based target, then you could filter out shapes that are deactivated (if that was desired).
See it at https://raw.githack.com/w3c/data-shapes/ISSUE-875/shacl12-profiling/index.html#disallow-recursive-constraints