You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Richard Eckart de Castilho (Jira)" <de...@uima.apache.org> on 2020/11/03 15:31:00 UTC

[jira] [Comment Edited] (UIMA-6289) SelectFS.coveredBy not selecting annotations with exact same bounds as annotation argument

    [ https://issues.apache.org/jira/browse/UIMA-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225485#comment-17225485 ] 

Richard Eckart de Castilho edited comment on UIMA-6289 at 11/3/20, 3:30 PM:
----------------------------------------------------------------------------

On a more stripped down version of the test only including two annotations, this is what can be observed.

{code}
        Annotation a1 = new Annotation(jCas, 5, 10);
        SubType subType = new SubType(jCas, 5, 10);
        
        asList(a1, subType)
                .forEach(Annotation::addToIndexes);

        assertThat(jCas.select(Annotation.class).coveredBy(subType).asList())
                .containsExactly(a1);
{code}

The annotation index contains two annotations:

{noformat}
FsIndex_annotation, index=FsIndex_set_sorted(Sorted)[Annotation]
  cache 0  FsIndex_set_sorted(Sorted)[Annotation]
  cache 2  FsIndex_set_sorted(Sorted)[SubType]
{noformat}

The test does a {{jcas.select(Annotation.class).coveredBy(subType)...}}. So what it does internally is, it positions an index iterator at the position of {{subType}} and then search towards the right (or downwards if you wish).

uimaFIT selectCovered in this case positions the index iterator at {{subType}} but then seeks left (or upward) for any annotations at the same offsets which might be relevant (the index iterator already filters by type, so uimaFIT does not need to pay attention to the type).



was (Author: rec):
On a more stripped down version of the test only including two annotations, this is what can be observed.

The annotation index contains two annotations:

{noformat}
FsIndex_annotation, index=FsIndex_set_sorted(Sorted)[Annotation]
  cache 0  FsIndex_set_sorted(Sorted)[Annotation]
  cache 2  FsIndex_set_sorted(Sorted)[SubType]
{noformat}

The test does a {{jcas.select(Annotation.class).coveredBy(subType)...}}. So what it does internally is, it positions an index iterator at the position of {{subType}} and then search towards the right (or downwards if you wish).

uimaFIT selectCovered in this case positions the index iterator at {{subType}} but then seeks left (or upward) for any annotations at the same offsets which might be relevant (the index iterator already filters by type, so uimaFIT does not need to pay attention to the type).


> SelectFS.coveredBy not selecting annotations with exact same bounds as annotation argument
> ------------------------------------------------------------------------------------------
>
>                 Key: UIMA-6289
>                 URL: https://issues.apache.org/jira/browse/UIMA-6289
>             Project: UIMA
>          Issue Type: Bug
>          Components: uimaj
>    Affects Versions: 3.1.1SDK
>            Reporter: Mario Juric
>            Priority: Major
>         Attachments: selectfs-issue.zip
>
>
> Invoking jCas.select(Annotation.class).coveredBy(annotation), where annotation is a direct subtype of Annotation, does not return all expected annotations when compared to JCasUtil.selectCovered. In the attached unit test all annotations that have the exact same bounds as annotation are not selected, only those that are completely enclosed get selected (begin > annotation.getBegin() and end < annotation.getEnd()). JCasUtil.selectCovered includes the missing annotations. Switching type priorities on didn't make a difference, and we don't use type priorities for the moment, so we rather avoid this.
> [^selectfs-issue.zip]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)