uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: question on uimaFIT following and preceding
Date Wed, 08 Feb 2017 21:45:00 GMT
Here's a (maybe) alternative use case which may want a different solution.

The implementation of following and preceding was thought of in the context of
an AnnotationIndex.
But it *could* be designed to apply to any sorted index.

In another case, you might be iterating over a sorted index on Annotations, but
which didn't use begin and end keys, but something else.

In these alternative cases, there may be no begin and end, but just some other
key or keys, used to determine a sort order.

The most general implementation for following and preceding would just do a
positioning, using the sort order, and then iterate from that point.

I suppose that would be "cleaner" and more general.


-Marshall (stirring up trouble as usual)

On 2/7/2017 9:48 AM, Marshall Schor wrote:
> I tend to agree with you :-)
> I've implemented the equivalent in the UIMA v3 Select framework, where it does
> "skip".  That could be made configurable, but I think I would rather wait to see
> if someone needs this before adding that configuration ability to the API.
> -Marshall
> On 2/7/2017 3:22 AM, Richard Eckart de Castilho wrote:
>>> On 06.02.2017, at 22:31, Marshall Schor <msa@schor.com> wrote:
>>> Hi,
>>> The v3 "select" framework has following and preceding methods, modeled on uimaFIT.
>>> I think "following" only depends on the "getEnd()" value of the annotation, and
>>> "preceding" only depends on the "getBegin()" value of the annotation, is this
>>> correct?
>> I am pretty sure that this is the intention, yes.
>>> Also, when doing a preceding, are annotations whose "getEnd()" are too large,
>>> skipped while iterating backwards?
>> The current implementation of selectPreceding() does not check skip such annotations.
>> Looking where selectPreceding originally came from, I believe that this may be bug.
>> Also, the behavior of selectPreceding() is inconsistent with selectBetween() and
>> which work as expected.
>> Since we have this behavior since v1.1.0, it is hard to tell if anybody came to rely
on it.
>> So I would consider this a bug to be fixed in selectPreceding...
>> WDYT?
>> Cheers,
>> -- Richard

View raw message