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 >
