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: "Standard" UIMA typesystem
Date Fri, 09 Sep 2016 14:29:29 GMT

Am 09.09.2016 um 15:59 schrieb Joern Kottmann:
> If you merge the type systems of the components you want to use you end up
> with
> a huge mess of a merged type system and you have to do type system
> conversions
> between the AEs.

Why do you end up with a huge mess? All is fine if everyone uses their
own namespaces, as it is with java classes. If you combine many java
libraries you also get a lot of classes.

In my opinion, if you get beyond simple type systems, you cannot convert
the types on the fly. You need some knowledge about the conversion,
e.g., implemented in a converter. This can be a performance problem...

Peter

> Jörn
>
> On Fri, Sep 9, 2016 at 3:49 PM, Peter Klügl <peter.kluegl@averbis.com>
> wrote:
>
>> I still don't get it.
>>
>>
>> You can reuse all components if you include some type system mapping
>> that knows the transformation. I combined some of our components with
>> DKPro Core, ClearTK, cTAKES and JCore components.
>>
>>
>> Our components won't work with the DKPro Core typesystem even if the
>> UIMA Framework would support more "laziness" or dynamic typing (for
>> different reasons, e.g., missing information).
>>
>>
>> I get the point with code generation though.
>>
>>
>> Best,
>>
>> Peter
>>
>>
>> Am 09.09.2016 um 15:11 schrieb Joern Kottmann:
>>> A very good reason to use a framework like UIMA is that we can reuse
>>> components
>>> and don't have to build everything from scratch (if I have to do that I
>>> don't need UIMA these days).
>>>
>>> To be able to reuse a component it must work with multiple type systems
>> or
>>> can easily be adapted
>>> to a custom type system.
>>>
>>> I am personally think the convenience the JCas brings is outweighed many
>>> times by all the complexity
>>> and disadvantages which come with it, e.g. code generation step, having
>>> extra special classes and mostly impossible
>>> to reuse the written code.
>>>
>>> Jörn
>>>
>>> On Fri, Sep 9, 2016 at 2:37 PM, Peter Klügl <peter.kluegl@averbis.com>
>>> wrote:
>>>
>>>> How should this be solved/improved? I do not see it.
>>>>
>>>> You have either generic analysis engines with parameters for the types,
>>>> or the analysis engine knows the types and depends on it, regardless if
>>>> you use CAS or JCas.
>>>>
>>>> Isn't that the thing with static typed feature structures? If you have
>>>> Java code that depends on a class hierarchy, you are stuck with that
>>>> hierarchy. (I hope this discussion won't go in a direction that
>>>> dynamically typed programming languages are  better)
>>>>
>>>>
>>>> I probably do not understand the motivation. Can you give me an example?
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>> Am 09.09.2016 um 13:57 schrieb Joern Kottmann:
>>>>> I personally think that we depend way too much on particular type
>> systems
>>>>> in UIMA. I really hope we can solve this to some degree in UIMA 3, if
I
>>>>> today
>>>>> write code using JCAS I am totally stuck with the TS I use, reusing any
>>>> of
>>>>> that
>>>>> code with a different TS is impossible.
>>>>>
>>>>> The best you can do is using just the CAS, but then it is still
>> difficult
>>>>> to support
>>>>> multiple type systems (e.g. complex configuration, various styles) and
>>>> allow
>>>>> reusing of the component in different systems.
>>>>>
>>>>> Jörn
>>>>>
>>>>> On Tue, Aug 30, 2016 at 7:57 PM, Richard Eckart de Castilho <
>>>> rec@apache.org>
>>>>> wrote:
>>>>>
>>>>>> On 30.08.2016, at 16:39, Peter Klügl <peter.kluegl@averbis.com>
>> wrote:
>>>>>>> If there no standard type system, then people have two options:
>> create
>>>>>>> their own one or reuse an existing type system of a component
>>>>>>> repository, e.g., DKPro Core. As far as I know LiMoSINe [1] moved
>> from
>>>>>>> their own type system to DKPro Core (I waiting for some text
to put
>> on
>>>>>>> our external resources page - in case they read this).  I also
was
>>>>>>> thinking about switching our NLP components to the DKPro Core
type
>>>>>>> system, but there are several issues preventing that, first of
all
>> that
>>>>>>> I cannot build it :-/
>>>>>> /me Apache/UIMA hat off, DKPro Core hat on
>>>>>>
>>>>>> Ok... I am finally addressing this annoying Windowsisim...
>>>>>>
>>>>>>   https://github.com/dkpro/dkpro-core/issues/414
>>>>>>
>>>>>> Btw. feel free to submit issues for DKPro Core type system
>> improvements.
>>>>>> We actually do evolve the TS - trying to avoid breaking changes...
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> -- Richard
>>


Mime
View raw message