Re: [Psidev-ms-dev] PSI-MSS WG Tuesday call reminder

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Steve,

Thanks for bringing up the great schism of mzData, dataXML, and mzML. ;)

I'm not sure what you mean about "1 is different than 1.0 and different 
than 1.00" - when a computer parses these numbers into floating point 
(or fixed point, for that matter), they are not different. 
Mathematically, they aren't different. So why should they be treated 
different for a reference/library format?

For any of you interested in one of the many historical discussions on 
this topic, I dug one up at:
http://sourceforge.net/mailarchive/forum.php?thread_name=S375284AbWJEL1o%2F20061005112745Z%2B11766%40ams006.ftl.affinity.com&forum_name=psidev-ms-dev

The many internal references in mzML to me means that it shouldn't be 
considered a light-weight format that simple scripts could parse: 
reading mzML with software takes a substantial API. Thus the only 
remaining benefit for ASCII peak representation (AFAIK) is human 
readability of peak lists and that's not enough to convince me that we 
should incur the "more than one way to do it" penalty.

However, NIST library folks have a quite straight-forward way to meet 
the "human readability" requirement: XML comments. There's no reason you 
can't put what looks like an MGF peak list in an XML comment with every 
mzML spectrum (although presumably not profile-mode ones!).

For example:
<spectrum index="1" id="scan=20" defaultArrayLength="10">
...
<!--
m/z intensity
123.4 0.12
234.5 12.3
345.6 23.4
456.7 345.6
567.8 45.3
678.9 34.2
789.0 123.4
890.1 4567.8
901.2 345.6
1234.5 4.56
-->
<binaryDataArrayList count="2">
... base64 arrays are still required ...
</binaryDataArrayList>
</spectrum>

Thoughts?
-Matt

Stein, Stephen E. Dr. wrote:
>
> Congrats on a new version…..
>
> However, I wanted to again state what I think is a defect in the 
> standard – the inability to accept an ASCII peak list. This prevents 
> us from using mzML it as the format for libraries or reference data.
>
> --- 1 is different than 1.0 and different than 1.00 ….
>
> this difference, to some, is non trivial and changes the meaning of 
> reference data when converted to binary.
>
> Also, the ability to see read the data is nice for those who want to 
> do it.
>
> I suppose it’s addition will do too much damage to add to 1.2 – but I 
> just felt that I should bring it up again as our needs have not changed.
>
> -Steve Stein
>
> ------------------------------------------------------------------------
>
> *From:* Eric Deutsch [mailto:ede...@sy...]
> *Sent:* Tuesday, June 09, 2009 12:02 PM
> *To:* 'Mass spectrometry standard development'
> *Cc:* 'Eric Deutsch'
> *Subject:* Re: [Psidev-ms-dev] PSI-MSS WG Tuesday call reminder
>
> Present: Marc, Jim, Matt, Eric, Lennart, Pierre-Alain
>
> 1) mzML 1.1.0
>
> - Released!
>
> + The whitespace issue in the xsd resolved before
>
> - Allowed binarydata data types
>
> + Add back in 32- and 64-bit integer. Those terms should be 
> unobsoleted. There were there
>
> + Add string array: null-terminated array of strings. Must have as 
> many nulls as elements.
>
> + Matt will add these to the CV
>
> + It will be implemented somehow in ProteoWizard and OpenMS
>
> + Matt will added another CV type which is binarydatatype and then 
> annotated mzArray, IntensityArray, and chargeArray with the 
> appropriate types
>
> - ASMS
>
> + There is a group that just put together a “unified” format for ion 
> mobility mass spec. Matt and Eric met him, and we will followup
>
> + Also had discussion with ANiML. Being done through ASTM
>
> - ASMS might help out with CV
>
> + David Sparkman may help us out.
>
> + Eric will update MSS WG page
>
> + Eric will email Juan Antonio about top page
>
> + Marc will double check with Andreas Römpp on units addition and then 
> add them as is
>
> 2) TraML development
>
> - Feedback from ASMS
>
> - Implementations
>
> + ProteoWizard has some implementation. OpenMS does as well by 
> Andreas. Jim is working on something
>
> - cvParams vs attributes
>
> + Problem with attributes is lack on units specification
>
> + Problem with attributes is default value ambiguity in C++
>
> + change transition name to id of type xsd:string
>
> + Apply rule: any attribute that is not an id or a Ref should be 
> switched to cvParam
>
> + How does mzIdentML handle b9-18^2 ? Try to do he same?
>
> + What about string values?
>
> + Matt is advocating more cvParams, Pierre-Alain as well. Jim as well.
>
> + Make normalizationStandard should be cvParams H-PINS
>
> + Eric will make another rev beased on this.
>
> + Meet again next week same time
>
> ------------------------------------------------------------------------
>
> *From:* Eric Deutsch [mailto:ede...@sy...]
> *Sent:* Monday, June 08, 2009 3:41 PM
> *To:* 'Mass spectrometry standard development'
> *Cc:* 'Eric Deutsch'
> *Subject:* PSI-MSS WG Tuesday call reminder
>
> Hi everyone, the next PSI Mass Spectrometry Standards Working Group 
> call will be Tuesday 8am PDT:
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=09&month=6&year=2009&hour=16&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=09&month=6&year=2009&hour=16&min=0&sec=0&p1=136>
>
> 08:00 San Francisco
>
> 11:00 New York
>
> 16:00 London
>
> 17:00 Geneva
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-314-3683
>
> Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
> Agenda:
>
> 1) mzML 1.1.0
>
> - Released!
>
> - Allowed binarydata data types
>
> -
>
> 2) TraML development
>
> - Feedback from ASMS
>
> - Implementations
>
> - cvParams vs attributes
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev