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) >>>> >>> >>> >> >> >> > > >
