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

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

This isn't only relevant for the analyzers.
Each of the components an instrument have more than one of, should be 
referred to from each scan.
For instance, I normally have a lockspray source for calibration.

--
Rune

Matthew Chambers wrote:
> Well, I don't particularly like the multiple virtual instruments either, 
> but I couldn't think of anything better (if it's one instrument, the 
> instrumentRef needs some way to reference the analyzer as well as the 
> instrument). I really don't like the idea of duplicating information in 
> an arbitrary way, though. Are you suggesting that it would be *optional* 
> to include the cvParam for the mass analyzer in the <scan>? That seems 
> unnecessarily hard to deal with for parsers and writers. On the other 
> hand, if the instrumentRef is to "LTQ FT -- FT" or to LTQ FT -- ion 
> trap" it is quite simple for the human reader to tell which analyzer is 
> in use. No indirection is necessary at all - just look at the id. If the 
> id is encoded in a less descriptive way, i.e. just a number, then the 
> user could quickly map in their mind that a "1" refers to the FT 
> component and a "2" refers to the IT component.
>
> I agree that this approach is not very scalable though as far as user 
> readability is concerned (e.g. if there were a hybrid instrument with 10 
> different analyzers, users could not easily remember which virtual 
> instrument each id represented). I just can't think of a CV way to do it 
> without duplicating information.
>
> And as I mentioned before, there are MANY ways in which indirection can 
> be used in mzML which can make it virtually impossible for readers to 
> interpret the file. ParamGroups have the potential to be the worst 
> offender. If such groups are id'd with just numbers and there are a lot 
> of them, users will find it impossible to remember which group of 
> cvParams corresponds to which paramGroupRef. But that's just the price 
> we pay for having that nice indirection capability. Clearly we need some 
> kind of "mzML explorer" tool to be packaged both with and apart from the 
> mzML library that we offer. Such a tool could properly render all the 
> indirection into a human readable presentation, and that is the only 
> real solution as I see it (without scrapping indirection completely).
>
> -Matt
>
>
> Kessner, Darren E. wrote:
>   
>> I've thought about this some more, and I don't like the use of two 
>> virtual <instrument> elements for the sole purpose of distinguishing 
>> between mass analyzers.  I write "virtual" because there is no 
>> difference between the two <instrument> objects, except the 'id' 
>> attribute and the "mass analyzer type" cvParam they contain.
>>
>>  
>>
>> (illustrative example -- see below for more comments)
>>
>>  
>>
>> <instrumentList count="2">
>>
>>   <instrument id="LTQ FT -- FT">
>>
>>     <cvParam cvLabel="MS" accession="MS:1000554" name=" LTQ FT " 
>> value=""/>
>>
>>     <cvParam cvLabel="MS" accession="MS:1000529" name="instrument 
>> serial number" value="23433"/>
>>
>>     ... (other cvParams here)
>>
>>       <componentList count="3">
>>
>>         <source order="1">
>>
>>           <cvParam cvLabel="MS" accession="MS:1000398" 
>> name="nanoelectrospray" value=""/>
>>
>>         </source>
>>
>>         <analyzer order="2">
>>
>>           <cvParam cvLabel="MS" accession="MS:1000082" name="FT-ICR" 
>> value=""/>
>>
>>         </analyzer>
>>
>>         <detector order="3">
>>
>>           <cvParam cvLabel="MS" accession="MS:1000253" name="electron 
>> multiplier" value=""/>
>>
>>         </detector>
>>
>>       </componentList>
>>
>>    <instrumentSoftwareRef ref="Xcalibur"/>
>>
>>   </instrument>
>>
>>  
>>
>> <!--  everything here is the same, except the id and mass analyzer 
>> type. -->
>>
>>  
>>
>>   <instrument id="LTQ FT -- ion trap">            <cvParam 
>> cvLabel="MS" accession="MS:1000554" name=" LTQ FT " value=""/>
>>
>>     <cvParam cvLabel="MS" accession="MS:1000529" name="instrument 
>> serial number" value="23433"/>
>>
>>     ... (other cvParams here)
>>
>>       <componentList count="3">
>>
>>         <source order="1">
>>
>>           <cvParam cvLabel="MS" accession="MS:1000398" 
>> name="nanoelectrospray" value=""/>
>>
>>         </source>
>>
>>         <analyzer order="2">
>>
>>           <cvParam cvLabel="MS" accession="MS:1000082" name="ion trap" 
>> value=""/>
>>
>>         </analyzer>
>>
>>         <detector order="3">
>>
>>           <cvParam cvLabel="MS" accession="MS:1000253" name="electron 
>> multiplier" value=""/>
>>
>>         </detector>
>>
>>       </componentList>
>>
>>    <instrumentSoftwareRef ref="Xcalibur"/>
>>
>>   </instrument>
>>
>> </instrumentList>
>>
>>  
>>
>>  
>>
>> I believe indirection should only be used if it makes the information 
>> clearer to the reader, whether it's a human or a parser, and whether 
>> we're talking about mzML or any programming language.  Here we're 
>> dealing with a single instrument, which can perform 3 different types 
>> of scans (FT ms1, IT ms1, IT ms2).  I believe this type information 
>> should be encoded with the scan, and I think it is less clear to the 
>> reader to encode some of the information with the scan, and some with 
>> a reference to a virtual instrument object.  (In fact, the information 
>> *is* encoded in the scan in the form of the filter string -- but I 
>> think everyone agrees that during conversion to mzML it is desirable 
>> to make this information explicit in the form of cvParams).
>>