On 8/12/2016 11:13 AM, Richard Eckart de Castilho wrote: > On 12.08.2016, at 17:03, Marshall Schor <[email protected]> wrote: >> I don't currently have a plan for this on the V3 branch, but I remember it. >> >> Extending the type system after commit would require changing the way feature >> structures store data, to be more "flexible". This is always a tradeoff vs >> space/performance. There's room to innovate here, I think, to acheive a good >> balance (e.g. no penalty if this flexibility is not used). >> >> Adding types may take some thinking, especially in the general case where >> types >> might be inserted into the hierarchy (and therefore change the hierarchy). > I think just adding as leaves of the inheritance tree would already > help many use-cases, e.g. the ability to add new subtypes of Annotation. Good point, nice tradeoff :-) >> Extensions to arbitrary java objects is partially built into V3. An issue is >> how to serialize/deserialize (in our various formats) these kinds of objects. > I've been looking into GATE a bit recently. They seem to use XStream. > That might be suitable for XML-based formats. For binary formats, either > native Java serialization or alternative serializations (e.g. kryo) might > be suitable. > > I would expect certain limitations. E.g. if the two features refer to two > different Java objects which internally again refer to a common object, > then I would expect that the serialized form contains the common object > twice and upon de-serialization, two copies of the common object will > exist. Not sure if such duplications could be avoided by using a custom > serialization like kryo [2]. Handling references in a graph is important, I think. Of particular concern would be things like a java collection object (e.g. a Set or Map) which contained Feature Structures. We would need to find these as "reachable", etc. in our serialization logic.
-Marshall > > Cheers, > > -- Richard > > [1] http://x-stream.github.io > [2] https://github.com/EsotericSoftware/kryo
