> On 12.09.2016, at 11:52, Joern Kottmann <[email protected]> wrote: > >> On Sun, Sep 11, 2016 at 3:38 PM, Peter Klügl <[email protected]> >> wrote: >> >>> Am 09.09.2016 um 23:24 schrieb Joern Kottmann: >>> >>> A framework like Uima has to make it easy to reuse components and in my >>> opinion strict compile time typing makes that really difficult to >> achieve. >> >> Components are already very reusable if they use the same typesystem. >> Again, that has nothing to do with compile time typing. >> >> And, this is not the only purpose but there are many more, e.g., allow >> the developer to create large maintainable pipelines. >> In my opinion, components in UIMA are much more reusable because of the >> static typing, not just throw-away prototypes. > > I strongly disagree here I think the really static type system (and with > JCas even compile time static) in UIMA makes it hard reuse a component, > because I need to write explicit type system converters in many cases to be > able to use them.
IMHO type converters are necessary whether or not the type system is compiled statically. You seem to want per-component converters (what you call adapters). I personally prefer converters at the beginning and end of pipeline sections (which can be realized e.g. through collection readers, CAS consumers or CAS mulipliers). Regarding adapters: IMHO a UIMA component largely *is* the adapter between type system X and underlying implementation Y. My hypothesis is that if there would be a generic configurable mechanism by which this mapping functionality could be externalized from a UIMA component, then this mechanism would have the same level of complexity as the Java code which usually fulfills this purpose in a component. Furthermore, I expect the remaining component code to become largely trivial then. - OR - if the mapping functionality is reduced in functionality in order to become simpler, then it would mean certain type system designs are not supported (cf. OpenNLP type mapping not being compatible with the DKPro Core type system and others). Type conversion is an entirely separate thing from JCas classes and managing different JCas wrappers at the level of classloaders. Here, UIMA offers the PEAR solution and I think a constructive discussion could revolve how PEARs can be improved or replaced by a superior approach. > The alternative to this would be a type system which is much less static > (or dynamic) and APIs to write AEs which can adapt well to similar but > different user defined type systems. This could be achieved by allowing > type system mappings, by adding explicit support for adapters in the > framework, allowing dynamic definition of types, > > Together with Thilo I wrote a paper which speaks a bit about this topic > (see at 6.4): > http://www.aclweb.org/anthology/W14-5209 A more dynamic approach to the type system would be great, in particular the ability to add types and features at execution time. We have an API that in principle supports this (CAS). Again, this is decoupled from JCas which is a higher-level API than CAS is. >>> But maybe I am wrong and people have some good examples of Jcas based AEs >>> which are nice to reuse in a simple custom pipeline. >>> >> >> I am not interested in simple pipelines. I do not need UIMA for that. I >> need UIMA for pipelines with dozens of components developed by different >> people. >> > If have a large pipeline you will end up writing two converters if you use > an AE which can't adapt to your type system, one to convert to the AEs type > system, this one you place before, and one to convert back from the AE type > system to yours. I was speaking here about a simple example, and not a > simple pipeline. Hm, here you seem to be talking about not per-component adapters but adapters between larger subsections of a pipeline - those I suggested could be implemented e.g. via CAS multipliers. At this point, I am actually unsure what you are suggesting in terms of what you call "adapters". Cheers, -- Richard
