psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] additional feature request: precursor m/z method logging?

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

Hi Josh,

I'm not sure I like the idea of this rather subtle difference being all 
the way up at the software/processing level. Instead, what if, for 
Thermo accurate mass instruments, the filter line m/z and the 
monoisotopic trailer m/z had their own CV terms, so a precursor block 
might look like:

<precursorList count="1">
              <precursor spectrumRef="S19">
                <ionSelection>
                  <cvParam cvLabel="MS" accession="MS:1000040" 
name="m/z" value="445.34"/>
                  <cvParam cvLabel="MS" accession="MS:1000041" 
name="charge state" value="2"/>
                  <cvParam cvLabel="MS" accession="MS:1000xxx" 
name="Xcalibur scan filter line m/z" value="445.51"/>
                  <cvParam cvLabel="MS" accession="MS:1000xxx" 
name="Xcalibur monoisotopic trailer m/z" value="445.34"/>
                </ionSelection>
                <activation>
                  <cvParam cvLabel="MS" accession="MS:1000133" 
name="collision-induced dissociation" value=""/>
                  <cvParam cvLabel="MS" accession="MS:1000045" 
name="collision energy" value="35" unitAccession="MS:1000137" 
unitName="electron volt"/>
                </activation>
              </precursor>
</precursorList>

In this case, it is clear which method was used for picking the primary 
m/z value. In the case of someone writing their own precursor m/z 
picking routine, that new software would have both a generic CV term 
referencing the software in the software/processing block, and also its 
own precursor m/z CV term, like:
<cvParam cvLabel="MS" accession="MS:1000xxx" name="msPrefix m/z" 
value="445.338"/> (in addition to this value being used as the primary 
m/z value)

But it also seems to be that any or all of this information is 
relatively useless from a machine's perspective. Quantitative 
information about how accurate the m/z value is would be more helpful on 
that front, e.g.:
<cvParam cvLabel="MS" accession="MS:1000xxx" name="m/z accuracy" 
value="2" unitAccession="MS:1000xxx" unitName="ppm"/>

-Matt


Eric Deutsch wrote:
> From: Joshua Tasman 
>
> Hi all,
>
> Can we figure out a way to add a note regarding the determination of the
> precursor m/z ("parent" m/z)?  There are a few ways to do it for Thermo
> software with the Xcalibur API, at least, and I can imagine that someone
> might write their own processing routines to include in the converters.
>
> So: 1) can we clarify that the software/processing section can handle
> multiple entries for the same software (for example, "thermo API filter
> line", "thermo API trailer label value", etc.
> and 2) some way to reference this near the info at the scan level?
>
> Thanks,
>
> Josh
>
>
>   

Re: [Psidev-ms-dev] additional feature request: contiguous/noncontigous marker for m/z array data?

[Pierre-Alain B. <pie...@is...>]

Hi all,

Eric Deutsch wrote:
> From: Joshua Tasman 
>
> Hi all,
>
> There are cases where the m/z array data is contiguous (standard profile
> mode) vs noncontiguous (centroided, or thresholded profile).  Could we add
> an attribute to the binary array section (or above) describing this?  Or is
> this best left to the parsers to automatically determine?
>   
good suggestion, why not having the possibility to have one attribute
> One tricky case that might not be quickly/easily scanned for: imagine a mode
> that preserves profile data points around detected peaks; so the first large
> # of data points might appear to be the same m/z delta.  Hence, a quick
> check by the parser might not get this correct.
>   
but this tricky get less tricky if the parser considers the start and 
end m/z values of the spectrum.  It is relartively rare that a peak is 
starting to appear in a m/z scale right at the start and end of the m/z 
range. Therefore one can expect a set of empty values in these edges. 
This happens in some Waters QTOFs that do a low intensity filter in the 
profile mode exported data.

Pierre-Alain
> Thanks for considering,
>
> Josh
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

[Psidev-ms-dev] additional feature request: contiguous/noncontigous marker for m/z array data?

[Eric D. <eri...@gm...>]

From: Joshua Tasman 

Hi all,

There are cases where the m/z array data is contiguous (standard profile
mode) vs noncontiguous (centroided, or thresholded profile).  Could we add
an attribute to the binary array section (or above) describing this?  Or is
this best left to the parsers to automatically determine?

One tricky case that might not be quickly/easily scanned for: imagine a mode
that preserves profile data points around detected peaks; so the first large
# of data points might appear to be the same m/z delta.  Hence, a quick
check by the parser might not get this correct.

Thanks for considering,

Josh

[Psidev-ms-dev] additional feature request: precursor m/z method logging?

[Eric D. <eri...@gm...>]

From: Joshua Tasman 

Hi all,

Can we figure out a way to add a note regarding the determination of the
precursor m/z ("parent" m/z)?  There are a few ways to do it for Thermo
software with the Xcalibur API, at least, and I can imagine that someone
might write their own processing routines to include in the converters.

So: 1) can we clarify that the software/processing section can handle
multiple entries for the same software (for example, "thermo API filter
line", "thermo API trailer label value", etc.
and 2) some way to reference this near the info at the scan level?

Thanks,

Josh

[Psidev-ms-dev] PSI-MSSWG call minutes

[Eric D. <eri...@gm...>]

Hi everyone, here are the notes I took at today's telecon. Please let me
know if I missed anything.

 

Present: Lennart, Pierre-Alain, Darren, Eric, Matt, Josh

 

- Status of xsd, examples, and pwiz

Latest snapshot of schema 2008-03-27 is up to date.

There are new example output files from pwiz on psidev site

 

- Status of CV: encoding of datatype in CV; value type can be encoded.
Everybody likes this.

Matt: what about range? Eric: nonNegative and stuff, nothing more specific
found? Matt: nope, nothing found.

We can encode the datatypes in the CV. Someone needs to go ahead and do this
in Toledo or before

 

- mzML <-> MIAPE-MS mapping from Pierre-Alain

Quantification is out of scope

What about "Location of parameters file"? make it a cvParam URI

Getting a sample MALDI doc showing spot IDs and samples is very important

Next step: create a sample MIAPE-MS compliant document and expand CV
accordingly

Pierre-Alain will lead effort to get such a document finished in Toledo

 

- Plans for Toledo next week

95 registrants

15 min intro to the for each WG

 

- PDA examples from Jim

Forthcoming soon in Toledo or perhaps before

 

- Discussion of <chromatogramList> and Darren's suggested modification

Eric neutral on this. This was discussed before in a similar form and
discarded?

Let's stick with what we had.

Darren will implement an example this week

 

CV update

- Ping David Sparkman to redo his changes to the CV

- Josh has a few minor items to add. Will email around for possible
discussion before addition

 

- Next call

See if we can arrange during meeting, perhaps Thursday afternoon (9am PDT)

Next usual telecom 9am PDT on April 29

 

 

TODO at Toledo

--------------

 - Update CV with value types + define necessary new types.

 - Hand-write a nice MALDI example file with spots referenced e.d.

 - Create a fully MIAPE compliant example mzML file

 - CV updating

 

To dos from last time:

 

