Mailing-List: contact user-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@uima.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: RUTA variable assignment problem
From: Mario Gazzo <mario.gazzo@gmail.com>
In-Reply-To: <561E060B.5060908@averbis.com>
Date: Wed, 14 Oct 2015 11:50:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <037987E5-ABB8-400C-AE14-CFC77627DD5A@gmail.com>
References: <1C21AED0-4FE9-45C5-8303-DE602C6CABB4@gmail.com>
 <561CCB0C.1020308@averbis.com>
 <475FC3CC-BDCD-40A9-84A4-6D0940ADA017@gmail.com>
 <561E060B.5060908@averbis.com>
To: user@uima.apache.org

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 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.

Best,
Mario

> On 14 Oct 2015, at 09:36 , Peter Kl=C3=BCgl <peter.kluegl@averbis.com> =
wrote:
>=20
> Hi Mario,
>=20
> Am 13.10.2015 um 12:17 schrieb Mario Gazzo:
>> Hi Peter,
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
>> 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 =E2=80=9Cglobal" 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?
>=20
> 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).
>=20
> 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.
>=20
> 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".
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> Best,
>=20
> Peter
>=20
>=20
>>=20
>> I would ideally like to create small executable examples that can =
reproduce my problems but I don=E2=80=99t think I get the time this week =
anymore. I will keep my line open though and answer any questions you =
might have ASAP.
>>=20
>> Cheers
>> Mario
>>=20
>>=20
>>> On 13 Oct 2015, at 11:12 , Peter Kl=C3=BCgl =
<peter.kluegl@averbis.com> wrote:
>>>=20
>>> Hi,
>>>=20
>>> 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?
>>>=20
>>> Here's a first short answer. I will try to look into it in more =
details
>>> if this does not help:
>>>=20
>>> The CREATE action searches for annotations (that should be assigned =
to a
>>> feature) within the scope of the match of the rule element.
>>>=20
>>> Is there an annotation of the type MatchedRegexAnnotation within the
>>> offsets of the annotation of the type SomeOtherMatch? ... e.g., is
>>> SomeOtherMatch overlapping UniqueMatch?
>>>=20
>>> 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.
>>>=20
>>> I will try to find the time to take a look at your second mail later
>>> this day (or tomorrow).
>>>=20
>>> Best,
>>>=20
>>> Peter
>>>=20
>>>=20
>>> Am 09.10.2015 um 15:41 schrieb Mario Juric:
>>>> Hi,
>>>>=20
>>>> 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:
>>>>=20
>>>> Type myvar;
>>>>=20
>>>> BLOCK(ForEach) UniqueMatch{} { // Capturing unique scope with this
>>>>   =E2=80=9CSome (\\w+) Regex" -> 1 =3D MatchedRegexAnnotation;
>>>>   MatchedRegexAnnotation { -> ASSIGN(myvar, =
MatchedRegexAnnotation)};
>>>> }
>>>>=20
>>>> SomeOtherMatch{} {
>>>> 	-> CREATE(Markup, =E2=80=9Cmyprop=E2=80=9D =3D myvar)
>>>> };
>>>>=20
>>>> The =E2=80=9Cmyprop=E2=80=9D 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Cheers
>>>> Mario
>=20