Re: graph containing comprehensive set of ill-formed shapes

Peter,

Please see answers below

> On Apr 23, 2017, at 12:33 PM, Peter F. Patel-Schneider <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> 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. 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.
> 
>>> 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 <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.

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.


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