psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] [Psidev-pi-dev] One of these dissociation methods doesn't belong...

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

Hi David, many thanks for taking this on and laying it out clearly. I
think all that you propose here is fine with me and I encourage you to go
ahead after waiting a little longer to see if there are other reactions. I
have only the following comments on your presentation below:

1) We had originally put in "?revision=1.21" to avoid the CV breaking for
users in case of changes in the unit ontology. However, it seems that the
unit ontology has not returned the favor, so unless we can get the unit
ontology to refer to a specific version of PATO et al., I guess I am
resigned to removing this as you have suggested.

2) run attribute probably belongs under MS:1000547. I don't know how it
got separated from its parent. I'm pretty sure it was there previously.

2.2) I suggest labeling rare terms as "uncommon". The would enable
functionality to allow certain terms that we know are rare to be hidden
from users unless they ask for uncommon terms. If we do the opposite,
there is a risk that a new term is not labeled "common" and may be hidden.
It seems less likely that a new term would be accidentally labeled
"uncommon".

2.8) Use of acronyms as synonyms is encouraged. Acronyms should not be
used as primary term names is our policy.

2.9) Policy is that terms are written and capitalized as they would appear
embedded in written text, i.e. NOT capitalized unless English rules
dictate capitalization due to a proper name such as Thermo or Dalton.

3) Software reclassification sounds good to me.

4) Prior to checking in your updates, please verify that any check-ins
since your fork are included.

Many thanks!
Eric




> -----Original Message-----
> From: David Ovelleiro [mailto:do...@eb...]
> Sent: Tuesday, April 19, 2011 7:47 AM
> To: Eric Deutsch
> Cc: psi...@li...; Mass spectrometry standard
> development; jp...@pr...; and...@an...emie.uni-
> giessen.de; ken...@ug...
> Subject: Re: [Psidev-pi-dev] One of these dissociation methods doesn't
> belong...
>
> Dear all,
>
> This message is organized in three different sections to make things
> easier. The first section is about a couple of little problems that we
> think that must be fixed in the general structure of the c.v. The
> second
> section focuses on the issues discussed about the ionization sources
> described in the c.v. The third section describes the "several steps
> reorganization" we have in mind at the PRIDE team, starting with the
> software members (MS:1000531).
> All this information has been checked using the 2.51.0 version of the
> PSI-MS controlled vocabulary (released April 7th).
>
> Section 1: General issues:
> 1. The dependency import:
> http://obo.cvs.sourceforge.net/*checkout*/obo/obo/ontology/phenotype/un
> it.obo?revision=1.21
> produces the following "Load error" in the OboEdit tool: "2
> unrecognized
> parent terms.". Both errors are related to the term PATO:0000081 , not
> included in the unit ontology, but in the PATO ontology (a "unit"
> dependence). Removed the "?revision=1.21" fragment in the PSI-MS, the
> loading of the obo file using OBO-Edit is successful.
> 2. The term MS:1000857 ("run attribute") has no parent. Maybe including
> it as a son of "spectrum generation information" (MS:1001458) will fix
> this.
>
> Section 2: Ionization sources
> In a short meeting with Juan Pablo Albar, Andreas Roempp and Kenny
> Helsens, we discussed several actions to be taken in the "source"
> (MS:1000458) descendants.
> 2.1 New terms to be added
> 2.1.1 Add LESA (Liquid Extraction Surface Analysis) as a new inlet
> 2.1.2 Add NanoMate as a new inlet
> 2.1.2 Add DESI (Desorption Electrospray Ionization) as a new source
> 2.1.3 Add DART (Direct Analysis in Real Time) as a new source
> 2.1.4 Add REIMS Rapid evaporative ionization mass spectrometry as a new
> source
> 2.1.5 Add SIMS Secondary ionization mass spectrometry as a new source
> 2.2 Frequently used terms
> In this meeting, the possibility of "highlighting" some terms was also
> discussed. The list of different ionization sources includes more than
> thirty terms. Some of the terms are not frequently used by the
> community
> and some of them overlap or are synonyms. One example: the "Electro
> Spray Ionization" (MS:1000073) is a "soft ionization" (MS:1000403) and
> a
> particular kind of "atmospheric pressure ionization" (MS:1000240). The
> three terms are at the same hierarchical level under "ionization type".
> To simplify this, four "highlighted" terms were suggested:
> - "Electro Spray Ionization"
> - "DESI (Desorption Electrospray Ionization)" (new term)
> - "SIMS Secondary ionization mass spectrometry" (new term)
> - "matrix-assisted laser desorption ionization"
> Two ways of doing this where proposed: selecting the "usual/more used"
> terms or selecting the "unusual" terms. The use of "Xref"'s was
> suggested as the way to flag these terms.
> 2.3 Use of acronyms
> The inclusion of highly used acronyms related to some terms was
> discussed, not only at the "ionization source", but also in other
> places
> in the controlled vocabulary. To do this, the use of Synonyms was
> suggested. The two
> 2.1 At the ionization sources level an intense use of acronyms was
> suggested: ESI, MALDI, SELDI, API. almost all of the terms would have
> newly associated acronyms.
> 2.2 Out of the range of the "ionization sources", we realised that the
> term "precursor activation" (MS:1000456) would need some kind of
> synonym: "Fragmentation technique", "Fragmentation". were candidates.
> We
> also found useful to include some acronyms to the different
> fragmentation techniques (CID, ETD, PQD.). The use of synonyms would
> do.
>
>
> Section 3: Software
> Some rearrangement of the software section was proposed by the PRIDE
> people (more concretely me.). The two main points discussed about this
> reorganization were:
> 3.1 Give some structure to the "software" section. What we had in mind
> was:
> - Divide the "software" into two main categories: "software classified
> by functionality" and "software classified by manufacturer".
> - The "software classified by manufacturer" will take into account the
> different manufacturers. We were told about an incorrect description of
> the company name "Thermo Finnigan software". At this point I must say
> that I'm quite confused with the "Thermo" several terms used. Maybe the
> more general term of "ThermoFisher Scientific" is the one to use.. I'm
> not sure.
> - The "software classified by functionality" is divided in 6
> categories:
> . acquisition software (MS:1001455): Software used to acquire the data
> generated by a Mass Spectrometer. This includes RAW files generation.
> . data processing software (MS:1001457): Software used to process the
> data generated by a Mass Spectrometer. This includes peaks lists
> generation, spectra annotation (charge assignment and precursor m/z
> characterization) and spectra processing (deisotoping, deconvolution,
> peak picking, smoothing, baseline reduction and related processes).
> . conversion software (MS:1010002): Software used for the conversion
> from one given format to other. Libraries and API for accessing the
> information contained in spectra/identification files are included.
> . analysis software (MS:1001456): Software used for the identification
> and/or qualitative characterization of proteins and peptides.
> . quantitation software (MS:1001139): Software used for the
> quantitative
> characterization of proteins and peptides using Mass Spectrometry
> derived data.
> . SRM software (MS:1000871): Software used to predict, select, or
> optimize transitions and/or analyse the results of selected reaction
> monitoring runs.
> As maybe some of you have deduced, I'm not a native English
> speaker/writer: please, feel free to improve these definitions. But I
> think that this is the most important point at the software level:
> define exactly what means "processing software", "adquisition
> software".
> This done, we'll be able to validate, using this c.v., if some user has
> described the software used for the acquisition (e.g. Xcalibur), the
> processing (maybe also Xcalibur) the search (e.g. Bioworks) and
> quantitation (maybe also Bioworks).
> When all this definitions are clear and assumed by us, we'll try to
> reorganize the different software: taking Xcalibur out of "analysis" is
> a clear example. Some of the definitions are not easy: in my opinion,
> the "processing software" is a complicate concept sometimes. but I'm
> sure that it can't be described as it's now (v 2.51.0): data processing
> software -> "Conversion software."
>
> We'll be waiting for your comments, corrections, contributions.
>
> Best,
> David

Re: [Psidev-ms-dev] [Psidev-pi-dev] One of these dissociation methods doesn't belong...

[David O. <do...@eb...>]

Dear all,

This message is organized in three different sections to make things 
easier. The first section is about a couple of little problems that we 
think that must be fixed in the general structure of the c.v. The second 
section focuses on the issues discussed about the ionization sources 
described in the c.v. The third section describes the “several steps 
reorganization” we have in mind at the PRIDE team, starting with the 
software members (MS:1000531).
All this information has been checked using the 2.51.0 version of the 
PSI-MS controlled vocabulary (released April 7th).

Section 1: General issues:
1. The dependency import: 
http://obo.cvs.sourceforge.net/*checkout*/obo/obo/ontology/phenotype/unit.obo?revision=1.21 
produces the following “Load error” in the OboEdit tool: “2 unrecognized 
parent terms…”. Both errors are related to the term PATO:0000081 , not 
included in the unit ontology, but in the PATO ontology (a “unit” 
dependence). Removed the “?revision=1.21” fragment in the PSI-MS, the 
loading of the obo file using OBO-Edit is successful.
2. The term MS:1000857 (“run attribute”) has no parent. Maybe including 
it as a son of “spectrum generation information” (MS:1001458) will fix this.

