Re: [Psidev-ms-dev] cvParam for mass analyzer in <scan>

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

Darren Kessner wrote:
>> I don't think this use case is all that common, though. Of course, if 
>> precursor mass/charge correction were more common, then so would this
>> use case.
>>     
>
>
> Actually, this is more common than most people probably realize -- 
> precursor m/z-intensity recalculation is done silently during RAW->mzXML 
> conversion by ReAdW, which finds a local max in the parent scan near the 
> value reported in the filter string (when it's not stored in the trailer 
> data). I think this sort of processing should be made explicit in the 
> data file, and when it is not done, we can at least facilitate this 
> calculation.
>   
It only looks up the intensity, it does not attempt to correct the m/z 
(and it does it for both inaccurate and accurate m/z). I don't think a 
simple lookup of an intensity value for a m/z should constitute 
"processing." But m/z correction certainly would. Actually that's 
another reason not to include the filter line in Thermo conversion...for 
high-accuracy instruments, users might see the difference between the 
filter precursor m/z and the cvParam precursor m/z and think that it's 
an error because the values don't match.


> On the other hand, it's not just for precursor recalculation. This would 
> also facilitate other calculations that span scans, e.g. integrating a 
> selected ion chromatogram over a certain time interval. Here again you 
> can rely on the software layer to distinguish between the mass analyzer 
> types, but I would argue that hybrid instruments are common enough to 
> warrant making this calculation simpler.
>   
MzML is loaded with performance optimizations and indirections like this 
one, the worst being that a paramGroup can either be inline or a 
reference to a group defined elsewhere in the file. That can happen 
almost anywhere in the file, and dealing with that is far harder for a 
parser implementor than indirection to a global instrument object. We 
can provide users with a nice I/O library with an interface that follows 
the indirection on the back-end and makes it appear direct in this case 
(and many others). Even if the cvParam were directly in the <scan>, 
trying to use it directly without the nice library interface would be 
ugly IMO. This change would be taking away a raindrop in the ocean of 
indirection that mzML supports. :)

-Matt