Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Representation of (different) Ion Mobility values in scanHeaders #276

Open
sneumann opened this issue Sep 27, 2022 · 1 comment
Open

Representation of (different) Ion Mobility values in scanHeaders #276

sneumann opened this issue Sep 27, 2022 · 1 comment

Comments

@sneumann
Copy link
Owner

Hi, as pointed out by @RogerGinBer in #275, there are a number of ways how ion mobility can be measured and included in mzML data. One is a scan attribute, where the ion mobility stuff is (hopefully) all below ion mobility attribute:
https://www.ebi.ac.uk/ols/ontologies/ms/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FMS_1002892&lang=en&viewMode=All&siblings=false
We currently add ion mobility drift time if present:

ionMobilityDriftTime[i] = scan.cvParam(MS_ion_mobility_drift_time).value.empty() ? NA_REAL : (scan.cvParam(MS_ion_mobility_drift_time).timeInSeconds() * 1000);

but what about other vendors/instruments ? Seems Bruker TIMS Data converted by msconvert uses inverse reduced ion mobility.
=> Should that go into the same header column ? Then users will have to know what actual value that column contains.
=> New column, potentially bloating our headers ?
Yours,
Steffen

@jorainer
Copy link
Collaborator

Good questions. I would maybe add a separate header column? it's true that we start to get pretty large header data.frames, but IMHO it would be bad to put it into the same column if we don't know that the values are equivalent (and have the exact same meaning).

Note that we have also the MsBackendTimsTof that supports direct import of data from the vendor files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants