psidev-pi-dev

[Psidev-pi-dev] storing intermediate results in mzML

[Richard S. <r.a...@ru...>]

Dear all,

I'm writing a metabolomics Java library for my processing software 
targeted towards high resolution LC/MS data (components like: peak 
picking, noise detection, etc). The basic element for this library is a 
mass chromatogram (x-axis time, y-axis intensity). In order to deal with 
the size of the datasets, enable other people to easily write 
components, etc. an intermediate file format is required. I've already 
defined one myself to see what would be required for a really dynamic 
pipeline and created a library on top of it. In order to hop on the 
international standards bandwagon I would off course like to move to a 
recognized standard like mzML. However, this _seems_ to fall short of my 
requirements. I've been browsing through this list and the standards 
document and tried to implement something, but I can't seem to figure 
out how to approach this.

What I would like to be able to do is store the following pieces of 
information:

- Multiple runs in a single file
 From the specification document: "A run in mzML should correspond to a 
single, consecutive and coherent set of scans on an instrument". This 
means that I essentially can only store data from a single raw file? I 
would like to do mix-models (see sets).

- MassChromatograms (single mass)
I would like to ubiquitously store mass chromatograms picked from the 
raw data. This means that both mass chromatograms made from centroid as 
well as profile data need to be stored. There is the option to store 
chromatogram data, but this seems limited to '2D' data where mass 
chromatogram data build with profile data needs '3D' data. In order to 
solve this the accession="MS:1000627" name="selected ion current 
chromatogram" needs sub-children? Or can it be set globally in the 
header or run, but then I would like to be able to mix models (see sets).

- BackgroundIons
The use of background ions are part of the pipeline. To store this an 
addition to the CV needs to be made.
 name: backgroundion chromatogram
 is_a: chromatogram type (MS:1000626)
 definition: chromatogram created by creating an array of a ubiquitously 
present mass.

- sets
The goal of the pipeline is to combine information from lots of 
measurements (biological, technical replicates, different machines, etc) 
and do perform various analysis methods. This means for example that 
background ions or mass chromatograms from various measurements need to 
be combined into sets. Different operations and visualizations are then 
possible on the data stored in the files. The same as the different runs 
applies here. Another option would be to make sets of sets, which means 
that the relation needs to be recursive. I can probably solve some of 
the issues with id-fields, but that would make it hard to parse for 
other people and sort of rule out the recursive relation.


I can off course solve a lot with the use of userParam tags, but then 
other people will have a hard time reading the data. Another thing, I 
once heard somebody mention AnalysisML to be something along these 
lines, however this project seems to have suffered a fatal end as I 
cannot find anything? Am I trying to use mzML outside of its boundries? 
If so, is a viable alternative available which I have so far been unable 
to find?


Cheers,
Richard

-- 
Drs. ing. RA Scheltema    Groningen Bioinformatics Centre
Tel: +31 50 363 8078      Kerklaan 30
Fax: +31 50 363 7976      9751 NN, Haren
Mob: +31 6 140 280 21     The Netherlands

Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 3A4F 3029 DF7D 2562 6653 053B 458C 39E7 C428 4618

[Psidev-pi-dev] storing intermediate results in mzML

[Richard S. <r.a...@ru...>]

My email ended up only in ms-dev, so trying to repost here to.



Dear all,

Thank you for your comments. A question from my side, is the phone 
conference scheduled for this afternoon open? As I'm on the agenda I 
would like to join if possible.


Matthew Chambers wrote:

> > I'm not sure what this would look like. We certainly didn't have 3d 
> > chromatograms in mind, but perhaps they can be accommodated. Would that 
> > be a chromatogram with three axes (data arrays): time, m/z, and 
> > intensity? Is this akin to the "psuedo-2d-gel" view?
>   
The mass chromatogram would indeed consist of time, m/z and intensity. 
The m/z data coming from the profile spectrum data. If you plot the mass 
chromatogram it will look a bit like a bell. I'm not quite sure what you 
mean with the pseudo-2d-gel view, but as I understand it, this is a 2d 
view of all the mass chromatograms found in for example a LC/MS profile. 
In the definition of the chromatogram block some semantics should be 
worked out in order to let the parser figure out what is stored there.

