You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Mario Gazzo <ma...@gmail.com> on 2015/10/06 19:02:43 UTC
Support for UIMA arrays in Ruta
Hej Peter,
Does Ruta still not support UIMA arrays in version 2.3?
Found this post from May this year that says it isn’t supported in version 2.2.1:
https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
Couldn’t find anything about it in the latest Ruta docs either.
Cheers
Mario
Re: Support for UIMA arrays in Ruta
Posted by Mario Gazzo <ma...@gmail.com>.
Hi Peter,
Thank you for the feedback.
I have been trying to implement something with CREATE all weekend and it simply puzzles me how RUTA determines the visibility of variables and annotations when invoking CREATE (please also see one of my other posts on this mailing list). Its really frustrating me so maybe you could explain this logic from the following simplified example.
Lets assume I have an XML document with some tags that are annotated with a TAG type of annotation and each has a name feature. Let’s say the document contains three element types R, A and B, so that A and B are contained with R like this:
<R>
<A></A>
<B></B>
</R>
Lets just ignore any attributes and other content. Then I have the elements annotated with the TAG type and give its name property the name of the element and its span to cover start and end tag of the element. I have so far assumed that given any match rule on R then any CREATE action I apply can reference any annotations within the context of R, so if I create special annotations for A and B then I can at least reference those in a CREATE action within R like this (not validated syntax):
TAG.name == “A" { -> A};
TAG.name == “B" { -> B};
TAG.name == “R" { -> CREATE(R, “a” = A, “b” = B)};
I assume similar applies for BLOCK statements. However there seem to be cases where I cannot reference A or B e.g.
BLOCK(ForEach) TAG.name == “R” {} {
TAG.name == “A" { -> A};
TAG.name == “B" { -> CREATE(B, “a" = A)};
}
I assume A is not visible in the CREATE because A is not within the matched context of the TAG named "B" despite the context of the surrounding BLOCK. How would I then reference A when creating B?
I tried using variables but it seem that whatever they reference its only visible when its within the matched context of B. The odd thing is that sometimes I can get things to work with variables and sometimes I can’t. I have examples of the above where R being the matched context but variables simply don’t have the correct value even if they reference something within the matched context of R.
Hope you might be able to clarify how matched context restricts the visibility of annotations and variables and how I would establish cross references between annotations in different parts of a document using RUTA. I could implement specific analysis engines myself to do exactly what I want but I like to understand whether I can do some of this with RUTA.
Cheers
Mario
> On 11 Oct 2015, at 18:40 , Peter Klügl <pe...@averbis.com> wrote:
>
> Hi,
>
> Am 11.10.2015 um 16:54 schrieb Mario Gazzo:
>> I just mean a separated match context. I am not sure GATHER fits what I am trying to achieve but I can see what you mean. I am not sure how I would go about doing the match in my case but I am still learning how to get the most out of the existing RUTA features so I would have to think a little bit more about it.
>
> I use to say that if you have to think too long how to solve something with ruta rules, then ruta misses some language elements which should be added ASAP (or a rule-based approach is simply not suitable here).
>
> If you have questions how to solve something with ruta, just ask :-)
> This helps also me to learn about use cases and how to improve the language.
>
>
>> We can of course share any custom actions or similar components if they make sense for others to use as well. Much of what we implement is to some degree coupled to how we choose to do things but I can send you any custom actions if we create them.
>
> yes, maybe they are too custom, but maybe with some small modifications they are also useful for other users. There are some actions/conditions is ruta that are very special and I would bet that hardly anyone besides myself have ever used them. Their existence did not hurt yet I hope...
>
> Best,
>
> Peter
>
>
>> Cheers
>> Mario
>>
>>> On 11 Oct 2015, at 16:30 , Peter Klügl <pe...@averbis.com> wrote:
>>>
>>> Hi,
>>>
>>> what do you mean by document scope? A different sofa/CAS or just a separated match context?
>>>
>>> An additional action is always an option. In the second case, the GATHER action could maybe help. It was added to assign only specific annotations to the features. However, you would still need to match on them.
>>>
>>> btw, contributions of new actions/conditions and functions are always wlecome :-)
>>>
>>> Best,
>>>
>>> Peter
>>>
>>> Am 11.10.2015 um 16:13 schrieb Mario Gazzo:
>>>> Thanks Peter,
>>>>
>>>> It works when I assign the FSArray the way you describe. However, I sometimes want to reference annotations across different document scopes. Therefore I try to capture some annotations in dedicated list variables so that I can reference them later in a CREATE action within some other document scope, but this is currently not possible as you state. I guess I would then have to implement my own action to do this.
>>>>
>>>> Cheers
>>>> Mario
>>>>
>>>>> On 11 Oct 2015, at 11:08 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> no, that's not possible. The CREATE accepts only type expressions, the GATHER integers and additionally integer lists (but these are referring to rule elements). A type list can only store type (expressions) and not the annotations themselves.
>>>>>
>>>>> You must know that these actions were added due to some requirements in specific use cases/projects. Then, we tried to make them more generic and useful in also other use cases. There are plans to replace the extensive usage of type expression with a new construct referring annotations more generally...
>>>>>
>>>>> Now to your problem :-)
>>>>>
>>>>> The CREATE action (and similar actions) checks the type of the feature and collects all annotations of the type specified by the type expression. In case of the CREATE action: if the feature expects a single annotation, then the first annotation within the matched context is assigned. If the feature allows multple annotations (FSArray), then all annotations of the specified type within the matched context are assigned.
>>>>>
>>>>> This means you need only to use the type of the FSArray in the CREATE action. The actual selection of the annotations is controlled of their types, e.g., you maybe need to create new annotations of derived types.
>>>>>
>>>>> Here a simple example (not tested):
>>>>> DECLARE Container (FSArray tokens);
>>>>> Sentence{-> CREATE(Container, "tokens" = Token)};
>>>>>
>>>>> Here, an annotation of type Container is created for each Sentence and all Token annotations within this sentence are assigned to the feature "tokens", which is an FSArray.
>>>>>
>>>>> I hope that helps :-)
>>>>>
>>>>> Best,
>>>>>
>>>>> Peter
>>>>>
>>>>> Am 10.10.2015 um 23:00 schrieb Mario Gazzo:
>>>>>> Can I assign a typelist to a FSArray feature in a CREATE action?
>>>>>>
>>>>>> I tried to read some annotations into a typelist variable using GETLIST and then assign it to a FSArray feature in a CREATE statement but it doesn’t seem to work. How does one do this otherwise?
>>>>>>
>>>>>> Cheers,
>>>>>> Mario
>>>>>>
>>>>>>> On 06 Oct 2015, at 20:28 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>>>
>>>>>>> The most important actions are CREATE and GATHER. There are also some others like FILL or SETFEATURE.
>>>>>>>
>>>>>>> The ASSIGN action works only for variables.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>> Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
>>>>>>>> That’s completely understandable, Peter.
>>>>>>>>
>>>>>>>> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Mario
>>>>>>>>
>>>>>>>>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Mario,
>>>>>>>>>
>>>>>>>>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>>>>>>>>
>>>>>>>>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>>>>>>>>
>>>>>>>>> Any help is welcome :-)
>>>>>>>>>
>>>>>>>>> (however, I must admit that this is trickier and more work than it looks like)
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>>>>>>>>> Hej Peter,
>>>>>>>>>>
>>>>>>>>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>>>>>>>>
>>>>>>>>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>>>>>>>>
>>>>>>>>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>>>>>>>>
>>>>>>>>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> Mario
>
Re: Support for UIMA arrays in Ruta
Posted by Peter Klügl <pe...@averbis.com>.
Hi,
Am 11.10.2015 um 16:54 schrieb Mario Gazzo:
> I just mean a separated match context. I am not sure GATHER fits what I am trying to achieve but I can see what you mean. I am not sure how I would go about doing the match in my case but I am still learning how to get the most out of the existing RUTA features so I would have to think a little bit more about it.
I use to say that if you have to think too long how to solve something
with ruta rules, then ruta misses some language elements which should be
added ASAP (or a rule-based approach is simply not suitable here).
If you have questions how to solve something with ruta, just ask :-)
This helps also me to learn about use cases and how to improve the language.
> We can of course share any custom actions or similar components if they make sense for others to use as well. Much of what we implement is to some degree coupled to how we choose to do things but I can send you any custom actions if we create them.
yes, maybe they are too custom, but maybe with some small modifications
they are also useful for other users. There are some actions/conditions
is ruta that are very special and I would bet that hardly anyone besides
myself have ever used them. Their existence did not hurt yet I hope...
Best,
Peter
> Cheers
> Mario
>
>> On 11 Oct 2015, at 16:30 , Peter Klügl <pe...@averbis.com> wrote:
>>
>> Hi,
>>
>> what do you mean by document scope? A different sofa/CAS or just a separated match context?
>>
>> An additional action is always an option. In the second case, the GATHER action could maybe help. It was added to assign only specific annotations to the features. However, you would still need to match on them.
>>
>> btw, contributions of new actions/conditions and functions are always wlecome :-)
>>
>> Best,
>>
>> Peter
>>
>> Am 11.10.2015 um 16:13 schrieb Mario Gazzo:
>>> Thanks Peter,
>>>
>>> It works when I assign the FSArray the way you describe. However, I sometimes want to reference annotations across different document scopes. Therefore I try to capture some annotations in dedicated list variables so that I can reference them later in a CREATE action within some other document scope, but this is currently not possible as you state. I guess I would then have to implement my own action to do this.
>>>
>>> Cheers
>>> Mario
>>>
>>>> On 11 Oct 2015, at 11:08 , Peter Klügl <pe...@averbis.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> no, that's not possible. The CREATE accepts only type expressions, the GATHER integers and additionally integer lists (but these are referring to rule elements). A type list can only store type (expressions) and not the annotations themselves.
>>>>
>>>> You must know that these actions were added due to some requirements in specific use cases/projects. Then, we tried to make them more generic and useful in also other use cases. There are plans to replace the extensive usage of type expression with a new construct referring annotations more generally...
>>>>
>>>> Now to your problem :-)
>>>>
>>>> The CREATE action (and similar actions) checks the type of the feature and collects all annotations of the type specified by the type expression. In case of the CREATE action: if the feature expects a single annotation, then the first annotation within the matched context is assigned. If the feature allows multple annotations (FSArray), then all annotations of the specified type within the matched context are assigned.
>>>>
>>>> This means you need only to use the type of the FSArray in the CREATE action. The actual selection of the annotations is controlled of their types, e.g., you maybe need to create new annotations of derived types.
>>>>
>>>> Here a simple example (not tested):
>>>> DECLARE Container (FSArray tokens);
>>>> Sentence{-> CREATE(Container, "tokens" = Token)};
>>>>
>>>> Here, an annotation of type Container is created for each Sentence and all Token annotations within this sentence are assigned to the feature "tokens", which is an FSArray.
>>>>
>>>> I hope that helps :-)
>>>>
>>>> Best,
>>>>
>>>> Peter
>>>>
>>>> Am 10.10.2015 um 23:00 schrieb Mario Gazzo:
>>>>> Can I assign a typelist to a FSArray feature in a CREATE action?
>>>>>
>>>>> I tried to read some annotations into a typelist variable using GETLIST and then assign it to a FSArray feature in a CREATE statement but it doesn’t seem to work. How does one do this otherwise?
>>>>>
>>>>> Cheers,
>>>>> Mario
>>>>>
>>>>>> On 06 Oct 2015, at 20:28 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>>
>>>>>> The most important actions are CREATE and GATHER. There are also some others like FILL or SETFEATURE.
>>>>>>
>>>>>> The ASSIGN action works only for variables.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
>>>>>>> That’s completely understandable, Peter.
>>>>>>>
>>>>>>> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>>>>>>>
>>>>>>> Cheers
>>>>>>> Mario
>>>>>>>
>>>>>>>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>>>>
>>>>>>>> Hi Mario,
>>>>>>>>
>>>>>>>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>>>>>>>
>>>>>>>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>>>>>>>
>>>>>>>> Any help is welcome :-)
>>>>>>>>
>>>>>>>> (however, I must admit that this is trickier and more work than it looks like)
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>>>>>>>> Hej Peter,
>>>>>>>>>
>>>>>>>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>>>>>>>
>>>>>>>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>>>>>>>
>>>>>>>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>>>>>>>
>>>>>>>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Mario
Re: Support for UIMA arrays in Ruta
Posted by Mario Gazzo <ma...@gmail.com>.
I just mean a separated match context. I am not sure GATHER fits what I am trying to achieve but I can see what you mean. I am not sure how I would go about doing the match in my case but I am still learning how to get the most out of the existing RUTA features so I would have to think a little bit more about it.
We can of course share any custom actions or similar components if they make sense for others to use as well. Much of what we implement is to some degree coupled to how we choose to do things but I can send you any custom actions if we create them.
Cheers
Mario
> On 11 Oct 2015, at 16:30 , Peter Klügl <pe...@averbis.com> wrote:
>
> Hi,
>
> what do you mean by document scope? A different sofa/CAS or just a separated match context?
>
> An additional action is always an option. In the second case, the GATHER action could maybe help. It was added to assign only specific annotations to the features. However, you would still need to match on them.
>
> btw, contributions of new actions/conditions and functions are always wlecome :-)
>
> Best,
>
> Peter
>
> Am 11.10.2015 um 16:13 schrieb Mario Gazzo:
>> Thanks Peter,
>>
>> It works when I assign the FSArray the way you describe. However, I sometimes want to reference annotations across different document scopes. Therefore I try to capture some annotations in dedicated list variables so that I can reference them later in a CREATE action within some other document scope, but this is currently not possible as you state. I guess I would then have to implement my own action to do this.
>>
>> Cheers
>> Mario
>>
>>> On 11 Oct 2015, at 11:08 , Peter Klügl <pe...@averbis.com> wrote:
>>>
>>> Hi,
>>>
>>> no, that's not possible. The CREATE accepts only type expressions, the GATHER integers and additionally integer lists (but these are referring to rule elements). A type list can only store type (expressions) and not the annotations themselves.
>>>
>>> You must know that these actions were added due to some requirements in specific use cases/projects. Then, we tried to make them more generic and useful in also other use cases. There are plans to replace the extensive usage of type expression with a new construct referring annotations more generally...
>>>
>>> Now to your problem :-)
>>>
>>> The CREATE action (and similar actions) checks the type of the feature and collects all annotations of the type specified by the type expression. In case of the CREATE action: if the feature expects a single annotation, then the first annotation within the matched context is assigned. If the feature allows multple annotations (FSArray), then all annotations of the specified type within the matched context are assigned.
>>>
>>> This means you need only to use the type of the FSArray in the CREATE action. The actual selection of the annotations is controlled of their types, e.g., you maybe need to create new annotations of derived types.
>>>
>>> Here a simple example (not tested):
>>> DECLARE Container (FSArray tokens);
>>> Sentence{-> CREATE(Container, "tokens" = Token)};
>>>
>>> Here, an annotation of type Container is created for each Sentence and all Token annotations within this sentence are assigned to the feature "tokens", which is an FSArray.
>>>
>>> I hope that helps :-)
>>>
>>> Best,
>>>
>>> Peter
>>>
>>> Am 10.10.2015 um 23:00 schrieb Mario Gazzo:
>>>> Can I assign a typelist to a FSArray feature in a CREATE action?
>>>>
>>>> I tried to read some annotations into a typelist variable using GETLIST and then assign it to a FSArray feature in a CREATE statement but it doesn’t seem to work. How does one do this otherwise?
>>>>
>>>> Cheers,
>>>> Mario
>>>>
>>>>> On 06 Oct 2015, at 20:28 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>
>>>>> The most important actions are CREATE and GATHER. There are also some others like FILL or SETFEATURE.
>>>>>
>>>>> The ASSIGN action works only for variables.
>>>>>
>>>>> Best,
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
>>>>>> That’s completely understandable, Peter.
>>>>>>
>>>>>> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>>>>>>
>>>>>> Cheers
>>>>>> Mario
>>>>>>
>>>>>>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>>>
>>>>>>> Hi Mario,
>>>>>>>
>>>>>>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>>>>>>
>>>>>>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>>>>>>
>>>>>>> Any help is welcome :-)
>>>>>>>
>>>>>>> (however, I must admit that this is trickier and more work than it looks like)
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>>>>>>> Hej Peter,
>>>>>>>>
>>>>>>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>>>>>>
>>>>>>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>>>>>>
>>>>>>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>>>>>>
>>>>>>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Mario
>
Re: Support for UIMA arrays in Ruta
Posted by Peter Klügl <pe...@averbis.com>.
Hi,
what do you mean by document scope? A different sofa/CAS or just a
separated match context?
An additional action is always an option. In the second case, the GATHER
action could maybe help. It was added to assign only specific
annotations to the features. However, you would still need to match on them.
btw, contributions of new actions/conditions and functions are always
wlecome :-)
Best,
Peter
Am 11.10.2015 um 16:13 schrieb Mario Gazzo:
> Thanks Peter,
>
> It works when I assign the FSArray the way you describe. However, I sometimes want to reference annotations across different document scopes. Therefore I try to capture some annotations in dedicated list variables so that I can reference them later in a CREATE action within some other document scope, but this is currently not possible as you state. I guess I would then have to implement my own action to do this.
>
> Cheers
> Mario
>
>> On 11 Oct 2015, at 11:08 , Peter Klügl <pe...@averbis.com> wrote:
>>
>> Hi,
>>
>> no, that's not possible. The CREATE accepts only type expressions, the GATHER integers and additionally integer lists (but these are referring to rule elements). A type list can only store type (expressions) and not the annotations themselves.
>>
>> You must know that these actions were added due to some requirements in specific use cases/projects. Then, we tried to make them more generic and useful in also other use cases. There are plans to replace the extensive usage of type expression with a new construct referring annotations more generally...
>>
>> Now to your problem :-)
>>
>> The CREATE action (and similar actions) checks the type of the feature and collects all annotations of the type specified by the type expression. In case of the CREATE action: if the feature expects a single annotation, then the first annotation within the matched context is assigned. If the feature allows multple annotations (FSArray), then all annotations of the specified type within the matched context are assigned.
>>
>> This means you need only to use the type of the FSArray in the CREATE action. The actual selection of the annotations is controlled of their types, e.g., you maybe need to create new annotations of derived types.
>>
>> Here a simple example (not tested):
>> DECLARE Container (FSArray tokens);
>> Sentence{-> CREATE(Container, "tokens" = Token)};
>>
>> Here, an annotation of type Container is created for each Sentence and all Token annotations within this sentence are assigned to the feature "tokens", which is an FSArray.
>>
>> I hope that helps :-)
>>
>> Best,
>>
>> Peter
>>
>> Am 10.10.2015 um 23:00 schrieb Mario Gazzo:
>>> Can I assign a typelist to a FSArray feature in a CREATE action?
>>>
>>> I tried to read some annotations into a typelist variable using GETLIST and then assign it to a FSArray feature in a CREATE statement but it doesn’t seem to work. How does one do this otherwise?
>>>
>>> Cheers,
>>> Mario
>>>
>>>> On 06 Oct 2015, at 20:28 , Peter Klügl <pe...@averbis.com> wrote:
>>>>
>>>> The most important actions are CREATE and GATHER. There are also some others like FILL or SETFEATURE.
>>>>
>>>> The ASSIGN action works only for variables.
>>>>
>>>> Best,
>>>>
>>>> Peter
>>>>
>>>>
>>>> Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
>>>>> That’s completely understandable, Peter.
>>>>>
>>>>> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>>>>>
>>>>> Cheers
>>>>> Mario
>>>>>
>>>>>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>>
>>>>>> Hi Mario,
>>>>>>
>>>>>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>>>>>
>>>>>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>>>>>
>>>>>> Any help is welcome :-)
>>>>>>
>>>>>> (however, I must admit that this is trickier and more work than it looks like)
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>>>>>> Hej Peter,
>>>>>>>
>>>>>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>>>>>
>>>>>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>>>>>
>>>>>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>>>>>
>>>>>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Mario
Re: Support for UIMA arrays in Ruta
Posted by Mario Gazzo <ma...@gmail.com>.
Thanks Peter,
It works when I assign the FSArray the way you describe. However, I sometimes want to reference annotations across different document scopes. Therefore I try to capture some annotations in dedicated list variables so that I can reference them later in a CREATE action within some other document scope, but this is currently not possible as you state. I guess I would then have to implement my own action to do this.
Cheers
Mario
> On 11 Oct 2015, at 11:08 , Peter Klügl <pe...@averbis.com> wrote:
>
> Hi,
>
> no, that's not possible. The CREATE accepts only type expressions, the GATHER integers and additionally integer lists (but these are referring to rule elements). A type list can only store type (expressions) and not the annotations themselves.
>
> You must know that these actions were added due to some requirements in specific use cases/projects. Then, we tried to make them more generic and useful in also other use cases. There are plans to replace the extensive usage of type expression with a new construct referring annotations more generally...
>
> Now to your problem :-)
>
> The CREATE action (and similar actions) checks the type of the feature and collects all annotations of the type specified by the type expression. In case of the CREATE action: if the feature expects a single annotation, then the first annotation within the matched context is assigned. If the feature allows multple annotations (FSArray), then all annotations of the specified type within the matched context are assigned.
>
> This means you need only to use the type of the FSArray in the CREATE action. The actual selection of the annotations is controlled of their types, e.g., you maybe need to create new annotations of derived types.
>
> Here a simple example (not tested):
> DECLARE Container (FSArray tokens);
> Sentence{-> CREATE(Container, "tokens" = Token)};
>
> Here, an annotation of type Container is created for each Sentence and all Token annotations within this sentence are assigned to the feature "tokens", which is an FSArray.
>
> I hope that helps :-)
>
> Best,
>
> Peter
>
> Am 10.10.2015 um 23:00 schrieb Mario Gazzo:
>> Can I assign a typelist to a FSArray feature in a CREATE action?
>>
>> I tried to read some annotations into a typelist variable using GETLIST and then assign it to a FSArray feature in a CREATE statement but it doesn’t seem to work. How does one do this otherwise?
>>
>> Cheers,
>> Mario
>>
>>> On 06 Oct 2015, at 20:28 , Peter Klügl <pe...@averbis.com> wrote:
>>>
>>> The most important actions are CREATE and GATHER. There are also some others like FILL or SETFEATURE.
>>>
>>> The ASSIGN action works only for variables.
>>>
>>> Best,
>>>
>>> Peter
>>>
>>>
>>> Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
>>>> That’s completely understandable, Peter.
>>>>
>>>> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>>>>
>>>> Cheers
>>>> Mario
>>>>
>>>>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>>>>
>>>>> Hi Mario,
>>>>>
>>>>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>>>>
>>>>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>>>>
>>>>> Any help is welcome :-)
>>>>>
>>>>> (however, I must admit that this is trickier and more work than it looks like)
>>>>>
>>>>> Best,
>>>>>
>>>>> Peter
>>>>>
>>>>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>>>>> Hej Peter,
>>>>>>
>>>>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>>>>
>>>>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>>>>
>>>>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>>>>
>>>>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>>>>
>>>>>> Cheers
>>>>>> Mario
>
Re: Support for UIMA arrays in Ruta
Posted by Peter Klügl <pe...@averbis.com>.
Hi,
no, that's not possible. The CREATE accepts only type expressions, the
GATHER integers and additionally integer lists (but these are referring
to rule elements). A type list can only store type (expressions) and not
the annotations themselves.
You must know that these actions were added due to some requirements in
specific use cases/projects. Then, we tried to make them more generic
and useful in also other use cases. There are plans to replace the
extensive usage of type expression with a new construct referring
annotations more generally...
Now to your problem :-)
The CREATE action (and similar actions) checks the type of the feature
and collects all annotations of the type specified by the type
expression. In case of the CREATE action: if the feature expects a
single annotation, then the first annotation within the matched context
is assigned. If the feature allows multple annotations (FSArray), then
all annotations of the specified type within the matched context are
assigned.
This means you need only to use the type of the FSArray in the CREATE
action. The actual selection of the annotations is controlled of their
types, e.g., you maybe need to create new annotations of derived types.
Here a simple example (not tested):
DECLARE Container (FSArray tokens);
Sentence{-> CREATE(Container, "tokens" = Token)};
Here, an annotation of type Container is created for each Sentence and
all Token annotations within this sentence are assigned to the feature
"tokens", which is an FSArray.
I hope that helps :-)
Best,
Peter
Am 10.10.2015 um 23:00 schrieb Mario Gazzo:
> Can I assign a typelist to a FSArray feature in a CREATE action?
>
> I tried to read some annotations into a typelist variable using GETLIST and then assign it to a FSArray feature in a CREATE statement but it doesn’t seem to work. How does one do this otherwise?
>
> Cheers,
> Mario
>
>> On 06 Oct 2015, at 20:28 , Peter Klügl <pe...@averbis.com> wrote:
>>
>> The most important actions are CREATE and GATHER. There are also some others like FILL or SETFEATURE.
>>
>> The ASSIGN action works only for variables.
>>
>> Best,
>>
>> Peter
>>
>>
>> Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
>>> That’s completely understandable, Peter.
>>>
>>> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>>>
>>> Cheers
>>> Mario
>>>
>>>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>>>
>>>> Hi Mario,
>>>>
>>>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>>>
>>>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>>>
>>>> Any help is welcome :-)
>>>>
>>>> (however, I must admit that this is trickier and more work than it looks like)
>>>>
>>>> Best,
>>>>
>>>> Peter
>>>>
>>>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>>>> Hej Peter,
>>>>>
>>>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>>>
>>>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>>>
>>>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>>>
>>>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>>>
>>>>> Cheers
>>>>> Mario
Re: Support for UIMA arrays in Ruta
Posted by Mario Gazzo <ma...@gmail.com>.
Can I assign a typelist to a FSArray feature in a CREATE action?
I tried to read some annotations into a typelist variable using GETLIST and then assign it to a FSArray feature in a CREATE statement but it doesn’t seem to work. How does one do this otherwise?
Cheers,
Mario
> On 06 Oct 2015, at 20:28 , Peter Klügl <pe...@averbis.com> wrote:
>
> The most important actions are CREATE and GATHER. There are also some others like FILL or SETFEATURE.
>
> The ASSIGN action works only for variables.
>
> Best,
>
> Peter
>
>
> Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
>> That’s completely understandable, Peter.
>>
>> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>>
>> Cheers
>> Mario
>>
>>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>>
>>> Hi Mario,
>>>
>>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>>
>>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>>
>>> Any help is welcome :-)
>>>
>>> (however, I must admit that this is trickier and more work than it looks like)
>>>
>>> Best,
>>>
>>> Peter
>>>
>>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>>> Hej Peter,
>>>>
>>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>>
>>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>>
>>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>>
>>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>>
>>>> Cheers
>>>> Mario
>
Re: Support for UIMA arrays in Ruta
Posted by Peter Klügl <pe...@averbis.com>.
The most important actions are CREATE and GATHER. There are also some
others like FILL or SETFEATURE.
The ASSIGN action works only for variables.
Best,
Peter
Am 06.10.2015 um 19:47 schrieb Mario Gazzo:
> That’s completely understandable, Peter.
>
> FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
>
> Cheers
> Mario
>
>> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>>
>> Hi Mario,
>>
>> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>>
>> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>>
>> Any help is welcome :-)
>>
>> (however, I must admit that this is trickier and more work than it looks like)
>>
>> Best,
>>
>> Peter
>>
>> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>>> Hej Peter,
>>>
>>> Does Ruta still not support UIMA arrays in version 2.3?
>>>
>>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>>
>>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>>
>>> Couldn’t find anything about it in the latest Ruta docs either.
>>>
>>> Cheers
>>> Mario
Re: Support for UIMA arrays in Ruta
Posted by Mario Gazzo <ma...@gmail.com>.
That’s completely understandable, Peter.
FSArray assignment might just do it for me at the moment. Could you point me to the special actions you are mentioning? Is it the Assign action?
Cheers
Mario
> On 06 Oct 2015, at 19:10 , Peter Klügl <pe...@averbis.com> wrote:
>
> Hi Mario,
>
> yes, sadly, it's true. Only the assignments to FSArrays using special actions is supported right now.
>
> I did not find the time to implement it for 2.3.0 or 2.3.1, but I really hope I can do it for 2.4.0.
>
> Any help is welcome :-)
>
> (however, I must admit that this is trickier and more work than it looks like)
>
> Best,
>
> Peter
>
> Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
>> Hej Peter,
>>
>> Does Ruta still not support UIMA arrays in version 2.3?
>>
>> Found this post from May this year that says it isn’t supported in version 2.2.1:
>>
>> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>>
>> Couldn’t find anything about it in the latest Ruta docs either.
>>
>> Cheers
>> Mario
>
Re: Support for UIMA arrays in Ruta
Posted by Peter Klügl <pe...@averbis.com>.
Hi Mario,
yes, sadly, it's true. Only the assignments to FSArrays using special
actions is supported right now.
I did not find the time to implement it for 2.3.0 or 2.3.1, but I really
hope I can do it for 2.4.0.
Any help is welcome :-)
(however, I must admit that this is trickier and more work than it looks
like)
Best,
Peter
Am 06.10.2015 um 19:02 schrieb Mario Gazzo:
> Hej Peter,
>
> Does Ruta still not support UIMA arrays in version 2.3?
>
> Found this post from May this year that says it isn’t supported in version 2.2.1:
>
> https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E <https://mail-archives.apache.org/mod_mbox/uima-user/201505.mbox/%3C5558A074.9090405@averbis.com%3E>
>
> Couldn’t find anything about it in the latest Ruta docs either.
>
> Cheers
> Mario