psidev-ms-dev — Mass spectroscopy standard development

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

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

Eric Deutsch wrote:
> So it seems like the final suggestion is something like:
>   <spectrum index="18" id="S2,4,6" >
>     <scan nativeScanReference="2,4,6">
>     </scan>
>   </spectrum>
>   

that would be
<spectrum><spectrumDescription><scan nativeScanReference="2,4,6">

This would work for cases when each spectrum refers to a single native scan.
But aren't there support for having a spectrum that is for instance a 
combination of several native scans?

[Term]
id: MS:1000570
name: spectra combination
def: "Method used to combine the mass spectra." [PSI:MS]
relationship: part_of MS:1000442 ! spectrum


What to do in this case?


--
Rune

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

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

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

--
Rune

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

[Psidev-ms-dev] PSI-MSSWG call in 8 hr

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

Hi everyone, here is a reminder of the call coming up in 8 hr. Dial-in
information is:

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to discuss all the items that have come up recently.
I list them as:

 

- Latest nativeScanReference proposal

- using defaultArrayLength attribute in <spectrum> but allow override in
binaryDataArray

- Allow new "possible charge state" term in <ionSelection> multiple
times

- Frederick suggestion that selectionWindow should really be scanWindow.
selectionWindow is something different, and by the way, where is it, we
really need that, too.

- MS^E example

- msLevel

- chromatograms

 

The schedule is still:

 

Schedule:

-----------------------

Jan 25: mzML reviews returned. Official community review complete.

Feb  5: mzML telecon 9:00am PST

Feb 19: mzML telecon 9:00am PST

Mar  4: mzML telecon 9:00am PST

Mar 17: US HUPO meeting 

Mar 25: mzML telecon 9:00am PST

Apr  8: mzML telecon 9:00am PST

Apr 23: PSI meeting in Toledo

May

Jun 1-5: ASMS - Must be done and advertising it here!

 

 

 

 

 

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

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

So it seems like the final suggestion is something like:

  <nativeScanRefFormat>
    <cvParam cvLabel="MS" accession="MS:1099580" name="Masswolf format
nativeScanReference"/>
  </nativeScanRefFormat>

  <spectrum index="18" id="S2,4,6" >
    <scan nativeScanReference="2,4,6">
    </scan>
  </spectrum>

  <offset index="18" id="S19" nativeScanReference="2,4,6">1234</offset>

--------------

For Thermo, we would have:

  <nativeScanRefFormat>
    <cvParam cvLabel="MS" accession="MS:1099581" name="Thermo format
nativeScanReference"/>
  </nativeScanRefFormat>

  <spectrum index="18" id="S19" >
    <scan nativeScanReference="19">
    </scan>
  </spectrum>

  <offset index="18" id="S19" nativeScanReference="19">1234</offset>

--------------

The one thing that concerns me is that there isn't much backward
compatibility here. It would be nice to preserve one attribute that
behaves in the same way it always did. If we made index start with 1
instead of 0, then that is probably as close to the traditional
"scanNumber" as we can hope for. Would that offend you, Darren?

--------------

My summary of the discussion goes like this:

New thread on acquisitionNumbers
- Darren posts example on what this would look like
- Matt suggests that there should be no acquisitionNumber in <index>
- Darren counters that having scanNumber aka acquisitionNumber in
<index> is critical
- Darren proffers:
  <offset id="S17" externalID="17">4826</offset>
  with externalID interpreted according to some other metadatum
(original
  source file type, instrument vendor, something else...)
- Matt: Why do you need to know scan number at open time?
- Darren: the point is we *know* the scan number and need to seek to it
- Mike brings up subsetting of one mzML file to another
- Matt brings up the externalID idea
- Darren offers a way to either annotate the assumption that
externalID=scan number or
  have an optional scanNumber attribute. Neither is liked
- Rune asks why preserving thermo scan number is important
- Darren says that he has tools that also go back to a RAW file with a
given scan number. So preserving the scan number is important.
- Darren provides a dump of a huge number of obscure bits of
configuration data availabel for each scan in Thermo RAW format. How to
encode in mzML? cvParams? userParams?
- Matt likes externalID instead of scanNumber and describes some
possible naming conventions
- Josh suggests that we need to encode a "native scan reference" to be
able to go back to the vendor software
- Darren agrees that native unique identifier needs to be in the index
and the rest in <scan>
- Josh suggests a slew of optional vendor-specific attributes in <index>
- Darren is okay with that, but also suggests using cvParams in the
<index> to define the meaning of externalID in a specific context,
different for each vendor
- Josh points out that some vendors have multi-part keys instead of a
single one so this makes the above a lot trickier
- Darren wonders if the multi-parts information needs to be in each
<offset> tag or could be global to the index?
  <index externalIDTypeAccession1="cycle"
externalIDTypeAccession2="scan">
    <offset id="S19" externalID="(19,123)">4826</offset>
- Josh agrees, although suggests nativeScanID
- Darren votes for nativeID
- Josh is fine with that
- Matt seems in agreement
- so the suggestions seemed to be:
  <index>
    <externalIDTypeList count="2">
      <cvParam .../>
      <cvParam .../>
    </externalIDTypeList>
    ...
    <offset id="S19" nativeID="(19,123)">4826</offset>
    ...
  </index>


--

Unique scan numbers thread
- Josh points out that MassWolf just renumbers the scans
  But there will be a "native scan reference" in mzXML
- Matt asks for details
- Josh suggests something like:
  <nativeScanRefFormat> containing ordered list
    <cvParam cvLabel="MS" accession="MS:1099580" name="scan cycle
