psidev-ms-dev — Mass spectroscopy standard development

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

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

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

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

[Stein, S. E. Dr. <ste...@ni...>]

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

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

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

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

I just committed the binary data array/type changes to the CV:
- added key-value relationships to specify which binary data types are 
valid for which binary data arrays
- improved definitions for binary data types
- added new binary data type for null-terminated ASCII strings

-Matt


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

Re: [Psidev-ms-dev] MzML mapping file

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

I didn't realize (forgot?) that I was supposed to update the mapping for 
this. It's now committed:
- added mapping for chromatogram precursor and product elements
- updated isolation window mappings to require "isolation window target 
m/z" and allow other attributes (i.e. lower and upper offsets)

-Matt


Marc Sturm wrote:
> Hi Matt,
>
> you wanted to add mapping rules for the chromatogram elements to the 
> mapping file. Have you done that yet? I'd like to validate the SRM 
> example files before we declare 1.1.0 finished.
>
> Best,
>  Marc

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

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

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
<http://www.timeanddate.com/worldclock/fixedtime.html?day=09&month=6&year=20
09&hour=16&min=0&sec=0&p1=136> &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

 

 

 

 

 

 

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

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

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
<http://www.timeanddate.com/worldclock/fixedtime.html?day=09&month=6&year=20
09&hour=16&min=0&sec=0&p1=136> &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

 

 

 

 

 

 

Re: [Psidev-ms-dev] Minor spec doc comment

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

Hi Andy, thanks for this, I have updated references of AnalysisXML to
mzIdentML. As far as the relationship to other specs, I thought it would be
nice to maintain some reference to the other related formats like spML,
since it inevitably comes up every year why mzML doesn't contain something
so important as chromatography information. Here's what it currently says:

 

 

