[Mulgara-general] SPARQL question

[Alex Hall]

Paul Gearon wrote:
> On Wed, Nov 26, 2008 at 2:39 PM, Jim Irwin <jimirwin at acm.org> wrote:
>> I wrote a SPARQL query that attempts to find all the root classes of an
>> ontology, i.e. those that are not subclasses of classes other than
>> owl:Thing and rdfs:Class.
> <snip/>
> 
>> Here's my question:  In my SPARQL query's OPTIONAL group, I filter out
>> all the rdfs:subClassOf triples that contain owl:Thing or rdfs:Class as
>> the object.  So I would expect that the ?sup variable would not be bound
>> outside that group, and that foaf:OnlineAccount would pass the
>> !bound(?sup) filter.  However, it appears that it does not pass the
>> filter, as if the !bound filter were being applied inside the OPTIONAL
>> group rather than outside it.
> 
> The FILTER(!isBound) should certainly be applied outside of the
> OPTIONAL. I'm not saying that it is (I need to check), but that's the
> intent.
> 
>> Just for comparison, I ran the same query using Jena, and
>> foaf:OnlineAccount does appear in the results list when using Jena, as I
>> would expect it to.
>>
>> Is this a bug in Mulgara's implementation of SPARQL filters, or is this
>> just an area of ambiguity in the SPARQL spec that allows for different
>> implementations?
> 
> No, I don't read this as an ambiguity. If I got it wrong, then it's me
> and not the spec.
> 
> I think the best way to handle this is to step through it in a
> debugger and follow it carefully. I'll let you know how this goes.

I took a quick look at this.  The problem appears to be that the
TuplesContext.isBound() method, used to evaluate the FILTER(!isBound), calls
LeftJoin.getRawColumnValue().  This method bypasses the evaluation of the inner
FILTER ( (?sup != owl:Thing) && (?sup != rdfs:Class) ), which is only done in
LeftJoin.getColumnValue().  It seems that the solution would be to change
isBount() to test the "filtered" column value, but I'm not very familiar with
that part of the code.

In a more general sense, I don't really understand the difference between "raw"
and "filtered" column values.  It seems that filtering should be applied on a
row-by-row basis, not a column-by-column basis.  LeftJoin appears to be the only
class that is evaluating these differently.  I would think that if the
right-hand side of an optional join is filtered out in normal evaluation, then
it's not valid for filters outside the join to ever access the values that it
would have been bound to.  Paul, am I incorrect?  My instinct is that the inner
filter should be pushed down into the right-hand-side of the optional join, not
evaluated as part of the join itself.

Alex