[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