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

Status: Beta

Brought to you by: aceol, baranda, cccolinc, chrisftaylor, and 22 others

psidev-ms-dev

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

From: Eric D. <eri...@gm...> - 2008-04-16 13:48:07

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: precursor m/z method logging?

From: Matthew C. <mat...@va...> - 2008-04-16 14:30:50

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: precursor m/z method logging?

From: Joshua T. <jt...@sy...> - 2008-04-16 17:43:34

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: precursor m/z method logging?

From: Matthew C. <mat...@va...> - 2008-04-16 18:35:45


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