I guess we've always (probably incorrectly) thought that those use-cases which wanted unique, fixed identifiers for every feature structure would just add them as a feature, with whatever kind of id was wanted...
-Marshall On 8/11/2016 4:44 PM, Richard Eckart de Castilho wrote: > 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
