[Mulgara-dev] Re: Bug list and versions

[Paul Gearon]

On Nov 13, 2006, at 5:51 PM, Life is hard, and then you die wrote:
>> mulgara:is was designed to allow other constraints to have a variable
>> "pre-set" before they were resolved.  So it acts as a modifier to  
>> other
>> constraints.  The "and" syntax is really an overload that was  
>> adopted to
>> make the syntax similar to what already existed in iTQL.
>
> Interesting. Because
>
>     select $s from <local:///topazproject#test> where $s  
> <mulgara:is> '42';
>
> works just fine (returns one row with $s = '42'). And if I run the
> original select above with one OR term at at time it works exactly as
> expected too.

I continued reading Andrae's thread and was pleased to see his  
description of the implementation.  I had never looked at this code,  
but Andrew once described it as a modifier, hence my description.   
The implementation that Andrae describes makes a lot more sense, and  
I'm happy to see it done that way (I don't know if it was ever done  
the way Andrew described it, only that this was what I was told about  
it).

Good to know Andrae is about to clarify those areas of the code I  
haven't worked in.

>> c) AND the <mulgara:is> with the EXCLUDE operator, but I recommend  
>> against
>> this, as this operator is rarely useful.
>
> Agreed. We had a long discussion here around the misunderstanding (or
> mis-definition) of EXCLUDE.

I have difficulty telling people that EXCLUDE is a mistake.  For some  
reason people think they need it.  I've given it a lot of thought,  
and I can't come up with a single use case where it is useful.

The problem is that the subjects, predicates, or objects that you  
THINK you are excluding, almost always appear elsewhere in the graph  
in a different context.  It usually includes everything or nothing.   
I've also seen examples where EXCLUDE appeared to work, but then a  
single new assertion broke the query.

To anyone out there who thinks that EXCLUDE is useful, bring me your  
query, and I'll show you why it will fail.

>> d) AND the <mulgara:is> with the MINUS operator (eg. all uses of  
>> <p:hasB>
>> MINUS those cases of "<p:hasB> 'mollusk').  This is better than  
>> EXCLUDE, but
>> will not return anything if there are no instances of the <p:hasB>  
>> predicate
>> in use:
>
> Oh? Wow! When did that make it in? I completely missed this one...
> (looks like I should file a bug against the docs since I can't seem to
> find it anywhere there).

It went in last year.

We haven't had any new documentation since 2004, since everything  
that exists to date was automatically generated by commercial  
software that we no longer have access to.  Everyone thinks it's a  
bad idea to hand-edit the HTML files, meaning that we can't edit the  
docs.  (That didn't stop me from changing "Kowari" to "Mulgara", but  
that's beside the point!)  :-)

The result is that we have historical documentation, but nothing  
current.  If we want anything current then we have to build the  
entire documentation for Mulgara from scratch.  Doesn't sound like  
fun, does it?  :-)

If you want some idea of how to use MINUS, then look in the jxdata/ 
iTQL/difference directory.  This has the scripted tests for the  
difference operator.

>>   ($b <p:hasB> $value minus
>>   $b <p:hasB> 'mollusks') and
>>   $t <mulgara:is> '1'
>>
>> This will only match on $b if it uses the <p:hasB> predicate, but  
>> the value
>> is set to something other than mollusks.
>
> This is really useful for a completely different query of ours (where
> we're currently using EXCLUDE). Thanks!

No problem.  As I said, if you're using EXCLUDE, then you'll need to  
change it.

Paul