Re: graph containing comprehensive set of ill-formed shapes

On 04/22/2017 04:58 PM, Irene Polikoff wrote:
> 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.

It is new information to me.  SHACL-SHACL only appeared at CR.

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

So I'm reporting a problem with the design.

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

sh:ex a sh:NodeShape ;
  sh:class ex:C ;
  sh:node sh:ex .

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

I am referring to the syntax rules that were introduced between the last two
version of SHACL.

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 Sunday, 23 April 2017 16:34:04 UTC