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