I would suggest something as following (a mass chromatogram spanning 9 
scans, sorry for the verbosity of it all). For the centroid data the 
original structure would hold with the addition of the cvParam MS:1000127:

<chromatogram id="0" index="0" defaultArrayLength="9">
   <cvParam cvRef="MS" accession="MS:1000627" name="selected ion current 
chromatogram" value="" />
   <cvParam cvRef="MS" accession="MS:1000128" name="profile mass 
spectrum" value="" />
  
   <binaryDataArrayList count="19">
      <binaryDataArray encodedLength="36">
         <cvParam cvRef="MS" accession="MS:1000519" name="32-bit 
integer" value="" />
         <cvParam cvRef="MS" accession="MS:1000576" name="no 
compression" value="" />
         <cvParam cvRef="MS" accession="MS:1000595" name="time array" 
value="" />
         <binary>.......</binary>
      </binaryDataArray>
      // scan 0
      <binaryDataArray encodedLength="72">
         <cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" 
value="" />
         <cvParam cvRef="MS" accession="MS:1000576" name="no 
compression" value="" />
         <cvParam cvRef="MS" accession="MS:1000514" name="m/z array" 
value="" />
         <binary>.......</binary>
      </binaryDataArray>
      <binaryDataArray encodedLength="72">
         <cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" 
value="" />
         <cvParam cvRef="MS" accession="MS:1000576" name="no 
compression" value="" />
         <cvParam cvRef="MS" accession="MS:1000515" name="intensity 
array" value="" />
         <binary>.......</binary>
      </binaryDataArray>
      // scan 1
      ...
   </binaryDataArrayList>
</chromatogram>

> > Yes, I think a background ion chromatogram is reasonable. But there may 
> > be some semantics to work out: is there a distinction between 
> > "background ions" and "noise"? I know there are different kinds of noise 
> > to think about...
>   
There is a distinction between noise and background ions. The definition 
for a background ion should according to me in LC/MS be a compound which 
is continuously eluting from the LC/GC or continuously being injected 
into the MS. A famous example of this would be PEGs dissolving from the 
plastic tubing used to transport the sample from the LC to the MS. So 
background ions are real (usable) compounds, while noise are artefacts 
from the measurement technique used not describing a real compound. 
Isomers forming a peak on top of the elution pattern of a background ion 
should probably be removed.

If this definition is maintained I think the addition to the CV that I 
proposed still holds, but I could be wrong and more is necessary? 
Probably single spectra (no separation up front) would suffer a bit, 
although then we're not really talking about a chromatogram right?

 name: backgroundion chromatogram
 is_a: chromatogram type (MS:1000626)
 definition: chromatogram created by creating an array of a ubiquitously present mass.


David Creasy wrote:

> > We're still alive (I think!), but I don't think we have what you want:
> > http://psidev.info/index.php?q=node/319
>   
My _very_ quick overview would make me agree. How would we continue from 
here?



Cheers,
Richard

-- 
Drs. ing. RA Scheltema    Groningen Bioinformatics Centre
Tel: +31 50 363 8078      Kerklaan 30
Fax: +31 50 363 7976      9751 NN, Haren
Mob: +31 6 140 280 21     The Netherlands

Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 3A4F 3029 DF7D 2562 6653 053B 458C 39E7 C428 4618

Re: [Psidev-pi-dev] storing intermediate results in mzML

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

Hi Richard,

You posted this message on the analysisXML mailing list. :) I'll cc it 
to the ms-dev list along with my response, although I expect the PI guys 
will have valuable comments as well.


