Re: graph containing comprehensive set of ill-formed shapes

See below
> On Apr 22, 2017, at 7:30 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> There are several new pieces of information that I have brought up recently.
> 
> The purported remedy is incomplete.

This is not new information. SHACL-SHACL is not designed to perform all validity checks. It performs many useful checks and, as a result, makes it possible to detect many, but not all problems. So, it is not a remedy in the sense of fully addressing your original objection. 

> There are interoperability problems on well-formed shapes graphs between SHACL
> Core and SHACL-SPARQL implementations.

Yes, but this is by-design. SHACL-SPARQL implementations do more than SHACL Core implementations

> There are interoperability problems on well-formed shapes graphs between
> different SHACL Core implementations.

Please provide an example

> The new syntax rules increase the probability of creating ill-formed shapes
> graphs.

There have been no new syntax rules since CR. So, I am not sure what you are referring to.
> 
> 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:59:35 UTC