psidev-ms-dev — Mass spectroscopy standard development

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

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

+ Present: Matt, Jim, Fredrik, Andreas, Eric



Agenda:

1) World HUPO Congress results

 - Saturday PSI session with mzML and TraML presentations

 - mzML 1.1 poster and presentation

 - TraML 0.9 poster

 - MIAPE-MS discussions with journals

 - Other?

+ Eric gives a summary of the results from HUPO



----

2) mzML 1.1.0

- Manuscript plans? Aim for end of October?

- Other?

+ MS3+ spectra topic from list on 2009-09-22:

+ As long as the MS(n-1) scan is available, then the previous precursor is
available in the previous scan

+ Eric: update documentation on how MS3+ precursor information is to be
encoded



+ How do we encode the case where one has an ambiguous charge state and one
wants to encode both hypotheses in the mzML

+ Matt will come up with an example of how that might look in mzML



----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

+ Discuss with Pierre-Alain

+ MIAPE-MS update



----

3) TraML development

  http://www.psidev.info/index.php?q=node/405

- Aim to submit specification to document process by end of October

- Implementations?

- What do we do with the <interpretation> cvParams insufficiency problem?

- Add a new <targetList> section for inclusion and exclusion precursor
targets

- TarML? There already is a TARML in the universe.. Temporal Authorization
Rule Markup Language

- Maybe Andreas can help with inclusion/exclusion examples

+ Andreas is working on updating OpenMS to 0.9

+ Put <targetIncludeList> and exclude in a container <targetList> with CV
term to indicate precendence.

+ Eric will send out email on that.

- David Cox at Sciex would like to do some test implementation

+ Andreas will update implementation

+ Jim will update his implementation

+ Matt will update his implementation in ProteoWizard



+ Meet again in two weeks







*From:* Eric Deutsch [mailto:ede...@sy...]
*Sent:* Monday, October 05, 2009 11:30 PM
*To:* 'Mass spectrometry standard development'
*Cc:* Eric Deutsch
*Subject:* PSI-MSS WG 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=06&month=10&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) World HUPO Congress results

 - Saturday PSI session with mzML and TraML presentations

 - mzML 1.1 poster and presentation

 - TraML 0.9 poster

 - MIAPE-MS discussions with journals

 - Other?



----

2) mzML 1.1.0

- Manuscript plans? Aim for end of October?

- Other?



----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.



----

3) TraML development

  http://www.psidev.info/index.php?q=node/405

- Aim to submit specification to document process by end of October

- Implementations?

- What do we do with the <interpretation> cvParams insufficiency problem?

- Add a new <targetList> section for inclusion and exclusion precursor
targets

- TarML? There already is a TARML in the universe.. Temporal Authorization
Rule Markup Language

- Maybe Andreas can help with inclusion/exclusion examples

- David Cox at Sciex would like to do some test implementation

[Psidev-ms-dev] PSI-MSS WG 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=06
<http://www.timeanddate.com/worldclock/fixedtime.html?day=06&month=10&year=2
009&hour=16&min=0&sec=0&p1=136>
&month=10&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) World HUPO Congress results

 - Saturday PSI session with mzML and TraML presentations

 - mzML 1.1 poster and presentation

 - TraML 0.9 poster

 - MIAPE-MS discussions with journals

 - Other?

 

----

2) mzML 1.1.0

- Manuscript plans? Aim for end of October?

- Other?

 

----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

 

----

3) TraML development

   <http://www.psidev.info/index.php?q=node/405>
http://www.psidev.info/index.php?q=node/405

- Aim to submit specification to document process by end of October

- Implementations?

- What do we do with the <interpretation> cvParams insufficiency problem?

- Add a new <targetList> section for inclusion and exclusion precursor
targets

- TarML? There already is a TARML in the universe.. Temporal Authorization
Rule Markup Language

- Maybe Andreas can help with inclusion/exclusion examples

- David Cox at Sciex would like to do some test implementation

 

 

Re: [Psidev-ms-dev] possible charge states and etd

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

Hi Chris,

I'm forwarding to psidev-ms since this is very relevant there.

In mzML, there is a special mechanism for storing a spectrum that is 
derived from other spectra: combined/merged spectra. I think with 
sufficient hackishness we could use the same mechanism to replace the 
original spectrum with multiple merged spectra that aren't really 
merged, but are just processed different ways and end up with different 
metadata (a hypothesized charge state instead of a possible charge 
state) and different binary data (different precursor peaks removed). 
The concept is reasonable, but the "merged=" id prefix should probably 
be augmented with "processed=" or something like that. The scanList 
would be the way that the processed version maps back to the original one.