1.      MIAPE MS (http://www.psidev.info/index.php?q=node/91) The "Minimum
Information About a Proteomics Experiment: Mass Spectrometry" module
document identifies the minimum information required to report the use of a
mass spectrometer in a proteomics experiment. The mzML format has been
designed to encode the requirements specified in MIAPE MS. However, mzML
does not enforce MIAPE compliance itself; mzML documents may be valid and
useful without being fully MIAPE compliant. The mzML validator has settings
to validate at either the basic mzML level or at a MIAPE MS compliant level,
depending on the needs of the user.

2.      spML (http://www.psidev.info/index.php?q=node/90). spML (sample
processing Markup Language) is the proposed PSI standard for describing
general protein separation and sample processing other than gel
electrophoresis. GelML is being developed separately from spML because there
is a well defined community associated with gel electrophoresis. As both
GelML and spML build on FuGE (Functional Genomics Experiment) (Jones, Miller
et al. 2007) and use FuGE to describe the relationships between steps in a
proteomics workflow, they will be designed to be straightforward to use
together where appropriate. This document does not assume familiarity with
spML.

3.      mzIdentML (http://www.psidev.info/index.php?q=node/85). The
mzIdentML specification is being developed by the PSI as a standard to
capture the output of search engines that assign mass spectra to protein or
peptide sequences. It is FuGE-based and will provide a UML model as well as
an XML schema. It is anticipated that mzML will serve as an important
'input' to the model defined by mzIdentML. This document does not assume
familiarity with mzIdentML or FuGE.

 

Does that seem good?

 

Thanks,

Eric

 

 

 

 

 

> -----Original Message-----

> From: Jones, Andy [mailto:And...@li...]

> Sent: Thursday, May 21, 2009 8:24 AM

> To: 'Mass spectrometry standard development'

> Subject: [Psidev-ms-dev] Minor spec doc comment

> 

> Hi all,

> 

> I noticed a minor error in the mzML spec doc:

> 

> 2.2  Relationship to Other Specifications

> 

> I think this section was copied and pasted from the GelML specification so

> doesn't make a lot of sense - I would remove sub-sections 2-4. Could you

> also change subsection 5 from analysisXML to mzIdentML if this isn't too

> late for changes ;-)

> 

> Cheers

> Andy

> 

> 

> 

> --------------------------------------------------------------------------

> ----

> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT

> is a gathering of tech-side developers & brand creativity professionals.

> Meet

> the minds behind Google Creative Lab, Visual Complexity, Processing, &

> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian

> Group, R/GA, & Big Spaceship. http://www.creativitycat.com

> _______________________________________________

> Psidev-ms-dev mailing list

> Psi...@li...

> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Silly question about possible encodings in mzML.

[Brian P. <bri...@in...>]

Perhaps even 8 and 16 bit?  32 bit seems like overkill for a charge state
(unless you're using compression, of course).

 

Brian

 

  _____  

From: Angel Pizarro [mailto:an...@ma...] 
Sent: Monday, June 08, 2009 9:44 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Silly question about possible encodings in
mzML.

 

I agree with Matt here. 

-a

On Mon, Jun 8, 2009 at 12:38 PM, Matthew Chambers
<mat...@va...> wrote:

Is it sensible to store charge state array in a floating point type? I
think we may need to bring back the 32 and 64 bit integer types.

-Matt



Marc Sturm wrote:
> Hi Lennart,
>
> These are the possible combinations:
>
> + MS:1000518 ! binary data type (children only)
>     - MS:1000521 ! 32-bit float
>     - MS:1000523 ! 64-bit float
> + MS:1000572 ! binary data compression type (children only)
>     - MS:1000574 ! zlib compression
>     - MS:1000576 ! no compression
>
> I think it's always little endian.
>
> Best,
>   Marc
>
>> Dear PSI-MS Enthousiasts,
>>
>>
>> I have a really silly question, which I guess I should know, but I'll
>> put forward that I've missed a few too many meetings and calls recently.
>>
>> The question is: which data encodings can we expect in mzML binary
arrays?
>>
>> Is it simply bzipped/non-bzipped base64 (little-endian), or am I missing
>> some other possible options? And I further assume bzipping to be flagged
>> by a CV param?
>>
>>
>>
>> Thanks in advance,
>>
>> lnnrt.
>>
>>
----------------------------------------------------------------------------
--
>> 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
>>
>>
>
>
>
----------------------------------------------------------------------------
--
> 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
>

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




-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-ms-dev] Silly question about possible encodings in mzML.

[Angel P. <an...@ma...>]

I agree with Matt here. -a

On Mon, Jun 8, 2009 at 12:38 PM, Matthew Chambers <
mat...@va...> wrote:

> Is it sensible to store charge state array in a floating point type? I
> think we may need to bring back the 32 and 64 bit integer types.
>
> -Matt
>
>
> Marc Sturm wrote:
> > Hi Lennart,
> >
> > These are the possible combinations:
> >
> > + MS:1000518 ! binary data type (children only)
> >     - MS:1000521 ! 32-bit float
> >     - MS:1000523 ! 64-bit float
> > + MS:1000572 ! binary data compression type (children only)
> >     - MS:1000574 ! zlib compression
> >     - MS:1000576 ! no compression
> >
> > I think it's always little endian.
> >
> > Best,
> >   Marc
> >
> >> Dear PSI-MS Enthousiasts,
> >>
> >>
> >> I have a really silly question, which I guess I should know, but I'll
> >> put forward that I've missed a few too many meetings and calls recently.
> >>
> >> The question is: which data encodings can we expect in mzML binary
> arrays?
> >>
> >> Is it simply bzipped/non-bzipped base64 (little-endian), or am I missing
> >> some other possible options? And I further assume bzipping to be flagged
> >> by a CV param?
> >>
> >>
> >>
> >> Thanks in advance,
> >>
> >> lnnrt.
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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
> >>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
> ------------------------------------------------------------------------------
> 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
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-ms-dev] Silly question about possible encodings in mzML.

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

Is it sensible to store charge state array in a floating point type? I 
think we may need to bring back the 32 and 64 bit integer types.

-Matt


Marc Sturm wrote:
> Hi Lennart,
>
> These are the possible combinations:
>
> + MS:1000518 ! binary data type (children only)
>     - MS:1000521 ! 32-bit float
>     - MS:1000523 ! 64-bit float
> + MS:1000572 ! binary data compression type (children only)
>     - MS:1000574 ! zlib compression
>     - MS:1000576 ! no compression
>
> I think it's always little endian.
>
> Best,
>   Marc
>   
>> Dear PSI-MS Enthousiasts,
>>
>>
>> I have a really silly question, which I guess I should know, but I'll 
>> put forward that I've missed a few too many meetings and calls recently.
>>
>> The question is: which data encodings can we expect in mzML binary arrays?
>>
>> Is it simply bzipped/non-bzipped base64 (little-endian), or am I missing 
>> some other possible options? And I further assume bzipping to be flagged 
>> by a CV param?
>>
>>
>>
>> Thanks in advance,
>>
>> lnnrt.
>>
>> ------------------------------------------------------------------------------
>> 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
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> 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
>   

Re: [Psidev-ms-dev] Silly question about possible encodings in mzML.

[Marc S. <st...@in...>]

Hi Lennart,

These are the possible combinations:

+ MS:1000518 ! binary data type (children only)
    - MS:1000521 ! 32-bit float
    - MS:1000523 ! 64-bit float
