Feature Proposal: Get one particular scan or list of scans from Thermo Raw, mzML or Brucker data

[ypriverol]

We released this year the PRIDE Archive USI (e.g https://www.ebi.ac.uk/pride/archive/usi?usi=mzspec:PXD000561:Adult_Frontalcortex_bRP_Elite_85_f09:scan:17555:VLHPLEGAVVIIFK/2), the service aims to retrieve from any public or private dataset a given spectrum from PRIDE and render it. On top, you can visualize your own peptide in proforma representation. The idea is that for example in Papers, you don’t need to screenshot anymore the spectra but give the URL to PRIDE Archive in USI format. In the background of that service, when a USI query is performed, we look for the file in the infrastructure and read the corresponding scan from the raw file. (we have a python API for that). Currently, Python API uses ThermoRawFileParser to get the corresponding scan, ThermoRawFileParser do not need to convert the entire file to mzML, but only the corresponding scan . Because we are only using ThermoRawFile parser, we can only support Thermo data. But if in the future this project supports thermo, bruker and mzMLs we can replace ThermoRawFile parser with this.

[david-bouyssie]

For Bruker it's a bit tricky because some pipelines are using the MGF file produced by Data Analyst (if I remember well the name of the tool).
This MGF contains merged MS/MS spectra from TIMS MS/MS frames.
And some other tools merge spectra on the fly.
So I wonder how you can manage to generate "Universal Spectrum Identifiers" for such cases.

Otherwise I like the idea.

[jspaezp]

Well ...
On page 12 there seems to be a specification to handle the frame-> scan relationship.
https://psidev.info/sites/default/files/2021-07/USI_FullSpecification_1.0.0_FINAL.pdf

Having said that... usually for bruker data, a series of scans for a range of mobilities are collapsed together to make a single "scan" interpreted by a search engine. Therefore the entry that most people would want is the "precursor" identifier, rather than the "frame->scan" for ms2 DDA data.

An example of how some of my .tdf files in their PasefFrameMsMsInfo table look

Frame|ScanNumBegin|ScanNumEnd|IsolationMz|IsolationWidth|CollisionEnergy|Precursor
-- | -- | -- | -- | -- | -- | --
3 | 454 | 479 | 1254.31142493223 | 3.0 | 41.0427215189873 | 1
3 | 500 | 525 | 1314.05888976671 | 3.0 | 40.0965189873418 | 2
3 | 569 | 594 | 1169.93620133925 | 3.0 | 38.6772151898734 | 3
3 | 647 | 672 | 1136.46274175889 | 3.0 | 37.0727848101266 | 4

Furthermore, the current implementation in timsrust uses the notations interchangeably:
https://github.com/MannLabs/timsrust/blob/234ba0c79ccfcbfac8e59852313b9ab6bef3c75e/src/file_readers/spectrum_readers/dda_reader.rs#L47-L89

Where querying scan index = 1 actually queries the frame sections that match precursor id = 1 and returns a smoothed+centroided version of the data (within this paradigm there is no way to query precursor frames).

All of this is to say that ... even if there is current support within the USI spec for bruker tdf data, I am not sure if it addresses the data than an user would actually want from it prior to converting the raw data.

IF nativeId:120,475 means frame 120, scan 475, this data is usually not what any user would want.
IF scan:33 means the post-smoothed and centroided version of the series of scans that come from precursor no.33, this schema does not allow querying precursors or DIA data and I believe its confusing with respect to the "pasef meaning of scan" (It is not intuitive that querying for scan 33 gives back the data from frame X in the range of scans from Y1 and Y2).

Sorry for the long worded reply without a clear answer D: let me know what you think and if you have any insights on what the expected behavior would be!