- Darren will check if the xsd and his code are in synch and make notes for
changes

- Jim has examples in his head. Will send out soon.

- Matt will come up with an example of an index for chromatograms

- Matt will run a Quantum MRM file through msconvert and report results

- Pierre-Alain will work on this and report results.

- Can we encode the xsd datatypes in the obo file? Yes, let's try.

- Lennart will explore this possibility, make an example, and report.

- Use xsd datatypes. Maybe add nonNegativeFloat, e.g.

 

 

General mentioned things yet to do:

- Lennart will need to do some work on the validator when the schema is
stable

 

 

 

 

  _____  

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Eric
Deutsch
Sent: Monday, April 14, 2008 10:11 PM
To: 'Mass spectrometry standard development'
Subject: [Psidev-ms-dev] PSI-MSSWG call in 11 hr

 

Hi everyone, this is just a reminder of our scheduled call at 9am PDT (11 hr
from now) Tuesday.

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

Agenda items:

- Status of xsd, cv, examples, and pwiz

- mzML <-> MIAPE-MS mapping from Pierre-Alain

- PDA examples from Jim

- Plans for Toledo next week

- Next call

 

Re: [Psidev-ms-dev] PSI-MSSWG call minutes

[shivram <shi...@re...>]

  Can anyone help in analysing my Q-ToF data

please do let me know so that i can send my data


Thanks in advance

Shivram, PhD Student

On Wed, 16 Apr 2008 Eric Deutsch wrote :
>Hi everyone, here are the notes I took at today's telecon. Please let me
>know if I missed anything.
>
>
>
>Present: Lennart, Pierre-Alain, Darren, Eric, Matt, Josh
>
>
>
>- Status of xsd, examples, and pwiz
>
>Latest snapshot of schema 2008-03-27 is up to date.
>
>There are new example output files from pwiz on psidev site
>
>
>
>- Status of CV: encoding of datatype in CV; value type can be encoded.
>Everybody likes this.
>
>Matt: what about range? Eric: nonNegative and stuff, nothing more
>specific found? Matt: nope, nothing found.
>
>We can encode the datatypes in the CV. Someone needs to go ahead and do
>this in Toledo or before
>
>
>
>- mzML <-> MIAPE-MS mapping from Pierre-Alain
>
>Quantification is out of scope
>
>What about "Location of parameters file"? make it a cvParam URI
>
>Getting a sample MALDI doc showing spot IDs and samples is very
>important
>
>Next step: create a sample MIAPE-MS compliant document and expand CV
>accordingly
>
>Pierre-Alain will lead effort to get such a document finished in Toledo
>
>
>
>- Plans for Toledo next week
>
>95 registrants
>
>15 min intro to the for each WG
>
>
>
>- PDA examples from Jim
>
>Forthcoming soon in Toledo or perhaps before
>
>
>
>- Discussion of <chromatogramList> and Darren's suggested modification
>
>Eric neutral on this. This was discussed before in a similar form and
>discarded?
>
>Let's stick with what we had.
>
>Darren will implement an example this week
>
>
>
>CV update
>
>- Ping David Sparkman to redo his changes to the CV
>
>- Josh has a few minor items to add. Will email around for possible
>discussion before addition
>
>
>
>- Next call
>
>See if we can arrange during meeting, perhaps Thursday afternoon (9am
>PDT)
>
>Next usual telecom 9am PDT on April 29
>
>
>
>
>
>TODO at Toledo
>
>--------------
>
>  - Update CV with value types + define necessary new types.
>
>  - Hand-write a nice MALDI example file with spots referenced e.d.
>
>  - Create a fully MIAPE compliant example mzML file
>
>  - CV updating
>
>
>
>To dos from last time:
>
>
>
>- Darren will check if the xsd and his code are in synch and make notes
>for changes
>
>- Jim has examples in his head. Will send out soon.
>
>- Matt will come up with an example of an index for chromatograms
>
>- Matt will run a Quantum MRM file through msconvert and report results
>
>- Pierre-Alain will work on this and report results.
>
>- Can we encode the xsd datatypes in the obo file? Yes, let's try.
>
>- Lennart will explore this possibility, make an example, and report.
>
>- Use xsd datatypes. Maybe add nonNegativeFloat, e.g.
>
>
>
>
>
>General mentioned things yet to do:
>
>- Lennart will need to do some work on the validator when the schema is
>stable
>
>
>
>
>
>
>
>
>
>________________________________
>
> From: psi...@li...
>[mailto:psi...@li...] On Behalf Of Eric
>Deutsch
>Sent: Monday, April 14, 2008 10:11 PM
>To: 'Mass spectrometry standard development'
>Subject: [Psidev-ms-dev] PSI-MSSWG call in 11 hr
>
>
>
>Hi everyone, this is just a reminder of our scheduled call at 9am PDT
>(11 hr from now) Tuesday.
>
>
>
>+ Germany: 08001012079
>
>+ Switzerland: 0800000860
>
>+ UK: 08081095644
>
>+ USA: 1-866-314-3683
>
>+ Generic international: +44 2083222500 (UK number)
>
>access code: 297427
>
>
>
>Agenda items:
>
>- Status of xsd, cv, examples, and pwiz
>
>- mzML <-> MIAPE-MS mapping from Pierre-Alain
>
>- PDA examples from Jim
>
>- Plans for Toledo next week
>
>- Next call
>
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>Don't miss this year's exciting event. There's still time to save $100.
>Use priority code J8TL2D2.
>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>_______________________________________________
>Psidev-ms-dev mailing list
>Psi...@li...
>https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev


RESEARCH SCHOLAR
BIRLA INSTITUTE OF SCIENTIFIC RESEARCH(BISR)
STATUE CIRCLE,JAIPUR.(INDIA)
Mobile : 91-9829077959  
LAB    : 91-41-2385283

[Psidev-ms-dev] PSI-MSSWG call minutes

[Eric D. <ede...@sy...>]

Hi everyone, here are the notes I took at today's telecon. Please let me
know if I missed anything.

 

Present: Lennart, Pierre-Alain, Darren, Eric, Matt, Josh

 

- Status of xsd, examples, and pwiz

Latest snapshot of schema 2008-03-27 is up to date.

There are new example output files from pwiz on psidev site

 

- Status of CV: encoding of datatype in CV; value type can be encoded.
Everybody likes this.

Matt: what about range? Eric: nonNegative and stuff, nothing more
specific found? Matt: nope, nothing found.

We can encode the datatypes in the CV. Someone needs to go ahead and do
this in Toledo or before

 

- mzML <-> MIAPE-MS mapping from Pierre-Alain

Quantification is out of scope

What about "Location of parameters file"? make it a cvParam URI

Getting a sample MALDI doc showing spot IDs and samples is very
important

Next step: create a sample MIAPE-MS compliant document and expand CV
accordingly

Pierre-Alain will lead effort to get such a document finished in Toledo

 

- Plans for Toledo next week

95 registrants

15 min intro to the for each WG

 

- PDA examples from Jim

Forthcoming soon in Toledo or perhaps before

 

