Re: SHACL-SPARQL a superset of CORE?

The intent has been that SHACL Core is a subset of SHACL-SPARQL. In 
theory it would also be possible to define a SHACL-SPARQL that only has 
the extension mechanism and the Core is just one instance of it, but the 
WG argued that for the sake of interoperability, each implementation 
should include Core.

The situation with regards to Peter's other comments is even more 
complicated by the other extensions such as the SHACL-SPARQL Advanced 
Features or JavaScript extensions. For example, should shapes graphs 
that contain sh:target also be rejected? This is a slippery slope and I 
don't think we should change the current policy in any way. If people 
want to ensure certain dialects are present, they can already (easily) 
do this themselves by checking the shapes graph before it gets sent to 
the SHACL validation engine. This is nothing that the spec needs to 
enforce - if we added such requirements we may badly shoot ourselves in 
the foot if the other extensions become standards too.

Holger


On 22/04/2017 9:11, Irene Polikoff wrote:
> I was thinking that SHACL-SPARQL processors have to support SHACL 
> Core. The spec implies this by saying that SHACL-SPARQL is an 
> extension of Core, but it may not be sufficiently clear. I do remember 
> us discussing this as well.
>
> This document defines the *SHACL Core* language, also referred to as 
> just *SHACL*, as described in Part A, and the *SHACL-SPARQL* language 
> that extends SHACL Core with constructs described in Part B. This 
> specification describes conformance criteria for:
>
>   * *SHACL Core processors* as processors that support validation with
>     the SHACL Core Language
>   * *SHACL-SPARQL processors* as processors that support validation
>     with the SHACL-SPARQL Language
>
> What do other members recall?
>
> As per below, Peter seems to think that:
>
>> some violations will be reported only by SHACL Core implementations 
>> and other
>> violations will be reported only by SHACL-SPARQL implementations. 
>
>
>
>> Begin forwarded message:
>>
>> *From: *"Peter F. Patel-Schneider" <pfpschneider@gmail.com 
>> <mailto:pfpschneider@gmail.com>>
>> *Subject: **Re: graph containing comprehensive set of ill-formed shapes*
>> *Date: *April 21, 2017 at 5:30:27 PM EDT
>> *To: *Irene Polikoff <irene@topquadrant.com 
>> <mailto:irene@topquadrant.com>>
>> *Cc: *public-rdf-shapes@w3.org <mailto:public-rdf-shapes@w3.org>
>>
>> The situation with respect to RDFS/OWL is quite different from that 
>> for SHACL.
>> For starters, RDFS and OWL are two different recommendations, so 
>> there is some
>> expectation that there might be differences between them.  On the 
>> other hand
>> SHACL is one recommendation so there should be an expectation of
>> interoperability between different SHACL implementations, even 
>> between SHACL
>> Core and SHACL-SPARQL.
>>
>> Further, there is a useful interoperability between RDFS and OWL - RDFS
>> entailment is sound with respect to OWL entailment (subject to some 
>> annoying
>> caveats).  The same can't be said for SHACL Core versus SHACL-SPARQL  In
>> general the violations reported by SHACL Core implementations will be
>> different from those reported by SHACL-SPARQL implementations - some
>> violations will be reported only by SHACL Core implementations and other
>> violations will be reported only by SHACL-SPARQL implementations.  These
>> differences may only arise long after deployment.
>>
>> Fortunately there is a simple change that alleviates much of this
>> interoperability problem.  Just require that SHACL implementations at 
>> least
>> have a mode where they signal when they see constructs that they do not
>> handle.  This is already a requirement for sh:entailment so it is not 
>> as if
>> requirements for signalling unhandled constructs is alien to SHACL. 
>>  With this
>> simple change users can ensure that they will be quickly notified if 
>> there is
>> a chance of interoperability failures.
>>
>> A sound method for detecting the potential use of SHACL-SPARQL 
>> construct in
>> shapes is very simple - it is not necessary to process SPARQL-based 
>> constraint
>> components to find their parameters.  All that is needed is to check 
>> for the
>> absence of sh:sparql constructs in shapes and the absence of SHACL 
>> instances
>> of sh:ConstraintComponent in the shapes graph.  This easy method will 
>> produce
>> a signal in cases where a SHACL-based constraint component is present but
>> unused - certainly not a significant problem and probably not a 
>> problem at all.
>>
>> So there is a very easy method to make SHACL Core and SHACL-SPARQL
>> implementations much more interoperable.  Given that one of the 
>> tenets of W3C
>> recommendations is interoperability this method needs to be required 
>> for SHACL
>> implementations.
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
>>
>>
>> On 04/21/2017 12:47 PM, Irene Polikoff wrote:
>>> I don’t think I follow.
>>>
>>> Two SHACL Core processors will not produce different results. They 
>>> will both only understand SHACL Core and produce results for the 
>>> shapes “inside” SHACL Core.
>>>
>>> SHACL SPARQL constructs are valid RDF, but SHACL Core processors do 
>>> not understand or interpret their semantics.
>>>
>>> Similarly, to how an RDFS inference engine will ignore OWL 
>>> restrictions - they don’t mean anything special to it. And an OWL 
>>> inferencing engine that only supports one profile (let’s say OWL RL) 
>>> will not be signaling that there are some axioms which meaning it 
>>> didn’t interpret.
>>>
>>>> On Apr 21, 2017, at 3:03 PM, Peter F. Patel-Schneider 
>>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>
>>>> It is important for interoperability that SHACL Core 
>>>> implementations are
>>>> required to *not* silently produce different results on valid 
>>>> shapes graphs.
>>>> Instead they must be required to signal that they have been given a 
>>>> shapes
>>>> graph that they do not completely handle.
>>>>
>>>> peter
>>>>
>>>>
>>>> On 04/21/2017 12:01 PM, Irene Polikoff wrote:
>>>>> But, of course, SHACL Core and SHACL-SPARQL implementations will 
>>>>> produce different results. This is by design.
>>>>>
>>>>> SHACL Core processors do not support SHACL-SPARQL. By definition, 
>>>>> a SHACL Core and a SHACL SPARQL processors are only interoperable 
>>>>> for a subset of SHACL which is SHACL Core and sh:sparql is not in 
>>>>> SHACL Core.
>>>>>
>>>>>> On Apr 21, 2017, at 2:43 PM, Peter F. Patel-Schneider 
>>>>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>>>
>>>>>> A SHACL implementation that silently ignores sh:sparql constructs 
>>>>>> produces an
>>>>>> interoperability nightmare.
>>>>>>
>>>>>> For example, such an implementation will produce no violations 
>>>>>> for the shape
>>>>>> ex:sparql a sh:NodeShape ;
>>>>>>  sh:targetNode ex:i ;
>>>>>>  sh:sparql "SELECT ?this WHERE { }" .
>>>>>> A SHACL-SPARQL implementation will instead produce a violation.
>>>>>>
>>>>>> peter
>>>>>>
>>>>>>
>>>>>> On 04/21/2017 03:39 AM, Irene Polikoff wrote:
>>>>>>> Peter,
>>>>>>>
>>>>>>> If your implementation is SHACL Core only, how could 
>>>>>>> SHACL-SPARQL constructs affect it? It would seem to me that the 
>>>>>>> values in the sh:spraql triples would be no different to it than 
>>>>>>> values in the ex:foo (or any user defined predicate) triples.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On Apr 21, 2017, at 12:45 AM, Peter F. Patel-Schneider 
>>>>>>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> My alt-SHACL implementation does complete syntax checking, 
>>>>>>>> signalling whenever
>>>>>>>> in encounters a shape or path or list that is not correctly 
>>>>>>>> formed.  My
>>>>>>>> implementation has a strict mode that signals whenever the 
>>>>>>>> putative shapes
>>>>>>>> graph contains anything that violates any of the SHACL Core 
>>>>>>>> syntax rules or
>>>>>>>> contains a recursive shape or contains SHACL-SPARQL constructs 
>>>>>>>> that could
>>>>>>>> affect validation.  To test this checking I had put together an 
>>>>>>>> RDF graph
>>>>>>>> containing a comprehensive set of constructs that need to be 
>>>>>>>> checked.
>>>>>>>>
>>>>>>>> I just updated this graph, and the associated checking code, to 
>>>>>>>> incorporate
>>>>>>>> the numerous additional syntax rules that were added when the 
>>>>>>>> SHACL document
>>>>>>>> became a candidate recommendation.   I include the graph here. 
>>>>>>>>  It can be
>>>>>>>> turned into a comprehensive set of syntax test cases for SHACL 
>>>>>>>> Core by just
>>>>>>>> separating it into small graphs each containing one of the test 
>>>>>>>> shapes.
>>>>>>>>
>>>>>>>> The amount of code required to do complete syntax checking was 
>>>>>>>> quite modest.
>>>>>>>> Running my implementation over the graph was helpful in finding 
>>>>>>>> bugs such as
>>>>>>>> incorrect recursion checks in the path code.  I strongly 
>>>>>>>> recommend that every
>>>>>>>> SHACL implementation be run on every shape in this graph.
>>>>>>>>
>>>>>>>> Peter F. Patel-Schneider
>>>>>>>> Nuance Communications
>>>>>>>> <syntax.ttl>
>>>>>
>>>
>