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

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

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. :) I don't like the idea of writing the filter string to the 
file at all, but I have no reason to stop people from doing it - it is 
of course Thermo's way of storing a quick summary of the scan metadata. 
But that metadata is totally redundant with the metadata in the mzML 
file, even if some of it has been made indirectly accessible for 
optimization purposes (it would be plausible to write the same 
instrument element for every scan in order to minimize indirection, but 
that would obviously be inefficient). As for implementation, both 
writers and readers (at least readers which care about the instrument 
metadata) would need to keep an internal mapping to the instrument 
metadata from the scans, or else store it for every scan without regard 
to the redundancy. I'm afraid this is just a tradeoff between 
performance optimization and ease of implementation. Anyway, mzXML went 
with the "one instrument element per analyzer" method, and it wasn't too 
hard to implement support for. The hardest part in my experience was 
having to parse all the Thermo filters up front to determine which 
analyzers the instrument has. :(

-Matt


Kessner, Darren E. wrote:
>> I do not like the idea of putting the mass analyzer type cvParams 
>> in multiple places (i.e. both in the scan element and in the 
>> instrument)
>>     
>
> I agree that it's a good principle to avoid duplicated information.  But
> I think that it's important to make the most common use cases most
> convenient.
>
> An example of this is the 'msLevel' attribute, which can be found in the
> filter string as well, but since it is commonly used to do quick
> filtering of the spectra, the information is duplicated and placed in a
> convenient place.  In our software tools, the first filtering done is
> always by msLevel and massAnalyzerType.
>
> I also agree that we can hide the indirection.  But there will be other
> writers and parsers that will also have to deal with this common
> scenario.  (It's actually more annoying for mzML writers, which would
> have to keep an internal map from the filter string fragment to the
> multiple <instrument> entries in order to write out <spectrum>
> elements.)
>
>
> Darren
>
>
>