- Discussion of <chromatogramList> and Darren's suggested modification

Eric neutral on this. This was discussed before in a similar form and
discarded?

Let's stick with what we had.

Darren will implement an example this week

 

CV update

- Ping David Sparkman to redo his changes to the CV

- Josh has a few minor items to add. Will email around for possible
discussion before addition

 

- Next call

See if we can arrange during meeting, perhaps Thursday afternoon (9am
PDT)

Next usual telecom 9am PDT on April 29

 

 

TODO at Toledo

--------------

 - Update CV with value types + define necessary new types.

 - Hand-write a nice MALDI example file with spots referenced e.d.

 - Create a fully MIAPE compliant example mzML file

 - CV updating

 

To dos from last time:

 

- Darren will check if the xsd and his code are in synch and make notes
for changes

- Jim has examples in his head. Will send out soon.

- Matt will come up with an example of an index for chromatograms

- Matt will run a Quantum MRM file through msconvert and report results

- Pierre-Alain will work on this and report results.

- Can we encode the xsd datatypes in the obo file? Yes, let's try.

- Lennart will explore this possibility, make an example, and report.

- Use xsd datatypes. Maybe add nonNegativeFloat, e.g.

 

 

General mentioned things yet to do:

- Lennart will need to do some work on the validator when the schema is
stable

 

 

 

 

________________________________

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Eric
Deutsch
Sent: Monday, April 14, 2008 10:11 PM
To: 'Mass spectrometry standard development'
Subject: [Psidev-ms-dev] PSI-MSSWG call in 11 hr

 

Hi everyone, this is just a reminder of our scheduled call at 9am PDT
(11 hr from now) Tuesday.

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

Agenda items:

- Status of xsd, cv, examples, and pwiz

- mzML <-> MIAPE-MS mapping from Pierre-Alain

- PDA examples from Jim

- Plans for Toledo next week

- Next call

 

Re: [Psidev-ms-dev] PSI-MSSWG call in 11 hr

[Eric D. <eri...@gm...>]

Hi Darren, I don't quite understand what you're proposing here. Can you
provide a pseudoxml example? Are you proposing:

<spectrumList>
  <spectrum></spectrum>
  <spectrum></spectrum>
</spectrumList>
<spectrumList>
  <chromatogram></chromatogram>
  <chromatogram></chromatogram>
</spectrumList>

which would probably mean this would be legal:

<spectrumList>
  <spectrum></spectrum>
  <spectrum></spectrum>
  <chromatogram></chromatogram>
  <chromatogram></chromatogram>
</spectrumList>

Please clarify.

thanks,
Eric



 ------------------------------

*From:* psi...@li... [mailto:
psi...@li...] *On Behalf Of *Darren Kessner
*Sent:* Tuesday, April 15, 2008 8:01 AM
*To:* Mass spectrometry standard development
*Subject:* Re: [Psidev-ms-dev] PSI-MSSWG call in 11 hr



Hi all,



I'd also like to discuss the implementation of chromatogram lists.  I had
mentioned this in a message a little while back, but there wasn't any
response.  Here's the text of the message:



Since Matt's <chromatogramList> looks almost like <spectrumList>, does

it make sense to just reuse/generalize and allow multiple <spectrumList>

elements?



I think this has been discussed earlier, but it's on my mind since I was

thinking about the parsing of <chromatogramList>.



The advantages to generalization are:

1) easier writing and maintenance of schema

2) much less error-prone coding and maintenance of parsers/writers

3) automatically handles stuff like a list of UV spectra, or whatever

new technology is used inline with mass spec in the future



Now that I'm thinking about it again, another advantage is the
generalization/reuse of the <index> to handle multiple <spectrumList>
elements.





Darren







On Apr 14, 2008, at 10:11 PM, Eric Deutsch wrote:



 Hi everyone, this is just a reminder of our scheduled call at 9am PDT (11
hr from now) Tuesday.



+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427



Agenda items:

- Status of xsd, cv, examples, and pwiz

- mzML <-> MIAPE-MS mapping from Pierre-Alain

- PDA examples from Jim

- Plans for Toledo next week

- Next call



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI-MSSWG call in 11 hr

[Darren K. <Dar...@cs...>]

Hi all,

I'd also like to discuss the implementation of chromatogram lists.  I  
had mentioned this in a message a little while back, but there wasn't  
any response.  Here's the text of the message:

Since Matt's <chromatogramList> looks almost like <spectrumList>, does
it make sense to just reuse/generalize and allow multiple <spectrumList>
elements?

I think this has been discussed earlier, but it's on my mind since I was
thinking about the parsing of <chromatogramList>.

The advantages to generalization are:
1) easier writing and maintenance of schema
2) much less error-prone coding and maintenance of parsers/writers
3) automatically handles stuff like a list of UV spectra, or whatever
new technology is used inline with mass spec in the future

Now that I'm thinking about it again, another advantage is the  
generalization/reuse of the <index> to handle multiple <spectrumList>  
elements.


Darren



On Apr 14, 2008, at 10:11 PM, Eric Deutsch wrote:

> Hi everyone, this is just a reminder of our scheduled call at 9am  
> PDT (11 hr from now) Tuesday.
>
> + Germany: 08001012079
> + Switzerland: 0800000860
> + UK: 08081095644
> + USA: 1-866-314-3683
> + Generic international: +44 2083222500 (UK number)
> access code: 297427
>
> Agenda items:
> - Status of xsd, cv, examples, and pwiz
> - mzML <-> MIAPE-MS mapping from Pierre-Alain
> - PDA examples from Jim
> - Plans for Toledo next week
> - Next call
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] PSI-MSSWG call in 11 hr

[Eric D. <eri...@gm...>]

Hi everyone, this is just a reminder of our scheduled call at 9am PDT (11 hr
from now) Tuesday.

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

Agenda items:

- Status of xsd, cv, examples, and pwiz

- mzML <-> MIAPE-MS mapping from Pierre-Alain

- PDA examples from Jim

- Plans for Toledo next week

- Next call

 

Re: [Psidev-ms-dev] Getting standard formats from Shimadzu

[Simon A. <sim...@bb...>]

David,

Thanks for your reply.  Distiller does look like it might be a viable  
option for what we're trying to do.  I'll get back to the research  
group and see if they've got it, or are willing to purchase it.

Many thanks

Simon.

On 1 Apr 2008, at 14:42, David Creasy wrote:
> Simon,
>
> One option for this format is Mascot Distiller:
>
> http://www.matrixscience.com/distiller.html
>
> I believe that most LC MS IT-TOF systems ship with Mascot Distiller.
> There's also a Distiller developer kit available that you can use for
> your custom s/w if you need it. If you are interested, send me a  
> message
> offline.
>
> David
> dc...@ma...
>
> Simon Andrews wrote:
>> I'm working with a group who have a Shimadzu LC MS IT-TOF system who
>> would like me to write some custom analysis software for them.
>> However the data from the machine is stored in LC Data Files (.lcd),
>> which appear to be an undocumented binary format.
>>
>> Is anyone aware of a source of documentation for this format, or any
>> tools to convert it to one of the standard open formats for MS data?
>> They have the LCMSolution software package, but that didn't appear to
>> have any option to save in a non-native format.
>>
>> Any help is much appreciated.
>>
>> --------------------------------------------------------------------- 
>> ----
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ 
>> marketplace
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ 
> marketplace
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Chromatogram proposal (at least for SRM/MRMfiles)

[Kessner, D. E. <Dar...@cs...>]

Since Matt's <chromatogramList> looks almost like <spectrumList>, does
it make sense to just reuse/generalize and allow multiple <spectrumList>
elements?

I think this has been discussed earlier, but it's on my mind since I was
thinking about the parsing of <chromatogramList>.

The advantages to generalization are:
1) easier writing and maintenance of schema
2) much less error-prone coding and maintenance of parsers/writers
3) automatically handles stuff like a list of UV spectra, or whatever
new technology is used inline with mass spec in the future


Darren




IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] Getting standard formats from Shimadzu

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

Simon,

One option for this format is Mascot Distiller:

http://www.matrixscience.com/distiller.html

I believe that most LC MS IT-TOF systems ship with Mascot Distiller.
There's also a Distiller developer kit available that you can use for 
your custom s/w if you need it. If you are interested, send me a message 
offline.

David
dc...@ma...

Simon Andrews wrote:
> I'm working with a group who have a Shimadzu LC MS IT-TOF system who  
> would like me to write some custom analysis software for them.   
> However the data from the machine is stored in LC Data Files (.lcd),  
> which appear to be an undocumented binary format.
> 
> Is anyone aware of a source of documentation for this format, or any  
> tools to convert it to one of the standard open formats for MS data?   
> They have the LCMSolution software package, but that didn't appear to  
> have any option to save in a non-native format.
> 
> Any help is much appreciated.
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Getting standard formats from Shimadzu

[Simon A. <sim...@bb...>]

I'm working with a group who have a Shimadzu LC MS IT-TOF system who  
would like me to write some custom analysis software for them.   
However the data from the machine is stored in LC Data Files (.lcd),  
which appear to be an undocumented binary format.

Is anyone aware of a source of documentation for this format, or any  
tools to convert it to one of the standard open formats for MS data?   
They have the LCMSolution software package, but that didn't appear to  
have any option to save in a non-native format.

Any help is much appreciated.

[Psidev-ms-dev] 26 days until the PSI Spring Meeting in Toledo, Registration is open

[Juan P. A. <jp...@pr...>]

Dear Friends,

Sorry if you have already registered and you get multiple posts.

The HUPO-PSI Spring Meeting 2008 is almost here, register now!

             (DEADLINE FOR REGISTRATION APRIL, 1ST)

Come and join us April 23-25th, 2008, at  Hotel Beatriz in
Toledo, Spain for the 2008 Spring Meeting of the HUPO
Proteomics Standards Initiative.

A unique opportunity to participate in the development of current
standards in Proteomics.

The PSI working groups are targeting to discuss and deliver a number of
standards, including (not exhaustively)
- Adaptation of MI XML format to new data types
- PSICQUIC definition
- mzML stable format (merging mzData and mzXML)
- Controlled Vocabularies for a number of PSI modules and the PSI Beta
Validator framework presentation,
- MIAPE documentation for still remaining modules
- and much more



Detailed information and registration form can be found at
http://www.psidev.info/index.php?q=node/305


Looking forward to seeing you in Toledo,


  From the meeting organization committee and the PSI Steering Group

Juan Pablo Albar


-- 
Dr. Juan Pablo Albar
ProteoRed, Coordinator
Centro Nacional de Biotecnología/CSIC
UAM Campus Cantoblanco
Darwin, 3
Madrid E-28049 Spain

http://www.proteored.org/
Telf  (+34) 91585-4668
Fax  (+34) 91585-4506

Re: [Psidev-ms-dev] xsd changes

[Fredrik L. <Fre...@im...>]

Hi Lennart,

It looks very good, chromatograms are very welcome for SRMs and SIMs etc.
As Matt writes, this brings up the question about ids again. I'd vote 
for making all ids (except the mzML id) data type xs:ID, even if this 
means that they have to be unique within the file (and that they cannot 
contain spaces etc), but it is very good for validation of uniqueness. 
References that are always within the file should be of type xs:IDREF to 
make sure that the referenced item exist by simple xsd validation. Or is 
there a good reason for permitting a chromatogram to have the same id as 
a spectrum or something else?

Fredrik

Re: [Psidev-ms-dev] xsd changes

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

Hi Lennart, thanks for adding chromatograms. I am going to work 
immediately on using them to speed up viewing of MRM data! :)  I will 
note that I didn't intend the "id" attribute of the chromatogram element 
to /necessarily/ imply the type of chromatogram, I just happened to use 
it like that for my example. Like SpectrumType's id attribute, it is a 
free string that can be something silly like "foobar" as long as it's 
unique to the file (we should decide whether that means unique to the 
chromatogramList or unique to both chromatogramList and spectrumList). I 
think the ChromatogramType element should be like the SpectrumType 
element: it should have an immediate child cvParam describing its type. 
I apologize for not making that clear in my example. The other changes I 
of course agree with. Also, since the chromatogram index proposal is 
quite trivial, I'll just attach it here.

<index name="spectrum">
    <offset ...>...</offset>
    <offset ...>...</offset>
    <offset ...>...</offset>
</index>
<index name="chromatogram">
    <offset ...>...</offset>
    <offset ...>...</offset>
    <offset ...>...</offset>
</index>

Simple enough. :) Doesn't even require changes to the schema, except 
that currently the spectrum element and its corresponding offsets 
REQUIRE the nativeID attribute. How does that work with conversions from 
formats without that information (e.g. DTA, current mzXML, mzData, 
etc.)? Obviously the chromatograms won't have a nativeID, so their 
offsets won't have a nativeID either.

-Matt