-Matt


Chris Paulse wrote:
>
> For spectra where the precursor is either not confidently identified 
> as having a definitive charge state, or where two precursors with 
> different charge states co-fragment, it becomes a bit hard for me to 
> figure out what to do during the ms2 precursor removal step. There’s 
> an existing program called DTAGenerator that for cases where the 
> precursor charge is unknown, creates a separate spectrum record for 
> each assumed parent charge, and performs unfragmented precursor 
> removal for each hypothesis. This creates obvious problems for 
> downstream processing.
>
> On the other hand, it might not be the best idea to remove all charge 
> reduced precursors for all possible charge states in a single spectrum 
> before searching. The search task should have some way of generating 
> multiple hypotheses, and merging/filtering search results for the 
> given observation.
>
> I’m working with the Charge Prediction Machine program to identify 
> charge states for low resolution spectra – Zhi Sun wrote a perl script 
> that incorporates it into tpp. The idea would be to take the output of 
> this step (an mzXML file) and run msconvert on it. CPM does not 
> discriminate between indeterminate precursor charge and multi-charge 
> precursors. The author says that this is hard to do in practice 
> (probably because of lack of training data?). You might be aware that 
> Jimmy Eng has done some work to create an SVM equivalent of Charge 
> Prediction Machine, but this is still early in development.
>
> Do you see how this might impact the design of the precursor removal 
> spectrum filter?
>
> Thanks!
>
> Chris
>

Re: [Psidev-ms-dev] MS3+ spectra

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

A product ion spectrum that was produced from multiple isolation windows 
would need multiple precursors. I don't know if there's an instrument 
that can or does do this, but it's easy to imagine an instrument which 
can isolate each peak of an isotope envelope instead of isolating a wide 
window around all the isotopes (and all the noise in between).

-Matt


Fredrik Levander wrote:
> Hi Matt,
>
> Are there any other examples of spectra which have more than one 
> precursor than the MS3(or higher) spectra? I think the general MS2 case 
> would be one precursor but possibly several selected ions. The only 
> situation I can  think of where there might be several possible 
> precursors selected would be some kind of merged spectrum, but that 
> could probably also in most cases be written as having one precursor 
> with several selected ions (if not the activation conditions were 
> different from each other for the original MS2 precursors).
> A CV term that clarifies the order of a certain precursor in the 
> fragmentation hierarchy seems like a reasonable solution to clarify this 
> if needed, anyway. I guess it is not really correct in xml to just use 
> the order of apperance.
>
> -Fredrik
>
> Matthew Chambers skrev:
>   
>> Hi all,
>>
>> As far as I can tell, we don't have documentation or an official example 
>> of how to handle this case. Fredrik made an example for this and sent 
>> this example to the list on 12/28/2008:
>> http://dev.thep.lu.se/fp6-prodac/svn/trunk/mzML/scans/5.ms3_scan.txt
>>
>> I'm concerned about the use of multiple precursors to represent the 
>> precursor "history." This seems quite confusing. Most of the time I 
>> would expect to see one precursor for the MS3 and if I wanted to know 
>> what the original MS precursor was, I'd look at the MS2's precursor. 
>> However, I can see that a method with a targeted MS3 (i.e. precursor and 
>> 1st generation product masses already known) might not even record the 
>> intermediate MS2 spectrum. So specifying the precursor hierarchy is 
>> sensible, but IMO we need to do it in a distinct way from the way we 
>> list multiple precursors that actually were fragmented to create the 
>> current scan. A clear solution to me seems to be to allow precursor to 
>> have a precursorList child element to explicitly indicate that the 
>> nested precursorList represents a previous generation of fragmentation. 
>> This is quite messy implementation-wise though, so another option is to 
>> use a cvParam in the precursorList to explicitly indicate what it means 
>> to have multiple precursors. This would mean that you couldn't mix 
>> multiple isolation windows with MS3+ though.
>>
>> Thoughts?
>> -Matt

Re: [Psidev-ms-dev] MS3+ spectra

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

Hi Matt,

