You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Gokhan Soydan <gs...@topquadrant.com> on 2011/10/13 06:25:04 UTC
BIND bug in nested graph pattern
Hello,
Using a BIND in a nested graph pattern (a basic, OPTIONAL or UNION
pattern) with an input argument that was assigned in the parent graph
pattern doesn't work. The following example query returns no value for
?x, whereas it should return the value of ?s assigned to ?x
SELECT ?x
WHERE {
?s ?p ?o
{
BIND( ?s AS ?x )
}
}
This is the case both in ARQ 2.8.1 and ARQ 2.8.7.
Thanks,
Gokhan
Re: BIND bug in nested graph pattern
Posted by Andy Seaborne <an...@apache.org>.
On 13/10/11 22:05, Gokhan Soydan wrote:
> Just to double-check. I assume this behavior (SPARQL is evaluated inside
> out) is also valid for OPTIONAL and UNION patterns, correct?
Yes - that is what the spec says.
ARQ analyses queries and execute them top-to-bottom (roughly) when it
would give the same results as this stream-based execution is usually
more efficient and uses a lot less intermediate memory. Think of it as
"index joins with scoping checks".
Andy
>
> Thanks,
> Gokhan
>
>
> On 10/13/2011 3:56 AM, Paolo Castagna wrote:
>>
>> Damian Steer wrote:
>>> On 13 Oct 2011, at 08:24, Paolo Castagna wrote:
>>>
>>>> Hi Gokhan
>>>>
>>>> Gokhan Soydan wrote:
>>>>> Hello,
>>>>>
>>>>> Using a BIND in a nested graph pattern (a basic, OPTIONAL or UNION
>>>>> pattern) with an input argument that was assigned in the parent graph
>>>>> pattern doesn't work. The following example query returns no value for
>>>>> ?x, whereas it should return the value of ?s assigned to ?x
>>>>>
>>>>> SELECT ?x
>>>>> WHERE {
>>>>> ?s ?p ?o
>>>>> {
>>>>> BIND( ?s AS ?x )
>>>>> }
>>>>> }
>>>> It says:
>>>>
>>>> "Use of BIND is a separate element of a group graph pattern and it
>>>> ends any basic graph pattern."
>>>>
>>>> So, I tried this instead:
>>>> SELECT ?x { ?s ?p ?o BIND ( ?s AS ?x ) }
>>>>
>>>> Bingo! I got my results:
>>> ARQ is correct. The mantra to repeat is: SPARQL is evaluated inside out.
>> Thanks Damian, it is always good to have confirmation.
>>
>> SPARQL is evaluated inside out, SPARQL is evaluate inside out, SPARQL
>> is evaluated inside out...
>>
>>> So:
>>>
>>>>> ?s ?p ?o
>>>>> {
>>>>> BIND( ?s AS ?x )
>>>>> }
>>> Start with the inner bit. ?s is unbound, and ?x isn't bound. The
>>> inner bit isn't doing anything at all, ?x is never bound.
>> SPARQL is evaluated inside out! ;-)
>>
>> Paolo
>>
>>> Damian
>
Re: BIND bug in nested graph pattern
Posted by Gokhan Soydan <gs...@topquadrant.com>.
Just to double-check. I assume this behavior (SPARQL is evaluated inside
out) is also valid for OPTIONAL and UNION patterns, correct?
Thanks,
Gokhan
On 10/13/2011 3:56 AM, Paolo Castagna wrote:
>
> Damian Steer wrote:
>> On 13 Oct 2011, at 08:24, Paolo Castagna wrote:
>>
>>> Hi Gokhan
>>>
>>> Gokhan Soydan wrote:
>>>> Hello,
>>>>
>>>> Using a BIND in a nested graph pattern (a basic, OPTIONAL or UNION
>>>> pattern) with an input argument that was assigned in the parent graph
>>>> pattern doesn't work. The following example query returns no value for
>>>> ?x, whereas it should return the value of ?s assigned to ?x
>>>>
>>>> SELECT ?x
>>>> WHERE {
>>>> ?s ?p ?o
>>>> {
>>>> BIND( ?s AS ?x )
>>>> }
>>>> }
>>> It says:
>>>
>>> "Use of BIND is a separate element of a group graph pattern and it ends any basic graph pattern."
>>>
>>> So, I tried this instead:
>>> SELECT ?x { ?s ?p ?o BIND ( ?s AS ?x ) }
>>>
>>> Bingo! I got my results:
>> ARQ is correct. The mantra to repeat is: SPARQL is evaluated inside out.
> Thanks Damian, it is always good to have confirmation.
>
> SPARQL is evaluated inside out, SPARQL is evaluate inside out, SPARQL is evaluated inside out...
>
>> So:
>>
>>>> ?s ?p ?o
>>>> {
>>>> BIND( ?s AS ?x )
>>>> }
>> Start with the inner bit. ?s is unbound, and ?x isn't bound. The inner bit isn't doing anything at all, ?x is never bound.
> SPARQL is evaluated inside out! ;-)
>
> Paolo
>
>> Damian
Re: BIND bug in nested graph pattern
Posted by Gokhan Soydan <gs...@topquadrant.com>.
Thanks a lot Paolo and Damian. That is actually change of behavior,
because similar queries with BIND were working in a bit earlier versions
of ARQ.
I will keep in mind that SPARQL is evaluated inside out :-) Although,
that will change my thinking in how I write some of my queries :-/
Gokhan
On 10/13/2011 3:56 AM, Paolo Castagna wrote:
>
> Damian Steer wrote:
>> On 13 Oct 2011, at 08:24, Paolo Castagna wrote:
>>
>>> Hi Gokhan
>>>
>>> Gokhan Soydan wrote:
>>>> Hello,
>>>>
>>>> Using a BIND in a nested graph pattern (a basic, OPTIONAL or UNION
>>>> pattern) with an input argument that was assigned in the parent graph
>>>> pattern doesn't work. The following example query returns no value for
>>>> ?x, whereas it should return the value of ?s assigned to ?x
>>>>
>>>> SELECT ?x
>>>> WHERE {
>>>> ?s ?p ?o
>>>> {
>>>> BIND( ?s AS ?x )
>>>> }
>>>> }
>>> It says:
>>>
>>> "Use of BIND is a separate element of a group graph pattern and it ends any basic graph pattern."
>>>
>>> So, I tried this instead:
>>> SELECT ?x { ?s ?p ?o BIND ( ?s AS ?x ) }
>>>
>>> Bingo! I got my results:
>> ARQ is correct. The mantra to repeat is: SPARQL is evaluated inside out.
> Thanks Damian, it is always good to have confirmation.
>
> SPARQL is evaluated inside out, SPARQL is evaluate inside out, SPARQL is evaluated inside out...
>
>> So:
>>
>>>> ?s ?p ?o
>>>> {
>>>> BIND( ?s AS ?x )
>>>> }
>> Start with the inner bit. ?s is unbound, and ?x isn't bound. The inner bit isn't doing anything at all, ?x is never bound.
> SPARQL is evaluated inside out! ;-)
>
> Paolo
>
>> Damian
Re: BIND bug in nested graph pattern
Posted by Paolo Castagna <ca...@googlemail.com>.
Damian Steer wrote:
> On 13 Oct 2011, at 08:24, Paolo Castagna wrote:
>
>> Hi Gokhan
>>
>> Gokhan Soydan wrote:
>>> Hello,
>>>
>>> Using a BIND in a nested graph pattern (a basic, OPTIONAL or UNION
>>> pattern) with an input argument that was assigned in the parent graph
>>> pattern doesn't work. The following example query returns no value for
>>> ?x, whereas it should return the value of ?s assigned to ?x
>>>
>>> SELECT ?x
>>> WHERE {
>>> ?s ?p ?o
>>> {
>>> BIND( ?s AS ?x )
>>> }
>>> }
>> It says:
>>
>> "Use of BIND is a separate element of a group graph pattern and it ends any basic graph pattern."
>>
>> So, I tried this instead:
>> SELECT ?x { ?s ?p ?o BIND ( ?s AS ?x ) }
>>
>> Bingo! I got my results:
>
> ARQ is correct. The mantra to repeat is: SPARQL is evaluated inside out.
Thanks Damian, it is always good to have confirmation.
SPARQL is evaluated inside out, SPARQL is evaluate inside out, SPARQL is evaluated inside out...
>
> So:
>
>>> ?s ?p ?o
>>> {
>>> BIND( ?s AS ?x )
>>> }
>
> Start with the inner bit. ?s is unbound, and ?x isn't bound. The inner bit isn't doing anything at all, ?x is never bound.
SPARQL is evaluated inside out! ;-)
Paolo
>
> Damian
Re: BIND bug in nested graph pattern
Posted by Damian Steer <d....@bristol.ac.uk>.
On 13 Oct 2011, at 08:24, Paolo Castagna wrote:
> Hi Gokhan
>
> Gokhan Soydan wrote:
>> Hello,
>>
>> Using a BIND in a nested graph pattern (a basic, OPTIONAL or UNION
>> pattern) with an input argument that was assigned in the parent graph
>> pattern doesn't work. The following example query returns no value for
>> ?x, whereas it should return the value of ?s assigned to ?x
>>
>> SELECT ?x
>> WHERE {
>> ?s ?p ?o
>> {
>> BIND( ?s AS ?x )
>> }
>> }
>
> It says:
>
> "Use of BIND is a separate element of a group graph pattern and it ends any basic graph pattern."
>
> So, I tried this instead:
> SELECT ?x { ?s ?p ?o BIND ( ?s AS ?x ) }
>
> Bingo! I got my results:
ARQ is correct. The mantra to repeat is: SPARQL is evaluated inside out.
So:
>> ?s ?p ?o
>> {
>> BIND( ?s AS ?x )
>> }
Start with the inner bit. ?s is unbound, and ?x isn't bound. The inner bit isn't doing anything at all, ?x is never bound.
Damian
Re: BIND bug in nested graph pattern
Posted by Paolo Castagna <ca...@googlemail.com>.
Hi Gokhan
Gokhan Soydan wrote:
> Hello,
>
> Using a BIND in a nested graph pattern (a basic, OPTIONAL or UNION
> pattern) with an input argument that was assigned in the parent graph
> pattern doesn't work. The following example query returns no value for
> ?x, whereas it should return the value of ?s assigned to ?x
>
> SELECT ?x
> WHERE {
> ?s ?p ?o
> {
> BIND( ?s AS ?x )
> }
> }
>
>
> This is the case both in ARQ 2.8.1 and ARQ 2.8.7.
The latest stable release of ARQ is 2.8.8:
http://repo1.maven.org/maven2/com/hp/hpl/jena/arq/2.8.8/
Have you tried using the latest stable release?
There is also a SNAPSHOT on the Apache Maven repository:
https://repository.apache.org/content/repositories/snapshots/org/apache/jena/jena-arq/2.8.9-incubating-SNAPSHOT/
Have you tried testing this SNAPSHOT as well?
I tried using:
ARQ 2.8.9-incubating-SNAPSHOT (the new Apache SNAPSHOT) and ARQ 2.8.9-SNAPSHOT (the old SNAPSHOT).
The both have the behavior you described, some results are there (i.e. the correct number)
but it seems the variable ?x is not bound to the value of ?s.
-----
| x |
=====
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
-----
I suspected a bug, but I wanted to double check.
So, I went to check the SPARQL 1.1 Query Language spec:
http://www.w3.org/TR/sparql11-query/#bind
It says:
"Use of BIND is a separate element of a group graph pattern and it ends any basic graph pattern."
So, I tried this instead:
SELECT ?x { ?s ?p ?o BIND ( ?s AS ?x ) }
Bingo! I got my results:
-----------------------------------
| x |
===================================
| <http://example.org/book/book1> |
| <http://example.org/book/book1> |
| <http://example.org/book/book2> |
| <http://example.org/book/book2> |
| _:b0 |
| _:b0 |
| <http://example.org/book/book3> |
| <http://example.org/book/book3> |
| <http://example.org/book/book4> |
| <http://example.org/book/book5> |
| <http://example.org/book/book5> |
| <http://example.org/book/book6> |
| <http://example.org/book/book6> |
| <http://example.org/book/book7> |
| <http://example.org/book/book7> |
| _:b1 |
| _:b1 |
-----------------------------------
I hope it helps,
Paolo
>
> Thanks,
> Gokhan