Richard Scheltema wrote:
> Dear all,
>
> I'm writing a metabolomics Java library for my processing software 
> targeted towards high resolution LC/MS data (components like: peak 
> picking, noise detection, etc). The basic element for this library is a 
> mass chromatogram (x-axis time, y-axis intensity). In order to deal with 
> the size of the datasets, enable other people to easily write 
> components, etc. an intermediate file format is required. I've already 
> defined one myself to see what would be required for a really dynamic 
> pipeline and created a library on top of it. In order to hop on the 
> international standards bandwagon I would off course like to move to a 
> recognized standard like mzML. However, this _seems_ to fall short of my 
> requirements. I've been browsing through this list and the standards 
> document and tried to implement something, but I can't seem to figure 
> out how to approach this.
>
> What I would like to be able to do is store the following pieces of 
> information:
>
> - Multiple runs in a single file
>  From the specification document: "A run in mzML should correspond to a 
> single, consecutive and coherent set of scans on an instrument". This 
> means that I essentially can only store data from a single raw file? I 
> would like to do mix-models (see sets).
>   
MzML does not support multiple runs in a single file. It was a design 
decision to make the format simpler. Nothing is stopping you from 
managing a collection of mzML files as a set, though. But it's important 
to understand that mzML is intended to store the raw output of a 
vendor's instrument, as well as processing to the level of a peak list. 
The chromatogram semantics were tacked on as something of an 
afterthought: I lobbied for it because on-demand building of 
chromatograms from tens of thousands of tiny SRM spectra is ridiculously 
slow.


> - MassChromatograms (single mass)
> I would like to ubiquitously store mass chromatograms picked from the 
> raw data. This means that both mass chromatograms made from centroid as 
> well as profile data need to be stored. There is the option to store 
> chromatogram data, but this seems limited to '2D' data where mass 
> chromatogram data build with profile data needs '3D' data. In order to 
> solve this the accession="MS:1000627" name="selected ion current 
> chromatogram" needs sub-children? Or can it be set globally in the 
> header or run, but then I would like to be able to mix models (see sets).
>   
I'm not sure what this would look like. We certainly didn't have 3d 
chromatograms in mind, but perhaps they can be accommodated. Would that 
be a chromatogram with three axes (data arrays): time, m/z, and 
intensity? Is this akin to the "psuedo-2d-gel" view?


> - BackgroundIons
> The use of background ions are part of the pipeline. To store this an 
> addition to the CV needs to be made.
>  name: backgroundion chromatogram
>  is_a: chromatogram type (MS:1000626)
>  definition: chromatogram created by creating an array of a ubiquitously 
> present mass.
>   
Yes, I think a background ion chromatogram is reasonable. But there may 
be some semantics to work out: is there a distinction between 
"background ions" and "noise"? I know there are different kinds of noise 
to think about...


> - sets
> The goal of the pipeline is to combine information from lots of 
> measurements (biological, technical replicates, different machines, etc) 
> and do perform various analysis methods. This means for example that 
> background ions or mass chromatograms from various measurements need to 
> be combined into sets. Different operations and visualizations are then 
> possible on the data stored in the files. The same as the different runs 
> applies here. Another option would be to make sets of sets, which means 
> that the relation needs to be recursive. I can probably solve some of 
> the issues with id-fields, but that would make it hard to parse for 
> other people and sort of rule out the recursive relation.
>
>
> I can off course solve a lot with the use of userParam tags, but then 
> other people will have a hard time reading the data. Another thing, I 
> once heard somebody mention AnalysisML to be something along these 
> lines, however this project seems to have suffered a fatal end as I 
> cannot find anything? Am I trying to use mzML outside of its boundries? 
> If so, is a viable alternative available which I have so far been unable 
> to find?
>   
AnalysisXML is alive and well and about to submit to the PSI 
documentation process AFAIK. As I understand it, it is mostly a 
proteomics identification standard at the moment, but with a flexible 
enough framework to support other kinds of data in later releases. I 
don't recall if it supports multiple runs per file. You can check out 
examples and schema at: http://code.google.com/p/psi-pi/

-Matt

Re: [Psidev-pi-dev] storing intermediate results in mzML

[Richard S. <r.a...@ru...>]

Dear all,

Thank you for your comments. A question from my side, is the phone 
conference scheduled for this afternoon open? As I'm on the agenda I 
would like to join if possible.


