uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thilo Goetz <twgo...@gmx.de>
Subject Re: Type Priorities
Date Fri, 14 Mar 2008 10:09:03 GMT
LeHouillier, Frank D. wrote:
> I was certainly tripped up by it.  I'm not even sure that the default
> behavior shouldn't be different than it is.  It feels like an artifact
> of implementation convenience rather than something the user should
> expect.

I don't like the behavior, either.  However, type priorities were
introduced because of user requirements.  They're certainly not
an implementation convenience.  Quite the opposite, in fact :-)

Now if enough users speak up, maybe we can change something.
Perhaps by default, type priorities should not be used and
you'd need to do something special to activate them.  One
might imagine special iterator overloads that respect type

The problem that type priorities are trying to address is
a valid one, IMHO.  I'm just not sure that the way we're
tackling this is the best one.

> Anyway, perhaps another solution to this problem might be suggested by
> the findCoverFS method in the Regex annotator.  In Katrin's example you
> could create a dummy Abbreviation with the offsets of the entity, use
> FSIterator.moveTo() to get to it and add all the valid iterators you
> find going forward that still fall within the end offset to your list.

This is what the code in my other reply is supposed to do.

> I'm not sure of the efficiency of moveTo() versus iterating through the
> whole list though.  Is an FSIndex implemented as a hash so that
> searching through it for the right offsets (using moveTo()) is
> efficient?

The annotation indexes are implemented as balanced search
trees (red-black trees).  moveTo() is quite efficient.


View raw message