Repository navigation
behaviour of SHACL Core implementations on shapes graphs with SHACL-SPARQL constructs #63
Description
The shapes graph that is supposed to check for syntactic validity of shapes
graphs includes checks concerning sh:sparql constraints. Are SHACL Core
implementations supposed to check for the syntactic validity of sh:sparql
and other SHACL-SPARQL constructs? What is the behaviour of SHACL Core
implementations on shapes graphs containing shapes with sh:sparql
constraints or containing definitions of SPARQL-based constraint components?
It would be best if SHACL Core implementations were required to signal an
error when given a shapes graph containing shapes with sh:sparql constraints
or containing definitions of SPARQL-based constraint components. This would
eliminate a source of silent interoperability problems.
Activity
HolgerKnublauch commentedon Apr 20, 2017
Pure SHACL Core implementations simply ignore SHACL-SPARQL - they are triples like any other meaningless triple. On the sh:sparql triple in the shacl-shacl file, there is no harm in keeping it. It only serves to recognize that its subjects are also shapes. The file does not claim to be about pure SHACL Core only.
Given our very short remaining runway, my strong preference is to only make changes to the document if absolutely needed. Changing the policy to signal an error does not look sufficiently critical.
pfps commentedon Apr 20, 2017
I don't see any wording in the document to the effect that SHACL Core implementations are rquired to ignore SHACL-SPARQL constructs.
Interoperability is a core W3C desire. Having SHACL Core implementations ignore SHACL-SPARQL constructs produces silent interoperability failures.
irenetq commentedon Apr 25, 2017
Do OWL profiles in your view also produce silent interoperability failures because there is no requirement for reasoners to warn that they will not generate inferences as a result of certain OWL axioms? The spec simply identifies a subset of inferences that a reasoner that supports a given profile will generate. It has no statements requiring reasoner to warn that they will not act on some axioms because they are outside of the profile they support.
HolgerKnublauch commentedon Apr 27, 2017
Related to this, Peter had last week submitted some test cases that were testing "pure SHACL Core" behavior. However, there is no requirement for SHACL-SPARQL implementations to provide such a "pure SHACL Core" mode, and therefore there would be no way for those implementations to pass these tests. I have now deleted these tests. d966a35
pfps commentedon Apr 29, 2017
In Shapes Constraint Language (SHACL) W3C Candidate Recommendation 11 April
2017 there is:
"All SHACL implementations MUST at least implement SHACL Core."
"SHACL Core processors as processors that support validation with the SHACL
Core Language"
"For SHACL Core this specification uses parts of SPARQL 1.1 in non-normative
alternative definitions of the semantics of constraint components and
targets. While these may help some implementers, SPARQL is not required for
the implementation of the SHACL Core language."
"SHACL-SPARQL is based on SPARQL 1.1 and uses it as a mechanism to declare
constraints and constraint components. Implementations that cover only the
SHACL Core features are not required to implement these mechanisms."
"Access to the shapes graph is not a requirement for supporting the SHACL
Core language."
So it is clear that SHACL Core implementations do not have to implement
SHACL-SPARQL constructs. But it is not at all clear from the SHACL document
that SHACL Core implementations have to be oblivious of SHACL-SPARQL
constructs. There are several behaviours of SHACL Core implementations that
are consistent with the above:
1/ SHACL Core implementations are oblivious of all SHACL-SPARQL constructs.
2/ SHACL Core implementations treat SHACL-SPARQL constructs as having no
semantic meaning but any ill-formed SHACL-SPARQL constructs in a shapes
graph mean that the behaviour of a SHACL Core implementation is undefined on
that shapes graph.
3/ SHACL Core implementations treat shapes graphs with significant
SHACL-SPARQL constructs as ill-formed shapes graphs.
4/ SHACL Core implementations treat shapes graphs with any triples whose
predicate is SHACL-SPARQL property as ill-formed shapes graphs.
There is evidence against behaviour 1/ in the SHACL document. The normative
shapes graph in Appendix C makes subjects of triples with sh:sparql as
predicate into shapes. This then means that SHACL Core behaviour is
undefined on shapes graphs like:
ex:s1 sh:sparql "SELECT $this WHERE { }" ;
sh:deactivated 1 .
ex:s2 a sh:NodeShape ;
sh:targetClass ex:C ;
sh:class ex:D .
Further evidence against behaviour 1/ is that I submitted tests to check out
the behaviour of SHACL Core implementations on shapes graph containing
SHACL-SPARQL constructs. These tests have been removed.
There is evidence for behaviour 2/ in the SHACL document, which states in
Section 3.4.2 "If the shapes graph contains ill-formed nodes, then the
result of the validation process is undefined." So any ill-formed node,
including nodes that are ill-formed because of SHACL-SPARQL constructs,
makes the validation process undefined.
If the working group wants behaviour 1/ it needs to make that behaviour
clear in the SHACL document and remove parts of the document that go against
the behaviour. The working group then also needs to create tests for the
behaviour.
I think that it is best to go with behaviour 3/, with the determination of
significance as the presence in the shapes graph of either a SHACL Core
shape with a value for sh:sparql or a SHACL instance of
sh:ConstraintComponent.
HolgerKnublauch commentedon Apr 29, 2017
The intent has always been option 1) so I have clarified this by adding an informative sentence. I also removed the potentially misleading reference to sh:sparql in the SHACL-SHACL graph. See
d4da3e4
irenetq commentedon May 3, 2017
We will consider the issue addressed unless we hear back from the submitter within 5 days of the last WG response comment.
pfps commentedon May 3, 2017
These are new requirements for SHACL Core implementations. Where are the tests to confirm two interoperating implementations?
pfps commentedon May 3, 2017
"Removed accidental use of sh:sparql in SHACL-for-SHACL graph, clarified that SHACL Core processors ignore SHACL-SPARQL constructs (see Issue #63)."
This is not correct. There has already been discussion on the appearance of sh:sparql in the shapes graph, at which time the response was not that the inclusion was accidental but that indeed it did make some nodes be shapes that would not be so otherwise.
irenetq commentedon May 3, 2017
I think you may be referring to me saying that shacl-shacl was not exclusively for SHACL Core processors and, thus, included some checks for shapes outside of SHACL Core. Is this correct? If not, please provide a link to the discussion.
pfps commentedon May 3, 2017
It's actually the second message in this thread.
irenetq commentedon May 3, 2017
I take it you mean the following:
"Pure SHACL Core implementations simply ignore SHACL-SPARQL - they are triples like any other meaningless triple. On the sh:sparql triple in the shacl-shacl file, there is no harm in keeping it. It only serves to recognize that its subjects are also shapes. The file does not claim to be about pure SHACL Core only."
In this case, what this says is consistent with all the subsequent messages:
SHACL Core implementations should ignore triples like sh:sparql as meaningless to them
SHACL-SHACL file included some checking for such triples because it was expected to be used by the SHACL Core processors AND SHACL SPARQL processors. The WG has since discussed that it may be slightly better to separate checks that are for SHACL Core only - although there doesn't seem to be any harm in keeping all the checks together, except, perhaps, you reading into this some completely unintended meaning.
irenetq commentedon May 10, 2017
Adding a link to the wiki page for the formal objection https://www.w3.org/2014/data-shapes/wiki/PRFO1