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

Peter biopython at maubp.freeserve.co.uk
Sat Feb 21 14:03:14 EST 2009


On Sat, Feb 21, 2009 at 12:24 AM, Iddo Friedberg <idoerg at gmail.com> wrote:
>
> Hi all,
>
> I am sort of living in this world right now, doing a lot of
> metagenomics, so here are my $0.02. I agree with Leighton (assuming I
> understand him): We should consider the possible applications people
> will run using the quality data when designing the [parser?]

Sure.  By having the FASTQ and QUAL files integrated into Bio.SeqIO
(using SeqRecord objects) one simple use case is supported -
interconverting these files into other formats (e.g. FASTQ to FASTA,
or with a little more effort FASTA+QUAL to FASTQ).   Your trimming
example is a another good use case - which could be done with the
SeqRecord representation.

For anything more complicated (like assembly or mapping onto a
genome), with massive datasets the modest overhead of the SeqRecord
and Seq objects could be an issue - but isn't this sort of thing is
usually best handled by an external tool (written in C or C++ by a
specialist)?

Anyway - If you have a look at Bug 2767 at the first attachment I did
the core of the FASTQ parser as a generic function returning a tuple
of strings (the record title, sequence and the encoded quality string
- see FastqGeneralIterator).  While this could be just a private
function, I was thinking this could actually be very helpful for
anyone trying to do something where performance speed or memory usage
was important. On top of this core parser, I had a FastqPhredIterator
(and would similarly have a FastqSolexaIterator) function which turns
these into SeqRecord objects for use via the Bio.SeqIO API.  i.e. We
can offer both the standard Bio.SeqIO interface using SeqRecords, and
a simpler string based parser for those that need it.

Peter


More information about the Biopython-dev mailing list