SHACL dependence on EXISTS

SHACL, the in-progress result of the W3C Data Shapes Working Group with
Editors' draft at http://w3c.github.io/data-shapes/shacl/, depends on EXISTS
in several ways.

The most prominent is that SHACL has basic graph patterns inside EXISTS that
need to work correctly if a filter variable is mapped to a blank node.  For
example,
  SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
  WHERE {
 $this $predicate ?value .
 FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* $class } .
  }
needs to not map the first element of the inner triple to any node in the
graph if ?value is mapped to a blank node by the outer basic graph pattern.

The most general is that SHACL permits constructs to be written as SPARQL
queries and fragments of SPARQL queries.  This makes any problem in the
SPARQL specification a problem with SHACL.  However, SHACL doesn't here
dictate how EXISTS should work, SHACL just needs EXISTS to work.  It would
be better for SHACL if EXISTS didn't have too many counterintuitive aspects,
of course.

The most important in my view, however, is that SHACL centrally uses
pre-binding, i.e., evaluating SPARQL queries with variables "pre-bound" to
values.  In the above query the variables using $ are all pre-bound.  The
previous definition of pre-binding in SHACL used substitution, which
inherited many of the problems of EXISTS.  The current definition of
pre-binding in SHACL uses evaluation, which has its own problems.  A fixed
definition of EXISTS could be used as a model for the definition of
pre-binding in SHACL.  Here again SHACL doesn't need any particular
definition of EXISTS, just some definition that works and that can be
adapted to work for pre-binding.


Peter F. Patel-Schneider
Nuance Communications

Received on Wednesday, 6 July 2016 16:23:03 UTC