behaviour of SHACL Core implementation on shapes graphs with ill-formed SHACL-SPARQL constructs

[pfps]

Is the behaviour of SHACL Core implementations undefined if the only invalid part of a shapes graph is a SHACL-SPARQL construct? For example, is the behaviour of a SHACL Core implemenatation defined on ex:s1 a sh:NodeShape ; sh:targetNode ex:i ; sh:class ex:C . ex:s2 a sh:NodeShape ; sh:targetNode ex:i ; sh:sparql [ ] .

[HolgerKnublauch]

Pure SHACL core implementations ignore SHACL-SPARQL syntax rules and see no special meaning in sh:sparql.

[pfps]

Is this a requirement for SHACL Core processors? Where is this stated?

[HolgerKnublauch]

It is stated because the syntax rules of SHACL-SPARQL are in Part 2 of the document, while SHACL Core is in Part 1.

[pfps]

I don't see anything in the document indicating that SHACL Core processors MUST ignore SHACL-SPARQL constructs - neither wording nor organization.

[HolgerKnublauch]

I disagree with your assessment, see my previous comment.

[irenetq]

The working group has reviewed this issue at the meeting on April 24th and decided that the text in the spec makes it clear that SHACL-SPARQL constructs carry no meaning for the processors that only support SHACL Core.

In other words, to the SHACL Core-only processor there is not difference between

{my:Shape sh:sparql "a"}

or

{my:Shape sh:sparql [ sh:message "Values are literals with German language tag." ; sh:prefixes ex: ; sh:select """ SELECT $this ?value WHERE { $this $PATH ?value . FILTER (!isLiteral(?value) || !langMatches(lang(?value), "de")) } """ ; ]} .
or

{my:Shape my:property [ sh:message "Values are literals with German language tag." ; sh:prefixes ex: ; sh:select """ SELECT $this ?value WHERE { $this $PATH ?value . FILTER (!isLiteral(?value) || !langMatches(lang(?value), "de")) } """ ; ] }.

SHACL Core only processors treat triples with sh:sparql predicate exactly the same way as triples with some arbitrary non SHACL predicate. Simply as RDF statements with no special semantics understood by the processor.

[irenetq]

I think this issue is redundant given issue #63. Since response to issue 63 says that triples with sh:sparql predicate carry no special meaning to SHACL Core-only processors, then the question about the query being ill formed is a mute point.

[pfps]

I have responded in issue 63.

[HolgerKnublauch]

This has been clarified and handled by #63.

[irenetq]

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

[irenetq]

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