uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}
Date Fri, 05 Jan 2018 20:29:02 GMT
Hi Richard,

This sounds like an interesting idea - to have the JCas classes (perhaps
augmented with some annotations) serve as additional type definitions.

I believe that the current implementation won't work even if the maximal-feature
definition was loaded first.  This is because the offsets would be computed for
that definition, and then when a subsequent type system was loaded (with fewer
features), the feature offsets would remain the same (for the maximal Features)
but the arrays they would be indexing into would be smaller (the size of the
loaded type system).

So, the only work-around I see at the moment is to use class loader isolation,
reloading the JCas classes each time. 

I'll look more into how to design the a fix around your idea (merging the JCas
imputed type info).

Cheers. -Marshall


On 1/5/2018 2:05 PM, Richard Eckart de Castilho wrote:
> On 05.01.2018, at 17:16, Marshall Schor <msa@schor.com> wrote:
>> Based on Web Annot's use case, I'm thinking thorough alternatives.
> "WebAnno" ;)
>
>> One way to support this would be to have the user code tell the UIMA framework
>> that no reachable instances of JCas classes exist; the user would be responsible
>> for guaranteeing this.
> There may be no way for the user code to know if this is the case or not or to 
> enforce this to be the case. 
>
>> The other choice would be to not support this (because of the inherent dangers)
>> and instead require users having multiple type systems with JCas classes
>> specifying features only in some versions of those type systems, first load the
>> JCas classes with the feature-maximal versions of the types.
>>
>> I think I favor the 2nd approach, as it is much safer. 
>>
>> What do others think we should do?
> The current line of thinking seems to assume that:
>
> 1) a type system definition is loaded (maybe from an XML file)
> 2) a CAS is created using the TSD
> 3) the JCas classes are loaded and are initialized according to the TSD
>
> The suggestion to "first load a feature-maximal version of the types" seems
> to be following that line. I.e. the TSD loaded in 1) should cover all
> the features also covered by the JCas classes.
>
> How about a slightly different approach:
>
> 1) a type system definition is loaded (maybe from an XML file)
> 1a) the JCas classes are loaded and their definitions are merged with the
>     TSD
> 2) a CAS is created using the merged TSD
> 3) the JCas classes are initialized with the now feature-maximal type system
>
> An error would/should be thrown if in step 1a the JCas classes
> and the TSD are inherently incompatible. 
>
> In this case, the JCas classes would be an additional source of type system
> information. Thinking this further, one could even initialize a CAS without
> providing any TSD, simply by having UIMA inspect the available JCas classes
> (e.g. through classpath scanning or by providing the framework with a list
> of classes). To complete this, the JCas classes could be enhanced with
> Java annotations to carry any information included in TSDs which is currently
> not included in a machine-readable way in the JCas classes, e.g. type and
> feature description text. As such, a set of suitably annotated JCas classes
> could be converted to a TSD XML and vice versa.
>
> The above assumes that JCas classes are loaded and initialized eagerly, but 
> probably it could be adapted to a situation where the classes are loaded lazily.
>
> Cheers,
>
> -- Richard
>
>


Mime
View raw message