+ MS:1000572 ! binary data compression type (children only)
    - MS:1000574 ! zlib compression
    - MS:1000576 ! no compression

I think it's always little endian.

Best,
  Marc
> Dear PSI-MS Enthousiasts,
>
>
> I have a really silly question, which I guess I should know, but I'll 
> put forward that I've missed a few too many meetings and calls recently.
>
> The question is: which data encodings can we expect in mzML binary arrays?
>
> Is it simply bzipped/non-bzipped base64 (little-endian), or am I missing 
> some other possible options? And I further assume bzipping to be flagged 
> by a CV param?
>
>
>
> Thanks in advance,
>
> lnnrt.
>
> ------------------------------------------------------------------------------
> 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
>   

[Psidev-ms-dev] Silly question about possible encodings in mzML.

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthousiasts,


I have a really silly question, which I guess I should know, but I'll 
put forward that I've missed a few too many meetings and calls recently.

The question is: which data encodings can we expect in mzML binary arrays?

Is it simply bzipped/non-bzipped base64 (little-endian), or am I missing 
some other possible options? And I further assume bzipping to be flagged 
by a CV param?



Thanks in advance,

lnnrt.

Re: [Psidev-ms-dev] Problem parsing mzML.xsd RC6, with patch

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

Hi Steffen, yes, this fix has now been committed. Please let us know if this
does not fix your problem.

Thanks,
Eric


