Re: graph containing comprehensive set of ill-formed shapes

There are several new pieces of information that I have brought up recently.

The purported remedy is incomplete.
There are interoperability problems on well-formed shapes graphs between SHACL
Core and SHACL-SPARQL implementations.
There are interoperability problems on well-formed shapes graphs between
different SHACL Core implementations.
The new syntax rules increase the probability of creating ill-formed shapes
graphs.

Peter F. Patel-Schneider
Nuance Communications


On 04/22/2017 04:18 PM, Irene Polikoff wrote:
> Peter,
> 
> Merits aside, there is a strong procedural reason for not adding such requirement. As you know, the working group charter is coming to the end. W3C has a morrotorium on publishing new versions that is starting now and will last for at least a week, may be more. Then, after a document with a new requirement is published, the implementers would need to comply, etc. All of this pushes the timescale.
> 
> Further, you brought up the topic of checking validity of the shapes graph many times in the past, even raising a formal objection prior to the CR. I don’t believe you are providing any new information now.
> 
> Irene
> 
>> On Apr 22, 2017, at 3:58 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>> There is a very simple test to ensure that are not SHACL-SPARQL constructs in
>> a shapes graph.  Just look for sh:sparql values in shapes and SHACL instances
>> of sh:ConstraintComponent.  If there are none then the only effective
>> constructs in the shapes graph are in SHACL Core.
>>
>> Of course there are cases where a SHACL Core processor would otherwise produce
>> the same results as a SHACL-SPARQL processor on a shapes graph, but I don't
>> think that that is what is needed here.
>>
>> As far as future versions of SHACL are concerned I don't see how there is any
>> way to ensure that a SHACL Core processor (or a SHACL-SPARQL processor) for
>> the current version of SHACL does the right thing for future versions of
>> SHACL.  Future versions of SHACL could be written so that changes to
>> SHACL-SPARQL did not require changes to SHACL Core implementations, of course.
>> An easy way to achieve this under my proposal would be to have the future
>> version of SHACL-SPARQL only make changes that are only effective if there are
>> SHACL instances of sh:ConstraintComponent in the shapes graph.
>>
>>
>> My proposal eliminates an important source of silent interoperability failures
>> between SHACL Core and SHACL-SPARQL implementations.   It is much like C
>> compilers complaining if they see C++ syntax, even if that syntax would not
>> change the behaviour of the program.
>>
>> My proposal is extremely simple to implement and its run-time costs are
>> minimal.  I see no reason not to add it to SHACL.
>>
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
>>
>>
>> On 04/21/2017 10:45 PM, Dimitris Kontokostas wrote:
>>> Hi Peter,
>>>
>>> Although I agree that interoperability is important, I don't think it is
>>> realistic to require shacl core processor to be able to detect shacl sparql
>>> constructs without implementing (part of) shacl sparql.
>>>
>>> For example, a constraint component could be defined but never used in a
>>> shapes graph.
>>>
>>> Also, what about deactivated shapes, shapes that are never reached in a
>>> validation or ill formed constructs?
>>>
>>> This easily becomes more complex than identifying two graph patterns
>>>
>>> In addition, it is not future proof. What if we later define shacl sparql+ or
>>> another variant? Will all preexisting shacl core implementations break for not
>>> detecting the new constructs?
>>>
>>> An informative note about interoperability would helpful but conformance
>>> criteria are hard to define imho.
>>>
>>> Best,
>>> Dimitris
>>>
>>> Typed by thumb. Please forgive brevity, errors.
>>>
>>> On Apr 22, 2017 4:09 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com
>>> <mailto:pfpschneider@gmail.com>> wrote:
>>>
>>>    Note that SHACL implementations that ignore SHACL-SPARQL constructs can
>>>    produce more violations than even a SHACL implementation that is in complete
>>>    compliance with all the SHACL constructs.   There are very simple examples
>>>    that demonstrate this, such as
>>>
>>>      ex:s1 a sh:NodeShape ;
>>>       sh:targetNode ex:i ;
>>>       sh:not [ sh:sparql "SELECT $this WHERE { }" ] .
>>>
>>>    peter
>>>
>>>
>>>    On 04/21/2017 04:03 PM, Irene Polikoff wrote:
>>>> Peter,
>>>>
>>>> We will discuss this at the next WG meeting.
>>>>
>>>>
>>>>> On Apr 21, 2017, at 5:30 PM, Peter F. Patel-Schneider
>>>    <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>>
>>>>> 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>
>>>>>>>>
>>>>>>
>>>>
>>>
>

Received on Saturday, 22 April 2017 23:31:21 UTC