The semantics of BIND in SPARQL*

Hi all,

I'm an engineer at Stardog and we're working on a beta support for
RDF*/SPARQL*. Here's one thing which bothers me: the semantics of
BIND(<<spo>> as ?x).

The way it's defined in Defn 13.2 (if I
read it correctly) basically means "evaluate spo as a triple pattern and
extend each solution with ?x = <s,p,o>". This is OK but it's very different
from the standard semantics of BIND in SPARQL, e.g. BIND(:a as ?x). It
creates the following specific issues:

i) It's difficult to construct embedded triples out of nothing. On the
empty data, "select ?x { bind(:a as ?x) }" returns "?x = :a" but "select ?x
{ bind(<<:a :p :b>> as ?x) }" returns nothing because the semantics
evaluates ":a :p :b" and that triple is not in the data.

ii) this possibly creates troubles for query parameterisation in SPARQL*
which often (though it is not standardised) works by textually replacing
variables by their parameter values and adding BIND nodes to preserve
variables names. For example,evaluation of select ?x ?y { ?x ?p ?y . } with
"?x -> :a" could be done as select ?x ?y { :a ?p ?y . bind(:a as ?x) }, and
it's not clear if that would work in all cases for "?x -> << :a :p :b >>"

iii) queries like "construct { << ?x :p ?y >> :q "abc" } where { something
}", while seem reasonable, cannot be trivially rewritten into something
like "construct { ?s :q "abs" } where { something . bind(<< ?x :p ?y >> as
?s) }". It's pretty common in SPARQL to rewrite complex expressions in
projections to bind expressions and aux variables to simplify processing,
and it now breaks since BIND works differently for embedded patterns.

To sum up, it feels like overriding the same old BIND keyword for a
different semantics is not ideal. Does anyone have thoughts on this?


Received on Friday, 22 November 2019 13:49:38 UTC