uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Juric ...@unsilo.com>
Subject Re: Problem matching adjacent annotations using Ruta
Date Mon, 14 Mar 2016 14:36:37 GMT
Hi Peter,

Seems we uncovered the problem. It is not directly related to Ruta. We construct our view
by mapping content from another view and for the affected documents we insert some text in
the same process. We messed up in the mapping process and accidentally mapped some ruta basic
annotations created in the previous view to the new view. This caused the Ruta problems when
we applied another set of Ruta rules to the new view.

Thanks for the support but we should be all good now.

Regarding the visibility I also think it might be a good idea to address this sometimes in
future but it was not related to this problem. All our fault :)

Cheers
Mario







> On 14 Mar 2016, at 15:17 , Peter Klügl <peter.kluegl@averbis.com> wrote:
> 
> hmm, sounds like a bug. Can you add SPACE to the retained types:
> 
> RETAINTYPE(WS, SPACE, BREAK);
> This should not change anything, but...
> 
> Why did A PERIOD SPACE not match?
> 
> Do have a have a reproducible example?
> 
> I promise that I will do something about the visiblity in the next releses.
> 
> Best,
> 
> Peter
> 
> Am 14.03.2016 um 14:33 schrieb Mario Juric:
>> Hi,
>> 
>> We try to do a simple match on two adjacent annotations but for some reason it dosen’t
always work. The rule looks like this:
>> 
>> A B { -> CREATE(C, 2, "prop"="val")};
>> 
>> This work for many documents but not for all. Looking at a failed example document
we can see that B starts exactly where A stops i.e. a.end == b.begin. Yet, the rule is never
fired. Its a view with text content, A and B are our own custom annotation types, there are
no invisible characters or markup in these particular cases and we set RETAINTYPE(WS, BREAK).
>> 
>> B annotates a period followed by a singe space in these cases whereas A covers the
preceding sentence up to where B begins so I also tried to match on periods and spaces like
this:
>> 
>> A PERIOD SPACE { -> CREATE(C, 2, 3, "prop"="val")};
>> 
>> This didn’t change the outcome.
>> 
>> I appreciate any suggestions to help me find the cause.
>> 
>> 
>> Cheers,
>> Mario
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message