Add minimal terms for ion mobility frames

[mobiusklein]

Closes #361

This adds a minimal set of terms that were important for #361, omitting special cases and obsolete representations.

Open questions remaining:

1. Do we need analogs to scan window lower limit + upper for ion mobility?
2. Need ProteoWizard implementation. Should be straight-forward to add after OBO is updated.

[chambm]

Seems reasonable, except what instrument has profile IM values? Waters has 200 bins and their masses are profile; 200 doesn't seem enough to count as profile. Bruker is 1000ish bins but the masses are explicitly centroided at acquisition. I'll be honest I didn't follow much of the linked issue discussion.

[mobiusklein]

@chambm What we want to express is whether or not the IM dimension is expected to contain a series of points for an analyte, or whether it has been processed s.t. each point refers to a distinct analyte (or two analytes so close we can't tell them apart). This is the same idea for profile spectrum vs. centroid spectrum.

Put another way, "Can I treat this spectrum as a peak list or do I need to do something to it before I can go off and use them?".

The bin spacing is a valid point for IM peak resolution, but I don't think that's something we can get from the vendor software and will vary in definition by unit and/or vendor.

[chambm]

For centroid spectra it's still extremely common to have multiple peaks for a single analyte, e.g. isotopes and charge states. Only a deconvolved and deisotoped centroided spectrum would (potentially?) be one peak per analyte (even then it depends how you define "analyte" I think).

But if I understand what you're saying, when coming straight from ProteoWizard, IM representation would always be ion mobility profile frame?

[mobiusklein]

Apologies, I should have said ion, not analyte. But yes, you have the idea, I think.

I'm not aware of any filters in MSConvert that collapse the IM dimension, except maybe scanSumming?

[chambm]

ScanSumming just drops it entirely. I'm still not sure about this "centroid/profile" distinction in the IM dimension. I think it needs more consideration from other IM-interested folks.

[edeutsch]

This seems fine to me, but I am not very close to ion mobility data and software, so I am uncertain what the needs really are.

[mobiusklein]

I admit I worked primarily on larger molecules with fairly wide mobilograms/arrival time distributions using Waters Cyclic and Bruker timsTOF data, where frames/cycles do form well-defined peaks, and my approach to both was to gather everything into isotopic pattern fitted groups and look for structure over the mobility and RT dimensions. The example file in the linked issue are single frame IM feature extractions at a single RT.

The same idea is applied to timsTOF data in IonQuant, where m/z-IM-rt abundances are extracted from contiguous observations, but they use identification seeds instead of using traditional feature detection techniques. I think this article states the same idea is used in MaxQuant for timsTOF data.

[jspaezp]

Hey there! new to this whole process so here are my 2 cents (as someone who currently writes software for timsTOF data), I think the distinction between the two representations makes a lot of sense, I have certainly struggled with what name to give intermediate representations of data processing where the ion-mobility dimension is ... 'centroided' ... without it being discarded and I also see the process as analogous to centroiding in the m/z dimension.

(graphical illustration to make sure we are talking about the same thing, disregard the cluster index in the right panel)

This is essentially what I implemented here: lazear/sage#166 if anyone is interested ... Right now it all happens in memory and not exported, but I can imagine wanting to export it to disk at some point.

What issues do I see?

1. It is very common for a single frame to represent multiple pieces of data ... for instance in dda/diaPASEF, a single frame will contain the spectra for multiple isolated precursors (think ... from ims 0.7-0.8 the quad is set to isolate from x-y, in ims 0.8-0.95 from z-w ...). It is unclear to me how/whether the current implementation allows communicating that. I am not sure if the "right" understanding of the frame is as a property of a spectrum, rather than a collection of them (I think this is most likely lack of knowledge of the ontology rather than a real issue with the proposed terms).

Regarding this point:

This seems fine to me, but I am not very close to ion mobility data and software, so I am uncertain what the needs really are.

I certainly feel like it would have the same utility as the profile-centroid distinction in the m/z dimension, is there any reason why you feel that might not be the case?

[mobiusklein]

It is very common for a single frame to represent multiple pieces of data ... for instance in dda/diaPASEF, a single frame will contain the spectra for multiple isolated precursors (think ... from ims 0.7-0.8 the quad is set to isolate from x-y, in ims 0.8-0.95 from z-w ...). It is unclear to me how/whether the current implementation allows communicating that. I am not sure if the "right" understanding of the frame is as a property of a spectrum, rather than a collection of them (I think this is most likely lack of knowledge of the ontology rather than a real issue with the proposed terms).

The 3D spectrum / ion mobility frame concept in general doesn't. That behavior is up to the reader to understand from the instrument metadata. That's why ProteoWizard defines "raw" frames differently depending upon what it infers from the TDF file contents, inferred by reading the distinct SQL tables: https://github.com/ProteoWizard/pwiz/blob/8a73de245643eeddb423505f11dd3e841bb78ec4/pwiz_aux/msrc/utility/vendor_api/Bruker/TimsData.cpp#L297-L471. The timsrust library does something similar. For Waters, depending upon the combination of configurations with cyclic IMS, SONAR, and other tricks, you get different topologies, but only the trivial MS1/low energy configuration matches the timsTOF configuration.

[mobiusklein]

I have certainly struggled with what name to give intermediate representations of data processing where the ion-mobility dimension is ... 'centroided' ... without it being discarded and I also see the process as analogous to centroiding in the m/z dimension.

@jspaezp I forgot to respond to this point. Are you referring to #361 (comment) 's ion mobility feature frame idea or did you find you were interested in that separately?

[mobiusklein]

I have adapted some examples from Waters cIMS HDMSe:

A slice of a low energy cycle

A high energy cycle

The same done with timsTOF DDA-PASEF data on a similar sample:

MS1

MS2

I don't have a DIA-PASEF example handy yet.

@chambm what evidence would you need to see for the profile/centroid concept to make sense for ion mobility data?

[chambm]

Are any of those plots showing "centroid IMS" data?

[mobiusklein]

No, none of these show centroids in the ion mobility dimension since I had interpreted your previous argument to be that you didn't think that the IM dimension fit the definition of being in profile mode because it was discretized.

Centroid ion mobility would be singular points in the ion mobility dimension. The "idealized" scenario there is that you've done all the work you would want in the ion mobility dimension to collapse them down to a single point:

Reduces to

That is the use-case @timosachsenberg describes in the original issue, I think.

[chambm]

Thanks, that's a useful illustration. Then you would (for some intermediate storage reason probably) want to write that back out to mzML?

[mobiusklein]

Right. It could then be read back in like a checkpoint or used for a step implemented elsewhere that doesn't know how to deal with IM profiles, since IM introduces another layer of signal processing.

I struggled with justification because we're in a phase of all-in-one tools that read straight from vendor files and then don't write the data out for "public consumption" until its in a nice, well behaved CSV.

[timosachsenberg]

No, none of these show centroids in the ion mobility dimension since I had interpreted your previous argument to be that you didn't think that the IM dimension fit the definition of being in profile mode because it was discretized.

Centroid ion mobility would be singular points in the ion mobility dimension. The "idealized" scenario there is that you've done all the work you would want in the ion mobility dimension to collapse them down to a single point

Yes, or if one wants to align more closely with the concept of profile vs. centroid, I would suggest using a single point per isotopic peak.

In all-in-one tools, this may not be strongly justified. However, given the significant data reduction, such a format could be ideal for modular tools that want to use open standards.

Maybe something we can also discuss at HUPO-PSI if some of you folks are there.