Re: The semantics of BIND in SPARQL*

Hi Pavel,

Good question - it really pushes on the triple reference / triple in 
data model point.

On 22/11/2019 13:44, Pavel Klinov wrote:
> 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 https://arxiv..org/pdf/1406.3399.pdf 
> <https://arxiv.org/pdf/1406.3399.pdf> 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.

In PG mode, yes, I think <<:a :p :b>> with no :a :p :b has to evaluate 
to error.

Is SA mode, no problem it is a term without associate condition.

>
> 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?
>
> Best,
> Pavel

Received on Monday, 2 December 2019 13:30:21 UTC