[Biocorba-l] BSANE and bioCORBA
Ewan Birney
birney@ebi.ac.uk
Thu, 31 May 2001 12:59:03 +0100 (BST)
On Thu, 31 May 2001, Juha Muilu wrote:
> Ewan,
> Thanks for the response!
>
> Ewan Birney wrote:
> >
> > I think the sensible proposal is that BioCorba 0.3 is equivalent to the
> > Sequence core of BSANE - does this sound ok to people? I guess I think
> >
> > Jason
> > Alan
> > Brad
> > (ideally Matt)
> >
> > should say yes first to this before we go for it. We also need a proposal
> > from Juha for BioCorba 0.3 that we can kick around...
>
> How does the models I have on my web-pages look like?
>
> Perhaps we should first start discussion what is missing or is too much
> in the current models. Step by step. Our wish list is to have at least:
> - Proper identifiers. we have found model used in the CosNaming
> services good
I have to revisit this. We might want to bring this up at BOSC as Andrew
Dalke wants to push for a URI style syntax for identifiers.
Ok in principle. Devil is in the details.
> - Other kind of annotations besides the seq features (also the
> value should
> be any)
We need an annotation object which has to be quite flexible.
> - Have a high level entity (currently named as Identifiable),
> which can be used with the annotations.
Probably good
> - Composite sequence locations
>
Already got.
> >
> > I don't want to force BioCorba development into the OMG development model
> > of voting etc because I think it sucks, but I am more than happy to bend
> > BioCorba to play well with BSANE in the Sequence area.
>
> What is the alternative? I do not see voting as bad idea.
The alternative is classic open source "rough consensus" - works for IETF,
Apache, BSD etc etc etc.
>
> >
> > Personally from my perspective, I would be happy to kill off AnonymousSeq
> > - this was something really driven by Matt Pocock - Matt - are you tuned
> > in?
>
> I have used AnonymousSequence as a superclass of SymbolArray (=
> BioJava's SymbolList). It made possible (it seems) to have orthogonal
> sequence extension, which has the Alphabet, without forcing people to
> use it they do not want.
>
don't get this yet - don't worry - probably just need to read your models.
> >
> > A possible use of AnonymousSeq is in the SeqFeature->get_PrimarySeq which
> > is still unclear actually whether this returns just this SeqFeature's
> > subseq (in which case it should be an AnonymousSeq as it doesn't really
> > have an id) or the entire_seq (in which case it should be a PrimarySeq)
> >
> > In any case, we should sort out the semantics.
> >
> > The other thing I would *really* like is to remove the
> >
> > get_PrimarySeqVector
> >
> > from PrimarySeqDB and replace it with
> >
> > get_PrimarySeqIterator
>
> Perhaps we should use the iterator/list pattern used in the BSA. It is
> actually quite good!
>
This is a possibility.
I just don't want to trigger pulling the entire database out into memory
on this call (even just a small proxy object per sequence).
> >
> > The vector call is almost unimplementable for most DB implementations I
> > have got, where as the Iterator is trivially implementable. Alan - this is
> > your baby here - can we change this?
> >
> > Juha -
> >
> > Can I suggest that you send a proposal for BioCorba 0.3 just as plain,
> > commented IDL (no DOC files; no long OMG submission things... ) which
> >
> > (a) is just the part of BSANE that is the BioCorba 0.3 part
> >
> > (b) does not add in massive new things without having a serious "I want to
> > add CORBA::Collection to this to do..." type post here.
>
>
> Fine. I have some IDLs here:
> http://corba.ebi.ac.uk/~muilu/uml/bsane_v3/idl
> Perhaps those contain too much changes?
>
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
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 would make AnnotationHolder read-only as well, not just throw
exception on read-only. WriteableAnnotationHolder could be an inherieted
class of AnnotationHolder
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...
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?
I would dispense with SeqFeatureHolder and just have a straight
forward Seq. (what is the gain? Other SeqFeature holders like...)
I can't see where you hook up the SeqFeatureHolder with the Sequence
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.
> 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>.
-----------------------------------------------------------------