Are there any other examples of spectra which have more than one 
precursor than the MS3(or higher) spectra? I think the general MS2 case 
would be one precursor but possibly several selected ions. The only 
situation I can  think of where there might be several possible 
precursors selected would be some kind of merged spectrum, but that 
could probably also in most cases be written as having one precursor 
with several selected ions (if not the activation conditions were 
different from each other for the original MS2 precursors).
A CV term that clarifies the order of a certain precursor in the 
fragmentation hierarchy seems like a reasonable solution to clarify this 
if needed, anyway. I guess it is not really correct in xml to just use 
the order of apperance.

-Fredrik

Matthew Chambers skrev:
> Hi all,
>
> As far as I can tell, we don't have documentation or an official example 
> of how to handle this case. Fredrik made an example for this and sent 
> this example to the list on 12/28/2008:
> http://dev.thep.lu.se/fp6-prodac/svn/trunk/mzML/scans/5.ms3_scan.txt
>
> I'm concerned about the use of multiple precursors to represent the 
> precursor "history." This seems quite confusing. Most of the time I 
> would expect to see one precursor for the MS3 and if I wanted to know 
> what the original MS precursor was, I'd look at the MS2's precursor. 
> However, I can see that a method with a targeted MS3 (i.e. precursor and 
> 1st generation product masses already known) might not even record the 
> intermediate MS2 spectrum. So specifying the precursor hierarchy is 
> sensible, but IMO we need to do it in a distinct way from the way we 
> list multiple precursors that actually were fragmented to create the 
> current scan. A clear solution to me seems to be to allow precursor to 
> have a precursorList child element to explicitly indicate that the 
> nested precursorList represents a previous generation of fragmentation. 
> This is quite messy implementation-wise though, so another option is to 
> use a cvParam in the precursorList to explicitly indicate what it means 
> to have multiple precursors. This would mean that you couldn't mix 
> multiple isolation windows with MS3+ though.
>
> Thoughts?
> -Matt
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] MS3+ spectra

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

Hi all,

As far as I can tell, we don't have documentation or an official example 
of how to handle this case. Fredrik made an example for this and sent 
this example to the list on 12/28/2008:
http://dev.thep.lu.se/fp6-prodac/svn/trunk/mzML/scans/5.ms3_scan.txt

I'm concerned about the use of multiple precursors to represent the 
precursor "history." This seems quite confusing. Most of the time I 
would expect to see one precursor for the MS3 and if I wanted to know 
what the original MS precursor was, I'd look at the MS2's precursor. 
However, I can see that a method with a targeted MS3 (i.e. precursor and 
1st generation product masses already known) might not even record the 
intermediate MS2 spectrum. So specifying the precursor hierarchy is 
sensible, but IMO we need to do it in a distinct way from the way we 
list multiple precursors that actually were fragmented to create the 
current scan. A clear solution to me seems to be to allow precursor to 
have a precursorList child element to explicitly indicate that the 
nested precursorList represents a previous generation of fragmentation. 
This is quite messy implementation-wise though, so another option is to 
use a cvParam in the precursorList to explicitly indicate what it means 
to have multiple precursors. This would mean that you couldn't mix 
multiple isolation windows with MS3+ though.

Thoughts?
-Matt

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

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

Present: Andreas, Fredrik, Matt, Eric



Discussion of TraML/TarML to better support ordinary inclusion/exclusion
lists

Eric will propose to add to schema:

<targetIncludeList>

  <target id=”” peptideRef=””>

    <precursor>…</precursor>

    <configurationList>…</configurationList>

  </target>

  …

</targetIncludeList>

<targetExcludeList>

  <target id=”” peptideRef=””>

    <precursor>…</precursor>

    <configurationList>…</configurationList>

  </target>

  …

</targetExcludeList>





1) mzML 1.1.0

- Manuscript : in preparation for submission to MCP

- HUPO poster: PAB currently reviewing it

- HUPO Saturday PSI session presentation by PAB

- HUPO Monday talk by Eric

- Outstanding items

  - some discussion about non-integer charge values from Proteios

  - Andreas wrote a proposal on 9/1. Add two mapping file rules. No
conclusion on last item. Keep in mind for future revisions

  - Matt agrees to fix the CV hierarchy problem near spectrum type as
described 9/1 by Andreas

----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO



----

3) TraML development

- New version 0.9.0 posted at dev page:

  http://www.psidev.info/index.php?q=node/405

- HUPO poster by Eric

- HUPO Saturday PSI session presentation by Eric

- Implementations? Let’s make a push in October to get some implementations
going and prepare official submission.

- What do we do with the <interpretation> cvParams insufficiency problem?



No meeting next week due to HUPO Congress.

