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 Sun, 07 Jan 2018 21:40:35 GMT
Hi,

I think that the answer depends on the meaning of the question :-)

It *is* supported if the question is:

  - step 1, 2, 3, 4 + then starting up a new pipe line in a new class loader.

It is *not* supported, (even in v2) if the question is:

  - step 1, 2, 3, 4 where the JCas classes were loaded with the first type
system description, and then,
    in the same class loader, another type system with the 2nd order is used to
create another CAS.

====================

I thought of another use case which also breaks the assumption I was trying to
exploit in the "fix" where feature offsets get initialized to the next
sequential slot(s).

Suppose Type T is defined with slots f1, f2, at first, but a later type system
has f1, f2, f3, and f4.
Suppose Type Ts is a subtype of Type T, with slots s1, s2.

Now if type T (f1, f2) is loaded, and the JCas has f1, f2, f3, and f4,   slot f3
and f4 are assigned to the (maybe non-existent except for subtype's existence)
next 2 sequential slots.  But if that type system includes Ts, then s1 slot will
overlay f3, and s2 overlays f4.

So a further restriction to make this work is that the Types with extra JCas
slots can't have subtypes...

This use case affects the work-around proposed earlier, where you arrange the
maximal feature type system definition to be loaded first, and the JCas is
loaded against that.   If subsequently different type systems are loaded with
both fewer features for T and subtypes Ts, that same  "overlap" problem happens.

===================
So, I think that with a lot of restrictions, some form of this can be made to
work, but I certainly agree that it's fragile.
===================
I'm wondering how hard it would be to have the different type systems run with
different JCas class loaders.  This probably could be done by only specifying
new class loaders for the "UIMA Extension Class Loaders", which are used to load
the JCas classes and the annotators.

I agree this could be an issue if you need to pass same-named but
differently-defined JCas classes among these different type systems.  If this is
the case, I'd be curious about the semantics - I would guess that only the
"common" part of the JCas class (common to all different type systems) would be
being accessed.  If that's true, I'm wondering if a better approach (but
certainly more work) is to refactor so that this common part is a different
common (unchanging) type?

-Marshall

On 1/7/2018 2:22 PM, Richard Eckart de Castilho wrote:
> On 07.01.2018, at 06:06, Marshall Schor <msa@schor.com> wrote:
>> This only works when the different type definitions for type T keep the slots in
>> the same order, with no omissions.
>> (The JCas initialization for a new type system checks this.)  For example, valid
>> definions for type T would be
>>   T with features (none)
>>   T with features f1
>>   T with features f1, f2
>>   T with features f1, f2, f3
>>   T with features f1, f2, f3, f4
>>   T with features f1, f2, f3, f4, f5 ...
>>
>> You could not have T with features f2, f3  (skipping f1).  And the feature
>> definitions would need to be in this exact order (it would not work for T with
>> features f2, f1).
>>
>> Does this cover the case(s) in WebAnno?
> It might. But it still looks like a rather fragile construction that
> might better be avoided. What does the order of the features depend on?
> Alphanumeric sorting? Order in the JCas class / TSD XML?
>
> Let's say I do this: 
>
> - define a TSD in XML with features in the order f1, f2, f3
> - generate JCas classes from that XML
> - refactor the XML for some reason, reordering the features into f3, f2, f1
> - *not* regenerate the JCas classes (since actually the information content
>   didn't change and the order of fields in Java classes normally don't matter
>   anyway)
>
> Is such a thing supported in v3? Was it supported in v2?
>
> Cheers,
>
> -- Richard
>
>
>


Mime
View raw message