Closed danaivach closed 1 month ago
Our implementation is based on the premise that a target node doesn't actually have to exist for it to violate a shape. In your case you are saying that <http://example.org/component>
has to have at least one <https://saref.etsi.org/core/hasState>
path when using sh:minCount 1
.
I'll check the specification and test cases to see if this is the correct interpretation or not.
The spec isn't exactly very clear: https://www.w3.org/TR/shacl/#targetNode
But there is a test case that is validated against the reference SHACL implementation:
There is also a test from the W3C SHACL test suite that tests for something similar: https://github.com/eclipse-rdf4j/rdf4j/blob/main/core/sail/shacl/src/test/resources/w3c/core/node/datatype-002.ttl
An issue with that test though is that it doesn't seem to differentiate between what is data and what are shapes, so the nodes are definitely present in the data graph.
Thank you. I had misinterpreted the role of the SHACL rules upon committing them, assuming that the rules will not be violated if the target node does not exist.
The ShaclSailValidationException
is indeed not raised if the conforming node is added in the graph prior to the addition of the SHACL rules.
Current Behavior
RDF4J
SailRepositoryConnection
throws aShaclSailValidationException
inconnection.commit()
when adding SHACL rules withsh:targetNode
combined withsh:minCount
>0 or withsh:hasValue
.Expected Behavior
I'm flagging it as a bug because I would expect that
sh:targetNode
is supported based on https://github.com/eclipse-rdf4j/rdf4j/issues/1362 and https://github.com/eclipse-rdf4j/rdf4j/issues/1574.Steps To Reproduce
Code sample:
Exception:
Version
5.0.2
Are you interested in contributing a solution yourself?
None
Anything else?
No response