[data-shapes] BIND assignment expression errors (#753)

afs has just created a new issue for https://github.com/w3c/data-shapes:

== BIND assignment expression errors ==
`BIND(expr AS ?var)` can fail to set the variable. This happen is evaluating `expr` results in an error.

Example:

Data:
```sparql
PREFIX : <http://example/>
:x2 :data 2 .
:x0 :data 0 .
```

RuleSet:
```sparql
PREFIX : <http://example/>
RULE { ?x :in ?o ;
          :out ?z .
} WHERE {
    ?x :data ?o .
    BIND( 1/?o AS ?z )
}
```

Match `:x2 :data 2` behaves correctly. `?z` is bound to `0.5` (`xsd:decimal`).

Match `:x0 :data 0` is an evaluation error at `BIND`.
In SPARQL, `?z` is left unbound, and execution continues with the current solution mapping.

Possible choices for SHACL Rules:

1. Skip the inclusion of all the triples from the template when ?z is unbound. This can be define as either
    1a.  Treat `BIND error` as a "no match". Do not output a solution mapping for this match.
    1b. At template instantiation, skip all triples in one application of the head if any one of them fails
    Result:
```sparql
PREFIX : <http://example/>
:x2     :in     2 .
:x2     :out    0.5 .
```

2. Skip only triples which `:x0 :in 0` would be inferred but not `:x0 :out ?`.
    Result:
```sparql
PREFIX : <http://example/>
:x0     :in     0 .
:x2     :in     2 .
:x2     :out    0.5 .
```

By the current well-formedness conditions, `?z` can not be bound later. (Use `IF` or `COALESCE` if you want to try one thing then another.)

Of these, I prefer 1, done as 1a - handle in the pattern matching. It is similar to the fact that `FILTER(1/?o != 0 )` would exclude the solution.

Choice 2 can lead to missing data. Both triples are expected for `:x0`, only one is output. I don't see a use case for this behaviour although this is more consistent with SPARQL `CONSTRUCT` (and it can be confusing there).


Please view or discuss this issue at https://github.com/w3c/data-shapes/issues/753 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 1 February 2026 14:50:00 UTC