> -----Original Message-----
> From: Steffen Neumann [mailto:sne...@ip...]
> Sent: Wednesday, June 03, 2009 10:44 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Problem parsing mzML.xsd RC6, with patch
> 
> Hi,
> 
> Has this been fixed ?
> 
> Yours,
> Steffen
> 
> On Thu, 2009-05-28 at 22:32 +0200, Steffen Neumann wrote:
> > Hi,
> >
> > I tried to create an Eclipse EMF model
> > from the mzML RC6 XSD.
> >
> > I haven't found out how to cut&paste the full error,
> > therefor these two screenshots :-(
> >
> > The problem are extra spaces " " in the xpath expressions:
> >
> > 	<xs:selector xpath=".//dx:precursor |.//dx:scan" />
> > 	                                   ^^
> > below is a patch which cleans those up.
> >
> > Yours,
> > Steffen
> >
> >
> >
> > --- mzML1.1.0.xsd	2009-05-28 22:25:33.000000000 +0200
> > +++ mzML1.1.0clean.xsd	2009-05-28 22:31:05.000000000 +0200
> > @@ -1029,7 +1029,7 @@
> >            This is a reference to a source file in sourceFileList. It
> ensures that an id is present in the file and is one of the values defined
> in KEY_SOURCEFILE_ID.
> >          </xs:documentation>
> >        </xs:annotation>
> > -      <xs:selector xpath=".//dx:precursor |.//dx:scan" />
> > +      <xs:selector xpath=".//dx:precursor|.//dx:scan" />
> >        <xs:field xpath="@sourceFileRef" />
> >      </xs:keyref>
> >      <xs:keyref name="KEYREF_RUN_SAMPLEREF" refer="dx:KEY_SAMPLE_ID">
> > @@ -1056,7 +1056,7 @@
> >            This is a reference to a data processing element in
> dataProcessingList. It ensures that an id is present in the file and is
> one of the values defined in KEY_DP_ID.
> >          </xs:documentation>
> >        </xs:annotation>
> > -      <xs:selector xpath="./dx:run/dx:spectrumList
> |./dx:run/dx:chromatogramList" />
> > +      <xs:selector
> xpath="./dx:run/dx:spectrumList|./dx:run/dx:chromatogramList" />
> >        <xs:field xpath="@defaultDataProcessingRef" />
> >      </xs:keyref>
> >      <xs:keyref name="KEYREF_DPREF" refer="dx:KEY_DP_ID">
> > @@ -1065,7 +1065,7 @@
> >            This is a reference to a data processing element in
> dataProcessingList. It ensures that an id is present in the file and is
> one of the values defined in KEY_DP_ID.
> >          </xs:documentation>
> >        </xs:annotation>
> > -      <xs:selector xpath=".//dx:spectrum |.//dx:chromatogram
> |.//dx:binaryDataArray" />
> > +      <xs:selector
> xpath=".//dx:spectrum|.//dx:chromatogram|.//dx:binaryDataArray" />
> >        <xs:field xpath="@dataProcessingRef" />
> >      </xs:keyref>
> >      <xs:keyref name="KEYREF_CVREF" refer="dx:KEY_CV_ID">
> > @@ -1083,7 +1083,7 @@
> >            This is a reference to the CV in cvList used for unit terms.
> It ensures that an id is present in the file and is one of the values
> defined in KEY_CV_ID.
> >          </xs:documentation>
> >        </xs:annotation>
> > -      <xs:selector xpath=".//dx:cvParam |.//dx:userParam" />
> > +      <xs:selector xpath=".//dx:cvParam|.//dx:userParam" />
> >        <xs:field xpath="@unitCvRef" />
> >      </xs:keyref>
> >      <xs:keyref name="KEYREF_RPGREF" refer="dx:KEY_RPG_ID">
> > @@ -1101,7 +1101,7 @@
> >            This is a reference to an instrument configuration in
> instrumentConfigurationList. It ensures that an id is present in the file
> and is one of the values defined in KEY_IC_ID.
> >          </xs:documentation>
> >        </xs:annotation>
> > -      <xs:selector xpath="./dx:run/dx:spectrumList
> |./dx:run/dx:chromatogramList" />
> > +      <xs:selector
> xpath="./dx:run/dx:spectrumList|./dx:run/dx:chromatogramList" />
> >        <xs:field xpath="@defaultInstrumentConfigurationRef" />
> >      </xs:keyref>
> >      <xs:keyref name="KEYREF_ICREF" refer="dx:KEY_IC_ID">
> >
> > ------------------------------------------------------------------------
> ------
> > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> > is a gathering of tech-side developers & brand creativity professionals.
> Meet
> > the minds behind Google Creative Lab, Visual Complexity, Processing, &
> > iPhoneDevCamp as they present alongside digital heavyweights like
> Barbarian
> > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> > _______________________________________________ Psidev-ms-dev mailing
> list Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> 
> --------------------------------------------------------------------------
> ----
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Problem parsing mzML.xsd RC6, with patch

[Steffen N. <sne...@ip...>]

Hi,

Has this been fixed ?

Yours,
Steffen

On Thu, 2009-05-28 at 22:32 +0200, Steffen Neumann wrote:
> Hi,
> 
> I tried to create an Eclipse EMF model 
> from the mzML RC6 XSD. 
> 
> I haven't found out how to cut&paste the full error, 
> therefor these two screenshots :-(
> 
> The problem are extra spaces " " in the xpath expressions:
> 
> 	<xs:selector xpath=".//dx:precursor |.//dx:scan" />
> 	                                   ^^
> below is a patch which cleans those up.
> 
> Yours,
> Steffen
> 
> 
> 
> --- mzML1.1.0.xsd	2009-05-28 22:25:33.000000000 +0200
> +++ mzML1.1.0clean.xsd	2009-05-28 22:31:05.000000000 +0200
> @@ -1029,7 +1029,7 @@
>            This is a reference to a source file in sourceFileList. It ensures that an id is present in the file and is one of the values defined in KEY_SOURCEFILE_ID.
>          </xs:documentation>
>        </xs:annotation>
> -      <xs:selector xpath=".//dx:precursor |.//dx:scan" />
> +      <xs:selector xpath=".//dx:precursor|.//dx:scan" />
>        <xs:field xpath="@sourceFileRef" />
>      </xs:keyref>
>      <xs:keyref name="KEYREF_RUN_SAMPLEREF" refer="dx:KEY_SAMPLE_ID">
> @@ -1056,7 +1056,7 @@
>            This is a reference to a data processing element in dataProcessingList. It ensures that an id is present in the file and is one of the values defined in KEY_DP_ID.
>          </xs:documentation>
>        </xs:annotation>
> -      <xs:selector xpath="./dx:run/dx:spectrumList |./dx:run/dx:chromatogramList" />
> +      <xs:selector xpath="./dx:run/dx:spectrumList|./dx:run/dx:chromatogramList" />
>        <xs:field xpath="@defaultDataProcessingRef" />
>      </xs:keyref>
>      <xs:keyref name="KEYREF_DPREF" refer="dx:KEY_DP_ID">
> @@ -1065,7 +1065,7 @@
>            This is a reference to a data processing element in dataProcessingList. It ensures that an id is present in the file and is one of the values defined in KEY_DP_ID.
>          </xs:documentation>
>        </xs:annotation>
> -      <xs:selector xpath=".//dx:spectrum |.//dx:chromatogram |.//dx:binaryDataArray" />
> +      <xs:selector xpath=".//dx:spectrum|.//dx:chromatogram|.//dx:binaryDataArray" />
>        <xs:field xpath="@dataProcessingRef" />
>      </xs:keyref>
>      <xs:keyref name="KEYREF_CVREF" refer="dx:KEY_CV_ID">
> @@ -1083,7 +1083,7 @@
>            This is a reference to the CV in cvList used for unit terms. It ensures that an id is present in the file and is one of the values defined in KEY_CV_ID.
>          </xs:documentation>
>        </xs:annotation>
> -      <xs:selector xpath=".//dx:cvParam |.//dx:userParam" />
> +      <xs:selector xpath=".//dx:cvParam|.//dx:userParam" />
>        <xs:field xpath="@unitCvRef" />
>      </xs:keyref>
>      <xs:keyref name="KEYREF_RPGREF" refer="dx:KEY_RPG_ID">
> @@ -1101,7 +1101,7 @@
>            This is a reference to an instrument configuration in instrumentConfigurationList. It ensures that an id is present in the file and is one of the values defined in KEY_IC_ID.
>          </xs:documentation>
>        </xs:annotation>
> -      <xs:selector xpath="./dx:run/dx:spectrumList |./dx:run/dx:chromatogramList" />
> +      <xs:selector xpath="./dx:run/dx:spectrumList|./dx:run/dx:chromatogramList" />
>        <xs:field xpath="@defaultInstrumentConfigurationRef" />
>      </xs:keyref>
>      <xs:keyref name="KEYREF_ICREF" refer="dx:KEY_IC_ID">
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________ Psidev-ms-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Problem parsing mzML.xsd RC6, with patch

[Steffen N. <sne...@ip...>]

Hi,

I tried to create an Eclipse EMF model 
from the mzML RC6 XSD. 

I haven't found out how to cut&paste the full error, 
therefor these two screenshots :-(

The problem are extra spaces " " in the xpath expressions:

	<xs:selector xpath=".//dx:precursor |.//dx:scan" />
	                                   ^^
below is a patch which cleans those up.

Yours,
Steffen



--- mzML1.1.0.xsd	2009-05-28 22:25:33.000000000 +0200
+++ mzML1.1.0clean.xsd	2009-05-28 22:31:05.000000000 +0200
@@ -1029,7 +1029,7 @@
           This is a reference to a source file in sourceFileList. It ensures that an id is present in the file and is one of the values defined in KEY_SOURCEFILE_ID.
         </xs:documentation>
       </xs:annotation>
-      <xs:selector xpath=".//dx:precursor |.//dx:scan" />
+      <xs:selector xpath=".//dx:precursor|.//dx:scan" />
       <xs:field xpath="@sourceFileRef" />
     </xs:keyref>
     <xs:keyref name="KEYREF_RUN_SAMPLEREF" refer="dx:KEY_SAMPLE_ID">
@@ -1056,7 +1056,7 @@
           This is a reference to a data processing element in dataProcessingList. It ensures that an id is present in the file and is one of the values defined in KEY_DP_ID.
         </xs:documentation>
       </xs:annotation>
-      <xs:selector xpath="./dx:run/dx:spectrumList |./dx:run/dx:chromatogramList" />
+      <xs:selector xpath="./dx:run/dx:spectrumList|./dx:run/dx:chromatogramList" />
       <xs:field xpath="@defaultDataProcessingRef" />
     </xs:keyref>
     <xs:keyref name="KEYREF_DPREF" refer="dx:KEY_DP_ID">
@@ -1065,7 +1065,7 @@
           This is a reference to a data processing element in dataProcessingList. It ensures that an id is present in the file and is one of the values defined in KEY_DP_ID.
         </xs:documentation>
       </xs:annotation>
-      <xs:selector xpath=".//dx:spectrum |.//dx:chromatogram |.//dx:binaryDataArray" />
+      <xs:selector xpath=".//dx:spectrum|.//dx:chromatogram|.//dx:binaryDataArray" />
       <xs:field xpath="@dataProcessingRef" />
     </xs:keyref>
     <xs:keyref name="KEYREF_CVREF" refer="dx:KEY_CV_ID">
@@ -1083,7 +1083,7 @@
           This is a reference to the CV in cvList used for unit terms. It ensures that an id is present in the file and is one of the values defined in KEY_CV_ID.
         </xs:documentation>
       </xs:annotation>
-      <xs:selector xpath=".//dx:cvParam |.//dx:userParam" />
+      <xs:selector xpath=".//dx:cvParam|.//dx:userParam" />
       <xs:field xpath="@unitCvRef" />
     </xs:keyref>
     <xs:keyref name="KEYREF_RPGREF" refer="dx:KEY_RPG_ID">
@@ -1101,7 +1101,7 @@
           This is a reference to an instrument configuration in instrumentConfigurationList. It ensures that an id is present in the file and is one of the values defined in KEY_IC_ID.
         </xs:documentation>
       </xs:annotation>
-      <xs:selector xpath="./dx:run/dx:spectrumList |./dx:run/dx:chromatogramList" />
+      <xs:selector xpath="./dx:run/dx:spectrumList|./dx:run/dx:chromatogramList" />
       <xs:field xpath="@defaultInstrumentConfigurationRef" />
     </xs:keyref>
     <xs:keyref name="KEYREF_ICREF" refer="dx:KEY_IC_ID">

Re: [Psidev-ms-dev] TraML Validator available (alpha version)

[Andreas B. <be...@in...>]

Ok as Marc said, the correct URL is with a '/' at the end:


http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/TraML/

> da fehlt ein / am Ende:
> So geht es nicht von außen...

--
Div. for Simulation of Biological Systems, WSI, University of Tuebingen
Room C322, Sand 14, 72076 Tuebingen, Germany
phone: +49-7071-29-70461 fax: +49-7071-29-5152
http://www-bs.informatik.uni-tuebingen.de

Re: [Psidev-ms-dev] TraML Validator available (alpha version)

[Marc S. <st...@in...>]

sorry, for the last post. It was meant for Andreas only. The correct URL is

http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/TraML/

-Marc




> Hi psi-ms enthusiasts,
>
> as promised, I created a alpha version of the TraML validator. The URL  
> is
>
> http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/TraML
>
> At the bottom is the output of the validation of the toy example.
>
>
> Cheers,
> A.
>
>
>
>
>
>
>
>
>
>
> There are not many files to validate at the moment ;) the toy example  
> gives the fallowing errors/warnings:
>
> Upload: Successfully uploaded the file ToyExample1.TraML.
>
> Validation against the schema:
> Success: the file is valid!
>
> Semantic validation:
> All reported errors are only reported once, in arbitrary order:
>
> CV term must have a unit: MS:1000045 - collision energy
> CV term must have a unit: MS:1000502 - dwell time
> CV term must have a unit: MS:1000869 - collision gas pressure
> CV term must have a unit: MS:1000875 - declustering potential
> CV term must have a unit: MS:1000876 - cone voltage
> CV term must have a unit: MS:1000877 - tube lens
> CV term must have a unit: MS:1001117 - theoretical mass
> CV term used in invalid element: 'MS:1000857 - interchannel delay' at  
> element '/TraML/transitionList/transition/configurationList/ 
> configuration'
> Name of CV term not correct: 'MS:1000587 - contact organization'  
> should be 'contact address'
> Name of CV term not correct: 'MS:1000857 - interchannel delay' should  
> be 'run attribute'
> Name of CV term not correct: 'MS:1000863 - predicted pI' should be  
> 'predicted isoelectric point'
> Value of CV term not allowed: 'MS:1000857 - interchannel delay'  
> value='0.01' at element '/TraML/transitionList/transition/ 
> configurationList/configuration'
> Value of CV term not allowed: 'MS:1000863 - predicted pI' value='5.22'  
> at element '/TraML/compoundList/peptide'
> Value of CV term not allowed: 'MS:1000866 - molecular formula'  
> value='C2HO3' at element '/TraML/compoundList/compound'
> Value of CV term not allowed: 'MS:1000868 - SMILES string' value='[CH] 
> (=[O])[C](=[O])[O-]' at element '/TraML/compoundList/compound'
> Violated mapping rule 'configuration_may' number of term repeats at  
> element '/TraML/transitionList/transition/configurationList/ 
> configuration'
> Violated mapping rule 'contact_must' at element '/TraML/contactList/ 
> contact', 2 should be present, 1 found!
>
>
> --
> Div. for Simulation of Biological Systems, WSI, University of Tuebingen
> Room C322, Sand 14, 72076 Tuebingen, Germany
> phone: +49-7071-29-70461 fax: +49-7071-29-5152
> http://www-bs.informatik.uni-tuebingen.de
>
>
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] TraML Validator available (alpha version)

[Marc S. <st...@in...>]

Hi Andreas,

da fehlt ein / am Ende:

http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/TraML

So geht es nicht von außen...

Viele Grüße,
  Marc


> as promised, I created a alpha version of the TraML validator. The URL  
> is
>
> http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/TraML
>
> At the bottom is the output of the validation of the toy example.
>
>
> Cheers,
> A.
>
>
>
>
>
>
>
>
>
>
> There are not many files to validate at the moment ;) the toy example  
> gives the fallowing errors/warnings:
>
> Upload: Successfully uploaded the file ToyExample1.TraML.
>
> Validation against the schema:
> Success: the file is valid!
>
> Semantic validation:
> All reported errors are only reported once, in arbitrary order:
>
> CV term must have a unit: MS:1000045 - collision energy
> CV term must have a unit: MS:1000502 - dwell time
> CV term must have a unit: MS:1000869 - collision gas pressure
> CV term must have a unit: MS:1000875 - declustering potential
> CV term must have a unit: MS:1000876 - cone voltage
> CV term must have a unit: MS:1000877 - tube lens
> CV term must have a unit: MS:1001117 - theoretical mass
> CV term used in invalid element: 'MS:1000857 - interchannel delay' at  
> element '/TraML/transitionList/transition/configurationList/ 
> configuration'
> Name of CV term not correct: 'MS:1000587 - contact organization'  
> should be 'contact address'
> Name of CV term not correct: 'MS:1000857 - interchannel delay' should  
> be 'run attribute'
> Name of CV term not correct: 'MS:1000863 - predicted pI' should be  
> 'predicted isoelectric point'
> Value of CV term not allowed: 'MS:1000857 - interchannel delay'  
> value='0.01' at element '/TraML/transitionList/transition/ 
> configurationList/configuration'
> Value of CV term not allowed: 'MS:1000863 - predicted pI' value='5.22'  
> at element '/TraML/compoundList/peptide'
> Value of CV term not allowed: 'MS:1000866 - molecular formula'  
> value='C2HO3' at element '/TraML/compoundList/compound'
> Value of CV term not allowed: 'MS:1000868 - SMILES string' value='[CH] 
> (=[O])[C](=[O])[O-]' at element '/TraML/compoundList/compound'
> Violated mapping rule 'configuration_may' number of term repeats at  
> element '/TraML/transitionList/transition/configurationList/ 
> configuration'
> Violated mapping rule 'contact_must' at element '/TraML/contactList/ 
> contact', 2 should be present, 1 found!
>
>
> --
> Div. for Simulation of Biological Systems, WSI, University of Tuebingen
> Room C322, Sand 14, 72076 Tuebingen, Germany
> phone: +49-7071-29-70461 fax: +49-7071-29-5152
> http://www-bs.informatik.uni-tuebingen.de
>
>
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] TraML Validator available (alpha version)