number" value=""/>
    <cvParam cvLabel="MS" accession="MS:1099581" name="scan function
number" value=""/>
    <cvParam cvLabel="MS" accession="MS:1099582" name="scan number"
value=""/>
  </nativeScanRefFormat>
  <spectrum>
    <scan
      ...
      nativeScanRef="(2,4,6")
    </scan>
  </spectrum>
- Matt suggests just having a single cvParam to describe "MassWolf
nativeID format"

--

Related to the above if a <scan> nativeID thread
- Darren suggests:
  <offset id="S19" nativeID="19">1234</offset>
  It would also be convenient, and consistent, to have nativeID in
<scan>:
  <spectrum index=0 id="S19" nativeID="19">
  ...
  </spectrum>
- Matt suggests that <offset> should be <spectrum_offset>
- Darren says the important part of the discussion is that nativeID are
both in <spectrum> and <index>
- 


> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Matthew Chambers
> Sent: Monday, March 03, 2008 11:52 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Unique scan numbers
> 
> To be honest, for the mzML approach, I would prefer a single CV term
> describing the format and the axes it corresponds to. I see no reason
to
> allow formats with arbitrary axes in a controlled nativeID system. I'm
> happy to restrict that capability to the arbitrary id string. Perhaps
> there is a reason though and I'm not seeing it.
> 
> For mzXML, the axes definition block makes more sense to me. I would
> vote against flanking the id with parentheses though as that kind of
> makes them look like Cartesian coordinates. :)
> 
> -Matt
> 
> 
> Joshua Tasman wrote:
> > Hi Matt,
> >
> > After the discussion here last week with you and Darren, it seemed
an
> efficient way to deal with this would be to have each scan contain a
> string, and the header would have some description on how to parse
this.
> >
> > Off the top of my head, you could have something in the head like:
> >
> > mzML-ish:
> > in header:
> >  <nativeScanRefFormat> containing ordered list
> >    <cvParam with cv term for first axis />
> >    <cvParam with cv term for first axis />
> >    <cvParam with cv term for first axis />
> >  </nativeScanRefFormat>
> >
> > in spectrum: a string represenation like "(1st,2nd,3rd)"
> >
> > mzXML-ish:
> >  header:
> >  <nativeScanRefFormat Vendor="VendorX"> containing ordered list
> >    <axis name="cycle">
> >    <axis name="function">
> >    <axis name="scan">
> >  </nativeScanRefFormat>
> >
> > ...
> > <scan
> >  ...
> >  nativeScanRef="(2,4,6")
> > </scan>
> >
> > What do you think?
> >
> > Josh
> >
> >
> >
> > Matthew Chambers wrote:
> >
> >> Hi Josh,
> >>
> >> What design are you planning for the "native scan reference" in
mzXML?
> >> It seems the same issues I just posted about in response to Darren
will
> >> apply to the mzXML design as well.
> >>
> >> -Matt
> >>
> >>
> >> Joshua Tasman wrote:
> >>
> >>> 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
> >>>>
> >>>>
> >>>
----------------------------------------------------------------------
> ---
> >>> 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] Unique scan numbers

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

To be honest, for the mzML approach, I would prefer a single CV term 
describing the format and the axes it corresponds to. I see no reason to 
allow formats with arbitrary axes in a controlled nativeID system. I'm 
happy to restrict that capability to the arbitrary id string. Perhaps 
there is a reason though and I'm not seeing it.

For mzXML, the axes definition block makes more sense to me. I would 
vote against flanking the id with parentheses though as that kind of 
makes them look like Cartesian coordinates. :)

-Matt


Joshua Tasman wrote:
> Hi Matt,
>
> After the discussion here last week with you and Darren, it seemed an efficient way to deal with this would be to have each scan contain a string, and the header would have some description on how to parse this.
>
> Off the top of my head, you could have something in the head like:
>
> mzML-ish:
> in header:
>  <nativeScanRefFormat> containing ordered list
>    <cvParam with cv term for first axis />
>    <cvParam with cv term for first axis />
>    <cvParam with cv term for first axis />
>  </nativeScanRefFormat>
>
> in spectrum: a string represenation like "(1st,2nd,3rd)"
>
> mzXML-ish:
>  header: 
>  <nativeScanRefFormat Vendor="VendorX"> containing ordered list
>    <axis name="cycle">
>    <axis name="function">
>    <axis name="scan">
>  </nativeScanRefFormat>
>
> ... 
> <scan
>  ...
>  nativeScanRef="(2,4,6")
> </scan>
>
> What do you think?
>
> Josh
>  
>
>
> Matthew Chambers wrote:
>   
>> Hi Josh,
>>
>> What design are you planning for the "native scan reference" in mzXML? 
>> It seems the same issues I just posted about in response to Darren will 
>> apply to the mzXML design as well.
>>
>> -Matt
>>
>>
>> Joshua Tasman wrote:
>>     
>>> 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
>>>>     
>>>>         
>>> -------------------------------------------------------------------------
>>> 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] cvParam for mass analyzer in <scan>

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

Well, I don't particularly like the multiple virtual instruments either, 
but I couldn't think of anything better (if it's one instrument, the 
instrumentRef needs some way to reference the analyzer as well as the 
instrument). I really don't like the idea of duplicating information in 
an arbitrary way, though. Are you suggesting that it would be *optional* 
to include the cvParam for the mass analyzer in the <scan>? That seems 
unnecessarily hard to deal with for parsers and writers. On the other 
hand, if the instrumentRef is to "LTQ FT -- FT" or to LTQ FT -- ion 
trap" it is quite simple for the human reader to tell which analyzer is 
in use. No indirection is necessary at all - just look at the id. If the 
id is encoded in a less descriptive way, i.e. just a number, then the 
user could quickly map in their mind that a "1" refers to the FT 
component and a "2" refers to the IT component.

