@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 <[email protected]> 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 >>>> <[email protected]> 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) >>>>> <[email protected]> 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)