Lennart Martens wrote:
> Dear PSI-MS Enthousiasts,
>
>
> Darren has provided some updates to the XSD (based on the original mzML 
> 0.99.1, so I manually diff'ed them into the latest snapshot), and Matt 
> has suggested a nice schema addition for chromatograms.
>
> This new snapshot has all of that.
>
> Files (all relevant info is in the changelog text file):
>
> http://www.ebi.ac.uk/~lmartens/mzML/20080327_changelog.txt
>
> http://www.ebi.ac.uk/~lmartens/mzML/20080327_mzML0.99.9_idx_SNAPSHOT.xsd
>
> http://www.ebi.ac.uk/~lmartens/mzML/20080327_mzML0.99.9_SNAPSHOT.xsd
>
> http://www.ebi.ac.uk/~lmartens/mzML/20080327_tiny.msdata.mzML
>
> http://www.ebi.ac.uk/~lmartens/mzML/20080327_tiny.msdata.with.chromatograms.mzML
>
>
> Have fun.
>
> Cheers,
>
> lnnrt.
>
>   

[Psidev-ms-dev] xsd changes

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthousiasts,


Darren has provided some updates to the XSD (based on the original mzML 
0.99.1, so I manually diff'ed them into the latest snapshot), and Matt 
has suggested a nice schema addition for chromatograms.

This new snapshot has all of that.

Files (all relevant info is in the changelog text file):

http://www.ebi.ac.uk/~lmartens/mzML/20080327_changelog.txt

http://www.ebi.ac.uk/~lmartens/mzML/20080327_mzML0.99.9_idx_SNAPSHOT.xsd

http://www.ebi.ac.uk/~lmartens/mzML/20080327_mzML0.99.9_SNAPSHOT.xsd

http://www.ebi.ac.uk/~lmartens/mzML/20080327_tiny.msdata.mzML

http://www.ebi.ac.uk/~lmartens/mzML/20080327_tiny.msdata.with.chromatograms.mzML


Have fun.

Cheers,

lnnrt.

[Psidev-ms-dev] Annotating the CVParam 'value' attribute content in the OBO file of the CV

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthousiasts,


I have had some help from Richard Cote (who developed the Ontology 
Lookup Service and therefore knows about these things) with regards to 
our plan to encode the allowed value type for a CV Param in the PSI-MS 
CV, along with the term.

Apparently (and perhaps not surprisingly), we're not the first to think 
of this :). A nice precedent has been set by the PSI-MOD (Ontology for 
protein modifications). An example is given below:

[Term]
id: MOD:00002
name: O-glycosyl-L-serine
def: "a protein modification that effectively forms an 
O3-glycosylserine" [PSI-MOD:ref]
exact_synonym: "O-glycosylserine" []
exact_synonym: "OGlycoSer" [PSI-MOD:unique short name]
xref_analog: DiffAvg: "146.14"
xref_analog: DiffFormula: "C 6 H 10 N 0 O 4"
xref_analog: DiffMono: "146.057909"
xref_analog: Formula: "C 9 H 15 N 1 O 6"
xref_analog: MassAvg: "233.22"
xref_analog: MassMono: "233.089937"
xref_analog: Origin: "S"
xref_analog: Source: "Natural"
xref_analog: TermSpec:"none"
is_a: MOD:00396 ! O-glycosylated residue
is_a: MOD:00916 ! modified L-serine residue


As you can see, the 'xref_analog' fields are used to encode a variety of 
'annotations' (which is incidentally the way the OLS has been rigged to 
interpret them).

So essentially, the 'xref_analog' stuff for PSI-MS can become something 
like this:

xref_analog: value-type:xsd\:int "The allowed value-type for this CV term."

Note the escaped ':' between xsd and int (OBO uses ':' as an internal 
separator, so it escapes them in values and such).

This mechanism also works beautifully with OBO-Edit (the premier 
graphical OBO file format editing tool), as these 'xref_analog' fields 
are Dbxrefs in the interface, in our example case with database name 
'value-type' and database id 'xsd:int', and comment 'The allowed 
value-type for this CV term.'.

So we can reliably use this proven mechanism. Another potentially nice 
thing is that one term can have many 'xref_analog' fields, so we can 
potentially permit more than one data type (if we would ever want to do 
that).



Cheers,

lnnrt.

[Psidev-ms-dev] PSI-MSSWG call minutes

[Eric D. <eri...@gm...>]

Hi everyone, here are the notes I took today at the call. Thanks for
participating.

 

Present: Lennart, Darren, Matt, Josh, Eric, Parag

 

  _____  

From: Eric Deutsch 
Sent: Monday, March 24, 2008 11:49 PM
To: 'Mass spectrometry standard development'
Subject: PSI-MSSWG call in 9 hr

 

Hi everyone, the call is coming up in 9 hr.

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

During the call, let's discuss:

- synching Darren's code and the xsd and example files and validator to
current state

 

Lennart will need to do some work on the validator when the schema is stable

Darren will check if the xsd and his code are in synch and makes notes for 

 

- Various todo's:

 o JimS will provide some PDA spectrum examples

 

Jim has examples in his head. Will send out soon.

 

 o Matt will send <chromatogram> example

 

Everyone liked the format example.

Suggested policy: individual scans always required. Full TIC is recommended.
The individual SRM SICs recommended. Individual SRM TICs optional but
supported.

Put <chromatogramList> after <spectrumList> (so that writers can write in
one pass)

<chromatogram>s will be indexed.

Matt will come up with an example of an index for chromatograms

Matt will run a Quantum MRM file through msconvert and report results

 

 o Pierre-Alain will finish mzML <--> MIAPE mapping/checking

 

Pierre-Alain will work on this and report results.

 

- Figure out cvParam datatype validation plan

 

Can we encode the xsd datatypes in the obo file? Yes, let's try.

Lennart will explore this possibility, make an example, and report.

Use xsd datatypes. Maybe add nonNegativeFloat, e.g.

 

- Runup to Toledo meeting

 

Next call on April 15, 9am PDT due to schedule conflicts on Apr 8.

 

- Address cvParam category name issue, as described in spec doc. Do we want:

A) <cvParam cvRef="MS" accession="MS:1000583" name="SRM spectrum"/>

C) <cvParam cvRef="MS" accession="MS:1000583" name="SRM spectrum"
categoryAccession="MS:1000035"/>

 (where MS:1000035="spectrum type")

The category accession is not needed or used under normal circumstances by
Darren's reader and presumably most readers. But it could be useful in cases
where a term not known to the reader is used. Under scenario A, if the
reader software predates MS:1000583, the reader will be very hard pressed to
know what to do with this term. In theory, under the same scenario with
option C, the reader could more easily determine what to do with this piece
of information even though the exact term is unknown. Maybe "cannot
determine spectrum type" should be a terminal error, while "unrecognized
spectrum type" might merely be a warning. Darren and I discussed for a while
at US HUPO. Let's see if we can come to a decision.

 

Spectrum type is not a good example. Instrument model is a much better
example. But even in the face of that, the general consensus is to stick
with A. There is quite some dissatisfaction with adding categoryAccession
and the consensus of people writing reader software is that it is not
necessary.

 

Thanks!

Eric

 

 

 

 

  _____  

From: Eric Deutsch 
Sent: Tuesday, March 04, 2008 10:26 AM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: RE: PSI-MSSWG call in 8 hr

 

Hi everyone, here are my notes from the telecon. Thank you for your
participation. Please let me know if I forgot/misunderstood anything:

 

Meeting minutes 2008-03-04 9:00am PST

 

Present: Darren, Jim, Matt, Lennart, Josh, Eric

 

- Eric's most recent nativeID proposal is accepted except for the format of
the value, which should be:

  nativeID="19"

  nativeID="2,6,5"

  nativeID="run1,3,4"

  nativeID="&quot;run1,2&quot;,3,4"

 

- possible charge state suggestion is fine with folks:

  - 0-1 "charge state"

  XOR

  - 2-N "possible charge state"

 

- Come up with an example of how we want summed spectra to look:

- one file that includes original scan and a summed spectrum

 

- in old mzXML, we can have different start_scan and end_scan. How do we
encode that?

 

- defaultArrayLength proposal is fine

 

