uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Klügl <peter.klu...@averbis.com>
Subject Re: RUTA variable assignment problem
Date Wed, 14 Oct 2015 09:59:23 GMT
Hi,

Am 14.10.2015 um 11:50 schrieb Mario Gazzo:
> Thank you Peter,
>
> I appreciate the extensive explanation and the suggestions for a workaround in the other
mail you posted. It clarifies things quite a bit for me. I look forward to the new language
features though, any timeline for this yet?

I think I will have some time for Ruta development next week. There are
some bugs that need to be fixed first, but then I think I can implement
new features. This means that the first prototype may be ready soon (a
few weeks). The actual release will take more time depending on what
else will be including (and when that we be implemented). The plans are
that we see the 2.4.0 release still this year.

There is actually a real need for another bugfix release, but I plan to
skip it in favor of a faster 2.4.0 release.

Well, I was always too optimistic in the past... let's see when it will
really happen.


> I can share some insights on how we use Ruta in our setup, if you are interested and
it is useful for your development, but we could then also discuss how we can contribute where
it make sense to do so.

Of course! :-)

Best,

Peter


> Best,
> Mario
>
>> On 14 Oct 2015, at 09:36 , Peter Klügl <peter.kluegl@averbis.com> wrote:
>>
>> 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.kluegl@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


Mime
View raw message