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

[Matthew C. <mat...@gm...>]

Hi Steve,

Since there can be more than two columns and the timing can get non-linear (potentially even more 
complicated than your table allows, i.e. it could be adjusted on the fly based on current elution 
rate), I think it makes the most sense to add the first/second/third elution time terms. These will 
be distinct from the scan start time term (which will remain the time since the start of 
acquisition). It might make sense to refactor the elution time term to be "first column elution 
time" but that will need to be ok with TraML as well (it's really the only format that uses "elution 
time" right now AFAIK).

-Matt


On 9/27/2012 7:41 AM, Robles, Steve wrote:
> Hi everyone,
>
> We would like to export our two-dimensional GCxGC-MS data to mzML and include the first and second
> column elution times.
>
> There was a thread in the psidev-ms-dev email archive that covered this topic and resulted in the
> modulation time term being added to CV
> https://sourceforge.net/mailarchive/forum.php?thread_name=assp.7128de5073.1306482337.4700.551.camel%40paddy&forum_name=psidev-ms-dev.
>
> [Term]
>
> id: MS:1002042
>
> 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."
> [http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+Matters/Nomenclature-and-Conventions-in-Comprehensive-Mult/ArticleStandard/Article/detail/58429]
>
> 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 modulation time allows the elution time from the first and second column to be calculated.
> However, our instrument allows the modulation time to vary over the course of a single run so that
> there can be more than one value for this field. Examples can be found on page 4 of this site
> http://www.leco.com/products/sep_sci/pegasus_4d/pdf/SEP%20SCI%20PEGASUS%204D%20GCxGC-TOFMS%20209-183.pdf
> and
> http://www.labmate-online.com/articles/chromatography/1/leco_corporation/analysis_of_samples_from_the_gulf_of_mexico_oil_spill_by_gcxgc-tofms_-_leco_corporation/815/
>
> To fully describe the data we would not only need a term for each modulation time but also a
> matching field that describes the scan or elution time that the modulation time is effective. For
> example consider the following table:
>
> Time from injection (s)                  Modulation Time (s)
>
> 0                                                                      0
>
> 50                                                                   4
>
> 130                                                                 5
>
> 430                                 `                               6
>
> Here acquisition starts at 50 seconds from injection. Spectra acquired from 50 s to anything less
> than 130 s will have a modulation time of 4 s; spectra acquired from 130 s to anything less than 430
> s will have a modulation time of 5 s; and anything acquired at 430 s or after will have a modulation
> time of 6 s.
>
> The second and first column elution time can be described by:
>
> t2 = (t – ti) % mi
>
> t1 = t – t2
>
> Where:
>
> t1 is the first column elution time
>
> t2 is the second column elution time
>
> t is the time from injection
>
> ti is the greatest modulation start time from injection that is less than or equal to t
>
> mi is the modulation time that goes with ti
>
> So for example a spectrum at t = 136 would have a second column elution time of 1 and a first column
> elution time of 135.
>
> The only way we could represent this data with the current schema and CV would be to break the
> sample into three different files, each with a different modulation time. However we would prefer to
> keep the sample in a single file.
>
> We can think of a few ways to handle this problem.
>
> 1)The first would be to include the list of modulation times and have the software that is reading
> the file calculate the first and second column elution times. This could be implemented in at least
> a couple of different ways.
>
> a.A new list object added to the run element. Each item in the list would require two cvParams, one
> for the modulation start time (a new term?) and a modulation time.
>
> b.Instead of a list element, create a specific series of elements for both the modulation time and
> modulation start time (i.e. modulation time 1, modulation start time 1, modulation time 2,
> modulation start time 2, …).
>
> 2)Another approach would be to create two new terms “first column elution time” and “second column
> elution time”, and add these to scan elements. There was a suggestion like this in the original
> thread that wasn’t implemented.
>
> 3)Just create a “ second column elution time term” and store the first column term in the elution
> time MS:1000826.
>
> The first approach will not increase the file size as much as the others but requires more changes
> to the schema or CV. It also requires the importing application to calculate the elution times. The
> second approach doesn’t require the importing application to know how to determine the elution
> times. It only requires a couple of new CV terms but will increase the file size the most. The third
> option has the drawback that the it will usually produce multiple spectra with the same elution time
> MS:1000826 which may cause trouble for some applications.
>
> We prefer the second option since its straight-forward and it avoids the possibility of
> misinterpretation by the application reading the file. Does anyone have any other suggestions?
>
> It might also be a good idea to update the definition of MS:1000826 – elution time from “The time of
> elution from a chromatographic column, relative to the start of the chromatography."” to “The time
> of elution from all chromatographic columns, relative to the start of the chromatography.”
>
> Sorry we missed the original thread when this topic came up; we’ve been following Psidev-ms-vocab
> and not Psidev-ms-dev. We’re glad to see an effort is being made to support comprehensive separation
> techniques with mzML.
>
> Thank you,
>
> *Steven Robles *| Software design engineer