psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

[Eric D. <ede...@sy...>]

Hi Darren, in order to close this thread, would you provide a compelling
example of what you'd like to see?

One thing we'd like to avoid is having "more than one way to do it". I'm
slightly nervous that allowing this capability would allow one to
annotate the function of some software in two different ways.  So now we
have in our examples:

<softwareList count="1">
  <software id="Xcalibur">
    <softwareParam cvLabel="MS" accession="MS:1000532" name="Xcalibur"
version="2.0.5"/>
  </software>
</softwareList>
<dataProcessingList count="1">
  <dataProcessing id="Xcalibur Processing" softwareRef="Xcalibur">
    <processingMethod order="1">
	<cvParam cvLabel="MS" accession="MS:1000033" name="deisotoping"
value="false"/>
	<cvParam cvLabel="MS" accession="MS:1000034" name="charge
deconvolution" value="false"/>
	<cvParam cvLabel="MS" accession="MS:1000035" name="peak picking"
value="true"/>
    </processingMethod>
  </dataProcessing>
</dataProcessingList>

What would you like to see transformed from mzXML:
<software type="acquisition"
          name="Xcalibur"
       version="1.3 alpha 8"/>
?

Maybe:

<softwareList count="1">
  <software id="Xcalibur">
    <softwareParam cvLabel="MS" accession="MS:1000532" name="Xcalibur"
version="2.0.5"/>
  </software>
</softwareList>
<dataProcessingList count="1">
  <dataProcessing id="Xcalibur Processing" softwareRef="Xcalibur">
    <processingMethod order="1">
	<cvParam cvLabel="MS" accession="MS:100xxxx" name="data
acquisition" value="false"/>
    </processingMethod>
  </dataProcessing>
</dataProcessingList>


Thanks,
Eric





> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Darren Kessner
> Sent: Tuesday, February 19, 2008 7:35 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
attribute
> 
> Actually, my comment about dataProcessing was limited to the uses of
the
> software during processing.
> 
> I think the addition of the cvParam for the general software type is
> useful (and in fact I'm using it in the latest msdata code).  If
nothing
> else, it provides for a much more straightfoward translation from
> mzXML.  Without it, encoding the mzXML software type is much more
> awkward.
> 
> 
> Darren
> 
> 
> On Tue, 19 Feb 2008 4:20 am, Lennart Martens wrote:
> > Hi Eric, hi PSI MS Enthousiast,
> >
> >
> >>  I read that this discussion was deemed moot. Play-by-play below.
> >>  Lennart, should we remove your new cvParam entry location to
remove
> >>  temptation to use it, or leave it in?
> >
> > I'll schedule it for removal, and will do so in the version I'll try
to
> > build after the phone con tonight (or this morning :)).
> >
> >
> > Cheers,
> >
> > lnnrt.
> >
> >
------------------------------------------------------------------------
> -
> > 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
> 
> Darren
> 
>
------------------------------------------------------------------------
-
> 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] DTA to mzML conversion

[Eric D. <ede...@sy...>]

Okay, I think it is quite reasonable to support this then.  So currently
we have:

<ionSelection>
  <cvParam cvLabel="MS" accession="MS:1000040" name="m/z"
value="445.34"/>
  <cvParam cvLabel="MS" accession="MS:1000041" name="charge state"
value="2"/>
</ionSelection>

Or 

<ionSelection>
  <cvParam cvLabel="MS" accession="MS:1000040" name="m/z"
value="445.34"/>
</ionSelection>

How about we support this:

<ionSelection>
  <cvParam cvLabel="MS" accession="MS:1000040" name="m/z"
value="445.34"/>
  <cvParam cvLabel="MS" accession="MS:100xxxx" name="possible charge
state" value="2"/>
  <cvParam cvLabel="MS" accession="MS:100xxxx" name="possible charge
state" value="3"/>
</ionSelection>

So this means adding a term for a possible charge state instead of a
known charge state and then allowing multiple cvParams.

I would say the validation rule is that only 0-1 "charge state" is
allowed, or alternatively 0-N "multiple charge state" is allowed.

Seem okay?

Thanks,
Eric





> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Coleman, Michael
> Sent: Tuesday, February 19, 2008 7:59 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] DTA to mzML conversion
> 
> To clarify, I think having the converter be able to keep or discard
the
> multiple charge information is fine.  What I'm against is *forcing*
this
> information to be discarded, which is how I interpret option (a)
below.
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: psi...@li...
> > [mailto:psi...@li...] On
> > Behalf Of Matthew Chambers
> > Sent: Tuesday, February 19, 2008 9:44 AM
> > To: Mass spectrometry standard development
> > Subject: Re: [Psidev-ms-dev] DTA to mzML conversion
> >
> >
> > Eh, I think we should leave it up to the implementor of the
> > converter.
> > Ideally the converter would be configurable to either keep the
charge
> > state information or discard it. In either case, the scan
> > number would
> > only appear as a single element.
> >
> > -Matt
> >
> >
> > Coleman, Michael wrote:
> > > I'm strongly in favor of (b), i.e., keeping that charge state
> > > information.  If the instrument software, or some other software
> > > upstream of the search engine has reason to believe that
> > the charge for
> > > a particular spectrum is +2 or +3 but not +1, or +2 but not
> > +1 or +3, or
> > > whatever, the search engine ought to be able to make use of this
> > > information.
> > >
> > > As a practical matter, the spectrum format we currently use
> > here (ms2,
> > > very similar to dta) efficiently encodes this information,
> > so not having
> > > it in mzML would be at least a minor argument for not
> > converting.  (We
> > > could, of course, simply duplicate the entire spectrum in
> > this case, but
> > > this would further bloat the output, and still lose some important
> > > information.)
> > >
> > > Mike
> > >
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: psi...@li...
> > >> [mailto:psi...@li...] On
> > >> Behalf Of Fredrik Levander
> > >> Sent: Tuesday, February 19, 2008 9:04 AM
> > >> To: Mass spectrometry standard development
> > >> Subject: Re: [Psidev-ms-dev] DTA to mzML conversion
> > >>
> > >>
> > >> Hi dta fans,
> > >>
> > >> I agree completely with 1 and 2. For 3 (several possible
> > >> charge states),
> > >> there seems to be two possibilities:
> > >> a) Do not write the chargestate at all into the mzML in
> > cases where
> > >> there are multiple guesses.
> > >> b) Put all the proposed values into one precursor. See line
> > >> 206-207 at:
> > >> http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/ADH0
> > >> 71030_002.mzML?rev=26
> > >>
> > >> Anyone else who would prefer either of a or b? At least
> > some search
> > >> engines would try both 2+ and 3+ if there is no charge
> > state given in
> > >> the file, so maybe solution a is better? Or does b have
advantages?
> > >>
> > >> Fredrik
> > >>
> > >> Eric Deutsch wrote:
> > >>
> > >>> Hi everyone, regarding list dta to mzML conversion, here are my
> > >>> thoughts:
> > >>>
> > >>> 1) The current rule is that scanNumbers must be unique
> > >>>
> > >> within a file and
> > >>
> > >>> always increasing, although not necessarily sequentially.
> > >>>
> > >> IDs must be
> > >>
> > >>> unique within a file. I don't think should change for
> > >>>
> > >> conversion from
> > >>
> > >>> dta.
> > >>>
> > >>> 2) I would only encode the spectrum once, since as you say
> > >>>
> > >> it is just
> > >>
> > >>> one spectrum.
> > >>>
> > >>> 3) I don't even see why you need two precursors. When we
> > >>>
> > >> convert dta to
> > >>
> > >>> mzXML, duplicates were dropped and the actual observed
> > >>>
> > >> precursor mass
> > >>
> > >>> was put in the mzXML. Thus you are "losing" the
> > information that the
> > >>> spectrum could be charge 2 or 3. However, this information
> > >>>
> > >> was guessed
> > >>
> > >>> in the first place, and most software I know that extracts
> > >>>
> > >> a spectrum
> > >>
> > >>> with no charge information will apply some rules to decide on
what
> > >>> charges to search. So, I suggest that the conversion from
> > >>>
> > >> dta to mzML is
> > >>
> > >>> just the reverse of mzML to dta. One spectrum per scan. If
> > >>>
> > >> only 1 charge
> > >>
> > >>> (dta file) is provided, encode it at the user's discretion.
> > >>>
> > >> If more than
> > >>
> > >>> 1 charge (dta file) is provided, encode the spectrum
> > >>>
> > >> without any charge
> > >>
> > >>> information. For LCQ data, it would probably be reasonable
> > >>>
> > >> to not encode
> > >>
> > >>> *any* charge information in the mzML file at all. Because
> > it doesn't
> > >>> come with any in the first place.
> > >>>
> > >>> We will be adding the functionality for multiple precursors
> > >>>
> > >> anyway for
> > >>
> > >>> the case when you have multiple peaks in your selection
> > >>>
> > >> window as seen,
> > >>
> > >>> e.g., in an orbitrap. I suppose there's no reason you
> > couldn't take
> > >>> advantage of that to encode both the 2+ and 3+ although I
wouldn't
> > >>> recommend it.
> > >>>
> > >>> Eric
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: psi...@li...
> > >>>>
> > >>>>
> > >>> [mailto:psidev-ms-dev-
> > >>>
> > >>>
> > >>>> bo...@li...] On Behalf Of Fredrik Levander
> > >>>> Sent: Thursday, February 14, 2008 9:55 AM
> > >>>> To: Mass spectrometry standard development
> > >>>> Subject: Re: [Psidev-ms-dev] DTA to mzML conversion
> > >>>>
> > >>>> Hi Matt and Rune,
> > >>>>
> > >>>> Thanks for the comments. I agree that the important
> > >>>>
> > >> information is the
> > >>
> > >>>> scan number, since this is what you would like to look up
> > >>>>
> > >> in the raw
> > >>
> > >>>> data file. And it doesn't make much sense to have the
> > scan repeated
> > >>>> twice in the file, so I think we'll go for solution 2
> > and just keep
> > >>>>
> > >>>>
> > >>> the
> > >>>
> > >>>
> > >>>> sourceFileRef to one of the files.
> > >>>> However, since we do have unique spectrum ids there should
> > >>>>
> > >> not be any
> > >>
> > >>>> real need to stick to the unique scan number requirement
> > >>>>
> > >> from what I
> > >>
> > >>>>
> > >>>>
> > >>> got
> > >>>
> > >>>
> > >>>> from the indexing discussion, even if it is still in the
> > specs (?).
> > >>>> Couldn't there be cases when data is collected in
> > >>>>
> > >> different channels
> > >>
> > >>>> where the scan numbers are the same in different channels?
> > >>>>
> > >>>> Regards
> > >>>>
> > >>>> Fredrik
> > >>>>
> > >>>> Matthew Chambers skrev:
> > >>>>
> > >>>>
> > >>>>> Hi Fredrik,
> > >>>>>
> > >>>>> Our group has a converter that does this conversion (to mzXML
or
> > >>>>>
> > >>>>>
> > >>> mzData
> > >>>
> > >>>
> > >>>>> currently, not yet mzML, but they all have the same uniqueness
> > >>>>> constraints on scan numbers and they all support multiple
> > >>>>>
> > >> precursors
> > >>
> > >>>>>
> > >>>>>
> > >>> at
> > >>>
> > >>>
> > >>>>> least in theory); we went with solution 2 because solution 1
is
> > >>>>>
> > >>>>>
> > >>> invalid
> > >>>
> > >>>
> > >>>>> for all the XML formats (i.e. it would need a schema
> > >>>>>
> > >> change and that
> > >>
> > >>>>> change isn't likely to happen, whereas multiple
> > >>>>>
> > >> sourceFileRefs would
> > >>
> > >>>>>
> > >>>>>
> > >>> be
> > >>>
> > >>>
> > >>>>> understandable). As I understand it, sourceFileRef is optional
> > >>>>> ("<xs:attribute name="sourceFileRef" type="xs:anyURI"
> > >>>>>
> > >>>>>
> > >>> use="optional">"),
> > >>>
> > >>>
> > >>>>> so if you can't or don't want to encode it correctly, just
don't
> > >>>>>
> > >>>>>
> > >>> include
> > >>>
> > >>>
> > >>>>> it. Our converter doesn't even bother to include the
> > >>>>>
> > >> sourceFileRefs
> > >>
> > >>>>>
> > >>>>>
> > >>> to
> > >>>
> > >>>
> > >>>>> the DTAs, it's not helpful information IMO. As long as the
> > >>>>>
> > >>>>>
> > >>> conversion is
> > >>>
> > >>>
> > >>>>> done without data loss, get it over with and then have
> > >>>>>
> > >> mercy on your
> > >>
> > >>>>> filesystem by deleting the DTAs. ;)
> > >>>>>
> > >>>>> -Matt
> > >>>>>
> > >>>>>
> > >>>>> Fredrik Levander wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Hi All,
> > >>>>>>
> > >>>>>> In the Proteios platform we're including converters from
> > >>>>>>
> > >> some peak
> > >>
> > >>>>>>
> > >>>>>>
> > >>> list
> > >>>
> > >>>
> > >>>>>> formats to mzData, and now also to mzML. It is clearly
> > >>>>>>
> > >> not optimal
> > >>
> > >>>>>>
> > >>>>>>
> > >>> with
> > >>>
> > >>>
> > >>>>>> such conversion since instrument settings etcetera are lost.
> > >>>>>>
> > >>>>>>
> > >>> However, I
> > >>>
> > >>>
> > >>>>>> guess there will be need for such converters if
> > someone wants to
> > >>>>>>
> > >>>>>>
> > >>> use
> > >>>
> > >>>
> > >>>>>> their old instruments with manufacturer peak picking
> > algorithms.
> > >>>>>>
> > >>>>>> There are sample files generated from DTAs and
> > ProteinLynx by the
> > >>>>>> converters (0.99.1) at:
> > >>>>>> http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML
> > >>>>>>
> > >>>>>> The converters will be part of the new release of the
Proteios
> > >>>>>>
> > >>>>>>
> > >>> Software
> > >>>
> > >>>
> > >>>>>> Environment, but if anyone would like to try them with
> > >>>>>>
> > >> their files,
> > >>
> > >>>>>> there is a standalone package (mzMLconverters.zip) at
> > the address
> > >>>>>>
> > >>>>>>
> > >>> above
> > >>>
> > >>>
> > >>>>>> which should work under Windows/Linux/OSX with Java 1.5
> > >>>>>>
> > >> or higher.
> > >>
> > >>>>>> Please notice that the output files are not schematically
valid
> > >>>>>>
> > >>>>>>
> > >>> since
> > >>>
> > >>>
> > >>>>>> some terms are still missing in the CV.
> > >>>>>>
> > >>>>>> For the conversion of multiple DTA files to one mzML
> > >>>>>>
> > >> file there is
> > >>
> > >>>>>>
> > >>>>>>
> > >>> a
> > >>>
> > >>>
> > >>>>>> small problem which is related to how lcq_dta generates
> > >>>>>>
> > >> dta files:
> > >>
> > >>>>>>
> > >>>>>>
> > >>> If
> > >>>
> > >>>
> > >>>>>> the charge state of the precursor can not be determined,
> > >>>>>>
> > >> a spectrum
> > >>
> > >>>>>>
> > >>>>>>
> > >>> can
> > >>>
> > >>>
> > >>>>>> result in two DTA files which are identical apart from the
> > >>>>>>
> > >>>>>>
> > >>> precursor.
> > >>>
> > >>>
> > >>>>>> There are two solutions on how to handle this:
> > >>>>>> 1) Two spectra, with the same scanNumber but different
> > >>>>>>
> > >> spectrum Ids
> > >>
> > >>>>>>
> > >>>>>>
> > >>>> (The
> > >>>>
> > >>>>
> > >>>>>> solution used by the current converter)
> > >>>>>> 2) One spectrum, two precursors. However, this will
> > not work with
> > >>>>>>
> > >>>>>>
> > >>> the
> > >>>
> > >>>
> > >>>>>> current schema since there can only be one sourceFileRef for
a
> > >>>>>>
> > >>>>>>
> > >>>> spectrum.
> > >>>>
> > >>>>
> > >>>>>> Do you all think solution 1 is fine, or is there a
> > >>>>>>
> > >> better solution?
> > >>
> > >>>>>> Solution 2 seems to need schema changes.
> > >>>>>> Other comments are also welcome
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>
> > >>>>>> Fredrik
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >> --------------------------------------------------------------
> > >> ---------
> > >>
> > >>>
> > >>>
> > >>>> --
> > >>>>
> > >>>>
> > >>>>>> 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
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >> --------------------------------------------------------------
> > >> ----------
> > >>
> > >>> -
> > >>>
> > >>>
> > >>>> 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
> > >>>
> > >>>
> > >> --------------------------------------------------------------
> > >> -----------
> > >> 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
> > >
> > >
> >
> > --------------------------------------------------------------
> > -----------
> > 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

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

