Bio-objects (was: [Biocorba-l] BSANE and bioCORBA)

[Juha Muilu]

> >
[ --- cut ---]
>Ewan:
> Aha. I am looking at the moment at these files.
> 
> First Comments: (hurried reading because I have to get to somewhere else
> this afternoon).
> 
>    I would not have Identifiable inheriet from Annotable. If anything the
> other way around. Let rich objects be mix-ins from fro Identifiable and
> Annotable

OK. The identifiable is actually rather light weight. One method call
for getting the annotationHolder should not be a problem? 

As a modeling point of view I saw that once you can identify things you
can also start to annotate them and thus these two belongs together. 

I was trying also to separate those but it end up in to cases where I
have to inherit same interfaces more than once. I do not know is this
(diamond inheritance) a bad problem.
Philipp, our C++ guru, please let us know.

> 
>    Annotation should definitely *not* inheriet from Annotable - this sort
> of recursion is going to lead to tears v. quickly (if BioJava is doing
> this then they are going to be heading into trouble as well... ;)).
> 

I took this from bioJava just to be compatible with them. I agree that
the recursion can be misused.

>    I would make AnnotationHolder read-only as well, not just throw
> exception on read-only. WriteableAnnotationHolder could be an inherieted
> class of AnnotationHolder
> 

Good point!

> 
>    I need to revisit CosPropertyService and CosLifeCycle - if I remember
> right they make life a pain in the arse for implementors - I prefer the
> GNOME reference counting system and just a short a simple key - list-value
> system as in BioCorba. I realise this is the sort of friction causing
> thing with an OMG system...
> 

Agreed. Although not sure is the GNOME thing any better. Only thing we
need for sure is the remove method!

> 
>    I've just revisited them and I still don't like them. Long,
> overburdensome and just a general make-life-for-the-implentors diffcult
> with no gain for the client side. Do other people have a view - Brad -
> Jason - take a look at the IDLs and see if you like it.
> 
>    (this reminds me why the Gnome crowd definitely did not use the CORBA
> LifeCycle etc specs for their work - just too much pain for not enough
> gain).

> 
> SeqFeatures:
> 
>     You've dropped a whole set of functionality from SeqFeature that we
> need for GFF and general Bioperl compatiblity
> 
>     I'm not v. keen on the already cooked mixin-s for TextSeqFeature and
> EntitySeqFeature - they don't buy us much? Are they used elsewhere?

Originally I have Annotation interface where the value was stored as a
CORBA any.
After taking with Alan I end up into above solution (which may again end
up into a reinventing
the corba any...). In short: values of annotations should be more that
just strings.

> 
>     I would dispense with SeqFeatureHolder and just have a straight
> forward Seq. (what is the gain? Other SeqFeature holders like...)

We may need more specific query methods for accessing the features. We
can do this easily if Annotation/Feature holder is separated from the
Seq as done in the bioJava (FeatureHolder). I found it as a good idea.
Any comments. 

Problem is that Seq becomes too specialized which may prevent further
extensions if we add the query methods there.

> 
>     I can't see where you hook up the SeqFeatureHolder with the Sequence

It is narrowed from the AnnotationHolder. If sequence has features then
the get_annotations method (inherited frm Annotatable) will return
SeqFeatureHolder

> 
>     We don't have the transfer limit size (from a practical perspective
> important. ORBs have built in string length limits)
> 
> I would *much* prefer the main additional ideas here being
> 
>     (a) well structured identifiers (discuss with Andrew Dalke) and
> 
>     (b) Annotation interface
> 
> added to BioCorba with minor changes to the BioCorba IDL than this
> splitting and complications inside BSANE.  BSANE can then inheriet if it
> wants to from these and add whatever else BSANE wants around and ontop
> of this core sequence stuff shared between BSANE and BioCorba.
> 
> I, for one, and I suspect Jason and others are happy to be flexible but I
> want a *useful*, *implementable* standard, which is where BioCorba is
> starting from. I'd vote for a lean, mean specification which is focused
> mainly on just giving access to well-understood bioinformatics objects as
> exemplified by Bio* projects.
> 

We have same the goals and we should work together to get the extensions
right and hopefully have the one IDL.

> 
> > Alan has also made lot of work with the new bioCORBA version trying to
> > approach consensus from the bioCORBA side.
> >
> 
> Yup. The location model is now in sync.
> 
> > >
> > > Would this suit everyone?
> > >
> > > -----------------------------------------------------------------
> > > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> > > <birney@ebi.ac.uk>.
> > > -----------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Biocorba-l mailing list
> > > Biocorba-l@biocorba.org
> > > http://www.biocorba.org/mailman/listinfo/biocorba-l
> >
> > --
> >  +--------------------------------------------------------------------+
> >  |Juha Muilu, Ph.D., EMBL Outstation| Email:  muilu@ebi.ac.uk         |
> >  |European Bioinformatics Institute | Phone:  +44 (0)1223 494 624     |
> >  |Wellcome Trust Genome Campus      | Fax:    +44 (0)1223 494 468     |
> >  |Hinxton, Cambridge CB10 1SD, UK   | http://industry.ebi.ac.uk/~muilu|
> >  +--------------------------------------------------------------------+
> >
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>.
> -----------------------------------------------------------------

-- 
 +--------------------------------------------------------------------+
 |Juha Muilu, Ph.D., EMBL Outstation| Email:  muilu@ebi.ac.uk         |
 |European Bioinformatics Institute | Phone:  +44 (0)1223 494 624     |
 |Wellcome Trust Genome Campus      | Fax:    +44 (0)1223 494 468     |
 |Hinxton, Cambridge CB10 1SD, UK   | http://industry.ebi.ac.uk/~muilu|
 +--------------------------------------------------------------------+