Matthew Chambers wrote:
> I'm not sure what this would look like. We certainly didn't have 3d 
> chromatograms in mind, but perhaps they can be accommodated. Would that 
> be a chromatogram with three axes (data arrays): time, m/z, and 
> intensity? Is this akin to the "psuedo-2d-gel" view?
The mass chromatogram would indeed consist of time, m/z and intensity. 
The m/z data coming from the profile spectrum data. If you plot the mass 
chromatogram it will look a bit like a bell. I'm not quite sure what you 
mean with the pseudo-2d-gel view, but as I understand it, this is a 2d 
view of all the mass chromatograms found in for example a LC/MS profile. 
In the definition of the chromatogram block some semantics should be 
worked out in order to let the parser figure out what is stored there.

I would suggest something as following (a mass chromatogram spanning 9 
scans, sorry for the verbosity of it all). For the centroid data the 
original structure would hold with the addition of the cvParam MS:1000127:

<chromatogram id="0" index="0" defaultArrayLength="9">
   <cvParam cvRef="MS" accession="MS:1000627" name="selected ion current 
chromatogram" value="" />
   <cvParam cvRef="MS" accession="MS:1000128" name="profile mass 
spectrum" value="" />
  
   <binaryDataArrayList count="19">
      <binaryDataArray encodedLength="36">
         <cvParam cvRef="MS" accession="MS:1000519" name="32-bit 
integer" value="" />
         <cvParam cvRef="MS" accession="MS:1000576" name="no 
compression" value="" />
         <cvParam cvRef="MS" accession="MS:1000595" name="time array" 
value="" />
         <binary>.......</binary>
      </binaryDataArray>
      // scan 0
      <binaryDataArray encodedLength="72">
         <cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" 
value="" />
         <cvParam cvRef="MS" accession="MS:1000576" name="no 
compression" value="" />
         <cvParam cvRef="MS" accession="MS:1000514" name="m/z array" 
value="" />
         <binary>.......</binary>
      </binaryDataArray>
      <binaryDataArray encodedLength="72">
         <cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" 
value="" />
         <cvParam cvRef="MS" accession="MS:1000576" name="no 
compression" value="" />
         <cvParam cvRef="MS" accession="MS:1000515" name="intensity 
array" value="" />
         <binary>.......</binary>
      </binaryDataArray>
      // scan 1
      ...
   </binaryDataArrayList>
</chromatogram>

> Yes, I think a background ion chromatogram is reasonable. But there may 
> be some semantics to work out: is there a distinction between 
> "background ions" and "noise"? I know there are different kinds of noise 
> to think about...
There is a distinction between noise and background ions. The definition 
for a background ion should according to me in LC/MS be a compound which 
is continuously eluting from the LC/GC or continuously being injected 
into the MS. A famous example of this would be PEGs dissolving from the 
plastic tubing used to transport the sample from the LC to the MS. So 
background ions are real (usable) compounds, while noise are artefacts 
from the measurement technique used not describing a real compound. 
Isomers forming a peak on top of the elution pattern of a background ion 
should probably be removed.

If this definition is maintained I think the addition to the CV that I 
proposed still holds, but I could be wrong and more is necessary? 
Probably single spectra (no separation up front) would suffer a bit, 
although then we're not really talking about a chromatogram right?

 name: backgroundion chromatogram
 is_a: chromatogram type (MS:1000626)
 definition: chromatogram created by creating an array of a ubiquitously present mass.


David Creasy wrote:
> We're still alive (I think!), but I don't think we have what you want:
> http://psidev.info/index.php?q=node/319
My _very_ quick overview would make me agree. How would we continue from 
here?



Cheers,
Richard


-- 
Drs. ing. RA Scheltema    Groningen Bioinformatics Centre
Tel: +31 50 363 8078      Kerklaan 30
Fax: +31 50 363 7976      9751 NN, Haren
Mob: +31 6 140 280 21     The Netherlands

Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 3A4F 3029 DF7D 2562 6653 053B 458C 39E7 C428 4618

Re: [Psidev-pi-dev] [Psidev-ms-dev] storing intermediate results in mzML

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

