psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] CV term Proteinlynx

[Rune S. P. <ru...@ph...>]

As I understand the Waters software, we have several things named 
proteinlynx.
- There's a module for MassLynx called ProteinLynx.
- ProteinLynx Global Server: The search engine used by ProteinLynx Browser.
- ProteinLynx Browser: Waters software for data analysis.

--
Regards
Rune

[Psidev-ms-dev] CV terms

[Rune S. P. <ru...@ph...>]

There are open requests for cv terms in the tracker
http://sourceforge.net/tracker/?atid=848524&group_id=65472&func=browse

january 15. I proposed adding the Waters Q-Tof Premier instrument.
As I think of it, we also have a Waters Synapt HDMS, that instrument is 
also not in the cv.

Also something needs to be added to be able to indicate that a scan is a 
reference scan (locksprayer source for instance).
I think either it should be noted in the instrument description or in 
the specific scan somehow.

--
Regards
Rune

Re: [Psidev-ms-dev] Smaller files

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

 From Josh Tasman, unable to post directly:

Hi Rune,

As you've seen in the source code, only the most basic implementation is 
currently in the SPC converters; and as Matt points out it is in the 
mzML spec so could be implemented pretty easily.

Thanks for your good suggestion, especially integer counts for Waters 
(although my experience is that if you acquire in centroid you get real 
values.)

Josh


Matthew Chambers wrote:
 > Compression and data type/precision are cv params for the
 > BinaryDataArray elements:
 > MS_zlib_compression = 1000574
 > MS_no_compression = 1000576
 >
 > MS_32_bit_integer = 1000519
 > MS_16_bit_float = 1000520
 > MS_32_bit_float = 1000521
 > MS_64_bit_integer = 1000522
 > MS_64_bit_float = 1000523
 >
 > Rune Schjellerup Philosof wrote:
 >> I looked for the capability in the latest (20080327) snapshot xsd from
 >> Lennart and couldn't find it.
 >> Isn't integer intensities also quite common.
 >> Data from the Waters Premier seem to be integer ion counts.
 >>
 >> -Rune
 >>
 >> Matt Chambers wrote:
 >>  
 >>> Hi Rune, mzML has both of these capabilities. With separate binary
 >>> arrays (like mzXML 3.0 theoretically supports but so far is rare in the
 >>> wild), the m/z array can be 64 and the intensity array can be 32, which
 >>> is most likely to fit current instrument capabilities. Also,
 >>> chromatogram time values probably don't need 64 bit either. SPC's
 >>> converter tools support writing and reading compressed mzML last time I
 >>> checked.
 >>>
 >>> -Matt
 >>>
 >>>
 >>> Rune Schjellerup Philosof wrote:
 >>>  
 >>>    
 >>>> In mzXML 3.0 there are two options for generating smaller files.
 >>>> 1. Saving in 32bit instead of 64bit.
 >>>> 2. Compressing the scans using zllib.
 >>>>
 >>>> Any special reasons why these features hasn't survived into mzML 
(yet)?
 >>>>
 >>>> --
 >>>> Regards
 >>>> Rune

Re: [Psidev-ms-dev] Smaller files

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

Compression and data type/precision are cv params for the 
BinaryDataArray elements:
MS_zlib_compression = 1000574
MS_no_compression = 1000576

MS_32_bit_integer = 1000519
MS_16_bit_float = 1000520
MS_32_bit_float = 1000521
MS_64_bit_integer = 1000522
MS_64_bit_float = 1000523

Rune Schjellerup Philosof wrote:
> I looked for the capability in the latest (20080327) snapshot xsd from 
> Lennart and couldn't find it.
> Isn't integer intensities also quite common.
> Data from the Waters Premier seem to be integer ion counts.
>
> -Rune
>
> Matt Chambers wrote:
>   
>> Hi Rune, mzML has both of these capabilities. With separate binary 
>> arrays (like mzXML 3.0 theoretically supports but so far is rare in the 
>> wild), the m/z array can be 64 and the intensity array can be 32, which 
>> is most likely to fit current instrument capabilities. Also, 
>> chromatogram time values probably don't need 64 bit either. SPC's 
>> converter tools support writing and reading compressed mzML last time I 
>> checked.
>>
>> -Matt
>>
>>
>> Rune Schjellerup Philosof wrote:
>>   
>>     
>>> In mzXML 3.0 there are two options for generating smaller files.
>>> 1. Saving in 32bit instead of 64bit.
>>> 2. Compressing the scans using zllib.
>>>
>>> Any special reasons why these features hasn't survived into mzML (yet)?
>>>
>>> --
>>> Regards
>>> Rune
>>>
>>>   
>>>     
>>>       
>> -------------------------------------------------------------------------
>> 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
>>   
>>     
>
>
> -------------------------------------------------------------------------
> 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] Smaller files

[Rune S. P. <ru...@ph...>]

I looked for the capability in the latest (20080327) snapshot xsd from 
Lennart and couldn't find it.
Isn't integer intensities also quite common.
Data from the Waters Premier seem to be integer ion counts.

-Rune

