problematic cases for pre-binding

[pfps]

The definition of pre-binding in https://www.w3.org/TR/2017/CR-shacl-20170411/ produces some problematic situations.

For example, a BIND of a pre-bound variable, which is allowed in the SHACL definition of pre-bnding, ends up being problematic because it will evaluate an Extend operation where the name being bound already has a binding.

So what is the result of ex:s1 a sh:NodeShape ; sh:targetNode ex:i ; sh:sparql [ sh:select "SELECT $this WHERE { BIND ( 5 AS $this ) }" ] . against an empty data graph?

[HolgerKnublauch]

This case is (now) ill-formed, see my other recent comment and https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Apr/0037.html

[pfps]

So there is now a new definition of pre-binding. I'll take a close look at it when the working group approves the changes.

[HolgerKnublauch]

I don't expect further changes in the upcoming meeting, and we had already voted on this type of change in the recent meeting. The sooner you could provide us your feedback, the better. Thanks.

[HolgerKnublauch]

In today's meeting, the WG has formally approved these changes.

[pfps]

OK, I'll take yet another look at prebinding at my first opportunity.

[pfps]

The recent changes to pre-binding are problematic for a number of reasons: they introduce a new significant source of interoperability problems; they exclude many useful non-problematic queries, including a query that is used as an example in the SHACL document; and they do not exclude all problematic cases. If these exclusions can be extended to exclude all problematic cases the result will still be unsuitable because of the large number of useful queries that are excluded and the new signficant source of interoperability problems.

The following problematic SPARQL query SELECT DISTINCT $this WHERE { SELECT $this ?class WHERE { VALUES ?class { ex:C ex:D } } BIND ( $this AS ?that ) ?that a ?class . } is still allowed.

[pfps]

Of course I messed up the SPARQL syntax. Here is a fixed version:

SELECT DISTINCT $this WHERE {
  { SELECT $this ?class WHERE { VALUES ?class { ex:C ex:D } } }
  BIND ( $this AS ?that )
  ?that a ?class . }

[irenetq]

A "useful query" is a very broad term that is open to judgement. There is no limit to what may be useful to someone in some situation. Lack of support for some features someone may find useful does not, however, mean that a language without these features is not useful.

For example, SPARQL 1.0 was already very useful even if it was missing a variety of features different users wanted. As a case in point, SPARQL 1.0 didn't include VALUES keyword. SPARQL 1.1 added a number of features. One could think of additional features that could also be added and be useful to some people, but this hasn't happened yet. It may or may not happen in the future

Similarly, if the WG can not resolve all the pre-binding issues within its allotted timeframe, a logical solution is to support in the SHACL 1.0 release a subset of the language that doesn't have unresolved pre-binding issues. This may mean not supporting VALUES keyword at all or further limiting its support. Future efforts can add features and extend support. This is a normal evolution process.

The result is still an order of magnitude more useful than just SHACL CORE because compared to even a small subset of SPARQL, it severely limits potential use cases.

[pfps]

[This is in response to a comment in another issue, but my response belongs in this issue.]

I have reported the problems with the current definition of pre-binding in SHACL that I know about. These are mostly just the problems known with Proposal B for EXISTS in the SPARQL EXISTS CG, as this proposal forms the basis for the current definition of pre-binding in SHACL.

I do not know whether there are more problems with the current definition of pre-binding as I have not had time to do a complete examination of pre-binding, as opposed to EXISTS. I had planned to get this done by now but there have been many other things related to SHACL that have come up. As there is a currently known problem with pre-binding I'm prioritizing other things over looking more closely at pre-binding, such as how to get the SHACL test suite into an acceptable state.

[HolgerKnublauch]

With VALUES being ill-formed, is there anything else missing here, Peter?

[irenetq]

We will consider the issue addressed unless we hear back from the submitter within 5 days of the last WG response comment.

[pfps]

I have pointed out multiple problems with pre-binding. At this point it is again up to the working group to produce a clean, reviewed, approved version of pre-binding.

[HolgerKnublauch]

We made further changes today, see https://github.com/w3c/data-shapes/commit/c97ea5efd423464cc4d659a4c86b248001f746aa

[irenetq]

This is a subject of a formal objection, so I think we can simply tag this one as "Commenter is Not Satisfied"

[irenetq]

Adding a link to the wiki page for the formal objection https://www.w3.org/2014/data-shapes/wiki/PRFO4