Section 2: Ionization sources
In a short meeting with Juan Pablo Albar, Andreas Roempp and Kenny 
Helsens, we discussed several actions to be taken in the “source” 
(MS:1000458) descendants.
2.1 New terms to be added
2.1.1 Add LESA (Liquid Extraction Surface Analysis) as a new inlet
2.1.2 Add NanoMate as a new inlet
2.1.2 Add DESI (Desorption Electrospray Ionization) as a new source
2.1.3 Add DART (Direct Analysis in Real Time) as a new source
2.1.4 Add REIMS Rapid evaporative ionization mass spectrometry as a new 
source
2.1.5 Add SIMS Secondary ionization mass spectrometry as a new source
2.2 Frequently used terms
In this meeting, the possibility of “highlighting” some terms was also 
discussed. The list of different ionization sources includes more than 
thirty terms. Some of the terms are not frequently used by the community 
and some of them overlap or are synonyms. One example: the “Electro 
Spray Ionization” (MS:1000073) is a “soft ionization” (MS:1000403) and a 
particular kind of “atmospheric pressure ionization” (MS:1000240). The 
three terms are at the same hierarchical level under “ionization type”. 
To simplify this, four “highlighted” terms were suggested:
- “Electro Spray Ionization”
- “DESI (Desorption Electrospray Ionization)” (new term)
- “SIMS Secondary ionization mass spectrometry” (new term)
- “matrix-assisted laser desorption ionization”
Two ways of doing this where proposed: selecting the “usual/more used” 
terms or selecting the “unusual” terms. The use of “Xref”’s was 
suggested as the way to flag these terms.
2.3 Use of acronyms
The inclusion of highly used acronyms related to some terms was 
discussed, not only at the “ionization source”, but also in other places 
in the controlled vocabulary. To do this, the use of Synonyms was 
suggested. The two
2.1 At the ionization sources level an intense use of acronyms was 
suggested: ESI, MALDI, SELDI, API… almost all of the terms would have 
newly associated acronyms.
2.2 Out of the range of the “ionization sources”, we realised that the 
term “precursor activation” (MS:1000456) would need some kind of 
synonym: “Fragmentation technique”, “Fragmentation”… were candidates. We 
also found useful to include some acronyms to the different 
fragmentation techniques (CID, ETD, PQD…). The use of synonyms would do.


Section 3: Software
Some rearrangement of the software section was proposed by the PRIDE 
people (more concretely me…). The two main points discussed about this 
reorganization were:
3.1 Give some structure to the “software” section. What we had in mind was:
- Divide the “software” into two main categories: “software classified 
by functionality” and “software classified by manufacturer”.
- The “software classified by manufacturer” will take into account the 
different manufacturers. We were told about an incorrect description of 
the company name “Thermo Finnigan software”. At this point I must say 
that I’m quite confused with the “Thermo” several terms used. Maybe the 
more general term of “ThermoFisher Scientific” is the one to use…. I’m 
not sure.
- The “software classified by functionality” is divided in 6 categories:
. acquisition software (MS:1001455): Software used to acquire the data 
generated by a Mass Spectrometer. This includes RAW files generation.
. data processing software (MS:1001457): Software used to process the 
data generated by a Mass Spectrometer. This includes peaks lists 
generation, spectra annotation (charge assignment and precursor m/z 
characterization) and spectra processing (deisotoping, deconvolution, 
peak picking, smoothing, baseline reduction and related processes).
. conversion software (MS:1010002): Software used for the conversion 
from one given format to other. Libraries and API for accessing the 
information contained in spectra/identification files are included.
. analysis software (MS:1001456): Software used for the identification 
and/or qualitative characterization of proteins and peptides.
. quantitation software (MS:1001139): Software used for the quantitative 
characterization of proteins and peptides using Mass Spectrometry 
derived data.
. SRM software (MS:1000871): Software used to predict, select, or 
optimize transitions and/or analyse the results of selected reaction 
monitoring runs.
As maybe some of you have deduced, I’m not a native English 
speaker/writer: please, feel free to improve these definitions. But I 
think that this is the most important point at the software level: 
define exactly what means “processing software”, “adquisition software”. 
This done, we’ll be able to validate, using this c.v., if some user has 
described the software used for the acquisition (e.g. Xcalibur), the 
processing (maybe also Xcalibur) the search (e.g. Bioworks) and 
quantitation (maybe also Bioworks).
When all this definitions are clear and assumed by us, we’ll try to 
reorganize the different software: taking Xcalibur out of “analysis” is 
a clear example. Some of the definitions are not easy: in my opinion, 
the “processing software” is a complicate concept sometimes… but I’m 
sure that it can’t be described as it’s now (v 2.51.0): data processing 
software -> “Conversion software.”

We’ll be waiting for your comments, corrections, contributions…

Best,
David

Re: [Psidev-ms-dev] [Psidev-pi-dev] One of these dissociation methods doesn't belong...

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

Hi David, Matt, thank you for the discussion. Mistakes will happen, so
let's just move forward with minimum distress. This is an easy fix, so I
would be grateful if you would just go ahead and make it, Matt, thanks.

I would like to recommend the following policy: any addition or change to
the CV be pre-announced to the PI list or the MS list (as appropriate) and
the vocab list shortly before they are committed. This is will let
everyone know what is happening, and allows the opportunity to catch
mistakes (if the new entries are posted verbatim, which I encourage when
modest).

Second, I would again urge you, David, to stay fairly current with the CV
so your reorganization attempts do not stray too far from the version in
CVS. I would urge you to announce and check in the changes you have worked
on at the meeting during this week. I plan on checking in some more items
this week and the greater we diverge, the more difficult your job will be
to merge the two branches.

Thank you,
Eric


> -----Original Message-----
> From: David Ovelleiro [mailto:do...@eb...]
> Sent: Monday, April 18, 2011 7:57 AM
> To: psi...@li...
> Subject: Re: [Psidev-pi-dev] One of these dissociation methods doesn't
> belong...
>
> I completely agree with the action proposed by Matt.
> The way in which this term was introduced (badly ;) ) and when was
> introduced (a couple of days before the PSI meeting :( ) and without
> previous publication in the PSI mailing list... is in my opinion a
> distressing precedent, and will make very difficult the actions we
> proposed in Heidelberg.
>
> David
>
> On 18/04/2011 15:46, Matthew Chambers wrote:
> > I agree with your suggestion assuming that nobody has started using
> the broken parent relationship
> > yet (a fairly safe assumption I guess). This sets a precedent for
> handling similar cases in the
> > future. Does anybody disagree with this? If not, I'll make the fix
> later today or tomorrow.
> >
> > -Matt
> >
> >
> > On 4/16/2011 7:56 AM, Eric Deutsch wrote:
> >> Hi Matt, normally moving a term to a new location would require a
> level 2
> >> version number change, but if I understand the situation here, this
> term
> >> is in the correct location via one parent, but has a second,
> spurious
> >> parent probably due to cut and paste error. I think it is fine to
> simply
> >> remove the errant parent and increment the minor version number,
> because
> >> this is just an error fix. Or am I misunderstanding?
> >>
> >> Thanks,
> >> Eric
> >>
> >>
> >>> -----Original Message-----
> >>> From: Matt Chambers [mailto:mat...@gm...]
> >>> Sent: Friday, April 15, 2011 5:28 PM
> >>> To: psi...@li...
> >>> Subject: Re: [Psidev-pi-dev] One of these dissociation methods
> doesn't
> >>> belong...
> >>>
> >>> I would be surprised if this was a typo since the term has both the
> >>> search
> >>> engine input parameter and dissociation method parent terms. What
> is
> >>> the PSI
> >>> process for moving terms in the hierarchy? What is our versioning
> >>> policy for it?
> >>>
> >>> -Matt
> >>>
> >>>
> >>> On 4/15/2011 2:31 PM, Eric Deutsch wrote:
> >>>> Hi Matt, thanks for noticing this. The solution, of course, if
> just
> >>> to
> >>>> reparent the term to where it was intended. Probably a simple
> typo.
> >>>>
> >>>> David Ovelleiro, Andreas Roempp and others were doing some CV
> >>>> reorganization here at the PSI meeting and were looking at the
> list
> >>> of
> >>>> dissociation types, although curiously I didn't notice this
> problem
> >>> at the
> >>>> time.
> >>>>
> >>>> David, shall we fix this problem right away, or will you check in
> the
> >>>> changes you have made so far and have already fixed this?
> >>>>
> >>>> Thanks,
> >>>> Eric
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Matthew Chambers [mailto:mat...@gm...]
> >>>>> Sent: Thursday, April 14, 2011 2:07 PM
> >>>>> To: psi...@li...
> >>>>> Subject: [Psidev-pi-dev] One of these dissociation methods
> doesn't
> >>>>> belong...
> >>>>>
> >>>>> This is why we post proposed CV terms to the list before adding
> >>> them.
> >>>>> ;)
> >>>>>
> >>>>> It's clearly wrong for a search engine input parameter to show up
> in
> >>> an
> >>>>> mzML's activation element!
> >>>>> Now what do we do about it?
> >>>>>
> >>>>> -Matt
> > ---------------------------------------------------------------------
> ---------
> > Benefiting from Server Virtualization: Beyond Initial Workload
> > Consolidation -- Increasing the use of server virtualization is a top
> > priority.Virtualization can reduce costs, simplify management, and
> improve
> > application availability and disaster protection. Learn more about
> boosting
> > the value of server virtualization. http://p.sf.net/sfu/vmware-
> sfdev2dev
> > _______________________________________________
> > Psidev-pi-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>
> --
> David Ovelleiro
> Bioinformatician
> PRIDE Group
> Proteomics Services Team, PANDA Group
> EMBL European Bioinformatics Institute
> Wellcome Trust Genome Campus
> Hinxton, Cambridge, UK
> CB10 1SD
>
>
> -----------------------------------------------------------------------
> -------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and
> improve
> application availability and disaster protection. Learn more about
> boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-
> sfdev2dev
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-ms-dev] PSI-MS controlled vocabularies proposal

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