Matt Chambers wrote:
> Hi Rune, mzML has both of these capabilities. With separate binary 
> arrays (like mzXML 3.0 theoretically supports but so far is rare in the 
> wild), the m/z array can be 64 and the intensity array can be 32, which 
> is most likely to fit current instrument capabilities. Also, 
> chromatogram time values probably don't need 64 bit either. SPC's 
> converter tools support writing and reading compressed mzML last time I 
> checked.
>
> -Matt
>
>
> Rune Schjellerup Philosof wrote:
>   
>> In mzXML 3.0 there are two options for generating smaller files.
>> 1. Saving in 32bit instead of 64bit.
>> 2. Compressing the scans using zllib.
>>
>> Any special reasons why these features hasn't survived into mzML (yet)?
>>
>> --
>> Regards
>> Rune
>>
>>   
>>     
>
>
> -------------------------------------------------------------------------
> 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] Smaller files

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

Hi Rune, mzML has both of these capabilities. With separate binary 
arrays (like mzXML 3.0 theoretically supports but so far is rare in the 
wild), the m/z array can be 64 and the intensity array can be 32, which 
is most likely to fit current instrument capabilities. Also, 
chromatogram time values probably don't need 64 bit either. SPC's 
converter tools support writing and reading compressed mzML last time I 
checked.

-Matt


Rune Schjellerup Philosof wrote:
> In mzXML 3.0 there are two options for generating smaller files.
> 1. Saving in 32bit instead of 64bit.
> 2. Compressing the scans using zllib.
>
> Any special reasons why these features hasn't survived into mzML (yet)?
>
> --
> Regards
> Rune
>
>   

[Psidev-ms-dev] Smaller files

[Rune S. P. <mai...@ph...>]

In mzXML 3.0 there are two options for generating smaller files.
1. Saving in 32bit instead of 64bit.
2. Compressing the scans using zllib.

Any special reasons why these features hasn't survived into mzML (yet)?

--
Regards
Rune

Re: [Psidev-ms-dev] Chromatogram and spectrum terms in the CV

[Darren K. <dke...@ya...>]

Hi everyone,

I've added chromatogram support to ProteoWizard, including indexing.  
I've updated the tiny.pwiz.mzML example linked from the mzML page.

In addition to the CV terms mentioned by Matt, I think we should add a 
"dataProcessingRef" attribute to the <chromatogram> element in the spec, 
so we can encode where we are getting the chromatogram from (e.g. 
XCalibur directly vs. a post-processing calculation).

I haven't checked the schema, but it also needs to handle multiple 
<index> elements -- one to index into <spectrumList> and one to index 
into <chromatogramList>.  Currently <indexOffset> points to the first 
<index>, and we look for the multiple <index> elements.  If this bothers 
anyone, we might consider having either multiple <indexOffset> elements 
with name attributes, or put the <index> elements in an <indexList>.


Darren



Matthew Chambers wrote:
> Hi all,
>
> With the new developments in the schema to support chromatograms and 
> non-mass spectra, some corresponding changes to the CV should happen.
>
> The current "spectrum type" should be renamed to "mass spectrum type" 
> and a new "spectrum type" term should be defined that allows for 
> non-mass spectra:
>   
>> [Term]
>> id: MS:1000559
>> name: spectrum type
>> def: "Spectrum type." [PSI:MS]
>> relationship: part_of MS:1000442 ! spectrum
>>     
>
> All the children of the old "spectrum type" are really mass spectrum 
> types, so they would be children of the renamed "mass spectrum type":
>   
>> name: MS1 spectrum
>> name: MSn spectrum
>> name: CRM spectrum
>> name: SIM spectrum
>> name: SRM spectrum
>>     
>
> We don't have a term for PDA spectrum, UV spectrum, or ADC spectrum; I 
> suggest we add all these and make them children of the generic "spectrum 
> type" because unless I'm missing something they don't require their own 
> subtypes. Mass spectra definitely need their own subtype though (to ease 
> semantic validation: any mass spectrum should have m/z and intensity 
> arrays).
>
> Add a "chromatogram type" term.
> Redefine the "total ion chromatogram" term to be PART_OF "chromatogram 
> type".
> Add a "chromatogram" term analogous to the "spectrum" term (i.e. PART_OF 
> MS:0000000) and make "chromatogram type" PART_OF "chromatogram" just 
> like "spectrum_type" is PART_OF "spectrum".
> Add a "selected ion chromatogram" term.
> The "m/z" term could suffice to indicate which ion was "selected". But 
> for SRM SICs, an additional m/z is indicated to indicate the 
> product/fragment m/z and having two terms that just say "m/z" is 
> undesirable. Consequently, we might either add only a "product m/z" term 
> or add both "precursor m/z" and "product m/z" terms.
>
> That's all I can think of for now. :)
>
> -Matt
>
> -------------------------------------------------------------------------
> 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] Chromatogram and spectrum terms in the CV

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

Hi all,

With the new developments in the schema to support chromatograms and 
non-mass spectra, some corresponding changes to the CV should happen.

