Isa,

Can you send us your files?
It sounds like we should take a look at your Skyline document and your exported spectral library.

In Skyline you can use the menu item:
File > Share
to create a .zip file containing your Skyline document and supporting files including whatever libraries you have checked at "Settings > Peptide Settings > Library". The .sky.zip file will not include any libraries that are in that list, but which are unchecked. If there are any unchecked libraries that you also want us to look at, you should either check the checkbox next to them, or send them to us separately.

I am not sure exactly how ion mobility in spectral libraries is supposed to work, but somebody will probably be able to figure out what is going on once we see your files.
-- Nick

Thank you for sending those files.

I see that you have a .mzXML file next to your .pep.xml file. "mzXML" is a very old format, and my guess is that the format is not able to contain ion mobility information.
One thing that might work would be to use msconvert to create a .mzML file, and put that next to "peptides.pep.xml" instead of the mzXML file. Then, when you create your spectral library, I think BiblioSpec will be able to get the ion mobility from the mzML file based on the spectrum that was identified in the .pep.xml file. ("BiblioSpec" is the name of the program that Skyline uses to create a spectral library from peptide search results).

-- Nick

Since, it is not always possible to tell the ion mobility value from the raw data (encoded in mzML or otherwise), we do support adding the IMS values to pepXML, which MS Fragger already does for timsTOF data. The values are expected to be encoded like this:

<spectrum_query ... ion_mobility="value">

If you open your pepXML in a text editor and the <spectrum_query> tags do not contain this value, you can communicate this to the PEAKS team, and as soon as they export pepXML with the "ion_mobility" attribute then Skyline will support this as it does already for pepXML from MS Fragger.

Alternatively, since there is no pepXML standard value for ion mobility, you may also find what you believe is the ion mobility value encoded in a different way. If it is in the pepXML, we are willing to consider supporting it to get you unblocked. If it is not in the pepXML, then I think there is not much we can do, and you will need to work with the PEAKS team to get it somewhere we can use.

Thanks for posting this to the Skyline support board and for your interest in helping to improve the integration between PEAKS and Skyline for timsTOF data.

--Brendan

Hi,

thank you for your responses. PEAKS has different export options. For Third Parties like Skyline (.pepXML, mzxml) and PRIDE/Scaffold (mzIdentML, mgf).

I tried to use the Export for PRIDE/Scaffold and Skyline was able to generate a library with this mzIdentML and mgf file. Ion mobility values are displayed. Is it valid to do it that way? And if so, how can I see ion mobility integration slice in full-scan windows (1/k0 over m/z)?

Best,

Isa

It is definitely valid to do it that way, but Matt Chambers has also discovered an "invK0" attribute in the PEAKS pepXML. So, the next Skyline-daily version will have that fixed. I have mentioned to the PEAKS team before that Skyline doesn't necessarily need pepXML/mzXML and they could simplify things by having just the one mzIdentML/MGF export, which we have supported for many years as integration formats with Scaffold.

Soon, we will be back to supporting both equally well, though, and that may be enough for the PEAKS team not to bother changing.

Thanks for pointing this out and supplying your example files.

--Brendan