Mailing-List: contact user-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@uima.apache.org
Subject: Re: UIMA Ruta use of features in a block statement
To: user@uima.apache.org
References: <2146449917.2945085.1496151331791.JavaMail.zimbra@scai.fraunhofer.de>
 <1dec92a8-13a0-beb4-bc30-3f056227d693@averbis.com>
 <1928343073.2947554.1496155059954.JavaMail.zimbra@scai.fraunhofer.de>
 <eeb44e5c-fe00-ad76-7553-de0cf0858a68@gmail.com>
 <2baef45a-0269-af9a-6fb1-48f8af8d992f@scai.fraunhofer.de>
From: =?UTF-8?Q?Peter_Kl=c3=bcgl?= <peter.kluegl@averbis.com>
Message-ID: <b911a044-d96f-2f12-f3ee-4201fe1b7fbe@averbis.com>
Date: Wed, 31 May 2017 09:59:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <2baef45a-0269-af9a-6fb1-48f8af8d992f@scai.fraunhofer.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 31 May 2017 07:59:14 -0000

Hi,


Am 30.05.2017 um 19:35 schrieb Sumit Madan:
>
> We were not able to access the annotation within the BLOCK.
>
> ###
> STRING s;
> BOOLEAN a ;
>
> // This is not working for us:
> BLOCK(forEACH) Lemma{}{
>     Lemma{->MATCHEDTEXT(s), ASSIGN(a,contains(s,"er"))};
>     Lemma{a ->Test1};
> }
>
> // This is working:
> BLOCK(forEACH) Lemma{}{
>     W{->MATCHEDTEXT(s), ASSIGN(a,contains(s,"er"))};
>     W{a ->Test2};
> }
>
> // This is also working:
> BLOCK(forEACH) Lemma{}{
> Document{->MATCHEDTEXT(s), ASSIGN(a,contains(s,"er"))};
> Document{a ->Test3};
> }
> ###
>

All three examples should work. Which ruta version do you use? It looks
like a bug.


>>
>>> Or is the block statement not needed at all?
>> Yes, they are not need at all, also not in similar use cases. If you
>> have several conditions with separate actions, you can increase the
>> speed using the FOREACH block.
>
> Alright, that makes sense.
>
>>
>>>   I used it because I found it in the user guideline in relation to
>>> NER-task:
>>>
>>> STRING s;
>>> BOOLEAN a ;
>>> BLOCK(forEACH) W{}{
>>>      W{->MATCHEDTEXT(s), ASSIGN(a,contains(s,"er"))};
>>>      W{a ->Test};
>>> }
>>> So, what's the advantage of the block statement here?
>> There is no advantage. I assume that it was necessary when the string
>> function have been introduced. However, the language evolved quite a bit
>> since then. This example should just illustrate some usage of the
>> function. Now, you can also use the function as an implicit condition.
>> Thus, you do not need a separate rule after the assign action. Thus, you
>> do not need the block to restrict the window in order to restrict the
>> usage of the global variable (which is also not required). It's now a
>> really bad example...
>>
>> Now I would write it as:
>>
>> W{contains(W.ct, "er") -> Test};
>
> We weren't aware that we can use contains() as a condition too. I
> think the documentation [1] doesn't describe that String functions
> with return value boolean can be used as conditions. I think one can
> assume if you see the source code (public class
> ContainsBooleanFunction extends BooleanFunctionExpression) under [2].
>
> [1] https://uima.apache.org/d/ruta-current/tools.ruta.book.html
> [2]:
> https://github.com/apache/uima-ruta/blob/trunk/ruta-core-ext/src/main/java/org/apache/uima/ruta/string/bool/ContainsBooleanFunction.java
>

Thank, I'll extend the documentation.


>>
>>> And one other question:
>>> We implemented Ruta into the UIMA pipeline, but in the debug mode,
>>> the ruta views "matched rules", "applied rules", "failed rules" etc.
>>> are all empty.
>>> How can we fix this?
>> Can you give me more information? Did you directly launch the ruta
>> script in a ruta debug launch configuration or did you include the AE in
>> a pipeline and launch that in a java debug launch config?
>
> We integrated the AE in our pipeline as we have our own type system.
> The steps we took to integrate Ruta in our environment:
> 1. Read the BasicEngine.xml as AnalysisEngineDescription.
> 2. Modify it and add the merged typesystem (Ruta typesystem +ours)
> 3. Modify some  parameters (such as extensions, debugging, statistics)
> 4. Write the modified AnalysisEngineDescription as a temporary file
> 5. Create a new aggregate AE (AAED.xml) with a different view name
> (sofaName) and use the temporary file as the AnalysisEngine
> (descriptorLocation)
> 6. Produce AE, process CAS and destroy AE
>
> All these steps are included in a apply() method, which is very
> similar to Ruta::apply(CAS cas, String script, Map<String, Object>
> parameters). We just call our apply() method in our UIMA analysis
> engines if we need to extract information with Ruta.
>
>> In general,
>> you need to set the two debug config parameters of the RutaEngine to
>> true in order to add debug information to the CAS: DEBUG and
>> DEBUG_WITH_MATCHES
>
> They are activated and the CAS contains the debugging information but
> still the views are all empty. Do we have to do something else to fill
> the views as we are not in the workbench?
>

Hmm, I do not know, this sounds all correct. Did you switch the CAS view
in the CAS Editor?


Best,

Peter