The current "spectrum type" should be renamed to "mass spectrum type" 
and a new "spectrum type" term should be defined that allows for 
non-mass spectra:
> [Term]
> id: MS:1000559
> name: spectrum type
> def: "Spectrum type." [PSI:MS]
> relationship: part_of MS:1000442 ! spectrum

All the children of the old "spectrum type" are really mass spectrum 
types, so they would be children of the renamed "mass spectrum type":
> name: MS1 spectrum
> name: MSn spectrum
> name: CRM spectrum
> name: SIM spectrum
> name: SRM spectrum

We don't have a term for PDA spectrum, UV spectrum, or ADC spectrum; I 
suggest we add all these and make them children of the generic "spectrum 
type" because unless I'm missing something they don't require their own 
subtypes. Mass spectra definitely need their own subtype though (to ease 
semantic validation: any mass spectrum should have m/z and intensity 
arrays).

Add a "chromatogram type" term.
Redefine the "total ion chromatogram" term to be PART_OF "chromatogram 
type".
Add a "chromatogram" term analogous to the "spectrum" term (i.e. PART_OF 
MS:0000000) and make "chromatogram type" PART_OF "chromatogram" just 
like "spectrum_type" is PART_OF "spectrum".
Add a "selected ion chromatogram" term.
The "m/z" term could suffice to indicate which ion was "selected". But 
for SRM SICs, an additional m/z is indicated to indicate the 
product/fragment m/z and having two terms that just say "m/z" is 
undesirable. Consequently, we might either add only a "product m/z" term 
or add both "precursor m/z" and "product m/z" terms.

That's all I can think of for now. :)

-Matt

[Psidev-ms-dev] Semantic validator checking for m/z and intensity binaryDataArrays

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

Hi all,

Looking at the current semantic mapping file 
(https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml), 
it seems that Spectrum does not require an m/z and intensity 
binaryDataArray and according to the spec it should. However, we have a 
problem where only mass spectra must have m/z and intensity. PDA spectra 
must have wavelenth and intensity instead. Both mass and PDA spectra use 
the Spectrum element so the type cvParam would have to be used to 
distinguish which rules to apply to a particular element. Chromatograms 
have a separate element so giving it its own required arrays should be 
simple. The semantic validator should be capable of validating these 
arrays, but can it currently do that?


-Matt

Re: [Psidev-ms-dev] PDA spectrum example + nativeIDs + component references

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

Hi all,

I support the fully qualified nativeIDs for Thermo that Matt suggests.

I also think we should add the component references (sourceRef, 
analyzerRef, detectorRef).  This would resolve the issue Matt and I were
debating a month or so ago about encoding instrument information in the
individual <spectrum> elements.  We had left the discussion with the
problem that using "virtual instrument" references to distinguish
between mass analyzer types in a hybrid instrument wouldn't scale well
to handle more options.  Being able to refer to specific components
handles both issues of scalability and non-redundancy of information in
<spectrum>.


Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Thursday, April 17, 2008 8:18 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] PDA spectrum example

Other than a few syntactical problems and some missing metadata, it 
looks good. Thanks Jim (and Eric for forwarding)! Would it be possible 
to get the corresponding RAW file for such a PDA example for use with 
developing converters? And even better would be a RAW file with both MS 
and PDA spectra intermixed.

In the Thermo context, this brings up an issue with nativeID. I think 
everybody wants to see Thermo nativeID simply be a scan number like been

for so long, but I am thinking that is not quite true to what the file 
is storing. As I understand it, each "controller" has its own list of 
scan numbers, so a file-scoped spectrum id is a combination of the 
controller and the scan number. Now in the vast majority of cases we are

only dealing with controller 0 for MS data, but I am wary of treating 
this technically degenerate case (i.e. where one dimension of the ID is 
always the same so it could potentially be excluded) specially. I think 
it will cause considerable confusion when implementors look up the 
format of the nativeID after they encounter a "non-degenerate" case 
where the multi-dimensional ID is necessary. I would propose a Thermo 
nativeID look like: "<controller #>,<scan #>", e.g. "0,1" "0,2" "0,3" 
"0,4" ... "0,10000" for an average MS file with 10k scans. For a 
"non-degenerate" case where MS are intermixed with PDA spectra, it would

