Mailing-List: contact user-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@uima.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4F63498C.9010506@cs.cmu.edu>
Date: Fri, 16 Mar 2012 10:09:16 -0400
From: Eric Riebling <er1k@cs.cmu.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: user@uima.apache.org
Subject: Re: Getting annotations from CASes 'external' to a pipeline
References: <4F61FECE.1090009@cs.cmu.edu> <4F622BD5.8080704@schor.com>
 <4F6238A0.60203@cs.cmu.edu>
 <CAGRYgEN8kYZtH=P=CLF05OaQZQu4fFkwiwzY6kQO=g4fi-WUTg@mail.gmail.com>
 <4F626643.1040905@schor.com>
 <CAGRYgEPitZtTpGSyLRLPWc-FimLgNHbeDmeNgX+wvE6DePuEvA@mail.gmail.com>
In-Reply-To: 
 <CAGRYgEPitZtTpGSyLRLPWc-FimLgNHbeDmeNgX+wvE6DePuEvA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Interesting things to note:

  * When I run a CPE with XMI Collection Reader, the CAS being passed
	into getNext() already has the type system of the XMI being
	deserialized - so it works

  * XMICasDeserializer as used in XMI collection Reader doesn't
	even instantiate a deserializer with a type system, it's
	used in a static way.

  * When I use a CAS created with getEmpty(j)Cas() the CAS that's
	about to be populated does NOT have the type system of the
	XMI I'm trying to deserialize... which is why it DOESN'T
	work

  * Using a deserializer instantiated with a type system doesn't
	seem to do the right thing.  Even though the deserializer
	is given a type system to use, if the CAS being deserialized
	into doesn't already also have that type system, the types
	go ignored.  Or I don't understand the purpose of giving a
	typesystem to a deserializer. :)

I know the lenient parameter is supposed to not throw exceptions
and ignore unknown types.  I think what's happening in my case is
that almost ALL the types are unknown types, they DO get ignored,
and so I don't get annotations.

What I'm looking for now is some way to create an empty (or even full!)
CAS into which to deserialize that DOES have our typesystem.  Then it
ought to work, like it does when I use the CAS from process(), because
it DOES have our typesystem.

Interesting.


