You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Thilo Goetz <tw...@gmx.de> on 2007/05/29 11:33:30 UTC

Re: Multiple Inheritances in Type System

KANO, Yoshinobu wrote:
> Hello,
> 
> The UIMA type system should be compliant to ecore/EMF, as far as I know,
> and there are a mapping definition between ecore and Java.
> 
> But the current Apache UIMA implementation does not allow any multiple
> inheritances.
> If we define a second supertype in the definition file,
> UIMA Eclipse plugin will delete it automatically.
> The ECore2UIMATypeSystem converter also does not support real multiple
> inheritances.
> 
> Are there any plan to support multiple inheritances?
> If any, when will it be - roughly speaking, two or three months, or half
> a year?
> 
> best regards,
> 
> Yoshinobu

We don't currently have any plans to add multiple inheritance to the type
system (or at least I don't).  It's not that difficult in principle, as
multiple inheritence at the data level is relatively unproblematic.  There
are a few assumptions about each type having a unique parent strewn through
the code, but nothing major I think.  If anybody wants to work on this,
feel free to make a proposal.

--Thilo

Re: Multiple Inheritances in Type System

Posted by "KANO, Yoshinobu" <ka...@is.s.u-tokyo.ac.jp>.
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
kano@is.s.u-tokyo.ac.jp
Tsujii Laboratory, the University of Tokyo

Re: Multiple Inheritances in Type System

Posted by Thilo Goetz <tw...@gmx.de>.
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)
>>
> 


Re: Multiple Inheritances in Type System

Posted by Adam Lally <al...@alum.rpi.edu>.
On 5/30/07, KANO, Yoshinobu <ka...@is.s.u-tokyo.ac.jp> 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).
> ><snip/>

If creating a new JCas-like mechanism, I think we should carefully
consider aligning it with other (all?) aspects of Ecore, not just
multiple inheritance.  Some of this may require other changes in the
core CAS.

We expect the OASIS UIMA Technical Committee to decide that Ecore is
the type system represetnation for the UIMA spec, so something like
this will probably eventually be necessary for Apache UIMA to comply
with the UIMA spec.  But this raises the question of whether we should
attempt such a major piece of work to align with Ecore before or after
the OASIS TC actually releases a spec (end of this year, hopefully).

-Adam

Re: Multiple Inheritances in Type System

Posted by "KANO, Yoshinobu" <ka...@is.s.u-tokyo.ac.jp>.
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
kano@is.s.u-tokyo.ac.jp
Tsujii Laboratory, the University of Tokyo

Re: Multiple Inheritances in Type System

Posted by "J. William Murdock" <bi...@murdocks.org>.
Thilo Goetz wrote:
> Yes, I hadn't thought of that.  I guess it wouldn't be too hard to do, 
> but
> it would mean a non-backward compatible change I think.  And I don't 
> think
> we're ready for that, at least not in the 2.x branch.

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)


Re: Multiple Inheritances in Type System

Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 5/29/07, Thilo Goetz <tw...@gmx.de> wrote:
>> KANO, Yoshinobu wrote:
>> > Hello,
>> >
>> > The UIMA type system should be compliant to ecore/EMF, as far as I 
>> know,
>> > and there are a mapping definition between ecore and Java.
>> >
>> > But the current Apache UIMA implementation does not allow any multiple
>> > inheritances.
>> > If we define a second supertype in the definition file,
>> > UIMA Eclipse plugin will delete it automatically.
>> > The ECore2UIMATypeSystem converter also does not support real multiple
>> > inheritances.
>> >
>> > Are there any plan to support multiple inheritances?
>> > If any, when will it be - roughly speaking, two or three months, or 
>> half
>> > a year?
>> >
>> > best regards,
>> >
>> > Yoshinobu
>>
>> We don't currently have any plans to add multiple inheritance to the type
>> system (or at least I don't).  It's not that difficult in principle, as
>> multiple inheritence at the data level is relatively unproblematic.  
>> There
>> are a few assumptions about each type having a unique parent strewn 
>> through
>> the code, but nothing major I think.  If anybody wants to work on this,
>> feel free to make a proposal.
>>
> 
> Also JCAS would need to be considered.  Since JCAS cover classes are
> currently classes, not interfaces, there's no way a JCAS cover class
> could have two supertypes.  So I think supporting multiple inheritance
> would also involve a new JCAS design using interfaces.
> 
> -Adam

Yes, I hadn't thought of that.  I guess it wouldn't be too hard to do, but
it would mean a non-backward compatible change I think.  And I don't think
we're ready for that, at least not in the 2.x branch.

--Thilo


Re: Multiple Inheritances in Type System

Posted by Adam Lally <al...@alum.rpi.edu>.
On 5/29/07, Thilo Goetz <tw...@gmx.de> wrote:
> KANO, Yoshinobu wrote:
> > Hello,
> >
> > The UIMA type system should be compliant to ecore/EMF, as far as I know,
> > and there are a mapping definition between ecore and Java.
> >
> > But the current Apache UIMA implementation does not allow any multiple
> > inheritances.
> > If we define a second supertype in the definition file,
> > UIMA Eclipse plugin will delete it automatically.
> > The ECore2UIMATypeSystem converter also does not support real multiple
> > inheritances.
> >
> > Are there any plan to support multiple inheritances?
> > If any, when will it be - roughly speaking, two or three months, or half
> > a year?
> >
> > best regards,
> >
> > Yoshinobu
>
> We don't currently have any plans to add multiple inheritance to the type
> system (or at least I don't).  It's not that difficult in principle, as
> multiple inheritence at the data level is relatively unproblematic.  There
> are a few assumptions about each type having a unique parent strewn through
> the code, but nothing major I think.  If anybody wants to work on this,
> feel free to make a proposal.
>

Also JCAS would need to be considered.  Since JCAS cover classes are
currently classes, not interfaces, there's no way a JCAS cover class
could have two supertypes.  So I think supporting multiple inheritance
would also involve a new JCAS design using interfaces.

-Adam