look like (3 is the controller # for PDA):
0,1
...
0,1000
3,1
...
3,500
Here I iterate on controller first and then on scan number because 
switching between controllers is presumably more intensive in the API 
than switching scan numbers.

Also the "non-degenerate" case reintroduces the issue of having multiple

components within a single instrument. It seems like we can have 
multiples of all three components (source/analyzer/detector). Unless I 
am mistaken and the PDA acquiring component is considered to be a 
separate instrument? If it is indeed part of the same instrument, we 
might look at some kind of component referencing attributes (sourceRef, 
analyzerRef, detectorRef) for scan or spectrum. How does that sound? We 
could fabricate a hypothetical example with an instrument that has MALDI

and ESI sources used in tandem with both IT, Orbitrap, and TOF analyzers

in tandem, and EM and PDA detectors...coming soon to a lab near you.

-Matt


Eric Deutsch wrote:
>
> Hi everyone, attached is a PDA example mzML file from Jim Shofstahl. 
> Here's what Jim said with it:
>
> Hopefully the rest of the format matches the current standard. Any new

> terms have CV values that begin with 9's.
>
> When PDA data is stored in an Xcalibur raw file, there isn't that much

> information that goes In the scan header, so the format is rather 
> sparse when it comes to descriptive information.
>
> Thanks,
>
> Jim Shofstahl
>
>

------------------------------------------------------------------------
-
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/j
avaone
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
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.

[Psidev-ms-dev] No CV terms for non-destructive detectors

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

Unless I'm mistaken, non-destructive detectors like those in the 
Orbitrap and FT instruments are not present in the CV, which currently 
has these types:
 name: channeltron
 name: daly detector
 name: faraday cup
 name: microchannel plate detector
 name: multi-collector
 name: photomultiplier
 name: electron multiplier
 name: array detector
 name: conversion dynode
 name: dynode
 name: focal plane collector
 name: ion-to-photon detector
 name: point collector
 name: postacceleration detector

Also, triple quadrupole instruments may have quadrupoles with different 
characteristics at each stage, how do we handle that?

-Matt

Re: [Psidev-ms-dev] PDA spectrum example

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

Other than a few syntactical problems and some missing metadata, it 
looks good. Thanks Jim (and Eric for forwarding)! Would it be possible 
to get the corresponding RAW file for such a PDA example for use with 
developing converters? And even better would be a RAW file with both MS 
and PDA spectra intermixed.

In the Thermo context, this brings up an issue with nativeID. I think 
everybody wants to see Thermo nativeID simply be a scan number like been 
for so long, but I am thinking that is not quite true to what the file 
is storing. As I understand it, each "controller" has its own list of 
scan numbers, so a file-scoped spectrum id is a combination of the 
controller and the scan number. Now in the vast majority of cases we are 
only dealing with controller 0 for MS data, but I am wary of treating 
this technically degenerate case (i.e. where one dimension of the ID is 
always the same so it could potentially be excluded) specially. I think 
it will cause considerable confusion when implementors look up the 
format of the nativeID after they encounter a "non-degenerate" case 
where the multi-dimensional ID is necessary. I would propose a Thermo 
nativeID look like: "<controller #>,<scan #>", e.g. "0,1" "0,2" "0,3" 
"0,4" ... "0,10000" for an average MS file with 10k scans. For a 
"non-degenerate" case where MS are intermixed with PDA spectra, it would 
look like (3 is the controller # for PDA):
0,1
...
0,1000
3,1
...
3,500
Here I iterate on controller first and then on scan number because 
switching between controllers is presumably more intensive in the API 
than switching scan numbers.

Also the "non-degenerate" case reintroduces the issue of having multiple 
components within a single instrument. It seems like we can have 
multiples of all three components (source/analyzer/detector). Unless I 
am mistaken and the PDA acquiring component is considered to be a 
separate instrument? If it is indeed part of the same instrument, we 
might look at some kind of component referencing attributes (sourceRef, 
analyzerRef, detectorRef) for scan or spectrum. How does that sound? We 
could fabricate a hypothetical example with an instrument that has MALDI 
and ESI sources used in tandem with both IT, Orbitrap, and TOF analyzers 
in tandem, and EM and PDA detectors...coming soon to a lab near you.

-Matt


Eric Deutsch wrote:
>
> Hi everyone, attached is a PDA example mzML file from Jim Shofstahl. 
> Here’s what Jim said with it:
>
> Hopefully the rest of the format matches the current standard. Any new 
> terms have CV values that begin with 9’s.
>
> When PDA data is stored in an Xcalibur raw file, there isn’t that much 
> information that goes In the scan header, so the format is rather 
> sparse when it comes to descriptive information.
>
> Thanks,
>
> Jim Shofstahl
>
>

Re: [Psidev-ms-dev] PDA spectrum example

[Coleman, M. <MK...@St...>]

What does "PDA" mean?

Mike

-----Original Message-----
From: psi...@li... [mailto:psi...@li...] On Behalf Of Eric Deutsch
Sent: Thursday, April 17, 2008 12:36 AM
To: 'Mass spectrometry standard development'
Subject: [Psidev-ms-dev] PDA spectrum example

Hi everyone, attached is a PDA example mzML file from Jim Shofstahl. Here's what Jim said with it:

Hopefully the rest of the format matches the current standard.  Any new terms have CV values that begin with 9's.

When PDA data is stored in an Xcalibur raw file, there isn't that much information that goes In the scan header, so the format is rather sparse when it comes to descriptive information.

Thanks,
Jim Shofstahl

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

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

 > What is the use case for this?
Some peak detection algorithms required the m/z values to be equally 
spaced, while others require equally spaced or fitting to a polynomial 
(for example quadratic TOF data).

For a database search engine, it's useful to know instantly whether it's 
a peak list or profile data.

Other examples of 'non contiguous' data are stitched PSD data where the 
segments aren't all on the same scale. And some exotic?? instruments may 
apply different calibration parameters to different parts of the 
spectrum, so values may initially appear to be quadratically spaced, and 
then they suddenly change to a different polynomial fit.

It can be surprisingly difficult to determine/reconstruct profile data 
- for example TOF data with zero intensity values thresholded out.

Any converter / writer should know what type of data is being written, 
so the more information for the consumer the better?

The following would certainly be useful for us:

centroided
profile
   linear
   quadratic
   higher order polynomial
   FT
   other
      contiguous
      missing zeros  (thresholded)
      multiple calibration coefficients
      multiple segments (stitched psd)

David

Pierre-Alain Binz wrote:
> I aggree too with the annotation of this thresholding as processing.
> Important for some LC-MS "image" analysis tools that can make a 
> algorithmic different analysis between those kind of data
> Pierre-Alain
> 
> Joshua Tasman wrote:
>> Cool.  So, no need to denote "choppy profile" vs "contiguous profile" at the binary array level?
>>
>> (Yay, seems like I can post again! :) )
>>
>> Josh
>>
>>
>> Matthew Chambers wrote:
>>   
>>> Yes, I agree too. Intensity thresholding should most definitely be 
>>> encoded in mzML. It is one of those basic kinds of data processing like 
>>> peak picking that we just have to support even though it's not strictly 
>>> speaking the raw data.
>>>
>>> -Matt
>>>
>>>
>>> Darren Kessner wrote:
>>>     
>>>> I see -- I definitely think it's useful to flag the data reduction.   
>>>> Perhaps this should be encoded as a cvParam in <dataProcessing>?
>>>>
>>>> Darren
>>>>
>>>>
>>>>
>>>> On Apr 16, 2008, at 10:15 AM, Joshua Tasman wrote:
>>>>
>>>>   
>>>>       
>>>>> Hi Darren,
>>>>>
>>>>> You did understand what I meant.  I've been working with the Agilent  
>>>>> MassHunter-format machines which give huge non-thresholded profile  
>>>>> arrays (at least currently), where I'd like to make note of data  
>>>>> reduction that might be applied at conversion time-- and make it  
>>>>> easier for the parsers to handle "choppy profile" data.  However, if  
>>>>> Thermo data already looks that way (I didn't realize), maybe it's  
>>>>> not necessary.
>>>>>
>>>>> I incorrectly believed that "profile" implied "no gaps in m/z  
>>>>> spacing".
>>>>>
>>>>> -Josh
>>>>>
>>>>>
>>>>> Darren Kessner wrote:
>>>>>     
>>>>>         
>>>>>> What is the use case for this?
>>>>>>
>>>>>> I think everyone has an intuitive understanding of "contiguous",  
>>>>>> but I
>>>>>> think it is a little more complicated to define properly.  The
>>>>>> intuitive definition is "regularly spaced with no missing data  
>>>>>> points".
>>>>>>
>>>>>> When accessing profile data in RAW files from Thermo FT instruments,
>>>>>> the spectra are thresholded, and this gives rise to the islands that
>>>>>> Josh mentioned during the conference call.  However, in FT data
>>>>>> without islands (e.g. if thresholding is disabled, or perhaps with
>>>>>> preprocessing to extract a single island or fill in missing data
>>>>>> points), the data points are still not regularly spaced in m/z.  (The
>>>>>> data points are regularly spaced in frequency space, but the  
>>>>>> frequency-
>>>>>>       
>>>>>>           
>>>>>>> m/z calibration function is non-linear).  Because the data points
>>>>>>>         
>>>>>>>             
>>>>>> are not regularly spaced, any processing must use some form of
>>>>>> interpolation, so I'm not sure how a "contiguous" flag will help.
>>>>>>
>>>>>>
>>>>>> Darren
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Apr 16, 2008, at 6:48 AM, 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?
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>> 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
>>>>>>>         
>>>>>>>             
>>>>>> -------------------------------------------------------------------------
>>>>>> 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
>>>>>>       
>>>>>>           
>>>>> -------------------------------------------------------------------------
>>>>> 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
>>>>>     
>>>>>         
>>>> -------------------------------------------------------------------------
>>>> 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
>>>>
>>>>   
>>>>       
>>> -------------------------------------------------------------------------
>>> 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
>>>     
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>   
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

-- 
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

[Psidev-ms-dev] Inlet type vs. ionization type

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

Which ionization types are associated with which inlet types? Or are 
there just too many combinations to list? Ionization type can probably 
be gotten from the native formats fairly reliably, but inlet type seems 
to either be merely implied or absent.

-Matt

[Psidev-ms-dev] scan polarity vs. inlet type / source attribute (consistency issue)

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

Looking at the CV and the semantic mapping, it appears inlet type and 
source attributes are restricted to the instrument description. This 
makes sense to me (it's similar to the mass analyzer problem where a 
hybrid instrument may have multiple analyzers). However, why is polarity 
on a per-spectrum basis if inlet type and source attributes are not?

-Matt

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

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

Joshua Tasman wrote:
> Hm.. good suggestion about including the accuracy, but the whole problem is that we don't know how much to trust the various methods currently, at least for Thermo-- in other words, for the routines that return doubles, no way to know the correct measure of significant digits.
>   
We can probably guess this from downstream data analysis and apply it 
upstream, if we can't get it from Xcalibur.

> I guess I was picturing a case where the user choses the method(s) they think is best.  Your suggestion is good, and (perhaps correctly) offloads the question of determining which value to use to a downstream user / program.
>   
Actually it allows both. The primary m/z value is filled in based on the 
converter's design/configuration, but downstream users/programs can use 
the alternate m/z values if they know/care about them. Also, it wouldn't 
lose information (currently, choosing one or the other m/z value 
excludes the other, and being able to see both is quite desirable I think).

> But, what's the dislike with having centroiding, thresholding, precursor mz determination, etc, having blocks or subsections in the main software processing header?
>   
Can you come up with an example of how you would want this to look?

-Matt


>
> Josh
>
>
> Matthew Chambers wrote:
>   
>> 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
>>>
>>>
>>>   
>>>       
>> -------------------------------------------------------------------------
>> 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
>>     
>
>
> -------------------------------------------------------------------------
> 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] additional feature request: contiguous/noncontigous marker for m/z array data?

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

I aggree too with the annotation of this thresholding as processing.
Important for some LC-MS "image" analysis tools that can make a 
algorithmic different analysis between those kind of data
Pierre-Alain

Joshua Tasman wrote:
> Cool.  So, no need to denote "choppy profile" vs "contiguous profile" at the binary array level?
>
> (Yay, seems like I can post again! :) )
>
> Josh
>
>
> Matthew Chambers wrote:
>   
>> Yes, I agree too. Intensity thresholding should most definitely be 
>> encoded in mzML. It is one of those basic kinds of data processing like 
>> peak picking that we just have to support even though it's not strictly 
>> speaking the raw data.
>>
>> -Matt
>>
>>
>> Darren Kessner wrote:
>>     
>>> I see -- I definitely think it's useful to flag the data reduction.   
>>> Perhaps this should be encoded as a cvParam in <dataProcessing>?
>>>
>>> Darren
>>>
>>>
>>>
>>> On Apr 16, 2008, at 10:15 AM, Joshua Tasman wrote:
>>>
>>>   
>>>       
>>>> Hi Darren,
>>>>
>>>> You did understand what I meant.  I've been working with the Agilent  
>>>> MassHunter-format machines which give huge non-thresholded profile  
>>>> arrays (at least currently), where I'd like to make note of data  
>>>> reduction that might be applied at conversion time-- and make it  
>>>> easier for the parsers to handle "choppy profile" data.  However, if  
>>>> Thermo data already looks that way (I didn't realize), maybe it's  
>>>> not necessary.
>>>>
>>>> I incorrectly believed that "profile" implied "no gaps in m/z  
>>>> spacing".
>>>>
>>>> -Josh
>>>>
>>>>
>>>> Darren Kessner wrote:
>>>>     
>>>>         
>>>>> What is the use case for this?
>>>>>
>>>>> I think everyone has an intuitive understanding of "contiguous",  
>>>>> but I
>>>>> think it is a little more complicated to define properly.  The
>>>>> intuitive definition is "regularly spaced with no missing data  
>>>>> points".
>>>>>
>>>>> When accessing profile data in RAW files from Thermo FT instruments,
>>>>> the spectra are thresholded, and this gives rise to the islands that
>>>>> Josh mentioned during the conference call.  However, in FT data
>>>>> without islands (e.g. if thresholding is disabled, or perhaps with
>>>>> preprocessing to extract a single island or fill in missing data
>>>>> points), the data points are still not regularly spaced in m/z.  (The
>>>>> data points are regularly spaced in frequency space, but the  
>>>>> frequency-
>>>>>       
>>>>>           
>>>>>> m/z calibration function is non-linear).  Because the data points
>>>>>>         
>>>>>>             
>>>>> are not regularly spaced, any processing must use some form of
>>>>> interpolation, so I'm not sure how a "contiguous" flag will help.
>>>>>
>>>>>
>>>>> Darren
>>>>>
>>>>>
>>>>>
>>>>> On Apr 16, 2008, at 6:48 AM, 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?
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> 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
>>>>>>         
>>>>>>             
>>>>> -------------------------------------------------------------------------
>>>>> 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
>>>>>       
>>>>>           
>>>> -------------------------------------------------------------------------
>>>> 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
>>>>     
>>>>         
>>> -------------------------------------------------------------------------
>>> 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
>>>
>>>   
>>>       
>> -------------------------------------------------------------------------
>> 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
>>     
>
> -------------------------------------------------------------------------
> 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] additional feature request: precursor m/z method logging?

