The idea was to obtain annotations that precede the "pos" annotation in terms of offsets. So if you superimpose the "pos" annotation and another candidate annotation "c" on the text, then "c" and "pos" should not overlap.
I think the annotation so far has been mostly (probably exclusively) used on annotations that to not overlap (e.g. Token). I think selectPreceding in uimaFIT has a bug here - as you point out - that while iterating backwards, the end position of the annotations are not checked before including them in the result set. Cheers, -- Richard > On 30.09.2016, at 21:38, Marshall Schor <[email protected]> wrote: > > The implementation appears to take a positioning element, (let's call it > "pos"), > and then start at an annotation where > > * for following: the begin is > pos.end > * for preceding: the end is < pos.begin > > The Annotation index guarantees that "begin" positions are in ascending order > as > you go thru the index. > > But there's no such guarantee for "end" positions. They can jump back and > forth. So the logic for preceding: starting with some annotation whose end > is < > pos.begin in no way guarantees that all the found annotations will have this > property. > > What was the design intent for preceding? > > If it was to get FSs that precede the pos in the index, then this logic is not > doing that - it's initially skipping some number of preceding items (where the > preceding FSs have ends >= pos.begin), and then providing results where the > end > could easily bounce around the pos.begin position. > > -Marshall >
