You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What shall be the format of a unique ID in the QFeature object and for all downstream analysis?
I would argue for something like MXXXTYYYCZZZ where the XXX denotes the nomimal mass of the feature, YYY the retention time in seconds and ZZZ potentially present CCS values (make it future proof).
Example:
mz 181.070665, RT 6.73 minutes would become M181T404
Sounds good. Only question would be whether we include a Study ID anywhere or not.
IF all our networks will ever only cover one dataset, or at least we assume that all identical MXXXTYYYCZZZ
are the same feature, then this proposal makes sense. What is CZZZ on our old QTOF ? Missing ?
C000 or CN/A ? Yours, Steffen
I like the @ part. That keeps it optional, and we have a choice of MTBLS or DOI or whatever ;-) And thinking in terms of a regex, the XX, YY and ZZ would have to be numeric , in Da , sec, and angström ?! respectively. Yours, Steffen
Is M181T404 unique enough for sensitive machines?
mz 181.070665, RT 6.73 minutes -> M181T404
mz 181.470665, RT 6.74 minutes -> M181T404
The second combination migth not be relevant, but I remember that I came cross this problem, that there were Features close by.
Is M181T404 unique enough for sensitive machines?
mz 181.070665, RT 6.73 minutes -> M181T404
mz 181.470665, RT 6.74 minutes -> M181T404
The second combination migth not be relevant, but I remember that I came cross this problem, that there were Features close by.
I think features that have the same mass should be appart by minimum one second, otherwise the would be one feature.
I would think adding study ID (i.e. MTBLS) to the QFeature might be too much? Maybe some where else to capture it would be better? Header etc ...
It might look like a overkill, but makes the ID really unique. Even between datasets that might use the same LC-MS method and therefore have the same IDs.
QFeatures is not handling any sample headers, I think this would go to MSExperiment, right @sneumann ?
Is M181T404 unique enough for sensitive machines?
mz 181.070665, RT 6.73 minutes -> M181T404
mz 181.470665, RT 6.74 minutes -> M181T404
The second combination migth not be relevant, but I remember that I came cross this problem, that there were Features close by.
I tested now on one of my datasets. With nominal mass and seconds I have up to eight features with the same ID. With three digits for the mass it reduced down to 3, but still not optimal.
Shall we collect a few datasets for testing to find a optimal solution? I will create a few lines of R code for testing.
I checked a few datasets and we still have a lot of collisions. Didn't expect that... Tested how many digits for m/z and RT would be required. I will soon update you on the results.
xcms solved the collisions by adding an arbitrary _1, _2 to the duplicated features. You could ALWAYS get collisions, so be prepared. They're only IDs, in the end. Yours, Steffen
I would suggest to have something like FT0001MXXXRYYYCZZZ, with that we have everything in place. The number will be based on the row number. I will create a function for our package.
Activity
LiesaSalzer commentedon Sep 15, 2020
sounds good. What if there is already an ID? overwrite it?
sneumann commentedon Sep 15, 2020
Sounds good. Only question would be whether we include a Study ID anywhere or not.
IF all our networks will ever only cover one dataset, or at least we assume that all identical MXXXTYYYCZZZ
are the same feature, then this proposal makes sense. What is CZZZ on our old QTOF ? Missing ?
C000 or CN/A ? Yours, Steffen
michaelwitting commentedon Sep 15, 2020
@LiesaSalzer
If there is an ID I would keep it. Any objections?
@sneumann
How shall it look like with a study ID?
MXXXTYYYCZZZ@MTBLSAAAA?If there is CCS value I would drop this part.
sneumann commentedon Sep 15, 2020
I like the @ part. That keeps it optional, and we have a choice of MTBLS or DOI or whatever ;-) And thinking in terms of a regex, the XX, YY and ZZ would have to be numeric , in Da , sec, and angström ?! respectively. Yours, Steffen
michaelwitting commentedon Sep 15, 2020
Yes, that is the plan!
bitbarbie commentedon Sep 15, 2020
Is M181T404 unique enough for sensitive machines?
mz 181.070665, RT 6.73 minutes -> M181T404
mz 181.470665, RT 6.74 minutes -> M181T404
The second combination migth not be relevant, but I remember that I came cross this problem, that there were Features close by.
rsalek commentedon Sep 15, 2020
I would think adding study ID (i.e. MTBLS) to the QFeature might be too much? Maybe some where else to capture it would be better? Header etc ...
michaelwitting commentedon Sep 15, 2020
I think features that have the same mass should be appart by minimum one second, otherwise the would be one feature.
michaelwitting commentedon Sep 15, 2020
It might look like a overkill, but makes the ID really unique. Even between datasets that might use the same LC-MS method and therefore have the same IDs.
QFeaturesis not handling any sample headers, I think this would go toMSExperiment, right @sneumann ?rsalek commentedon Sep 15, 2020
I probable do not know the extend of your use case here and the details of the format. Maybe be can chat tomorrow? Just thinking keeping it simple
michaelwitting commentedon Sep 16, 2020
On top of the discussion: How shall we call the variable?
$uniqueIDor$idor ???michaelwitting commentedon Sep 16, 2020
And another point: Shall we encode the ionization mode, e.g.
POSMXXXTYYYCZZZ@MTBLSABCDLiesaSalzer commentedon Sep 17, 2020
I like the additional information about the ionization mode!
LiesaSalzer commentedon Sep 17, 2020
I would say keep it simple with 'id'
michaelwitting commentedon Sep 17, 2020
I tested now on one of my datasets. With nominal mass and seconds I have up to eight features with the same ID. With three digits for the mass it reduced down to 3, but still not optimal.
Shall we collect a few datasets for testing to find a optimal solution? I will create a few lines of R code for testing.
rsalek commentedon Sep 17, 2020
What you need, would data tables work?
michaelwitting commentedon Sep 17, 2020
Yes, typical m/z-RT data tables. Just to check how often certain collisions occur. Positive and negative data is possible...
rsalek commentedon Sep 17, 2020
sent one via gDoc, this is peak list, no cleanups! Let me know if you need more via slack
michaelwitting commentedon Sep 18, 2020
I checked a few datasets and we still have a lot of collisions. Didn't expect that... Tested how many digits for m/z and RT would be required. I will soon update you on the results.
sneumann commentedon Sep 18, 2020
xcms solved the collisions by adding an arbitrary
_1,_2to the duplicated features. You could ALWAYS get collisions, so be prepared. They're only IDs, in the end. Yours, Steffenmichaelwitting commentedon Sep 29, 2020
I would suggest to have something like
FT0001MXXXRYYYCZZZ, with that we have everything in place. The number will be based on the row number. I will create a function for our package.