- Jim has some examples of files with PDA data

  He will come up some examples of this

  Perhaps encoded as the MS spectrum as usual <spectrum index="27"
nativeID="19"> and then another

  <spectrum index="28" nativeID="PDA19"> with a spectrum type "PDA spectrum"

 

- Jim will also come up MALDI data examples for us

 

- agreed that we rename selectionWindow to scanWindow as this is a misnomer

- add optionally to <ionSelection>, all 2 new cvParams "selection window m/z
lower limit"

  and "selection window m/z upper limit" for the *true* fragmentation
selection window start and stop

 

- agreed change acqNumber to acquisitionNumber

 

- What to do with msLevel?

  agreed make it a cvParam next to spectrum type instead of a attribute of
<spectrum>

  because for example a PDA spectrum will have no msLevel

 

- state that index should be for seeking rather than cataloguing.

  So no msLevel in the index

  Index should be *complete* so it could be used for a list of items to seek
to

  but should contain only identifiers, not attributes/metadata

  - Start a thread on this to discuss more

 

- Matt will send <chromatogram> example since he is working on these now

 

- Next meeting indeed March 25 as on schedule.  This is *3* weeks from now,
because of US HUPO

- Maybe a few of us could meet and chat at US HUPO although unlikely
anything official.

 

 

 

 

 

  _____  

From: Eric Deutsch 
Sent: Tuesday, March 04, 2008 1:08 AM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: PSI-MSSWG call in 8 hr

 

Hi everyone, here is a reminder of the call coming up in 8 hr. Dial-in
information is:

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to discuss all the items that have come up recently. I
list them as:

 

- Latest nativeScanReference proposal

- using defaultArrayLength attribute in <spectrum> but allow override in
binaryDataArray

- Allow new "possible charge state" term in <ionSelection> multiple times

- Frederick suggestion that selectionWindow should really be scanWindow.
selectionWindow is something different, and by the way, where is it, we
really need that, too.

- MS^E example

- msLevel

- chromatograms

 

The schedule is still:

 

Schedule:

-----------------------

Jan 25: mzML reviews returned. Official community review complete.

Feb  5: mzML telecon 9:00am PST

Feb 19: mzML telecon 9:00am PST

Mar  4: mzML telecon 9:00am PST

Mar 17: US HUPO meeting 

Mar 25: mzML telecon 9:00am PST

Apr  8: mzML telecon 9:00am PST

Apr 23: PSI meeting in Toledo

May

Jun 1-5: ASMS - Must be done and advertising it here!

 

 

 

 

 

Re: [Psidev-ms-dev] PSI-MSSWG call in 9 hr

[Angel P. <an...@ma...>]

On Tue, Mar 25, 2008 at 2:49 AM, Eric Deutsch <ede...@sy...>
wrote:

>
> - Address cvParam category name issue, as described in spec doc. Do we
> want:
>
> A) <cvParam cvRef="MS" accession="MS:1000583" name="SRM spectrum"/>
>
> C) <cvParam cvRef="MS" accession="MS:1000583" name="SRM spectrum"
> categoryAccession="MS:1000035"/>
>
>  (where MS:1000035="spectrum type")
>
> The category accession is not needed or used under normal circumstances by
> Darren's reader and presumably most readers. But it could be useful in cases
> where a term not known to the reader is used. Under scenario A, if the
> reader software predates MS:1000583, the reader will be very hard pressed to
> know what to do with this term. In theory, under the same scenario with
> option C, the reader could more easily determine what to do with this piece
> of information even though the exact term is unknown. Maybe "cannot
> determine spectrum type" should be a terminal error, while "unrecognized
> spectrum type" might merely be a warning. Darren and I discussed for a while
> at US HUPO. Let's see if we can come to a decision.
>
> Can't attend the call, but I really can't keep quiet about this.
categoryAccession, or any other method of scoping terms (or essentially
defining new terms) within xml instances that do not live within the
referenced CV itslef is a *bad* idea. Here's the thing about cvRef, you can
use more than one source wihtin an XML instance. Here is the thing about
CV's and ontologies, they can reference and inherit from each other.

So option (D) is born:


D) <cvParam cvRef="MyMS" accession="ME:0000501" name="SRM spectrum"/>

and within the MyMS CV, we would have  ME:000501 IS_A MS:1000035

And the world is at peace and one with itself. Or at least that is the way
is should be.

Re: [Psidev-ms-dev] Chromatogram proposal (at least for SRM/MRM files)

[Randy J. <rkj...@in...>]

All,

I could not agree more with Matt's comments.  In practice we have seen
there is a huge benefit to storing MRM data as chromatograms rather than
spectra.  The main problem with spectra is that there is no consistency
in how the x-axis is defined between vendors today.  Some create an
array with one peak at each transition (which is not an m/z axis at
all), and some create a single data pair with loads of redundant header
information.

I haven't checked the example in detail except to see that is looks
sane.

I won't be able to be on the call today, but I really like what Matt has
done.

Randy

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Tuesday, March 25, 2008 11:11 AM
To: Mass spectrometry standard development
Subject: [Psidev-ms-dev] Chromatogram proposal (at least for SRM/MRM
files)

Hi all,

To reiterate, I really want to see chromatograms supported in mzML 
because otherwise it will be impossible to get instant/random access to 
the most useful SRM/MRM views without first coming up with a proprietary

format to cache them.

I'll just get something out there to look at before the conference call.

I haven't gotten it done until now because I'm not decided whether 
SRM/MRM-derived chromatograms (total ion chromatograms and 
selected/extracted ion chromatograms) should be treated differently than

other scan modes' TICs and SICs. I think that they might be treated 
(termed) differently because a SRM/MRM-derived chromatogram has some 
slightly different markup that should always go with it (i.e. the 
transition precursor m/z and for SICs, the product m/z as well).

The example I've come up with here is based on the SRM/MRM tiny example.

If there is only a single transition in the run (one precursor m/z and 
one product m/z) then I propose 3 chromatograms: a TIC for the entire 
run, a TIC for the precursor m/z (which is also a SIC, argh!), and a SIC

for the product m/z. In other words, the entire run has a TIC, every 
precursor m/z in a SRM/MRM run has a TIC, and every transition 
(precursor m/z paired with a product m/z) has a SIC.

I propose this format for storing SRM/MRM files despite the fact that 
some vendors proprietary formats seem to store them as individual scans.

At US HUPO I talked with Darren about how Thermo's Qual Browser gets 
such quick views of the SRM/MRM chromatograms (especially the TIC) when 
if only the scans are present, it would have to iterate through 50000 or

more scans (typical of an SRM/MRM file) to build that view. I came to 
the conclusion that Thermo's RAW files probably store the TIC of the 
entire run for quick access instead of rebuilding it. I'm less certain 
about whether this is true for the individual transitions (because there

is some delay when selecting a view of a precursor TIC or transition 
SIC), but regardless I think it makes much more sense to store these 
data as chromatograms instead of (or even in addition to) scans. This is

even more true in the XML world where markup on each tiny SRM/MRM 
spectrum will be very expensive.