Hi David, Matt, thanks for this summary and discussion. I look forward to
the discussion in Heidelberg. I think this is all good, although I might
suggest doing updates in smaller chunks rather than one grand update, but we
can debate this.

Thanks!
Eric


> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@gm...]
> Sent: Tuesday, April 05, 2011 9:49 AM
> To: psi...@li...
> Subject: Re: [Psidev-ms-dev] PSI-MS controlled vocabularies proposal
> 
> Xcalibur is perhaps misclassified, but aren't the classifications
> themselves sound? In other words,
> the structure itself is fine, but the way some of the terms are assigned
> into it may not be. I think
> there are plenty of misclassifications to be cleaned up, but the hierarchy
> seems more or less ok.
> 
> The way we get new terms into the CV is more inconsistent and represents
> the bigger problem IMO. For
> "editorial dispatch" I mean the way that journals send out papers to
> subfield experts because the
> journal doesn't staff an expert editor for every subfield. Perhaps we can
> just start sending
> unsolicited review requests to various experts. ;)
> 
> -Matt
> 
> 
> On 4/5/2011 11:14 AM, David Ovelleiro wrote:
> > Dear Matt,
> >
> > I'll be glad to send you our example material. I'll assume that the
> extension of your
> > email(m*a*t*t.c*h*a*m*b*e*r*s*42) is gmail.
> >
> > I'll send you (tomorrow, maybe in two days) a couple of attachments with
> the information. We'd
> > really appreciate knowing your opinion about this.
> >
> > I agree with you when you say that sometimes, you can find things out of
> the scope of the PSI-MS cv.
> > that is something that we'll need to handle.
> >
> > On the other hand, I don't agree when you say that there's little to
> control in software. Maybe is
> > one of the simplest sets of information, but if we are going to use the
> c.v. to validate data, we
> > need some criteria. for example: in software, you'll find the Xcalibur
> software in "adquisition",
> > "processing" and "analysis". everywhere. And, although Xcalibur is
> clearly an "adquisition"
> > software, performing several "processing" steps. I wouldn't say that
> XCalibur is also an "analysis
> > software". If you allow this, further steps of validation are impossible
> (like "what kind of
> > software are you using to adquire-process-analyse your data?"). That's
> the reason why we'll suggest
> > a clear effort on documenting things. Having this documentation, we
> would be able to know why
> > there's an LTQ-velos and not an Orbitrap-velos, for example ;)
> >
> > I'm not very sure what "editorial dispatch mechanism" means when talking
> about new terms in
> > controlled vocabularies. but if you can detail it further, we'll take it
> into account. Anyway, I
> > think that our proposal will take a simpler (and maybe more practical)
> approach for the new candidates.
> >
> > Anyway, I think it's a pity that we are not going to be able to discuss
> all this at Heidelberg. I'll
> > send you the information ASAP.
> >
> > Regards,
> >
> > David
> >
> >
> >
> >
> > On 05/04/2011 16:05, Matthew Chambers wrote:
> >> Hi David,
> >>
> >> My understanding of the main problem with adding terms to the CV is a
> lack of consensus and/or
> >> expertise. AFAIK, the largest outstanding CV request is from 7/19/2010
> from Salvador Martinez at
> >> ProteoRed. It was a big batch of terms spanning multiple subfields of
> expertise. The bulk of the
> >> terms are MALDI sample prep related and we have a decided lack of MALDI
> expertise in our working
> >> groups (AFAIK). My reply regarding those terms was:
> >>> I think most of the sample preparation terms should go
> intohttp://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
> >>   >  Incidentally, has there been discussion about merging sep.obo with
> psi-ms.obo?
> >> This met with no comment.
> >>
> >> Some of the other terms were raw data signal processing related and I
> was the only one to comment on
> >> them which was not enough consensus to make me comfortable adding them.
> >>
> >> The software terms were quickly added by Martin because there's little
> to "control" about them.
> >>
> >> Since I'm not going to be at Heidelberg, I'd appreciate a preview of
> your detailed example changes
> >> to the software hierarchy. But I think that the CV structure is a small
> part of our CV worries. :)
> >> Perhaps we would benefit from an editorial dispatch mechanism like the
> journals use?
> >>
> >> Thanks,
> >> -Matt
> >>
> >>
> >> On 4/5/2011 7:47 AM, David Ovelleiro wrote:
> >>> Dear all,
> >>>
> >>> As announced in one of the last phone conferences, we proposed to
> >>> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
> >>> maintenance as well as use in tools like the semantic validator.
> >>>
> >>> Our proposal has to main points:
> >>>
> >>> 1. Restructuration of the controlled vocabularies
> >>>
> >>> Our intention at this level can be summarized in the following points:
> >>> . Keep things as simple as possible
> >>> . Respect present id's as much as possible: we'll try to keep the
> >>> present id's in order to maintain the maximal backwards compatibility.
> >>> On the other hand, the overall structure will change. In practical
> >>> terms: that the software generating mzIdentML will work perfectly, but
> >>> the semantic validators will need to be updated.
> >>> . We'll document things: every major definition will be carefully
> built.
> >>> All definitions, when possible, will be generated using all the
> >>> information inside MIAPE specifications. References to the mzML and
> >>> mzIdentML formats will be made when possible. The proper documentation
> >>> of everything will make possible the maintenance of the controlled
> >>> vocabulary and will make things easier when semantic validators are
> built.
> >>>
> >>>
> >>> 2. Maintain and update the controlled vocabularies.
> >>>
> >>> Once the first step is finished, we'll begin with the update and
> >>> introduction of new terms proposed by the community. The exact
> mechanism
> >>> how the CV will be updated needs to be discussed in detail in
> >>> Heidelberg. I think we all agree that at the moment it is completely
> >>> impractical, too lengthy and troublesome. We need to come up with a
> new
> >>> strategy to do it
> >>>
> >>> The restructuration and update of the controlled vocabularies will be
> >>> made in a single step, sometime this year: there'll be a single update
> >>> with all the changes. In the meantime, we'll make public all the
> >>> proposals in the PSI mail list. We'll discuss with the community the
> >>> changes to be made (structure and definitions).
> >>>
> >>> A detailed example of the changes we have in mind will be shown in the
> >>> PSI meeting in Heidelberg. This example will take into account only
> the
> >>> "software" section of the controlled vocabularies.
> >>> We are expecting to hear your opinions about this proposal, and go
> into
> >>> detail in Heidelberg.
> 
> --------------------------------------------------------------------------
> ----
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

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

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

Notes from teleconference on Apr 5, 2011



Present: Florian, Eric, Matt, Pierre-Alain, Jim,





Agenda:

1) PSI Spring Workshop April 11-13

- Collaborative efforts with the PI WG on mzIdentML, mzQuantML, CV

- Finishing TraML

- Drafting SRM experiment guidelines

- Drafting a format for SRM experimental results

- MIAPE-MS finalization

- MIAPE-Quant work?

- Adjacent to the ProteomeXchange workshop

- Please attend and encourage attendance



----

2) mzML 1.1.0

- We have been contacted by Vladimir Likic, who has said that he is
representing some portions of the metabolomics community and they are
interested in seeing if mzML would be a good fit for them as a
next-generation format. See:
http://bioinformatics.bio21.unimelb.edu.au/mzml.html

- Steffen feels there probably only minor changes required for GC-MS.
Probably only mostly just some terms like “travel time” and the like.

- Currently the ANDI format is most often used for GC-MS, but it seems out
of date and is the format that would be replaced.

- Steffen attended a metabolomics conf at EBI and will report

- Other outstanding todo items:

  - Eric should test FAIMS support in mzML

  - Eric should test a recent file with multiple fragmentation types to see
if they are properly labeled

+ Need a term for LTQ Orbitrap Velos. Matt will add.

+ Jim will send along additional missing instruments

+ Eric has problems with SF CVS

+ Need definition for Steffen’s proposed “second column modulation time”

- Other items?



----

3) TraML development

- TraML version 0.9.4 is available at
http://www.psidev.info/index.php?q=node/405

- TraML was submitted to PSI document process

- Reviews are back and partially addressed.Still outstanding todo items

- Implementations? Please update to 0.9.4 and test

  - Matt has implemented in ProteoWizard complete to 0.9.4

  - Matt has finished the C# bindings which will enable Skyline support

  - Matt will sent out a sample file generated from ProteoWizard

  - Eric will try validating with his tools

  - ISB implementation in ATAQS is done

  - Jim has an implementation but just will need to update to 0.9.4

  - Eric will also contact Amol to discuss TraML implementations

  - Dave Cox at Sciex will test implement?

  - Brendan’s comments were found and sent to the list

  - Need to add two new terms

