Re: graph containing comprehensive set of ill-formed shapes

On 04/23/2017 03:17 PM, Irene Polikoff wrote:
> Peter,
> 
> Please see answers below
> 
>> On Apr 23, 2017, at 12:33 PM, Peter F. Patel-Schneider
>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>
>>
>> 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 <mailto: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.
> 
> Yes, SHACL-SHACL only appeared at CR. We are very interested in hearing about
> any bugs in it.
> 
> However, as I said in the previous e-mail, by its nature SHACL-SHACL can not
> detect all issues. The limitations of SHACL-SHACL are well understood and
> there is no need to report that it can’t detect a certain issue e.g., the fact
> that the value of sh:pattern is not a valid regular expressions. That is,
> unless you can propose an additional shape for SHACL-SHACL that could detect
> an issue that is currently undetected.
> 
> Note that SHACL-SHACL implements constraints that need to be checked for every
> shapes graph - whether it is was designed to be used with a SHACL Core
> processor or with a SHACL-SPARQL processor. 

This does not align with wording in the SHACL document:
"The following shapes graph is intended to enforce many of the syntactic
constraints related to SHACL Core in this specification."
It turns out that SHACL-SHACL does check at least one thing that is not in
SHACL Core - it makes a node with a value for sh:shacl a shape.

> It is possible to create a
> separate extension to be used for the shapes graphs that are designed to use
> only with SHACL Core processors. This extension could add a check to, for
> example, detect the presence of sh:sparql values.

>>>> 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 is nothing new in the design, so I am not sure what you are reporting.
> SHACL-SPARQL has always been defined as an extension.

The problem with the design is that SHACL Core and SHACL-SPARQL processors can
silently report different violations.

>>>> 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 .
> 
> If you are reporting that handling recursive shapes is left to implementations
> and, thus, different SHACL Core processors can produce different results, this
> is certainly not new. It has been already discussed at length and you
> participated in the discussions.
> 
> The working group thinks that there is an opportunity to specify a subset of
> recursive shapes for which there could be a defined behavior. This has been
> identified as a topic for the future community or working group to take on.
> 
> If you have additional potential topics for future work, you can send them and
> we will record them on this
> page https://www.w3.org/2014/data-shapes/wiki/Postponed. If you do so, please
> identify them in the heading of your e-mail - e.g., “Proposed addition to
> postponed features:<…>"
>>
>>>> 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.
> 
> If you are referring to the syntax rules that prohibited certain constraint
> components for the node shapes, this is not new. You have already filed a
> formal objection regarding it, which was overruled.

There were new syntax rules added at CR time, which I had not responded to.

> The WG understands that you have a strong opinion on this matter and disagree
> with some of the decisions made. Nevertheless, these decisions have been made
> and we must move on. 
> 
> The WG has new items to address and complete within the deadlines. We
> appreciate your interest in SHACL and your contributions, but returning to
> topics that have been already discussed and decided is not helpful. It puts an
> unnecessary burden on the WG to write a response to you simply to say that it
> is not a new topic. This takes away from the bandwidth we have to work on the
> new or outstanding issues. Please support us in staying focused and bring up
> only new issues.

Is the working group then not going to examine the newly reported or new
interoperability problems?

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 <mailto: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>
>>>>>>> <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>
>>>>>>> <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>
>>>>>>> <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>
>>>>>>> <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>
>>>>>>> <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 22:44:35 UTC