Re: [Psidev-ms-dev] Standardize representation for MS^e and AIF

[Hannes R. <han...@gm...>]

Hi Matt

I would suggest to go with Option 1 since in most other DIA settings,
the high energy scans are treated as MS2 with a isolation window that
specifies which (if any) ions were isolated. Using the scan window as
the isolation window is not *quite* correct since it is possible that
you fragment something that is *not* in the scan window but then
produces fragment ions (e.g. you scan from 0 to 2000 m/z but in your
high energy scan you also fragment a 3000 m/z analyte that produces a
signal at 1800 m/z which you pick up in your high energy scan).

I think setting low energy = MS1 and high energy = MS2 makes most
sense to me, having a new spectrum type does not seem warrented to me.

Best

Hannes

On Mon, Sep 17, 2018 at 10:16 AM, Chambers, Matthew
<mat...@gm...> wrote:
> Hi Eric, you were in the discussion of this issue in the private thread with
> the Waters folks. Do you have a preference for one of the options below, or
> another to suggest?
>
> On 8/14/2018 5:07 PM, Chambers, Matthew wrote:
>
> Hi all,
>
> Over the last few months there have been quite a few users asking me about
> how to distinguish the low and high energy levels in MSe[1]. It seems most
> users expect them to correspond to MS1 and MS2 (most of the users were
> actually reporting all MSe scans being the same MS level as a bug). As far
> as I know, reporting both low and high energy MSe spectra as MS1 is the
> current standard approach. But it seems obvious that users need a way to
> distinguish between the low and high energy spectra, so something needs to
> change with mzML. I see a few options and there may be others.
>
> 1. Keep the existing schema: continue treating low energy spectra as MS1,
> but treat high energy spectra as MSn (ms2) with an isolationWindow the same
> width as the scanWindow, and add a bogus selectedIon in the middle of the
> window.
>
> 2. Change the schema: make isolationWindow and selectedIonList optional so
> collision energy can be stored in the activation element without specifying
> bogus window/ion information.
>
> 3. Change the schema: allow the activation element in either the <scan>
> element or the <precursor> element? This would avoid the need to have a
> "precursor" for a spectrum which really doesn't have one.
>
> With either option 2 or 3, there are a few aspects to decide:
>   a. Should low energy MSe spectra be considered MS1 or MSn (ms2)? If MS1,
> should they still have an activation element in order to preserve collision
> energy info?
>   b. If low energy spectra are treated as MS1, should high energy spectra be
> considered MS1 or MSn (ms2)? High energy spectra certainly need the
> activation element.
>   c. Should MSe spectra get their own spectrum type instead of trying to
> shoehorn them into MS1/MSn? Perhaps a general term like "broadband
> fragmentation spectrum"?
>
> It's not clear to me which option is the best, but if I had to choose I'd
> probably pick 1. Because it won't force schema-validating parsers to update,
> and old software will still be able to read the new files (but that would
> only be a good thing in SOME cases; in other cases the software should
> probably give an error that it can't handle that kind of data).
>
> This has been an outstanding issue for mzML for a while. I hope we can
> finally get it resolved.
>
> Thanks,
> -Matt
>
>
> [1] Briefly, MSe is a data-independent-acquisition method where all ions are
> fragmented simultaneously rather than isolating any specific precursors.
> It's up to the analyzing software to make sense of the resulting complex
> spectra by looking at how the peaks change over time. The technique may or
> may not be combined with ion mobility separation (HDMSe). The spectra are
> acquired in an every-other-scan scheme, i.e. low-high-low-high-low-high. Low
> energy spectra have very little collision energy, but it's not exactly zero.
>
>
>
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>