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 10:47:21 GMT
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.


> Eddie

View raw message