Re: graph containing comprehensive set of ill-formed shapes

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

Received on Friday, 21 April 2017 19:47:41 UTC