Re: [Biojava-l] parsing EMBL files

[Lorna Morris]

Hi Mark
Thanks for your answer. I can see the logic, it is an odd way to 
represent a frameshift by using an overlap in a join statement. It seems 
easier for me to not call mergeLocations in the first place instead of 
recovering the sub-locations from the MergeLocation instance.

I spotted something else, whilst parsing EMBL files. Sorting 
sub-locations by their natural order (min, max values) doesn't always 
work, if the CompoundLocation overlaps with the origin.

For example the following join statement occurs in the EMBL file 
(AE001273.embl):

join(1041920..1042519,1..1176)
From this Biojava creates the following CompoundLocation:
1176, 1041920,{([1,1176]), [1041920,1042519])}
A call to Collections.sort(locations, Location.naturalOrder) in 
constructor of CompoundLocation flips the 2 sub-locations, so the one 
with the lower coordinates appears first.

The quickest solution for me is to retain the original order of the 
Location objects as they are parsed, and not do any sorting. Perhaps 
there is a better solution, to allow CompoundLocation objects to be 
CircularLocations and if they pass through the origin, then don't sort 
them according to the naturalOrder. Do you think this solution would be 
preferable, or do you think it is sufficient to retain original order of 
sub-locations in all CompoundLocations. I will stick with this quick fix 
for the time being, but maybe work on a better one for the future, if it 
is more appropriate.

Thanks for your help,
Lorna
[EMAIL PROTECTED] wrote:
I guess the logic was, if two sublocations overlap then they should be 
merged. Apparently that is not always the case : (

I think that the Location that is formed will be an instance of a 
MergeLocation in which case it should be possible to recover the 
sub-locations



Lorna Morris <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
10/21/2004 06:35 PM
       To:     [EMAIL PROTECTED]
       cc:     (bcc: Mark Schreiber/GP/Novartis)
       Subject:        [Biojava-l] parsing EMBL files
Hi
I'm using the biojava (SeqIOTools.readEmbl()) to parse EMBL flat files. 
However I've noticed after reading EMBL flat files, and writing them out 
again using biojava the location data of features can change.

e.g:
In the original flat file (accession number : AE001273) this location 
data in present:

FT   CDS 
join(complement(536417..536485),complement(535378..536418))

This gets changed by Biojava to:
FT   CDS             complement(535378..536485)
I looked at the biojava src code and found out that this occurs because
Biojava merges sub-locations in join statments that are overlapping.
If I comment out this code in LocationTools._union():
if(canMerge(last,cur)) {
                try {
            last = MergeLocation.mergeLocations(last,cur);
        } catch (BioException ex) {
            throw new BioError("Cannot make MergeLocation",ex);
          }
        }
Then the location appears as it should in the original EMBL format, with 
the join descibing the overlap. Overlaps between sub-locations in 
joins,are allowed in EMBL format, but are very rare. They maybe used to 
describe frameshifts,occurring through sequence errors.

Is there another reason, for including this code which perhaps I've 
missed? I've commented it out and diffed the files produced, and there 
aren't any other differences with the EMBL file (AE001273.embl) at least.

I just wanted to check if by removing this code, whether there might be 
other side effects.

Many thanks,
Lorna Morris
_______________________________________________
Biojava-l mailing list  -  [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l

 


_______________________________________________
Biojava-l mailing list  -  [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l