Richard Scheltema wrote:
> Dear all,
>
> Thank you for your comments. A question from my side, is the phone 
> conference scheduled for this afternoon open? As I'm on the agenda I 
> would like to join if possible.
>   
Yes, the call is open to all interested parties. BYOB. :)


> Matthew Chambers wrote:
>   
>> I'm not sure what this would look like. We certainly didn't have 3d 
>> chromatograms in mind, but perhaps they can be accommodated. Would that 
>> be a chromatogram with three axes (data arrays): time, m/z, and 
>> intensity? Is this akin to the "psuedo-2d-gel" view?
>>     
> The mass chromatogram would indeed consist of time, m/z and intensity. 
> The m/z data coming from the profile spectrum data. If you plot the mass 
> chromatogram it will look a bit like a bell. I'm not quite sure what you 
> mean with the pseudo-2d-gel view, but as I understand it, this is a 2d 
> view of all the mass chromatograms found in for example a LC/MS profile. 
> In the definition of the chromatogram block some semantics should be 
> worked out in order to let the parser figure out what is stored there.
>
> I would suggest something as following (a mass chromatogram spanning 9 
> scans, sorry for the verbosity of it all). For the centroid data the 
> original structure would hold with the addition of the cvParam MS:1000127:
>
> <snip>
I fear this is a pretty cryptic representation that would rarely be 
supported. I'm thinking the preferable way to store these chromatograms 
is simply as a series of 2d chromatograms. Yes, it means repeating the 
metadata and the time array every time, but I don't feel that's a 
critical issue. Actually, repeating the metadata is probably a bonus, 
because each slice of the 3d chromatogram (the separated dimension being 
m/z) should correspond with a single m/z. We have yet to settle on the 
"right" way to put m/z in the chromatogram elements, even for simpler 
concepts like an SRM chromatogram.


>> Yes, I think a background ion chromatogram is reasonable. But there may 
>> be some semantics to work out: is there a distinction between 
>> "background ions" and "noise"? I know there are different kinds of noise 
>> to think about...
>>     
> There is a distinction between noise and background ions. The definition 
> for a background ion should according to me in LC/MS be a compound which 
> is continuously eluting from the LC/GC or continuously being injected 
> into the MS. A famous example of this would be PEGs dissolving from the 
> plastic tubing used to transport the sample from the LC to the MS. So 
> background ions are real (usable) compounds, while noise are artefacts 
> from the measurement technique used not describing a real compound. 
>   
I would argue that both electronic noise and chemical ("real") noise are 
kinds of noise. They are also both ways to get a certain level of 
background intensity. I glean these meanings from the "signal to noise" 
calculation often used. As far as I know, the "noise" denominator there 
refers to the sum of electronic and chemical noise. So in my lexicon, 
noise and background are nearly synonymous, but "electronic noise" and 
"chemical noise" are distinct causes of noise. A "background ion 
chromatogram" would also, I expect, refer to the sum of electronic and 
chemical noise. How would you separate them?


> Isomers forming a peak on top of the elution pattern of a background ion 
> should probably be removed.
>   
I'm not sure I understand this statement; does it refer to some data 
processing on the raw chromatogram to remove signal when it is 
co-eluting with noise?


> If this definition is maintained I think the addition to the CV that I 
> proposed still holds, but I could be wrong and more is necessary? 
> Probably single spectra (no separation up front) would suffer a bit, 
> although then we're not really talking about a chromatogram right?
>
>  name: backgroundion chromatogram
>  is_a: chromatogram type (MS:1000626)
>  definition: chromatogram created by creating an array of a ubiquitously present mass.
>   
I'm used to chromatograms referring to either a specific m/z (selected 
ion chromatogram), the total ion current, or some mass range within each 
spectrum. In the last case, the intensity within the mass range is 
summed to create a single value. Does this definition invoke the 
"specific m/z" usage by choosing an m/z known to be a source of chemical 
noise/background intensity? And if so, we're talking about a specific 
kind of selected ion chromatogram?

-Matt

Re: [Psidev-pi-dev] storing intermediate results in mzML

