behaviour of SHACL Core implementations on shapes graphs with SHACL-SPARQL constructs

[pfps]

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.

[HolgerKnublauch]

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]

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]

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]

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. https://github.com/w3c/data-shapes/commit/d966a3511cb119c85aa6abd8ab1d83a9d8fd9fd7

[pfps]

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]

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

https://github.com/w3c/data-shapes/commit/d4da3e48bb52c51d81667c054a65981cdaa1bd0b

[irenetq]

We will consider the issue addressed unless we hear back from the submitter within 5 days of the last WG response comment.

[pfps]

These are new requirements for SHACL Core implementations. Where are the tests to confirm two interoperating implementations?

[pfps]

"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]

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]

It's actually the second message in this thread.

[irenetq]

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:

1. SHACL Core implementations should ignore triples like sh:sparql as meaningless to them

2. 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]

Adding a link to the wiki page for the formal objection https://www.w3.org/2014/data-shapes/wiki/PRFO1