- Change <Validation> to <ValidationStatus>

- Fix <Configuration> to (1..N)

- What about MS3 support?

- Steffen points out that just adding another <Product> tag isn’t enough.
What if there are different collision energies for MS2 and MS3?

- Seems like there was agreement to move <Interpretation>, <Prediction>,
<ConfigurationList> into <Product>, thereby allowing (requiring!) separate
entries for each <Product> entry. For 99% of cases, this is just a trivial
move of elements.

- Discussion ensued about <Product> should have “isolation window target
m/z” or “selection window target m/z”.  Are we isolating (pure filter) or
selecting (scanning in a range)? Ran out of time. Continue on email or next
time.

+ Agreed that <Precursor> is “isolation window” and <Product> is a
“selection window”?

+ To support MS3, Add an <intermediateProduct> element

+ Eric will put together an example of that and email it out

+ Discussed Brendan’s Review

+ Matt will email out how mzIdentML can support non Unimod modifications

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304



----

4) MIAPE-MS revision

- Document is ready to be submitted, but..

- We need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- Waiting to sync with MIAPE-MSI as well

- Keep working on our documents and when we’re ready, see if we should wait

- We also need to coordinate the creation of MIAPE-Quant

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out

- Progress will continue at the workshop

+ Trying to get MIAPE-compliant mzML file

+ One example from PRIDE

+ One example article from Proteomics

+ Ask Juan Pablo for MIAPE example



----

5) Improving the controlled vocabulary

- There is a todo list based on a previous discussion

- Need someone with some time to work on it

- Some folks from PRIDE have expressed the desired to clean up the CV. Work
with them.

- Richard will ask David Ovelleiro to send a note to the list on his efforts

- There is a list of action items from a previous call

- Email from David Ovelleiro this morning

+ David will present at the meeting next week



----

6) SRM analysis guidelines and format

- At a “Data Quality Metrics” workshop in Sydney before World HUPO (hosted
by NCI), there was strong support to try to develop a set of guidelines for
reporting of SRM experiments as there currently are none. A working group
was identified at the meeting. Eric will organize some discussions on this.

- It was also proposed that PSI work on a standard format for the reporting
of SRM experiment analysis. There was some support for this. This is
distinct from mzML, which holds the chromatograms. It is distinct from TraML
which holds the input transitions. It might have some overlap with
mzQuantML. This should be discussed and a subgroup identified.





Next meeting:

- In person next week in Heidelberg

Re: [Psidev-ms-dev] PSI-MS controlled vocabularies proposal

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

Xcalibur is perhaps misclassified, but aren't the classifications themselves sound? In other words, 
the structure itself is fine, but the way some of the terms are assigned into it may not be. I think 
there are plenty of misclassifications to be cleaned up, but the hierarchy seems more or less ok.

The way we get new terms into the CV is more inconsistent and represents the bigger problem IMO. For 
"editorial dispatch" I mean the way that journals send out papers to subfield experts because the 
journal doesn't staff an expert editor for every subfield. Perhaps we can just start sending 
unsolicited review requests to various experts. ;)

-Matt


On 4/5/2011 11:14 AM, David Ovelleiro wrote:
> Dear Matt,
>
> I'll be glad to send you our example material. I'll assume that the extension of your
> email(m*a*t*t.c*h*a*m*b*e*r*s*42) is gmail.
>
> I'll send you (tomorrow, maybe in two days) a couple of attachments with the information. We'd
> really appreciate knowing your opinion about this.
>
> I agree with you when you say that sometimes, you can find things out of the scope of the PSI-MS cv…
> that is something that we’ll need to handle.
>
> On the other hand, I don’t agree when you say that there’s little to control in software. Maybe is
> one of the simplest sets of information, but if we are going to use the c.v. to validate data, we
> need some criteria… for example: in software, you’ll find the Xcalibur software in “adquisition”,
> “processing” and “analysis”… everywhere. And, although Xcalibur is clearly an “adquisition”
> software, performing several “processing” steps… I wouldn’t say that XCalibur is also an “analysis
> software”. If you allow this, further steps of validation are impossible (like “what kind of
> software are you using to adquire-process-analyse your data?”). That’s the reason why we’ll suggest
> a clear effort on documenting things… Having this documentation, we would be able to know why
> there’s an LTQ-velos and not an Orbitrap-velos, for example ;)
>
> I’m not very sure what “editorial dispatch mechanism” means when talking about new terms in
> controlled vocabularies… but if you can detail it further, we’ll take it into account. Anyway, I
> think that our proposal will take a simpler (and maybe more practical) approach for the new candidates…
>
> Anyway, I think it’s a pity that we are not going to be able to discuss all this at Heidelberg. I’ll
> send you the information ASAP.
>
> Regards,
>
> David
>
>
>
>
> On 05/04/2011 16:05, Matthew Chambers wrote:
>> Hi David,
>>
>> My understanding of the main problem with adding terms to the CV is a lack of consensus and/or
>> expertise. AFAIK, the largest outstanding CV request is from 7/19/2010 from Salvador Martinez at
>> ProteoRed. It was a big batch of terms spanning multiple subfields of expertise. The bulk of the
>> terms are MALDI sample prep related and we have a decided lack of MALDI expertise in our working
>> groups (AFAIK). My reply regarding those terms was:
>>> I think most of the sample preparation terms should go intohttp://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
>>   >  Incidentally, has there been discussion about merging sep.obo with psi-ms.obo?
>> This met with no comment.
>>
>> Some of the other terms were raw data signal processing related and I was the only one to comment on
>> them which was not enough consensus to make me comfortable adding them.
>>
>> The software terms were quickly added by Martin because there's little to "control" about them.
>>
>> Since I'm not going to be at Heidelberg, I'd appreciate a preview of your detailed example changes
>> to the software hierarchy. But I think that the CV structure is a small part of our CV worries. :)
>> Perhaps we would benefit from an editorial dispatch mechanism like the journals use?
>>
>> Thanks,
>> -Matt
>>
>>
>> On 4/5/2011 7:47 AM, David Ovelleiro wrote:
>>> Dear all,
>>>
>>> As announced in one of the last phone conferences, we proposed to
>>> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
>>> maintenance as well as use in tools like the semantic validator.
>>>
>>> Our proposal has to main points:
>>>
>>> 1. Restructuration of the controlled vocabularies
>>>
>>> Our intention at this level can be summarized in the following points:
>>> . Keep things as simple as possible
>>> . Respect present id’s as much as possible: we’ll try to keep the
>>> present id’s in order to maintain the maximal backwards compatibility.
>>> On the other hand, the overall structure will change. In practical
>>> terms: that the software generating mzIdentML will work perfectly, but
>>> the semantic validators will need to be updated.
>>> . We’ll document things: every major definition will be carefully built.
>>> All definitions, when possible, will be generated using all the
>>> information inside MIAPE specifications. References to the mzML and
>>> mzIdentML formats will be made when possible. The proper documentation
>>> of everything will make possible the maintenance of the controlled
>>> vocabulary and will make things easier when semantic validators are built.
>>>
>>>
>>> 2. Maintain and update the controlled vocabularies.
>>>
>>> Once the first step is finished, we’ll begin with the update and
>>> introduction of new terms proposed by the community. The exact mechanism
>>> how the CV will be updated needs to be discussed in detail in
>>> Heidelberg. I think we all agree that at the moment it is completely
>>> impractical, too lengthy and troublesome. We need to come up with a new
>>> strategy to do it
>>>
>>> The restructuration and update of the controlled vocabularies will be
>>> made in a single step, sometime this year: there’ll be a single update
>>> with all the changes. In the meantime, we’ll make public all the
>>> proposals in the PSI mail list. We’ll discuss with the community the
>>> changes to be made (structure and definitions).
>>>
>>> A detailed example of the changes we have in mind will be shown in the
>>> PSI meeting in Heidelberg. This example will take into account only the
>>> “software” section of the controlled vocabularies.
>>> We are expecting to hear your opinions about this proposal, and go into
>>> detail in Heidelberg.

Re: [Psidev-ms-dev] PSI-MS controlled vocabularies proposal

[David O. <do...@eb...>]

Dear Matt,

I'll be glad to send you our example material. I'll assume that the 
extension of your email(m*a*t*t.c*h*a*m*b*e*r*s*42) is gmail.

I'll send you (tomorrow, maybe in two days) a couple of attachments with 
the information. We'd really appreciate knowing your opinion about this.

I agree with you when you say that sometimes, you can find things out of 
the scope of the PSI-MS cv… that is something that we’ll need to handle.

On the other hand, I don’t agree when you say that there’s little to 
control in software. Maybe is one of the simplest sets of information, 
but if we are going to use the c.v. to validate data, we need some 
criteria… for example: in software, you’ll find the Xcalibur software in 
“adquisition”, “processing” and “analysis”… everywhere. And, although 
Xcalibur is clearly an “adquisition” software, performing several 
“processing” steps… I wouldn’t say that XCalibur is also an “analysis 
software”. If you allow this, further steps of validation are impossible 
(like “what kind of software are you using to adquire-process-analyse 
your data?”). That’s the reason why we’ll suggest a clear effort on 
documenting things… Having this documentation, we would be able to know 
why there’s an LTQ-velos and not an Orbitrap-velos, for example ;)

