RT for MS/MS missing in spectral library export

RT for MS/MS missing in spectral library export blaine roberts  2018-03-09
I am working to build a spectral library that contains the CCS, RT, accurate mass and transition data. However, when I export a spectral library of reviewed peptides including the CCS it does not contain the RT of the peptide for when the Ms/MS was collected as it does when I import DDA data. So, when I import a new ion mobility all ion data set it integrates over the entire LC run and not around the 2 minute window. In my exported CCS library all of the observed ms/ms times are 0. I have uploaded the share file 'RT_missing_fromexport.zip' Description "Roberts_missingRT". How do I get the RT information to be included so it will be applied to the import of new ion mobility all ion data?

Brian Pratt responded:  2018-03-09
Hi Blaine,

Thanks for uploading the data.

I'm not sure I'm understanding the scenario yet. Maybe some screenshots would help?

Can you also provide an example of the export that's missing RT values?


Brian Pratt
blaine roberts responded:  2018-03-09
I have uploaded the CCS spectral library 'CCS_FDR0_001_BrainRef.blib'

Attached is a screen shot. Notice there are two light blue vertical lines, the one at 78 minutes is from the ms/ms spectra collection time in the DDA library. The line at time zero is from the CCS-export library. When I "use only scans within 2 min of ms/ms IDs" feature it integrate from both of the blue lines, which is fine except the export that now has the CCS values for each peptide does not have a corresponding ms/ms ID retention time.

What I am aiming to do is build a library of peptides with CCS, RT, mass, and transitions assigned. My approach is as follows; High pH fractionate sample->run duplicate LC-MS for each fraction, one in DDA mode, the second in ion mobility-all ion mode. -> Then build a DDA library form run1 and match with the IMS-all ion mode. I am using standard flow chromatography so the retention time drift between runs is less than a few seconds which allows for narrow extraction times. I build my target library of peptides (e.g. assay library) directly from the DDA library -> then I train the mProphet model and manually review peptides -> then assign CCS via the ion mobility calculator "use results' -> then export the CCS assigned spectral library. The Idea is to use this for the 'samples' hoping that it will assist in the assignment of the correct chromatographic peaks on the 1D ion mobility-all ion data. Similar to the SWATH approach but with the CCS included. Then statistical analysis via MSstats or otherwise. Maybe I am in error in trying to use Skyline this way but my understanding of SWATH made me think this approach might be viable. I am trying to benchmark the 6560 for protomics similar to what Erin Baker has done but on the commercial instrument and with standard flow. I would be very happy to collaborate with you. I have optimised CE-ramps, trap time, source parameters and have been using a reference human brain sample.

blaine roberts responded:  2018-03-09
Do you think it would be possible to include CCS as a variable in the mProphet model?

Brian Pratt responded:  2018-03-10
Hi Blaine,

Thanks for the files. It certainly looks like we're failing to include that IMS data in the export, I'll look into that.

I've not personally worked in the mProphet code so I don't know what that entails - perhaps another Skyline developer can address that. It sounds like an interesting idea.

blaine roberts responded:  2018-03-10
Hi Brian,

I look forward to any updates. Please let me know if you require any data files that might assist you.

Can you discuss with the mProphet folks? As CCS is a physical parameter it may be quite useful to improve the accuracy of the model when IMS data is available.

Brendan MacLean responded:  2018-03-10
Hi Blaine,
I think maybe we talked about this in Australia (integrating IMS into mProphet). I'll keep it in mind, but don't hold your breath for this. I assume by CCS, you really mean some kind of error value in the ion-mobility dimension, similar to the mass error we have in the m/z dimension. I think we would probably do that in the units we display for that dimension, e.g. drift time (ms). The predicted value would come from the CCS value, and then like mass error (ppm), we would calculate the difference between the predicted value and the observed value. In m/z, we used weighted mean of the signal we extract across that dimension to give us a center of m/z. The other alternative is to use some form of peak detection to come up with a peak apex. And, of course, the two usually become the same when the spectra are centroided. I don't know of a vendor that currently has a centroiding option for IMS data. Though, we have asked.

So, that would be it, some kind of "Ion mobility error" score. If you can convince me you have a data set that would prove this improves the mProphet scores (e.g. 3-organism mix data, like the Navarro, Nature Biotech 2016 paper), then we might be interested in giving you a test version of Skyline with this enabled (using the weighted mean method for determining observed IM value).

I am not as optimistic as you seem to be, but maybe I am not understanding your thinking fully. So, I will stop there and let you tell me if I am heading off in the wrong direction, or if I correctly understand your intent.

Thanks for your willingness to share your data and ideas with us.