Nice ideas: keeping type systems and "lenient" as separate concepts.
It makes more sense to me that specifying "lenient" would not be part of the serialized format, but would rather be a part of the loading (deserializing) API (which is how it is now), because the concept of lenient seems to go with the act of deserializing, and the same serialized form might sometimes be loaded with and without this feature. -Marshall On 7/20/2016 5:51 AM, Richard Eckart de Castilho wrote: > On 20.07.2016, at 11:26, Peter Klügl <[email protected]> wrote: >>>> - do we support type system inclusion in the header? >>> Not sure what you mean by "in the header" vs "in the serialized files". >> We had a header specifying that there is also a serialized type system. >> If I exchange the string header with Header, the information should >> still be present, I think. > Sorry, you lost me ;) > >>>> - do we support type system inclusion in the serialized files? >>> With "serialized", do you mean the "Java serialized files" - or any of the >>> binary files? >> Sp and S6p right now. We could also include it optinally in all formats. > For DKPro Core, I coded it such that > > S+ reinitializes the CAS with the typesystem stored in the file. > > 6+ uses the typesystem information stored in the file to support lenient > loading. > I.e. types present in the binary form but not in the target CAS are ignored > during > loading. It does *not* change the typesystem in the CAS. > > Lenient loading and CAS reinitialization are orthogonal. > > We could support storing TS information in all file formats. But then we need > some parameter which controls whether the typesystem information should be: > > - ignored > - used for lenient loading > - used to reinitialize the TS in the CAS > > Cheers, > > -- Richard
