Re: graph containing comprehensive set of ill-formed shapes

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 19:58:40 UTC