@Jörn: this is what the converter analysis engines do, but no objects need to be created in the trivial case. For the non-trivial case its the same for me.
@Richard: this could work, but only for the trivial case, same structure different names. Maybe I am a bit pessimistic, but I see many many problems and a lot of work if someone wants to implement it. Best, Peter Am 12.09.2016 um 16:36 schrieb Richard Eckart de Castilho: > On 12.09.2016, at 16:53, Joern Kottmann <[email protected]> wrote: >> With special APIs you could probably do the following things: >> - Define type name mappings, type A looks like type B to the AE >> - Define functions which are used to access the features of a FS (the >> function can map the feature value to something new) and let the CAS APIs >> take care of calling it >> - Define functions which converts an entire FS of type A into an FS of type >> B and let the CAS APIs take care of calling it >> - It could be possible to define adapters for AAEs as well (same TS AEs >> could be grouped) > Hm, JCas cover classes (might be able to) address all these issues if some > assumptions > are relaxed, e.g. that the name of a JCas class is the same as for a uima > type. > > So I have a feeling that these things could be solved by allowing users to > prep > a CAS with their own cover classes which would be used instead of generated > JCas cover classes. > > Does that make some initial sense already or should I elaborate this > further... > or does it sound completely wrong? > > Cheers, > > -- Richard
