[Biopython-dev] Quality scores (and per-letter-annotation) in a SeqRecord?

Jose Blanca jblanca at btc.upv.es
Fri Feb 20 11:49:36 UTC 2009

> I suppose you could consider adding a .phred_quality
> property which is explicit, but then you'd end up with many different
> properties.  Then there are other per-letter quality annotations - you
> might want the A, C, G and T intensity from capillary sequencing (four
> sets of numbers, not just one).  Plus of course this doesn't address
> non-quality related per-letter-annotations (like secondary structure,
> or atomic coordinates).
> My point is that if we can't give top level properties to everything,
> hence the original introduction of the annotations dictionary in the
> first place.  Only a handful of really important things got their own
> properties (id, name, description and the sequence itself).  If there
> was only ONE key quality score, then I wouldn't mind making an
> exception so much - but that doesn't seem to be the case.
That's a very good point. It wouldn't be wise to populate the SeqRecord class 
with a lot of properties.
Another posible approach would be to create a derived class for that a 
SeqWithQuality. It would be like a SeqRecord but with a .quality property. 
For other cases other classes could be derived from SeqRecord.
The problem with putting the quatilies in a dict with all the other per base 
annotation is that it has a different behaviour than the .seq case. The seq 
case is special because is much more used, so maybe that's fair enough.
I don't know, maybe it is wiser to set all the per case annotations in a dict 
a let the sequence outside. In that way we won't be creating a lot of new 
classes derived from SeqRecord.
The more I think about the dict possibility, the more I like it.

Jose M. Blanca Postigo
Instituto Universitario de Conservacion y
Mejora de la Agrodiversidad Valenciana (COMAV)
Universidad Politecnica de Valencia (UPV)
Edificio CPI (Ciudad Politecnica de la Innovacion), 8E
46022 Valencia (SPAIN)
Tlf.:+34-96-3877000 (ext 88473)

More information about the Biopython-dev mailing list