inconsistent requirements for sh:focusNode

[pfps]

There is contradictory information on the value of sh:focus in validation results:

In Section 3.6.2.1 Focus node (sh:focusNode) there is

"Each validation result has exactly one value for the property sh:focusNode that is equal to the focus node that has caused the result. This is the focus node that was validated when the validation result was produced. "

In 5.3.2 Mapping of Solution Bindings to Result Properties there is

"sh:focusNode The binding for the variable this"

These diverge in cases where the binding for the variable this is not the focus node.

[HolgerKnublauch]

All SELECT queries must project ?this, ?this is pre-bound and I don't see how ?this could change its value when it is already pre-bound from the start. What scenario would make this happen?

[pfps]

Pre-binding of a variable does not always result in the variable being bound to that value in query results. For example, SELECT $this WHERE { VALUES $this { 5 } } will produce a query result with $this bound to 5.

[HolgerKnublauch]

See https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Apr/0037.html we have included further syntax rules including those that were already written down in the SPARQL EXISTS document but not yet copied over. This includes the rule that makes it illegal to use pre-bound variables in VALUES clauses.

[pfps]

This new exclusion does not have the desired effect. The limitation on VALUES still allows for cases where $this is unbound.

[HolgerKnublauch]

How can $this become unbound when it has been pre-bound by the surrounding SHACL engine? Do you have a specific example please?

[pfps]

The following query will return a single solution set, with the variable this unbound even if it had been pre-bound.

SELECT $this ?that WHERE { { SELECT $this ?that WHERE { VALUES ?that { "aa" } } } FILTER (true) }

[HolgerKnublauch]

Ok this is the same problem as #61 and from some experiments it seems that there may indeed be a problem. Not having consistent binding of a variable would be counter intuitive to users.

To make progress, we may need to exclude further syntactic constructs. I cannot claim that I have understood what's going on in your example. Is this problem specific to VALUES or can you create a scenario like this without VALUES?

[pfps]

This is actually a different problem, but related.

The final definition of pre-binding might just have some cases where $this is unbound but that don't have any other problems. So there still might be a need to allow for $this being unbound.

I just noticed that rule for sh:sourceConstraintComponent should be fixed up for Section 6 constraints.

[HolgerKnublauch]

I believe allowing $this to become unbound would be unintuitive to users, and yes the definition of how sh:focusNode gets set currently depends on this assumption.

But what does sh:sourceConstraintComponent have to do with this?

[HolgerKnublauch]

VALUES is now generally causing ill-formed shapes. So the discussion here is moot unless you can construct another case where $this becomes unbound.

[irenetq]

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

[pfps]

Has the working group subjected this new change to review and approved the change?

[irenetq]

Yes