MSP Spectral Library import for small molecules failed

MSP Spectral Library import for small molecules failed stolltho  2020-05-17
Hi there.

Wanted to import .msp spectral libraries from:

.msp import works for HMDB, MoNA and ReSpect but NOT for GNPS, Fiehn HILIC and LipidBlast (throws an error message, see example attached) from

Spectral library import from
does not work at all, i.e. shows zero molecules after import


Brian Pratt responded:  2020-05-18
Hi Thomas,

Thanks for the report. I had already found the MoNa/LipidBlast problem with the formula being strangely formatted when the precursor_type is "[M+]", that should be fixed in the next Skyline-Daily.

MSP is a very loose "standard" in the way that FASTA is a "standard", everybody seems to find a different way to express things within the confines of the format. There is still work to do on the MoNA/LipidBlast import to pick out all the useful information (SMILES, InChiKey etc) that's crammed into the "Comments" field, but what I have ready to go does get the name and strangely formatted formula in so that's a good step forward.

I will investigate the others as well. Please do not hesitate to alert us to any other problems you find.

Thanks for using the Skyline support board!

Brian Pratt
stolltho responded:  2020-05-18
Thanks Brian for your swift reply.
I actually don't need the libraries at the moment.
Just wanted to let you guys know, since others might encounter the same issue.
Emmanuel responded:  2021-05-04
Dear Brian,

I'm still facing the same issue than Thomas, reason why I'm re-opening this discussion ....

I've tried to import .msp databases from the MS-DIAL/Riken website and for some of the libraries it works (e.g. FiehnHILIC), but not for other databases (e.g. Massbank, Lipidblast ).

When comparing the field names of one library that is imported and another that isn't, I don't see any difference. I'm using the latest Skyline-daily release (64-bits , on a Win10 Pro (v. 1709) computer.

Also, when importing a library that works I've got sometimes a warning message about duplicates that should be excluded before the library import. Apparently Skyline is checking the unicity of the INCHIKey, but for some entries one can get the same INCHIKey but different adducts, compound names, instrument type or collision energies ... (see attached screenshot).

Do you mind sharing which fields are checked for dups during the import of .msp libraries?
Knowing these fields will help to curate the libraries before their import into Skyline.

Thanks for your support.

Brian Pratt responded:  2021-05-05
Hi Emmanuel,

The challenge with .msp files is that there's no real standard for how things are represented. You provided a screenshot of a nice tidy table, but that's not what an MSP file looks like. In a .msp file those values could be wedged into a "Comments" field, or appear with any variety of keywords - it's all down to whoever wrote the .msp export code for whatever system you're working with. If you come across a variant that we haven't yet dealt with, we'd appreciate seeing example of it.

As to duplicates, it's really a question of what we do *not* track rather than what we do. If we come up with two or more entries for the same molecule and adduct, that's a conflict. The spectra might come from different machine types, or with different collision energies, or a host of other parameters, but as we don't track those it's up to the user to filter on the appropriate values before passing the information to Skyline. You wouldn't want to feed Skyline a spectral library that wasn't appropriate to the kind of raw data being processed, and it's up to you to select the contents carefully. The BiblioSpec schema is a good example of the things we do track in a spectral library:

I hope this explains things.

Thanks for using the Skyline support board!

Brian Pratt
Emmanuel responded:  2021-05-07
Hi Brian,

Thanks for your reply.

The nice tidy table I have attached is not an .msp file, but the result of parsing steps I'm doing to check different things before importing the real .msp file into Skyline ... no variant I came across yet, I'm using the usual MS-DIAL/RIKEN and MoNA websites to download these .msp libraries.

I agree that curation remains the best solution, but considering the number of entries in each library it's quite tedious and time-consuming. Therefore, I'm looking for a global screening approach with large libraries to process DIA datasets in order to find putative hits that can be further (manually) confirmed.

Thanks for pointing me towards the BiblioSpec format, I'll have a closer look at it.

Have a nice WE.

Brian Pratt responded:  2021-05-07
If you've been parsing .msp files yourself then you'll appreciate that the contents can vary wildly depending on who produced it (retention time, for example, has been variously observed as two different keywords as well as being buried in a "comment"). Even within the MONA website there are a great many msp variants to be found. It's not a trivial problem to read these files, they're only marginally better than free-text.

So again, if you encounter a .msp file that Skyline doesn't handle well, we would love to see that file.

Many sources of .msp files provide their own means of filtering an internal database before emitting a .msp file, that's ideal for curation. But they're still likely to emit some, shall we say, innovative representations of the data, and we'll always want to hear about it when Skyline doesn't handle them well.