uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kl├╝gl <peter.klu...@averbis.com>
Subject Re: "Standard" UIMA typesystem
Date Sun, 11 Sep 2016 13:48:31 GMT
back to the original topic:

Another option: provide an abstract minimal typesystem that is extended
by the different typesystems of the component repositories.

Pro: If specific features are not required, no mapping needs to be added.

Con: Problems if the repo already uses a central supertype.

Best,

Peter

Am 30.08.2016 um 11:40 schrieb Jens Grivolla:
> Hi all,
>
> at the LREC conference there were some brief discussions about pushing for
> a "standard" typesystem (and maybe some more things) to make combining UIMA
> annotators from different sources easier.
>
> While it is great that UIMA itself is a generic framework that is
> completely agnostic to the tasks it is used for, there are many users that
> want to be able to use existing analysis engines. Currently they are forced
> to either choose a specific component collection (DKpro, cTakes, JCORE,
> OpenNLP, ...) or write adapters to convert type systems.
>
> There was agreement between some of us (Richard, Peter, etc.) that it would
> be very helpful to guide component developers towards a shared type system
> to make adoption of UIMA easier and avoid fragmentation.
>
> Here are some suggestions on how to proceed:
>
> - go all in and have the UIMA project provide a type system (in the UIMA
> namespace)
> - develop an independent (unofficial) type system that is recommended on
> the UIMA web site
> - develop an unofficial type system and gather endorsements from a variety
> of institutions (UPF, UKP, JulieLab, Averbis, ...) so as to promote this
> type system.
>
> I think (and there was initial agreement on this) that DKpro's type system
> would be a good starting point (with some fixes).
>
> So, how does everybody feel about this, and how do we get started?
>
> Best,
> Jens
>


Mime
View raw message