- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 22 Mar 2017 17:13:42 -0700
- To: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
This is a formal objection to the resolution of the RDF Data Shapes Working Group to advance the maturity level of https://www.w3.org/TR/shacl/ to Candidate Recommendation using the editors' draft at http://w3c.github.io/data-shapes/shacl/ as of 22 March 2017. The reason for this objection is that a fundamental part of SHACL, pre-binding, still has significant known problems. Problems with pre-binding have been known to the working group since at least June of 2015. A summary of some current known problems with pre-binding is given at the end of this message. This objection is being filed at this time because pre-binding has been undergoing recent change and its known problems might have been fixed before requesting advancement for the document. Pre-binding is so central to the SPARQL extension mechanism for SHACL, SHACL-SPARQL, that any significant problem with pre-binding undermines the entirety of SHACL-SPARQL. Pre-binding is also a central part of non-normative descriptions of targets and constraints in SHACL Core so problems with pre-binding also affect the rest of the SHACL document. The working group could have removed pre-binding from the document by splitting it into two pieces, one for SHACL Core and one for SHACL-SPARQL, and only advancing the SHACL Core piece. This possibility had been discussed several times in the working group when there was more than adequate time to perform the split. So, in summary, as of 22 March 2017 pre-binding underpins a large part of SHACL and has several known problems which affect the definition of SHACL. The SHACL document should not advance to candidate recommendation until these problems are fixed or pre-binding is eliminated from the document. Peter F. Patel-Schneider Nuance Communications A summary of some known problems with pre-binding in SHACL: The current definition of pre-binding in SHACL is adapted from a proposed fix for SPARQL EXISTS, first appearing in https://lists.w3.org/Archives/Public/public-sparql-exists/2016Sep/0024.html Its current version is in a proposed editor's draft at https://w3c.github.io/sparql-exists/docs/sparql-exists.html The current adaptation of this proposal for pre-binding is at http://w3c.github.io/data-shapes/shacl/#pre-binding. The proposal for EXISTS itself has several problems, and its adaptation for defining pre-binding has several more. Some of these problems are minor and technical but some of them are quite major or affect a large number of SPARQL queries. The proposed definition of EXISTS depends on a mapping that replaces local variables in a SPARQL algebra expression. This mapping is defined for all SPARQL algebra expressions except for projections. Pre-binding is thus undefined on any query of the form SELECT $this ?value WHERE { ... } and indeed on any SELECT query with no DISTINCT or REDUCED keyword. This problem was reported to the working group in https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Mar/0022.html Another problem affects SPARQL queries using AS. Here the problem involves the Extend operator in the SPARQL algebra. For example, the query SELECT DISTINCT ?this WHERE { BIND ( ex:a AS ?this ) } with the variable this pre-bound results in an undefined use of Extend. This problem was reported to the SPARQL EXISTS Community Group in https://lists.w3.org/Archives/Public/public-sparql-exists/2017Mar/0000.html Another problem is that sometimes the proposal for pre-binding doesn't actually use the bindings. For example, SELECT DISTINCT $this WHERE { VALUES $this { ex:a ex:b ex:c } } with the variable this pre-bound to ex:d returns three solution bindings, one each with the variable this mapped to ex:a, ex:b, and ex:c, ignoring the pre-binding of the variable this. This problem was reported to the SPARQL EXISTS Community Group in https://lists.w3.org/Archives/Public/public-sparql-exists/2017Mar/0001.html Yet another problem with the definition of pre-binding involves an unintuitive result. One might expect that SELECT DISTINCT ?this WHERE { ex:a ex:b ex:c . MINUS { ex:a ex:b ex:c . } } with ?this pre-bound would produce some results because there is no variable shared between the left-hand and right-hand sides of the MINUS. However, pre-binding introduces a binding for the variable this on both sides so no results are produced. This problem was reported to the SPARQL EXISTS Community Group quite some time ago. There is also a potential problem with the definition of pre-binding as it depends on replacing variables in SPARQL queries with arbitrary new (fresh) variables. As variable names do show up in SPARQL results, it should be demonstrated that this replacement does not affect the result of a SPARQL query. I expect that this is indeed the case, but there is no demonstration of it in the SHACL document. This problem was reported to the working group in https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Mar/0009.html The above are mostly problems about how pre-binding is defined. Only when these problems are eliminated can the definition of pre-binding be examined to see whether it does some right thing as far as SHACL is concerned. Indeed, a previous definition of pre-binding in SHACL suffered from this sort of problem.
Received on Thursday, 23 March 2017 00:14:20 UTC