I envision something like:

<run id="msRun01" instrumentRef="TSQ Quantum" sampleRef="1"
startTimeStamp="2007-06-27T15:23:45.00035">
	<sourceFileRefList count="1">
		<sourceFileRef ref="1"/>
	</sourceFileRefList>

	<chromatogramList count="3">
		<chromatogram id="TIC" index="1" arrayLength="2">
			<cvParam cvLabel="MS" accession="MS:1000xxx"
name="total ion chromatogram" value=""/>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS"
accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000xxx" name="time array" value=""/>
	
<binary>HereAreTheScanTimesForEachSpectrum</binary>
			</binaryDataArray>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS"
accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000515" name="intensity array" value=""/>
	
<binary>HereAreTheTotalIntensitiesForEachSpectrum</binary>
			</binaryDataArray> 
		</chromatogram>
		<chromatogram id="Transition TIC: 567.8" index="2"
arrayLength="2">
			<cvParam cvLabel="MS" accession="MS:1000xxx"
name="SRM total ion chromatogram" value=""/>
			<cvParam cvLabel="MS" accession="MS:1000xxx"
name="SRM precursor m/z" value="567.8"/>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS"
accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000xxx" name="time array" value=""/>
	
<binary>HereAreTheScanTimesForEachSpectrumForThisPrecursor</binary>
			</binaryDataArray>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS"
accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000515" name="intensity array" value=""/>
	
<binary>HereAreTheTotalIntensitiesForEachSpectrumForThisPrecursor</binar
y>
			</binaryDataArray> 
		</chromatogram>
		<chromatogram id="Transition SIC: 567.8 -> 456.7"
index="3" arrayLength="2">
			<cvParam cvLabel="MS" accession="MS:1000xxx"
name="SRM selected ion chromatogram" value=""/>
			<cvParam cvLabel="MS" accession="MS:1000xxx"
name="SRM precursor m/z" value="567.8"/>
			<cvParam cvLabel="MS" accession="MS:1000xxx"
name="SRM product m/z" value="456.7"/>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS"
accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000xxx" name="time array" value=""/>
	
<binary>HereAreTheScanTimesForEachSpectrumForThisTransition</binary>
			</binaryDataArray>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS"
accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS"
accession="MS:1000515" name="intensity array" value=""/>
	
<binary>HereAreTheTotalIntensitiesForEachSpectrumForThisTransition</bina
ry>
			</binaryDataArray> 
		</chromatogram>
	</chromatogramList>

	<spectrumList count="2">
		<!-- ... -->
	</spectrumList>
</run>


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Chromatogram proposal (at least for SRM/MRM files)

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

Hi all,

To reiterate, I really want to see chromatograms supported in mzML 
because otherwise it will be impossible to get instant/random access to 
the most useful SRM/MRM views without first coming up with a proprietary 
format to cache them.

I'll just get something out there to look at before the conference call. 
I haven't gotten it done until now because I'm not decided whether 
SRM/MRM-derived chromatograms (total ion chromatograms and 
selected/extracted ion chromatograms) should be treated differently than 
other scan modes' TICs and SICs. I think that they might be treated 
(termed) differently because a SRM/MRM-derived chromatogram has some 
slightly different markup that should always go with it (i.e. the 
transition precursor m/z and for SICs, the product m/z as well).

The example I've come up with here is based on the SRM/MRM tiny example. 
If there is only a single transition in the run (one precursor m/z and 
one product m/z) then I propose 3 chromatograms: a TIC for the entire 
run, a TIC for the precursor m/z (which is also a SIC, argh!), and a SIC 
for the product m/z. In other words, the entire run has a TIC, every 
precursor m/z in a SRM/MRM run has a TIC, and every transition 
(precursor m/z paired with a product m/z) has a SIC.

I propose this format for storing SRM/MRM files despite the fact that 
some vendors proprietary formats seem to store them as individual scans. 
At US HUPO I talked with Darren about how Thermo's Qual Browser gets 
such quick views of the SRM/MRM chromatograms (especially the TIC) when 
if only the scans are present, it would have to iterate through 50000 or 
more scans (typical of an SRM/MRM file) to build that view. I came to 
the conclusion that Thermo's RAW files probably store the TIC of the 
entire run for quick access instead of rebuilding it. I'm less certain 
about whether this is true for the individual transitions (because there 
is some delay when selecting a view of a precursor TIC or transition 
SIC), but regardless I think it makes much more sense to store these 
data as chromatograms instead of (or even in addition to) scans. This is 
even more true in the XML world where markup on each tiny SRM/MRM 
spectrum will be very expensive.

I envision something like:

<run id="msRun01" instrumentRef="TSQ Quantum" sampleRef="1" startTimeStamp="2007-06-27T15:23:45.00035">
	<sourceFileRefList count="1">
		<sourceFileRef ref="1"/>
	</sourceFileRefList>

	<chromatogramList count="3">
		<chromatogram id="TIC" index="1" arrayLength="2">
			<cvParam cvLabel="MS" accession="MS:1000xxx" name="total ion chromatogram" value=""/>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS" accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000xxx" name="time array" value=""/>
				<binary>HereAreTheScanTimesForEachSpectrum</binary>
			</binaryDataArray>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS" accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000515" name="intensity array" value=""/>
				<binary>HereAreTheTotalIntensitiesForEachSpectrum</binary>
			</binaryDataArray> 
		</chromatogram>
		<chromatogram id="Transition TIC: 567.8" index="2" arrayLength="2">
			<cvParam cvLabel="MS" accession="MS:1000xxx" name="SRM total ion chromatogram" value=""/>
			<cvParam cvLabel="MS" accession="MS:1000xxx" name="SRM precursor m/z" value="567.8"/>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS" accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000xxx" name="time array" value=""/>
				<binary>HereAreTheScanTimesForEachSpectrumForThisPrecursor</binary>
			</binaryDataArray>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS" accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000515" name="intensity array" value=""/>
				<binary>HereAreTheTotalIntensitiesForEachSpectrumForThisPrecursor</binary>
			</binaryDataArray> 
		</chromatogram>
		<chromatogram id="Transition SIC: 567.8 -> 456.7" index="3" arrayLength="2">
			<cvParam cvLabel="MS" accession="MS:1000xxx" name="SRM selected ion chromatogram" value=""/>
			<cvParam cvLabel="MS" accession="MS:1000xxx" name="SRM precursor m/z" value="567.8"/>
			<cvParam cvLabel="MS" accession="MS:1000xxx" name="SRM product m/z" value="456.7"/>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS" accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000xxx" name="time array" value=""/>
				<binary>HereAreTheScanTimesForEachSpectrumForThisTransition</binary>
			</binaryDataArray>
			<binaryDataArray encodedLength="123">
				<cvParam cvLabel="MS" accession="MS:1000523" name="32-bit float" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000576" name="no compression" value=""/>
				<cvParam cvLabel="MS" accession="MS:1000515" name="intensity array" value=""/>
				<binary>HereAreTheTotalIntensitiesForEachSpectrumForThisTransition</binary>
			</binaryDataArray> 
		</chromatogram>
	</chromatogramList>

	<spectrumList count="2">
		<!-- ... -->
	</spectrumList>
