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

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

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).
>
>  
>
>  
>
> Darren
>
>  
>
>  
>
>  
>
>  
>
> 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.
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>