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: Handling type conversion (was Re: "Standard" UIMA typesystem)
Date Wed, 14 Sep 2016 17:00:05 GMT
@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 <kottmann@gmail.com> 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


Mime
View raw message