</run>

[Psidev-ms-dev] PSI-MSSWG call in 9 hr

[Eric D. <ede...@sy...>]

Hi everyone, the call is coming up in 9 hr.

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

During the call, let's discuss:

- synching Darren's code and the xsd and example files and validator to
current state

- Various todo's:

 o JimS will provide some PDA spectrum examples

 o Matt will send <chromatogram> example

 o Pierre-Alain will finish mzML <--> MIAPE mapping/checking

- Figure out cvParam datatype validation plan

- Runup to Toledo meeting

- Address cvParam category name issue, as described in spec doc. Do we
want:

A) <cvParam cvRef="MS" accession="MS:1000583" name="SRM spectrum"/>

C) <cvParam cvRef="MS" accession="MS:1000583" name="SRM spectrum"
categoryAccession="MS:1000035"/>

 (where MS:1000035="spectrum type")

The category accession is not needed or used under normal circumstances
by Darren's reader and presumably most readers. But it could be useful
in cases where a term not known to the reader is used. Under scenario A,
if the reader software predates MS:1000583, the reader will be very hard
pressed to know what to do with this term. In theory, under the same
scenario with option C, the reader could more easily determine what to
do with this piece of information even though the exact term is unknown.
Maybe "cannot determine spectrum type" should be a terminal error, while
"unrecognized spectrum type" might merely be a warning. Darren and I
discussed for a while at US HUPO. Let's see if we can come to a
decision.

 

Thanks!

Eric

 

 

 

 

________________________________

From: Eric Deutsch 
Sent: Tuesday, March 04, 2008 10:26 AM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: RE: PSI-MSSWG call in 8 hr

 

Hi everyone, here are my notes from the telecon. Thank you for your
participation. Please let me know if I forgot/misunderstood anything:

 

Meeting minutes 2008-03-04 9:00am PST

 

Present: Darren, Jim, Matt, Lennart, Josh, Eric

 

- Eric's most recent nativeID proposal is accepted except for the format
of the value, which should be:

  nativeID="19"

  nativeID="2,6,5"

  nativeID="run1,3,4"

  nativeID="&quot;run1,2&quot;,3,4"

 

- possible charge state suggestion is fine with folks:

  - 0-1 "charge state"

  XOR

  - 2-N "possible charge state"

 

- Come up with an example of how we want summed spectra to look:

- one file that includes original scan and a summed spectrum

 

- in old mzXML, we can have different start_scan and end_scan. How do we
encode that?

 

- defaultArrayLength proposal is fine

 

- Jim has some examples of files with PDA data

  He will come up some examples of this

  Perhaps encoded as the MS spectrum as usual <spectrum index="27"
nativeID="19"> and then another

  <spectrum index="28" nativeID="PDA19"> with a spectrum type "PDA
spectrum"

 

- Jim will also come up MALDI data examples for us

 

- agreed that we rename selectionWindow to scanWindow as this is a
misnomer

- add optionally to <ionSelection>, all 2 new cvParams "selection window
m/z lower limit"

  and "selection window m/z upper limit" for the *true* fragmentation
selection window start and stop

 

- agreed change acqNumber to acquisitionNumber

 

- What to do with msLevel?

  agreed make it a cvParam next to spectrum type instead of a attribute
of <spectrum>

  because for example a PDA spectrum will have no msLevel

 

- state that index should be for seeking rather than cataloguing.

  So no msLevel in the index

  Index should be *complete* so it could be used for a list of items to
seek to

  but should contain only identifiers, not attributes/metadata

  - Start a thread on this to discuss more

 

- Matt will send <chromatogram> example since he is working on these now

 

- Next meeting indeed March 25 as on schedule.  This is *3* weeks from
now, because of US HUPO

- Maybe a few of us could meet and chat at US HUPO although unlikely
anything official.

 

 

 

 

 

________________________________

From: Eric Deutsch 
Sent: Tuesday, March 04, 2008 1:08 AM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: PSI-MSSWG call in 8 hr

 

Hi everyone, here is a reminder of the call coming up in 8 hr. Dial-in
information is:

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to discuss all the items that have come up recently.
I list them as:

 

- Latest nativeScanReference proposal

- using defaultArrayLength attribute in <spectrum> but allow override in
binaryDataArray

- Allow new "possible charge state" term in <ionSelection> multiple
times

- Frederick suggestion that selectionWindow should really be scanWindow.
selectionWindow is something different, and by the way, where is it, we
really need that, too.

- MS^E example

- msLevel

- chromatograms

 

The schedule is still:

 

Schedule:

-----------------------

Jan 25: mzML reviews returned. Official community review complete.

Feb  5: mzML telecon 9:00am PST

Feb 19: mzML telecon 9:00am PST

Mar  4: mzML telecon 9:00am PST

Mar 17: US HUPO meeting 

Mar 25: mzML telecon 9:00am PST

Apr  8: mzML telecon 9:00am PST

Apr 23: PSI meeting in Toledo

May

Jun 1-5: ASMS - Must be done and advertising it here!

 

 

 

 

 

[Psidev-ms-dev] InsilicosViewer with mzML support thanks to ProteoWizard 1.0 release

[Brian P. <bri...@in...>]

Hi Darren,

 

I won't be at USHUPO, but good luck with the poster, and feel free to
mention that ProteoWizard is now used by InsilicosViewer for displaying mzML
data (http://www.insilicos.com/Insilicos_Viewer.html).  I haven't done any
sort of formal announcement yet since it's clear that mzML isn't put to bed,
but it's out there for test purposes now.

 

Brian

 

  _____  

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Kessner,
Darren E.
Sent: Friday, March 14, 2008 5:54 PM
To: Mass spectrometry standard development
Subject: [Psidev-ms-dev] ProteoWizard 1.0 released

 

Hi all,

 

I'm happy to announce the official release of ProteoWizard, available on
SourceForge under the Apache license.

 

Codebase is available through public subversion, and the first source and
binary (Windows and Linux i386) packages are available for download.  

 

The binary tools packages may be of interest to this group of mzML
enthusiasts:

 

msconvert: converts RAW -> mzML <-> mzXML, (and more vendor formats
hopefully soon with the help of Matt Chambers!)

 

msaccess:  extracts spectrum data & metadata, selected ion chromatograms,
pseudo-2D-gel image generation

                  (works on RAW/mzML/mzXML equally well, except no RAW on
Linux)

 

Here's the website:

http://proteowizard.sourceforge.net

 

I'll be presenting a poster about ProteoWizard this Tuesday at US HUPO --
I'd love to meet any of you who will be there!

 

 

Darren

 

 

 

IMPORTANT WARNING: This message is intended for the use of the person or
entity to which it is addressed and may contain information that is
privileged and confidential, the disclosure of which is governed by
applicable law. If the reader of this message is not the intended recipient,
or the employee or agent responsible for delivering it to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message. Thank You for
your cooperation.