[Mulgara-dev] Fwd: Bug list and versions

Andrae Muys andrae at netymon.com
Tue Nov 14 09:05:11 UTC 2006


On 14/11/2006, at 2:32 PM, Life is hard, and then you die wrote:

> On Tue, Nov 14, 2006 at 10:42:28AM +1000, Andrae Muys wrote:
>>
>> select $a $t from <>
>> where
>>  $b <p:type> <t:p> and
>>  $b <p:hasA> $a and
>>  ((
>>    $b <p:hasB> 'mollusks' and
>>    $t <#is> '0'
>>   ) or (
>>    $t <#is> '1'
>>  ))
>>
>> As far as I can tell it appears you are trying to perform some sort
>> of outer-join-like query here - roughly analogous to a SPARQL
>> optional?
>
> Sort-of like an outer-join, yes; not sure it's really like 'optional'.
> As explained in the other email, the general form is
>
>   ...pre-condition-on-a-and-b... and
>   ((
>     condition1-on-b and
>     $t <#is> '0'
>    ) or (
>     condition2-on-b and
>     $t <#is> '1'
>    ) or (
>     condition3-on-b and
>     $t <#is> '2'
>   ))
>
> So the $t is to know which or-term(s) actually matched. In the error
> case, one of the conditions is empty, leaving only the <#is> clause.

Yes I got that, and the only thing stopping you from doing a straight  
subquery is that you are querying the property not the instance.

ie.  select $a from .... rather than select $b from ....

>> I am fascinated by this, you are the first users I am aware of
>> making real use of NUC-disjunctions - almost everyone seems to
>> prefer to use subqueries to solve these sort of problems.  Part of
>> the reason for this is that the performance of NUC-disjunctions is
>> unavoidably poor.
>
> We haven't reached the detailed query performance-optimization stage
> yet, so this is good to know. Luckily this particular query is not
> very performance sensitive.

If you do, I've finally remembered how I did this last time I had to  
write an equivalent query (attaching constants never occurred to me :).

select $a subquery(select from <> where precondition-on-a-and-b and  
condition-1-on-b)
           subquery(select from <> where precondition-on-a-and-b and  
condition-2-on-b)
from <>
where precondition-on-a-and-b.

The thing that messes this up a little is that it is possible for the  
$b <-> $a relation to be an N<->M relationship, and that you are  
apparently wanting to aggregate the condition's over all $b's  
matching a given $a.  If in fact you do care which $b a given $a/ 
condition-N pair reflects then this query becomes much much simpler:

select $a $b subquery(select from <> where condition-1-on-b)
              subquery(select from <> where condition-2-on-b)
from <>
where precondition-on-a-and-b

Or possibly tidier:

select $a subquery(
              select $b subquery(select from <> where condition-1-on-b)
                        subquery(select from <> where condition-2-on-b)
              from <>
              where precondition-on-a-and-b)
from <>
where constrain-a's-from-a-and-b

(note that the repeated precondition is not really inefficient, as  
substitution will greatly simplify the inner condition).

>> Unfortunately, because you aren't selecting $b
>> you can't capture the optional restriction as a subquery in this
>> case - if you were you could use the following:
>>
>> select $b $a subquery(select
>>           from <rmi://localhost/server1#test>
>>           where $b <p:hasB> 'mollusks')
>> from <rmi://localhost/server1#test>
>> where
>>  $b <p:type> <t:p> and
>>  $b <p:hasA> $a
>>
>> Then $k0 will be empty where $t == '1', unconstrained where $t ==  
>> '0'.
>
> Ah, I see. So in the more general case I could use
>
>   select $b $a
>     subquery(select '0' from <...> where condition1-on-b)
>     subquery(select '1' from <...> where condition2-on-b)
>     subquery(select '2' from <...> where condition3-on-b)
>   from <rmi://localhost/server1#test>
>   where
>     ...pre-condition-on-a-and-b...
>
> That's good to know.
>
Yes, although you should note that in this case the 'N''s are  
redundant.  Calling isEmpty() and isUnconstrained() on the sub-Answer  
will obtain the same result far more efficiently (as it will avoid  
the multiple calls, and the network-data transfer).

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd





More information about the Mulgara-dev mailing list