Re: can subqueries be executed first in SPARQL?

On 06/17/2016 03:00 PM, Gregory Williams wrote:
> On Jun 17, 2016, at 2:25 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>>> 18.2.1 does not suggest that the recommendation believes that.
>>> their nature is one of the things which defines a language.
>>
>> 18.2.1 talks about variable scope.  However, all that it ends up doing is
>> determining when certain syntactic constructs are syntactically illegal and
>> determining how to translate SELECT *.  It doesn't do many of the things
>> that one would think of as needed for variable scoping in a programming
>> language, like determining whether a variable mention is a local or a global
>> variable.
>>
>> One could say that this notion of scoping is so important for SPARQL that it
>> should affect the meaning of EXISTS.  For example, that only substitutions
>> that are in-scope for SELECT ... should be carried through into its
>> pattern.  I don't see any support for anything like this in the SPARQL 1.1
>> Query specification.
> 
> Isn’t that exactly what some of the errata do? For example, [1]:
> 
> """
> The definition of Substitute should exclude varaibles not visible at the outermost level of the graph pattern. That is, a variable used inside a nested SELECT that is not in it's projection, should be considered a different variable. Similarly, with embedded NOT EXISTS/EXISTS expressions, variables used only within that expression, are "hidden" (these are an a nested "ASK" query).
> """

Indeed, this issue has already been noted and is the subject of this proposed
erratum "suggested by the community".  However, this suggestion is not
well-formed.

Consider a slight modification of the example in the erratum

SELECT ?s WHERE {
    ?s :p ?value .
    FILTER EXISTS {
        ?s :p ?count .
        BIND ( :p AS ?other )
        {
            SELECT (COUNT(*) AS ?count) WHERE {
                ?s :p ?other
            }
        }
    }
}

Here ?other is "visible at the outermost level of the graph pattern" but is
also not in the projection.  Which one of the two rules should be followed?
My guess is that the intent is to push substitutions through Project only for
variables that are in the projection.

Virtuoso does not follow this suggestion, as far as I can tell.

But pushing substitutions through Project for variables that are in the
projection has its own problems. Substituting only into the body of the SELECT
is well-defined, but is counter-intuitive.  Substituting in the projection
variables generally results in semantically ill-formed solution sets.

For example,
SELECT ?s WHERE {
  ?s :p : b .
  FILTER EXISTS { SELECT ?s WHERE { ?s :p :b } }
}
on
:c :p :b .
produces a SPARQL algebra expression something like
Project( ..., { :c } )
Which is not exactly kosher.



> 
>>> early on in this exchange, i suggested the step to formulate the tests which
>>> demonstrate the significant issues and add them to the w3c [SPARQL] test
>>> suite in order to set milestones.
>>> once they exist, one can respond to your supposition.
>>
>> How can one add tests to the W3C SPARQL test suite?
> 
> The test suite is now under the maintenance of the RDF Tests Community Group[2].

Thanks.

> 
> thanks,
> .greg
> 
> [1] http://www.w3.org/2013/sparql-errata#errata-query-8
> [2] https://w3c.github.io/rdf-tests/
> 

peter

Received on Friday, 17 June 2016 22:32:13 UTC