[Joshua T. <jt...@sy...>]

Hm.. good suggestion about including the accuracy, but the whole problem is that we don't know how much to trust the various methods currently, at least for Thermo-- in other words, for the routines that return doubles, no way to know the correct measure of significant digits.

I guess I was picturing a case where the user choses the method(s) they think is best.  Your suggestion is good, and (perhaps correctly) offloads the question of determining which value to use to a downstream user / program.

But, what's the dislike with having centroiding, thresholding, precursor mz determination, etc, having blocks or subsections in the main software processing header?


Josh


Matthew Chambers wrote:
> 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
>>
>>
>>   
> 
> -------------------------------------------------------------------------
> 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] additional feature request: contiguous/noncontigous marker for m/z array data?

[Joshua T. <jt...@sy...>]

Cool.  So, no need to denote "choppy profile" vs "contiguous profile" at the binary array level?

(Yay, seems like I can post again! :) )

Josh


Matthew Chambers wrote:
> Yes, I agree too. Intensity thresholding should most definitely be 
> encoded in mzML. It is one of those basic kinds of data processing like 
> peak picking that we just have to support even though it's not strictly 
> speaking the raw data.
> 
> -Matt
> 
> 
> Darren Kessner wrote:
>> I see -- I definitely think it's useful to flag the data reduction.   
>> Perhaps this should be encoded as a cvParam in <dataProcessing>?
>>
>> Darren
>>
>>
>>
>> On Apr 16, 2008, at 10:15 AM, Joshua Tasman wrote:
>>
>>   
>>> Hi Darren,
>>>
>>> You did understand what I meant.  I've been working with the Agilent  
>>> MassHunter-format machines which give huge non-thresholded profile  
>>> arrays (at least currently), where I'd like to make note of data  
>>> reduction that might be applied at conversion time-- and make it  
>>> easier for the parsers to handle "choppy profile" data.  However, if  
>>> Thermo data already looks that way (I didn't realize), maybe it's  
>>> not necessary.
>>>
>>> I incorrectly believed that "profile" implied "no gaps in m/z  
>>> spacing".
>>>
>>> -Josh
>>>
>>>
>>> Darren Kessner wrote:
>>>     
>>>> What is the use case for this?
>>>>
>>>> I think everyone has an intuitive understanding of "contiguous",  
>>>> but I
>>>> think it is a little more complicated to define properly.  The
>>>> intuitive definition is "regularly spaced with no missing data  
>>>> points".
>>>>
>>>> When accessing profile data in RAW files from Thermo FT instruments,
>>>> the spectra are thresholded, and this gives rise to the islands that
>>>> Josh mentioned during the conference call.  However, in FT data
>>>> without islands (e.g. if thresholding is disabled, or perhaps with
>>>> preprocessing to extract a single island or fill in missing data
>>>> points), the data points are still not regularly spaced in m/z.  (The
>>>> data points are regularly spaced in frequency space, but the  
>>>> frequency-
>>>>       
>>>>> m/z calibration function is non-linear).  Because the data points
>>>>>         
>>>> are not regularly spaced, any processing must use some form of
>>>> interpolation, so I'm not sure how a "contiguous" flag will help.
>>>>
>>>>
>>>> Darren
>>>>
>>>>
>>>>
>>>> On Apr 16, 2008, at 6:48 AM, 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?
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> 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
>>>>>         
>>>> -------------------------------------------------------------------------
>>>> 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
>>>>       
>>> -------------------------------------------------------------------------
>>> 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
>>>     
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>   
> 
> -------------------------------------------------------------------------
> 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] additional feature request: contiguous/noncontigous marker for m/z array data?

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

