Add 'NIST msp' to input choices

[Treutler]

I would like to create MassBank records from *.msp spectral libraries as this format is exported by raw-data-processing software like MS-DIAL. For this, I would add the option 'msp' to parameter 'readMethod' in function 'msmsRead' and implement the corresponding functionality in file 'leMsmsRaw.R'.

[meowcat]

Hi Hendrik,

MSP input and output are really really high on my priority list. I have done some preliminary work, unfortunately I have not so much time to work on RMassBank right now.

I want to add the functionality, but not via msmsRead, rather as a "parsing" functionality that can read in MSP, MGF or MassBank spectra. I actually have more changes pending that make going from MassBank to MSP/MGF and the other way around easier...

How soon do you need this functionality?

[Treutler]

Hi meowcat,

I would like to use RMassBank as follows: We (i) measure some standards, we (ii) process the raw data to msp, and RMassBank should (iii) select the standards-spectra from msp given the compound-list (and ignore the remaining spectra in the msp file) and (iv) export the standards-spectra to MassBank format and msp format.

I implemented the functionality to (iii) select the standards-spectra from msp (based on the xcms-routines). Here, I adapted a simple msp-parser, but this could be replaced by your (probably more sophisticated) parser(s).

All in all, I have the feeling that the acquirement of spectra (parsing or raw-data processing) should be separated from the selection of spectra of interest. I think this modularity would lead to a better code-maintainability and code-extensibility.

I am working on this at the moment, maybe we can bring our code together in the next week(s)?

[meowcat]

Hi Hendrik,

We can work on that; one question though: why do you not process the raw data directly with RMassBank?

[Treutler]

We work with SWATH-MS/MS data and as far as I know this kind of data is not supported by xcms/CAMERA (in particular the deconvolution of SWATH-MS/MS spectra). We do the raw-data processing using MS-DIAL instead and export the spectra to msp.

[meowcat]

Oh. Yeah I have actually started to implement a SWATH deconvolution in RMassBank but I don't think it's really working well yet.

What do you currently use to parse MSP? Can it deal with both the "conventional MSP format" mz int, mz int, mz int or also with the "hi-res format"

mz int comment
mz int comment

etc?

I am currently only working on the latter, but to me it is important also

• to parse all the possible metadata that can be in the MSP records,
• to do it in a reproducible and reversible way, i.e. if I read in an MSP and write out the same as MSP, it should be as identical as possible
• to do it so reversibly that I can read in MSP, write MassBank, read MassBank and write MSP and then it should still look the same as in the beginning.

So this requires a bit of thinking...

[tsufz]

Hi, during the NORMAN cross-working group meeting, this topic was mentioned again. We have a potential contributor who wants to submit in msp format and thus we should go ahead with implementation. He promised to provide test data.

Best, Tobias

[tsufz]

@pstahlhofen, could you keep care on it, please?

[pstahlhofen]

Sure, I will

[meowcat]

Question: is the processing from msmsWorkflow and mbWorkflow still desired and useful in this case, or are these already curated spectra? Or rather, in two parts:

• are the peaks already filtered, curated, annotated?
• is the metadata already the way it should finally be?
• is there a separate compound list, or is that info to be taken from the MSP?

The work to be done is quite different for the two cases I think. One is converting an entire MSP record with annotations into something that works with mbWorkflow final steps; the other is more or less splitting a list of MSP records into a compoundlist and a peaklist and rerunning everything.

[sneumann]

Hi, I'd like to introduce @achimmiri working in my group and picking up some of the work by Hendrik. We still have *.msp files coming from e.g. MS-Dial for all features with MS/MS data, so we'd like to still use the Workflow to read 'em in and select the most suitable MS/MS spectrum regarding precursor mz and RT from our compound list.

• So peaks are not yet filtered, curated, annotated.
• As metadata we have either InChi, SMILES or PubMed CID, and we benefit from the additional Compound information gathering by RMassBank.
• As MS-Dial does not know/use the compound list, there is no usable information in the MSP, instead we use the compound list. [1] Yours, Steffen [1] Actually, we have a slightly modified compound list that also includes some parameters for the settings file, so we don't have to maintain two separate files.

[meowcat]

It could be actually useful to make a reader from Spectra instead of MSP, and then use your MsBackendMsp or my generalized text backend from https://github.com/meowcat/SpectraMapping (mine is stalled WIP for sure but does work at least for non-crazy cases, I think yours is also still WIP?) This way we not only avoid writing another MSP parser in addition to our other WIP ones, but additionally get access to all data from Spectra infrastructure.