Project Plan

Assessing protein sequence database suitability using de novo sequencing describes two metrics which could both be useful. First of all a metric to verify the suitability of a database for a protein identification of a given sample. The other metric scores the quality of the mass spectra regarding their capability to produce high scoring de novo sequences.

1. Database Suitability

The process of calculating the suitablity of a given protein database for a given set of mass spectra consists of mainly six steps. Those are:

  1. Calculate de novo sequences from the mass spectra;
  2. Append high quality (score >= 60) de novo sequences to one another to create one de novo protein;
  3. Add this protein with a unique header to the given protein database;
  4. Run a standard protein search engine (f.e. Comet or X!Tandem);
  5. Re-rank instances where database hits and de novo hits rank 'close' to each other to ensure the database sequence is on top;
  6. Count the number of database and de novo sequences for a given FDR and calculate the quality as follows:

    database quality = #database sequences /
                    (#database sequences + #de novo sequences)

These steps are the ones described in the paper.

The target OpenMS workflow which calculates this metric as in the paper will look something like this:


The input files are highlighted in orange, the new tool in green and important intermediate files in purple.
Why the IDFilter needs to be run might not be that obvious. First of all we probably will only use high scoring sequences for the de novo protein. Second of all peptides under a lenght of six amino acids can be discarded. And third of all only peptides with a precursor charge state two and three will be added. The last two conditions are standard assumptions which are also done in the paper. Although not directly mentioned a quick look into the python scripts used by the authors yields this information.
As the name implies IDFilter will filter the given peptide identifications accordingly.

What needs to be done to get this workflow, well, working?
  • IDFileConverter can convert an idXML to a FASTA file, however it just writes each peptide hit as one FASTA entry. Therefore a flag needs to be added to make it possible to concatenate the first of each peptide hit and write only one FASTA entry.
  • The 'DatabaseQuality' tool does not exist for the time being and needs to be coded.
2. Spectral Quality

Calculating the spectral quality should be a little bit simpler. The paper describes it as the ratio of spectra which produced a sequence with a novor score >= 60 to all ms2 spectra. This should be easily calculated and will also be done in the 'DatabaseQuality' tool.

Comments

Post a Comment

Popular posts from this blog

GSOC Final Report

Image
What was the goal? A recent publication (found here ) describes a metric to evaluate the suitability of a database used for an identification search of LC-MS/MS data. This is useful because sometimes you don't now from which organism the data is coming from. In that case it is also very challenging to find the best database to search with. OpenMS (codebase located on github ) is a huge open source library with a lot of tools to analyze  mass spectrometry  data. The goal of this project was to implement the freshly proposed metric as a tool in OpenMS. The paper also describes another metric so score the quality of the recorded spectra. This metric was also to be implemented, but it is a lot more trivial and not doesn't need that much attention. Was the goal achieved? Yes, it was. One week ago the final version of the database suitability tool was merged. This tool calculates database suitability and spectral quality according to the algorithms presented in the paper. All algori...
Read more

Week 13: The Final Week

Image
In the final week of GSOC I implemented and tested the correction function for the database suitability. Implementing Implementing didn't take that long. This was mostly because the main functionalities were already implemented by me for the other try of correcting suitability. I just had to change some minor stuff for them to work. The only thing I did need to add was the functionality to calculate some decoy entries. Since I want to sample the given database, it's not really possible to take a file already containing decoys. Unfortunately the decoy calculations are not, as for now, exported into a library class. So, I just copied some code from the DecoyDatabase UTIL. That's not good style and might be changed later on, but for now it was the fastest solution. And fast solutions are needed considering it's the last week. Benchmarking I than tested the corrected suitability on the human data from before and also on some data from a roundworm (C. Elegans). The files fo...
Read more

Week 12: Suitability Correction (& some PR Work)

Image
At the start of this week only the PR containing the changes to the adapters passed. I still had to work on some stuff for the suitability functions. But since these changes were not that complex and reviewing of my changes also took some time, I merged my suitability class on a local branch to start working on the corrected suitability. This is would I did while waiting for reviews or tests to finish: Changes for Suitability Correction For this correction to work a lot of additional functions needed to be coded. Also the input of the compute function had to change drastically because for the two internal identification searches a lot of additonal information is needed. First of all a mzML input to have something to search at all. Second of all the two databases, the original database and the deNovo "database" (with one entry which is a concatination of all deNovo sequences), to have something to search with. And third of all the parameters to know which search adapter to use...
Read more