I’m not very sure what “editorial dispatch mechanism” means when talking 
about new terms in controlled vocabularies… but if you can detail it 
further, we’ll take it into account. Anyway, I think that our proposal 
will take a simpler (and maybe more practical) approach for the new 
candidates…

Anyway, I think it’s a pity that we are not going to be able to discuss 
all this at Heidelberg. I’ll send you the information ASAP.

Regards,

David




On 05/04/2011 16:05, Matthew Chambers wrote:
> Hi David,
>
> My understanding of the main problem with adding terms to the CV is a lack of consensus and/or
> expertise. AFAIK, the largest outstanding CV request is from 7/19/2010 from Salvador Martinez at
> ProteoRed. It was a big batch of terms spanning multiple subfields of expertise. The bulk of the
> terms are MALDI sample prep related and we have a decided lack of MALDI expertise in our working
> groups (AFAIK). My reply regarding those terms was:
>> I think most of the sample preparation terms should go into http://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
>   >  Incidentally, has there been discussion about merging sep.obo with psi-ms.obo?
> This met with no comment.
>
> Some of the other terms were raw data signal processing related and I was the only one to comment on
> them which was not enough consensus to make me comfortable adding them.
>
> The software terms were quickly added by Martin because there's little to "control" about them.
>
> Since I'm not going to be at Heidelberg, I'd appreciate a preview of your detailed example changes
> to the software hierarchy. But I think that the CV structure is a small part of our CV worries. :)
> Perhaps we would benefit from an editorial dispatch mechanism like the journals use?
>
> Thanks,
> -Matt
>
>
> On 4/5/2011 7:47 AM, David Ovelleiro wrote:
>> Dear all,
>>
>> As announced in one of the last phone conferences, we proposed to
>> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
>> maintenance as well as use in tools like the semantic validator.
>>
>> Our proposal has to main points:
>>
>> 1. Restructuration of the controlled vocabularies
>>
>> Our intention at this level can be summarized in the following points:
>> . Keep things as simple as possible
>> . Respect present id’s as much as possible: we’ll try to keep the
>> present id’s in order to maintain the maximal backwards compatibility.
>> On the other hand, the overall structure will change. In practical
>> terms: that the software generating mzIdentML will work perfectly, but
>> the semantic validators will need to be updated.
>> . We’ll document things: every major definition will be carefully built.
>> All definitions, when possible, will be generated using all the
>> information inside MIAPE specifications. References to the mzML and
>> mzIdentML formats will be made when possible. The proper documentation
>> of everything will make possible the maintenance of the controlled
>> vocabulary and will make things easier when semantic validators are built.
>>
>>
>> 2. Maintain and update the controlled vocabularies.
>>
>> Once the first step is finished, we’ll begin with the update and
>> introduction of new terms proposed by the community. The exact mechanism
>> how the CV will be updated needs to be discussed in detail in
>> Heidelberg. I think we all agree that at the moment it is completely
>> impractical, too lengthy and troublesome. We need to come up with a new
>> strategy to do it
>>
>> The restructuration and update of the controlled vocabularies will be
>> made in a single step, sometime this year: there’ll be a single update
>> with all the changes. In the meantime, we’ll make public all the
>> proposals in the PSI mail list. We’ll discuss with the community the
>> changes to be made (structure and definitions).
>>
>> A detailed example of the changes we have in mind will be shown in the
>> PSI meeting in Heidelberg. This example will take into account only the
>> “software” section of the controlled vocabularies.
>> We are expecting to hear your opinions about this proposal, and go into
>> detail in Heidelberg.
>>
>>
>> Best regards,
>>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev


-- 
David Ovelleiro
Bioinformatician
PRIDE Group
Proteomics Services Team, PANDA Group
EMBL European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, UK
CB10 1SD

Re: [Psidev-ms-dev] PSI-MS controlled vocabularies proposal

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

Hi David,

My understanding of the main problem with adding terms to the CV is a lack of consensus and/or 
expertise. AFAIK, the largest outstanding CV request is from 7/19/2010 from Salvador Martinez at 
ProteoRed. It was a big batch of terms spanning multiple subfields of expertise. The bulk of the 
terms are MALDI sample prep related and we have a decided lack of MALDI expertise in our working 
groups (AFAIK). My reply regarding those terms was:
> I think most of the sample preparation terms should go into http://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
 > Incidentally, has there been discussion about merging sep.obo with psi-ms.obo?
This met with no comment.

Some of the other terms were raw data signal processing related and I was the only one to comment on 
them which was not enough consensus to make me comfortable adding them.

The software terms were quickly added by Martin because there's little to "control" about them.

Since I'm not going to be at Heidelberg, I'd appreciate a preview of your detailed example changes 
to the software hierarchy. But I think that the CV structure is a small part of our CV worries. :) 
Perhaps we would benefit from an editorial dispatch mechanism like the journals use?

Thanks,
-Matt


On 4/5/2011 7:47 AM, David Ovelleiro wrote:
> Dear all,
>
> As announced in one of the last phone conferences, we proposed to
> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
> maintenance as well as use in tools like the semantic validator.
>
> Our proposal has to main points:
>
> 1. Restructuration of the controlled vocabularies
>
> Our intention at this level can be summarized in the following points:
> . Keep things as simple as possible
> . Respect present id’s as much as possible: we’ll try to keep the
> present id’s in order to maintain the maximal backwards compatibility.
> On the other hand, the overall structure will change. In practical
> terms: that the software generating mzIdentML will work perfectly, but
> the semantic validators will need to be updated.
> . We’ll document things: every major definition will be carefully built.
> All definitions, when possible, will be generated using all the
> information inside MIAPE specifications. References to the mzML and
> mzIdentML formats will be made when possible. The proper documentation
> of everything will make possible the maintenance of the controlled
> vocabulary and will make things easier when semantic validators are built.
>
>
> 2. Maintain and update the controlled vocabularies.
>
> Once the first step is finished, we’ll begin with the update and
> introduction of new terms proposed by the community. The exact mechanism
> how the CV will be updated needs to be discussed in detail in
> Heidelberg. I think we all agree that at the moment it is completely
> impractical, too lengthy and troublesome. We need to come up with a new
> strategy to do it
>
> The restructuration and update of the controlled vocabularies will be
> made in a single step, sometime this year: there’ll be a single update
> with all the changes. In the meantime, we’ll make public all the
> proposals in the PSI mail list. We’ll discuss with the community the
> changes to be made (structure and definitions).
>
> A detailed example of the changes we have in mind will be shown in the
> PSI meeting in Heidelberg. This example will take into account only the
> “software” section of the controlled vocabularies.
> We are expecting to hear your opinions about this proposal, and go into
> detail in Heidelberg.
>
>
> Best regards,
>

[Psidev-ms-dev] PSI-MS controlled vocabularies proposal

[David O. <do...@eb...>]

Dear all,

As announced in one of the last phone conferences, we proposed to 
restructure the PSI-MS controlled vocabularies/ontology, to facilitate 
maintenance as well as use in tools like the semantic validator.

Our proposal has to main points:

1. Restructuration of the controlled vocabularies

Our intention at this level can be summarized in the following points:
. Keep things as simple as possible
. Respect present id’s as much as possible: we’ll try to keep the 
present id’s in order to maintain the maximal backwards compatibility. 
On the other hand, the overall structure will change. In practical 
terms: that the software generating mzIdentML will work perfectly, but 
the semantic validators will need to be updated.
. We’ll document things: every major definition will be carefully built. 
All definitions, when possible, will be generated using all the 
information inside MIAPE specifications. References to the mzML and 
mzIdentML formats will be made when possible. The proper documentation 
of everything will make possible the maintenance of the controlled 
vocabulary and will make things easier when semantic validators are built.


2. Maintain and update the controlled vocabularies.

Once the first step is finished, we’ll begin with the update and 
introduction of new terms proposed by the community. The exact mechanism 
how the CV will be updated needs to be discussed in detail in 
Heidelberg. I think we all agree that at the moment it is completely 
impractical, too lengthy and troublesome. We need to come up with a new 
strategy to do it

The restructuration and update of the controlled vocabularies will be 
made in a single step, sometime this year: there’ll be a single update 
with all the changes. In the meantime, we’ll make public all the 
proposals in the PSI mail list. We’ll discuss with the community the 
changes to be made (structure and definitions).

A detailed example of the changes we have in mind will be shown in the 
PSI meeting in Heidelberg. This example will take into account only the 
“software” section of the controlled vocabularies.
We are expecting to hear your opinions about this proposal, and go into 
detail in Heidelberg.


Best regards,

-- 
David Ovelleiro
Bioinformatician
PRIDE Group
Proteomics Services Team, PANDA Group
EMBL European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, UK
CB10 1SD

[Psidev-ms-dev] LTQ Velos vs. LTQ Orbitrap Velos

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

We have no term for "LTQ Orbitrap Velos" in the CV. I seem to recall that this was done on purpose 
but I can't recall why. Can anyone shed light on that?

-Matt

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

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

Hi everyone, this is a reminder for the PSI MSS WG teleconference call
tomorrow, Tuesday, at the usual time.



Note that there appears to be a new number for US callers. The old number is
also provided below in case the new number doesn’t work out.



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: NEW NUMBER: 1-866-832-8490   Old number: 1-866-314-3683

Generic international: +44 2083222500 (UK number)



