Re: Sofa-unaware AEs that create new views in an AAE
Thanks :-) Peter Am 23.04.2014 00:07, schrieb Eddie Epstein: > I think so too. Have created > https://issues.apache.org/jira/browse/UIMA-3765to cover this work. > > Eddie > > > On Tue, Apr 22, 2014 at 12:26 PM, Peter Klügl wrote: > >> 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 >> >> >>
Re: Sofa-unaware AEs that create new views in an AAE
I think so too. Have created https://issues.apache.org/jira/browse/UIMA-3765to cover this work. Eddie On Tue, Apr 22, 2014 at 12:26 PM, Peter Klügl wrote: > 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 > > >
Re: Sofa-unaware AEs that create new views in an AAE
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 wrote: >> >>> Am 18.04.2014 15:23, schrieb Eddie Epstein: On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl >>> 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
Re: Sofa-unaware AEs that create new views in an AAE
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 wrote: > >> Am 18.04.2014 15:23, schrieb Eddie Epstein: >>> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl >> 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 >>> >>
Re: Sofa-unaware AEs that create new views in an AAE
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? Eddie On Tue, Apr 22, 2014 at 6:47 AM, Peter Klügl wrote: > Am 18.04.2014 15:23, schrieb Eddie Epstein: > > On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl >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 > > > >
Re: Sofa-unaware AEs that create new views in an AAE
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. Best, Peter 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 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 >>
Re: Sofa-unaware AEs that create new views in an AAE
Am 18.04.2014 15:23, schrieb Eddie Epstein: > On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl 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 >
Re: Sofa-unaware AEs that create new views in an AAE
On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl 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. > 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. > > 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. > > Peter > Many if not most view aware components I've seen do not have a single input view. Eddie
Re: Sofa-unaware AEs that create new views in an AAE
Am 17.04.2014 15:39, schrieb Richard Eckart de Castilho: > On 17.04.2014, at 15:31, Peter Klügl wrote: > >> That would work, if the modifier AEs that create new views are not cascaded. > Btw: I think it would be great if UIMA did offer a mechanism that would > allow an AE to redefine the default view without external sofa mapping. > > E.g. AE1 runs, creates a new view and wants that this view is subsequently > the default. It would call cas.setDefaultView("newView"). Then AE2 would > get that view as default, etc. > > It can be done using an external sofa-mapping, but the longer the cascade > gets, the more annoying it is to set up local and global names and to > make the mapping explicit. Sounds nice, but I think it can be a bit confusing if those components are used in an normal AAE. Peter > -- Richard >
Re: Sofa-unaware AEs that create new views in an AAE
The fact that views are "immutable" is also valuable though. To me, the fact that you can't rearrange views easily is similar to the fact that you can't change the text of a document once it's set: even if it was doable, it would make processes less observable and less robust in the end. Best, Hugo On 04/17/2014 10:39 PM, Richard Eckart de Castilho wrote: > On 17.04.2014, at 15:31, Peter Klügl wrote: > >> That would work, if the modifier AEs that create new views are not cascaded. > > Btw: I think it would be great if UIMA did offer a mechanism that would > allow an AE to redefine the default view without external sofa mapping. > > E.g. AE1 runs, creates a new view and wants that this view is subsequently > the default. It would call cas.setDefaultView("newView"). Then AE2 would > get that view as default, etc. > > It can be done using an external sofa-mapping, but the longer the cascade > gets, the more annoying it is to set up local and global names and to > make the mapping explicit. > > -- Richard >
Re: Sofa-unaware AEs that create new views in an AAE
On 17.04.2014, at 15:31, Peter Klügl wrote: > That would work, if the modifier AEs that create new views are not cascaded. Btw: I think it would be great if UIMA did offer a mechanism that would allow an AE to redefine the default view without external sofa mapping. E.g. AE1 runs, creates a new view and wants that this view is subsequently the default. It would call cas.setDefaultView("newView"). Then AE2 would get that view as default, etc. It can be done using an external sofa-mapping, but the longer the cascade gets, the more annoying it is to set up local and global names and to make the mapping explicit. -- Richard
Re: Sofa-unaware AEs that create new views in an AAE
Am 17.04.2014 15:18, schrieb Richard Eckart de Castilho: > Have a look at this thread. I believe to have discussed the same general > issue with Luca there: > > http://markmail.org/thread/dgwku65srpvqdvdr > > At least, maybe that helps to better pinpoint the problem. That would work, if the modifier AEs that create new views are not cascaded. I added a simple AAE created for investigating the problem at the end. Maybe I did something wrong, but I tested different variants and debugged the UIMA implementation. There are five AEs: - CWEngine: a simple Ruta script (input=input of AAE) - ModifierCW: Ruta modifier that creates a new view (input=input of AAE, output=norm_1_out) - SWEngine: a simple Ruta script (input=norm_1_out) - ModifierSW: Ruta modifier that creates a new view (input=norm_1_out, output=norm_2_out) - SimpleEngine: a simple Ruta script (input=norm_2_out) ModifierCW works since it uses the default view, but ModifierSW fails because it gets also the default view despite the mapping. http://uima.apache.org/resourceSpecifier";> org.apache.uima.java false AAE 1.0 CWEngine ModifierCW SWEngine ModifierSW SimpleEngine input norm_1_out norm_2_out true true true ModifierCW out norm_1_out ModifierSW norm_1_out SWEngine norm_1_out ModifierSW out norm_2_out SimpleEngine norm_2_out CWEngine input ModifierCW input
Re: Sofa-unaware AEs that create new views in an AAE
btw, here's the StackOverflow question that caused me to investigate the problem: http://stackoverflow.com/questions/23002788/uima-ruta-sofa-mapping-in-aggregate-pipeline Peter Am 17.04.2014 14:04, schrieb Peter Klügl: > Hi, > > as I understand the implementation, an AE is sofa aware if it specifies > input or output views in its capabilities. Let's say it only specifies > an output view, so it's sofa aware. If it is part of an AAE with sofa > mapping (one AAE sofa mapped to the default input view of the AE), then > it get passed the base CAS independently of the sofa mapping. Shouldn't > it get the view mapped in the AAE? > > I have a simple AE that should just get the mapped sofa as input and > then should create a new view, which name is given by a parameter. Is > it correct that I have to introduce another parameter for the input view > and have to "getView" in the AE? Is there no way to just use the mapped > sofa? > > Best, > > Peter >
Re: Sofa-unaware AEs that create new views in an AAE
Have a look at this thread. I believe to have discussed the same general issue with Luca there: http://markmail.org/thread/dgwku65srpvqdvdr At least, maybe that helps to better pinpoint the problem. -- Richard On 17.04.2014, at 15:11, Peter Klügl wrote: > Am 17.04.2014 15:02, schrieb Richard Eckart de Castilho: >> On 17.04.2014, at 14:04, Peter Klügl wrote: >> >>> Hi, >>> >>> as I understand the implementation, an AE is sofa aware if it specifies >>> input or output views in its capabilities. Let's say it only specifies >>> an output view, so it's sofa aware. If it is part of an AAE with sofa >>> mapping (one AAE sofa mapped to the default input view of the AE), then >>> it get passed the base CAS independently of the sofa mapping. Shouldn't >>> it get the view mapped in the AAE? >> It should be able to get the mapped views by the mapped names instead >> of by whatever original name they have. >> > > What do you mean exactly? It is maybe possible, or it should be > possible? Investigating the metadata in the process() method? > > >> I guess you ask whether it should get the defaultView because the >> input view is unmapped? > > > It doesn't get the mapped view, but the base view, which is the > _InitialView if the AAE uses it. If the AAE uses some arbitrary input > view, it gets an empty sofa. > > >> >>> I have a simple AE that should just get the mapped sofa as input and >>> then should create a new view, which name is given by a parameter. Is >>> it correct that I have to introduce another parameter for the input view >>> and have to "getView" in the AE? Is there no way to just use the mapped >>> sofa? >> Well, what do you map it to? The mapping allows you to have a global set >> of view names and a set of local view names for each component. E.g. >> your component should postulate that it expects the input data in a view >> called "INPUT" (hardcoded - no parameter). Then you use a sofa mapping to >> map a global view name to the local name "INPUT" on your AE. > > Hmm, maybe I do not understand you. "INPUT" would be the name of the > view that is accessed in the process() method? Do you mean with > postulate the capabilities? > > If the AE should be able to operate on different input views, e.g., > because there are several of those AEs in one AAE, then this would lead > again to a parameter specifying "INPUT". > > Peter > > >> -- Richard >
Re: Sofa-unaware AEs that create new views in an AAE
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? 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. 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. Peter > Eddie > > > > On Thu, Apr 17, 2014 at 8:04 AM, Peter Klügl wrote: > >> Hi, >> >> as I understand the implementation, an AE is sofa aware if it specifies >> input or output views in its capabilities. Let's say it only specifies >> an output view, so it's sofa aware. If it is part of an AAE with sofa >> mapping (one AAE sofa mapped to the default input view of the AE), then >> it get passed the base CAS independently of the sofa mapping. Shouldn't >> it get the view mapped in the AAE? >> >> I have a simple AE that should just get the mapped sofa as input and >> then should create a new view, which name is given by a parameter. Is >> it correct that I have to introduce another parameter for the input view >> and have to "getView" in the AE? Is there no way to just use the mapped >> sofa? >> >> Best, >> >> Peter >> >> >>
Re: Sofa-unaware AEs that create new views in an AAE
Am 17.04.2014 15:02, schrieb Richard Eckart de Castilho: > On 17.04.2014, at 14:04, Peter Klügl wrote: > >> Hi, >> >> as I understand the implementation, an AE is sofa aware if it specifies >> input or output views in its capabilities. Let's say it only specifies >> an output view, so it's sofa aware. If it is part of an AAE with sofa >> mapping (one AAE sofa mapped to the default input view of the AE), then >> it get passed the base CAS independently of the sofa mapping. Shouldn't >> it get the view mapped in the AAE? > It should be able to get the mapped views by the mapped names instead > of by whatever original name they have. > What do you mean exactly? It is maybe possible, or it should be possible? Investigating the metadata in the process() method? > I guess you ask whether it should get the defaultView because the > input view is unmapped? It doesn't get the mapped view, but the base view, which is the _InitialView if the AAE uses it. If the AAE uses some arbitrary input view, it gets an empty sofa. > >> I have a simple AE that should just get the mapped sofa as input and >> then should create a new view, which name is given by a parameter. Is >> it correct that I have to introduce another parameter for the input view >> and have to "getView" in the AE? Is there no way to just use the mapped >> sofa? > Well, what do you map it to? The mapping allows you to have a global set > of view names and a set of local view names for each component. E.g. > your component should postulate that it expects the input data in a view > called "INPUT" (hardcoded - no parameter). Then you use a sofa mapping to > map a global view name to the local name "INPUT" on your AE. Hmm, maybe I do not understand you. "INPUT" would be the name of the view that is accessed in the process() method? Do you mean with postulate the capabilities? If the AE should be able to operate on different input views, e.g., because there are several of those AEs in one AAE, then this would lead again to a parameter specifying "INPUT". Peter > -- Richard
Re: Sofa-unaware AEs that create new views in an AAE
On 17.04.2014, at 14:04, Peter Klügl wrote: > Hi, > > as I understand the implementation, an AE is sofa aware if it specifies > input or output views in its capabilities. Let's say it only specifies > an output view, so it's sofa aware. If it is part of an AAE with sofa > mapping (one AAE sofa mapped to the default input view of the AE), then > it get passed the base CAS independently of the sofa mapping. Shouldn't > it get the view mapped in the AAE? It should be able to get the mapped views by the mapped names instead of by whatever original name they have. I guess you ask whether it should get the defaultView because the input view is unmapped? > I have a simple AE that should just get the mapped sofa as input and > then should create a new view, which name is given by a parameter. Is > it correct that I have to introduce another parameter for the input view > and have to "getView" in the AE? Is there no way to just use the mapped > sofa? Well, what do you map it to? The mapping allows you to have a global set of view names and a set of local view names for each component. E.g. your component should postulate that it expects the input data in a view called "INPUT" (hardcoded - no parameter). Then you use a sofa mapping to map a global view name to the local name "INPUT" on your AE. -- Richard
Re: Sofa-unaware AEs that create new views in an AAE
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. Eddie On Thu, Apr 17, 2014 at 8:04 AM, Peter Klügl wrote: > Hi, > > as I understand the implementation, an AE is sofa aware if it specifies > input or output views in its capabilities. Let's say it only specifies > an output view, so it's sofa aware. If it is part of an AAE with sofa > mapping (one AAE sofa mapped to the default input view of the AE), then > it get passed the base CAS independently of the sofa mapping. Shouldn't > it get the view mapped in the AAE? > > I have a simple AE that should just get the mapped sofa as input and > then should create a new view, which name is given by a parameter. Is > it correct that I have to introduce another parameter for the input view > and have to "getView" in the AE? Is there no way to just use the mapped > sofa? > > Best, > > Peter > > >
Sofa-unaware AEs that create new views in an AAE
Hi, as I understand the implementation, an AE is sofa aware if it specifies input or output views in its capabilities. Let's say it only specifies an output view, so it's sofa aware. If it is part of an AAE with sofa mapping (one AAE sofa mapped to the default input view of the AE), then it get passed the base CAS independently of the sofa mapping. Shouldn't it get the view mapped in the AAE? I have a simple AE that should just get the mapped sofa as input and then should create a new view, which name is given by a parameter. Is it correct that I have to introduce another parameter for the input view and have to "getView" in the AE? Is there no way to just use the mapped sofa? Best, Peter