I considered the fleshed out XML-style identifier, but IMO it's too 
verbose to go into the index. What we really need is an external id that 
can fit in a single attribute, and of course that's going to depend on 
convention. I agree it's not pretty, but it can be well-defined and 
validated (just not schematically). The convention would also be more in 
line with the CV paradigm (compared to each component of the identifier 
having a separate, custom-named attribute) because the conventions could 
be defined in the CV. The schematic validation for the custom-named 
attributes could be done, but it would be tricky and confusing (i.e. no 
mixing and matching from different id schemes, if you use part of a 
scheme, you must use all of it, etc.).

The idea Darren just posted is better in that it relies on convention 
but defines (part of) the convention in the file itself. However, unless 
it was carefully implemented and incorporated into the semantic 
validator, it would allow people to specify the id only partially (i.e. 
sample, period, and cycle, but no experiment). The same is true of my 
suggestion too, though, so that's not really an issue. The semantic 
validator would need to be modified either way.

-Matt

Joshua Tasman wrote:
> Thanks, Darren.  Your version would work for Thermo, but not for other vendor schemes that doesn't have a flat scalar index for denoting scans.  Others have various "coordinate systems" to determine each scan, such as requiring 'cycle', 'period', 'method', 'scan' (off the top of my head, maybe slightly different) so you'd need something like 'externalIDTypeAccession1', 'externalIDTypeAccession2', 'externalIDTypeAccession3'...
>
> Ah-- but my "fixed attributes" propose requires an indexedmzXML schema rev when a new coordinate system is introduced.  Can anyone out there think of a way to flexibly use varying numbers of accessions without taking up too much space at the index?  I'm back to thinking you'd need a "nativeScanRef" subelement with unbounded number of cvParams, but this would be pretty big.  Maybe that's just what's needed for this.
>
> Josh
>
> Kessner, Darren E. wrote:
>   
>> I'm fine with that, Josh.
>>
>> Here's another idea, to make use of the existing vocabulary terms:
>>
>> <index>
>>
>>   <offset id="S19" externalID="19" externalIDTypeAccession="MS:1000532"
>> externalIDTypeName="Xcalibur" >4826</offset>
>>
>> ...
>>
>> </index>
>>
>>
>> Darren
>>
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of Joshua
>> Tasman
>> Sent: Monday, February 25, 2008 12:21 PM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
>> number
>>
>> Darren and Matt:
>>
>> Thinking about it-- why not just have a slew of optional named
>> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
>> "MassLynxPeriod", 
>> "AnalystCycle", etc.?  Less elegant, but should do the trick for fast
>> index parsing, and make me happy by avoiding a convention-based string
>> for each vendor and keeping it human readable?  I'd propose that if, in
>> a specific file, these are used in the index, they should be enumerated
>> more fully in the <spectrum> with cvParams, as previously suggested.
>>
>> Josh
>> 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
>
>   

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

[Joshua T. <jt...@sy...>]

I'm fine with nativeID.

Kessner, Darren E. wrote:
> I'd vote for idNative or nativeID, since "scan" may not always apply.
> 
> Darren
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Joshua
> Tasman
> Sent: Monday, February 25, 2008 12:54 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
> number
> 
> Good thinking.  As long as all parser authors (me, you and Matt?) are on
> board with this, this seems like a good pragmatic solution (and I assume
> Matt is, since he first proposed the "cooridinate string" idea).
> 
> (And, I'd suggest renaming "externalID" to "nativeScanID", or something
> similar, to be more specific.)
> 
> Josh
> 
> 
> Kessner, Darren E. wrote:
>> Sorry -- that didn't make sense.  This is more what I had in mind:
>>
>> <index>
>>    <externalIDTypeList count="2">
>>       <cvParam .../>
>>       <cvParam .../>
>>    </externalIDTypeList>
>>    ...
>>    <offset id="S19" externalID="(19,123)">4826</offset>
>>    ...
>> </index>
>>
>>
>> Darren
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of
> Joshua
>> Tasman
>> Sent: Monday, February 25, 2008 12:41 PM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
>> number
>>
>> Thanks, Darren.  Your version would work for Thermo, but not for other
>> vendor schemes that doesn't have a flat scalar index for denoting
> scans.
>> Others have various "coordinate systems" to determine each scan, such
> as
>> requiring 'cycle', 'period', 'method', 'scan' (off the top of my head,
>> maybe slightly different) so you'd need something like
>> 'externalIDTypeAccession1', 'externalIDTypeAccession2',
>> 'externalIDTypeAccession3'...
>>
>> Ah-- but my "fixed attributes" propose requires an indexedmzXML schema
>> rev when a new coordinate system is introduced.  Can anyone out there
>> think of a way to flexibly use varying numbers of accessions without
>> taking up too much space at the index?  I'm back to thinking you'd
> need
>> a "nativeScanRef" subelement with unbounded number of cvParams, but
> this
>> would be pretty big.  Maybe that's just what's needed for this.
>>
>> Josh
>>
>> Kessner, Darren E. wrote:
>>> I'm fine with that, Josh.
>>>
>>> Here's another idea, to make use of the existing vocabulary terms:
>>>
>>> <index>
>>>
>>>   <offset id="S19" externalID="19"
>> externalIDTypeAccession="MS:1000532"
>>> externalIDTypeName="Xcalibur" >4826</offset>
>>>
>>> ...
>>>
>>> </index>
>>>
>>>
>>> Darren
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: psi...@li...
>>> [mailto:psi...@li...] On Behalf Of
>> Joshua
>>> Tasman
>>> Sent: Monday, February 25, 2008 12:21 PM
>>> To: Mass spectrometry standard development
>>> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
>>> number
>>>
>>> Darren and Matt:
>>>
>>> Thinking about it-- why not just have a slew of optional named
>>> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
>>> "MassLynxPeriod", 
>>> "AnalystCycle", etc.?  Less elegant, but should do the trick for fast
>>> index parsing, and make me happy by avoiding a convention-based
> string
>>> for each vendor and keeping it human readable?  I'd propose that if,
>> in
>>> a specific file, these are used in the index, they should be
>> enumerated
>>> more fully in the <spectrum> with cvParams, as previously suggested.
>>>
>>> Josh
>>> 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

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

I'd vote for idNative or nativeID, since "scan" may not always apply.

Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Monday, February 25, 2008 12:54 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
number

Good thinking.  As long as all parser authors (me, you and Matt?) are on
board with this, this seems like a good pragmatic solution (and I assume
Matt is, since he first proposed the "cooridinate string" idea).

