On 12.09.2016, at 13:00, Richard Eckart de Castilho <[email protected]> wrote: > >> The alternative to this would be a type system which is much less static >> (or dynamic) and APIs to write AEs which can adapt well to similar but >> different user defined type systems. This could be achieved by allowing >> type system mappings, by adding explicit support for adapters in the >> framework, allowing dynamic definition of types, >> >> Together with Thilo I wrote a paper which speaks a bit about this topic >> (see at 6.4): >> http://www.aclweb.org/anthology/W14-5209
I never really understood the points about the data serialization (6.1 and 6.3) in that paper, despite having been at the workshop and briefly discussing that after the presentation with Thilo. UIMA natively supports a number of different serialization formats. External component collections add a large number of additional formats. Each of these formats has specific benefits and drawbacks and is therefore best suited for particular uses. My understanding is that you suggest to keep the graph structure as the underlying model. My hypothesis is that any format supporting this graph structure would be at least as complex as the XMI serialization. More specifically, if a JSON serialization would be defined in UIMA, it would end having a quite similar structure as the XMI - actually, that is what happened in the JSON serializer that Marshall has implemented. The paper does unfortunately not describe what type of JSON dialect you imagine to define that would not inherit the type of structural complexity that XMI exposes. I also don't get the critique about being more relaxed in serialization (6.3). You are probably aware that various formats supported by UIMA allow lenient loading. What kind of relaxation would you deem necessary beyond that? Best, -- Richard
