Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Nils H. <nil...@ce...>]

Hi!
I would like to offer some comments on the proposed GCxGC-MS terms.
We have been mainly working with LECO Pegasus IV acquired GCxGC-MS data,
which can currently only be exported to ANDI-MS/netcdf format
without any two-dimensional information using LECO's own ChromaTOF
software. So we ask our users to define the modulation time used during
the acquisition, which is then used as a basis in order to calculate 2D
coordinates for every acquired mass spectrum.

> and 2) to add some terms specific for GCxGC-MS (and LCxLC-MS 
> for that matter). There was consensus to keep the spectra in a single 
> mzML file, but we need a way to encode the two retention dimensions:
> 
> 2a) we can add a new "run attribute":
> 
> [Term]
> id: MS:1000XXX
> name: modulation time
> def: "The duration of a complete cycle of modulation in a comprehensive
> two-dimensional separation system, equals the length of a second
> dimension chromatogram, i.e., the time between two successive injections
> into the second column." [not PSI:MS ?]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1000857 ! run attribute
> relationship: has_units UO:0000010 ! second 
> relationship: has_units UO:0000031 ! minute
> 
> The conversion between the 1D scan time reported by the instruments 
> and the two dimensions spanned by the two columns can then
> be done by a little maths, which is similar to the conversion between 
> a 2D n*m matrix and a linear vector of length n*m. Software that doesn't
> know or consider this term will present spectra as usual, and a *very*
> strange TIC at worst, but is otherwise not affected.
> 
That is the current way of choice in our software Maltcms and Maui.
Everything else can be derived from the modulation time if you know the
(fixed) rate at which mass spectra have been recorded.

By the way, even LECO presents the 1D TIC of GCxGC-MS chromatograms in
their ChromaTOF software.

> 2b) Alternatively, if the mzML writer knows the modulation time, 
> it can explicitly add both/all (for, say, GCxLCxGCxLC runs ...)
> retention times as scan attributes:
> 
>      MS:1000503 ! scan attribute
>      + MS:1000826 ! elution time 
>        + MS:1000XXX ! first column elution time (def: Retention time of a
>                                    peak in the first dimension of a
>                                    comprehensive two-dimensional system)
>        + MS:1000XXX ! second column elution time (def: ... second ...)
>        + MS:1000XXX ! third column elution time 
>        ...
>        + MS:1000XXX ! seventh column elution time (you get the idea ...)
> 
> A problem here is that many scans will of course have identical elution times 
> in the first dimension, which could irritate software 
> that only expects 1D LC-MS data. 
Do I understand it right, that {first,second,third,...} column elution
time would be additional terms added to each scan? Or would the first
column elution time replace the "global" elution time of the scan?
However, adding these terms to each scan would, as Steffen said, lead to
many identical and thus rather redundant entries.
> 
> I am leaning towards solution 2a) modulation time. 
2a) is the minimal required information, so I would also favor this
proposal.
> 

Sincerely,
Nils

-- 
Nils Hoffmann                         	  phone:    +49-521-106-4342
Bielefeld University                 	   room:             U10-144
Faculty of Technology, Genome Informatics
P.O. Box 10 01 31	
33501 Bielefeld, Germany
http://www.cebitec.uni-bielefeld.de/~hoffmann