Re: Dictionary annotator - added parameter to make analysis on different SOFAs

[Luca Foppiano <lu...@foppiano.org>]

HI Richard,
   there is no special reason, I didn't know I could have used the sofa
mappings. I haven't arrived that far.

Anyway, as a matter of principle, I think Whitespace and Dictionary are
likely to be used together as exercise, therefore I found quite complicated
to figure out how to chain them, therefore having similar approaches (both
using parameters) would simplify the solution.

I'm not sure but I imagine that the Whitespace annotator could use the sofa
mapping as well.

Cheers
Luca



On Fri, Jan 31, 2014 at 8:26 PM, Richard Eckart de Castilho
<re...@apache.org>wrote:

> Hi Luca,
>
> is there a specific reason that you chose to make the sofa names a
> parameter instead of using sofa mappings?
>
> Cheers,
>
> -- Richard
>
> On 31.01.2014, at 16:58, Luca Foppiano <lu...@foppiano.org> wrote:
>
> > Dear all,
> >   I've created a small change (copy-pasted from the Whitespace AE) to
> allow the Dictionary Annotator to operate on SOFAs different from the
> default one.
> >
> > Basically it works as the Whitespace Annotator, the parameter name is
> called sofaNames. If it is accepted I will update the documentation
> accordingly.
> >
> > Regards
> > Luca
>
>


-- 
Luca Foppiano

Software Engineer
+31615253280
luca@foppiano.org
www.foppiano.org

Re: Dictionary annotator - added parameter to make analysis on different SOFAs

[Luca Foppiano <lu...@foppiano.org>]

On Mon, Feb 3, 2014 at 12:29 PM, Richard Eckart de Castilho
<re...@apache.org>wrote:

> Hi Luca,
>
> I believe the annotators that are provided in the UIMA Addons and
> in the UIMA Sandbox are a rather loose and sometimes incoherent
> collection. I believe this is partly an effect of the UIMA project
> itself always rejecting to offer a default type system suggestion.
> It seems to me that providing types and a coherent collection of
> interoperable components has always been deferred to other projects.
>
> There are various UIMA component collections that each offer a
> type system and a set of analysis components designed to work
> with this type system. These components also tend to share other
> common design traits, e.g. common parameters, approaches to view
> handling, etc.
>

[...]


> Maybe this can give you some further orientation if you are looking
> for more a more coherent offer of analysis components.
>
>
Thanks for the information, I've checked only U-Compare so far, but I
definitely prefer to build something around Uima-fit. An important part of
my discovery research is to get into problematic situation, because I'm
trying to find weak parts in the integration process of different
Annotator.

[...]


> Disclaimer: My own work is focussing on DKPro Core and uimaFIT.
>

:-)

Cheers
-- 
Luca Foppiano

Software Engineer
+31615253280
luca@foppiano.org
www.foppiano.org

Re: Dictionary annotator - added parameter to make analysis on different SOFAs

[Richard Eckart de Castilho <re...@apache.org>]

Hi Luca,

I believe the annotators that are provided in the UIMA Addons and
in the UIMA Sandbox are a rather loose and sometimes incoherent
collection. I believe this is partly an effect of the UIMA project
itself always rejecting to offer a default type system suggestion.
It seems to me that providing types and a coherent collection of
interoperable components has always been deferred to other projects.

There are various UIMA component collections that each offer a
type system and a set of analysis components designed to work
with this type system. These components also tend to share other
common design traits, e.g. common parameters, approaches to view
handling, etc.

These are the collections I know of (in alphabetical order):

- Apache cTAKES - for the medical domain
  http://ctakes.apache.org

- ClearTK - general purpose
  https://code.google.com/p/cleartk/   

- DKPro Core - general purpose
  https://code.google.com/p/dkpro-core-asl/

- JCoRe - bioinformatics touch
  http://www.julielab.de/Resources/NLP+Tools.html

- U-Compare - general purpose
  http://nactem.ac.uk/ucompare/

uimaFIT originated from the contexts of ClearTK and later DKPro Core.
These collections build heavily on uimaFIT and support its style best.

Maybe this can give you some further orientation if you are looking
for more a more coherent offer of analysis components.

Cheers,

-- Richard

Disclaimer: My own work is focussing on DKPro Core and uimaFIT.

On 03.02.2014, at 12:14, Luca Foppiano <lu...@foppiano.org> wrote:

> HI Richard,
>   there is no special reason, I didn't know I could have used the sofa
> mappings. I haven't arrived that far.
> 
> Anyway, as a matter of principle, I think Whitespace and Dictionary are
> likely to be used together as exercise, therefore I found quite complicated
> to figure out how to chain them, therefore having similar approaches (both
> using parameters) would simplify the solution.
> 
> I'm not sure but I imagine that the Whitespace annotator could use the sofa
> mapping as well.
> 
> Cheers
> Luca
> 
> On Fri, Jan 31, 2014 at 8:26 PM, Richard Eckart de Castilho
> <re...@apache.org>wrote:
> 
>> Hi Luca,
>> 
>> is there a specific reason that you chose to make the sofa names a
>> parameter instead of using sofa mappings?
>> 
>> Cheers,
>> 
>> -- Richard
>> 
>> On 31.01.2014, at 16:58, Luca Foppiano <lu...@foppiano.org> wrote:
>> 
>>> Dear all,
>>>  I've created a small change (copy-pasted from the Whitespace AE) to
>> allow the Dictionary Annotator to operate on SOFAs different from the
>> default one.
>>> 
>>> Basically it works as the Whitespace Annotator, the parameter name is
>> called sofaNames. If it is accepted I will update the documentation
>> accordingly.
>>> 
>>> Regards
>>> Luca
> 
> -- 
> Luca Foppiano
> 
> Software Engineer
> +31615253280
> luca@foppiano.org
> www.foppiano.org