[Mulgara-dev] xsd resolver

[Paul Gearon]

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.

I never knew what the XSD resolver actually did until a few weeks ago
(when I looked up the code to see what it can and can't do). So it
never occurred to me how this might interact with other data. Yeah,
it's a big problem.

> 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).
>
> Any thoughts?

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.

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.

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?

> Btw., this problem relates to any resolver that can generate tuples of
> values not stored in the stringpool, such as the http-resolver and
> file-resolver.

Yes, I see that. Yuck.  :-)

Are you able to see if the numbers you are working with are being
localized into negative gNodes?  TIA.

Paul