[David C. <dc...@ma...>]

Hi Richard,

You've posted this to the analysisXML list.
I think you should post it to:
   psi...@li...
Sorry for any confusion between the two lists.

 > Another thing, I
 > once heard somebody mention AnalysisML to be something along these
 > lines, however this project seems to have suffered a fatal end as I
 > cannot find anything?

We're still alive (I think!), but I don't think we have what you want:

http://psidev.info/index.php?q=node/319

David


Richard Scheltema wrote:
> Dear all,
> 
> I'm writing a metabolomics Java library for my processing software 
> targeted towards high resolution LC/MS data (components like: peak 
> picking, noise detection, etc). The basic element for this library is a 
> mass chromatogram (x-axis time, y-axis intensity). In order to deal with 
> the size of the datasets, enable other people to easily write 
> components, etc. an intermediate file format is required. I've already 
> defined one myself to see what would be required for a really dynamic 
> pipeline and created a library on top of it. In order to hop on the 
> international standards bandwagon I would off course like to move to a 
> recognized standard like mzML. However, this _seems_ to fall short of my 
> requirements. I've been browsing through this list and the standards 
> document and tried to implement something, but I can't seem to figure 
> out how to approach this.
> 
> What I would like to be able to do is store the following pieces of 
> information:
> 
> - Multiple runs in a single file
>  From the specification document: "A run in mzML should correspond to a 
> single, consecutive and coherent set of scans on an instrument". This 
> means that I essentially can only store data from a single raw file? I 
> would like to do mix-models (see sets).
> 
> - MassChromatograms (single mass)
> I would like to ubiquitously store mass chromatograms picked from the 
> raw data. This means that both mass chromatograms made from centroid as 
> well as profile data need to be stored. There is the option to store 
> chromatogram data, but this seems limited to '2D' data where mass 
> chromatogram data build with profile data needs '3D' data. In order to 
> solve this the accession="MS:1000627" name="selected ion current 
> chromatogram" needs sub-children? Or can it be set globally in the 
> header or run, but then I would like to be able to mix models (see sets).
> 
> - BackgroundIons
> The use of background ions are part of the pipeline. To store this an 
> addition to the CV needs to be made.
>  name: backgroundion chromatogram
>  is_a: chromatogram type (MS:1000626)
>  definition: chromatogram created by creating an array of a ubiquitously 
> present mass.
> 
> - sets
> The goal of the pipeline is to combine information from lots of 
> measurements (biological, technical replicates, different machines, etc) 
> and do perform various analysis methods. This means for example that 
> background ions or mass chromatograms from various measurements need to 
> be combined into sets. Different operations and visualizations are then 
> possible on the data stored in the files. The same as the different runs 
> applies here. Another option would be to make sets of sets, which means 
> that the relation needs to be recursive. I can probably solve some of 
> the issues with id-fields, but that would make it hard to parse for 
> other people and sort of rule out the recursive relation.
> 
> 
> I can off course solve a lot with the use of userParam tags, but then 
> other people will have a hard time reading the data. Another thing, I 
> once heard somebody mention AnalysisML to be something along these 
> lines, however this project seems to have suffered a fatal end as I 
> cannot find anything? Am I trying to use mzML outside of its boundries? 
> If so, is a viable alternative available which I have so far been unable 
> to find?
> 
> 
> Cheers,
> Richard
> 

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

dc...@ma...
http://www.matrixscience.com

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

Re: [Psidev-pi-dev] storing intermediate results in mzML

[Jones, A. <And...@li...>]

This reminds me that I noticed we have a problem with the PSI website. If you
follow the links from Groups to Proteomics Informatics on the PSI site, you get
this page: http://psidev.info/index.php?q=node/70 which is unclear what it
contains.