I agree that this approach is not very scalable though as far as user 
readability is concerned (e.g. if there were a hybrid instrument with 10 
different analyzers, users could not easily remember which virtual 
instrument each id represented). I just can't think of a CV way to do it 
without duplicating information.

And as I mentioned before, there are MANY ways in which indirection can 
be used in mzML which can make it virtually impossible for readers to 
interpret the file. ParamGroups have the potential to be the worst 
offender. If such groups are id'd with just numbers and there are a lot 
of them, users will find it impossible to remember which group of 
cvParams corresponds to which paramGroupRef. But that's just the price 
we pay for having that nice indirection capability. Clearly we need some 
kind of "mzML explorer" tool to be packaged both with and apart from the 
mzML library that we offer. Such a tool could properly render all the 
indirection into a human readable presentation, and that is the only 
real solution as I see it (without scrapping indirection completely).

-Matt


Kessner, Darren E. wrote:
>
> I've thought about this some more, and I don't like the use of two 
> virtual <instrument> elements for the sole purpose of distinguishing 
> between mass analyzers.  I write "virtual" because there is no 
> difference between the two <instrument> objects, except the 'id' 
> attribute and the "mass analyzer type" cvParam they contain.
>
>  
>
> (illustrative example -- see below for more comments)
>
>  
>
> <instrumentList count="2">
>
>   <instrument id="LTQ FT -- FT">
>
>     <cvParam cvLabel="MS" accession="MS:1000554" name=" LTQ FT " 
> value=""/>
>
>     <cvParam cvLabel="MS" accession="MS:1000529" name="instrument 
> serial number" value="23433"/>
>
>     ... (other cvParams here)
>
>       <componentList count="3">
>
>         <source order="1">
>
>           <cvParam cvLabel="MS" accession="MS:1000398" 
> name="nanoelectrospray" value=""/>
>
>         </source>
>
>         <analyzer order="2">
>
>           <cvParam cvLabel="MS" accession="MS:1000082" name="FT-ICR" 
> value=""/>
>
>         </analyzer>
>
>         <detector order="3">
>
>           <cvParam cvLabel="MS" accession="MS:1000253" name="electron 
> multiplier" value=""/>
>
>         </detector>
>
>       </componentList>
>
>    <instrumentSoftwareRef ref="Xcalibur"/>
>
>   </instrument>
>
>  
>
> <!--  everything here is the same, except the id and mass analyzer 
> type. -->
>
>  
>
>   <instrument id="LTQ FT -- ion trap">            <cvParam 
> cvLabel="MS" accession="MS:1000554" name=" LTQ FT " value=""/>
>
>     <cvParam cvLabel="MS" accession="MS:1000529" name="instrument 
> serial number" value="23433"/>
>
>     ... (other cvParams here)
>
>       <componentList count="3">
>
>         <source order="1">
>
>           <cvParam cvLabel="MS" accession="MS:1000398" 
> name="nanoelectrospray" value=""/>
>
>         </source>
>
>         <analyzer order="2">
>
>           <cvParam cvLabel="MS" accession="MS:1000082" name="ion trap" 
> value=""/>
>
>         </analyzer>
>
>         <detector order="3">
>
>           <cvParam cvLabel="MS" accession="MS:1000253" name="electron 
> multiplier" value=""/>
>
>         </detector>
>
>       </componentList>
>
>    <instrumentSoftwareRef ref="Xcalibur"/>
>
>   </instrument>
>
> </instrumentList>
>
>  
>
>  
>
> I believe indirection should only be used if it makes the information 
> clearer to the reader, whether it's a human or a parser, and whether 
> we're talking about mzML or any programming language.  Here we're 
> dealing with a single instrument, which can perform 3 different types 
> of scans (FT ms1, IT ms1, IT ms2).  I believe this type information 
> should be encoded with the scan, and I think it is less clear to the 
> reader to encode some of the information with the scan, and some with 
> a reference to a virtual instrument object.  (In fact, the information 
> *is* encoded in the scan in the form of the filter string -- but I 
> think everyone agrees that during conversion to mzML it is desirable 
> to make this information explicit in the form of cvParams).
>
>  
>
>  
>
> Darren
>
>  
>
>  
>
>  
>
>  
>
> IMPORTANT WARNING: This message is intended for the use of the person 
> or entity to which it is addressed and may contain information that is 
> privileged and confidential, the disclosure of which is governed by
> applicable law. If the reader of this message is not the intended 
> recipient, or the employee or agent responsible for delivering it to 
> the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this information is STRICTLY 
> PROHIBITED.
>
> If you have received this message in error, please notify us immediately
> by calling (310) 423-6428 and destroy the related message. Thank You 
> for your cooperation.
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] <scan> nativeID

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

Ahh -- sorry, I missed that.  And I agree ;)


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Monday, March 03, 2008 10:42 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] <scan> nativeID