(And, I'd suggest renaming "externalID" to "nativeScanID", or something
similar, to be more specific.)

Josh


Kessner, Darren E. wrote:
> Sorry -- that didn't make sense.  This is more what I had in mind:
> 
> <index>
>    <externalIDTypeList count="2">
>       <cvParam .../>
>       <cvParam .../>
>    </externalIDTypeList>
>    ...
>    <offset id="S19" externalID="(19,123)">4826</offset>
>    ...
> </index>
> 
> 
> Darren
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
Joshua
> Tasman
> Sent: Monday, February 25, 2008 12:41 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
> number
> 
> Thanks, Darren.  Your version would work for Thermo, but not for other
> vendor schemes that doesn't have a flat scalar index for denoting
scans.
> Others have various "coordinate systems" to determine each scan, such
as
> requiring 'cycle', 'period', 'method', 'scan' (off the top of my head,
> maybe slightly different) so you'd need something like
> 'externalIDTypeAccession1', 'externalIDTypeAccession2',
> 'externalIDTypeAccession3'...
> 
> Ah-- but my "fixed attributes" propose requires an indexedmzXML schema
> rev when a new coordinate system is introduced.  Can anyone out there
> think of a way to flexibly use varying numbers of accessions without
> taking up too much space at the index?  I'm back to thinking you'd
need
> a "nativeScanRef" subelement with unbounded number of cvParams, but
this
> would be pretty big.  Maybe that's just what's needed for this.
> 
> Josh
> 
> Kessner, Darren E. wrote:
>> I'm fine with that, Josh.
>>
>> Here's another idea, to make use of the existing vocabulary terms:
>>
>> <index>
>>
>>   <offset id="S19" externalID="19"
> externalIDTypeAccession="MS:1000532"
>> externalIDTypeName="Xcalibur" >4826</offset>
>>
>> ...
>>
>> </index>
>>
>>
>> Darren
>>
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of
> Joshua
>> Tasman
>> Sent: Monday, February 25, 2008 12:21 PM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
>> number
>>
>> Darren and Matt:
>>
>> Thinking about it-- why not just have a slew of optional named
>> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
>> "MassLynxPeriod", 
>> "AnalystCycle", etc.?  Less elegant, but should do the trick for fast
>> index parsing, and make me happy by avoiding a convention-based
string
>> for each vendor and keeping it human readable?  I'd propose that if,
> in
>> a specific file, these are used in the index, they should be
> enumerated
>> more fully in the <spectrum> with cvParams, as previously suggested.
>>
>> Josh
>> 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.

Re: [Psidev-ms-dev] Unique scan numbers

[Joshua T. <jt...@sy...>]

Hi Fredrik,

Catching up: massWolf simply renumbers all scans starting with "1" in the mzXML output.  Like I said in a different post, we'll be adding a "native scan reference" to mzXML for each vendor software type.

Josh


Fredrik Levander wrote:
> Hi All,
> 
> In QTOF files from Waters with mixed MS1 and MS2 data we have several 
> parallel 'functions' with data being recorded into separate files. The 
> scan numbers are only unique within each function. In the raw data 
> folder we thus have several different spectra with the same scan number 
> (but different source files). When converting this into an mzML file it 
> would be good to keep the original scan numbers which are useful for 
> traceability, but to generate unique spectrum ids. I thus propose that 
> the requirement for unique scanNumbers within an mzML file is removed. 
> However, spectra should not be repeated within the file, so this would 
> NOT be applicable to the dta to mzML conversion use case.
> Would such a change generate problems for the readers?
> How is this solved in MassWolf?
> 
> 
> Regards
> 
> Fredrik
> 
> -------------------------------------------------------------------------
> 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] indexedmzML: scanNumber / acquisition number

[Joshua T. <jt...@sy...>]

Good thinking.  As long as all parser authors (me, you and Matt?) are on board with this, this seems like a good pragmatic solution (and I assume Matt is, since he first proposed the "cooridinate string" idea).

