Hi, I tried enabling type priorities, but not surprisingly it didn’t make any difference when I also haven’t defined type priorities. If its true that the behaviour for coveredBy is that undefined without type priorities, so that it doesn’t include annotations with the same bounds, then it isn’t useful in our case, since we do not intent to specify type priorities, unless there is a use case for us.
Cheers Mario > On 3 Nov 2020, at 12.14, Richard Eckart de Castilho <r...@apache.org> wrote: > > External email – Do not click links or open attachments unless you recognize > the sender and know that the content is safe. > > > On 3. Nov 2020, at 12:10, Raffaella Ventaglio <raffaella.ventag...@celi.it> > wrote: >> >> Hi, unfortunately I can't try your example at the moment, but if >> `/JCasUtil.selectCovered/` behavior is similar to >> `AnnotationIndex.subiterator` behavior, than having an arbitrary ordering >> between your annotation types could impact the definition of "covered by". > > uimaFIT's JCasUtil.selectCovered ignores type priorities. It only takes into > account the offsets. > > Similarly, the UIMAv3 SelectFS by default does ignore type priorities (same > behavior as uimaFIT), but there is an option to enable type prios > (jcas.select(...).typePriority()...). > > -- Richard ________________________________ Disclaimer: This email and any files transmitted with it are confidential and directed solely for the use of the intended addressee or addressees and may contain information that is legally privileged, confidential, and exempt from disclosure. If you have received this email in error, please notify the sender by telephone, fax, or return email and immediately delete this email and any files transmitted along with it. Unintended recipients are not authorized to disclose, disseminate, distribute, copy or take any action in reliance on information contained in this email and/or any files attached thereto, in any manner other than to notify the sender; any unauthorized use is subject to legal prosecution.
