- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 6 Jul 2016 09:22:27 -0700
- To: public-sparql-exists@w3.org
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