[Andreas B. <be...@in...>]

Hi psi-ms enthusiasts,

as promised, I created a alpha version of the TraML validator. The URL  
is

http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/TraML

At the bottom is the output of the validation of the toy example.


Cheers,
A.










There are not many files to validate at the moment ;) the toy example  
gives the fallowing errors/warnings:

Upload: Successfully uploaded the file ToyExample1.TraML.

Validation against the schema:
Success: the file is valid!

Semantic validation:
All reported errors are only reported once, in arbitrary order:

CV term must have a unit: MS:1000045 - collision energy
CV term must have a unit: MS:1000502 - dwell time
CV term must have a unit: MS:1000869 - collision gas pressure
CV term must have a unit: MS:1000875 - declustering potential
CV term must have a unit: MS:1000876 - cone voltage
CV term must have a unit: MS:1000877 - tube lens
CV term must have a unit: MS:1001117 - theoretical mass
CV term used in invalid element: 'MS:1000857 - interchannel delay' at  
element '/TraML/transitionList/transition/configurationList/ 
configuration'
Name of CV term not correct: 'MS:1000587 - contact organization'  
should be 'contact address'
Name of CV term not correct: 'MS:1000857 - interchannel delay' should  
be 'run attribute'
Name of CV term not correct: 'MS:1000863 - predicted pI' should be  
'predicted isoelectric point'
Value of CV term not allowed: 'MS:1000857 - interchannel delay'  
value='0.01' at element '/TraML/transitionList/transition/ 
configurationList/configuration'
Value of CV term not allowed: 'MS:1000863 - predicted pI' value='5.22'  
at element '/TraML/compoundList/peptide'
Value of CV term not allowed: 'MS:1000866 - molecular formula'  
value='C2HO3' at element '/TraML/compoundList/compound'
Value of CV term not allowed: 'MS:1000868 - SMILES string' value='[CH] 
(=[O])[C](=[O])[O-]' at element '/TraML/compoundList/compound'
Violated mapping rule 'configuration_may' number of term repeats at  
element '/TraML/transitionList/transition/configurationList/ 
configuration'
Violated mapping rule 'contact_must' at element '/TraML/contactList/ 
contact', 2 should be present, 1 found!


