You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Peter Klügl <pk...@uni-wuerzburg.de> on 2014/04/17 14:04:54 UTC
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
Re: Sofa-unaware AEs that create new views in an AAE
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 17.04.2014 15:39, schrieb Richard Eckart de Castilho:
> On 17.04.2014, at 15:31, Peter Klügl <pk...@uni-wuerzburg.de> 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
Posted by Mog <mo...@crydee.eu>.
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 <pk...@uni-wuerzburg.de> 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
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 17.04.2014, at 15:31, Peter Klügl <pk...@uni-wuerzburg.de> 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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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.
<?xml version="1.0" encoding="UTF-8"?>
<analysisEngineDescription xmlns="http://uima.apache.org/resourceSpecifier">
<frameworkImplementation>org.apache.uima.java</frameworkImplementation>
<primitive>false</primitive>
<delegateAnalysisEngineSpecifiers>
<delegateAnalysisEngine key="CWEngine">
<import location="CWEngine.xml"/>
</delegateAnalysisEngine>
<delegateAnalysisEngine key="SWEngine">
<import location="SWEngine.xml"/>
</delegateAnalysisEngine>
<delegateAnalysisEngine key="SimpleEngine">
<import location="SimpleEngine.xml"/>
</delegateAnalysisEngine>
<delegateAnalysisEngine key="ModifierCW">
<import location="ModifierCW.xml"/>
</delegateAnalysisEngine>
<delegateAnalysisEngine key="ModifierSW">
<import location="ModifierSW.xml"/>
</delegateAnalysisEngine>
</delegateAnalysisEngineSpecifiers>
<analysisEngineMetaData>
<name>AAE</name>
<description/>
<version>1.0</version>
<vendor/>
<configurationParameters/>
<configurationParameterSettings/>
<flowConstraints>
<fixedFlow>
<node>CWEngine</node>
<node>ModifierCW</node>
<node>SWEngine</node>
<node>ModifierSW</node>
<node>SimpleEngine</node>
</fixedFlow>
</flowConstraints>
<fsIndexCollection/>
<capabilities>
<capability>
<inputs/>
<outputs/>
<inputSofas>
<sofaName>input</sofaName>
</inputSofas>
<outputSofas>
<sofaName>norm_1_out</sofaName>
<sofaName>norm_2_out</sofaName>
</outputSofas>
<languagesSupported/>
</capability>
</capabilities>
<operationalProperties>
<modifiesCas>true</modifiesCas>
<multipleDeploymentAllowed>true</multipleDeploymentAllowed>
<outputsNewCASes>true</outputsNewCASes>
</operationalProperties>
</analysisEngineMetaData>
<resourceManagerConfiguration/>
<sofaMappings>
<sofaMapping>
<componentKey>ModifierCW</componentKey>
<componentSofaName>out</componentSofaName>
<aggregateSofaName>norm_1_out</aggregateSofaName>
</sofaMapping>
<sofaMapping>
<componentKey>ModifierSW</componentKey>
<aggregateSofaName>norm_1_out</aggregateSofaName>
</sofaMapping>
<sofaMapping>
<componentKey>SWEngine</componentKey>
<aggregateSofaName>norm_1_out</aggregateSofaName>
</sofaMapping>
<sofaMapping>
<componentKey>ModifierSW</componentKey>
<componentSofaName>out</componentSofaName>
<aggregateSofaName>norm_2_out</aggregateSofaName>
</sofaMapping>
<sofaMapping>
<componentKey>SimpleEngine</componentKey>
<aggregateSofaName>norm_2_out</aggregateSofaName>
</sofaMapping>
<sofaMapping>
<componentKey>CWEngine</componentKey>
<aggregateSofaName>input</aggregateSofaName>
</sofaMapping>
<sofaMapping>
<componentKey>ModifierCW</componentKey>
<aggregateSofaName>input</aggregateSofaName>
</sofaMapping>
</sofaMappings>
</analysisEngineDescription>
Re: Sofa-unaware AEs that create new views in an AAE
Posted by Richard Eckart de Castilho <re...@apache.org>.
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 <pk...@uni-wuerzburg.de> wrote:
> Am 17.04.2014 15:02, schrieb Richard Eckart de Castilho:
>> On 17.04.2014, at 14:04, Peter Klügl <pk...@uni-wuerzburg.de> 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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 17.04.2014 15:02, schrieb Richard Eckart de Castilho:
> On 17.04.2014, at 14:04, Peter Klügl <pk...@uni-wuerzburg.de> 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
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 17.04.2014, at 14:04, Peter Klügl <pk...@uni-wuerzburg.de> 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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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 <pk...@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
>>
Re: Sofa-unaware AEs that create new views in an AAE
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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 <pk...@uni-wuerzburg.de>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
Posted by Eddie Epstein <ea...@gmail.com>.
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 <pk...@uni-wuerzburg.de>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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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 <pk...@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 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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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 <pk...@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 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
Posted by Eddie Epstein <ea...@gmail.com>.
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 <pk...@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 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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 18.04.2014 15:23, schrieb Eddie Epstein:
> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl <pk...@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
>
Re: Sofa-unaware AEs that create new views in an AAE
Posted by Eddie Epstein <ea...@gmail.com>.
On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl <pk...@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.
> 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
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
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 <pk...@uni-wuerzburg.de>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
Posted by Eddie Epstein <ea...@gmail.com>.
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 <pk...@uni-wuerzburg.de>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
>
>
>