access code: 297427 #





Agenda:

1) PSI Spring Workshop April 11-13

- Collaborative efforts with the PI WG on mzIdentML, mzQuantML, CV

- Finishing TraML

- Drafting SRM experiment guidelines

- Drafting a format for SRM experimental results

- MIAPE-MS finalization

- MIAPE-Quant work?

- Adjacent to the ProteomeXchange workshop

- Please attend and encourage attendance



----

2) mzML 1.1.0

- We have been contacted by Vladimir Likic, who has said that he is
representing some portions of the metabolomics community and they are
interested in seeing if mzML would be a good fit for them as a
next-generation format. See:
http://bioinformatics.bio21.unimelb.edu.au/mzml.html

- Steffen feels there probably only minor changes required for GC-MS.
Probably only mostly just some terms like “travel time” and the like.

- Currently the ANDI format is most often used for GC-MS, but it seems out
of date and is the format that would be replaced.

- Steffen attended a metabolomics conf at EBI and will report

- Other outstanding todo items:

  - Eric should test FAIMS support in mzML

  - Eric should test a recent file with multiple fragmentation types to see
if they are properly labeled

- Other items?



----

3) TraML development

- TraML version 0.9.4 is available at
http://www.psidev.info/index.php?q=node/405

- TraML was submitted to PSI document process

- Reviews are back and partially addressed.Still outstanding todo items

- Implementations? Please update to 0.9.4 and test

  - Matt has implemented in ProteoWizard complete to 0.9.4

  - Matt has finished the C# bindings which will enable Skyline support

  - Matt will sent out a sample file generated from ProteoWizard

  - Eric will try validating with his tools

  - ISB implementation in ATAQS is done

  - Jim has an implementation but just will need to update to 0.9.4

  - Eric will also contact Amol to discuss TraML implementations

  - Dave Cox at Sciex will test implement?

  - Brendan’s comments were found and sent to the list

  - Need to add two new terms

- Change <Validation> to <ValidationStatus>

- Fix <Configuration> to (1..N)

- What about MS3 support?

- Steffen points out that just adding another <Product> tag isn’t enough.
What if there are different collision energies for MS2 and MS3?

- Seems like there was agreement to move <Interpretation>, <Prediction>,
<ConfigurationList> into <Product>, thereby allowing (requiring!) separate
entries for each <Product> entry. For 99% of cases, this is just a trivial
move of elements.

- Discussion ensued about <Product> should have “isolation window target
m/z” or “selection window target m/z”.  Are we isolating (pure filter) or
selecting (scanning in a range)? Ran out of time. Continue on email or next
time.

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304



----

4) MIAPE-MS revision

- Document is ready to be submitted, but..

- We need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- Waiting to sync with MIAPE-MSI as well

- Keep working on our documents and when we’re ready, see if we should wait

- We also need to coordinate the creation of MIAPE-Quant

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out

- Progress will continue at the workshop



----

5) Improving the controlled vocabulary

- There is a todo list based on a previous discussion

- Need someone with some time to work on it

- Some folks from PRIDE have expressed the desired to clean up the CV. Work
with them.

- Richard will ask David Ovelleiro to send a note to the list on his efforts

- There is a list of action items from a previous call



----

6) SRM analysis guidelines and format

- At a “Data Quality Metrics” workshop in Sydney before World HUPO (hosted
by NCI), there was strong support to try to develop a set of guidelines for
reporting of SRM experiments as there currently are none. A working group
was identified at the meeting. Eric will organize some discussions on this.

- It was also proposed that PSI work on a standard format for the reporting
of SRM experiment analysis. There was some support for this. This is
distinct from mzML, which holds the chromatograms. It is distinct from TraML
which holds the input transitions. It might have some overlap with
mzQuantML. This should be discussed and a subgroup identified.





Next meeting:

- In person next week in Heidelberg

[Psidev-ms-dev] Tomorrow's call postponed until next week

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

Hi everyone, due to a schedule change, I can unable to make tomorrow’s
planned call. Let’s defer until next week Tuesday regular time.



Thanks,

Eric

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Chris T. <chr...@eb...>]

Absolutely, some cases are simple, and clearly the retention 
times should stay with the m/z data (those retention times are 
measurements by the mass spec anyway of course), but where the 
first dimension is kept as a series of aliquots and then each 
run out in a later 1D LCMS (still effectively 2D), or where a 
series of gel plugs are being analysed, or where you simply want 
to say more about the column, I think the format would begin to 
feel the stretch no?

Also, more generally we have no effective way of transferring 
more than trivial amounts of information about samples as things 
stand. This could be solved with ISA-Tab itself, but previously 
there hasn't been much appetite for that in this group...

Anyway I suppose the rush of enthusiasm is all the answer I need.

C.


On 21/03/2011 16:17, Neumann, Steffen wrote:
> Hi Chris (Taylor ?)
>
> I think you overshoot a bit here, the raw data
> of 2D GCxGC (or LCxLC for that matter) will be stored
> by the MS instrument in a single file, therefore
> I think it is quite natural to keep it in one mzML file.
>
> The only difference to 1D GC-MS (or LC-MS) is that
> the retention time observed by the MS instrument
> stems can be mapped back to 2D retention "positions" (?)
> resulting from two individual (but coupled) GC separations.
>
> So it comes down to the question how to store the
> information about re-mapping the retention time(s),
> and that definitely has to be kept inside the mzML
> because it must not get lost.
>
> Yours,
> Steffen
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1498/3521 - Release Date: 03/21/11
>
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://www.mibbi.org/
~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Neumann, S. <sne...@ip...>]

Hi Chris (Taylor ?)

I think you overshoot a bit here, the raw data 
of 2D GCxGC (or LCxLC for that matter) will be stored 
by the MS instrument in a single file, therefore 
I think it is quite natural to keep it in one mzML file.

The only difference to 1D GC-MS (or LC-MS) is that 
the retention time observed by the MS instrument 
stems can be mapped back to 2D retention "positions" (?)
resulting from two individual (but coupled) GC separations.

So it comes down to the question how to store the 
information about re-mapping the retention time(s),
and that definitely has to be kept inside the mzML
because it must not get lost.

Yours,
Steffen

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[<mem...@gm...>]

It's a shame we don't have a simple tracking format that could 
handle this end of things properly. Obviously there's FuGE which 
could point at a set of mzMLs, but without wishing to disrespect 
that, I mean something much more lightweight (in both the formal 
and informal sense...).

If such a thing existed then the pressure to (redundantly) model 
that kind of contextual info (at whatever level) would be taken 
off the other in-house formats. The only question would be 
whether always needing two formats (the first to specify which 
files relate to which fractions from a 2D separation [plus other 
metadata], and then the mzML assay files, plus presumably many 
mzIdents alongside so that'd be three) is too much of an 
increase in complexity versus the situation where any of the 
assay files could stand alone.

If I were to sketch such a thing it'd have:
(1) Adequate generic structure to capture [tagged] metadata 
about sample origins and so on (thinking MI guidelines +).
(1a) A 'Study' element for high-level info about the set of 
assays conducted and links out.
(1b) Study components' (cv-tagged to specify function), which 
could hold a person or a metagenomic sample site or a tissue 
bank or glasshouse growth or sample prep protocol etc.
(2) Mechanism for pointing at assay-specific data files (mzML, 
GelML including proprietary stuff using URI/PURL/DOI/...).
(3) Also make it generally ontology/cv/whatever friendly

There's a tab format called ISA-Tab which has the same basic 
structure, some dedicated supporting software and users (e.g., 
CS in Manchester export the tab from a tool); maintaining 
general structural compatibility with that wouldn't hurt.

Is there any interest in such a thing? If we stick to XML and 
keep it simple we could have a draft before we meet.

Cheers, Chris.


On 20/03/2011 18:00, Oliver Kohlbacher wrote:
>
> On 16.03.2011, at 06:01, Neumann, Steffen wrote:
>
>> Hi,
>>
>> Nils will try to get us an example file. But from what I remember
>> you really get only one file with consecutive scan numbers
>> and one monotonously increasing (1D) scan times,
>> which can be converted to 2D if you know the modulation time.
> That is also my understanding from 2D-LC data. I would argue quite in
> favor of using mzML for this and 2D data is also not that uncommon
> in proteomics, so it is a problem that will have to be dealt with
> anyways.
>
> Conceptually, I would consider those just a single {L|G}C-MS run.
> Information on how the 1D RT should be mapped to 2D coordinates
> should be provided in addition to that. We could basically
> store a relation assigning each scan two or more retention
> coordinates (retention times or an index for the primary separation,
> which would also make it comparable to offline fractionation).
>
> Just my two cents,
>    Oliver
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1498/3514 - Release Date: 03/18/11
>
>

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Oliver K. <oli...@un...>]

On 16.03.2011, at 06:01, Neumann, Steffen wrote:

> Hi,
> 
> Nils will try to get us an example file. But from what I remember
> you really get only one file with consecutive scan numbers 
> and one monotonously increasing (1D) scan times,
> which can be converted to 2D if you know the modulation time.
That is also my understanding from 2D-LC data. I would argue quite in
favor of using mzML for this and 2D data is also not that uncommon
in proteomics, so it is a problem that will have to be dealt with
anyways.