(And, I'd suggest renaming "externalID" to "nativeScanID", or something similar, to be more specific.)

Josh


Kessner, Darren E. wrote:
> Sorry -- that didn't make sense.  This is more what I had in mind:
> 
> <index>
>    <externalIDTypeList count="2">
>       <cvParam .../>
>       <cvParam .../>
>    </externalIDTypeList>
>    ...
>    <offset id="S19" externalID="(19,123)">4826</offset>
>    ...
> </index>
> 
> 
> Darren
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Joshua
> Tasman
> Sent: Monday, February 25, 2008 12:41 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
> number
> 
> Thanks, Darren.  Your version would work for Thermo, but not for other
> vendor schemes that doesn't have a flat scalar index for denoting scans.
> Others have various "coordinate systems" to determine each scan, such as
> requiring 'cycle', 'period', 'method', 'scan' (off the top of my head,
> maybe slightly different) so you'd need something like
> 'externalIDTypeAccession1', 'externalIDTypeAccession2',
> 'externalIDTypeAccession3'...
> 
> Ah-- but my "fixed attributes" propose requires an indexedmzXML schema
> rev when a new coordinate system is introduced.  Can anyone out there
> think of a way to flexibly use varying numbers of accessions without
> taking up too much space at the index?  I'm back to thinking you'd need
> a "nativeScanRef" subelement with unbounded number of cvParams, but this
> would be pretty big.  Maybe that's just what's needed for this.
> 
> Josh
> 
> Kessner, Darren E. wrote:
>> I'm fine with that, Josh.
>>
>> Here's another idea, to make use of the existing vocabulary terms:
>>
>> <index>
>>
>>   <offset id="S19" externalID="19"
> externalIDTypeAccession="MS:1000532"
>> externalIDTypeName="Xcalibur" >4826</offset>
>>
>> ...
>>
>> </index>
>>
>>
>> Darren
>>
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of
> Joshua
>> Tasman
>> Sent: Monday, February 25, 2008 12:21 PM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
>> number
>>
>> Darren and Matt:
>>
>> Thinking about it-- why not just have a slew of optional named
>> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
>> "MassLynxPeriod", 
>> "AnalystCycle", etc.?  Less elegant, but should do the trick for fast
>> index parsing, and make me happy by avoiding a convention-based string
>> for each vendor and keeping it human readable?  I'd propose that if,
> in
>> a specific file, these are used in the index, they should be
> enumerated
>> more fully in the <spectrum> with cvParams, as previously suggested.
>>
>> Josh
>> 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

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

Sorry -- that didn't make sense.  This is more what I had in mind:

<index>
   <externalIDTypeList count="2">
      <cvParam .../>
      <cvParam .../>
   </externalIDTypeList>
   ...
   <offset id="S19" externalID="(19,123)">4826</offset>
   ...
</index>


Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Monday, February 25, 2008 12:41 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
number

Thanks, Darren.  Your version would work for Thermo, but not for other
vendor schemes that doesn't have a flat scalar index for denoting scans.
Others have various "coordinate systems" to determine each scan, such as
requiring 'cycle', 'period', 'method', 'scan' (off the top of my head,
maybe slightly different) so you'd need something like
'externalIDTypeAccession1', 'externalIDTypeAccession2',
'externalIDTypeAccession3'...

Ah-- but my "fixed attributes" propose requires an indexedmzXML schema
rev when a new coordinate system is introduced.  Can anyone out there
think of a way to flexibly use varying numbers of accessions without
taking up too much space at the index?  I'm back to thinking you'd need
a "nativeScanRef" subelement with unbounded number of cvParams, but this
would be pretty big.  Maybe that's just what's needed for this.

Josh

Kessner, Darren E. wrote:
> I'm fine with that, Josh.
> 
> Here's another idea, to make use of the existing vocabulary terms:
> 
> <index>
> 
>   <offset id="S19" externalID="19"
externalIDTypeAccession="MS:1000532"
> externalIDTypeName="Xcalibur" >4826</offset>
> 
> ...
> 
> </index>
> 
> 
> Darren
> 
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
Joshua
> Tasman
> Sent: Monday, February 25, 2008 12:21 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
> number
> 
> Darren and Matt:
> 
> Thinking about it-- why not just have a slew of optional named
> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
> "MassLynxPeriod", 
> "AnalystCycle", etc.?  Less elegant, but should do the trick for fast
> index parsing, and make me happy by avoiding a convention-based string
> for each vendor and keeping it human readable?  I'd propose that if,
in
> a specific file, these are used in the index, they should be
enumerated
> more fully in the <spectrum> with cvParams, as previously suggested.
> 
> Josh
> 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.

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

Does that information have to be included with each <offset>, or can it
be encoded once with the <index>?

<index externalIDTypeAccession1="cycle" externalIDTypeAccession2="scan">
   ...
   <offset id="S19" externalID="(19,123)">4826</offset>
   ...
</index>


Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Monday, February 25, 2008 12:41 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
number

Thanks, Darren.  Your version would work for Thermo, but not for other
vendor schemes that doesn't have a flat scalar index for denoting scans.
Others have various "coordinate systems" to determine each scan, such as
requiring 'cycle', 'period', 'method', 'scan' (off the top of my head,
maybe slightly different) so you'd need something like
'externalIDTypeAccession1', 'externalIDTypeAccession2',
'externalIDTypeAccession3'...

Ah-- but my "fixed attributes" propose requires an indexedmzXML schema
rev when a new coordinate system is introduced.  Can anyone out there
think of a way to flexibly use varying numbers of accessions without
taking up too much space at the index?  I'm back to thinking you'd need
a "nativeScanRef" subelement with unbounded number of cvParams, but this
would be pretty big.  Maybe that's just what's needed for this.

Josh

Kessner, Darren E. wrote:
> I'm fine with that, Josh.
> 
> Here's another idea, to make use of the existing vocabulary terms:
> 
> <index>
> 
>   <offset id="S19" externalID="19"
externalIDTypeAccession="MS:1000532"
> externalIDTypeName="Xcalibur" >4826</offset>
> 
> ...
> 
> </index>
> 
> 
> Darren
> 
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
Joshua
> Tasman
> Sent: Monday, February 25, 2008 12:21 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
> number
> 
> Darren and Matt:
> 
> Thinking about it-- why not just have a slew of optional named
> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
> "MassLynxPeriod", 
> "AnalystCycle", etc.?  Less elegant, but should do the trick for fast
> index parsing, and make me happy by avoiding a convention-based string
> for each vendor and keeping it human readable?  I'd propose that if,
in
> a specific file, these are used in the index, they should be
enumerated
> more fully in the <spectrum> with cvParams, as previously suggested.
> 
> Josh
> 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.

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

[Joshua T. <jt...@sy...>]

Thanks, Darren.  Your version would work for Thermo, but not for other vendor schemes that doesn't have a flat scalar index for denoting scans.  Others have various "coordinate systems" to determine each scan, such as requiring 'cycle', 'period', 'method', 'scan' (off the top of my head, maybe slightly different) so you'd need something like 'externalIDTypeAccession1', 'externalIDTypeAccession2', 'externalIDTypeAccession3'...

Ah-- but my "fixed attributes" propose requires an indexedmzXML schema rev when a new coordinate system is introduced.  Can anyone out there think of a way to flexibly use varying numbers of accessions without taking up too much space at the index?  I'm back to thinking you'd need a "nativeScanRef" subelement with unbounded number of cvParams, but this would be pretty big.  Maybe that's just what's needed for this.

Josh

Kessner, Darren E. wrote:
> I'm fine with that, Josh.
> 
> Here's another idea, to make use of the existing vocabulary terms:
> 
> <index>
> 
>   <offset id="S19" externalID="19" externalIDTypeAccession="MS:1000532"
> externalIDTypeName="Xcalibur" >4826</offset>
> 
> ...
> 
> </index>
> 
> 
> Darren
> 
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Joshua
> Tasman
> Sent: Monday, February 25, 2008 12:21 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
> number
> 
> Darren and Matt:
> 
> Thinking about it-- why not just have a slew of optional named
> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
> "MassLynxPeriod", 
> "AnalystCycle", etc.?  Less elegant, but should do the trick for fast
> index parsing, and make me happy by avoiding a convention-based string
> for each vendor and keeping it human readable?  I'd propose that if, in
> a specific file, these are used in the index, they should be enumerated
> more fully in the <spectrum> with cvParams, as previously suggested.
> 
> Josh
> 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] indexedmzML: scanNumber / acquisition number

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

I'm fine with that, Josh.

Here's another idea, to make use of the existing vocabulary terms:

<index>

  <offset id="S19" externalID="19" externalIDTypeAccession="MS:1000532"
externalIDTypeName="Xcalibur" >4826</offset>

...

</index>


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Monday, February 25, 2008 12:21 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
number

Darren and Matt:

Thinking about it-- why not just have a slew of optional named
attributes for the <index>, like: "XcaliburNum", "MassLynxCycle",
"MassLynxPeriod", 
"AnalystCycle", etc.?  Less elegant, but should do the trick for fast
index parsing, and make me happy by avoiding a convention-based string
for each vendor and keeping it human readable?  I'd propose that if, in
a specific file, these are used in the index, they should be enumerated
more fully in the <spectrum> with cvParams, as previously suggested.

Josh
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] indexedmzML: scanNumber / acquisition number

[Joshua T. <jt...@sy...>]

Darren and Matt:

Thinking about it-- why not just have a slew of optional named attributes for the <index>, like: "XcaliburNum", "MassLynxCycle", "MassLynxPeriod", 
"AnalystCycle", etc.?  Less elegant, but should do the trick for fast index parsing, and make me happy by avoiding a convention-based string for each vendor and keeping it human readable?  I'd propose that if, in a specific file, these are used in the index, they should be enumerated more fully in the <spectrum> with cvParams, as previously suggested.

Josh

Kessner, Darren E. wrote:
>> First off-- Can you guys (Matt, Darren) briefly summarize if this info
> is > actually needed at the index?  If not, I'd go for more detailed
> info in 
>> the <spectrum> element (like we're storing for everything else; see
> last 
>> paragraph.)
> 
> Yes, we really want to have a native unique identifier (scan number or
> equivalent) in the <index>.
> 
> I agree that more detailed information would be useful, and can be
> included in <spectrum>.
> 
> 
> 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] indexedmzML: scanNumber / acquisition number

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

> First off-- Can you guys (Matt, Darren) briefly summarize if this info
is > actually needed at the index?  If not, I'd go for more detailed
info in 
> the <spectrum> element (like we're storing for everything else; see
last 
> paragraph.)

Yes, we really want to have a native unique identifier (scan number or
equivalent) in the <index>.

I agree that more detailed information would be useful, and can be
included in <spectrum>.


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] indexedmzML: scanNumber / acquisition number

[Joshua T. <jt...@sy...>]

First off-- Can you guys (Matt, Darren) briefly summarize if this info is actually needed at the index?  If not, I'd go for more detailed info in the <spectrum> element (like we're storing for everything else; see last paragraph.)

We (ISB/SPC) also want to record what we're calling the "native scan reference" for each format as it's often important to go back to the vendor software for comparison, as Darren points out.  We want to be able to include information other formats with multidimensional axes (period, cycle, method, etc) as Matt has pointed out.  (This info will be added to an upcoming rev of mzXML, by the way.)

I too think this should be optional, but highly recommended to include in the mzML file.

I'd vote for something more detailed that Matt's last suggestion of a string with some fixed format, though.  If we're enumerating everything else, why come up with an ad-hoc solution based on convention here?  Could we not just add an optional "nativeScanRef" subelement with varying number of cvParams underneath it to clearly define "scanNum" in the Thermo case, "cycle", "period", etc for others, under <spectrum> or <spectrumDescription>?

-Josh


