[Biococoa-dev] BCSequence

[Koen van der Drift]

On Aug 25, 2004, at 2:00 AM, Alexander Griekspoor wrote:

> Let's start a little new discussion then ;-)
> In principle these modifications can be seen as features right? So now 
> we have three names/kinds around in two pairs:
> - Modifications (example: methylgroup, phosphate etc)
> - Features (example: alpha-helix, nuclear localization signal etc)
> Or
> - Features (example: methylgroup, phosphate etc)
> - Annotations (example: alpha-helix, nuclear localization signal etc)


I think we should treat the modifications as an array of BCSymbols. We 
could even make a BCModificationsArray if we add an intermediate class 
called BCSymbolArray as follows:

BCSymbolArray
|
|
------BCSequence
|
|
------BCModificationsArray


The BCSymbolArray can actually take care of a some of the code that is 
currently in BCSequence.

If we calculate the mass of a molecule, we can just iterate over the 
BCModificationsArray to add the masses of the modifications. For me 
features and annotations relate more to secondary structures and 
author's comments (as found in a swissprot or ncbi file). But that's 
just a name game.


> Modifications and features are very alike, and a modification could be 
> seen as a special feature and thus a subclass (inheriting the 
> add/removing/editing/syncing etc methods, but add weight, pi etc ). 
> Also the question raises wether we should keep them in two arrays 
> (features and modifications) or in one (features). If you display all 
> features of a sequence, it perhaps would be nice to see the 
> modifications as well.

I think we should keep them separate. Modifications are per BCSymbol, 
features can span a whole range of BCSymbols. Also maybe we should move 
the mass calculations into a separate class that accepts a sequence to 
calculate the mass? The same for features, pI, etc.


For example we have the class MassCalculator with the following methods

-(id) MassCalculator initWithSequence:(BCSequence *)seq
-(id) MassCalculator initWithSubSequence:(BCSequence *)seq 
inRange:(NSRange)aRange
-(id) MassCalculator initWithString:(NSString *)seq
-(id) MassCalculator initWithSubString:(NSString *)seq 
inRange:(NSRange)aRange

-(float)getMass useMassType:(BCMassType)type addModifications:(BOOL)mods

The getMass method iterates over all symbols and adds the mass, just as 
we do now in the molecularWeight method.


Then we use it as follows:

MassCalculator calculator = [[MassCalculator alloc] 
initwithSequence:mySequence];

float totalMass = [calculator getMass useMassType:BCAverage 
addModifications:YES];

[calculator release];


<nitpicking mode on>
I prefer to use the word 'mass' instead of 'weight'. See eg the 
description in <http://en.wikipedia.org/wiki/Weight>. If we want to 
keep a method molecularWeight around that's fine with me, we could just 
have it return the result of getMass using the averageMass type, which 
is the same value.
<nitpicking mode off>


> 1 The molecular weight method should take modifications into account. 
> A methylgroup adds weight. Thus modifications should have an 
> addedWeight: mode: method  that can accept negative values as well (if 
> the modification removes more weight than it adds).

Just put a negative value in the plist, and it will substract it when 
summing all modifications.



> In both cases it would be nice to add a (p)list of predefined 
> modifications and features.
>

definitely yes.



> I think that's a pretty easy choice, as we don't know of anyone using 
> BioCocoa at the moment, I think we should just start from scratch.
>

I agree, but it think it would be fair to Peter to let him have his say 
as well. He started BioCocoa and the IO classes are all his code and I 
don't want to throw that away :)


- Koen.