Re: RUTA variable assignment problem

[Peter Klügl]

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

Re: RUTA variable assignment problem

[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 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ügl  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  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 

Re: RUTA variable assignment problem

[Peter Klügl]

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

Re: RUTA variable assignment problem

[Peter Klügl]

Hi,

I think this is the same problem. The CREATE action just searches in its
match context. I will answer the context question is the other mail.

Best,

Peter

Am 11.10.2015 um 16:21 schrieb Mario Juric:
> I am still struggling with the use of variables in some CREATE statements. 
> The features do not always have the expected values after CREATE. Let me give 
> another more concrete example:
>
> TYPE pmcIdentifier;
> BLOCK(ForEach) IdentifierAnnotation.propertyName=="PMC"{} { // Just capturing 
> scope
> IdentifierAnnotation.propertyName=="PMC" { -> ASSIGN(pmcIdentifier, 
> IdentifierAnnotation), LOG(pmcIdentifier.ct)};
> }
>
> TYPE doiIdentifier;
> BLOCK(ForEach) IdentifierAnnotation.propertyName=="DOI"{} { // Just capturing 
> scope
> IdentifierAnnotation.propertyName=="DOI" { -> ASSIGN(doiIdentifier, 
> IdentifierAnnotation), LOG(doiIdentifier.ct)};
> }
>
> BLOCK(ForEach) XMLTagAnnotation.path=="article/front/article-meta"{} {
> XMLTagAnnotation.name=="article-meta" {
> -> CREATE(
> DocumentInfoAnnotation,
> “id" = pmcIdentifier,
> "doi" = doiIdentifier
> )
> };
> }
>
> The IdentifierAnnotation annotations have successfully been created in 
> statements not shown here, which is also evident from a CAS inspection, and 
> the LOG actions output the expected strings, but when I reference the 
> variables in the CREATE action then the id and doi features of the 
> DocumentInfoAnnotation end up pointing to the same identifier (pmc in the 
> above example). Its puzzling me how this can happen.
>
>> On 09 Oct 2015, at 15:41 , Mario Juric  wrote:
>>
>> 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

Re: RUTA variable assignment problem

[Peter Klügl]

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

Re: RUTA variable assignment problem

[Mario Juric]

I am still struggling with the use of variables in some CREATE statements. The 
features do not always have the expected values after CREATE. Let me give 
another more concrete example:

TYPE pmcIdentifier;
BLOCK(ForEach) IdentifierAnnotation.propertyName=="PMC"{} { // Just capturing 
scope
IdentifierAnnotation.propertyName=="PMC" { -> ASSIGN(pmcIdentifier, 
IdentifierAnnotation), LOG(pmcIdentifier.ct)};
}

TYPE doiIdentifier;
BLOCK(ForEach) IdentifierAnnotation.propertyName=="DOI"{} { // Just capturing 
scope
IdentifierAnnotation.propertyName=="DOI" { -> ASSIGN(doiIdentifier, 
IdentifierAnnotation), LOG(doiIdentifier.ct)};
}

BLOCK(ForEach) XMLTagAnnotation.path=="article/front/article-meta"{} {
XMLTagAnnotation.name=="article-meta" {
-> CREATE(
DocumentInfoAnnotation,
“id" = pmcIdentifier,
"doi" = doiIdentifier
)
};
}

The IdentifierAnnotation annotations have successfully been created in 
statements not shown here, which is also evident from a CAS inspection, and the 
LOG actions output the expected strings, but when I reference the variables in 
the CREATE action then the id and doi features of the DocumentInfoAnnotation 
end up pointing to the same identifier (pmc in the above example). Its puzzling 
me how this can happen.

> On 09 Oct 2015, at 15:41 , Mario Juric  wrote:
> 
> 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