Hi Mario,
Am 13.10.2015 um 12:17 schrieb Mario Gazzo:
> Hi Peter,
>
> Thank you for answering. I fully understand that you may both be busy and
> that systems can come in between sometimes. I am subscribing to the user list
> though.
>
> Regarding your question. There is only a single MatchedRegexAnnotation in
> that example, which is the one that gets assigned to the variable. There a
> two variables in the other example I send but they should reference two
> different annotations but the CREATE method ends up assigning the same value
> to the features. All the issues I had so far of this type involve the CREATE
> method, which sometimes appears erratic about when and how it captures
> variables and types.
I guess that CREATE combined with a type variable is not the way you may
want to go. A type variable just stores a type, not an annotation. This
type is then used to search for annotations by the action.
> When you say "the scope of the match of the rule element" then I like to
> understand how you define scope in the different cases. E.g. is a variable
> defined in the “global" script space always visible also within BLOCK
> statements? Are all matches of different rule elements within a BLOCK in the
> same scope? Is there a clear difference between scope and any matched
> annotation context since it seems that variables can be local when declared
> in a BLOCK but are they available just because I match the same area in
> another BLOCK?
Yes, sorry, my answer was not accurate. The scope of variables is global
in general with some exceptions for blocks. It should be possible to
defined variables with the same identifier in the different block
resulting in something like overriding (at least this "should" work. I
haven't used it for year and there are no unit tests).
Therefore, each apply/execution of the action for each match of the rule
assigns the value of the variable anew. After the rule, the current
value of the variable was set by the last rule match.
With "the scope of the match of the rule element" I meant the actual
text match/position of the rule element given by the "matching condition".
In the last rule of the first mail, this would be the text position of
each SomeOtherMatch Annotation. The CREATE annotation searched for
annotation of the type specified by the variables within this window.
Thus, it does not make a difference if you use a variable, since it only
contains a type and not the intended annotation.
I have similar problems these days, and thus there will be more support
for theses use cases in UIMA Ruta 2.4.0 (I hope).
I will post a new mail with some explanations how I solve my use cases
right now. Maybe that would solve also your problems. Let me know if
not. Then, we will find another solution next week.
Best,
Peter
>
> I would ideally like to create small executable examples that can reproduce
> my problems but I don’t think I get the time this week anymore. I will keep
> my line open though and answer any questions you might have ASAP.
>
> Cheers
> Mario
>
>
>> On 13 Oct 2015, at 11:12 , Peter Klügl <peter.klu...@averbis.com> wrote:
>>
>> Hi,
>>
>> sorry for the delayed response. I received your mail just yesterday.
>> Maybe your mail needed to be moderated. Did you subscribe to the user list?
>>
>> Here's a first short answer. I will try to look into it in more details
>> if this does not help:
>>
>> The CREATE action searches for annotations (that should be assigned to a
>> feature) within the scope of the match of the rule element.
>>
>> Is there an annotation of the type MatchedRegexAnnotation within the
>> offsets of the annotation of the type SomeOtherMatch? ... e.g., is
>> SomeOtherMatch overlapping UniqueMatch?
>>
>> Maybe CREATE is not the correct action for you. Unfortunately, for
>> filling feature for distant annotations there is currently only the
>> GATHER action. This will hopefully change with ruta 2.4.0.
>>
>> I will try to find the time to take a look at your second mail later
>> this day (or tomorrow).
>>
>> Best,
>>
>> Peter
>>
>>
>> Am 09.10.2015 um 15:41 schrieb Mario Juric:
>>> Hi,
>>>
>>> I have a annotation type variable that I am assigning a value in a
>>> statement block and then use that value in match rule to set the attribute
>>> in a new annotation like this:
>>>
>>> Type myvar;
>>>
>>> BLOCK(ForEach) UniqueMatch{} { // Capturing unique scope with this
>>> “Some (\\w+) Regex" -> 1 = MatchedRegexAnnotation;
>>> MatchedRegexAnnotation { -> ASSIGN(myvar, MatchedRegexAnnotation)};
>>> }
>>>
>>> SomeOtherMatch{} {
>>> -> CREATE(Markup, “myprop” = myvar)
>>> };
>>>
>>> The “myprop” attribute never gets a value even though the
>>> MatchedRegexAnnotation is created. A completely analog implementation
>>> appears to work flawlessly in another context but not in the current.
>>>
>>> I am in the dark about this and my Ruta skills are sill infant so any idea
>>> to what could be the problem is much appreciated.
>>>
>>> Cheers
>>> Mario
