this began with
https://skyline.ms/announcements/home/support/thread.view?rowId=51299
wherein the small molecule entries in a SCIEX exported method were confusing to a user
And carried on in an email thread between Brendan and Brian:
-----------------
Brian Pratt 12:44 PM 6/4/2021
to Brendan
At the heart of it all we do need a sense of the neutral mass, but that's not problematic if we change our understanding of [M(+/-)(charge)] to mean "inherent charge". So mz=100 with adduct [M-] means mass 100, and mz=100 with adduct [M+2] means mass = 50.
And changing the formatting to skip the average/mono split when there is none shouldn't be a big deal.
As to simplifying [M-] to "-" in some contexts, I dunno, it feels like we're making up our own notation which probably isn't a good thing.
Anyway, I'll enter an issue for all this.
On Fri, Jun 4, 2021 at 12:19 PM Brendan MacLean <brendanx@proteinms.net> wrote:
Responses in-line:
On Fri, Jun 4, 2021 at 11:51 AM Brian Pratt <bspratt@proteinms.net> wrote:
>> So, that ion name is the provided product m/z minus an electron?
No, it's the product mass. If we're told the m/z is 175 and the adduct is [M-] then 174.999 the mass you need to add an electron to to arrive at 175.
I don't think this is helpful, even if explainable.
>> It sure makes the provided rounded numbers look ugly,
Yes. It's possible that we should be understanding [M-] as denoting an inherently charged mass, and not doing any of these small adjustments in mass<->m/z conversion..
Yes, in this case, the user gave us an m/z value and that is all we have. We should not pretend like we understand the neutral mass. They have actually only given us the m/z value and the charge state, and we have no idea how they arrived at that. The ionization is unexplained. So, we don't know the neutral mass.
>> and why is the value repeated twice?
Masses average/mono - but we weren't told which it really is so we populate both the same way.
When they are the same, we should show only one value. I might even go as far as saying we should only ever show the value type in the Transition Settings - Prediction tab, which is 99.9% monoisotopic. So, we are just making everything more verbose for a low probability case. Not our usual approach.
>> And why do the names in the transition list end up with the adduct on either end of the text?
That first occurrence is probably the precursor adduct, but I'd have to double check the code.
I suppose this might be consistent with peptides. I vaguely remember David Cox wanting the precursor charge to appear in this field.
>> This is in place of something like "y3+" for a peptide. Seems like it would be much more understandable to the user expressed as:
Peptide fragment names encode a great deal of information in a very terse format when read in the context of the parent peptide, we don't have that luxury especially in a list defined only in terms of masses.
Also you have to keep in mind that we're not limited to (de)protonation so things like "+" and "-" are ambiguous. Especially in what's meant to be a machine readable format I'd think we'd want to be as explicit as possible.
Perhaps. At the very least, this should become:
[M-]Ion [175_0000][M-]
If both precursor and product charge are required. I am not totally sure I agree that you couldn't adopt a more terse format for only the [M-] and [M+] cases, especially when we now see that many people are just using m/z values with charge states and no information about how they achieved those charge states. Ambiguous, yes, but also what we are seeing a lot. These terms are just saying "a charge state we know not how it was achieved". Do we need the extra characters to say that?
But, anyway, I could live with the above. The duplicated masses and the 6-digit precision to show the loss of an electron, we really need to dump.
On Fri, Jun 4, 2021 at 10:49 AM Brendan MacLean <brendanx@proteinms.net> wrote:
Hi Brian,
I find myself a little confused by the transition names below in the exported transition list for SCIEX. Here is how the document looks in Skyline:
image.png
So, that ion name is the provided product m/z minus an electron? It sure makes the provided rounded numbers look ugly, and why is the value repeated twice? And why do the names in the transition list end up with the adduct on either end of the text?
[M-]Ion [174_999451_174_999451][M-]
This is in place of something like "y3+" for a peptide. Seems like it would be much more understandable to the user expressed as:
Ion [175.0000][M-]
Or even more like what they see in the Targets view:
Ion 175.0000-
After all, we don't use "y3[M+]". So, we are not above using simplified nomenclature.
---Brendan
---------- Forwarded message ---------
From: Skyline Support <skyline@proteinms.net>
Date: Fri, Jun 4, 2021 at 10:31 AM
Subject: RE: optimization for small molecule
To: <brendanx@proteinms.net>
***Please do not reply to this email notification. Replies to this email are routed to an unmonitored mailbox. Instead, please use the link below.***
Brendan MacLean (Members, UGM Registrees) responded 2021-06-04
And now I think I see the confusion: The names above I got from exporting a transition list for SCIEX did not use the "Order by m/z" checkbox, which SCIEX would recommend you use, because it optimizes the quadrupole switching. However, it may also have lead you to mistakenly expect to see the first precursor in your list at the top of your transition list, but it actually moves 15-KETE to the top with its 112.999451 m/z, giving you the impression that Skyline changed:
15(S)-HETE -> Oxylipin.15-KETE...
When actually 15(S)-HETE can still be found lower down (line 4) in the now ordered list:
Oxylipin.15-KETE.[M-]Ion [112_999451_112_999451][M-].light
Oxylipin.12-KETE.[M-]Ion [152_999451_152_999451][M-].light
Oxylipin.5-KETE.[M-]Ion [202_999451_202_999451][M-].light
Oxylipin.15(S)-HETE.[M-]Ion [174_999451_174_999451][M-].light
Oxylipin.11(S)-HETE.[M-]Ion [166_999451_166_999451][M-].light
Oxylipin.8(S)-HETE.[M-]Ion [154_999451_154_999451][M-].light
Oxylipin.12(S)-HETE.[M-]Ion [134_999451_134_999451][M-].light
Oxylipin.9R-HETE.[M-]Ion [122_999451_122_999451][M-].light
Oxylipin.5(S)-HETE.[M-]Ion [114_999451_114_999451][M-].light
Click here to view this message or go to
https://skyline.ms/announcements/home/support/thread.view?rowId=51299