[Biojava-dev] Region & Junction

[mark.schreiber at novartis.com]

I think this is similar to what Matthew was proposing for his BJv2. Not 
sure if that ever got very far but it is a good idea.

The problem is, who would want to reinvent the entire code base to correct 
a design flaw we have had from the start. Actually, it's not really even a 
design flaw more of an inellegance.

If you really want this behaivour you could wrap SymbolList with a view 
that translates interbase coordinates into biological coordinates. There 
is also the  rarely used BetweenLocation which sounds like your Junction 
class.

One thing I came across which actually is a design flaw and related to 
this is that Strand needs to be specified at the level of Location not 
Feature. This is cause some GenBank records contain assemblies of 
different chunks of sequence from different records and (believe it or 
not) different strands (complement)!! This cannot be done without breaking 
biojava. Maybe it could be done with something like a compound feature 
which is like a CompoundLocation but combines StrandedFeatures as a whole. 
So I guess it could be done with the current API but would not be pretty.

- Mark





Michael Heuer <heuermh at acm.org>
Sent by: biojava-dev-bounces at portal.open-bio.org
06/24/2005 06:32 AM

 
        To:     biojava-dev at biojava.org
        cc:     (bcc: Mark Schreiber/GP/Novartis)
        Subject:        [Biojava-dev] Region & Junction


Hello,

Just floating an idea that's been in my head for a bit.

What if for a "biojava next" we replace Sequence and typed Features etc.
with classes extending the two basic SOFA classes _region_ and
_junction_.  A region is a length of symbols and a junction is the space
between two symbols [1, 2].

At the API level Region would look something like a SymbolList but with
interbase (zero-based) coordinates.

Subclasses of _region_, such as _exon_ and _transposable_element_, and of
_junction_, like _insertion_site_, might be generated as java classes from
SOFA itself (or maybe an OWL representation thereof).  Methods could be
generated between these classes representing the various SOFA relationship
types (_kind_of_, _derives_from_, _part_of_).

Of course, in java land these class names would take on proper
JavaClassNameCapitalization instead of lowercase_with_underscores.

   michael


[1]
> http://song.sf.net

[2]
> http://genomebiology.com/2005/6/5/R44

_______________________________________________
biojava-dev mailing list
biojava-dev at biojava.org
http://biojava.org/mailman/listinfo/biojava-dev