On 3/15/2012 6:50 PM, Eddie Epstein wrote:
> My last note was incorrect. Here is a paraphrase of working code:
>
>    public AbstractCas next() throws AnalysisEngineProcessException {
>      CAS aCAS = getEmptyCAS();
>      try {
>        ByteArrayInputStream casIn = getNextXmiCas();
>        XmiCasDeserializer.deserialize(casIn, aCAS, true); //
> deserialize in a lenient fashion
>        return aCAS;
>      } catch (SAXException e) {
>        throw new AnalysisEngineProcessException(e);
>      } catch (IOException e) {
>        throw new AnalysisEngineProcessException(e);
>      }
> ...
>
>
> On Thu, Mar 15, 2012 at 5:59 PM, Marshall Schor<msa@schor.com>  wrote:
>>
>>
>> On 3/15/2012 4:38 PM, Eddie Epstein wrote:
>>>
>>> Cannot deserialize into a CAS from getEmptyCas().
>>
>> This is not right.  More information soon (ran out of time today). -Marshall
>>
>>> Must use a CAS from
>>> CasCreationUtils.createCas for deserialization, and then use casCopier
>>> to copy to the CAS from getEmptyCas().
>>>
>>> Pick the version of createCas that specifies a typesystem, and use the
>>> typesystem from the pipeline CAS (i.e. the one from getEmptyCas).
>>>
>>> On Thu, Mar 15, 2012 at 2:44 PM, Eric Riebling<er1k@cs.cmu.edu>    wrote:
>>>>
>>>> Thanks, guys.  This is getting me closer to the goal, and explains the
>>>> observed
>>>> behaviors.  Now I'm facing issues when implemented as a CAS Multiplier.
>>>>   I
>>>> try
>>>> creating a new CAS first with getEmptyJCas().
>>>>
>>>> Here are some various strategies and what resulted:
>>>>
>>>>   * create a deserializer with the typesystem from the AE (which
>>>>         includes types in the 'external' CAS to be deserialized)
>>>>   * ues it to deserialize into the empty CAS created with getEmptyJCas()
>>>>
>>>>   ->    The deserialized CAS for some reason has only the base TOP
>>>> typesystem
>>>>   ->    Trying to access an annotation from an index (that should be there)
>>>>     generates the "used in Java code,  but was not declared in the XML
>>>> type
>>>> descriptor"
>>>>         exception
>>>>
>>>>   * same as above, but use CasCopier to try and copy the type system
>>>>         (and everything else) from the CAS in the AE's process() method
>>>>           into the empty CAS
>>>>
>>>>   ->    Attempted to copy a FeatureStructure of type "(my type name)", which
>>>> is
>>>> not defined in the type system of the destination CAS.
>>>>
>>>> It seems the ONLY way to obtain a CAS (empty or otherwise) that has the
>>>> type
>>>> system able
>>>> to accept the external CAS being deserialized is to use the very CAS
>>>> passed
>>>> into
>>>> the AE's process() method.  Doing so obviously mangles that CAS for the
>>>> rest
>>>> of
>>>> the pipeline.
>>>>
>>>>
>>>> On 3/15/2012 1:50 PM, Marshall Schor wrote:
>>>>>
>>>>>
>>>>> On 3/15/2012 10:38 AM, Eric Riebling wrote:
>>>>>>
>>>>>> I have a pipeline with it's own type system.
>>>>>> I also have deserialized, annotated CASes on disk with a different type
>>>>>> system.
>>>>>> Suppose I want an Analysis Engine in the pipeline to read in the
>>>>>> deserialized
>>>>>> CASes in order to obtain annotations and 'do things with them'
>>>>>>
>>>>>> I understand some limitations in the UIMA framework prevent this, but
>>>>>> could it be done by making the first type system include that of the
>>>>>> CASes to deserialize?
>>>>>
>>>>> Yes, I think so.
>>>>>>
>>>>>>
>>>>>> Also, it would necessitate creating new CASes within the Analysis
>>>>>> Engine.
>>>>>> I could think of several approaches, and have tried some without
>>>>>> success:
>>>>>>
>>>>>> * Create a new, 'temporary' View in the AE's process() method, obtain a
>>>>>> JCas, obtain it's CAS, and use that to store the deserialized CASes
>>>>>> (seems to mangle the original CAS and break downstream AEs in the
>>>>>> pipeline,
>>>>>> and seems to not be able to find any annotations in the deserialized
>>>>>> CAS)
>>>>>>
>>>>> This won't work. The deserialize method effectively "resets" the CAS
>>>>> before loading it.
>>>>> A view is not a new CAS; it is a new view of the same CAS.
>>>>>
>>>>>> * Use the CAS in the process() method to store the deserialized CASes
>>>>>> (also mangles the original CAS, breaks downstream AEs, but DOES
>>>>>> permit obtaining annotations from the deserialized CASes)
>>>>>
>>>>> Right, deserializing into an existing CAS resets it in flight.
>>>>>>
>>>>>>
>>>>>> * Make the Analysis Engine be a CAS Multiplier, and deserialize into
>>>>>> a CAS created with createEmtpyCas()
>>>>>> (I haven't tried this yet)
>>>>>
>>>>> Yes, this is the way to get a separate CAS instance to deserialize into.
>>>>> It's how Collection Readers do it.
>>>>> -Marshall
>>>>>>
>>>>>>
>>>>>> It's kind of a use case for a hybrid Component that behaves in some
>>>>>> ways
>>>>>> like
>>>>>> an AE (has a process() method), in some ways like XMI Collection
>>>>>> Reader,
>>>>>> and
>>>>>> in some ways like a CAS Multiplier.
>>>>>>
>>>>>> But it's a useful use case! It is also a very bizarre one becuase you
>>>>>> could
>>>>>> almost think of it as a pipeline within a pipeline, which processes a
>>>>>> set
>>>>>> of deserialized annotated XMI documents, within a pipeline that
>>>>>> processes
>>>>>> ...
>>>>>> in our case, a Question Answering system with question keyterms,
>>>>>> ranked lists of documents and answer candidates.
>>>>>>
>>
>