Meet again in two weeks, same time.



Eric







*From:* ede...@sy... [mailto:ede...@sy...]
*Sent:* Monday, September 21, 2009 11:10 PM
*To:* Mass spectrometry standard development
*Cc:* Eric Deutsch
*Subject:* PSI-MSS WG 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=22&month=9&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

- Manuscript

- HUPO poster

- HUPO Saturday PSI session presentation

- HUPI Monday talk

- Outstanding items



----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO



----

3) TraML development

- New version 0.9.0 posted at dev page:

  http://www.psidev.info/index.php?q=node/405

- HUPO poster

- HUPO Saturday PSI session presentation

- Implementations?

- What do we do with the <interpretation> cvParams insufficiency problem?

Re: [Psidev-ms-dev] TraML extension to support inclusion and exclusion lists

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

Hi Andreas,

I argued several weeks ago that TraML should perhaps be TarML to include 
non-SRM use cases, but it was a hypothetical suggestion. It will need 
someone in the group who understands those use cases to advocate for it.

-Matt


Andreas Bertsch wrote:
> Dear TraML enthusiasts,
>
>
> during a developer meeting of the OpenMS developers the need for  
> specifying inclusion and exclusion lists came up. This is a frequently  
> asked feature to produce such lists for different experiments and from  
> various data sources. The files used to encode and transfer such  
> information to the mass spectrometer's acquisition software are mostly  
> csv and tsv file formats, similar to those of transition  
> specification. Of course different ones for different vendors or even  
> different instruments.
>
> The information encoded in TraML is very similar to that needed for  
> inclusion and exclusion lists. Especially precursors, peptides and  
> proteins and information about how they were selected, and so on.
> It seems to me that the changes necessary for TraML to also support  
> inclusion and exclusion lists are very small. (Except that the format  
> name is a bit misleading, maybe TarML, for targeted experiments ;) )
>
> I'll try to attend the phone conference today.
>
> Cheers,
> A.

[Psidev-ms-dev] TraML extension to support inclusion and exclusion lists

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

Dear TraML enthusiasts,


during a developer meeting of the OpenMS developers the need for  
specifying inclusion and exclusion lists came up. This is a frequently  
asked feature to produce such lists for different experiments and from  
various data sources. The files used to encode and transfer such  
information to the mass spectrometer's acquisition software are mostly  
csv and tsv file formats, similar to those of transition  
specification. Of course different ones for different vendors or even  
different instruments.

The information encoded in TraML is very similar to that needed for  
inclusion and exclusion lists. Especially precursors, peptides and  
proteins and information about how they were selected, and so on.
It seems to me that the changes necessary for TraML to also support  
inclusion and exclusion lists are very small. (Except that the format  
name is a bit misleading, maybe TarML, for targeted experiments ;) )

I'll try to attend the phone conference today.

Cheers,
A.

--
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] PSI-MSS WG call reminder

[<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=22&month=9&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

- Manuscript

- HUPO poster

- HUPO Saturday PSI session presentation

- HUPI Monday talk

- Outstanding items



----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO



----

3) TraML development

- New version 0.9.0 posted at dev page:

  http://www.psidev.info/index.php?q=node/405

- HUPO poster

- HUPO Saturday PSI session presentation

- Implementations?

- What do we do with the <interpretation> cvParams insufficiency problem?

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

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

Hi everyone, sorry I forgot to send around a notice. It was my last day of
vacation and I wasn't able to get it together. Some recent developments:

- We have been given the opportunity to submit the mzML manuscript to MCP.
So we will work on preparing the manuscript and submitting it. Look for a
draft soon.

- World HUPO is fast approaching so we should review the plans for posters
and talks.

- imzML now has a web site: http://www.imzml.org/

If there are any other announcements or concerns, please email them. I
would be especially interested in feedback on TraML.

It appears that next week I have an unexpected trip and will be on a plane
at the usual time, so unless we have important topics and someone else
will lead the call, I suggest we have our next call the Tuesday before
HUPO.

Regards,
Eric



