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:05:08 GMT
I think there is no problem at all after I noticed that the analysis
engine can use its local names of the views. I cannot use an arbitrary
input view, but the initialView. It's not what I preferred, but it
solves my problem.

Sorry about the inconveniences.



Am 22.04.2014 12:47, schrieb Peter Klügl:
> 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

View raw message