--
Div. for Simulation of Biological Systems, WSI, University of Tuebingen
Room C322, Sand 14, 72076 Tuebingen, Germany
phone: +49-7071-29-70461 fax: +49-7071-29-5152
http://www-bs.informatik.uni-tuebingen.de

[Psidev-ms-dev] Electron capture detector chromatogram

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

Does this chromatogram fit under existing chromatogram terms? This kind 
of data doesn't have a spectrum representation. The Y axis is counts per 
<time unit>.

-Matt

[Psidev-ms-dev] imzML term units

[Marc S. <stu...@gm...>]

Hi all,

I just noticed that the units of the MALDI laser terms are still a bit 
too permissive.
Here my suggestions as a basis for discussion - I'm not really sure they 
make senes:

MS:1000843 ! wavelength (UO:0000001!length unit)
  => UO:0000018!nanometer

MS:1000844 ! focus diameter x (UO:0000001!length unit)
  => UO:0000018!nanometer ?

MS:1000845 ! focus diameter y (UO:0000001!length unit)
  => UO:0000018!nanometer ?

MS:1000846 ! pulse energy (UO:0000111!energy unit)
  => UO:0000266!electronvolt ?

MS:1000847 ! pulse duration (UO:0000003!time unit)
  => UO:0000028!millisecond ?

