By the way, in case you need more complex positional relations between fields, have a look at LUCENE-5627 . A spanwithinquery is also used in the test code there as an unordered spannear with 2 arguments and distance -1.
Regards, Paul Elschot On 3 september 2014 20:23:46 CEST, Shai Erera <[email protected]> wrote: >Thanks Hoss, this is very useful information, especially >FieldMaskingSpanQuery :). > >So according to those issues, it seems others also think that end1 <= >end2 >is also a "correct" behavior of SNQ (in case ordered=true, and >start1==start2). Was there a reason these issues were not resolved >(e.g. >LUCENE-3120)? I'm asking if there was additional discussion where >people >raised objections against this, or was it just a matter of lack of >time/focus? > >Shai > > >On Wed, Sep 3, 2014 at 8:47 PM, Chris Hostetter ><[email protected]> >wrote: > >> : I then implemented a variation of a span query which I call >> SpanWithinQuery >> : which allows me to search for "fox WITHIN nickname". The way it's >> : implemented is a SpanNearQuery on annot:nick and annot:/nick, and >> whenever >> : a match is found for 'fox', it makes sure that the position falls >within >> : the range of the nick annotation. Quite simple. >> >> FWIW: i think what you are describing is just a special case of >> FieldMaskingSpanQuery, might save you some custom code -- but that's >a >> tangent. >> >> : If you forget about all the preface I wrote above, I have a basic >> question >> : about the semantics of SNQ. I tried a simple case -- SNQ("fox", >"fox") >> and >> : I get 0 results. Is this a bug in SNQ itself, or it's not built to >find >> : spans that are identical in their start/end positions, and I should >use >> : another variant of SpanQuery? >> >> I'm not lookin at the code, and i'ts been a looooong while since i >thouht >> about phrases/spans in depth, but i seem to recall this being a known >> aspect of the behavior ... similar to how PhraseQuery behaves i >think? >> >> since you have "ordered=true" then the 2nd span must come *after* the >> first span, and "after" is defined based on the end position of hte >spans >> (aparently?) >> >> You'll find a couple issues in jira (both closed and open) discussing >what >> the "right" behavior of SpanNearQuery should be. Some particularly >> on-point issues based on a quick skim... >> >> https://issues.apache.org/jira/browse/LUCENE-3120 >> https://issues.apache.org/jira/browse/LUCENE-3371 >> https://issues.apache.org/jira/browse/LUCENE-3229 >> >> >> -Hoss >> http://www.lucidworks.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