I don't know how you can actually browse to the main page
(http://psidev.info/index.php?q=node/319).

And even worse... if you browse via Workgroups, you get to this page:
http://psidev.info/index.php?q=node/40 

Would someone be able to fix these please? All links to Proteomics Informatics
should go here: http://psidev.info/index.php?q=node/319

thanks
Andy





> -----Original Message-----
> From: David Creasy [mailto:dc...@ma...]
> Sent: 15 December 2008 16:13
> To: Richard Scheltema
> Cc: psi...@li...
> Subject: Re: [Psidev-pi-dev] storing intermediate results in mzML
> 
> Hi Richard,
> 
> You've posted this to the analysisXML list.
> I think you should post it to:
>    psi...@li...
> Sorry for any confusion between the two lists.
> 
>  > Another thing, I
>  > once heard somebody mention AnalysisML to be something along these
>  > lines, however this project seems to have suffered a fatal end as I
>  > cannot find anything?
> 
> We're still alive (I think!), but I don't think we have what you want:
> 
> http://psidev.info/index.php?q=node/319
> 
> David
> 
> 
> Richard Scheltema wrote:
> > Dear all,
> >
> > I'm writing a metabolomics Java library for my processing software
> > targeted towards high resolution LC/MS data (components like: peak
> > picking, noise detection, etc). The basic element for this library is a
> > mass chromatogram (x-axis time, y-axis intensity). In order to deal with
> > the size of the datasets, enable other people to easily write
> > components, etc. an intermediate file format is required. I've already
> > defined one myself to see what would be required for a really dynamic
> > pipeline and created a library on top of it. In order to hop on the
> > international standards bandwagon I would off course like to move to a
> > recognized standard like mzML. However, this _seems_ to fall short of my
> > requirements. I've been browsing through this list and the standards
> > document and tried to implement something, but I can't seem to figure
> > out how to approach this.
> >
> > What I would like to be able to do is store the following pieces of
> > information:
> >
> > - Multiple runs in a single file
> >  From the specification document: "A run in mzML should correspond to a
> > single, consecutive and coherent set of scans on an instrument". This
> > means that I essentially can only store data from a single raw file? I
> > would like to do mix-models (see sets).
> >
> > - MassChromatograms (single mass)
> > I would like to ubiquitously store mass chromatograms picked from the
> > raw data. This means that both mass chromatograms made from centroid as
> > well as profile data need to be stored. There is the option to store
> > chromatogram data, but this seems limited to '2D' data where mass
> > chromatogram data build with profile data needs '3D' data. In order to
> > solve this the accession="MS:1000627" name="selected ion current
> > chromatogram" needs sub-children? Or can it be set globally in the
> > header or run, but then I would like to be able to mix models (see sets).
> >
> > - BackgroundIons
> > The use of background ions are part of the pipeline. To store this an
> > addition to the CV needs to be made.
> >  name: backgroundion chromatogram
> >  is_a: chromatogram type (MS:1000626)
> >  definition: chromatogram created by creating an array of a ubiquitously
> > present mass.
> >
> > - sets
> > The goal of the pipeline is to combine information from lots of
> > measurements (biological, technical replicates, different machines, etc)
> > and do perform various analysis methods. This means for example that
> > background ions or mass chromatograms from various measurements need to
> > be combined into sets. Different operations and visualizations are then
> > possible on the data stored in the files. The same as the different runs
> > applies here. Another option would be to make sets of sets, which means
> > that the relation needs to be recursive. I can probably solve some of
> > the issues with id-fields, but that would make it hard to parse for
> > other people and sort of rule out the recursive relation.
> >
> >
> > I can off course solve a lot with the use of userParam tags, but then
> > other people will have a hard time reading the data. Another thing, I
> > once heard somebody mention AnalysisML to be something along these
> > lines, however this project seems to have suffered a fatal end as I
> > cannot find anything? Am I trying to use mzML outside of its boundries?
> > If so, is a viable alternative available which I have so far been unable
> > to find?
> >
> >
> > Cheers,
> > Richard
> >
> 
> --
> David Creasy
> Matrix Science
> 64 Baker Street
> London W1U 7GB, UK
> Tel: +44 (0)20 7486 1050
> Fax: +44 (0)20 7224 1344
> 
> dc...@ma...
> http://www.matrixscience.com
> 
> Matrix Science Ltd. is registered in England and Wales
> Company number 3533898
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev