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:26:45 GMT
Am 22.04.2014 18:20, schrieb Peter Klügl:
> 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?

Well, yes, if the analysis engine specifies no input views. I think that
would be reasonable and a better solution since the aggregate can only
map to that view.


> 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
>>>>> 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

View raw message