We are planning to handle our HPSG related things in the UIMA framework. The types in the HPSG feature structure require multiple inheritances. This is one of the reasons why we need multiple inheritances.
The other reason is that multiple inheritances would be suitable to express concepts which are difficult to be a single tree structured type hierarchy. There could be various interpretations to essentially same entities/concepts. The multiple inheritances would be the straight forward way to express such various interpretations at the same time. If it is better to wait for the release of OASIS spec, I will try to make a temporal way to define the multiple inheritances out of the UIMA type systems, and prepare conversions into the UIMA type systems later when Apache UIMA becomes to support it (although I don't prefer this sort of ad hoc solutions). Yoshinobu Thilo Goetz wrote: > Possible, yes. Can you tell us a bit more why you think this is an > important requirement (and not just a nice-to-have)? > > --Thilo > > KANO, Yoshinobu wrote: >> Thank you for your replies. >> This design proposal is fine for me. >> Is it possible to implement the multiple inheritances for Apache UIMA in >> this way? >> >> Yoshinobu >> >> J. William Murdock wrote: >>> I think it could be done in a way that was weakly backward compatible >>> with the following design: >>> >>> 1) Leave the existing JCas implementation alone, deprecate it, and >>> impose a rule that types that use multiple inheritance cannot be >>> accessed via JCas. >>> >>> 2) Create a new JCas-like mechanism with a new name (e.g., "MultiJCas"), >>> that provides the capabilities of JCas and also multiple inheritance (by >>> implementing the individual types in the type system as interfaces, and >>> generating copies of code when needed, as per EMF). >>> >>> This is only weakly backward compatible, in that it imposes some serious >>> obstacles to anyone hoping to add multiple inheritance to an existing >>> component without modifying their code much; however, it would (I >>> believe) at least satisfy the minimal requirements that (a) existing >>> systems that work would continue to work, and (b) someone building new >>> systems can use multiple inheritance. >>> >>> If an approach like that is taken, then presumably this would be a good >>> opportunity to reassess other aspects of the design of JCas based on >>> accumulated user experience since the original JCas design (since the >>> "MultiJCas" would not need to be backward compatible). >>> >>> - Bill Murdock (IBM internal UIMA user but not a UIMA framework >>> developer or official spokesperson) >>> > -- Yoshinobu KANO [EMAIL PROTECTED] Tsujii Laboratory, the University of Tokyo
