uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}
Date Wed, 10 Jan 2018 20:15:51 GMT
> Some use cases with comments:
> 1) Type T loaded with features f1, f2, f3,  JCas loaded with f1, f2, f3
> Followed by: Type T loaded with features f1, f3.
> This causes at the 2nd Type T commit time, the augmentation of type T with
> feature f2.
> But, the (current) impl just does an "addFeature" API call.  The result is that
> without extra work, the features in the type system will be ordered as f1, f3,
> f2.  And the assigned offsets could be different. 
> To fix this, the algorithm which assigns offsets will need to see if the
> corresponding JCas class (if any) has offsets already assigned, and try to use
> those.

This is why I suggested to use "JCas first": the order of the features should be
defined by the JCas (i.e. they come first) while features defined in other TSDs
get appended after that.

> 2) Type T having supertype TS; Type T has 1 feature, f1, JCas for Type T has 1
> feature f1.  TS has no features, no JCas for TS or JCas for TS has no features. 
> Followed by: Type TS is loaded, having one feature (not in the JCas if there is
> one for TS).
> This causes the features for type T (which includes all the features of its
> supertype), to have offsets shifted down.
> For example if T has feature f1 with offset "3",  it would now have offset "4"
> (accounting for the space taken by the TS feature).

I believe this could also be resolved by using "JCas first": first all the slots
for features defined in any of the JCas classes in the inheritance hierarchy
are assigned and afterwards the features define in other TSDs are appended.

I believe that by using "JCas first", the slots for the JCas class features
are always fixed, independent of what other TSDs they are combined with.

Does "JCas first" now sound more sensible?

... or maybe I am misunderstanding something basic (which is entirely possible).


-- Richard

View raw message