MS:1000848 ! attenuation (UO:0000003!time unit)
  => UO:0000028!millisecond ?

MS:1000849 ! impact angle (UO:0000121!angle unit)
  => UO:0000185!degree ?

MS:1000835 ! matrix solution concentration (UO:0000051!concentration unit)
  => UO:0000175!gram per liter

-Marc

[Psidev-ms-dev] PSI-MSS WG call notes

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

Present: Matt, Jim, Marc, Eric, Fredrik

 

Agenda:

1) mzML 1.1.0

- chromatogram type issue

+ Add 3 new terms: SIM / SRM chromatograms, under mass chromatogram

+ mapping file it already up to date

+ Eric will send around the poster and print it

+ Matt will add the terms

+ Marc and Andreas R updated mapping file for MALDI support

+ Marc also fixed up the mapping file

+ Marc checked everything into SVN/CVS

+ Eric will add to documentation: for SRM, always use chromatograms except
for profile mode SRMs

+ Matt will obsolete CRM chromatogram terms, but leave spectrum

+ Matt will update the mapping file for chromatogram terms and alert
Fredrik, Marc, Eric

+ Once all this is done, then resubmit to PSI editors as finished

+ Double check that all examples on web site still validate

 

----

2) Need to update the mzML implementations catalog

+ Eric will update web site based on Excel sheet

 

