[Mulgara-dev] xsd resolver

[Life is hard, and then you die]

On Tue, Nov 11, 2008 at 02:12:08PM -0600, Paul Gearon wrote:
> On Tue, Nov 11, 2008 at 6:31 AM, Life is hard, and then you die
> <ronald at innovation.ch> wrote:
> <snip/>
> > Digging into this a bit, the "problem" is that the xsd resolver does a
> > findStringPoolRange() to find all items in the stringpool that match
> > the condition (i.e. all doubles in the stringpool with a value greater
> > than 0.5, in the above example); the resulting list of tuples is then
> > joined against the tuples returned by the lucene-resolver. Of course,
> > the chance of the stringpool happening to have a value that's the same
> > as a score is extremely small, and hence the join usually returns no
> > results.
[snip]
> > This leads me to wonder if A) the xsd-resolver shouldn't instead be a
> > filter rather than a generator of tuples, or B) if we should create
> > additional predicates that result in filtering instead of lookup. I
> > suppose a third approach might be C) try to determine if the subject
> > is bound elsewhere in the query and use lookup if not and filtering if
> > so - I'm not sure if this is fully feasible at this point, but I don't
> > have a full enough understanding of the Annotations yet (which I
> > presume is at least part of the mechanism for this sort of stuff).
> 
> You're right, we need filtering - but only when comparing to variables
> that were bound by something other than the data pool. Of course,
> SPARQL already does this, but that's not the point here.

But the SPARQL implementation _always_ does filtering, which isn't
great either.

> 2 things come to mind. First, a new resolver and/or predicates could
> be created as you suggest. At that point it becomes the developer's
> responsibility to know the difference and to use each accordingly.
> That works, and provides a lot of flexibility, but I'm not happy about
> it.

Neither am I.

> Second, I believe that any numbers generated in a query will have a
> negative gNode (are you able to check this?). Perhaps it's possible to
> filter on these numbers, while still matching on positive gNodes?

Yes, they are negative. But I'm not sure how that helps: the decision
whether to generate or filter needs to be done ahead of time, or else
we have to tell the query scheduler that the xsd resolver always be
run last.

Hmm, I think the DefinablePrefixAnnotation can be used to determine
whether the variables have been bound or not, i.e. that could be used
to trigger whether to filter or generate. However, I think one piece
is still missing: a way to the query planner that it should use other
resolvers to resolve the variables _if possible_ (the
MandatoryBindingAnnotation doesn't cut it because that's a hard
requirement rather than a soft please-but-only-if-you-can). So maybe a
new annotation is needed here.


  Cheers,

  Ronald