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. Peter > 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 <[email protected]>wrote: >> >>> Am 18.04.2014 15:23, schrieb Eddie Epstein: >>>> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl <[email protected] >>>> 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 >>>>