> -----Original Message-----
> From: Fredrik Levander [mailto:Fre...@im...]
> Sent: Tuesday, September 08, 2009 8:08 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call reminder
>
> No call today?
>
> 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=25&month=8&yea
> r=2009&hour=16&min=0&sec=0&p1=136
> >
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=25&month=8&ye
> ar=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
> >
> > - Manuscript
> >
> > - Outstanding items
> >
> >
> >
> > ----
> >
> > 2) MIAPE-MS revision
> >
> > - Have revised document to discuss at HUPO
> >
> >
> >
> > ----
> >
> > 3) TraML development
> >
> > - New version 0.9.0 posted at dev page:
> >
> >   http://www.psidev.info/index.php?q=node/405
> >
> >
> >
> > - Implementations?
> >
> > - What do we do with the <interpretation> cvParams insufficiency
> problem?
> >
> >
> >
> >
> >
> >
> >
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] imaging mzML (imzML) - specifications

[Andreas R. <And...@an...>]

Dear all,

 

I just wanted to give you a short update on the imzML (imaging mzML) format. 

 

imzML is a data format that was developed specifically for MS imaging. The metadata part is based on mzML (hence the name imzML). At the PSI workshop in Turku we decided NOT to include the imzML format into the PSI process and keep the cv separate. We got several requests (also from the mzML community) for more information on imzML. So we set up a website which is hosted by the MSimaging portal. It includes specifications, example files and (very soon) first tools. The link is www.imzml.org

 

So if you are interested in MS imaging please have a look. We currently have a review process (which will be most likely prolonged till the end of September). I would also like to use this opportunity to thank the MS workgroup for mzML which was a great help in realizing the imzML format.

 

Best regards,

Andreas

 

PS: For more information on the mzML/imzML discussion also see earlier posts:

https://sourceforge.net/mailarchive/forum.php?thread_name=3c6c07c20903251310i66cb1dachd7c036d00ee37c05%40mail.gmail.com&forum_name=psidev-ms-dev

 

 

 

 

 

 

 

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

 

Dr. Andreas Roempp

Institute of Inorganic and Analytical Chemistry

- Analytical Chemistry -

Justus Liebig University Giessen

Schubertstrasse 60, Build. 16

D-35392 Giessen

Germany

 

phone:  +49-641-99 34802

fax:    +49-641-99 34809

email: And...@an... <mailto:And...@an...> 

Internet: http://www.uni-giessen.de/analytik/ <http://www.uni-giessen.de/analytik/> 

 

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

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

No call today?

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=25&month=8&year=2009&hour=16&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=25&month=8&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
>
> - Manuscript
>
> - Outstanding items
>
>  
>
> ----
>
> 2) MIAPE-MS revision
>
> - Have revised document to discuss at HUPO
>
>  
>
> ----
>
> 3) TraML development
>
> - New version 0.9.0 posted at dev page:
>
>   http://www.psidev.info/index.php?q=node/405
>
>  
>
> - Implementations?
>
> - What do we do with the <interpretation> cvParams insufficiency problem?
>
>  
>
>  
>
>  
>

Re: [Psidev-ms-dev] CV 2.26.0: improvements to Bruker instrument terms

[Kallhardt M. <Mar...@bd...>]

Oops, yeah, there should either be no definition for MS:1001548 or "Bruker Daltonics' solariX series".
(Also the name should be "solariX series").

Thanks Steffen.


Best Regards,
i.A. Marius Kallhardt

Software Developer
Bruker Daltonik GmbH (Bremen)
Phone:  +49 (0) 421 2205 467
Fax:  +49 (0) 421 2205 305
Mail: mar...@bd...





Bruker Daltonik GmbH
--------------------------------------------------------

Fahrenheitstrasse 4
28359 Bremen
Germany 

Permoserstrasse 15
04318 Leipzig
Germany
Geschäftsführer
Frank Laukien, Ph. D.
Gerd Hülso
Sebastian Meyer-Plath
Stefan Ruge
Ian Sanders, Ph. D.
Dr. Michael Schubert
Sitz der Gesellschaft
Bremen 

Handelsregister 
Amtsgericht Bremen
HRB 8150
www.bdal.de


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

Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht. 
Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird.
Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. 
The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax.
-----Original Message-----

From: Matthew Chambers [mailto:mat...@va...] 
Sent: Donnerstag, 3. September 2009 18:35
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] CV 2.26.0: improvements to Bruker instrument terms

You're right (http://www.bdal.com/solarix/), but I'll let Marius give 
the corrected definition. Good catch.

-Matt