Conceptually, I would consider those just a single {L|G}C-MS run.
Information on how the 1D RT should be mapped to 2D coordinates
should be provided in addition to that. We could basically 
store a relation assigning each scan two or more retention 
coordinates (retention times or an index for the primary separation,
which would also make it comparable to offline fractionation).

Just my two cents,
  Oliver

[Psidev-ms-dev] Fwd: Invitation to review the PSI-document TraML: Transitions Markup Language

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

Here is Brendan MacLean's review of TraML. It looks like we have some work to do with regard to 
well-defined use cases and richer example documents (I guess that just confirms what we already knew).

-Matt


-------- Original Message --------
Subject: 	Fwd: Invitation to review the PSI-document TraML: Transitions Markup Language
Date: 	Fri, 18 Mar 2011 06:53:30 -0700
From: 	Brendan MacLean <bre...@pr...>
To: 	Matt Chambers <mat...@gm...>



Hi Matt,
Here is my response to the request for review feedback.

Summary:

     * The original TraML vision is unrealistic and outdated.
     * I would be open to working with you and Eric on a TraML standard version that allows a full
       round-trip from a Skyline document to TraML and back.
     * I am also open to Skyline supporting something closer to the existing TraML spec in order to
       enable a compelling use case, though a few issues like requiring a Unimod ID as the only valid
       way to represent a modification might be tricky.

How is it going?

--Brendan

---------- Forwarded message ----------
From: *Brendan MacLean* <bre...@pr... <mailto:bre...@pr...>>
Date: Wed, Aug 25, 2010 at 2:32 AM
Subject: Re: Invitation to review the PSI-document TraML: Transitions Markup Language
To: Christian Stephan <chr...@ru... <mailto:chr...@ru...>>


Hi Christian,
My apologies for running a bit over on the 4 weeks I promised.  My review is attached.  Hope this
helps at least in planning for a TraML 2.0, if you decide to move forward with the current
limitations in a TraML 1.0 specification.

Thanks again for the opportunity.

--Brendan

On Thu, Jul 22, 2010 at 3:08 AM, Christian Stephan <chr...@ru...
<mailto:chr...@ru...>> wrote:

     Dear Brendan MacLean,
     given your expertise in this area, I would appreciate your comments on the
     above mentioned paper work on “TraML: Transitions Markup Language".

     The documents are found here:
     http://www.psidev.info/index.php?q=node/449

     As PSI-Editor I would like to invite you to review this article.

     Please let me know within next 48 hours if you could review the
     article and the attached instance/comments within the next 4 weeks.


     Best regards,


     Christian

     --
     Dr. Christian Stephan
     Head of Bioinformatics
     Medizinisches Proteom-Center
     Zentrum Klinische Forschung (ZKF E.141) Ruhr-Universität-Bochum 44870
     Bochum
     Phone: +49 234 32 29 288
     Fax:   +49 234 32 14 554
     http://www.medizinisches-proteom-center.de

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Neumann, S. <Ste...@ip...>]

Hi,

Nils will try to get us an example file. But from what I remember
you really get only one file with consecutive scan numbers 
and one monotonously increasing (1D) scan times,
which can be converted to 2D if you know the modulation time.

Yours,
Steffen

________________________________________
From: Matthew Chambers [mat...@gm...]
Sent: 15 March 2011 23:00
To: psi...@li...
Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

Sorry, I meant 1st dimension. E.g. SCX fractions, IEF strips. If each fraction only lasts a few
minutes, it might make more sense to keep in one mzML. But in that case, the 1st dimension fraction
identifier would need to be a spectrum property. Looked at another way, do the scan numbers, or
whatever the instrument uses, reset when moving to the next fraction?

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

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

Sorry, I meant 1st dimension. E.g. SCX fractions, IEF strips. If each fraction only lasts a few 
minutes, it might make more sense to keep in one mzML. But in that case, the 1st dimension fraction 
identifier would need to be a spectrum property. Looked at another way, do the scan numbers, or 
whatever the instrument uses, reset when moving to the next fraction?

-Matt


On 3/15/2011 3:54 PM, Neumann, Steffen wrote:
> Hi,
>
> no, I think the 2nd dimension is in such a rapid succession (few seconds!),
> that a single metabolite elutes across several of those,
> and hence it makes no sense to split into multiple files.
>
> Yours,
> Steffen
>
> ________________________________________
> From: Matthew Chambers [mat...@gm...]
> Sent: 15 March 2011 21:25
> To: psi...@li...
> Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ?
>
> You propose a<run>  cvParam, but there is only one run per mzML. So you are agreeing with me that
> each 2nd dimension fraction would be a separate mzML? Constructing the 2d x vs. y would require
> reading from multiple mzMLs then.
>
> -Matt
>
>
> On 3/15/2011 2:59 PM, Neumann, Steffen wrote:
>> Hi,
>>
>> Yes, GCxGC is (almost ?) always online. Here is an image:
>> http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php
>>
>> if I get it orrectly, the Y axis is the "fast" column (think seconds),
>> the X axis the "slow" column (order of minutes). Each Pixel would be a TIC,
>> with a full spectrum "behind" it. (Or did I mix the axes up ?)
>>
>> There is also some course material, including GCxGC/TOF-MS at p27
>> http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf
>>
>> So as Nils confirmed, mzML is technically capable of carrying GCxGC data
>> as a (large) number of spectra.
>>
>> However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings,
>> so that images such as the one above can be created. This would also be
>> required for 2D peak picking (or alignment). No need to encode all sorts
>> of GC column information, that might go into sepML or whatever.
>>
>> Following Nils, I'd suggest something like
>>
>> [Term]
>> id: MS:1000XXX
>> name: second column modulation time
>> def: "The time of ..." [PSI:MS]
>> xref: value-type:xsd\:float "The allowed value-type for this CV term."
>> is_a: MS:1000857 ! run attribute
>> relationship: has_units UO:0000010 ! second
>> relationship: has_units UO:0000031 ! minute
>>
>> as a<cvParam>   for the<run>. Any software ignoring this 2D nature
>> would simply see a (very) strange pattern of spectra.
>>
>> Thoughts ? Does anyone have contact with sbd. at Leco ?
>> Which are the other major players with GCxGC ?
>>
>> Yours,
>> Steffen

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Neumann, S. <Ste...@ip...>]

Hi,

no, I think the 2nd dimension is in such a rapid succession (few seconds!),
that a single metabolite elutes across several of those, 
and hence it makes no sense to split into multiple files.

Yours,
Steffen

________________________________________
From: Matthew Chambers [mat...@gm...]
Sent: 15 March 2011 21:25
To: psi...@li...
Subject: Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

You propose a <run> cvParam, but there is only one run per mzML. So you are agreeing with me that
each 2nd dimension fraction would be a separate mzML? Constructing the 2d x vs. y would require
reading from multiple mzMLs then.

-Matt


On 3/15/2011 2:59 PM, Neumann, Steffen wrote:
> Hi,
>
> Yes, GCxGC is (almost ?) always online. Here is an image:
> http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php
>
> if I get it orrectly, the Y axis is the "fast" column (think seconds),
> the X axis the "slow" column (order of minutes). Each Pixel would be a TIC,
> with a full spectrum "behind" it. (Or did I mix the axes up ?)
>
> There is also some course material, including GCxGC/TOF-MS at p27
> http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf
>
> So as Nils confirmed, mzML is technically capable of carrying GCxGC data
> as a (large) number of spectra.
>
> However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings,
> so that images such as the one above can be created. This would also be
> required for 2D peak picking (or alignment). No need to encode all sorts
> of GC column information, that might go into sepML or whatever.
>
> Following Nils, I'd suggest something like
>
> [Term]
> id: MS:1000XXX
> name: second column modulation time
> def: "The time of ..." [PSI:MS]
> xref: value-type:xsd\:float "The allowed value-type for this CV term."
> is_a: MS:1000857 ! run attribute
> relationship: has_units UO:0000010 ! second
> relationship: has_units UO:0000031 ! minute
>
> as a<cvParam>  for the<run>. Any software ignoring this 2D nature
> would simply see a (very) strange pattern of spectra.
>
> Thoughts ? Does anyone have contact with sbd. at Leco ?
> Which are the other major players with GCxGC ?
>
> Yours,
> Steffen

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

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

Also, if each pixel is a TIC from a spectrum, then the image could be easily and quickly constructed 
using the TIC chromatograms.

-Matt


On 3/15/2011 2:59 PM, Neumann, Steffen wrote:
> Hi,
>
> Yes, GCxGC is (almost ?) always online. Here is an image:
> http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php
>
> if I get it orrectly, the Y axis is the "fast" column (think seconds),
> the X axis the "slow" column (order of minutes). Each Pixel would be a TIC,
> with a full spectrum "behind" it. (Or did I mix the axes up ?)
>
> There is also some course material, including GCxGC/TOF-MS at p27
> http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf
>
> So as Nils confirmed, mzML is technically capable of carrying GCxGC data
> as a (large) number of spectra.
>
> However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings,
> so that images such as the one above can be created. This would also be
> required for 2D peak picking (or alignment). No need to encode all sorts
> of GC column information, that might go into sepML or whatever.
>
> Following Nils, I'd suggest something like
>
> [Term]
> id: MS:1000XXX
> name: second column modulation time
> def: "The time of ..." [PSI:MS]
> xref: value-type:xsd\:float "The allowed value-type for this CV term."
> is_a: MS:1000857 ! run attribute
> relationship: has_units UO:0000010 ! second
> relationship: has_units UO:0000031 ! minute
>
> as a<cvParam>  for the<run>. Any software ignoring this 2D nature
> would simply see a (very) strange pattern of spectra.
>
> Thoughts ? Does anyone have contact with sbd. at Leco ?
> Which are the other major players with GCxGC ?
>
> Yours,
> Steffen

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

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

