Return-Path: X-Original-To: apmail-uima-user-archive@www.apache.org Delivered-To: apmail-uima-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7E36218484 for ; Wed, 14 Oct 2015 07:36:07 +0000 (UTC) Received: (qmail 88803 invoked by uid 500); 14 Oct 2015 07:36:07 -0000 Delivered-To: apmail-uima-user-archive@uima.apache.org Received: (qmail 88750 invoked by uid 500); 14 Oct 2015 07:36:07 -0000 Mailing-List: contact user-help@uima.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@uima.apache.org Delivered-To: mailing list user@uima.apache.org Received: (qmail 88739 invoked by uid 99); 14 Oct 2015 07:36:06 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Oct 2015 07:36:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 8E4A01A299F for ; Wed, 14 Oct 2015 07:36:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id JS-bJCcvdJft for ; Wed, 14 Oct 2015 07:35:58 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 9405124E1C for ; Wed, 14 Oct 2015 07:35:58 +0000 (UTC) Received: from [192.168.11.108] ([132.230.176.14]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0MP3YZ-1ZgVQu3vx1-006P4S for ; Wed, 14 Oct 2015 09:35:52 +0200 Subject: Re: RUTA variable assignment problem To: user@uima.apache.org References: <1C21AED0-4FE9-45C5-8303-DE602C6CABB4@gmail.com> <561CCB0C.1020308@averbis.com> <475FC3CC-BDCD-40A9-84A4-6D0940ADA017@gmail.com> From: =?UTF-8?Q?Peter_Kl=c3=bcgl?= X-Enigmail-Draft-Status: N1110 Message-ID: <561E060B.5060908@averbis.com> Date: Wed, 14 Oct 2015 09:36:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <475FC3CC-BDCD-40A9-84A4-6D0940ADA017@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:4XQHjhuw6Nv0xx0puvpaezQp3JBvg72ChTNZRIGtvuuX7I9w33v N/Gjp1hh2Qubq8CiakFEBTVJvpnCGfELShdaf8Q+oT7EF5utx0c42DwZOUVMWaxx3bYqA0T yCTG7VVotFwE0cpLz9DAiXJxOAdtBmztFHHzQiKu78wk3Z7pv1MpoumIxBEiNQdNZ8FWgoc 1nbNj4zl/ymulxzjzWa2w== X-UI-Out-Filterresults: notjunk:1;V01:K0:XmeGbL6UWpI=:BUybfAVez86N+SU76jsAWE /HNazhLUDrnCHnUrm/shR8EqaSoTAJc7qaKHKeHNAGMYVx0OFeFmvmPwVdew342n8DHWLYeeW D5RsL7fDkzOpy12MixWFUmD0ALgIATOSWXc65WygGLIOf5o7WlJpR4fQoQ+15uvK8ritdS/VZ JTcJZisx/TwpmXNVbmkfl04DG+9qp9hoIrldQH0dtdYA6aa3mb14pZ8oyKlwozqmoYOoJUGhO G0GNHMYjIFAXkQkiJGsjPoSEjGa5fXgUXiqxJ0V+8Rx6fJ9nuNkyfRTs2fv63uc1Y4nYAlMsD we83DdnaNh6YTmOC2XRRN4IXF8hy4Nxs1bc8Umt0klnLvnzkGvgfdzJJqHtgGn9YBiz+nIvtW koLy6Z8tqVlUbcB7WI5QQfAggRrPTe+LLvORKpVnGtLWUX4XY3j/PylTMOHbcsbMdMaP+qEuc n+lSfutROpUOotzSzxv46qZZBVcu+ubQNJq79DiXP49+au0EHqiP8XxWlTNULy2WPHeFA6YsI eY+nUavSp55hRh8cfGJNjKelodY98CJCLSA0+HEOyGSOOmBbJrZvrtBWG3XASnybSHKov9nc2 LDpxyWpIFt8tji53kILr6o0S4dnug2v+AavXI+ZTQlENNUL5mwKzsm9p6kpKBnrGLgtBsDcf4 DZxAGnS2v15GG7ZL1R+vpFT2x3Ir8OwtiAh84zkICmpMX7fuTTd0A1hEbsFOJLESghunViTfz Tv9YNNNuWG/T9dal 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. >>> >>> Cheers >>> Mario