W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004


From: Simon Raboczi <raboczi@tucanatech.com>
Date: Tue, 16 Nov 2004 16:57:01 +1000
Message-Id: <B770E47E-379C-11D9-889A-000A95C5686E@tucanatech.com>
Cc: public-rdf-dawg@w3.org
To: Eric Prud'hommeaux <eric@w3.org>

On 16/11/2004, at 3:11, Eric Prud'hommeaux wrote:

> On Tue, Nov 16, 2004 at 12:42:39AM +1000, Simon Raboczi wrote:
>> Can you demonstrate for the simplest case of
>> SELECT ?a ?b WHERE (?a <x:p1> <x:o1>) UNION (?b <x:p2> <x:o2>)
>> targeting a graph with the following triples
>> <x:s1> <x:p1> <x:o1> .
>> <x:s2> <x:p2> <x:o2> .
>> I'd expect the result
>> +--------+--------+
>> |   ?a   |   ?b   |
>> +--------+--------+
>> | <x:s1> |        |
>> |        | <x:s2> |
>> +--------+--------+
>> What's the equivalent SPARQL using [ ] instead of UNION?
> The simple way would be to again reduce the sides of the conjunction
> to a single triple as we did in SQL:
> SELECT ?a ?b WHERE (?s ?p ?o)
>                AND ((?p=<x:p1> AND ?o=<x:o1>)
>                  OR (?p=<x:p2> AND ?o=<x:o2>))

Sneaky!  You've replaced UNION in the WHERE clause by OR in the AND 
clause.  I didn't think of that because I'm still desperately hoping 
the difference between the WHERE and AND clauses will somehow go away.  
:)  I certainly agree that WHERE-UNION can always be transformed into 
AND-OR, but I think this is a separate issue to being able to replace 
it with outer join.

> If you want a challenge, and add NULLs to the language, maybe you can
> do it was a disjunction. You need a throw-away truth for this.
> Something like
>   moon madeOf greenCheese .
> SELECT ?a ?b WHERE (moon madeOf greenCheese)
>                    [?a <x:p1> <x:o1>]
>                    [?b <x:p2> <x:o2>]
>                AND (?a IS NULL OR ?b IS NULL)
> but that assumes that you'll get a match on the astronomical trivia.
> You can be more assured that (?s ?p ?o) will match, and since the
> results are a set, you get no more logical results, but that might
> be a bit pricey to actually execute.

I'm pretty sure what happens here is that the (moon madeOf greenCheese) 
LHS evaluates to the "always true" result, which has one unique 
solution with no variable bindings.  Outer joins always have the same 
number of solutions as their LHS argument, so the result after the two 
optional clauses will still have one solution.  The AND clause might 
reduce this to zero.  However, there's no way it'll ever produce two 
solutions as would be needed to match the behavior of UNION.
Received on Tuesday, 16 November 2004 06:57:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC