On 11.08.2016, at 22:29, Marshall Schor <[email protected]> wrote: > > Yes, it seems to me also, that reinitializing a CAS's type system and index > definition is unusual, and sort of major surgery. It's not clear to me what > happens if this CAS is part of a CAS pool - I suspect things could easily > break > down because there's an assumption made that all CASes in a CAS pool have the > same type system and index definitions.
For a long time, I was hesitant against implementing that - but since I did, I was quite happy with it and ran into surprisingly few problems. But then, me (and most users I know) probably using UIMA very differently than you and your peers :) > So - I'm OK with "dropping this" from the API. > > We're left with: > > a) needing to pass in a 2nd type system (only - not ts + index def) for > supplying the serialized type system to be used for form 6 kind of lenient > deserialization. No other format needs this. > > b) having an anomalous case of the Java Object serialization in CAS Complete > Serialization. If we did remove it from CasIOUtils, I'd definitely add it back to DKPro Core :) But yes, I think we could drop it from the CasIOUtils API. > So - I'm wondering if we can completely drop the CAS Complete Serialization > and > also perhaps the CASManagerSerializer formats from CasIOUtils? If people > want > these forms (I'm not sure why they would), they have other APIs to save / > load them. I can tell you why I specifically use these forms: as far as I can tell, these are the only forms that keep the addresses of FSes in the CAS intact. In WebAnno, we use the FS addresses as IDs that link elements in the UI to the FSes. So e.g. so to get a NamedEntity with ID 532, I just call ll_getFSForRef(532). Since we persist the CAS after each user action, it is important that the addresses remain intact across save/load cycles. I think I tried using COMPRESSED and/or BINARY as an alternative, but found that they discard deleted (non-reachable) annotations and thus the FS addresses change. Btw, I know that I'm deeply in "internal" country here - but it works and implementing something to provide essentially the same functionality but on "public" API seemed hard to impossible to do... and even worse... unnecessary :) That use case is also why I was lobbying for keeping the JCas.getAddress() in UIMAv3 and maybe even add it to the CAS interface (or even keep the (entire) LLCAS API). It is *very* convenient for FSes to have IDs. Cheers, -- Richard
