psidev-ms-dev

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

[Kessner, D. E. <Dar...@cs...>]

Hi all,

 

We use hybrid LTQ-FT's in our lab.  We generally do two survey scans,
one FT and one ion trap, followed by ms2 scans.

 

One very common action of our tools during data analysis is to check
which mass analyzer was used during the scan.  This can be done by
looking at the filter string, which in our case begins with "FTMS ..."
or "ITMS ...".  I'd like to encode the mass analyzer as a cvParam in
<scan>, so clients don't have to parse the filter string each time:

 

<scan instrumentRef="LTQ-FT">

  <cvParam cvLabel="MS" accession="MS:1000512" name="filter string"
value="FTMS + c ESI Full ms [ 400.00-1800.00]"/>

  <cvParam cvLabel="MS" accession="MS:1000xxx" name="FT-ICR" value=""/>

    ...

</scan>

 

<scan instrumentRef="LTQ-FT">

  <cvParam cvLabel="MS" accession="MS:1000512" name="filter string"
value="ITMS + c ESI Full ms [ 400.00-1800.00]"/>

  <cvParam cvLabel="MS" accession="MS:1000xxx" name="ion trap"
value=""/>

    ...

</scan>

 

Question #1:  Is there any problem with this?  It seems to be okay
according to the spec...

 

Question #2:  Should hybrid instruments be encoded as below, with two
"mass analyzer" cvParams, or as two <instrument> elements?

 

<instrument id="LTQ-FT">

  <cvParam cvLabel="MS" accession="MS:1000xxx" name="LTQ-FT" value=""/>

  <componentList count="3">

    ...

    <analyzer order="2">

      <cvParam cvLabel="MS" accession="MS:1000xxx" name="FT-ICR"
value=""/>

      <cvParam cvLabel="MS" accession="MS:1000xxx" name="ion trap"
value=""/>

    </analyzer>

  ...

  </componentList>

</instrument>

 

I would very much prefer to write everything as above.  

 

I realize that if a hybrid instrument is encoded as two <instrument>
elements, and since <scan> has an instrumentRef, one may look up the
mass analyzer as follows:

<scan> -> instrumentRef -> <instrument> -> componentList -> analyzer ->
cvParam("mass analyzer")

But I think 5 levels of indirection is a bit cumbersome...

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

http://www.sfcap.cshs.org/

 

 

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.

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

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

According to validator mapping (possibly an old version since I got it 
from the 0.99.1 Word doc), the analyzer element has these constraints:
> cvParam Mapping Rules:
> MUST supply a *child* term of MS:1000012 (resolution measurement 
> method) one or more times
>   e.g.: MS:1000085 (baseline)
>   e.g.: MS:1000086 (full width at half-maximum)
>   e.g.: MS:1000087 (ten percent valley)
> MUST supply a *child* term of MS:1000480 (mass analyzer attribute) one 
> or more times
>   e.g.: MS:1000014 (accuracy)
>   e.g.: MS:1000022 (TOF Total Path Length)
>   e.g.: MS:1000024 (final MS exponent)
>   e.g.: MS:1000025 (magnetic field strength)
>   e.g.: MS:1000105 (reflectron off)
>   e.g.: MS:1000106 (reflectron on)
> MUST supply a *child* term of MS:1000443 (mass analyzer type) one or 
> more times
>   e.g.: MS:1000078 (axial ejection linear ion trap)
>   e.g.: MS:1000079 (fourier transform ion cyclotron resonance mass 
> spectrometer)
>   e.g.: MS:1000080 (magnetic sector)
>   e.g.: MS:1000081 (quadrupole)
>   e.g.: MS:1000082 (quadrupole ion trap)
>   e.g.: MS:1000083 (radial ejection linear ion trap)
>   e.g.: MS:1000084 (time-of-flight)
>   e.g.: MS:1000254 (electrostatic energy analyzer)
>   e.g.: MS:1000284 (stored waveform inverse fourier transform)
>   e.g.: MS:1000288 (cyclotron)
>   et al.
So hybrids are stored as a single instrument with multiple mass analyzer 
types. 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). The indirection of using the instrumentRef to look up the 
analyzer type(s) does not bother me, it is the kind of thing that should 
be masked by the "user-friendly" interface. However, if there is only 
one instrument to refer to, and it has multiple analyzers, then 
referring to it does not do anything to clear up which analyzer was used 
for a given scan. I seem to recall this issue being discussed before, 
but I can't find it in my archives and I can't remember if/how the issue 
was resolved. Storing the two analyzers in separate instrument elements 
with separate ids would make this issue a lot simpler, but it might make 
for some misleading metadata.

