what is the difference between the "base CAS" view and _InitialView?

[Philip Ogren <ph...@ogren.info>]

I have a component that takes text from the "_InitialView" view, creates 
a second view, and posts a modified version of the text to the second 
view.  I had a unit test that was reading in a JCas from an XMI file and 
running the JCas through my annotator and testing that the text was 
correctly posted to the second view.  Everything was fine.  Later, it 
occurred to me that I should add SofaCapabilities to my annotator which 
I did.  However, my test broke.  The reason seems to be because the JCas 
I get back from the xmi file has the text in the "_InitialView" but the 
jCas passed into my annotator's process method is no longer the 
"_InitialView".  I tracked this down in the debugger and discovered that 
this is due to the following lines of code in PrimitiveAnalysisEngine_impl:

        // Get the right view of the CAS. Sofa-aware components get the 
base CAS.
        // Sofa-unaware components get whatever is mapped to the 
_InitialView.
        CAS view = ((CASImpl) aCAS).getBaseCAS();
        if (!mSofaAware) {
          view = aCAS.getView(CAS.NAME_DEFAULT_SOFA);
        }


So, to make my test work again I simply injected the following line of 
code near the top of the process method of my annotator:

        jCas = jCas.getView(CAS.NAME_DEFAULT_SOFA);
   

This made my problem go away.  However, this seems quite 
unsatisfactory!  Can someone explain to me what the difference is 
between the "base CAS" that I am now getting in my process method and 
the _InitialView CAS that I was getting before?  Are my annotators 
supposed to be aware of this difference.  Any advice and/or insight on 
this would be appreciated.

Thanks,
Philip

Re: what is the difference between the "base CAS" view and _InitialView?

[Eddie Epstein <ea...@gmail.com>]

The base CAS delivered to Sofa aware components has no explicit
view associated with it. The logic is that it is impossible to know the
intent of a sofa aware component and it should use getView as needed.

Sofa unaware components should therefor not declare sofa capabilities.
These components are intended to operate on the view delivered
to the process method as determined by sofa mapping. If there
is no mapping the _InitialView is given to process.

Regards,
Eddie


On Wed, Dec 30, 2009 at 7:18 PM, Philip Ogren <ph...@ogren.info> wrote:
> I have a component that takes text from the "_InitialView" view, creates a
> second view, and posts a modified version of the text to the second view.  I
> had a unit test that was reading in a JCas from an XMI file and running the
> JCas through my annotator and testing that the text was correctly posted to
> the second view.  Everything was fine.  Later, it occurred to me that I
> should add SofaCapabilities to my annotator which I did.  However, my test
> broke.  The reason seems to be because the JCas I get back from the xmi file
> has the text in the "_InitialView" but the jCas passed into my annotator's
> process method is no longer the "_InitialView".  I tracked this down in the
> debugger and discovered that this is due to the following lines of code in
> PrimitiveAnalysisEngine_impl:
>
>       // Get the right view of the CAS. Sofa-aware components get the base
> CAS.
>       // Sofa-unaware components get whatever is mapped to the _InitialView.
>       CAS view = ((CASImpl) aCAS).getBaseCAS();
>       if (!mSofaAware) {
>         view = aCAS.getView(CAS.NAME_DEFAULT_SOFA);
>       }
>
>
> So, to make my test work again I simply injected the following line of code
> near the top of the process method of my annotator:
>
>       jCas = jCas.getView(CAS.NAME_DEFAULT_SOFA);
>
> This made my problem go away.  However, this seems quite unsatisfactory!
>  Can someone explain to me what the difference is between the "base CAS"
> that I am now getting in my process method and the _InitialView CAS that I
> was getting before?  Are my annotators supposed to be aware of this
> difference.  Any advice and/or insight on this would be appreciated.
>
> Thanks,
> Philip
>