Re: Issue-3 - Blank nodes substituted into BGPs act as variables

On 14/07/16 18:57, Peter F. Patel-Schneider wrote:
> On 07/14/2016 10:43 AM, Gregory Williams wrote:
>>
>>> On Jul 14, 2016, at 10:37 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>>
>>> You have to put the multiset and Join in the right place.  If you think
>>> syntactically, it is like putting a generalized VALUES construct as the first
>>> element of the GroupGraphPattern that is the argument to EXISTS, i.e., changing
>>>    { ?x :q ?y FILTER(?y = ?o) }
>>> to
>>>    { VALUES* (?s ?o) { ... } ?x :q ?y FILTER(?y = ?o) }
>>> where ... is the correct values for ?s and ?o (and can be blank nodes).  To
>>> make that all easy, an initial replacement has to be done on the syntactic
>>> level, i.e., when FILTERS are gathered (18.2.2.2), and then when the exists is
>>> evaluated (18.6) the current solution mapping has to be pushed to the correct ....
>>>
>>> Evaluating the query on the graph
>>>   :b :p :c .
>>>   :d :q :c .
>>> results in the exists evaluating something like
>>> Filter( (?y=?o), Join( { { (:s,:b), (:o,:c) } } , BGP( ?x :q ?y )
>>> which should all work out.
>>
>> Might this approach require injecting the syntactic token in multiple places in the exists pattern? If you start combining filters as above with branching constructs like unions and multiple group graph patterns, it sounds like the injection might need to occur in many locations.
>>
>> thanks,
>> .greg
>
> To get the maximum conformance to the SPARQL spec, yes, you have to do the
> injection into every group graph pattern.   I don't think that that is the
> best way to go.  However, it may be that this group shouldn't produce the best
> solution but instead a worse solution that is closer to the spec.
>
>
> peter
>

This is a good case to explore by examples.

SELECT * WHERE {
        VALUES ?o { 1  2 }
        ?s ?p ?x
        FILTER(?o = ?x)
}

is

(filter (= ?o ?x)
   (join
     (table (vars ?o) (row [?o 1]) (row [?o 2]) )
     (bgp (triple ?s ?p ?x))))

so that's OK because the filter is over the join.


A simpler albeit artificial example like Greg's:

SELECT * WHERE {
        VALUES ?o { 1  2 }
        {
        ?s ?p ?x
        FILTER(?o = ?x)
        }
}

gives:

(join
   (table (vars ?o) (row [?o 1]) (row [?o 2]) )
   (filter (= ?o ?x)
     (bgp (triple ?s ?p ?x))))

and the filter does not have ?o set at that point.

In defence of artificial examples, program-generated SPARQL queries do 
seem to end up with quite unhuman structures.

     Andy

Received on Friday, 15 July 2016 15:20:42 UTC