Steffen Neumann wrote:
> On Thu, 2009-09-03 at 09:53 -0500, Matthew Chambers wrote:
>   
>> Committed CV 2.26.0:
>> - refactored Bruker instrument hierarchy into series (e.g. apex, flex, HCT)
>> - improved Bruker instrument definitions
>> - fixed databaseky typo
>>     
>
> Are you sure line 9306 is not a copy&paste error of line 9295 ?
> The solariXen are FTICR, successor to the apex series.
>
> Yours,
> Steffen
>
>  9292 [Term]
>  9293 id: MS:1001546
>  9294 name: amaZon X
>  9295 def: "Bruker Daltonics' amaZon X: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
>  9296 is_a: MS:1001545 ! Bruker Daltonics amaZon series
>  ...
>  9303 [Term]
>  9304 id: MS:1001548
>  9305 name: Bruker Daltonics solarix series
>  9306 def: "Bruker Daltonics' solarix: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
>  9307 is_a: MS:1000122 ! Bruker Daltonics instrument model
>   

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev Bruker Daltonik GmbH------------------------------Fahrenheitstrasse 428359 Bremen, Germany Permoserstrasse 1504318 Leipzig, Germany Geschäftsführer: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath, Stefan Ruge,    Ian Sanders, Ph. D., Dr. Michael Schubert Sitz der Gesellschaft: Bremen Handelsregister Amtsgericht Bremen: HRB 8150 www.bdal.de
------------------------------------------------------------Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird.Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax.-----Original Message-----
From: Matthew Chambers [mailto:mat...@va...] 
Sent: Donnerstag, 3. September 2009 18:35
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] CV 2.26.0: improvements to Bruker instrument terms

You're right (http://www.bdal.com/solarix/), but I'll let Marius give 
the corrected definition. Good catch.

-Matt


Steffen Neumann wrote:
> On Thu, 2009-09-03 at 09:53 -0500, Matthew Chambers wrote:
>   
>> Committed CV 2.26.0:
>> - refactored Bruker instrument hierarchy into series (e.g. apex, flex, HCT)
>> - improved Bruker instrument definitions
>> - fixed databaseky typo
>>     
>
> Are you sure line 9306 is not a copy&paste error of line 9295 ?
> The solariXen are FTICR, successor to the apex series.
>
> Yours,
> Steffen
>
>  9292 [Term]
>  9293 id: MS:1001546
>  9294 name: amaZon X
>  9295 def: "Bruker Daltonics' amaZon X: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
>  9296 is_a: MS:1001545 ! Bruker Daltonics amaZon series
>  ...
>  9303 [Term]
>  9304 id: MS:1001548
>  9305 name: Bruker Daltonics solarix series
>  9306 def: "Bruker Daltonics' solarix: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
>  9307 is_a: MS:1000122 ! Bruker Daltonics instrument model
>   

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] CV 2.26.0: improvements to Bruker instrument terms

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

You're right (http://www.bdal.com/solarix/), but I'll let Marius give 
the corrected definition. Good catch.

-Matt


Steffen Neumann wrote:
> On Thu, 2009-09-03 at 09:53 -0500, Matthew Chambers wrote:
>   
>> Committed CV 2.26.0:
>> - refactored Bruker instrument hierarchy into series (e.g. apex, flex, HCT)
>> - improved Bruker instrument definitions
>> - fixed databaseky typo
>>     
>
> Are you sure line 9306 is not a copy&paste error of line 9295 ?
> The solariXen are FTICR, successor to the apex series.
>
> Yours,
> Steffen
>
>  9292 [Term]
>  9293 id: MS:1001546
>  9294 name: amaZon X
>  9295 def: "Bruker Daltonics' amaZon X: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
>  9296 is_a: MS:1001545 ! Bruker Daltonics amaZon series
>  ...
>  9303 [Term]
>  9304 id: MS:1001548
>  9305 name: Bruker Daltonics solarix series
>  9306 def: "Bruker Daltonics' solarix: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
>  9307 is_a: MS:1000122 ! Bruker Daltonics instrument model
>   

Re: [Psidev-ms-dev] CV 2.26.0: improvements to Bruker instrument terms

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

On Thu, 2009-09-03 at 09:53 -0500, Matthew Chambers wrote:
> Committed CV 2.26.0:
> - refactored Bruker instrument hierarchy into series (e.g. apex, flex, HCT)
> - improved Bruker instrument definitions
> - fixed databaseky typo

Are you sure line 9306 is not a copy&paste error of line 9295 ?
The solariXen are FTICR, successor to the apex series.