I agree (I'd actually brought this up too, on 2/25:) 
> 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:
> Nope, same idea, but we had only talked about putting 'nativeID' in
the
> <offset> entry in the <index>.
> 
> I am proposing including 'nativeID' as an attribute to the
corresponding
> <spectrum> as well.
> 
> 
> Darren
> 
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
Joshua
> Tasman
> Sent: Monday, March 03, 2008 10:28 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] <scan> nativeID
> 
> Hi Darren,
> 
> I'm confused about this discussion (though maybe I've lost my place in
> the threads?)  Is this different than the ideas we were discussing
last
> week, regarding string formats for various vendor native scan
addressing
> schemes?
> 
> Josh
> 
> 
> Kessner, Darren E. wrote:
>> Hi all,
>>
>>  
>>
>> To pick up the discussion regarding <index> with nativeID, since we
> have:
>>   <offset id="S19" nativeID="19">1234</offset>
>>
>>  
>>
>> It would also be convenient, and consistent, to have nativeID in
> <scan>:
>>   <spectrum index=0 id="S19" nativeID="19">
>>
>>   ...
>>
>>   </spectrum>
>>
>>  
>>
>> In general, whatever information is in the <index> entry should be 
>> easily available in the actual <spectrum> element.  It makes
> generating 
>> the <index> a lot simpler for writers, and allows easier validation
of
> 
>> the <spectrum> for readers.
>>
>>  
>>
>>  
>>
>> 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] <scan> nativeID

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

I agree (I'd actually brought this up too, on 2/25:) 
> 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:
> Nope, same idea, but we had only talked about putting 'nativeID' in the
> <offset> entry in the <index>.
> 
> I am proposing including 'nativeID' as an attribute to the corresponding
> <spectrum> as well.
> 
> 
> Darren
> 
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Joshua
> Tasman
> Sent: Monday, March 03, 2008 10:28 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] <scan> nativeID
> 
> Hi Darren,
> 
> I'm confused about this discussion (though maybe I've lost my place in
> the threads?)  Is this different than the ideas we were discussing last
> week, regarding string formats for various vendor native scan addressing
> schemes?
> 
> Josh
> 
> 
> Kessner, Darren E. wrote:
>> Hi all,
>>
>>  
>>
>> To pick up the discussion regarding <index> with nativeID, since we
> have:
>>   <offset id="S19" nativeID="19">1234</offset>
>>
>>  
>>
>> It would also be convenient, and consistent, to have nativeID in
> <scan>:
>>   <spectrum index=0 id="S19" nativeID="19">
>>
>>   ...
>>
>>   </spectrum>
>>
>>  
>>
>> In general, whatever information is in the <index> entry should be 
>> easily available in the actual <spectrum> element.  It makes
> generating 
>> the <index> a lot simpler for writers, and allows easier validation of
> 
>> the <spectrum> for readers.
>>
>>  
>>
>>  
>>
>> 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] Unique scan numbers

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

Hi Matt,

After the discussion here last week with you and Darren, it seemed an efficient way to deal with this would be to have each scan contain a string, and the header would have some description on how to parse this.

Off the top of my head, you could have something in the head like:

mzML-ish:
in header:
 <nativeScanRefFormat> containing ordered list
   <cvParam with cv term for first axis />
   <cvParam with cv term for first axis />
   <cvParam with cv term for first axis />
 </nativeScanRefFormat>

in spectrum: a string represenation like "(1st,2nd,3rd)"

mzXML-ish:
 header: 
 <nativeScanRefFormat Vendor="VendorX"> containing ordered list
   <axis name="cycle">
   <axis name="function">
   <axis name="scan">
 </nativeScanRefFormat>

... 
<scan
 ...
 nativeScanRef="(2,4,6")
</scan>

What do you think?

Josh
 


Matthew Chambers wrote:
> Hi Josh,
> 
> What design are you planning for the "native scan reference" in mzXML? 
> It seems the same issues I just posted about in response to Darren will 
> apply to the mzXML design as well.
> 
> -Matt
> 
> 
> Joshua Tasman wrote:
>> 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
>>>     
>> -------------------------------------------------------------------------
>> 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] <scan> nativeID

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

Nope, same idea, but we had only talked about putting 'nativeID' in the
<offset> entry in the <index>.

I am proposing including 'nativeID' as an attribute to the corresponding
<spectrum> as well.


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Monday, March 03, 2008 10:28 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] <scan> nativeID

Hi Darren,

I'm confused about this discussion (though maybe I've lost my place in
the threads?)  Is this different than the ideas we were discussing last
week, regarding string formats for various vendor native scan addressing
schemes?

Josh


Kessner, Darren E. wrote:
> Hi all,
> 
>  
> 
> To pick up the discussion regarding <index> with nativeID, since we
have:
> 
>   <offset id="S19" nativeID="19">1234</offset>
> 
>  
> 
> It would also be convenient, and consistent, to have nativeID in
<scan>:
> 
>   <spectrum index=0 id="S19" nativeID="19">
> 
>   ...
> 
>   </spectrum>
> 
>  
> 
> In general, whatever information is in the <index> entry should be 
> easily available in the actual <spectrum> element.  It makes
generating 
> the <index> a lot simpler for writers, and allows easier validation of

> the <spectrum> for readers.
> 
>  
> 
>  
> 
> 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.

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

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

I've thought about this some more, and I don't like the use of two
virtual <instrument> elements for the sole purpose of distinguishing
between mass analyzers.  I write "virtual" because there is no
difference between the two <instrument> objects, except the 'id'
attribute and the "mass analyzer type" cvParam they contain.

 

(illustrative example -- see below for more comments)

 

<instrumentList count="2">

  <instrument id="LTQ FT -- FT">

    <cvParam cvLabel="MS" accession="MS:1000554" name=" LTQ FT "
value=""/>

    <cvParam cvLabel="MS" accession="MS:1000529" name="instrument serial
number" value="23433"/>

    ... (other cvParams here)

      <componentList count="3">

        <source order="1">

          <cvParam cvLabel="MS" accession="MS:1000398"