You propose a <run> cvParam, but there is only one run per mzML. So you are agreeing with me that 
each 2nd dimension fraction would be a separate mzML? Constructing the 2d x vs. y would require 
reading from multiple mzMLs then.

-Matt


On 3/15/2011 2:59 PM, Neumann, Steffen wrote:
> Hi,
>
> Yes, GCxGC is (almost ?) always online. Here is an image:
> http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php
>
> if I get it orrectly, the Y axis is the "fast" column (think seconds),
> the X axis the "slow" column (order of minutes). Each Pixel would be a TIC,
> with a full spectrum "behind" it. (Or did I mix the axes up ?)
>
> There is also some course material, including GCxGC/TOF-MS at p27
> http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf
>
> So as Nils confirmed, mzML is technically capable of carrying GCxGC data
> as a (large) number of spectra.
>
> However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings,
> so that images such as the one above can be created. This would also be
> required for 2D peak picking (or alignment). No need to encode all sorts
> of GC column information, that might go into sepML or whatever.
>
> Following Nils, I'd suggest something like
>
> [Term]
> id: MS:1000XXX
> name: second column modulation time
> def: "The time of ..." [PSI:MS]
> xref: value-type:xsd\:float "The allowed value-type for this CV term."
> is_a: MS:1000857 ! run attribute
> relationship: has_units UO:0000010 ! second
> relationship: has_units UO:0000031 ! minute
>
> as a<cvParam>  for the<run>. Any software ignoring this 2D nature
> would simply see a (very) strange pattern of spectra.
>
> Thoughts ? Does anyone have contact with sbd. at Leco ?
> Which are the other major players with GCxGC ?
>
> Yours,
> Steffen

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Neumann, S. <Ste...@ip...>]

Hi,

Yes, GCxGC is (almost ?) always online. Here is an image:
http://www.purdue.edu/discoverypark/bioscience/facilities/mpf/capabilities.php

if I get it orrectly, the Y axis is the "fast" column (think seconds), 
the X axis the "slow" column (order of minutes). Each Pixel would be a TIC,
with a full spectrum "behind" it. (Or did I mix the axes up ?)

There is also some course material, including GCxGC/TOF-MS at p27
http://depts.washington.edu/chemcrs/bulkdisk/chem429A_spr07/notes_Comprehensive2D.pdf

So as Nils confirmed, mzML is technically capable of carrying GCxGC data
as a (large) number of spectra. 

However, I'd like to have (at least a rudimentary) encoding for the GCxGC settings, 
so that images such as the one above can be created. This would also be 
required for 2D peak picking (or alignment). No need to encode all sorts 
of GC column information, that might go into sepML or whatever.

Following Nils, I'd suggest something like 

[Term]
id: MS:1000XXX
name: second column modulation time
def: "The time of ..." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000857 ! run attribute
relationship: has_units UO:0000010 ! second
relationship: has_units UO:0000031 ! minute

as a <cvParam> for the <run>. Any software ignoring this 2D nature
would simply see a (very) strange pattern of spectra.

Thoughts ? Does anyone have contact with sbd. at Leco ?
Which are the other major players with GCxGC ?

Yours,
Steffen

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

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

Notes from the PIS MSS WG phone conference



Present: Richard, Matt, Jim, Steffen, Eric, Gerhard, Julian,





Agenda:

1) PSI Spring Workshop April 11-13

- Collaborative efforts with the PI WG on mzIdentML, mzQuantML, CV

- Finishing TraML

- Drafting SRM experiment guidelines

- Drafting a format for SRM experimental results

- MIAPE-MS finalization

- MIAPE-Quant work?

- Adjacent to the ProteomeXchange workshop

- Please attend and encourage attendance



----

2) mzML 1.1.0

- We have been contacted by Vladimir Likic, who has said that he is
representing some portions of the metabolomics community and they are
interested in seeing if mzML would be a good fit for them as a
next-generation format. See:
http://bioinformatics.bio21.unimelb.edu.au/mzml.html

+ Steffen feels there probably only minor changes required for GC-MS.
Probably only mostly just some terms like “travel time” and the like.

+ Currently the ANDI format is most often used for GC-MS, but it seems out
of date and is the format that would be replaced.

+ Steffen will be at a metabolomics conf next week at EBI and will report

- Other outstanding todo items:

  - Eric should test FAIMS support in mzML

  - Eric should test a recent file with multiple fragmentation types to see
if they are properly labeled

- Other items?



----

3) TraML development

- TraML version 0.9.4 is available at
http://www.psidev.info/index.php?q=node/405

- TraML was submitted to PSI document process

- Reviews are back and partially addressed.Still outstanding todo items

- Implementations? Please update to 0.9.4 and test

  - Matt has implemented in ProteoWizard complete to 0.9.4

  - Matt has finished the C# bindings which will enable Skyline support

 + Brendan’s comments were apparently not received so we should ask him

  - Matt will sent out a sample file generated from ProteoWizard

  - Eric will try validating with his tools

  - ISB implementation in ATAQS is done

  - Jim has an implementation but just will need to update to 0.9.4

  - Eric will also contact Amol to discuss TraML implementations

  - Dave Cox at Sciex will test implement?

  - Need to add two new terms

+ Change <Validation> to <ValidationStatus>

+ Fix <Configuration> to (1..N)

+ What about MS3 support?

+ Steffen points out that just adding another <Product> tag isn’t enough.
What if there are different collision energies for MS2 and MS3?

+ Seems like there was agreement to move <Interpretation>, <Prediction>,
<ConfigurationList> into <Product>, thereby allowing (requiring!) separate
entries for each <Product> entry. For 99% of cases, this is just a trivial
move of elements.

+ Discussion ensued about <Product> should have “isolation window target
m/z” or “selection window target m/z”.  Are we isolating (pure filter) or
selecting (scanning in a range)? Ran out of time. Continue on email or next
time.

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304



----

4) MIAPE-MS revision

- Document is ready to be submitted, but..

- We need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- Waiting to sync with MIAPE-MSI as well

- Keep working on our documents and when we’re ready, see if we should wait

- We also need to coordinate the creation of MIAPE-Quant

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out

+ Progress will continue at the workshop



----

5) Improving the controlled vocabulary

- There is a todo list based on a previous discussion

- Need someone with some time to work on it

- Some folks from PRIDE have expressed the desired to clean up the CV. Work
with them.

+ Richard will ask David Ovelleiro to send a note to the list on his efforts

+ There is a list of action items from a previous call



----

6) SRM analysis guidelines and format

- At a “Data Quality Metrics” workshop in Sydney before World HUPO (hosted
by NCI), there was strong support to try to develop a set of guidelines for
reporting of SRM experiments as there currently are none. A working group
was identified at the meeting. Eric will organize some discussions on this.

- It was also proposed that PSI work on a standard format for the reporting
of SRM experiment analysis. There was some support for this. This is
distinct from mzML, which holds the chromatograms. It is distinct from TraML
which holds the input transitions. It might have some overlap with
mzQuantML. This should be discussed and a subgroup identified.





Next meeting:

- In 2 weeks Mar 29?

+ YES

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

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

How different from a SCX/IEF separation is GCxGC? I know SCX can be done "online" (if I understand, 
this means the 2d separation is automatic with no manual intervention), but it usually isn't. Is 
GCxGC always online?

In mzML, we generally define a "run" as a single "injection" (except with MALDI...) so perhaps each 
2nd dimension fraction should be a separate mzML and the fraction # should be stored in the header 
(this would apply for SCX and IEF as well).

-Matt


On 3/15/2011 12:08 PM, Nils Hoffmann wrote:
> Hi Steffen, hi list!
>
> Am 15.03.11 16:19, schrieb Steffen Neumann:
>> Hi,
>>
>> Nils, do you have some (small!!) example data for GCxGC ?
> In which format? What would be the file size limit?
> Where should I upload it?
>>
>> We're wondering whether mzML could encode that with the current schema,
>> or if it has to be extended somehow.
> Well, basically, all you need is the second column modulation time (time
> interval between releases from the cryo-modulator onto the second
> column, for Leco Pegasus GCxGC-MS that is). This allows you, along with
> the scan rate, to calculate the
> number of scans for the second dimension (e.g. t_mod = 5s,
> scans_per_second:=spm =500 =>  2500 scans per modulation (mass spectra)).
> Then, with the number of scans per modulation, you can simply index
> every scan in the two-dimensional coordinate system. Basically, this
> should also work for LCxLC-(MS).
>>
>> How is netCDF handling 2D retention time ?
> Not at all, netCDF 2D from LECO ChromATof looks identical to 1D output,
> just with a very large number of scans (>1000000). We have to know the
> modulation time (duration on the second column) in advance or infer it
> from the baseline modulations.
>>
>> Yours,
>> Steffen
>>
> Yours,
> Nils
>