----

3) MIAPE-MS revision

- Have revised document to discuss at ASMS

+ Pierre-Alain will send

 

----

4) TraML development

+ Eric sent around a draft of the poster and got some feedback

+ Change the schema to use ParamType (both cvParam and userParam) instead of
just cvParam

+ Contact is fine for TraML. At some future time, align mzML contact with
TraML

+ At some point, try embedding TraML in mzML

 

No phonecon next week during ASMS, but continue thereafter.

 

 

 

 

 

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

[Darren K. <da...@pr...>]

Hey Eric,

I'm taking care of some car trouble, so I can't be on the conference
call this morning.


Darren




On Mon, May 25, 2009 at 8:34 AM, Eric Deutsch
<ede...@sy...> wrote:
> Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
> will be Tuesday 8am PDT:
>
>
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=5&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
>
>
>
> ----
>
> 2) Need to update the mzML implementations catalog
>
>
>
> ----
>
> 3) MIAPE-MS revision
>
> - Have revised document to discuss at ASMS
>
>
>
> ----
>
> 4) TraML development
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>

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

[Pierre-Alain B. <pie...@is...>]

Hi all,
I might be missing the call (travelling). I will make sure Eric gets the 
revised proposal doc for MIAPE MS before the ASMS
Pierre-Alain

Eric Deutsch wrote:
>
> Hi everyone, the next PSI Mass Spectrometry Standards Working Group 
> call will be Tuesday 8am PDT:
>
>  
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=5&year=2009&hour=16&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=5&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
>
>  
>
> ----
>
> 2) Need to update the mzML implementations catalog
>
>  
>
> ----
>
> 3) MIAPE-MS revision
>
> - Have revised document to discuss at ASMS
>
>  
>
> ----
>
> 4) TraML development
>
>  
>
>  
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

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

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

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
will be Tuesday 8am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=19
<http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=5&year=20
09&hour=16&min=0&sec=0&p1=136> &month=5&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

 

----

2) Need to update the mzML implementations catalog

 

----

3) MIAPE-MS revision

- Have revised document to discuss at ASMS

 

----

4) TraML development