-Matt


Kessner, Darren E. wrote:
>
> Hi all,
>
>  
>
> We use hybrid LTQ-FT's in our lab.  We generally do two survey scans, 
> one FT and one ion trap, followed by ms2 scans.
>
>  
>
> One very common action of our tools during data analysis is to check 
> which mass analyzer was used during the scan.  This can be done by 
> looking at the filter string, which in our case begins with "FTMS ..." 
> or "ITMS ...".  I'd like to encode the mass analyzer as a cvParam in 
> <scan>, so clients don't have to parse the filter string each time:
>
>  
>
> <scan instrumentRef="LTQ-FT">
>
>   <cvParam cvLabel="MS" accession="MS:1000512" name="filter string" 
> value="FTMS + c ESI Full ms [ 400.00-1800.00]"/>
>
>   <cvParam cvLabel="MS" accession="MS:1000xxx" name="FT-ICR" value=""/>
>
>     ...
>
> </scan>
>
>  
>
> <scan instrumentRef="LTQ-FT">
>
>   <cvParam cvLabel="MS" accession="MS:1000512" name="filter string" 
> value="ITMS + c ESI Full ms [ 400.00-1800.00]"/>
>
>   <cvParam cvLabel="MS" accession="MS:1000xxx" name="ion trap" value=""/>
>
>     ...
>
> </scan>
>
>  
>
> Question #1:  Is there any problem with this?  It seems to be okay 
> according to the spec...
>
>  
>
> Question #2:  Should hybrid instruments be encoded as below, with two 
> "mass analyzer" cvParams, or as two <instrument> elements?
>
>  
>
> <instrument id="LTQ-FT">
>
>   <cvParam cvLabel="MS" accession="MS:1000xxx" name="LTQ-FT" value=""/>
>
>   <componentList count="3">
>
>     ...
>
>     <analyzer order="2">
>
>       <cvParam cvLabel="MS" accession="MS:1000xxx" name="FT-ICR" 
> value=""/>
>
>       <cvParam cvLabel="MS" accession="MS:1000xxx" name="ion trap" 
> value=""/>
>
>     </analyzer>
>
>   ...
>
>   </componentList>
>
> </instrument>
>
>  
>
> I would very much prefer to write everything as above. 
>
>  
>
> I realize that if a hybrid instrument is encoded as two <instrument> 
> elements, and since <scan> has an instrumentRef, one may look up the 
> mass analyzer as follows:
>
> <scan> -> instrumentRef -> <instrument> -> componentList -> analyzer 
> -> cvParam("mass analyzer")
>
> But I think 5 levels of indirection is a bit cumbersome...
>
>  
>
>  
>
> Darren
>
>  
>
>  
>
>

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

[Kessner, D. E. <Dar...@cs...>]

> 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



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.

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

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

[Darren K. <dke...@ya...>]

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

But you're right that I'm absolutely biased ;) (For the rest of you on 
the list -- one of the tools I wrote for our lab, msprefix, does 
precursor recalculation for FT data sets).

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.


Darren

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

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

[Kessner, D. E. <Dar...@cs...>]

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.

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
>   

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

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

[Kessner, D. E. <Dar...@cs...>]

That's a good point, Rune.

Using a virtual instrument for each possible combination of variables
won't scale well -- you would have to create an <instrument> and a
unique <instrument> 'id' for each combination of components that can
vary on your instrument.


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Rune
Schjellerup Philosof
Sent: Tuesday, March 04, 2008 2:03 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] cvParam for mass analyzer in <scan>

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