uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Klügl <pklu...@uni-wuerzburg.de>
Subject Re: Sofa-unaware AEs that create new views in an AAE
Date Tue, 22 Apr 2014 16:20:48 GMT
Am 22.04.2014 18:10, schrieb Eddie Epstein:
> The current design supports passing a specific view to an annotator:
> map the desired view to the default view and do not declare the
> annotator view aware by declaring input or output sofas.
>
> An alternate, unambiguous design would be that the default view
> should always be delivered to the process method. Is this a better
> model for you?

I actually solved the problem without changing any code.

What I wanted, or what I would have expected, is that the CAS given in
the process method is already the view mapped in the aggregate. The
component that made the problems has a code fragment that checks the
name of the given CAS and, if that is null, takes view with the default
CAS (_InitialView). I actually don't remember why I added that.

The aggregate maps now to that default view of the  analysis engine
instead of a specific one, and the analysis engine retrieves that view
if the base CAS is given. So, no need for an additional parameter.
That's all I wanted :-)

Thanks Eddie,

Peter


> Eddie
>
>
>
>
> On Tue, Apr 22, 2014 at 6:47 AM, Peter Klügl <pkluegl@uni-wuerzburg.de>wrote:
>
>> Am 18.04.2014 15:23, schrieb Eddie Epstein:
>>> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl <pkluegl@uni-wuerzburg.de
>>> wrote:
>>>
>>>> Am 17.04.2014 15:01, schrieb Eddie Epstein:
>>>>> Hi Peter,
>>>>>
>>>>> The logic is that since a sofa aware component may have one or
>>>>> more input and/or output views, such a component needs to use
>>>>> getView to specify which to use.
>>>>>
>>>>> For sofa aware delegates, sofa mapping enables the delegate to
>>>>> hard wire input and/or output View names in annotator code (or
>>>>> annotator config parameters) and then have the real View names
>>>>> assigned via mapping in the aggregate.
>>>> Is the real view name in the mapping important at all since the view get
>>>> accessed by the implementation in the process() method?
>>>>
>>> The real view name is what will be used when the CAS is serialized
>>> to a file or to a remote service.
>>>
>>
>> Yes, but that has nothing to do with the mapping, which is still obsolete.
>>
>>
>>>> I don't see the effect of the mapping to the default input view of an
>>>> sofa aware AE without input view capabilities at all. The mapping says
>>>> view1 is linked, but another one arrives.
>>>>
>>> The input view for a sofa aware component is always the base CAS view,
>>> for the reason given above.
>>>
>> I don't see the reasons. Why shouldn't the analysis engine get the view
>> mapped in the aggregate? If the analysis engine has more input views,
>> then it gets the base view and still can access them in the
>> implementation. It actually has to anyway right now. If it has only one
>> (or only the default view), then it can directly use the given one
>> without a static implementation (getView("name")) or an additional
>> parameter. I think this would enable the creation of better components
>> and I actually have a use case right now.
>>
>>
>>>> So, the best practice is to introduce a parameter for specifying the
>>>> input view? In case that the AE implementation should be used several
>>>> times in an AAE for different views.
>>>>
>>> Many if not most view aware components I've seen do not have a single
>>> input view.
>>
>> Ruta has some, which do not work in pipelines when cascaded.
>>
>> Maybe I missed something, but I do not yet see any reasons why it should
>> get the base view.
>>
>> Peter
>>
>>
>>> Eddie
>>>
>>


Mime
View raw message