[Biocorba-l] Biocorba IDL - Clarifications

[Brad Chapman]

Alan:
[how to make SeqFeature deal with stuff like]
> >   FT mRNA join(397..627,1194..1339,1596..1682,2294..2473,2608..3327)

Ewan: 
> Right. We punted on this one previously. But we have to solve it.
> options:
> 
> (a) have an extended "range" object that is a composite of simple range.
>
> (b). Same as above, but reverse the containment rules. 
> ie, Ranges have-a sequence feature object, and sequences return a list of
> ranges.
>
> (c) let sequence features have sub sequence features
>   
> (d) Let people extend sequence feature with sub sequence feature or more
> complex locations, ie:
> 
> We would put in biocorba.idl a number of "common extensions", with complex
> locations being one of them...
> 
> 
>     ComplexLocationSeqFeature : SeqFeature {
>         // could discuss how we extend this 
>         sequence<SeqFeature> subSequenceFeatures;
>         string embl_location_line(); // for anal parsing
> 
> I'm going for (d) in this - but the floor is open for other opinions here.
>   
> Whaddya reckon?

I understand the c option best, because that is what I have been
dealing with the current bioperl-corba based server I'm using. Right 
now bioperl-corba returns the following for the example above:

type() -> CDS_span
start() -> 397
end() -> 3327

type() -> CDS
start() -> 397
end() -> 627

and so on...

So you can get out the sub-element exons, just by having your client keep
track of whether you are in a CDS_span or not. This is hard to deal
with, though because if you have a predicted gene without introns,
then bioperl would return:

type() -> CDS
...

You can tell the difference between an internal CDS and an external
one by whether or not is has qualifiers, but this is pretty
ugly. So anyways, this is how I handle things like this with the
current setup.

I would like to second Ewan's nomination for trying option d. Gary
(from e-genetics) actually had a similar type idea at BOSC for implementing 
features in biopython--using inheritance to have multiple ways to deal 
with features. The way we were discussing it involved having multiple 
feature holder classes, and then multiply inheriting from a sequence 
class and a feature holder class to get a specialized sequence class
to hold your stuff (so you could have, for example, a MutableSeq class 
with a specific feature format). Of course, this might be good for python, 
but is probably not so hot for java since they don't have multiple 
inheritance (too bad :-).

But I think it is really a good idea worth exploring. If we have some
luck with it, then maybe I'll be extra encouraged to try this out for
biopython (and get ourselves some general ways to deal with features).

So, the point of all that rambling: +1 for option d.

Brad