You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <re...@apache.org> on 2013/11/15 11:16:10 UTC
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional in ConceptMapper
So welcome Jens and Michael to the UIMA project :)
With direct access to the SVN now, it should be much easier to get in your
changes. No need to jump through patch-and-review loops all the time.
Cheers,
-- Richard
On 30.10.2013, at 13:03, Michael Tanenblatt <sl...@park-slope.net> wrote:
> Jens and Richard:
>
> I also have some changes to ConceptMapper that I’d like to put in. Namely:
>
> 1) Allow multiple matches in the dictionary: a term can appear multiple times in the dictionary, and each match in the corpus will be annotated for each of those multiple entries
> 2) Allow different resultant annotation types, based on a feature in dictionary entries: optionally specify a parameter in the AE descriptor that provides the name of a key in some or all dictionary entries, the value of which is the resulting annotation type when that entry is found in the corpus. If none is specified, the current method is used as default.
>
>
>
>
> On Oct 29, 2013, at 11:50 AM, Jens Grivolla (JIRA) <de...@uima.apache.org> wrote:
>
>>
>> [ https://issues.apache.org/jira/browse/UIMA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808106#comment-13808106 ]
>>
>> Jens Grivolla commented on UIMA-2387:
>> -------------------------------------
>>
>> I just saw that trunk has changed since my patch, doing the same upgrades to JCasAnnotator_ImplBase instead of TextAnnotator that I have since done independently. This should make integration of UIMA-2387 easier, since I can rebase it on top of the current trunk to get a working AE instead of having to do it in two steps.
>>
>>> ResultingAnnotationName not optional in ConceptMapper
>>> -----------------------------------------------------
>>>
>>> Key: UIMA-2387
>>> URL: https://issues.apache.org/jira/browse/UIMA-2387
>>> Project: UIMA
>>> Issue Type: Bug
>>> Components: addons, Sandbox-ConceptMapper
>>> Affects Versions: 2.3.1Addons
>>> Reporter: Jens Grivolla
>>> Priority: Minor
>>> Attachments: UIMA-2387.patch
>>>
>>>
>>> Contrary to the documentation, the ResultingAnnotationName is not optional in the ConceptMapper descriptor. In our use case we only want to write back information to the original token, without creating a new annotation. Instead of treating this as a documentation bug it is therefore better to fix the code.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.1#6144)
>
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional
in ConceptMapper
Posted by Jens Grivolla <j+...@grivolla.net>.
On Github you would just fork the project and publish your fork for
everyone to see. You can then see the diffs through a very nice web
interface, or add the fork as additional branches to your local copy.
For non-git users the code can also be downloaded as a zip file. The
nice thing is that a personal fork is just as good as an official
branch, basically the only difference is that is is marked as belonging
to a different user.
This is a light-weight workflow for trying things out without polluting
the official (svn) repository. Of course, if it gets to the point that
non-git users would collaborate directly on the code, the changes would
need to be pushed back to svn. In that case I think I would create a
branch in SVN and rebase the git branch on top of it (and commit the
result to SVN of course).
My version of ConceptMapper is only very lightly uimaFITted so far
(basically the bare minimum to make it extend
org.apache.uima.fit.component.JCasAnnotator_ImplBase instead of the
original org.apache.uima.analysis_engine.annotator.TextAnnotator), with
no changes to parameter and resource handling, but I'd like to change
that. It especially needs some reasonable default values, so far almost
all parameters are mandatory.
-- Jens
On 11/28/2013 08:53 PM, Richard Eckart de Castilho wrote:
> According to the Apache documentation, the git mirrors are read only. So you cannot commit to them. If you do a git branch, how could I cooperate with you on the branch? And how could other non-git users (Marshall?) conveniently review the changes and compare them to the trunk version?
>
> -- Richard
>
> On 28.11.2013, at 17:45, Jens Grivolla <j+...@grivolla.net> wrote:
>
>> Since I'm pretty busy right now (should get better in a few days), I was waiting to see if I could use GIT branches for this instead of doing it directly in SVN.
>>
>> I have no idea how long it will take to get the git mirror, though, so I might do some tests before we get it.
>>
>> -- Jens
>>
>> On 11/28/2013 06:50 PM, Richard Eckart de Castilho wrote:
>>> @Jens: as far as I understood, you already have a uimaFITted version of the ConceptMapper. Care creating a (svn-)branch of that add-on and applying your patch there?
>>>
>>> Cheers,
>
>
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional in ConceptMapper
Posted by Richard Eckart de Castilho <re...@apache.org>.
According to the Apache documentation, the git mirrors are read only. So you cannot commit to them. If you do a git branch, how could I cooperate with you on the branch? And how could other non-git users (Marshall?) conveniently review the changes and compare them to the trunk version?
-- Richard
On 28.11.2013, at 17:45, Jens Grivolla <j+...@grivolla.net> wrote:
> Since I'm pretty busy right now (should get better in a few days), I was waiting to see if I could use GIT branches for this instead of doing it directly in SVN.
>
> I have no idea how long it will take to get the git mirror, though, so I might do some tests before we get it.
>
> -- Jens
>
> On 11/28/2013 06:50 PM, Richard Eckart de Castilho wrote:
>> @Jens: as far as I understood, you already have a uimaFITted version of the ConceptMapper. Care creating a (svn-)branch of that add-on and applying your patch there?
>>
>> Cheers,
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional
in ConceptMapper
Posted by Jens Grivolla <j+...@grivolla.net>.
Since I'm pretty busy right now (should get better in a few days), I was
waiting to see if I could use GIT branches for this instead of doing it
directly in SVN.
I have no idea how long it will take to get the git mirror, though, so I
might do some tests before we get it.
-- Jens
On 11/28/2013 06:50 PM, Richard Eckart de Castilho wrote:
> @Jens: as far as I understood, you already have a uimaFITted version of the ConceptMapper. Care creating a (svn-)branch of that add-on and applying your patch there?
>
> Cheers,
>
> -- Richard
>
> On 22.11.2013, at 13:01, Marshall Schor <ms...@schor.com> wrote:
>
>> It would be interesting (at least to me) to see what the changes would be to an
>> add-on, by using uimaFIT. I would encourage making a branch for a prototypical
>> add-on, and doing the work, so we can easily compare and discuss...
>>
>> -Marshall
>>
>> On 11/22/2013 4:21 AM, Jens Grivolla wrote:
>>> Hi, I have put this on hold until the git mirror is set up, which in turn
>>> depends on deciding first whether there will be a change to the SVN layout.
>>>
>>> However, I do have a question: many addons (mostly AEs) would benefit from
>>> using uimaFIT, at least to get simplified handling of parameters. Since
>>> uimaFIT is still a sandbox component (despite having a released version
>>> available), are there any objections to using it when updating addons, some of
>>> which still derive from deprecated classes, etc.?
>>>
>>> -- Jens
>>>
>>> On 11/15/2013 11:34 AM, Jens Grivolla wrote:
>>>> Hi, I'm currently changing jobs so I have higher priority internal
>>>> things to get done first, which is why I didn't respond much these days.
>>>>
>>>> For me it would be best to try out the changes and coordinate with
>>>> Michael via github before making changes in SVN. I was able to assign
>>>> UIMA-2387 to myself on JIRA, I think Michael's changes should have
>>>> separate issues.
>>>>
>>>> Bye,
>>>> Jens
>>>>
>>>> On 11/15/2013 11:16 AM, Richard Eckart de Castilho wrote:
>>>>> So welcome Jens and Michael to the UIMA project :)
>>>>>
>>>>> With direct access to the SVN now, it should be much easier to get in
>>>>> your
>>>>> changes. No need to jump through patch-and-review loops all the time.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> -- Richard
>>>>>
>>>>> On 30.10.2013, at 13:03, Michael Tanenblatt
>>>>> <sl...@park-slope.net> wrote:
>>>>>
>>>>>> Jens and Richard:
>>>>>>
>>>>>> I also have some changes to ConceptMapper that I’d like to put in.
>>>>>> Namely:
>>>>>>
>>>>>> 1) Allow multiple matches in the dictionary: a term can appear
>>>>>> multiple times in the dictionary, and each match in the corpus will
>>>>>> be annotated for each of those multiple entries
>>>>>> 2) Allow different resultant annotation types, based on a feature in
>>>>>> dictionary entries: optionally specify a parameter in the AE
>>>>>> descriptor that provides the name of a key in some or all dictionary
>>>>>> entries, the value of which is the resulting annotation type when
>>>>>> that entry is found in the corpus. If none is specified, the current
>>>>>> method is used as default.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 29, 2013, at 11:50 AM, Jens Grivolla (JIRA)
>>>>>> <de...@uima.apache.org> wrote:
>>>>>>
>>>>>>>
>>>>>>> [
>>>>>>> https://issues.apache.org/jira/browse/UIMA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808106#comment-13808106
>>>>>>>
>>>>>>> ]
>>>>>>>
>>>>>>> Jens Grivolla commented on UIMA-2387:
>>>>>>> -------------------------------------
>>>>>>>
>>>>>>> I just saw that trunk has changed since my patch, doing the same
>>>>>>> upgrades to JCasAnnotator_ImplBase instead of TextAnnotator that I
>>>>>>> have since done independently. This should make integration of
>>>>>>> UIMA-2387 easier, since I can rebase it on top of the current trunk
>>>>>>> to get a working AE instead of having to do it in two steps.
>>>>>>>
>>>>>>>> ResultingAnnotationName not optional in ConceptMapper
>>>>>>>> -----------------------------------------------------
>>>>>>>>
>>>>>>>> Key: UIMA-2387
>>>>>>>> URL: https://issues.apache.org/jira/browse/UIMA-2387
>>>>>>>> Project: UIMA
>>>>>>>> Issue Type: Bug
>>>>>>>> Components: addons, Sandbox-ConceptMapper
>>>>>>>> Affects Versions: 2.3.1Addons
>>>>>>>> Reporter: Jens Grivolla
>>>>>>>> Priority: Minor
>>>>>>>> Attachments: UIMA-2387.patch
>>>>>>>>
>>>>>>>>
>>>>>>>> Contrary to the documentation, the ResultingAnnotationName is not
>>>>>>>> optional in the ConceptMapper descriptor. In our use case we only
>>>>>>>> want to write back information to the original token, without
>>>>>>>> creating a new annotation. Instead of treating this as a
>>>>>>>> documentation bug it is therefore better to fix the code.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> This message was sent by Atlassian JIRA
>>>>>>> (v6.1#6144)
>
>
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional in ConceptMapper
Posted by Richard Eckart de Castilho <re...@apache.org>.
@Jens: as far as I understood, you already have a uimaFITted version of the ConceptMapper. Care creating a (svn-)branch of that add-on and applying your patch there?
Cheers,
-- Richard
On 22.11.2013, at 13:01, Marshall Schor <ms...@schor.com> wrote:
> It would be interesting (at least to me) to see what the changes would be to an
> add-on, by using uimaFIT. I would encourage making a branch for a prototypical
> add-on, and doing the work, so we can easily compare and discuss...
>
> -Marshall
>
> On 11/22/2013 4:21 AM, Jens Grivolla wrote:
>> Hi, I have put this on hold until the git mirror is set up, which in turn
>> depends on deciding first whether there will be a change to the SVN layout.
>>
>> However, I do have a question: many addons (mostly AEs) would benefit from
>> using uimaFIT, at least to get simplified handling of parameters. Since
>> uimaFIT is still a sandbox component (despite having a released version
>> available), are there any objections to using it when updating addons, some of
>> which still derive from deprecated classes, etc.?
>>
>> -- Jens
>>
>> On 11/15/2013 11:34 AM, Jens Grivolla wrote:
>>> Hi, I'm currently changing jobs so I have higher priority internal
>>> things to get done first, which is why I didn't respond much these days.
>>>
>>> For me it would be best to try out the changes and coordinate with
>>> Michael via github before making changes in SVN. I was able to assign
>>> UIMA-2387 to myself on JIRA, I think Michael's changes should have
>>> separate issues.
>>>
>>> Bye,
>>> Jens
>>>
>>> On 11/15/2013 11:16 AM, Richard Eckart de Castilho wrote:
>>>> So welcome Jens and Michael to the UIMA project :)
>>>>
>>>> With direct access to the SVN now, it should be much easier to get in
>>>> your
>>>> changes. No need to jump through patch-and-review loops all the time.
>>>>
>>>> Cheers,
>>>>
>>>> -- Richard
>>>>
>>>> On 30.10.2013, at 13:03, Michael Tanenblatt
>>>> <sl...@park-slope.net> wrote:
>>>>
>>>>> Jens and Richard:
>>>>>
>>>>> I also have some changes to ConceptMapper that I’d like to put in.
>>>>> Namely:
>>>>>
>>>>> 1) Allow multiple matches in the dictionary: a term can appear
>>>>> multiple times in the dictionary, and each match in the corpus will
>>>>> be annotated for each of those multiple entries
>>>>> 2) Allow different resultant annotation types, based on a feature in
>>>>> dictionary entries: optionally specify a parameter in the AE
>>>>> descriptor that provides the name of a key in some or all dictionary
>>>>> entries, the value of which is the resulting annotation type when
>>>>> that entry is found in the corpus. If none is specified, the current
>>>>> method is used as default.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Oct 29, 2013, at 11:50 AM, Jens Grivolla (JIRA)
>>>>> <de...@uima.apache.org> wrote:
>>>>>
>>>>>>
>>>>>> [
>>>>>> https://issues.apache.org/jira/browse/UIMA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808106#comment-13808106
>>>>>>
>>>>>> ]
>>>>>>
>>>>>> Jens Grivolla commented on UIMA-2387:
>>>>>> -------------------------------------
>>>>>>
>>>>>> I just saw that trunk has changed since my patch, doing the same
>>>>>> upgrades to JCasAnnotator_ImplBase instead of TextAnnotator that I
>>>>>> have since done independently. This should make integration of
>>>>>> UIMA-2387 easier, since I can rebase it on top of the current trunk
>>>>>> to get a working AE instead of having to do it in two steps.
>>>>>>
>>>>>>> ResultingAnnotationName not optional in ConceptMapper
>>>>>>> -----------------------------------------------------
>>>>>>>
>>>>>>> Key: UIMA-2387
>>>>>>> URL: https://issues.apache.org/jira/browse/UIMA-2387
>>>>>>> Project: UIMA
>>>>>>> Issue Type: Bug
>>>>>>> Components: addons, Sandbox-ConceptMapper
>>>>>>> Affects Versions: 2.3.1Addons
>>>>>>> Reporter: Jens Grivolla
>>>>>>> Priority: Minor
>>>>>>> Attachments: UIMA-2387.patch
>>>>>>>
>>>>>>>
>>>>>>> Contrary to the documentation, the ResultingAnnotationName is not
>>>>>>> optional in the ConceptMapper descriptor. In our use case we only
>>>>>>> want to write back information to the original token, without
>>>>>>> creating a new annotation. Instead of treating this as a
>>>>>>> documentation bug it is therefore better to fix the code.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> This message was sent by Atlassian JIRA
>>>>>> (v6.1#6144)
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional
in ConceptMapper
Posted by Marshall Schor <ms...@schor.com>.
It would be interesting (at least to me) to see what the changes would be to an
add-on, by using uimaFIT. I would encourage making a branch for a prototypical
add-on, and doing the work, so we can easily compare and discuss...
-Marshall
On 11/22/2013 4:21 AM, Jens Grivolla wrote:
> Hi, I have put this on hold until the git mirror is set up, which in turn
> depends on deciding first whether there will be a change to the SVN layout.
>
> However, I do have a question: many addons (mostly AEs) would benefit from
> using uimaFIT, at least to get simplified handling of parameters. Since
> uimaFIT is still a sandbox component (despite having a released version
> available), are there any objections to using it when updating addons, some of
> which still derive from deprecated classes, etc.?
>
> -- Jens
>
> On 11/15/2013 11:34 AM, Jens Grivolla wrote:
>> Hi, I'm currently changing jobs so I have higher priority internal
>> things to get done first, which is why I didn't respond much these days.
>>
>> For me it would be best to try out the changes and coordinate with
>> Michael via github before making changes in SVN. I was able to assign
>> UIMA-2387 to myself on JIRA, I think Michael's changes should have
>> separate issues.
>>
>> Bye,
>> Jens
>>
>> On 11/15/2013 11:16 AM, Richard Eckart de Castilho wrote:
>>> So welcome Jens and Michael to the UIMA project :)
>>>
>>> With direct access to the SVN now, it should be much easier to get in
>>> your
>>> changes. No need to jump through patch-and-review loops all the time.
>>>
>>> Cheers,
>>>
>>> -- Richard
>>>
>>> On 30.10.2013, at 13:03, Michael Tanenblatt
>>> <sl...@park-slope.net> wrote:
>>>
>>>> Jens and Richard:
>>>>
>>>> I also have some changes to ConceptMapper that I’d like to put in.
>>>> Namely:
>>>>
>>>> 1) Allow multiple matches in the dictionary: a term can appear
>>>> multiple times in the dictionary, and each match in the corpus will
>>>> be annotated for each of those multiple entries
>>>> 2) Allow different resultant annotation types, based on a feature in
>>>> dictionary entries: optionally specify a parameter in the AE
>>>> descriptor that provides the name of a key in some or all dictionary
>>>> entries, the value of which is the resulting annotation type when
>>>> that entry is found in the corpus. If none is specified, the current
>>>> method is used as default.
>>>>
>>>>
>>>>
>>>>
>>>> On Oct 29, 2013, at 11:50 AM, Jens Grivolla (JIRA)
>>>> <de...@uima.apache.org> wrote:
>>>>
>>>>>
>>>>> [
>>>>> https://issues.apache.org/jira/browse/UIMA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808106#comment-13808106
>>>>>
>>>>> ]
>>>>>
>>>>> Jens Grivolla commented on UIMA-2387:
>>>>> -------------------------------------
>>>>>
>>>>> I just saw that trunk has changed since my patch, doing the same
>>>>> upgrades to JCasAnnotator_ImplBase instead of TextAnnotator that I
>>>>> have since done independently. This should make integration of
>>>>> UIMA-2387 easier, since I can rebase it on top of the current trunk
>>>>> to get a working AE instead of having to do it in two steps.
>>>>>
>>>>>> ResultingAnnotationName not optional in ConceptMapper
>>>>>> -----------------------------------------------------
>>>>>>
>>>>>> Key: UIMA-2387
>>>>>> URL: https://issues.apache.org/jira/browse/UIMA-2387
>>>>>> Project: UIMA
>>>>>> Issue Type: Bug
>>>>>> Components: addons, Sandbox-ConceptMapper
>>>>>> Affects Versions: 2.3.1Addons
>>>>>> Reporter: Jens Grivolla
>>>>>> Priority: Minor
>>>>>> Attachments: UIMA-2387.patch
>>>>>>
>>>>>>
>>>>>> Contrary to the documentation, the ResultingAnnotationName is not
>>>>>> optional in the ConceptMapper descriptor. In our use case we only
>>>>>> want to write back information to the original token, without
>>>>>> creating a new annotation. Instead of treating this as a
>>>>>> documentation bug it is therefore better to fix the code.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> This message was sent by Atlassian JIRA
>>>>> (v6.1#6144)
>>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional in ConceptMapper
Posted by Michael Tanenblatt <sl...@park-slope.net>.
For ConceptMapper, at least, I'd prefer it not depend on uimaFIT
> On Nov 22, 2013, at 4:21 AM, Jens Grivolla <j+...@grivolla.net> wrote:
>
> Hi, I have put this on hold until the git mirror is set up, which in turn depends on deciding first whether there will be a change to the SVN layout.
>
> However, I do have a question: many addons (mostly AEs) would benefit from using uimaFIT, at least to get simplified handling of parameters. Since uimaFIT is still a sandbox component (despite having a released version available), are there any objections to using it when updating addons, some of which still derive from deprecated classes, etc.?
>
> -- Jens
>
>> On 11/15/2013 11:34 AM, Jens Grivolla wrote:
>> Hi, I'm currently changing jobs so I have higher priority internal
>> things to get done first, which is why I didn't respond much these days.
>>
>> For me it would be best to try out the changes and coordinate with
>> Michael via github before making changes in SVN. I was able to assign
>> UIMA-2387 to myself on JIRA, I think Michael's changes should have
>> separate issues.
>>
>> Bye,
>> Jens
>>
>>> On 11/15/2013 11:16 AM, Richard Eckart de Castilho wrote:
>>> So welcome Jens and Michael to the UIMA project :)
>>>
>>> With direct access to the SVN now, it should be much easier to get in
>>> your
>>> changes. No need to jump through patch-and-review loops all the time.
>>>
>>> Cheers,
>>>
>>> -- Richard
>>>
>>> On 30.10.2013, at 13:03, Michael Tanenblatt
>>> <sl...@park-slope.net> wrote:
>>>
>>>> Jens and Richard:
>>>>
>>>> I also have some changes to ConceptMapper that I’d like to put in.
>>>> Namely:
>>>>
>>>> 1) Allow multiple matches in the dictionary: a term can appear
>>>> multiple times in the dictionary, and each match in the corpus will
>>>> be annotated for each of those multiple entries
>>>> 2) Allow different resultant annotation types, based on a feature in
>>>> dictionary entries: optionally specify a parameter in the AE
>>>> descriptor that provides the name of a key in some or all dictionary
>>>> entries, the value of which is the resulting annotation type when
>>>> that entry is found in the corpus. If none is specified, the current
>>>> method is used as default.
>>>>
>>>>
>>>>
>>>>
>>>> On Oct 29, 2013, at 11:50 AM, Jens Grivolla (JIRA)
>>>> <de...@uima.apache.org> wrote:
>>>>
>>>>>
>>>>> [
>>>>> https://issues.apache.org/jira/browse/UIMA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808106#comment-13808106
>>>>> ]
>>>>>
>>>>> Jens Grivolla commented on UIMA-2387:
>>>>> -------------------------------------
>>>>>
>>>>> I just saw that trunk has changed since my patch, doing the same
>>>>> upgrades to JCasAnnotator_ImplBase instead of TextAnnotator that I
>>>>> have since done independently. This should make integration of
>>>>> UIMA-2387 easier, since I can rebase it on top of the current trunk
>>>>> to get a working AE instead of having to do it in two steps.
>>>>>
>>>>>> ResultingAnnotationName not optional in ConceptMapper
>>>>>> -----------------------------------------------------
>>>>>>
>>>>>> Key: UIMA-2387
>>>>>> URL: https://issues.apache.org/jira/browse/UIMA-2387
>>>>>> Project: UIMA
>>>>>> Issue Type: Bug
>>>>>> Components: addons, Sandbox-ConceptMapper
>>>>>> Affects Versions: 2.3.1Addons
>>>>>> Reporter: Jens Grivolla
>>>>>> Priority: Minor
>>>>>> Attachments: UIMA-2387.patch
>>>>>>
>>>>>>
>>>>>> Contrary to the documentation, the ResultingAnnotationName is not
>>>>>> optional in the ConceptMapper descriptor. In our use case we only
>>>>>> want to write back information to the original token, without
>>>>>> creating a new annotation. Instead of treating this as a
>>>>>> documentation bug it is therefore better to fix the code.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> This message was sent by Atlassian JIRA
>>>>> (v6.1#6144)
>
>
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional
in ConceptMapper
Posted by Jens Grivolla <j+...@grivolla.net>.
Hi, I have put this on hold until the git mirror is set up, which in
turn depends on deciding first whether there will be a change to the SVN
layout.
However, I do have a question: many addons (mostly AEs) would benefit
from using uimaFIT, at least to get simplified handling of parameters.
Since uimaFIT is still a sandbox component (despite having a released
version available), are there any objections to using it when updating
addons, some of which still derive from deprecated classes, etc.?
-- Jens
On 11/15/2013 11:34 AM, Jens Grivolla wrote:
> Hi, I'm currently changing jobs so I have higher priority internal
> things to get done first, which is why I didn't respond much these days.
>
> For me it would be best to try out the changes and coordinate with
> Michael via github before making changes in SVN. I was able to assign
> UIMA-2387 to myself on JIRA, I think Michael's changes should have
> separate issues.
>
> Bye,
> Jens
>
> On 11/15/2013 11:16 AM, Richard Eckart de Castilho wrote:
>> So welcome Jens and Michael to the UIMA project :)
>>
>> With direct access to the SVN now, it should be much easier to get in
>> your
>> changes. No need to jump through patch-and-review loops all the time.
>>
>> Cheers,
>>
>> -- Richard
>>
>> On 30.10.2013, at 13:03, Michael Tanenblatt
>> <sl...@park-slope.net> wrote:
>>
>>> Jens and Richard:
>>>
>>> I also have some changes to ConceptMapper that I’d like to put in.
>>> Namely:
>>>
>>> 1) Allow multiple matches in the dictionary: a term can appear
>>> multiple times in the dictionary, and each match in the corpus will
>>> be annotated for each of those multiple entries
>>> 2) Allow different resultant annotation types, based on a feature in
>>> dictionary entries: optionally specify a parameter in the AE
>>> descriptor that provides the name of a key in some or all dictionary
>>> entries, the value of which is the resulting annotation type when
>>> that entry is found in the corpus. If none is specified, the current
>>> method is used as default.
>>>
>>>
>>>
>>>
>>> On Oct 29, 2013, at 11:50 AM, Jens Grivolla (JIRA)
>>> <de...@uima.apache.org> wrote:
>>>
>>>>
>>>> [
>>>> https://issues.apache.org/jira/browse/UIMA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808106#comment-13808106
>>>> ]
>>>>
>>>> Jens Grivolla commented on UIMA-2387:
>>>> -------------------------------------
>>>>
>>>> I just saw that trunk has changed since my patch, doing the same
>>>> upgrades to JCasAnnotator_ImplBase instead of TextAnnotator that I
>>>> have since done independently. This should make integration of
>>>> UIMA-2387 easier, since I can rebase it on top of the current trunk
>>>> to get a working AE instead of having to do it in two steps.
>>>>
>>>>> ResultingAnnotationName not optional in ConceptMapper
>>>>> -----------------------------------------------------
>>>>>
>>>>> Key: UIMA-2387
>>>>> URL: https://issues.apache.org/jira/browse/UIMA-2387
>>>>> Project: UIMA
>>>>> Issue Type: Bug
>>>>> Components: addons, Sandbox-ConceptMapper
>>>>> Affects Versions: 2.3.1Addons
>>>>> Reporter: Jens Grivolla
>>>>> Priority: Minor
>>>>> Attachments: UIMA-2387.patch
>>>>>
>>>>>
>>>>> Contrary to the documentation, the ResultingAnnotationName is not
>>>>> optional in the ConceptMapper descriptor. In our use case we only
>>>>> want to write back information to the original token, without
>>>>> creating a new annotation. Instead of treating this as a
>>>>> documentation bug it is therefore better to fix the code.
>>>>
>>>>
>>>>
>>>> --
>>>> This message was sent by Atlassian JIRA
>>>> (v6.1#6144)
>>>
>>
>>
>
>
>
Re: [jira] [Commented] (UIMA-2387) ResultingAnnotationName not optional
in ConceptMapper
Posted by Jens Grivolla <j+...@grivolla.net>.
Hi, I'm currently changing jobs so I have higher priority internal
things to get done first, which is why I didn't respond much these days.
For me it would be best to try out the changes and coordinate with
Michael via github before making changes in SVN. I was able to assign
UIMA-2387 to myself on JIRA, I think Michael's changes should have
separate issues.
Bye,
Jens
On 11/15/2013 11:16 AM, Richard Eckart de Castilho wrote:
> So welcome Jens and Michael to the UIMA project :)
>
> With direct access to the SVN now, it should be much easier to get in your
> changes. No need to jump through patch-and-review loops all the time.
>
> Cheers,
>
> -- Richard
>
> On 30.10.2013, at 13:03, Michael Tanenblatt <sl...@park-slope.net> wrote:
>
>> Jens and Richard:
>>
>> I also have some changes to ConceptMapper that I’d like to put in. Namely:
>>
>> 1) Allow multiple matches in the dictionary: a term can appear multiple times in the dictionary, and each match in the corpus will be annotated for each of those multiple entries
>> 2) Allow different resultant annotation types, based on a feature in dictionary entries: optionally specify a parameter in the AE descriptor that provides the name of a key in some or all dictionary entries, the value of which is the resulting annotation type when that entry is found in the corpus. If none is specified, the current method is used as default.
>>
>>
>>
>>
>> On Oct 29, 2013, at 11:50 AM, Jens Grivolla (JIRA) <de...@uima.apache.org> wrote:
>>
>>>
>>> [ https://issues.apache.org/jira/browse/UIMA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808106#comment-13808106 ]
>>>
>>> Jens Grivolla commented on UIMA-2387:
>>> -------------------------------------
>>>
>>> I just saw that trunk has changed since my patch, doing the same upgrades to JCasAnnotator_ImplBase instead of TextAnnotator that I have since done independently. This should make integration of UIMA-2387 easier, since I can rebase it on top of the current trunk to get a working AE instead of having to do it in two steps.
>>>
>>>> ResultingAnnotationName not optional in ConceptMapper
>>>> -----------------------------------------------------
>>>>
>>>> Key: UIMA-2387
>>>> URL: https://issues.apache.org/jira/browse/UIMA-2387
>>>> Project: UIMA
>>>> Issue Type: Bug
>>>> Components: addons, Sandbox-ConceptMapper
>>>> Affects Versions: 2.3.1Addons
>>>> Reporter: Jens Grivolla
>>>> Priority: Minor
>>>> Attachments: UIMA-2387.patch
>>>>
>>>>
>>>> Contrary to the documentation, the ResultingAnnotationName is not optional in the ConceptMapper descriptor. In our use case we only want to write back information to the original token, without creating a new annotation. Instead of treating this as a documentation bug it is therefore better to fix the code.
>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.1#6144)
>>
>
>