Yours,
Steffen

 9292 [Term]
 9293 id: MS:1001546
 9294 name: amaZon X
 9295 def: "Bruker Daltonics' amaZon X: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
 9296 is_a: MS:1001545 ! Bruker Daltonics amaZon series
 ...
 9303 [Term]
 9304 id: MS:1001548
 9305 name: Bruker Daltonics solarix series
 9306 def: "Bruker Daltonics' solarix: ESI quadrupole ion trap, APCI, APPI, ETD, PTR." [PSI:MS]
 9307 is_a: MS:1000122 ! Bruker Daltonics instrument model

[Psidev-ms-dev] CV 2.26.0: improvements to Bruker instrument terms

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

Committed CV 2.26.0:
- refactored Bruker instrument hierarchy into series (e.g. apex, flex, HCT)
- improved Bruker instrument definitions
- fixed databaseky typo

[Psidev-ms-dev] mzML chromatograms

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

Hi all,

currently I am working on implementing the chromatogram support. I  
have noticed that there are no mapping rules for the precursor  
activation of chromatograms. I think it is necessary to port the  
following rules from spectrum to chromatograms.

         <CvMappingRule id="precursor_activation_must" cvElementPath="/ 
mzML/run/spectrumList/spectrum/precursorList/precursor/activation/ 
cvParam/@accession" requirementLevel="MUST" scopePath="/mzML/run/ 
spectrumList/spectrum/precursorList/precursor/activation"  
cvTermsCombinationLogic="AND">
           <CvTerm termAccession="MS:1000044" useTerm="true"  
termName="dissociation method" isRepeatable="true"  
allowChildren="true" cvIdentifierRef="MS"></CvTerm>
         </CvMappingRule>

         <CvMappingRule id="precursor_activation_may" cvElementPath="/ 
mzML/run/spectrumList/spectrum/precursorList/precursor/activation/ 
cvParam/@accession" requirementLevel="MAY" scopePath="/mzML/run/ 
spectrumList/spectrum/precursorList/precursor/activation"  
cvTermsCombinationLogic="OR">
           <CvTerm termAccession="MS:1000510" useTerm="false"  
termName="precursor activation attribute" isRepeatable="true"  
allowChildren="true" cvIdentifierRef="MS"></CvTerm>
         </CvMappingRule>

Additionally, a precursor type can also have selectedIons specified.  
Which does not make much sense in my opinion (at least in the use  
cases I am aware of). Should there be something like an empty mapping  
rule, such that no cv is allowed for chromatogram/precursor/ 
selectedIon (which simply results in no useful information if this tag  
is present in a chromatogram)?

Another question would be how to handle chromatograms that are defined  
via spectra. For SRM or SIM it is quite clear that these spectra can  
be converted into chromatograms. But what about other types? Are there  
any "guidelines" for converters what to convert to chromatograms and  
what to keep as spectra, e.g. for mzXML -> mzML converters?

One minor thing, the psi-ms ontology defines three terms, MS:1000804 !  
electromagnetic radiation spectrum, MS:1000805 ! emission spectrum, MS: 
1000806 ! absorption spectrum all children of spectrum type. The  
corresponding chromatogram terms, however, have a hierarchy, the  
emission and absorption chromatogram terms are children of  
electromagnetic radiation chromatogram, was that intended?

Cheers,
A.


--
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] cv name collision

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

Hi Darren,

Thanks for reporting this possible duplicate.
> I came across the following name collision in psi-ms.obo, I believe
> recently added:
>
> [Term]
> id: MS:1001526
> name: spectrum from database nativeID format
> def: "databasekey=xsd:Long" [PSI:MS]
> comment: A unique identifier of a spectrum stored in a database (e.g.
> a PRIMARY KEY identifier).
> is_a: MS:1000767 ! native spectrum identifier format
>
> [Term]
> id: MS:1001532
> name: spectrum from database nativeID format
> def: "databaseky=xsd:string" [PSI:MS]
> comment: A unique identifier of a spectrum stored in a database (e.g.
> a PRIMARY KEY identifier).
> is_a: MS:1001529 ! spectra data details
> is_a: MS:1000767 ! native spectrum identifier format

Maybe we can obsolete the second term and relax the definition of term  
1526 to "databasekey=xsd:string". The 1532 term is not used at the  
moment, so we can do that without breaking files (1526 is a perfect  
replacement).
Has anyone objections against this change?

(BTW, names of term are not necessarily unique, only the id has to be  
unique within an obo file! Terms might even do not have a name ;))

x-post/f'up in psi-pi list

Cheers,
A.

--
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] cv name collision

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

Hi all,

I came across the following name collision in psi-ms.obo, I believe
recently added:

[Term]
id: MS:1001526
name: spectrum from database nativeID format
def: "databasekey=xsd:Long" [PSI:MS]
comment: A unique identifier of a spectrum stored in a database (e.g.
a PRIMARY KEY identifier).
is_a: MS:1000767 ! native spectrum identifier format

[Term]
id: MS:1001532
name: spectrum from database nativeID format
def: "databaseky=xsd:string" [PSI:MS]
comment: A unique identifier of a spectrum stored in a database (e.g.
a PRIMARY KEY identifier).
is_a: MS:1001529 ! spectra data details
is_a: MS:1000767 ! native spectrum identifier format


Darren

Re: [Psidev-ms-dev] Errors in example files

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

Now the plgs_example is updated to use the latest CV. This also means 
that it has the charge arrays as encoded integers. Interestingly, the 
PLGS source file has some non-integer values for peak charge states 
(like 1.2043), so there is now some data loss introduced upon 
conversion.  Even if non-integer charge states don't make much sense, it 
could be a way of flagging that a peak is a mixture of two peaks with 
different charge states. So the float representation we had before is 
maybe better in the end anyway...

Fredrik

Re: [Psidev-ms-dev] XIC in MzData

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

Hi Neil,


> I suspected that mzML would deal with this. However, unfortunately I'm 
> attempting to generate PRIDE XML, which obviously relies on mzData.
> 
> I guess in the short term, I will have to leave it at "hack" status and 
> move over to mzML (and mzIdentML? - is this going to "replace" PRIDE?) 
> in time.

Yes, mzML and mzIdentML will supersede the mzData/PRIDE XML composite 
currently used to submit data to PRIDE.

As you can imagine, this transition is a rather involved operation for 
us, so it will take some time. Nevertheless, we've already developed our 
mzML API infrastructure (jmzml - available at 
http://code.google.com/p/jmzml) and are working towards an mzIdentML 
equivalent.


Cheers,

lnnrt.
-- 
Dr. Lennart Martens

PRIDE Group Coordinator
Proteomics Services, PANDA Group

EMBL-European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton
Cambridge
CB10 1SD
United Kingdom

Tel.:  +44 (0)1223 494 639 (Direct Line) ** NEW NUMBER
Fax:   +44 (0)1223 494 484
Skype: lennart_martens

Re: [Psidev-ms-dev] XIC in MzData

[Neil S. <nei...@ma...>]

Thanks Pierre-Alain,

I suspected that mzML would deal with this. However, unfortunately I'm  
attempting to generate PRIDE XML, which obviously relies on mzData.

I guess in the short term, I will have to leave it at "hack" status  
and move over to mzML (and mzIdentML? - is this going to "replace"  
PRIDE?) in time.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England

On 26 Aug 2009, at 09:59, Pierre-Alain Binz wrote:

> Hi Neil,
>
> mzData was not designed to efficiently support XIC, and in general  
> chromatograms. For this I would suggest you to migrate to mzML,  
> which provides a chromatogram element exactly for that purpose.
>
> Pierre-Alain
>
> Neil Swainston wrote:
>>
>> Hi all,
>>
>> I'm attempting to use mzData to markup extracted ion chromatograms.  
>> At the moment this is an almighty hack, which I don't like.
>>
>> Has anyone else done this or does anyone know the recommended way  
>> to do this "properly"?
>>
>> Thanks in advance for any help,
>>
>> Neil.
>>
>> Neil Swainston
>> Experimental Officer
>>
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> England
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports  
>> 2008 30-Day
>> trial. Simplify your report design, integration and deployment -  
>> and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] XIC in MzData

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

Hi Neil,

mzData was not designed to efficiently support XIC, and in general 
chromatograms. For this I would suggest you to migrate to mzML, which 
provides a chromatogram element exactly for that purpose.

Pierre-Alain

Neil Swainston wrote:
> Hi all,
>
> I'm attempting to use mzData to markup extracted ion chromatograms. At 
> the moment this is an almighty hack, which I don't like.
>
> Has anyone else done this or does anyone know the recommended way to 
> do this "properly"?
>
> Thanks in advance for any help,
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> England
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] XIC in MzData

[Neil S. <nei...@ma...>]

Hi all,

I'm attempting to use mzData to markup extracted ion chromatograms. At  
the moment this is an almighty hack, which I don't like.

Has anyone else done this or does anyone know the recommended way to  
do this "properly"?

Thanks in advance for any help,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England