Kessner, Darren E. wrote:
>> 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?
> 
> It's because we use Thermo's Xcalibur tools to look at the RAW files,
> and the scan number is their unique identifier.  In particular, the
> Xcalibur Qual Browser is very nice for seeing and moving around the
> scans and chromatograms visually.  To be able to use this tool in
> conjunction with tools that we write, it's important to be able to treat
> the scan number as a "first class citizen".
> 
> Incidentally, the RAW files do have a lot of information that we
> couldn't save in mzXML, but we can now in mzML.  There is a lot of scan
> metadata that consists mostly of various temperatures and voltages of
> the instrument during each scan.  The actual name-value pairs stored
> seem to depend on both the instrument and software configuration.  I was
> thinking that this stuff could be stored in the <scan> element as
> userParams.  Note that the names are context sensitive (e.g. see below
> -- the value for "Life (hours):" depends on the section it's in, and
> yes, the colon is part of the name), so I think it would be difficult to
> encode these using the existing cvParam specification.  
> 
> The ideal would be to be able to write something like this:
> <statusLogEntry index="1" name="Source Voltage (kV):" value="3.86"/>
> <statusLogEntry index="2" name="Source Current (uA):" value="2.14"/>
> 
> With the existing mzML spec, I would encode everything in the name:
> <userParam name="StatusLog 1 Source Voltage (kV):" value="3.86"/>
> <userParam name="StatusLog 2 Source Current (uA):" value="2.14"/>
> 
> Here's a printout of this extra metadata for a single scan:
> 
> Status Log (148 entries, RT: 0.0235433):
> 0: API SOURCE 
> 1: Source Voltage (kV): 3.86
> 2: Source Current (uA): 2.14
> 3: Vaporizer Thermocouple OK: No
> 4: Vaporizer Temp (C): -62.87
> 5: Sheath Gas Flow Rate (): 6.00
> 6: Aux Gas Flow Rate(): 2.24
> 7: Sweep Gas Flow Rate(): 1.93
> 8: Capillary Temp OK: Yes
> 9: Capillary Voltage (V): 46.73
> 10: Capillary Temp (C): 199.92
> 11: Tube Lens Voltage (V): 135.38
> 12:  
> 13: VACUUM 
> 14: Vacuum OK: Yes
> 15: Ion Gauge Pressure OK: Yes
> 16: Ion Gauge Status: On
> 17: Ion Gauge (E-5 Torr): 0.83
> 18: Convectron Pressure OK: Yes
> 19: Convectron Gauge (Torr): 0.92
> 20:  
> 21: FT VACUUM 
> 22: FT Penning Pressure OK: Yes
> 23: FT Penning Gauge (E-10 Torr): 2.66
> 24: FT Pirani Gauge 1 (Torr): 0.78
> 25: FT Pirani Gauge 2 (Torr): 0.02
> 26:  
> 27: TURBO PUMP 
> 28: Status: Running
> 29: Life (hours): 4934
> 30: Speed (Hz): 800
> 31: Power (Watts): 66
> 32: Temperature (C): 56.00
> 33:  
> 34: FT TURBO PUMP 1 
> 35: Status: Running
> 36: Life (hours): 4782
> 37: Speed (Hz): 1000
> 38: Power (Watts): 11
> 39:  
> 40: FT TURBO PUMP 2 
> 41: Status: Running
> 42: Life (hours): 4173
> 43: Speed (Hz): 1001
> 44: Power (Watts): 17
> 45:  
> 46: ION OPTICS 
> 47: Multipole 00 Offset (V): -5.05
> 48: Intermultipole Lens 0 (V): -4.68
> 49: Multipole 0 Offset (V): -6.28
> 50: Intermultipole Lens 1 (V): -9.99
> 51: Gate Lens (V): -44.89
> 52: Multipole 1 Offset (V): -6.68
> 53: Multipole RF Amplitude (Vp-p, set point): 400.28
> 54: Front Lens (V): -6.81
> 55: Front Section (V): -8.99
> 56: Center Section (V): -12.40
> 57: Back Section (V): -7.16
> 58: Back Lens (V): -0.27
> 59: FT Multipole 1 Offset (V): -21.66
> 60: FT Intermultipole Lens 1 (V): -63.93
> 61: FT Multipole 2 Offset (V): -68.20
> 62: FT Intermultipole Lens 2 (V): -109.98
> 63: FT Multipole 3 Offset (V): -71.54
> 64: FT Multipole 1 RF Amplitude (Vp-p): 453.25
> 65: FT Multipole 2 and 3 RF Amplitude (Vp-p): 499.97
> 66:  
> 67: MAIN RF 
> 68: Standing Wave Ratio OK: Yes
> 69: Main RF Detected (V): -0.01
> 70: RF Detector Temp (C): 51.01
> 71: RF Generator Temp (C): 30.82
> 72:  
> 73: ION DETECTION SYSTEM 
> 74: Dynode Voltage (kV): -15.02
> 75: Multiplier 1 (V): -794.82
> 76: Multiplier 2 (V): -796.51
> 77:  
> 78: ECD 
> 79: Status: Not Connected
> 80: Heater Current (A): 0.00
> 81: Heater Voltage (V): 0.00
> 82: Heater Resistance (Ohm): 0.00
> 83: Target Gate Current (mA): 0.00
> 84: Actual Gate Current (mA): 0.00
> 85: Cathode Emission (mA): 0.00
> 86:  
> 87: IRMPD 
> 88: Status: Not Connected
> 89:  
> 90: POWER SUPPLIES 
> 91: +5V Supply Voltage (V): 4.99
> 92: -15V Supply Voltage (V): -15.10
> 93: +15V Supply Voltage (V): 15.03
> 94: -18V Supply Voltage (V): -17.95
> 95: +18V Supply Voltage (V): 18.22
> 96: +24V Supply Voltage (V): 23.87
> 97: -28V Supply Voltage (V): -28.19
> 98: +28V Supply Voltage (V): 28.26
> 99: +28V Supply Current (Amps): 1.34
> 100: +36V Supply Voltage (V): 36.23
> 101: -150V Supply Voltage (V): -148.78
> 102: +150V Supply Voltage (V): 148.61
> 103: -300V Supply Voltage (V): -295.76
> 104: +300V Supply Voltage (V): 294.84
> 105: Ambient Temp. (C): 40.06
> 106:  
> 107: FT POWER SUPPLIES 
> 108: FT ICB +15 Supply (V): 14.74
> 109: FT ICB -15 Supply (V): -14.66
> 110: FT ICB +10 Supply (V): 9.89
> 111: FT ICB -10 Supply (V): -9.89
> 112: FT ICB +5 Supply (V): 4.99
> 113: FT ICB +3.3 Supply (V): 3.46
> 114: FT ICB +2.5 Supply (V): 3.46
> 115: FT IOS +275 Supply (V): 276.71
> 116: FT IOS -275 Supply (V): -277.77
> 117: FT IOS +32 Supply (V): 29.46
> 118: FT IOS +15 Supply (V): 14.96
> 119: FT IOS -15 Supply (V): -15.26
> 120: FT IOS +5 Supply (V): 5.04
> 121: FT EA +32 Supply (V): 29.32
> 122: FT EA -32 Supply (V): -29.46
> 123: FT EA +15 Supply (V): 14.96
> 124: FT EA -15 Supply (V): -14.99
> 125: FT EA +5 Supply (V): 4.98
> 126: FT EA -5 Supply (V): -4.97
> 127: FT PA +5 Supply (V): 4.99
> 128: FT PA -5 Supply (V): -4.97
> 129: FT EA Temp. (C): 45.81
> 130: FT RF1 Amp. Temp. (C): 35.45
> 131: FT RF1 Amp. Temp. (C): 38.34
> 132:  
> 133: FT CRYO MONITOR 
> 134: Helium (%): 81.10
> 135: Nitrogen (%): 67.70
> 136:  
> 137: INSTRUMENT STATUS 
> 138: Instrument: On
> 139: Analysis: Acquiring
> 140:  
> 141: SYRINGE PUMP 
> 142: Status: Running
> 143: Flow Rate (uL/min): 2.00
> 144: Syringe Diameter (mm): 1.03
> 145:  
> 146: DIVERT VALVE 
> 147: Divert/Inject valve: Load
> 
> Trailer Extra (26 entries):
> 0: AGC: On
> 1: Micro Scan Count: 1
> 2: Ion Injection Time (ms): 80.464
> 3: Scan Segment: 1
> 4: Scan Event: 1
> 5: Master Index: 0
> 6: Elapsed Scan Time (sec): 0.90
> 7: API Source CID Energy: 0.00
> 8: Average Scan by Inst: No
> 9: Charge State: 2
> 10: Monoisotopic M/Z: 810.4163
> 11: MS2 Isolation Width: 0.0
> 12: MS3 Isolation Width: 0.0
> 13: MS4 Isolation Width: 0.0
> 14: MS5 Isolation Width: 0.0
> 15: MS6 Isolation Width: 0.0
> 16: MS7 Isolation Width: 0.0
> 17: MS8 Isolation Width: 0.0
> 18: MS9 Isolation Width: 0.0
> 19: MS10 Isolation Width: 0.0
> 20: FT Analyzer Settings: Patch=2 T=1e6 NSR
> 21: FT Analyzer Message: MAge=6d Est=0x2a
> 22: FT Resolution: 100000
> 23: Conversion Parameter I: 0.000
> 24: Conversion Parameter A: 107533.039
> 25: Conversion Parameter B: -347.451
> 
> 
> 
> 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] indexedmzML: scanNumber / acquisition number

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