Yes, I agree too. Intensity thresholding should most definitely be 
encoded in mzML. It is one of those basic kinds of data processing like 
peak picking that we just have to support even though it's not strictly 
speaking the raw data.

-Matt


Darren Kessner wrote:
> I see -- I definitely think it's useful to flag the data reduction.   
> Perhaps this should be encoded as a cvParam in <dataProcessing>?
>
> Darren
>
>
>
> On Apr 16, 2008, at 10:15 AM, Joshua Tasman wrote:
>
>   
>> Hi Darren,
>>
>> You did understand what I meant.  I've been working with the Agilent  
>> MassHunter-format machines which give huge non-thresholded profile  
>> arrays (at least currently), where I'd like to make note of data  
>> reduction that might be applied at conversion time-- and make it  
>> easier for the parsers to handle "choppy profile" data.  However, if  
>> Thermo data already looks that way (I didn't realize), maybe it's  
>> not necessary.
>>
>> I incorrectly believed that "profile" implied "no gaps in m/z  
>> spacing".
>>
>> -Josh
>>
>>
>> Darren Kessner wrote:
>>     
>>> What is the use case for this?
>>>
>>> I think everyone has an intuitive understanding of "contiguous",  
>>> but I
>>> think it is a little more complicated to define properly.  The
>>> intuitive definition is "regularly spaced with no missing data  
>>> points".
>>>
>>> When accessing profile data in RAW files from Thermo FT instruments,
>>> the spectra are thresholded, and this gives rise to the islands that
>>> Josh mentioned during the conference call.  However, in FT data
>>> without islands (e.g. if thresholding is disabled, or perhaps with
>>> preprocessing to extract a single island or fill in missing data
>>> points), the data points are still not regularly spaced in m/z.  (The
>>> data points are regularly spaced in frequency space, but the  
>>> frequency-
>>>       
>>>> m/z calibration function is non-linear).  Because the data points
>>>>         
>>> are not regularly spaced, any processing must use some form of
>>> interpolation, so I'm not sure how a "contiguous" flag will help.
>>>
>>>
>>> Darren
>>>
>>>
>>>
>>> On Apr 16, 2008, at 6:48 AM, 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?
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> 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
>>>>         
>>> -------------------------------------------------------------------------
>>> 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
>>>       
>> -------------------------------------------------------------------------
>> 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
>>     
>
>
> -------------------------------------------------------------------------
> 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] additional feature request: contiguous/noncontigous marker for m/z array data?

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

