Thanks for pointing that out. I think this can be contained, by having the Apache UIMA project not officially endorse any particular type system but rather use its web site to refer to other broader community resources around UIMA, like a common type system (if one emerges for some subset of UIMA users).
The web site already has a reference to one such type system, designed for multi-modal artifact analysis: http://uima.apache.org/sandbox.html#gale.multimodal.example -Marshall On 8/30/2016 9:59 AM, Richard Eckart de Castilho wrote: > While I think that an endorsed type system is a good idea, I still wonder... > > As far as I understood, UIMA has always been advertised as an "empty" > framework > that does explicitly not prescribe a particular type system - probably to > underline > it's flexibility. Would that not suffer if UIMA itself provided a standard > typesystem? > > Cheers, > > -- Richard > >> On 30.08.2016, at 15:56, Marshall Schor <[email protected]> wrote: >> >> This is a great idea. The key will be in discovering and using a workable >> "crowd-sourced" (?) process (and perhaps supporting tooling :-) ) that lets a >> diverse set of people with somewhat aligned interests converge on a shared >> definition. >> >> -Marshall >> >> On 8/30/2016 5:40 AM, Jens Grivolla wrote: >>> 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
