From: Rune S. P. <mai...@ph...> - 2008-02-25 08:34:43
|
Why is it that your tools use the thermo scan number? Do you have some automated analysis of the thermo raw files that you cannot do on a mzML raw file? -- Rune Kessner, Darren E. wrote: > It's not that we need to know the scan number at file open, it's that we > *do* know the scan number. > > We have command line tools that will extract various things (scan > metadata, full scan binary data) by scanNumber. Being able to do this > is very important, since we use this in quality control scripts, > debugging other tools, and automated testing of code modules. > > The general point is that in any particular case, we don't want it to be > significantly less efficient to find and extract information from an > mzML file than it is from a RAW or mzXML (or any other) file. > > > Darren > > > > -----Original Message----- > From: psi...@li... > [mailto:psi...@li...] On Behalf Of > Matthew Chambers > Sent: Friday, February 22, 2008 10:01 AM > To: Mass spectrometry standard development > Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition > number > > Why do you need to know the scan number at file open time? You don't > even know if it's a Thermo spectrum (i.e. that the scan number actually > corresponds to some element in the native instrument data). What's wrong > > with using the 0-based index? Once you've accessed a scan to figure out > what kind it is, you can also get the native scan number via the > acquisition section (assuming you load all the spectrum-level metadata > at the same time for a given spectrum, which is easy and fast). > > Your externalID is better, but still not really sensible if the spectrum > > being indexed is a sum/average of multiple native scans. > > -Matt > > > Kessner, Darren E. wrote: > >> Ooh -- I like that even less... >> >> Generating a new scanNumber map requires hitting the file at the >> location of each <spectrum>, which can take a significant amount of >> > time > >> when there are 10k scans in a file. The point of including an index >> > is > >> so that this doesn't have to be done on file open. >> >> We have existing useful tools that rely on scanNumber indexing in >> > mzXML, > >> so I don't think this facility should be lost in mzML. >> >> >> Darren >> >> >> >> -----Original Message----- >> From: psi...@li... >> [mailto:psi...@li...] On Behalf Of >> Matthew Chambers >> Sent: Friday, February 22, 2008 9:44 AM >> To: Mass spectrometry standard development >> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition >> number >> >> Ugh. I don't think there should be any reference to acquisitions in >> > the > >> index; there is no 1:1 mapping and mapping to the first of the >> acquisitions is counter-intuitive. The scanNumber attribute in the >> > index > >> offsets should be replaced by the 0-based index (now that there is an >> index attribute on the spectrum) and if you want to refer to a Thermo >> spectrum by its original scan number, that will somehow have to be >> parsed from the spectrum id attribute or you can generate the >> index->scan mapping when reading and/or generating the file index. >> >> -Matt >> >> >> Kessner, Darren E. wrote: >> >> >>> Hi all, >>> >>> >>> >>> Please correct me if I'm wrong, but I believe the consensus now is to >>> > > >>> encode the Thermo scanNumber as the (first) acquisition number: >>> >>> >>> >>> <spectrum id="S17" index="0" msLevel="1" arrayLength="1313"> >>> >>> ... >>> <spectrumDescription> >>> >>> <acquisitionList count="1"> >>> >>> <acquisition number="17" spectrumRef="?" >>> sourceFileRef="?"/> >>> >>> </acquisitionList> >>> >>> ... >>> >>> </spectrumDescription> >>> >>> ... >>> >>> </spectrum> >>> >>> >>> >>> However, when the mzML is indexed, we still have <offset> entries >>> > with > >>> >>> >> >> >>> attribute 'scanNumber': >>> >>> >>> >>> <index> >>> >>> <offset id="S17" scanNumber="17">4826</offset> >>> >>> </index> >>> >>> >>> >>> Shall we make this: >>> >>> <offset id="S17" acquisitionNumber="17">4826</offset> >>> >>> and assume it refers to the *first* acquisition number in the >>> <acquisitionList> ? >>> >>> >>> >>> The use case is the same -- for efficient random access by Thermo >>> scanNumber we need this in the <index>. >>> >>> >>> >>> Previously I had also proposed including the 0-based index, which was >>> > > >>> deemed unnecessary (and I agree), but someone may want it now for >>> consistency and/or validation? >>> >>> <offset id="S17" index="0" >>> >>> >> acquisitionNumber="17">4826</offset> >> >> >>> >>> >>> >>> >>> Darren >>> >>> >>> >>> >>> >>> Darren Kessner >>> >>> Scientific Programmer >>> >>> Dar...@cs... <mailto: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. >>> >>> >>> > ------------------------------------------------------------------------ > >> >> >>> >>> > ------------------------------------------------------------------------ > >> - >> >> >>> 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 >>> >>> >>> >> > ------------------------------------------------------------------------ > >> - >> 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 >> 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 >> >> >> > > ------------------------------------------------------------------------ > - > 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 > 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 > |