name="nanoelectrospray" value=""/>

        </source>

        <analyzer order="2">

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

        </analyzer>

        <detector order="3">

          <cvParam cvLabel="MS" accession="MS:1000253" name="electron
multiplier" value=""/>

        </detector>

      </componentList>

   <instrumentSoftwareRef ref="Xcalibur"/>

  </instrument>

 

<!--  everything here is the same, except the id and mass analyzer type.
-->

 

  <instrument id="LTQ FT -- ion trap">            <cvParam cvLabel="MS"
accession="MS:1000554" name=" LTQ FT " value=""/>

    <cvParam cvLabel="MS" accession="MS:1000529" name="instrument serial
number" value="23433"/>

    ... (other cvParams here)

      <componentList count="3">

        <source order="1">

          <cvParam cvLabel="MS" accession="MS:1000398"
name="nanoelectrospray" value=""/>

        </source>

        <analyzer order="2">

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

        </analyzer>

        <detector order="3">

          <cvParam cvLabel="MS" accession="MS:1000253" name="electron
multiplier" value=""/>

        </detector>

      </componentList>

   <instrumentSoftwareRef ref="Xcalibur"/>

  </instrument>

</instrumentList>

 

 

I believe indirection should only be used if it makes the information
clearer to the reader, whether it's a human or a parser, and whether
we're talking about mzML or any programming language.  Here we're
dealing with a single instrument, which can perform 3 different types of
scans (FT ms1, IT ms1, IT ms2).  I believe this type information should
be encoded with the scan, and I think it is less clear to the reader to
encode some of the information with the scan, and some with a reference
to a virtual instrument object.  (In fact, the information *is* encoded
in the scan in the form of the filter string -- but I think everyone
agrees that during conversion to mzML it is desirable to make this
information explicit in the form of cvParams).

 

 

Darren

 

 

 

 

IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] <scan> nativeID

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

Hi Darren,

I'm confused about this discussion (though maybe I've lost my place in the threads?)  Is this different than the ideas we were discussing last week, regarding string formats for various vendor native scan addressing schemes?

Josh


Kessner, Darren E. wrote:
> Hi all,
> 
>  
> 
> To pick up the discussion regarding <index> with nativeID, since we have:
> 
>   <offset id="S19" nativeID="19">1234</offset>
> 
>  
> 
> It would also be convenient, and consistent, to have nativeID in <scan>:
> 
>   <spectrum index=0 id="S19" nativeID="19">
> 
>   ...
> 
>   </spectrum>
> 
>  
> 
> In general, whatever information is in the <index> entry should be 
> easily available in the actual <spectrum> element.  It makes generating 
> the <index> a lot simpler for writers, and allows easier validation of 
> the <spectrum> for readers.
> 
>  
> 
>  
> 
> 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

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

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

Hi Josh,

What design are you planning for the "native scan reference" in mzXML? 
It seems the same issues I just posted about in response to Darren will 
apply to the mzXML design as well.

-Matt


Joshua Tasman wrote:
> 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
>>     
>
> -------------------------------------------------------------------------
> 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] <scan> nativeID

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

Agreed about the consistency between metadata available in the spectrum 
element and the offset elements (though I still say the offset element 
needs to be specific to the type of element it is referencing, e.g. 
"spectrum_offset", so that we can index other things if we start to 
support them, e.g. chromatograms).

NativeID is a big new concept though (as far as I know it hasn't been 
discussed before, but there was a lot mzML work before I started paying 
attention, so maybe it has come up), which brings up its own issues. Do 
vendors get to decide what the nativeID formats look like? Does it go 
through some approval process like the CV terms? Does it go into the CV 
in some way? Do non-native formats get their own nativeIDs, e.g. 
DTA/MGF/mzXML/mzData? I am excited about the concept and what it means 
for not having to mess much with arbitrary string ids, where the only 
presentation is linear and unintuitive, and the id formats are 
completely non-standard and user/writer-defined.

-Matt


Kessner, Darren E. wrote:
>
> Hi all,
>
>  
>
> To pick up the discussion regarding <index> with nativeID, since we have:
>
>   <offset id="S19" nativeID="19">1234</offset>
>
>  
>
> It would also be convenient, and consistent, to have nativeID in <scan>:
>
>   <spectrum index=0 id="S19" nativeID="19">
>
>   ...
>
>   </spectrum>
>
>  
>
> In general, whatever information is in the <index> entry should be 
> easily available in the actual <spectrum> element.  It makes 
> generating the <index> a lot simpler for writers, and allows easier 
> validation of the <spectrum> for readers.
>
>  
>
>  
>
> 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
>   

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

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

Darren Kessner wrote:
>> I don't think this use case is all that common, though. Of course, if 
>> precursor mass/charge correction were more common, then so would this
>> use case.
>>     
>
>
> Actually, this is more common than most people probably realize -- 
> precursor m/z-intensity recalculation is done silently during RAW->mzXML 
> conversion by ReAdW, which finds a local max in the parent scan near the 
> value reported in the filter string (when it's not stored in the trailer 
> data). I think this sort of processing should be made explicit in the 
> data file, and when it is not done, we can at least facilitate this 
> calculation.
>   
It only looks up the intensity, it does not attempt to correct the m/z 
(and it does it for both inaccurate and accurate m/z). I don't think a 
simple lookup of an intensity value for a m/z should constitute 
"processing." But m/z correction certainly would. Actually that's 
another reason not to include the filter line in Thermo conversion...for 
high-accuracy instruments, users might see the difference between the 
filter precursor m/z and the cvParam precursor m/z and think that it's 
an error because the values don't match.