I see -- I definitely think it's useful to flag the data reduction.   
Perhaps this should be encoded as a cvParam in <dataProcessing>?

Darren



On Apr 16, 2008, at 10:15 AM, Joshua Tasman wrote:

> Hi Darren,
>
> You did understand what I meant.  I've been working with the Agilent  
> MassHunter-format machines which give huge non-thresholded profile  
> arrays (at least currently), where I'd like to make note of data  
> reduction that might be applied at conversion time-- and make it  
> easier for the parsers to handle "choppy profile" data.  However, if  
> Thermo data already looks that way (I didn't realize), maybe it's  
> not necessary.
>
> I incorrectly believed that "profile" implied "no gaps in m/z  
> spacing".
>
> -Josh
>
>
> Darren Kessner wrote:
>> What is the use case for this?
>>
>> I think everyone has an intuitive understanding of "contiguous",  
>> but I
>> think it is a little more complicated to define properly.  The
>> intuitive definition is "regularly spaced with no missing data  
>> points".
>>
>> When accessing profile data in RAW files from Thermo FT instruments,
>> the spectra are thresholded, and this gives rise to the islands that
>> Josh mentioned during the conference call.  However, in FT data
>> without islands (e.g. if thresholding is disabled, or perhaps with
>> preprocessing to extract a single island or fill in missing data
>> points), the data points are still not regularly spaced in m/z.  (The
>> data points are regularly spaced in frequency space, but the  
>> frequency-
>>> m/z calibration function is non-linear).  Because the data points
>> are not regularly spaced, any processing must use some form of
>> interpolation, so I'm not sure how a "contiguous" flag will help.
>>
>>
>> Darren
>>
>>
>>
>> On Apr 16, 2008, at 6:48 AM, 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?
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>
>>
>> -------------------------------------------------------------------------
>> 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
>
> -------------------------------------------------------------------------
> 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] additional feature request: contiguous/noncontigous marker for m/z array data?

