Re: Formal objection on syntax checking in SHACL

The summary of this objection in
https://www.w3.org/2014/data-shapes/wiki/FO-3:No_requirement_to_reject_graphs_with_invalid_shapes

misses both the core problem and its malign effects.

The core problem, laid out in the first sentence of the objection, is that
there is no requirement that "all SHACL implementations check for correct
SHACL syntax."  This does not mean that SHACL implementations reject shapes
graphs that contain ill-formed shapes nor does it mean that SHACL
implementations reject ill-formed shapes graphs.  It just means that SHACL
implementations check for correct SHACL syntax (and provide acceess to the
results of that check).  As long as a SHACL implementation lets its users
know whether a shapes graph is ill-formed or not it does not need to reject
ill-formed shapes graphs.  (It would be better if implementations were
required to have an interface that does reject ill-formed shapes graphs.)

The malign effects are that if a SHACL implementation does not provide a way
to determine whether a shapes graph is ill-formed or not then
"interoperability will be severely compromised".  Such SHACL implementations
do not provide information to users on "whether their shapes graphs,
*whether they conform to SHACL syntactic requirements or not* [emphasis
added], can be interoperably processed by other SHACL implementations."  The
bigger part of this problem is not behaviour of SHACL implementations on
ill-formed shapes graphs but their behaviour on shapes graphs that are not
ill-formed.

Peter F. Patel-Schneider
Nuance Communications


On 02/22/2017 08:02 PM, Peter F. Patel-Schneider wrote:
> This is a formal objection to the decision of the RDF Data Shapes working
> group to close ISSUE-233 without requiring that all SHACL implementations
> check for correct SHACL syntax.
> 
> 
> SHACL implementations need to provide an interface that signals whether the
> shapes graph argument to validation conforms to the syntactic requirements
> of SHACL Core, for SHACL Core implementations, or SHACL-SPARQL, for
> SHACL-SPARQL implementations.
> 
> For example, it is currently possible for SHACL implementations to implement
> the following shape as requiring that all SHACL instances of ex:C1 be any of
> ex:i1, ex:i2, ex:i3; or as requiring that all SHACL instances of ex:C1 be
> either ex:i1 or ex:i2; or by signalling a syntax error; or indeed by any
> behaviour whatever.
> 
> se:s1 rdf:type sh:NodeShape ;
>   sh:targetClass ex:C1 ;
>   sh:in _:b1 .
> _:b1 rdf:first ex:i1 .
> _:b1 rdf:rest _:b2 .
> _:b2 rdf:first ex:i2 .
> _:b1 rdf:rest _:b3 .
> _:b3 rdf:first ex:i3 .
> _:b3 rdf:rest rdf:nil .
> 
> The first of these permissable behaviours is the same as the required
> behaviour on the following shapes graph
> 
> se:s1 rdf:type sh:NodeShape ;
>   sh:targetClass ex:C1 ;
>   sh:in _:b1 .
> _:b1 rdf:first ex:i1 .
> _:b1 rdf:rest _:b2 .
> _:b2 rdf:first ex:i2 .
> _:b2 rdf:rest _:b3 .
> _:b3 rdf:first ex:i3 .
> _:b3 rdf:rest rdf:nil .
> 
> Users will thus have no tool to determine that their shapes graphs are
> syntactically invalid and thus that their shapes graphs will be processed
> the same in different SHACL implementations.
> 
> 
> Therefore if there is not a requirement for complete syntax checking
> interoperability will be severely compromised.  Users of SHACL
> implementations that do not signal whether the shapes graph conforms to the
> syntactic requirements of SHACL Core or SHACL-SPARQL will have no tool for
> determining whether their shapes graphs, whether they conform to SHACL
> syntactic requirements or not, can be interoperably processed by other SHACL
> implementations.
> 
> Optional signalling whether the shapes conforms to SHACL syntactic
> requirements, as in the resolution of ISSUE-233, is in no way a replacement
> for the requirement that all SHACL implementations check for correct SHACL
> syntax.  Users need to be able to know whether their shapes graph conforms
> to SHACL syntactic requirements or not.
> 
> 
> Implementing a complete check for SHACL Core is quite easy.  SHACL Core
> implementations will of necessity have to check most of the syntactic
> requirements of SHACL Core anyway.  For example, an implementation
> will have to check whether a property path refers to itself, or will go into
> an infinite loop.
> 
> The major place where implementations can get away without complete SHACL
> Core syntax checking is SHACL lists, as a simple SPARQL query can retrieve
> elements of SHACL lists without doing complete syntax checking for SHACL
> lists.  However, it is quite easy to implement complete syntax checking for
> SHACL lists, for example by the following Python program (that uses rdflib)
> 
> class SHACLSyntaxError(Error) :
>     def __init__(self,message) : self.message = message
> 
> def countValues(g,subject,predicate) :
>     return sum( 1 for _ in g.objects(subject,predicate) )
> 
> def wflist(g,node,elements=[]) :
>     if ( node in elements ) : raise SHACLSyntaxError("Circular list")
>     if ( node == RDF.nil ) :
>         if ( (RDF.nil,RDF.first,None) in graph ) :
>             raise SHACLSyntaxError("rdf:nil has rdf:first")
>         if ( (RDF.nil,RDF.next,None) in graph ) :
>             raise SHACLSyntaxError("rdf:nil has rdf:next")
>         return elements
>     if ( countValue(g,node,RDF.first) != 1 ) :
>         raise SHACLSyntaxError("List element has wrong number of values for
> rdf:first")
>     if ( countValue(g,node,RDF.rest) != 1 ) :
>         raise SHACLSyntaxError("List element has wrong number of values for
> rdf:rest")
>     return wflist(g,g.value(node,RDF.rest),
>                   elements.append(g.value(node,RDF.first)))
> 
> Implementing a complete syntax check for SHACL-SPARQL is more difficult,
> but the structural requirements are not too hard and the SPARQL syntax
> checks can be done by a SPARQL implementation, which a SHACL-SPARQL needs to
> use anway.
> 
> 
> It is not neceesary that SHACL implementations always check for correct
> SHACL syntax, just that they can be made to do so.  If a SHACL
> implementation finds it too computationally expensive to always check for
> correct SHACL syntax it could provide an "unsafe" interface that does not do
> complete syntax checking.
> 
> 
> Complete syntax checking is neither difficult nor expensive.  Not requiring
> complete syntax checking produces severe interoperability problems.
> Complete syntax checking thus needs to be a requirement on all SHACL
> implementations.
> 
> 
> Peter F. Patel-Schneider
> Nuance Communications
>

Received on Monday, 20 March 2017 17:02:28 UTC