Menu
▾
▴
psidev-ms-dev
|
From: Nils H. <nil...@ce...> - 2011-03-15 17:27:24
|
Hi Steffen, hi list! Am 15.03.11 16:19, schrieb Steffen Neumann: > Hi, > > Nils, do you have some (small!!) example data for GCxGC ? In which format? What would be the file size limit? Where should I upload it? > > We're wondering whether mzML could encode that with the current schema, > or if it has to be extended somehow. Well, basically, all you need is the second column modulation time (time interval between releases from the cryo-modulator onto the second column, for Leco Pegasus GCxGC-MS that is). This allows you, along with the scan rate, to calculate the number of scans for the second dimension (e.g. t_mod = 5s, scans_per_second:=spm =500 => 2500 scans per modulation (mass spectra)). Then, with the number of scans per modulation, you can simply index every scan in the two-dimensional coordinate system. Basically, this should also work for LCxLC-(MS). > > How is netCDF handling 2D retention time ? Not at all, netCDF 2D from LECO ChromATof looks identical to 1D output, just with a very large number of scans (>1000000). We have to know the modulation time (duration on the second column) in advance or infer it from the baseline modulations. > > Yours, > Steffen > Yours, Nils -- ##################################################################### # Please note: since March 1st, 2010, my phone and room numbers have # changed! # New room: U10-144 # New phone number: +49-521-106-4342 ##################################################################### Nils Hoffmann phone: +49-521-106-4342 Universitaet Bielefeld room: U10-144 Techn. Fakultaet, AG Genominformatik Nil...@Ce... 33594 Bielefeld, Germany http://www.cebitec.uni-bielefeld.de/~hoffmann/ |
|
From: Matthew C. <mat...@gm...> - 2011-03-15 18:17:07
|
How different from a SCX/IEF separation is GCxGC? I know SCX can be done "online" (if I understand, this means the 2d separation is automatic with no manual intervention), but it usually isn't. Is GCxGC always online? In mzML, we generally define a "run" as a single "injection" (except with MALDI...) so perhaps each 2nd dimension fraction should be a separate mzML and the fraction # should be stored in the header (this would apply for SCX and IEF as well). -Matt On 3/15/2011 12:08 PM, Nils Hoffmann wrote: > Hi Steffen, hi list! > > Am 15.03.11 16:19, schrieb Steffen Neumann: >> Hi, >> >> Nils, do you have some (small!!) example data for GCxGC ? > In which format? What would be the file size limit? > Where should I upload it? >> >> We're wondering whether mzML could encode that with the current schema, >> or if it has to be extended somehow. > Well, basically, all you need is the second column modulation time (time > interval between releases from the cryo-modulator onto the second > column, for Leco Pegasus GCxGC-MS that is). This allows you, along with > the scan rate, to calculate the > number of scans for the second dimension (e.g. t_mod = 5s, > scans_per_second:=spm =500 => 2500 scans per modulation (mass spectra)). > Then, with the number of scans per modulation, you can simply index > every scan in the two-dimensional coordinate system. Basically, this > should also work for LCxLC-(MS). >> >> How is netCDF handling 2D retention time ? > Not at all, netCDF 2D from LECO ChromATof looks identical to 1D output, > just with a very large number of scans (>1000000). We have to know the > modulation time (duration on the second column) in advance or infer it > from the baseline modulations. >> >> Yours, >> Steffen >> > Yours, > Nils > |
|
From: Matthew C. <mat...@gm...> - 2011-03-15 20:26:03
|
You propose a <run> cvParam, but there is only one run per mzML. So you are agreeing with me that each 2nd dimension fraction would be a separate mzML? Constructing the 2d x vs. y would require reading from multiple mzMLs then. -Matt On 3/15/2011 2:59 PM, Neumann, Steffen wrote: > Hi, > > Yes, GCxGC is (almost ?) always online. Here is an image: > http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php > > if I get it orrectly, the Y axis is the "fast" column (think seconds), > the X axis the "slow" column (order of minutes). Each Pixel would be a TIC, > with a full spectrum "behind" it. (Or did I mix the axes up ?) > > There is also some course material, including GCxGC/TOF-MS at p27 > http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf > > So as Nils confirmed, mzML is technically capable of carrying GCxGC data > as a (large) number of spectra. > > However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings, > so that images such as the one above can be created. This would also be > required for 2D peak picking (or alignment). No need to encode all sorts > of GC column information, that might go into sepML or whatever. > > Following Nils, I'd suggest something like > > [Term] > id: MS:1000XXX > name: second column modulation time > def: "The time of ..." [PSI:MS] > xref: value-type:xsd\:float "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 > > as a<cvParam> for the<run>. Any software ignoring this 2D nature > would simply see a (very) strange pattern of spectra. > > Thoughts ? Does anyone have contact with sbd. at Leco ? > Which are the other major players with GCxGC ? > > Yours, > Steffen |
|
From: Matthew C. <mat...@gm...> - 2011-03-15 22:01:07
|
Sorry, I meant 1st dimension. E.g. SCX fractions, IEF strips. If each fraction only lasts a few minutes, it might make more sense to keep in one mzML. But in that case, the 1st dimension fraction identifier would need to be a spectrum property. Looked at another way, do the scan numbers, or whatever the instrument uses, reset when moving to the next fraction? -Matt On 3/15/2011 3:54 PM, Neumann, Steffen wrote: > Hi, > > no, I think the 2nd dimension is in such a rapid succession (few seconds!), > that a single metabolite elutes across several of those, > and hence it makes no sense to split into multiple files. > > Yours, > Steffen > > ________________________________________ > From: Matthew Chambers [mat...@gm...] > Sent: 15 March 2011 21:25 > To: psi...@li... > Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? > > You propose a<run> cvParam, but there is only one run per mzML. So you are agreeing with me that > each 2nd dimension fraction would be a separate mzML? Constructing the 2d x vs. y would require > reading from multiple mzMLs then. > > -Matt > > > On 3/15/2011 2:59 PM, Neumann, Steffen wrote: >> Hi, >> >> Yes, GCxGC is (almost ?) always online. Here is an image: >> http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php >> >> if I get it orrectly, the Y axis is the "fast" column (think seconds), >> the X axis the "slow" column (order of minutes). Each Pixel would be a TIC, >> with a full spectrum "behind" it. (Or did I mix the axes up ?) >> >> There is also some course material, including GCxGC/TOF-MS at p27 >> http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf >> >> So as Nils confirmed, mzML is technically capable of carrying GCxGC data >> as a (large) number of spectra. >> >> However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings, >> so that images such as the one above can be created. This would also be >> required for 2D peak picking (or alignment). No need to encode all sorts >> of GC column information, that might go into sepML or whatever. >> >> Following Nils, I'd suggest something like >> >> [Term] >> id: MS:1000XXX >> name: second column modulation time >> def: "The time of ..." [PSI:MS] >> xref: value-type:xsd\:float "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 >> >> as a<cvParam> for the<run>. Any software ignoring this 2D nature >> would simply see a (very) strange pattern of spectra. >> >> Thoughts ? Does anyone have contact with sbd. at Leco ? >> Which are the other major players with GCxGC ? >> >> Yours, >> Steffen |
|
From: Neumann, S. <Ste...@ip...> - 2011-03-16 05:02:05
|
Hi, Nils will try to get us an example file. But from what I remember you really get only one file with consecutive scan numbers and one monotonously increasing (1D) scan times, which can be converted to 2D if you know the modulation time. Yours, Steffen ________________________________________ From: Matthew Chambers [mat...@gm...] Sent: 15 March 2011 23:00 To: psi...@li... Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? Sorry, I meant 1st dimension. E.g. SCX fractions, IEF strips. If each fraction only lasts a few minutes, it might make more sense to keep in one mzML. But in that case, the 1st dimension fraction identifier would need to be a spectrum property. Looked at another way, do the scan numbers, or whatever the instrument uses, reset when moving to the next fraction? |
|
From: Oliver K. <oli...@un...> - 2011-03-20 18:00:34
|
On 16.03.2011, at 06:01, Neumann, Steffen wrote:
> Hi,
>
> Nils will try to get us an example file. But from what I remember
> you really get only one file with consecutive scan numbers
> and one monotonously increasing (1D) scan times,
> which can be converted to 2D if you know the modulation time.
That is also my understanding from 2D-LC data. I would argue quite in
favor of using mzML for this and 2D data is also not that uncommon
in proteomics, so it is a problem that will have to be dealt with
anyways.
Conceptually, I would consider those just a single {L|G}C-MS run.
Information on how the 1D RT should be mapped to 2D coordinates
should be provided in addition to that. We could basically
store a relation assigning each scan two or more retention
coordinates (retention times or an index for the primary separation,
which would also make it comparable to offline fractionation).
Just my two cents,
Oliver
|
|
From: <mem...@gm...> - 2011-03-21 10:54:37
|
It's a shame we don't have a simple tracking format that could
handle this end of things properly. Obviously there's FuGE which
could point at a set of mzMLs, but without wishing to disrespect
that, I mean something much more lightweight (in both the formal
and informal sense...).
If such a thing existed then the pressure to (redundantly) model
that kind of contextual info (at whatever level) would be taken
off the other in-house formats. The only question would be
whether always needing two formats (the first to specify which
files relate to which fractions from a 2D separation [plus other
metadata], and then the mzML assay files, plus presumably many
mzIdents alongside so that'd be three) is too much of an
increase in complexity versus the situation where any of the
assay files could stand alone.
If I were to sketch such a thing it'd have:
(1) Adequate generic structure to capture [tagged] metadata
about sample origins and so on (thinking MI guidelines +).
(1a) A 'Study' element for high-level info about the set of
assays conducted and links out.
(1b) Study components' (cv-tagged to specify function), which
could hold a person or a metagenomic sample site or a tissue
bank or glasshouse growth or sample prep protocol etc.
(2) Mechanism for pointing at assay-specific data files (mzML,
GelML including proprietary stuff using URI/PURL/DOI/...).
(3) Also make it generally ontology/cv/whatever friendly
There's a tab format called ISA-Tab which has the same basic
structure, some dedicated supporting software and users (e.g.,
CS in Manchester export the tab from a tool); maintaining
general structural compatibility with that wouldn't hurt.
Is there any interest in such a thing? If we stick to XML and
keep it simple we could have a draft before we meet.
Cheers, Chris.
On 20/03/2011 18:00, Oliver Kohlbacher wrote:
>
> On 16.03.2011, at 06:01, Neumann, Steffen wrote:
>
>> Hi,
>>
>> Nils will try to get us an example file. But from what I remember
>> you really get only one file with consecutive scan numbers
>> and one monotonously increasing (1D) scan times,
>> which can be converted to 2D if you know the modulation time.
> That is also my understanding from 2D-LC data. I would argue quite in
> favor of using mzML for this and 2D data is also not that uncommon
> in proteomics, so it is a problem that will have to be dealt with
> anyways.
>
> Conceptually, I would consider those just a single {L|G}C-MS run.
> Information on how the 1D RT should be mapped to 2D coordinates
> should be provided in addition to that. We could basically
> store a relation assigning each scan two or more retention
> coordinates (retention times or an index for the primary separation,
> which would also make it comparable to offline fractionation).
>
> Just my two cents,
> Oliver
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1498/3514 - Release Date: 03/18/11
>
>
|
|
From: Steffen N. <sne...@ip...> - 2011-05-27 07:45:48
|
Hi,
On Sun, 2011-03-20 at 19:00 +0100, Oliver Kohlbacher wrote:
...
> Conceptually, I would consider those just a single {L|G}C-MS run.
> Information on how the 1D RT should be mapped to 2D coordinates
> should be provided in addition to that. We could basically
> store a relation assigning each scan two or more retention
> coordinates (retention times or an index for the primary separation,
> which would also make it comparable to offline fractionation).
I now got my hands on some example data from Nils Hoffmann
http://www.cebitec.uni-bielefeld.de/~hoffmann/files/GCxGC-MS-LECO.tar.bz2
which I converted with the OpenMS-1.8 FileConverter
http://msbi.ipb-halle.de/~sneumann/GCxGC_leco.mzML.bz2
1) OpenMS is already able to extract some information from the netCDF
where we lack the proper cvTerms. I would suggest
(also see separate mail on "inlet attribute")
[Term]
id: MS:1000XXX
name: inlet temperature
def: "Inlet temperature." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
is_a: MS:1000XXX ! inlet attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius
[Term]
id: MS:1000XXX
name: source temperature
def: "Source temperature ... ." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius
2a) For GCxGC, we need to specify the 2D coordinate / time system.
I would minimally suggest 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
BTW: how do we "cite" the definition ? I it took from
http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+Matters/Nomenclature-and-Conventions-in-Comprehensive-Mult/ArticleStandard/Article/detail/58429
There are tons more terms in this paper.
2b) Alternatively/additionally, we'd need to be able to add
several dimensions to the scan attribute "elution time".
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 ...)
Does anyone have a better idea ? Please ? Or is this reasonable
with current (and anticipated) seperation techniques ?
The paper above also lists GCϫGCϫGC, LC–GCϫGC or ...
I don't like the ordering in the name, but anything else would
rather be in the scope of sepML, and we still need to reference
several elution times.
Usually, the 2a) modulation time is the "run attribute" that is programmed
into the GCxGC-MS system when you run your samples. The actual elution
times for each scan could be 2b) adjusted / corrected if there are any
shifts/deviations (for whatever reason) within the run.
Thoughts ?
Yours,
Steffen
Just for reference, here is the netCDF metadata from above file(s):
netcdf header information GCxGC {
dimensions:
...
point_number = UNLIMITED ; // (43969157 currently)
scan_number = 100001 ;
variables:
...
// global attributes:
:netcdf_file_date_time_stamp = "20090325161325+0100" ;
:experiment_date_time_stamp = "20090306200015+0100" ;
:experiment_type = "Centroided Mass Spectrum" ;
:test_separation_type = "Gas-Liquid Chromatography" ;
:test_ms_inlet = "Capillary Direct" ;
:test_ms_inlet_temperature = 275.f ;
:test_ionization_mode = "Electron Impact" ;
:test_ionization_polarity = "Positive Polarity" ;
:test_source_temperature = 200.f ;
:test_accelerating_potential = -600.f ;
:test_detector_type = "Electron Multiplier" ;
:test_detector_potential = -1600.f ;
:test_resolution_type = "Constant Resolution" ;
:test_scan_function = "Mass Scan" ;
:test_scan_direction = "Up" ;
:test_scan_law = "Linear" ;
:test_scan_time = 0.0002f ;
...
}
--
IPB Halle AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann http://www.IPB-Halle.DE
Weinberg 3 http://msbi.bic-gh.de
06120 Halle Tel. +49 (0) 345 5582 - 1470
+49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409
|
|
From: Steffen N. <sne...@ip...> - 2011-10-26 14:58:10
|
Hi,
I'd like to revive this thread, which hasn't been brought
to some conclusion. The proposal is twofold:
1) to add a few GC related terms:
[Term]
id: MS:1000XXX
name: inlet temperature
def: "Inlet temperature." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
is_a: MS:1000XXX ! inlet attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius
[Term]
id: MS:1000XXX
name: source temperature
def: "Source temperature ... ." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius
IIRC during the last PSI-MS TelCo someone mentioned further terms
which are reported by GC-MS systems related to the source,
such as the "transfer capillary temperature".
Could someone knowledgeable with GC-MS please add these terms
to this thread ?
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.
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.
I am leaning towards solution 2a) modulation time.
More on multiple coupled chromatography can be found at
http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+Matters/Nomenclature-and-Conventions-in-Comprehensive-Mult/ArticleStandard/Article/detail/58429
which could (properly cited) be used for the definition
of the GCxGC terms.
Yours,
Steffen
On Fri, 2011-05-27 at 09:45 +0200, Steffen Neumann wrote:
...
> On Sun, 2011-03-20 at 19:00 +0100, Oliver Kohlbacher wrote:
> ...
> > Conceptually, I would consider those just a single {L|G}C-MS run.
> > Information on how the 1D RT should be mapped to 2D coordinates
> > should be provided in addition to that. We could basically
> > store a relation assigning each scan two or more retention
> > coordinates (retention times or an index for the primary separation,
> > which would also make it comparable to offline fractionation).
> I now got my hands on some example data from Nils Hoffmann
> http://www.cebitec.uni-bielefeld.de/~hoffmann/files/GCxGC-MS-LECO.tar.bz2
> which I converted with the OpenMS-1.8 FileConverter
> http://msbi.ipb-halle.de/~sneumann/GCxGC_leco.mzML.bz2
>
> 1) OpenMS is already able to extract some information from the netCDF
> where we lack the proper cvTerms. I would suggest
> (also see separate mail on "inlet attribute")
>
> [Term]
> id: MS:1000XXX
> name: inlet temperature
> def: "Inlet temperature." [PSI:MS]
> xref: value-type:xsd\:float "The allowed value-type for this CV term."
> is_a: MS:1000482 ! source attribute
> is_a: MS:1000XXX ! inlet attribute
> relationship: has_units UO:0000012 ! kelvin
> relationship: has_units UO:0000027 ! degree celsius
>
> [Term]
> id: MS:1000XXX
> name: source temperature
> def: "Source temperature ... ." [PSI:MS]
> xref: value-type:xsd\:float "The allowed value-type for this CV term."
> is_a: MS:1000482 ! source attribute
> relationship: has_units UO:0000012 ! kelvin
> relationship: has_units UO:0000027 ! degree celsius
>
> 2a) For GCxGC, we need to specify the 2D coordinate / time system.
> I would minimally suggest 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
>
> BTW: how do we "cite" the definition ? I it took from
> http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+Matters/Nomenclature-and-Conventions-in-Comprehensive-Mult/ArticleStandard/Article/detail/58429
> There are tons more terms in this paper.
>
> 2b) Alternatively/additionally, we'd need to be able to add
> several dimensions to the scan attribute "elution time".
>
> 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 ...)
>
> Does anyone have a better idea ? Please ? Or is this reasonable
> with current (and anticipated) seperation techniques ?
> The paper above also lists GCϫGCϫGC, LC–GCϫGC or ...
> I don't like the ordering in the name, but anything else would
> rather be in the scope of sepML, and we still need to reference
> several elution times.
>
> Usually, the 2a) modulation time is the "run attribute" that is programmed
> into the GCxGC-MS system when you run your samples. The actual elution
> times for each scan could be 2b) adjusted / corrected if there are any
> shifts/deviations (for whatever reason) within the run.
>
> Thoughts ?
>
> Yours,
> Steffen
>
> Just for reference, here is the netCDF metadata from above file(s):
>
> netcdf header information GCxGC {
> dimensions:
> ...
> point_number = UNLIMITED ; // (43969157 currently)
> scan_number = 100001 ;
> variables:
> ...
> // global attributes:
> :netcdf_file_date_time_stamp = "20090325161325+0100" ;
> :experiment_date_time_stamp = "20090306200015+0100" ;
> :experiment_type = "Centroided Mass Spectrum" ;
> :test_separation_type = "Gas-Liquid Chromatography" ;
> :test_ms_inlet = "Capillary Direct" ;
> :test_ms_inlet_temperature = 275.f ;
> :test_ionization_mode = "Electron Impact" ;
> :test_ionization_polarity = "Positive Polarity" ;
> :test_source_temperature = 200.f ;
> :test_accelerating_potential = -600.f ;
> :test_detector_type = "Electron Multiplier" ;
> :test_detector_potential = -1600.f ;
> :test_resolution_type = "Constant Resolution" ;
> :test_scan_function = "Mass Scan" ;
> :test_scan_direction = "Up" ;
> :test_scan_law = "Linear" ;
> :test_scan_time = 0.0002f ;
> ...
> }
>
>
--
IPB Halle AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann http://www.IPB-Halle.DE
Weinberg 3 http://msbi.bic-gh.de
06120 Halle Tel. +49 (0) 345 5582 - 1470
+49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409
|
|
From: Nils H. <nil...@ce...> - 2011-10-26 19:55:19
|
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
|
|
From: Steffen N. <sne...@ip...> - 2011-11-01 09:48:17
|
Hi, On Wed, 2011-10-26 at 16:33 +0200, Steffen Neumann wrote: ... > 1) to add a few GC related terms: There were no objections (but also no additions) to these, and they were mentioned in todays PSI MSS WG call reminder. > 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- There was some support for 2a) add a "modulation time", but left out of todays PSI MSS WG call reminder. It would be great if we can finalize these in the call today, to pave the way for GC-MS based metabolomics. Yours, Steffen -- IPB Halle AG Massenspektrometrie & Bioinformatik Dr. Steffen Neumann http://www.IPB-Halle.DE Weinberg 3 http://msbi.bic-gh.de 06120 Halle Tel. +49 (0) 345 5582 - 1470 +49 (0) 345 5582 - 0 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 |
|
From: Eric D. <ede...@sy...> - 2012-05-23 23:17:30
|
Hi everyone, I think this issue fell by the wayside a while back. I spoke with Nils Hoffmann as ASMS and he urged that we get these in the CV so he can use them. So I propose that we add the following terms. Unless there are objections, would you add these at the next interval, Gerhard? Thanks! Eric [Term] id: MS:1000XXX name: inlet temperaturedef: "The temperature of the inlet of a mass spectrometer." [PSI:MS] xref: value-type:xsd\:float "The allowed value-type for this CV term." is_a: MS:1000482 ! source attribute is_a: MS:1000XXX ! inlet attribute relationship: has_units UO:0000012 ! kelvin relationship: has_units UO:0000027 ! degree celsius [Term] id: MS:1000XXX name: source temperature def: "The temperature of the source of a mass spectrometer." [PSI:MS] xref: value-type:xsd\:float "The allowed value-type for this CV term." is_a: MS:1000482 ! source attribute relationship: has_units UO:0000012 ! kelvin relationship: has_units UO:0000027 ! degree celsius [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." [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 > -----Original Message----- > From: Steffen Neumann [mailto:sne...@ip...] > Sent: Friday, May 27, 2011 12:46 AM > To: Mass spectrometry standard development > Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? > > Hi, > > On Sun, 2011-03-20 at 19:00 +0100, Oliver Kohlbacher wrote: > ... > > Conceptually, I would consider those just a single {L|G}C-MS run. > > Information on how the 1D RT should be mapped to 2D coordinates > > should be provided in addition to that. We could basically > > store a relation assigning each scan two or more retention > > coordinates (retention times or an index for the primary separation, > > which would also make it comparable to offline fractionation). > > I now got my hands on some example data from Nils Hoffmann > http://www.cebitec.uni-bielefeld.de/~hoffmann/files/GCxGC-MS- > LECO.tar.bz2 > which I converted with the OpenMS-1.8 FileConverter > http://msbi.ipb-halle.de/~sneumann/GCxGC_leco.mzML.bz2 > > 1) OpenMS is already able to extract some information from the netCDF > where we lack the proper cvTerms. I would suggest > (also see separate mail on "inlet attribute") > > [Term] > id: MS:1000XXX > name: inlet temperature > def: "Inlet temperature." [PSI:MS] > xref: value-type:xsd\:float "The allowed value-type for this CV term." > is_a: MS:1000482 ! source attribute > is_a: MS:1000XXX ! inlet attribute > relationship: has_units UO:0000012 ! kelvin > relationship: has_units UO:0000027 ! degree celsius > > [Term] > id: MS:1000XXX > name: source temperature > def: "Source temperature ... ." [PSI:MS] > xref: value-type:xsd\:float "The allowed value-type for this CV term." > is_a: MS:1000482 ! source attribute > relationship: has_units UO:0000012 ! kelvin > relationship: has_units UO:0000027 ! degree celsius > > 2a) For GCxGC, we need to specify the 2D coordinate / time system. > I would minimally suggest 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 > > BTW: how do we "cite" the definition ? I it took from > > http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+M > atters/Nomenclature-and-Conventions-in-Comprehensive- > Mult/ArticleStandard/Article/detail/58429 > There are tons more terms in this paper. > > 2b) Alternatively/additionally, we'd need to be able to add > several dimensions to the scan attribute "elution time". > > 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 > ...) > > Does anyone have a better idea ? Please ? Or is this reasonable > with current (and anticipated) seperation techniques ? > The paper above also lists GCϫGCϫGC, LC–GCϫGC or ... > I don't like the ordering in the name, but anything else would > rather be in the scope of sepML, and we still need to reference > several elution times. > > Usually, the 2a) modulation time is the "run attribute" that is > programmed > into the GCxGC-MS system when you run your samples. The actual elution > times for each scan could be 2b) adjusted / corrected if there are any > shifts/deviations (for whatever reason) within the run. > > Thoughts ? > > Yours, > Steffen > > Just for reference, here is the netCDF metadata from above file(s): > > netcdf header information GCxGC { > dimensions: > ... > point_number = UNLIMITED ; // (43969157 currently) > scan_number = 100001 ; > variables: > ... > // global attributes: > :netcdf_file_date_time_stamp = "20090325161325+0100" ; > :experiment_date_time_stamp = "20090306200015+0100" ; > :experiment_type = "Centroided Mass Spectrum" ; > :test_separation_type = "Gas-Liquid Chromatography" ; > :test_ms_inlet = "Capillary Direct" ; > :test_ms_inlet_temperature = 275.f ; > :test_ionization_mode = "Electron Impact" ; > :test_ionization_polarity = "Positive Polarity" ; > :test_source_temperature = 200.f ; > :test_accelerating_potential = -600.f ; > :test_detector_type = "Electron Multiplier" ; > :test_detector_potential = -1600.f ; > :test_resolution_type = "Constant Resolution" ; > :test_scan_function = "Mass Scan" ; > :test_scan_direction = "Up" ; > :test_scan_law = "Linear" ; > :test_scan_time = 0.0002f ; > ... > } > > > -- > IPB Halle AG Massenspektrometrie & Bioinformatik > Dr. Steffen Neumann http://www.IPB-Halle.DE > Weinberg 3 http://msbi.bic-gh.de > 06120 Halle Tel. +49 (0) 345 5582 - 1470 > +49 (0) 345 5582 - 0 > sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 > > > > ----------------------------------------------------------------------- > ------- > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
|
From: Gerhard M. <Ger...@ru...> - 2012-05-24 16:10:53
|
Hi Eric, should we also define something like an inlet attribute (referenced by inlet temperature)? [Term] id: MS:1002039 name: inlet attribute def: "Inlet properties that are associated with a value." [PSI:MS] is_a: MS:1000547 ! object attribute Best, Gerhard Am 24.05.2012 01:17, schrieb Eric Deutsch: > Hi everyone, I think this issue fell by the wayside a while back. I spoke > with Nils Hoffmann as ASMS and he urged that we get these in the CV so he > can use them. So I propose that we add the following terms. > > Unless there are objections, would you add these at the next interval, > Gerhard? > > Thanks! > Eric > > [Term] > id: MS:1000XXX > name: inlet temperaturedef: > "The temperature of the inlet of a mass spectrometer." [PSI:MS] > xref: value-type:xsd\:float "The allowed value-type for this CV term." > is_a: MS:1000482 ! source attribute > is_a: MS:1000XXX ! inlet attribute > relationship: has_units UO:0000012 ! kelvin > relationship: has_units UO:0000027 ! degree celsius > > [Term] > id: MS:1000XXX > name: source temperature > def: "The temperature of the source of a mass spectrometer." [PSI:MS] > xref: value-type:xsd\:float "The allowed value-type for this CV term." > is_a: MS:1000482 ! source attribute > relationship: has_units UO:0000012 ! kelvin > relationship: has_units UO:0000027 ! degree celsius > > [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." > [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 > > > >> -----Original Message----- >> From: Steffen Neumann [mailto:sne...@ip...] >> Sent: Friday, May 27, 2011 12:46 AM >> To: Mass spectrometry standard development >> Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? >> >> Hi, >> >> On Sun, 2011-03-20 at 19:00 +0100, Oliver Kohlbacher wrote: >> ... >>> Conceptually, I would consider those just a single {L|G}C-MS run. >>> Information on how the 1D RT should be mapped to 2D coordinates >>> should be provided in addition to that. We could basically >>> store a relation assigning each scan two or more retention >>> coordinates (retention times or an index for the primary separation, >>> which would also make it comparable to offline fractionation). >> I now got my hands on some example data from Nils Hoffmann >> http://www.cebitec.uni-bielefeld.de/~hoffmann/files/GCxGC-MS- >> LECO.tar.bz2 >> which I converted with the OpenMS-1.8 FileConverter >> http://msbi.ipb-halle.de/~sneumann/GCxGC_leco.mzML.bz2 >> >> 1) OpenMS is already able to extract some information from the netCDF >> where we lack the proper cvTerms. I would suggest >> (also see separate mail on "inlet attribute") >> >> [Term] >> id: MS:1000XXX >> name: inlet temperature >> def: "Inlet temperature." [PSI:MS] >> xref: value-type:xsd\:float "The allowed value-type for this CV term." >> is_a: MS:1000482 ! source attribute >> is_a: MS:1000XXX ! inlet attribute >> relationship: has_units UO:0000012 ! kelvin >> relationship: has_units UO:0000027 ! degree celsius >> >> [Term] >> id: MS:1000XXX >> name: source temperature >> def: "Source temperature ... ." [PSI:MS] >> xref: value-type:xsd\:float "The allowed value-type for this CV term." >> is_a: MS:1000482 ! source attribute >> relationship: has_units UO:0000012 ! kelvin >> relationship: has_units UO:0000027 ! degree celsius >> >> 2a) For GCxGC, we need to specify the 2D coordinate / time system. >> I would minimally suggest 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 >> >> BTW: how do we "cite" the definition ? I it took from >> >> http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+M >> atters/Nomenclature-and-Conventions-in-Comprehensive- >> Mult/ArticleStandard/Article/detail/58429 >> There are tons more terms in this paper. >> >> 2b) Alternatively/additionally, we'd need to be able to add >> several dimensions to the scan attribute "elution time". >> >> 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 >> ...) >> >> Does anyone have a better idea ? Please ? Or is this reasonable >> with current (and anticipated) seperation techniques ? >> The paper above also lists GCϫGCϫGC, LC–GCϫGC or ... >> I don't like the ordering in the name, but anything else would >> rather be in the scope of sepML, and we still need to reference >> several elution times. >> >> Usually, the 2a) modulation time is the "run attribute" that is >> programmed >> into the GCxGC-MS system when you run your samples. The actual elution >> times for each scan could be 2b) adjusted / corrected if there are any >> shifts/deviations (for whatever reason) within the run. >> >> Thoughts ? >> >> Yours, >> Steffen >> >> Just for reference, here is the netCDF metadata from above file(s): >> >> netcdf header information GCxGC { >> dimensions: >> ... >> point_number = UNLIMITED ; // (43969157 currently) >> scan_number = 100001 ; >> variables: >> ... >> // global attributes: >> :netcdf_file_date_time_stamp = "20090325161325+0100" ; >> :experiment_date_time_stamp = "20090306200015+0100" ; >> :experiment_type = "Centroided Mass Spectrum" ; >> :test_separation_type = "Gas-Liquid Chromatography" ; >> :test_ms_inlet = "Capillary Direct" ; >> :test_ms_inlet_temperature = 275.f ; >> :test_ionization_mode = "Electron Impact" ; >> :test_ionization_polarity = "Positive Polarity" ; >> :test_source_temperature = 200.f ; >> :test_accelerating_potential = -600.f ; >> :test_detector_type = "Electron Multiplier" ; >> :test_detector_potential = -1600.f ; >> :test_resolution_type = "Constant Resolution" ; >> :test_scan_function = "Mass Scan" ; >> :test_scan_direction = "Up" ; >> :test_scan_law = "Linear" ; >> :test_scan_time = 0.0002f ; >> ... >> } >> >> >> -- >> IPB Halle AG Massenspektrometrie& Bioinformatik >> Dr. Steffen Neumann http://www.IPB-Halle.DE >> Weinberg 3 http://msbi.bic-gh.de >> 06120 Halle Tel. +49 (0) 345 5582 - 1470 >> +49 (0) 345 5582 - 0 >> sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 >> >> >> >> ----------------------------------------------------------------------- >> ------- >> vRanger cuts backup time in half-while increasing security. >> With the market-leading solution for virtual backup and recovery, >> you get blazing-fast, flexible, and affordable data protection. >> Download your free trial now. >> http://p.sf.net/sfu/quest-d2dcopy1 >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev -- --- Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer BioInformatik Medizinisches-Proteom-Center (MPC) Ruhr-Universität Bochum Zentrum für klinische Forschung I (ZKF I) E.042 Universitätsstrasse 150 D-44801 Bochum Phone: +49(0)234/32-29836 Fax: +49(0)234/32-14554 Email: Ger...@ru... Web: http://www.medizinisches-proteom-center.de |
|
From: Eric D. <Eri...@sy...> - 2012-05-24 16:58:54
|
Hi Gerhard, yes, I think this is probably the right thing to do. I have this vague recollection that we were trying to do away with "object attribute" since we introduced data types for each term. But maybe I'm misremembering... Thanks, Eric > -----Original Message----- > From: Gerhard Mayer [mailto:Ger...@ru...] > Sent: Thursday, May 24, 2012 9:11 AM > To: Mass spectrometry standard development > Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? > > Hi Eric, > > should we also define something like an inlet attribute (referenced by > inlet temperature)? > > [Term] > id: MS:1002039 > name: inlet attribute > def: "Inlet properties that are associated with a value." [PSI:MS] > is_a: MS:1000547 ! object attribute > > Best, > Gerhard > > > Am 24.05.2012 01:17, schrieb Eric Deutsch: > > Hi everyone, I think this issue fell by the wayside a while back. I > spoke > > with Nils Hoffmann as ASMS and he urged that we get these in the CV > so he > > can use them. So I propose that we add the following terms. > > > > Unless there are objections, would you add these at the next > interval, > > Gerhard? > > > > Thanks! > > Eric > > > > [Term] > > id: MS:1000XXX > > name: inlet temperaturedef: > > "The temperature of the inlet of a mass spectrometer." [PSI:MS] > > xref: value-type:xsd\:float "The allowed value-type for this CV > term." > > is_a: MS:1000482 ! source attribute > > is_a: MS:1000XXX ! inlet attribute > > relationship: has_units UO:0000012 ! kelvin > > relationship: has_units UO:0000027 ! degree celsius > > > > [Term] > > id: MS:1000XXX > > name: source temperature > > def: "The temperature of the source of a mass spectrometer." [PSI:MS] > > xref: value-type:xsd\:float "The allowed value-type for this CV > term." > > is_a: MS:1000482 ! source attribute > > relationship: has_units UO:0000012 ! kelvin > > relationship: has_units UO:0000027 ! degree celsius > > > > [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." > > > [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 > > > > > > > >> -----Original Message----- > >> From: Steffen Neumann [mailto:sne...@ip...] > >> Sent: Friday, May 27, 2011 12:46 AM > >> To: Mass spectrometry standard development > >> Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? > >> > >> Hi, > >> > >> On Sun, 2011-03-20 at 19:00 +0100, Oliver Kohlbacher wrote: > >> ... > >>> Conceptually, I would consider those just a single {L|G}C-MS run. > >>> Information on how the 1D RT should be mapped to 2D coordinates > >>> should be provided in addition to that. We could basically > >>> store a relation assigning each scan two or more retention > >>> coordinates (retention times or an index for the primary > separation, > >>> which would also make it comparable to offline fractionation). > >> I now got my hands on some example data from Nils Hoffmann > >> http://www.cebitec.uni-bielefeld.de/~hoffmann/files/GCxGC-MS- > >> LECO.tar.bz2 > >> which I converted with the OpenMS-1.8 FileConverter > >> http://msbi.ipb-halle.de/~sneumann/GCxGC_leco.mzML.bz2 > >> > >> 1) OpenMS is already able to extract some information from the > netCDF > >> where we lack the proper cvTerms. I would suggest > >> (also see separate mail on "inlet attribute") > >> > >> [Term] > >> id: MS:1000XXX > >> name: inlet temperature > >> def: "Inlet temperature." [PSI:MS] > >> xref: value-type:xsd\:float "The allowed value-type for this CV > term." > >> is_a: MS:1000482 ! source attribute > >> is_a: MS:1000XXX ! inlet attribute > >> relationship: has_units UO:0000012 ! kelvin > >> relationship: has_units UO:0000027 ! degree celsius > >> > >> [Term] > >> id: MS:1000XXX > >> name: source temperature > >> def: "Source temperature ... ." [PSI:MS] > >> xref: value-type:xsd\:float "The allowed value-type for this CV > term." > >> is_a: MS:1000482 ! source attribute > >> relationship: has_units UO:0000012 ! kelvin > >> relationship: has_units UO:0000027 ! degree celsius > >> > >> 2a) For GCxGC, we need to specify the 2D coordinate / time system. > >> I would minimally suggest 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 > >> > >> BTW: how do we "cite" the definition ? I it took from > >> > >> > http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+M > >> atters/Nomenclature-and-Conventions-in-Comprehensive- > >> Mult/ArticleStandard/Article/detail/58429 > >> There are tons more terms in this paper. > >> > >> 2b) Alternatively/additionally, we'd need to be able to add > >> several dimensions to the scan attribute "elution time". > >> > >> 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 > >> ...) > >> > >> Does anyone have a better idea ? Please ? Or is this > reasonable > >> with current (and anticipated) seperation techniques ? > >> The paper above also lists GCϫGCϫGC, LC–GCϫGC or ... > >> I don't like the ordering in the name, but anything else would > >> rather be in the scope of sepML, and we still need to > reference > >> several elution times. > >> > >> Usually, the 2a) modulation time is the "run attribute" that is > >> programmed > >> into the GCxGC-MS system when you run your samples. The actual > elution > >> times for each scan could be 2b) adjusted / corrected if there are > any > >> shifts/deviations (for whatever reason) within the run. > >> > >> Thoughts ? > >> > >> Yours, > >> Steffen > >> > >> Just for reference, here is the netCDF metadata from above file(s): > >> > >> netcdf header information GCxGC { > >> dimensions: > >> ... > >> point_number = UNLIMITED ; // (43969157 currently) > >> scan_number = 100001 ; > >> variables: > >> ... > >> // global attributes: > >> :netcdf_file_date_time_stamp = "20090325161325+0100" ; > >> :experiment_date_time_stamp = "20090306200015+0100" ; > >> :experiment_type = "Centroided Mass Spectrum" ; > >> :test_separation_type = "Gas-Liquid Chromatography" ; > >> :test_ms_inlet = "Capillary Direct" ; > >> :test_ms_inlet_temperature = 275.f ; > >> :test_ionization_mode = "Electron Impact" ; > >> :test_ionization_polarity = "Positive Polarity" ; > >> :test_source_temperature = 200.f ; > >> :test_accelerating_potential = -600.f ; > >> :test_detector_type = "Electron Multiplier" ; > >> :test_detector_potential = -1600.f ; > >> :test_resolution_type = "Constant Resolution" ; > >> :test_scan_function = "Mass Scan" ; > >> :test_scan_direction = "Up" ; > >> :test_scan_law = "Linear" ; > >> :test_scan_time = 0.0002f ; > >> ... > >> } > >> > >> > >> -- > >> IPB Halle AG Massenspektrometrie& Bioinformatik > >> Dr. Steffen Neumann http://www.IPB-Halle.DE > >> Weinberg 3 http://msbi.bic-gh.de > >> 06120 Halle Tel. +49 (0) 345 5582 - 1470 > >> +49 (0) 345 5582 - 0 > >> sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 > >> > >> > >> > >> -------------------------------------------------------------------- > --- > >> ------- > >> vRanger cuts backup time in half-while increasing security. > >> With the market-leading solution for virtual backup and recovery, > >> you get blazing-fast, flexible, and affordable data protection. > >> Download your free trial now. > >> http://p.sf.net/sfu/quest-d2dcopy1 > >> _______________________________________________ > >> Psidev-ms-dev mailing list > >> Psi...@li... > >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > --------------------------------------------------------------------- > --------- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > Discussions > > will include endpoint security, mobile security and the latest in > malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > -- > --- > Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer > BioInformatik > Medizinisches-Proteom-Center (MPC) > Ruhr-Universität Bochum > Zentrum für klinische Forschung I (ZKF I) > E.042 > Universitätsstrasse 150 > D-44801 Bochum > > Phone: +49(0)234/32-29836 > Fax: +49(0)234/32-14554 > Email: Ger...@ru... > Web: http://www.medizinisches-proteom-center.de > > > ----------------------------------------------------------------------- > ------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
|
From: Steffen N. <sne...@ip...> - 2012-05-25 14:32:51
|
Hi, On Thu, 2012-05-24 at 18:10 +0200, Gerhard Mayer wrote: > should we also define something like an inlet attribute (referenced by > inlet temperature)? We had been discussing this back when I had started the thread. I will dig back and suggest the terms again. Stay tuned. Yours, Steffen -- IPB Halle AG Massenspektrometrie & Bioinformatik Dr. Steffen Neumann http://www.IPB-Halle.DE Weinberg 3 http://msbi.bic-gh.de 06120 Halle Tel. +49 (0) 345 5582 - 1470 +49 (0) 345 5582 - 0 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 |
|
From: Steffen N. <sne...@ip...> - 2012-05-28 19:48:23
|
Hi, On Thu, 2012-05-24 at 18:10 +0200, Gerhard Mayer wrote: > should we also define something like an inlet attribute (referenced by > inlet temperature)? Yes, and they were part of the call notes from Tue, 1 Nov 2011 "[Psidev-pi-dev] PSI MSS WG call notes" where the "inlet attribute" had a relationship: part_of MS:1000458 ! source I don't recall that we wanted to get rid of "object attribute", my gut feeling is that from an ontology point of view it makes sense to define attributes as such, but we should keep the source and inlet attributes in sync w.r.t. the "object attribute", which currently lacks the "object attribute". OTOH, an attribute such as a temperature is hardly a PART_OF a physical device such as an inlet or source. Yours, Steffen For reference: [Term] id: MS:1000482 name: source attribute def: "Property of a source device that need a value." [PSI:MS] relationship: part_of MS:1000458 ! source -- IPB Halle AG Massenspektrometrie & Bioinformatik Dr. Steffen Neumann http://www.IPB-Halle.DE Weinberg 3 http://msbi.bic-gh.de 06120 Halle Tel. +49 (0) 345 5582 - 1470 +49 (0) 345 5582 - 0 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 |
|
From: Eric D. <Eri...@sy...> - 2012-05-29 03:03:59
|
Hi Steffen, thanks for the input. Yes, this has bothered me for a while that we use "part_of" in an questionable way. We really need some sort of relationship "is_attribute_of". Seems like there should be some kind of relationship like this already. Anyone know? Thanks, Eric > -----Original Message----- > From: Steffen Neumann [mailto:sne...@ip...] > Sent: Monday, May 28, 2012 12:48 PM > To: psi...@li... > Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? > > Hi, > > On Thu, 2012-05-24 at 18:10 +0200, Gerhard Mayer wrote: > > should we also define something like an inlet attribute (referenced > by > > inlet temperature)? > > Yes, and they were part of the call notes from > Tue, 1 Nov 2011 "[Psidev-pi-dev] PSI MSS WG call notes" > > where the "inlet attribute" had a > > relationship: part_of MS:1000458 ! source > > I don't recall that we wanted to get rid of "object attribute", > my gut feeling is that from an ontology point of view > it makes sense to define attributes as such, > but we should keep the source and inlet attributes in sync > w.r.t. the "object attribute", which currently lacks > the "object attribute". OTOH, an attribute such as a temperature > is hardly a PART_OF a physical device such as an inlet or source. > > Yours, > Steffen > > For reference: > > [Term] > id: MS:1000482 > name: source attribute > def: "Property of a source device that need a value." [PSI:MS] > relationship: part_of MS:1000458 ! source > > -- > IPB Halle AG Massenspektrometrie & Bioinformatik > Dr. Steffen Neumann http://www.IPB-Halle.DE > Weinberg 3 http://msbi.bic-gh.de > 06120 Halle Tel. +49 (0) 345 5582 - 1470 > +49 (0) 345 5582 - 0 > sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 > > > > ----------------------------------------------------------------------- > ------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
|
From: Neumann, S. <Ste...@ip...> - 2011-03-15 19:59:13
|
Hi, Yes, GCxGC is (almost ?) always online. Here is an image: http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php if I get it orrectly, the Y axis is the "fast" column (think seconds), the X axis the "slow" column (order of minutes). Each Pixel would be a TIC, with a full spectrum "behind" it. (Or did I mix the axes up ?) There is also some course material, including GCxGC/TOF-MS at p27 http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf So as Nils confirmed, mzML is technically capable of carrying GCxGC data as a (large) number of spectra. However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings, so that images such as the one above can be created. This would also be required for 2D peak picking (or alignment). No need to encode all sorts of GC column information, that might go into sepML or whatever. Following Nils, I'd suggest something like [Term] id: MS:1000XXX name: second column modulation time def: "The time of ..." [PSI:MS] xref: value-type:xsd\:float "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 as a <cvParam> for the <run>. Any software ignoring this 2D nature would simply see a (very) strange pattern of spectra. Thoughts ? Does anyone have contact with sbd. at Leco ? Which are the other major players with GCxGC ? Yours, Steffen |
|
From: Matthew C. <mat...@gm...> - 2011-03-15 20:28:13
|
Also, if each pixel is a TIC from a spectrum, then the image could be easily and quickly constructed using the TIC chromatograms. -Matt On 3/15/2011 2:59 PM, Neumann, Steffen wrote: > Hi, > > Yes, GCxGC is (almost ?) always online. Here is an image: > http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php > > if I get it orrectly, the Y axis is the "fast" column (think seconds), > the X axis the "slow" column (order of minutes). Each Pixel would be a TIC, > with a full spectrum "behind" it. (Or did I mix the axes up ?) > > There is also some course material, including GCxGC/TOF-MS at p27 > http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf > > So as Nils confirmed, mzML is technically capable of carrying GCxGC data > as a (large) number of spectra. > > However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings, > so that images such as the one above can be created. This would also be > required for 2D peak picking (or alignment). No need to encode all sorts > of GC column information, that might go into sepML or whatever. > > Following Nils, I'd suggest something like > > [Term] > id: MS:1000XXX > name: second column modulation time > def: "The time of ..." [PSI:MS] > xref: value-type:xsd\:float "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 > > as a<cvParam> for the<run>. Any software ignoring this 2D nature > would simply see a (very) strange pattern of spectra. > > Thoughts ? Does anyone have contact with sbd. at Leco ? > Which are the other major players with GCxGC ? > > Yours, > Steffen |
|
From: Neumann, S. <Ste...@ip...> - 2011-03-15 20:55:17
|
Hi, no, I think the 2nd dimension is in such a rapid succession (few seconds!), that a single metabolite elutes across several of those, and hence it makes no sense to split into multiple files. Yours, Steffen ________________________________________ From: Matthew Chambers [mat...@gm...] Sent: 15 March 2011 21:25 To: psi...@li... Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ? You propose a <run> cvParam, but there is only one run per mzML. So you are agreeing with me that each 2nd dimension fraction would be a separate mzML? Constructing the 2d x vs. y would require reading from multiple mzMLs then. -Matt On 3/15/2011 2:59 PM, Neumann, Steffen wrote: > Hi, > > Yes, GCxGC is (almost ?) always online. Here is an image: > http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php > > if I get it orrectly, the Y axis is the "fast" column (think seconds), > the X axis the "slow" column (order of minutes). Each Pixel would be a TIC, > with a full spectrum "behind" it. (Or did I mix the axes up ?) > > There is also some course material, including GCxGC/TOF-MS at p27 > http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf > > So as Nils confirmed, mzML is technically capable of carrying GCxGC data > as a (large) number of spectra. > > However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings, > so that images such as the one above can be created. This would also be > required for 2D peak picking (or alignment). No need to encode all sorts > of GC column information, that might go into sepML or whatever. > > Following Nils, I'd suggest something like > > [Term] > id: MS:1000XXX > name: second column modulation time > def: "The time of ..." [PSI:MS] > xref: value-type:xsd\:float "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 > > as a<cvParam> for the<run>. Any software ignoring this 2D nature > would simply see a (very) strange pattern of spectra. > > Thoughts ? Does anyone have contact with sbd. at Leco ? > Which are the other major players with GCxGC ? > > Yours, > Steffen ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Psidev-ms-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
|
From: Neumann, S. <sne...@ip...> - 2011-03-21 16:17:39
|
Hi Chris (Taylor ?) I think you overshoot a bit here, the raw data of 2D GCxGC (or LCxLC for that matter) will be stored by the MS instrument in a single file, therefore I think it is quite natural to keep it in one mzML file. The only difference to 1D GC-MS (or LC-MS) is that the retention time observed by the MS instrument stems can be mapped back to 2D retention "positions" (?) resulting from two individual (but coupled) GC separations. So it comes down to the question how to store the information about re-mapping the retention time(s), and that definitely has to be kept inside the mzML because it must not get lost. Yours, Steffen |
|
From: Chris T. <chr...@eb...> - 2011-03-22 10:13:52
|
Absolutely, some cases are simple, and clearly the retention times should stay with the m/z data (those retention times are measurements by the mass spec anyway of course), but where the first dimension is kept as a series of aliquots and then each run out in a later 1D LCMS (still effectively 2D), or where a series of gel plugs are being analysed, or where you simply want to say more about the column, I think the format would begin to feel the stretch no? Also, more generally we have no effective way of transferring more than trivial amounts of information about samples as things stand. This could be solved with ISA-Tab itself, but previously there hasn't been much appetite for that in this group... Anyway I suppose the rush of enthusiasm is all the answer I need. C. On 21/03/2011 16:17, Neumann, Steffen wrote: > Hi Chris (Taylor ?) > > I think you overshoot a bit here, the raw data > of 2D GCxGC (or LCxLC for that matter) will be stored > by the MS instrument in a single file, therefore > I think it is quite natural to keep it in one mzML file. > > The only difference to 1D GC-MS (or LC-MS) is that > the retention time observed by the MS instrument > stems can be mapped back to 2D retention "positions" (?) > resulting from two individual (but coupled) GC separations. > > So it comes down to the question how to store the > information about re-mapping the retention time(s), > and that definitely has to be kept inside the mzML > because it must not get lost. > > Yours, > Steffen > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1498/3521 - Release Date: 03/21/11 > > -- ~~~~~~~~~~~~~~~~~~~~~~~~ chr...@eb... http://www.mibbi.org/ ~~~~~~~~~~~~~~~~~~~~~~~~ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X