I am thinking that this externalID, or something like it, is a good idea 
as a replacement for scanNumber (in addition to 0-based index). The type 
and format of the identifier would change depending on the context, but 
that type and format would be well-defined by the specification (or 
possibly CV) for that context. All contexts would share some common 
traits: certainly the identifier must be unique, and perhaps it should 
be sortable according to a context-dependent predicate. For the Thermo 
context, the identifier would be a positive integer and the predicate is 
trivial. For a WIFF-file context, the identifier could have a 
well-defined pattern like: "sample.period.cycle.experiment". The 
predicate to sort this is more complicated, but not difficult (a 
lexicographical sort won't cut it). For spectra from a 4000 Series 
source, the identifier could have a well-defined pattern like: 
"chromatogram_name.ms2_job_run.fraction.ms2_spectrum". The predicate for 
this would be similar to the previous one. I got the last two examples 
from the Protein Pilot documentation, I hope that's ok. :) Is it 
reasonable to assume that many, if not most (or all) vendor formats have 
some unique (per-run) identifier like these? MALDI spots could probably 
be handled like this too.

We could define these patterns with a cvParam, but then the ID couldn't 
be used as an attribute in the index, and I would lobby for that as much 
as Darren. It is a reasonable use case to go looking for a spectrum 
based on its original source identifier (and expect equal performance to 
looking for it by 0-based index).

-Matt


Kessner, Darren E. wrote:
> Good question.  Here are a couple choices:
>
> 1) Mandate that in the Thermo case, externalID has to be the scan
> number, and the cvParam "Thermo Scientific" has to be put in some
> particular location, so that readers may make this assumption.
>
> 2) Use scanNumber and make it optional.
>
> My feeling is that #1 may be dangerous, and #2 is ugly.  At the moment I
> don't really have a strong feeling one way or the other (or maybe its
> equally weak feelings...).
>
>
> Darren
>
>
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
> Matthew Chambers
> Sent: Friday, February 22, 2008 10:43 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
> number
>
> Going back to your externalID idea, it would need to be optional on a 
> per-offset basis in case some spectra were sums/averages and others not.
>
> On top of that, how would this use case (which our software uses as 
> well, so to some extent I'm playing devil's advocate here) handle a 
> RAW->mzML converter that doesn't write the externalIDs or writes 
> something else instead of the pure scan number?
>
> -Matt
>
>
> 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
>>
>>   
>>     
>
> ------------------------------------------------------------------------
> -
> 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
>
>   

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

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

It's because we use Thermo's Xcalibur tools to look at the RAW files,
and the scan number is their unique identifier.  In particular, the
Xcalibur Qual Browser is very nice for seeing and moving around the
scans and chromatograms visually.  To be able to use this tool in
conjunction with tools that we write, it's important to be able to treat
the scan number as a "first class citizen".

Incidentally, the RAW files do have a lot of information that we
couldn't save in mzXML, but we can now in mzML.  There is a lot of scan
metadata that consists mostly of various temperatures and voltages of
the instrument during each scan.  The actual name-value pairs stored
seem to depend on both the instrument and software configuration.  I was
thinking that this stuff could be stored in the <scan> element as
userParams.  Note that the names are context sensitive (e.g. see below
-- the value for "Life (hours):" depends on the section it's in, and
yes, the colon is part of the name), so I think it would be difficult to
encode these using the existing cvParam specification.  

The ideal would be to be able to write something like this:
<statusLogEntry index="1" name="Source Voltage (kV):" value="3.86"/>
<statusLogEntry index="2" name="Source Current (uA):" value="2.14"/>

With the existing mzML spec, I would encode everything in the name:
<userParam name="StatusLog 1 Source Voltage (kV):" value="3.86"/>
<userParam name="StatusLog 2 Source Current (uA):" value="2.14"/>

Here's a printout of this extra metadata for a single scan:

Status Log (148 entries, RT: 0.0235433):
0: API SOURCE 
1: Source Voltage (kV): 3.86
2: Source Current (uA): 2.14
3: Vaporizer Thermocouple OK: No
4: Vaporizer Temp (C): -62.87
5: Sheath Gas Flow Rate (): 6.00
6: Aux Gas Flow Rate(): 2.24
7: Sweep Gas Flow Rate(): 1.93
8: Capillary Temp OK: Yes
9: Capillary Voltage (V): 46.73
10: Capillary Temp (C): 199.92
11: Tube Lens Voltage (V): 135.38
12:  
13: VACUUM 
14: Vacuum OK: Yes
15: Ion Gauge Pressure OK: Yes
16: Ion Gauge Status: On
17: Ion Gauge (E-5 Torr): 0.83
18: Convectron Pressure OK: Yes
19: Convectron Gauge (Torr): 0.92
20:  
21: FT VACUUM 
22: FT Penning Pressure OK: Yes
23: FT Penning Gauge (E-10 Torr): 2.66
24: FT Pirani Gauge 1 (Torr): 0.78
25: FT Pirani Gauge 2 (Torr): 0.02
26:  
27: TURBO PUMP 
28: Status: Running
29: Life (hours): 4934
30: Speed (Hz): 800
31: Power (Watts): 66
32: Temperature (C): 56.00
33:  
34: FT TURBO PUMP 1 
35: Status: Running
36: Life (hours): 4782
37: Speed (Hz): 1000
38: Power (Watts): 11
39:  
40: FT TURBO PUMP 2 
41: Status: Running
42: Life (hours): 4173
43: Speed (Hz): 1001
44: Power (Watts): 17
45:  
46: ION OPTICS 
47: Multipole 00 Offset (V): -5.05
48: Intermultipole Lens 0 (V): -4.68
49: Multipole 0 Offset (V): -6.28
50: Intermultipole Lens 1 (V): -9.99
51: Gate Lens (V): -44.89
52: Multipole 1 Offset (V): -6.68
53: Multipole RF Amplitude (Vp-p, set point): 400.28
54: Front Lens (V): -6.81
55: Front Section (V): -8.99
56: Center Section (V): -12.40
57: Back Section (V): -7.16
58: Back Lens (V): -0.27
59: FT Multipole 1 Offset (V): -21.66
60: FT Intermultipole Lens 1 (V): -63.93
61: FT Multipole 2 Offset (V): -68.20
62: FT Intermultipole Lens 2 (V): -109.98
63: FT Multipole 3 Offset (V): -71.54
64: FT Multipole 1 RF Amplitude (Vp-p): 453.25
65: FT Multipole 2 and 3 RF Amplitude (Vp-p): 499.97
66:  
67: MAIN RF 
68: Standing Wave Ratio OK: Yes
69: Main RF Detected (V): -0.01
70: RF Detector Temp (C): 51.01
71: RF Generator Temp (C): 30.82
72:  
73: ION DETECTION SYSTEM 
74: Dynode Voltage (kV): -15.02
75: Multiplier 1 (V): -794.82
76: Multiplier 2 (V): -796.51
77:  
78: ECD 
79: Status: Not Connected
80: Heater Current (A): 0.00
81: Heater Voltage (V): 0.00
82: Heater Resistance (Ohm): 0.00
83: Target Gate Current (mA): 0.00
84: Actual Gate Current (mA): 0.00
85: Cathode Emission (mA): 0.00
86:  
87: IRMPD 
88: Status: Not Connected
89:  
90: POWER SUPPLIES 
91: +5V Supply Voltage (V): 4.99
92: -15V Supply Voltage (V): -15.10
93: +15V Supply Voltage (V): 15.03
94: -18V Supply Voltage (V): -17.95
95: +18V Supply Voltage (V): 18.22
96: +24V Supply Voltage (V): 23.87
97: -28V Supply Voltage (V): -28.19
98: +28V Supply Voltage (V): 28.26
99: +28V Supply Current (Amps): 1.34
100: +36V Supply Voltage (V): 36.23
101: -150V Supply Voltage (V): -148.78
102: +150V Supply Voltage (V): 148.61
103: -300V Supply Voltage (V): -295.76
104: +300V Supply Voltage (V): 294.84
105: Ambient Temp. (C): 40.06
106:  
107: FT POWER SUPPLIES 
108: FT ICB +15 Supply (V): 14.74
109: FT ICB -15 Supply (V): -14.66
110: FT ICB +10 Supply (V): 9.89
111: FT ICB -10 Supply (V): -9.89
112: FT ICB +5 Supply (V): 4.99
113: FT ICB +3.3 Supply (V): 3.46
114: FT ICB +2.5 Supply (V): 3.46
115: FT IOS +275 Supply (V): 276.71
116: FT IOS -275 Supply (V): -277.77
117: FT IOS +32 Supply (V): 29.46
118: FT IOS +15 Supply (V): 14.96
119: FT IOS -15 Supply (V): -15.26
120: FT IOS +5 Supply (V): 5.04
121: FT EA +32 Supply (V): 29.32
122: FT EA -32 Supply (V): -29.46
123: FT EA +15 Supply (V): 14.96
124: FT EA -15 Supply (V): -14.99
125: FT EA +5 Supply (V): 4.98
126: FT EA -5 Supply (V): -4.97
127: FT PA +5 Supply (V): 4.99
128: FT PA -5 Supply (V): -4.97
129: FT EA Temp. (C): 45.81
130: FT RF1 Amp. Temp. (C): 35.45
131: FT RF1 Amp. Temp. (C): 38.34
132:  
133: FT CRYO MONITOR 
134: Helium (%): 81.10
135: Nitrogen (%): 67.70
136:  
137: INSTRUMENT STATUS 
138: Instrument: On
139: Analysis: Acquiring
140:  
141: SYRINGE PUMP 
142: Status: Running
143: Flow Rate (uL/min): 2.00
144: Syringe Diameter (mm): 1.03
145:  
146: DIVERT VALVE 
147: Divert/Inject valve: Load

Trailer Extra (26 entries):
0: AGC: On
1: Micro Scan Count: 1
2: Ion Injection Time (ms): 80.464
3: Scan Segment: 1
4: Scan Event: 1
5: Master Index: 0
6: Elapsed Scan Time (sec): 0.90
7: API Source CID Energy: 0.00
8: Average Scan by Inst: No
9: Charge State: 2
10: Monoisotopic M/Z: 810.4163
11: MS2 Isolation Width: 0.0
12: MS3 Isolation Width: 0.0
13: MS4 Isolation Width: 0.0
14: MS5 Isolation Width: 0.0
15: MS6 Isolation Width: 0.0
16: MS7 Isolation Width: 0.0
17: MS8 Isolation Width: 0.0
18: MS9 Isolation Width: 0.0
19: MS10 Isolation Width: 0.0
20: FT Analyzer Settings: Patch=2 T=1e6 NSR
21: FT Analyzer Message: MAge=6d Est=0x2a
22: FT Resolution: 100000
23: Conversion Parameter I: 0.000
24: Conversion Parameter A: 107533.039
25: Conversion Parameter B: -347.451



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] Schema SNAPSHOT update Thursday 21 Feb 2008

[Fredrik L. <Fre...@im...>]

This looks like a nice solution. Only drawback is that it is not 
possible to enforce either a spectrumRef or an externalSpectrumRef plus 
sourceFileRef by xsd rules as far as I can see. I updated the 
experimental file and schema to exemplify:
http://trac.thep.lu.se/trac/fp6-prodac/changeset/30
Or is there a better xsd solution for the attribute choice?

Fredrik

Kessner, Darren E. wrote:
> This could work for precursors as well:
>
> If we have the precursor spectrum in the current file:
> <precursor spectrumRef="S1">
>
> If not, but we still know where the precursor can be found:
> <precursor externalID="FUNC0_SCAN28" sourceFileRef="SF1">
>
>
>
> Darren
>
>   

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

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
>   

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

Good question.  Here are a couple choices:

1) Mandate that in the Thermo case, externalID has to be the scan
number, and the cvParam "Thermo Scientific" has to be put in some
particular location, so that readers may make this assumption.

2) Use scanNumber and make it optional.

My feeling is that #1 may be dangerous, and #2 is ugly.  At the moment I
don't really have a strong feeling one way or the other (or maybe its
equally weak feelings...).


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Friday, February 22, 2008 10:43 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
number

Going back to your externalID idea, it would need to be optional on a 
per-offset basis in case some spectra were sums/averages and others not.

On top of that, how would this use case (which our software uses as 
well, so to some extent I'm playing devil's advocate here) handle a 
RAW->mzML converter that doesn't write the externalIDs or writes 
something else instead of the pure scan number?

-Matt


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

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

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

Going back to your externalID idea, it would need to be optional on a 
per-offset basis in case some spectra were sums/averages and others not. 
On top of that, how would this use case (which our software uses as 
well, so to some extent I'm playing devil's advocate here) handle a 
RAW->mzML converter that doesn't write the externalIDs or writes 
something else instead of the pure scan number?

-Matt


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

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

[Coleman, M. <MK...@St...>]

One use case that might be worth considering is spectrum file
subsetting.  I might have mzML file A and decide to remove some of its
spectra, producing mzML file B.  If each spectrum has a unique name (an
identity), I might reasonably contemplate accessing a spectrum from
either file rapidly (using the index).  If the index is just a set of
offsets of <spectrum> elements, subsetting in this way would imply
building a table to convert from old indices to new, which seems ugly.

It's always possible to generate other ad hoc indices, of course, rather
than relying on the one present in the mzML file.

Mike



> -----Original Message-----
> From: psi...@li... 
> [mailto:psi...@li...] On 
> Behalf Of Matthew Chambers
> Sent: Friday, February 22, 2008 12:01 PM
> 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
> 

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

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.

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

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

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

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

Just throwing another idea out there:

   <offset id="S17" externalID="17">4826</offset>

with externalID interpreted according to some other metadatum (original
source file type, instrument vendor, something else...)


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Kessner, Darren E.
Sent: Friday, February 22, 2008 9:52 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition
number

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
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] indexedmzML: scanNumber / acquisition number

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

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.