> On the other hand, it's not just for precursor recalculation. This would 
> also facilitate other calculations that span scans, e.g. integrating a 
> selected ion chromatogram over a certain time interval. Here again you 
> can rely on the software layer to distinguish between the mass analyzer 
> types, but I would argue that hybrid instruments are common enough to 
> warrant making this calculation simpler.
>   
MzML is loaded with performance optimizations and indirections like this 
one, the worst being that a paramGroup can either be inline or a 
reference to a group defined elsewhere in the file. That can happen 
almost anywhere in the file, and dealing with that is far harder for a 
parser implementor than indirection to a global instrument object. We 
can provide users with a nice I/O library with an interface that follows 
the indirection on the back-end and makes it appear direct in this case 
(and many others). Even if the cvParam were directly in the <scan>, 
trying to use it directly without the nice library interface would be 
ugly IMO. This change would be taking away a raindrop in the ocean of 
indirection that mzML supports. :)

-Matt

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

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

> I don't think this use case is all that common, though. Of course, if 
> precursor mass/charge correction were more common, then so would this
> use case.


Actually, this is more common than most people probably realize -- 
precursor m/z-intensity recalculation is done silently during RAW->mzXML 
conversion by ReAdW, which finds a local max in the parent scan near the 
value reported in the filter string (when it's not stored in the trailer 
data). I think this sort of processing should be made explicit in the 
data file, and when it is not done, we can at least facilitate this 
calculation.

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

On the other hand, it's not just for precursor recalculation. This would 
also facilitate other calculations that span scans, e.g. integrating a 
selected ion chromatogram over a certain time interval. Here again you 
can rely on the software layer to distinguish between the mass analyzer 
types, but I would argue that hybrid instruments are common enough to 
warrant making this calculation simpler.


Darren

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

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

I don't think this use case is all that common, though. Of course, if 
precursor mass/charge correction were more common, then so would this 
use case. :) I don't like the idea of writing the filter string to the 
file at all, but I have no reason to stop people from doing it - it is 
of course Thermo's way of storing a quick summary of the scan metadata. 
But that metadata is totally redundant with the metadata in the mzML 
file, even if some of it has been made indirectly accessible for 
optimization purposes (it would be plausible to write the same 
instrument element for every scan in order to minimize indirection, but 
that would obviously be inefficient). As for implementation, both 
writers and readers (at least readers which care about the instrument 
metadata) would need to keep an internal mapping to the instrument 
metadata from the scans, or else store it for every scan without regard 
to the redundancy. I'm afraid this is just a tradeoff between 
performance optimization and ease of implementation. Anyway, mzXML went 
with the "one instrument element per analyzer" method, and it wasn't too 
hard to implement support for. The hardest part in my experience was 
having to parse all the Thermo filters up front to determine which 
analyzers the instrument has. :(

-Matt


Kessner, Darren E. wrote:
>> I do not like the idea of putting the mass analyzer type cvParams 
>> in multiple places (i.e. both in the scan element and in the 
>> instrument)
>>     
>
> I agree that it's a good principle to avoid duplicated information.  But
> I think that it's important to make the most common use cases most
> convenient.
>
> An example of this is the 'msLevel' attribute, which can be found in the
> filter string as well, but since it is commonly used to do quick
> filtering of the spectra, the information is duplicated and placed in a
> convenient place.  In our software tools, the first filtering done is
> always by msLevel and massAnalyzerType.
>
> I also agree that we can hide the indirection.  But there will be other
> writers and parsers that will also have to deal with this common
> scenario.  (It's actually more annoying for mzML writers, which would
> have to keep an internal map from the filter string fragment to the
> multiple <instrument> entries in order to write out <spectrum>
> elements.)
>
>
> Darren
>
>
>   

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

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

> I do not like the idea of putting the mass analyzer type cvParams 
> in multiple places (i.e. both in the scan element and in the 
> instrument)

I agree that it's a good principle to avoid duplicated information.  But
I think that it's important to make the most common use cases most
convenient.

An example of this is the 'msLevel' attribute, which can be found in the
filter string as well, but since it is commonly used to do quick
filtering of the spectra, the information is duplicated and placed in a
convenient place.  In our software tools, the first filtering done is
always by msLevel and massAnalyzerType.

I also agree that we can hide the indirection.  But there will be other
writers and parsers that will also have to deal with this common
scenario.  (It's actually more annoying for mzML writers, which would
have to keep an internal map from the filter string fragment to the
multiple <instrument> entries in order to write out <spectrum>
elements.)


Darren



IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

[Psidev-ms-dev] <scan> nativeID

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

Hi all,

 

To pick up the discussion regarding <index> with nativeID, since we
have:

  <offset id="S19" nativeID="19">1234</offset>

 

It would also be convenient, and consistent, to have nativeID in <scan>:

  <spectrum index=0 id="S19" nativeID="19">

  ...

  </spectrum>

 

In general, whatever information is in the <index> entry should be
easily available in the actual <spectrum> element.  It makes generating
the <index> a lot simpler for writers, and allows easier validation of
the <spectrum> for readers.

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

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

 

 

IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

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

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

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

-Matt


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

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

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

Hi all,

 

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

 

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

 

<scan instrumentRef="LTQ-FT">

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

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

    ...

</scan>

 

<scan instrumentRef="LTQ-FT">

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

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

    ...

</scan>

 

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

 

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

 

<instrument id="LTQ-FT">

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

  <componentList count="3">

    ...

    <analyzer order="2">

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

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

    </analyzer>

  ...

  </componentList>

</instrument>

 

I would very much prefer to write everything as above.  

 

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

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

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

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

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

 

 

IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] use case: FT transient data

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