[Joshua T. <jt...@sy...>]

Hi Darren,

You did understand what I meant.  I've been working with the Agilent MassHunter-format machines which give huge non-thresholded profile arrays (at least currently), where I'd like to make note of data reduction that might be applied at conversion time-- and make it easier for the parsers to handle "choppy profile" data.  However, if Thermo data already looks that way (I didn't realize), maybe it's not necessary.

I incorrectly believed that "profile" implied "no gaps in m/z spacing".

-Josh


Darren Kessner wrote:
> What is the use case for this?
> 
> I think everyone has an intuitive understanding of "contiguous", but I  
> think it is a little more complicated to define properly.  The  
> intuitive definition is "regularly spaced with no missing data points".
> 
> When accessing profile data in RAW files from Thermo FT instruments,  
> the spectra are thresholded, and this gives rise to the islands that  
> Josh mentioned during the conference call.  However, in FT data  
> without islands (e.g. if thresholding is disabled, or perhaps with  
> preprocessing to extract a single island or fill in missing data  
> points), the data points are still not regularly spaced in m/z.  (The  
> data points are regularly spaced in frequency space, but the frequency- 
>  >m/z calibration function is non-linear).  Because the data points  
> are not regularly spaced, any processing must use some form of  
> interpolation, so I'm not sure how a "contiguous" flag will help.
> 
> 
> Darren
> 
> 
> 
> On Apr 16, 2008, at 6:48 AM, 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?
>>
>> 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
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
> 
> 
> -------------------------------------------------------------------------
> 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] additional feature request: contiguous/noncontigous marker for m/z array data?

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

What is the use case for this?

I think everyone has an intuitive understanding of "contiguous", but I  
think it is a little more complicated to define properly.  The  
intuitive definition is "regularly spaced with no missing data points".

When accessing profile data in RAW files from Thermo FT instruments,  
the spectra are thresholded, and this gives rise to the islands that  
Josh mentioned during the conference call.  However, in FT data  
without islands (e.g. if thresholding is disabled, or perhaps with  
preprocessing to extract a single island or fill in missing data  
points), the data points are still not regularly spaced in m/z.  (The  
data points are regularly spaced in frequency space, but the frequency- 
 >m/z calibration function is non-linear).  Because the data points  
are not regularly spaced, any processing must use some form of  
interpolation, so I'm not sure how a "contiguous" flag will help.


Darren



On Apr 16, 2008, at 6:48 AM, 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?
>
> 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
>
>
>
>
>
>
> -------------------------------------------------------------------------
> 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