> How does that strike you? Does the transient intensity array not have an
> X-axis to go with the intensities?


Looks good.  The name "primaryArrayLength" may suggest something beyond 
"defaultArrayLength" or just "arrayLength".  But I'm happy with any of 
the names.

Thermo transients assume a regularly spaced time axis, but I could 
imagine transient data being encoded with time samples.


Darren




Eric Deutsch wrote:
> Okay, well, your example is compels me to think that is not the way we
> should do it.  It seems like the most reasonable alternative is to go
> with the previous suggestion of allowing overriding of the arrayLength:
>
> <spectrum id="S19" index="1" primaryArrayLength="13020">
> 	<spectrumDescription>
> 		...
> 	</spectrumDescription>
> 	<binaryDataArray encodedLength="5433"
> dataProcessingRef="Xcalibur Processing">
> 		<cvParam cvLabel="MS" accession="MS:1000514" name="m/z
> array" value=""/>
> 		...
> 		<binary>AAAAwDsGeUAAAAD...</binary>
> 	</binaryDataArray>
> 	<binaryDataArray encodedLength="4892">
> 		<cvParam cvLabel="MS" accession="MS:1000515"
> name="intensity array" value=""/>
> 		...
> 		<binary>AAAAAIBJxk...</binary>
> 	</binaryDataArray>
> 	<binaryDataArray encodedLength="23445" arrayLength="56343">
> 		<cvParam cvLabel="MS" accession="MS:100xxxx"
> name="transient intensity array" value=""/>
> 		...
> 		<binary>AAAAAIBJxk...</binary>
> 	</binaryDataArray>
> </spectrum>
>
> How does that strike you? Does the transient intensity array not have an
> X-axis to go with the intensities?
>
> Eric
>
>
>
>   

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

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

Yes, Eric & Matt -- I agree that this is the right way to do it.

No change needed to spec.  Possible change to the CV, if we want CV 
terms to represent "general software category", with "data acquisition", 
"format conversion".  This might be useful to the human reader, probably 
less so for a parser...


Darren



Matthew Chambers wrote:
> Except for the wormy cvParam format issue, I like:
>
> <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:1000xxx" name="data acquisition" value=""/>
> 	<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>
>
> The softwareList seems to behave just like an index. I like it better 
> than the mzXML equivlanet which seems to not allow for the fact that the 
> same software can be used for multiple types of data processing. Even if 
> it turns out that the mzML data processing list is backward compatible 
> with the mzXML data processing list, it cannot be expected that any 
> given mzML will be able to be converted to mzXML and back again without 
> any loss of information. Only in certain limited uses would that be 
> possible.
>
> -Matt
>
>
> Eric Deutsch wrote:
>   
>> 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
>>>     
>>>       
>> -------------------------------------------------------------------------
>> 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] use case: FT transient data

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

Okay, well, your example is compels me to think that is not the way we
should do it.  It seems like the most reasonable alternative is to go
with the previous suggestion of allowing overriding of the arrayLength:

<spectrum id="S19" index="1" primaryArrayLength="13020">
	<spectrumDescription>
		...
	</spectrumDescription>
	<binaryDataArray encodedLength="5433"
dataProcessingRef="Xcalibur Processing">
		<cvParam cvLabel="MS" accession="MS:1000514" name="m/z
array" value=""/>
		...
		<binary>AAAAwDsGeUAAAAD...</binary>
	</binaryDataArray>
	<binaryDataArray encodedLength="4892">
		<cvParam cvLabel="MS" accession="MS:1000515"
name="intensity array" value=""/>
		...
		<binary>AAAAAIBJxk...</binary>
	</binaryDataArray>
	<binaryDataArray encodedLength="23445" arrayLength="56343">
		<cvParam cvLabel="MS" accession="MS:100xxxx"
name="transient intensity array" value=""/>
		...
		<binary>AAAAAIBJxk...</binary>
	</binaryDataArray>
</spectrum>

How does that strike you? Does the transient intensity array not have an
X-axis to go with the intensities?

Eric





> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Kessner, Darren E.
> Sent: Thursday, February 21, 2008 11:34 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] use case: FT transient data
> 
> Actually, I agree with Matt here -- allowing a <binaryDataArray> to
> override the <spectrum> 'arrayLength' is a simple solution to allow
> these auxilliary arrays to have a different length from the main
> m/z-intensity arrays.
> 
> Another issue with using two <spectrum> elements for a single scan is
> that it has to be decided whether to duplicate scan metadata.  If the
> metadata is not to be duplicated, it is essential to have
> cross-references between the <spectrum> elements.
> 
> 
> Darren
> 
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
> Matthew Chambers
> Sent: Thursday, February 21, 2008 11:15 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] use case: FT transient data
> 
> It's a neat use case and would like to see it supported, but am I the
> only one that thinks this would be better as an auxiliary
> binaryDataArray element inside the same spectrum element? This
> implementation seems much more complicated and verbose than an
> equivalent implementation supported by binaryDataArray elements with
> varying length.
> 
> -Matt
> 
> 
> Kessner, Darren E. wrote:
> >
> > Hi all,
> >
> >
> >
> > Here is a <spectrumList> fragment to illustrate the encoding of FT
> > transient data, as requested by Eric during the conference call.
> >
> >
> >
> > Some notes:
> >
> >
> >
> > The <spectrum> attribute 'index' indicates the 0-based index into
the
> > <spectrumList>.  There are two scans (17 and 18), each with an
> > m/z-intensity <spectrum> followed by a transient intensity
> > <spectrum>.  The Thermo scan number is encoded as <acquisition>
> > attribute 'number' as suggested by Randy.
> >
> >
> >
> > I'm not sure whether we would want an additional CV term for
> > "transient intensity array", which is a time-based intensity array.
> > We would need a CV term for "acquisition time" to describe how long
> > the signal is being observed in the FT cell.  There would be some
> > other terms for metadata values associated with the transient as
> > well.  Note that there is no array for time points -- it is assumed
> > that the time spacing is regular, and calculated by the array size
and
> 
> > "acquisition time" (this may be encoded differently by different
> vendors).
> >
> >
> >
> > I don't immediately see a way to pair the m/z spectrum with the
> > transient spectrum -- it would be nice to have a general
<spectrumRef>
> 
> > from one <spectrum> to another (not just to a precursor), so that
you
> > can find e.g. the transient data associated with an m/z spectrum or
> > vice versa.
> >
> >
> >
> >
> >
> > <spectrumList count="4">
> >
> >
> >
> >     <spectrum id="S17" index="0" msLevel="1" arrayLength="1313">
> >
> >         <cvParam cvLabel="MS" accession="MS:1000580" name="MSn
> > spectrum" value=""/>
> >
> >         <spectrumDescription>
> >
> >             <acquisitionList count="1">
> >
> >                 <acquisition number="17" spectrumRef="?"
> > sourceFileRef="?"/>
> >
> >             </acquisitionList>
> >
> >             ...
> >
> >         </spectrumDescription>
> >
> >         <binaryDataArray encodedLength="5000"
> > dataProcessingRef="Xcalibur Processing">
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000514" name="m/z
> > array" value=""/>
> >
> >             <binary>...</binary>
> >
> >         </binaryDataArray>
> >
> >         <binaryDataArray encodedLength="5000">
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000515"
> > name="intensity array" value=""/>
> >
> >             <binary>...</binary>
> >
> >         </binaryDataArray>
> >
> >     </spectrum>
> >
> >
> >
> >     <spectrum id="S17_transient" index="1" msLevel="1"
> arrayLength="1234">
> >
> >         <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn
> > transient spectrum ?" value=""/>
> >
> >         <spectrumDescription>
> >
> >             <acquisitionList count="1">
> >
> >                 <acquisition number="17" spectrumRef="?"
> > sourceFileRef="?"/>
> >
> >             </acquisitionList>
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000xxx"
> > name="acquisition time" value=".768" unitAccession="MS:1000039"
> >
> >                             unitName="second"/>
> >
> >         </spectrumDescription>
> >
> >         <binaryDataArray encodedLength="5000"
> > dataProcessingRef="Xcalibur Processing">
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000xxx"
> > name="transient intensity array ?" value=""/>
> >
> >             <binary>...</binary>
> >
> >         </binaryDataArray>
> >
> >     </spectrum>
> >
> >
> >
> >     <spectrum id="S18" index="2" msLevel="1" arrayLength="1400">
> >
> >         <cvParam cvLabel="MS" accession="MS:1000580" name="MSn
> > spectrum" value=""/>
> >
> >         <spectrumDescription>
> >
> >             <acquisitionList count="1">
> >
> >                 <acquisition number="18" spectrumRef="?"
> > sourceFileRef="?"/>
> >
> >             </acquisitionList>
> >
> >             ...
> >
> >         </spectrumDescription>
> >
> >         <binaryDataArray encodedLength="5000"
> > dataProcessingRef="Xcalibur Processing">
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000514" name="m/z
> > array" value=""/>
> >
> >             <binary>...</binary>
> >
> >         </binaryDataArray>
> >
> >         <binaryDataArray encodedLength="5000">
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000515"
> > name="intensity array" value=""/>
> >
> >             <binary>...</binary>
> >
> >         </binaryDataArray>
> >
> >     </spectrum>
> >
> >
> >
> >     <spectrum id="S18_transient" index="3" msLevel="1"
> arrayLength="2345">
> >
> >         <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn
> > transient spectrum ?" value=""/>
> >
> >         <spectrumDescription>
> >
> >             <acquisitionList count="1">
> >
> >                 <acquisition number="18" spectrumRef="?"
> > sourceFileRef="?"/>
> >
> >             </acquisitionList>
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000xxx"
> > name="acquisition time" value=".768" unitAccession="MS:1000039"
> >
> >                             unitName="second"/>
> >
> >         </spectrumDescription>
> >
> >         <binaryDataArray encodedLength="5000"
> > dataProcessingRef="Xcalibur Processing">
> >
> >             ...
> >
> >             <cvParam cvLabel="MS" accession="MS:1000xxx"
> > name="transient intensity array ?" value=""/>
> >
> >             <binary>...</binary>
> >
> >         </binaryDataArray>
> >
> >     </spectrum>
> >
> >
> >
> > </spectrumList>
> >
> >
> >
> >
> >
> > 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
> >
> 
>
------------------------------------------------------------------------
> -
> 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] mzML 0.99.9 SNAPSHOT software::type attribute

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

Except for the wormy cvParam format issue, I like:

<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:1000xxx" name="data acquisition" value=""/>
	<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>

The softwareList seems to behave just like an index. I like it better 
than the mzXML equivlanet which seems to not allow for the fact that the 
same software can be used for multiple types of data processing. Even if 
it turns out that the mzML data processing list is backward compatible 
with the mzXML data processing list, it cannot be expected that any 
given mzML will be able to be converted to mzXML and back again without 
any loss of information. Only in certain limited uses would that be 
possible.

-Matt


Eric Deutsch wrote:
> 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
>>     
>
> -------------------------------------------------------------------------
> 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
>
>