psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] psi-ms controlled voc. version 3.14.0 released

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

Hi community,

The _*version   3.14.0*_ of our beloved controlled vocabulary has been 
released.
The changes, as announced, were:
Four terms related to SQID software. The first, the SQID software 
definition term. The other three, search engine specific scores (related 
to peptides or proteins).
Additions proposed in mail "Request new CV terms to the PSI-MS 
Controlled Vocabulary submission" by lw...@em... on 31/10/2011.
A new "inlet attribute" term and three source/inlet related terms

I haven't introduced the new proposed *_dependency _*(import: 
http://unit-ontology.googlecode.com/svn/trunk/unit.obo instead old 
sourceforge) because is not properly linking PATO. I'll send an email to 
the maintainers of these...

I'll wait until tomorrow for everybody agreeing with Eric yesterday's 
email (_*Re:New terms for mzQuantML*_). In the meantime, please, check 
that everything is fine for everybody (just fine, not perfect... or 
someone is going to be angry with me at the end :( ). If nobody objects, 
I'll submit the new version (3.15.0) tomorrow!!!!

Best,
David

-- 
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] Controlled vocabulary release candidate v. 3.14.0

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

Hi community,

After the last phone conference (Nov 1st), some new terms were agreed 
(related to SQID software/algorithm and source/inlet related terms). 
I'll list them at the bottom of this mail: "Additions in the c.v. 3.14.0".
Please, check them and if anything is wrong, please send an email to the 
list (psi...@li...). If everybody agrees, I'll 
submit the new version in a couple of days.


The Peak intensity discussion, is far from finished (a new mail 
yesterday). Although the proposal about characterizing the kind of 
signal represented in spectra/chromatograms (m/z versus electro magnetic 
radiation) seems not very successful, I'll wait until everybody has 
commented about this (or something new!) related to the peak intensity.
If nothing new related to peak intensity happens in a couple of days, 
I'll send an email to the list with ALL the changes listed in Eric 
Deutsch in his Nov 1st mail (PSI MSS WG call notes) (with "all the 
changes" I mean everything after "Peak intensity discussion:" and before 
"+ Andy will check with Martin on what to do with").



Additions in the c.v. 3.14.0
======================
Four terms related to SQID software. The first, the SQID software 
definition term. The other three, search engine specific scores (related 
to peptides or proteins).
Additions proposed in mail "Request new CV terms to the PSI-MS 
Controlled Vocabulary submission" by lw...@em... on 31/10/2011.

[Term]
id: MS:1001886
name: SQID
def: "Software for data analysis of peptides and proteins." [PSI:MS]
is_a: MS:1001456 ! analysis software
is_a: MS:1001457 ! data processing software

[Term]
id: MS:1001887
name: SQID:score
def: "The SQID result 'Score'." [PSI:PI]
is_a: MS:1001143 ! search engine specific score for peptides
is_a: MS:1001153 ! search engine specific score

[Term]
id: MS:1001888
name: SQID:deltaScore
def: "The SQID result 'deltaScore'." [PSI:PI]
is_a: MS:1001143 ! search engine specific score for peptides
is_a: MS:1001153 ! search engine specific score

[Term]
id: MS:1001889
name: SQID:protein score
def: "The SQID result 'protein score'." [PSI:PI]
is_a: MS:1001116 ! single protein result details
is_a: MS:1001153 ! search engine specific score


A new "inlet attribute" terms and three source/inlet related terms

[Term]
id: MS:1001890
name: inlet attribute
def: "Property of an instrument inlet that needs a value." [PSI:MS]
relationship: part_of MS:1000458 ! source

[Term]
id: MS:1001891
name: modulation time
def: "Duration of a complete cycle of modulation in a comprehensive 
two-dimensional separation system, equals the length of a second 
dimension chromatogram, i.e., the time between two successive injections 
into the second column." [PSI:MS]
xref: value-type:xsd\:string "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

[Term]
id: MS:1001892
name: inlet temperature
def: "Temperature of the instrument inlet." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1001890 ! inlet attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius

[Term]
id: MS:1001893
name: source temperature
def: "Temperature of the instrument source." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius


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

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

Present: Steffen, Juanan, Andy, Matt, Eric, David



Discussion of CV terms is captured below. Please let me know if there are
further comments or errors. David will follow up with a slightly more
official CV amendment proposal.



modulation time



[Term]

id: MS:1000XXX

name: modulation time

def: "Duration of a complete cycle of modulation in a comprehensive
two-dimensional separation system, equals the length of a second dimension
chromatogram, i.e., the time between two successive injections into the
second column." [PSI:MS]

xref: value-type:xsd\:string "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



inlet temperature



[Term]

id: MS:1000XXX

name: inlet temperature

def: "Temperature of the instrument inlet." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000XXX ! inlet attribute

relationship: has_units UO:0000012 ! kelvin

relationship: has_units UO:0000027 ! degree celsius



source temperature



[Term]

id: MS:1000XXX

name: source temperature

def: "Temperature of the instrument source." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000482 ! source attribute

relationship: has_units UO:0000012 ! kelvin

relationship: has_units UO:0000027 ! degree celsius



[Term]

id: MS:100????

name: inlet attribute

def: "Property of an instrument inlet that needs a value." [PSI:MS]

relationship: part_of MS:1000458 ! source



+ Need to add to mzML mapping file the addition of inlet attributes,
modulation time.



SQID:



+ David will create a formal proposal of the SQID terms as suggested and
send it out for discussion/approval



Peak intensity discussion:



1) Add a “spectrum” prefix to the current “peak” terms as listed here:



 MS:1000442 spectrum

  +  MS:1000231 spectrum peak

      + MS:1000042 spectrum peak intensity (has units and value) defined
for mass spectrum

          + MS:100???? spectrum peak height (has units and value)

          + MS:100???? spectrum peak area (has units and value)



[Term]

id: MS:1000231

name: spectrum peak

def: "A localized region of relatively large ion signal in a mass spectrum.
Although peaks are often associated with particular ions, the terms peak
and ion should not be used interchangeably." [PSI:MS]

relationship: part_of MS:1000442 ! spectrum



[Term]

id: MS:1000042

name: spectrum peak intensity

def: "Intensity of ions as measured by the height or area of a peak in a
mass spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000455 ! ion selection attribute

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit

relationship: part_of MS:1000231 ! spectrum peak



[Term]

id: MS:100????

name: spectrum peak height

def: "Intensity of ions as measured by the height of a peak in a mass
spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! spectrum peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit



[Term]

id: MS:100????

name: spectrum peak area

def: "Intensity of ions as measured by the area of a peak in a mass
spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! spectrum peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit





MS:1000625 chromatogram

  +  MS:1000??? chromatogram peak

      + MS:100??? chromatogram peak intensity (has units, etc.)

          + MS:100???? chromatogram peak height (has units, etc.)

          + MS:100???? chromatogram peak area



[Term]

id: MS:100????

name: chromatogram peak

def: "A localized region of relatively large ion signal in a chromatogram."
[PSI:MS]

relationship: part_of MS:1000625 ! chromatogram



[Term]

id: MS:100????

name: chromatogram peak intensity

def: "Intensity of ions as measured by the height or area of a peak in a
chromatogram." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit

relationship: part_of MS:1000231 ! chromatogram peak



[Term]

id: MS:100????

name: chromatogram peak height

def: "Intensity of ions as measured by the height of a peak in a
chromatogram." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:100???? ! chromatogram peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit



[Term]

id: MS:100????

name: chromatogram peak area

def: "Intensity of ions as measured by the area of a peak in a
chromatogram." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:100???? ! chromatogram peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit





+ Andy will check with Martin on what to do with these. Tidy them up a
little at least:

“peak area” x2

“peak intensity”



Eric had suggested:

MS:1001843 MS1 feature height quantification (no units or value) (concept
of performing quant via this method)

MS:1001844 MS1 feature area quantification (no units or value) (concept of
performing quant via this method)



Next meeting:

- Nov 22nd 8am Seattle Time?

+ yes

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

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

Hi,

On Wed, 2011-10-26 at 16:33 +0200, Steffen Neumann wrote:
...
> 1) to add a few GC related terms:
There were no objections (but also no additions) to these,
and they were mentioned in todays PSI MSS WG call reminder.

> and 2) to add some terms specific for GCxGC-MS (and LCxLC-MS 
> for that matter). There was consensus to keep the spectra in a single 
> mzML file, but we need a way to encode the two retention dimensions-
There was some support for 2a) add a "modulation time",
but left out of todays PSI MSS WG call reminder.

It would be great if we can finalize these in the call today,
to pave the way for GC-MS based metabolomics.

Yours,
Steffen

-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

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

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

Hi everyone, this is a reminder about the PSI MSS WG teleconference call
tomorrow, Tuesday, postponed from last week. Since the US is currently
flaunting its individuality by lingering on daylight savings time while the
rest of the world has moved on, let’s switch to an hour later in the US and
same time in Europe:



http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111101T09&p1=234



09:00 San Francisco

12:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ Finland: 080011569

+ UK: 08081095644

+ USA: NEW NUMBER: 1-866-832-8490

Generic international: +44 2083222500 (UK number)



access code: 297427 #





Agenda:

The main topic will be discussion of recent controlled vocabulary terms:



modulation time

inlet temperature

source temperature

 MS:1000442 spectrum

  +  MS:1000231 peak

      + MS:1000042 peak intensity (has units and value) defined for mass
spectrum

          + MS:100???? peak height (has units and value)

          + MS:100???? peak area (has units and value)

MS:1001843 MS1 peak height quantification (no units or value) (concept of
performing quant via this method)

MS:1001844 MS1 peak area quantification (no units or value) (concept of
performing quant via this method)



Next meeting:

- Nov 22nd 8am Seattle Time?

[Psidev-ms-dev] version 3.13.0 released

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

Hi community,

As promised yesterday, version 3.13.0 released.

Added terms:
- MS:1001879 (offset voltage)
- MS:1001880 (in-source collision-induced dissociation)
- MS:1001881 (mz5 file)
- MS:1001882 (transition validation attribute)
- MS:1001883 (coefficient of variation)
- MS:1001884 (signal-to-noise ratio)
- MS:1001885 (command-line parameters)

Changed names:
- MS:1000877 (tube lens voltage)
- MS:1000139 (4000 QTRAP)

Changed definitions:
- MS:1000932 (TripleTOF 5600)
- MS:1000672 (Cliquid)

Best,

-- 
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] mzML for GCxGC/MS ?

[Nils H. <nil...@ce...>]

Hi!
I would like to offer some comments on the proposed GCxGC-MS terms.
We have been mainly working with LECO Pegasus IV acquired GCxGC-MS data,
which can currently only be exported to ANDI-MS/netcdf format
without any two-dimensional information using LECO's own ChromaTOF
software. So we ask our users to define the modulation time used during
the acquisition, which is then used as a basis in order to calculate 2D
coordinates for every acquired mass spectrum.

> and 2) to add some terms specific for GCxGC-MS (and LCxLC-MS 
> for that matter). There was consensus to keep the spectra in a single 
> mzML file, but we need a way to encode the two retention dimensions:
> 
> 2a) we can add a new "run attribute":
> 
> [Term]
> id: MS:1000XXX
> name: modulation time
> def: "The duration of a complete cycle of modulation in a comprehensive
> two-dimensional separation system, equals the length of a second
> dimension chromatogram, i.e., the time between two successive injections
> into the second column." [not PSI:MS ?]
> xref: value-type:xsd\:string "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
> 
> The conversion between the 1D scan time reported by the instruments 
> and the two dimensions spanned by the two columns can then
> be done by a little maths, which is similar to the conversion between 
> a 2D n*m matrix and a linear vector of length n*m. Software that doesn't
> know or consider this term will present spectra as usual, and a *very*
> strange TIC at worst, but is otherwise not affected.
> 
That is the current way of choice in our software Maltcms and Maui.
Everything else can be derived from the modulation time if you know the
(fixed) rate at which mass spectra have been recorded.

By the way, even LECO presents the 1D TIC of GCxGC-MS chromatograms in
their ChromaTOF software.

> 2b) Alternatively, if the mzML writer knows the modulation time, 
> it can explicitly add both/all (for, say, GCxLCxGCxLC runs ...)
> retention times as scan attributes:
> 
>      MS:1000503 ! scan attribute
>      + MS:1000826 ! elution time 
>        + MS:1000XXX ! first column elution time (def: Retention time of a
>                                    peak in the first dimension of a
>                                    comprehensive two-dimensional system)
>        + MS:1000XXX ! second column elution time (def: ... second ...)
>        + MS:1000XXX ! third column elution time 
>        ...
>        + MS:1000XXX ! seventh column elution time (you get the idea ...)
> 
> A problem here is that many scans will of course have identical elution times 
> in the first dimension, which could irritate software 
> that only expects 1D LC-MS data. 
Do I understand it right, that {first,second,third,...} column elution
time would be additional terms added to each scan? Or would the first
column elution time replace the "global" elution time of the scan?
However, adding these terms to each scan would, as Steffen said, lead to
many identical and thus rather redundant entries.
> 
> I am leaning towards solution 2a) modulation time. 
2a) is the minimal required information, so I would also favor this
proposal.
> 

Sincerely,
Nils

-- 
Nils Hoffmann                         	  phone:    +49-521-106-4342
Bielefeld University                 	   room:             U10-144
Faculty of Technology, Genome Informatics
P.O. Box 10 01 31	
33501 Bielefeld, Germany
http://www.cebitec.uni-bielefeld.de/~hoffmann

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

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

Hi,

I'd like to revive this thread, which hasn't been brought 
to some conclusion. The proposal is twofold: 

1) to add a few GC related terms:

[Term]
id: MS:1000XXX
name: inlet temperature 
def: "Inlet temperature." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
is_a: MS:1000XXX ! inlet attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius

[Term] 
id: MS:1000XXX
name: source temperature 
def: "Source temperature ... ." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius

IIRC during the last PSI-MS TelCo someone mentioned further terms 
which are reported by GC-MS systems related to the source,
such as the "transfer capillary temperature". 
Could someone knowledgeable with GC-MS please add these terms 
to this thread ?

and 2) to add some terms specific for GCxGC-MS (and LCxLC-MS 
for that matter). There was consensus to keep the spectra in a single 
mzML file, but we need a way to encode the two retention dimensions:

2a) we can add a new "run attribute":

[Term]
id: MS:1000XXX
name: modulation time
def: "The duration of a complete cycle of modulation in a comprehensive
two-dimensional separation system, equals the length of a second
dimension chromatogram, i.e., the time between two successive injections
into the second column." [not PSI:MS ?]
xref: value-type:xsd\:string "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

The conversion between the 1D scan time reported by the instruments 
and the two dimensions spanned by the two columns can then
be done by a little maths, which is similar to the conversion between 
a 2D n*m matrix and a linear vector of length n*m. Software that doesn't
know or consider this term will present spectra as usual, and a *very*
strange TIC at worst, but is otherwise not affected.

2b) Alternatively, if the mzML writer knows the modulation time, 
it can explicitly add both/all (for, say, GCxLCxGCxLC runs ...)
retention times as scan attributes:

     MS:1000503 ! scan attribute
     + MS:1000826 ! elution time 
       + MS:1000XXX ! first column elution time (def: Retention time of a
                                   peak in the first dimension of a
                                   comprehensive two-dimensional system)
       + MS:1000XXX ! second column elution time (def: ... second ...)
       + MS:1000XXX ! third column elution time 
       ...
       + MS:1000XXX ! seventh column elution time (you get the idea ...)

A problem here is that many scans will of course have identical elution times 
in the first dimension, which could irritate software 
that only expects 1D LC-MS data. 

I am leaning towards solution 2a) modulation time. 

More on multiple coupled chromatography can be found at 
http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+Matters/Nomenclature-and-Conventions-in-Comprehensive-Mult/ArticleStandard/Article/detail/58429
which could (properly cited) be used for the definition 
of the GCxGC terms.


Yours,
Steffen






On Fri, 2011-05-27 at 09:45 +0200, Steffen Neumann wrote:
...
> On Sun, 2011-03-20 at 19:00 +0100, Oliver Kohlbacher wrote:
> ...
> > 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).


> I now got my hands on some example data from Nils Hoffmann 
> http://www.cebitec.uni-bielefeld.de/~hoffmann/files/GCxGC-MS-LECO.tar.bz2
> which I converted with the OpenMS-1.8 FileConverter 
> http://msbi.ipb-halle.de/~sneumann/GCxGC_leco.mzML.bz2
> 
> 1) OpenMS is already able to extract some information from the netCDF 
>    where we lack the proper cvTerms. I would suggest 
>    (also see separate mail on "inlet attribute")
> 
> [Term]
> id: MS:1000XXX
> name: inlet temperature 
> def: "Inlet temperature." [PSI:MS]
> xref: value-type:xsd\:float "The allowed value-type for this CV term."
> is_a: MS:1000482 ! source attribute
> is_a: MS:1000XXX ! inlet attribute
> relationship: has_units UO:0000012 ! kelvin
> relationship: has_units UO:0000027 ! degree celsius
> 
> [Term] 
> id: MS:1000XXX
> name: source temperature 
> def: "Source temperature ... ." [PSI:MS]
> xref: value-type:xsd\:float "The allowed value-type for this CV term."
> is_a: MS:1000482 ! source attribute
> relationship: has_units UO:0000012 ! kelvin
> relationship: has_units UO:0000027 ! degree celsius
> 
> 2a) For GCxGC, we need to specify the 2D coordinate / time system. 
>    I would minimally suggest a new "run attribute":
> 
> [Term]
> id: MS:1000XXX
> name: modulation time
> def: "The duration of a complete cycle of modulation in a comprehensive two-dimensional separation system, equals the length of a second
> dimension chromatogram, i.e., the time between two successive injections
> into the second column." [not PSI:MS ?]
> xref: value-type:xsd\:string "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
> 
>    BTW: how do we "cite" the definition ? I it took from 
>    http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+Matters/Nomenclature-and-Conventions-in-Comprehensive-Mult/ArticleStandard/Article/detail/58429
>    There are tons more terms in this paper.
> 
> 2b) Alternatively/additionally, we'd need to be able to add 
>     several dimensions to the scan attribute "elution time". 
> 
>      MS:1000503 ! scan attribute
>      + MS:1000826 ! elution time 
>        + MS:1000XXX ! first column elution time (def: Retention time of a
>                                    peak in the first dimension of a
>                                    comprehensive two-dimensional system)
>        + MS:1000XXX ! second column elution time (def: ... second ...)
>        + MS:1000XXX ! third column elution time 
>        ...
>        + MS:1000XXX ! seventh column elution time (you get the idea ...)
> 
>      Does anyone have a better idea ? Please ? Or is this reasonable 
>      with current (and anticipated) seperation techniques ?
>      The paper above also lists GCϫGCϫGC, LC–GCϫGC or ...
>      I don't like the ordering in the name, but anything else would 
>      rather be in the scope of sepML, and we still need to reference 
>      several elution times.
> 
> Usually, the 2a) modulation time is the "run attribute" that is programmed 
> into the GCxGC-MS system when you run your samples. The actual elution
> times for each scan could be 2b) adjusted / corrected if there are any 
> shifts/deviations (for whatever reason) within the run.
> 
> Thoughts ?
> 
> Yours,
> Steffen
> 
> Just for reference, here is the netCDF metadata from above file(s):
> 
> netcdf header information GCxGC {
> dimensions:
> ...
> 	point_number = UNLIMITED ; // (43969157 currently)
> 	scan_number = 100001 ;
> variables:
> ...
> // global attributes:
> 		:netcdf_file_date_time_stamp = "20090325161325+0100" ;
> 		:experiment_date_time_stamp = "20090306200015+0100" ;
> 		:experiment_type = "Centroided Mass Spectrum" ;
> 		:test_separation_type = "Gas-Liquid Chromatography" ;
> 		:test_ms_inlet = "Capillary Direct" ;
> 		:test_ms_inlet_temperature = 275.f ;
> 		:test_ionization_mode = "Electron Impact" ;
> 		:test_ionization_polarity = "Positive Polarity" ;
> 		:test_source_temperature = 200.f ;
> 		:test_accelerating_potential = -600.f ;
> 		:test_detector_type = "Electron Multiplier" ;
> 		:test_detector_potential = -1600.f ;
> 		:test_resolution_type = "Constant Resolution" ;
> 		:test_scan_function = "Mass Scan" ;
> 		:test_scan_direction = "Up" ;
> 		:test_scan_law = "Linear" ;
> 		:test_scan_time = 0.0002f ;
> ...
> }
> 
> 

-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

[Psidev-ms-dev] Controlled vocabulary release candidate v. 3.13.0

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

Hi community,

Attached to this email (and conveniently compressed), the new version 
3.13.0.
If everybody thinks is fine, I'll submit this tomorrow evening (Europe 
time, of curse).

=====================================================
Changes in the 3.13.0 version
=====================================================

Added terms:
- MS:1001879 (offset voltage)
- MS:1001880 (in-source collision-induced dissociation)
- MS:1001881 (mz5 file)
- MS:1001882 (transition validation attribute)
- MS:1001883 (coefficient of variation)
- MS:1001884 (signal-to-noise ratio)
- MS:1001885 (command-line parameters)

Changed names:
- MS:1000877 (tube lens voltage)
- MS:1000139 (4000 QTRAP)

Changed definitions:
- MS:1000932 (TripleTOF 5600)
- MS:1000672 (Cliquid)



=====================================================
Pending things
=====================================================


Pending things 1 -> Two terms (MS:1001843 and id: MS:1001844 -peak 
intensity and area- now sons of MS:1000042 ! peak intensity) proposed by 
Eric Deutsch about “peak area” and “peak height” (last email Oct 10th 
"PSI-MS CV: peak intensity area terms").
Related to this, the term MS:1001845 ("peak area" too) has been 
obsoleted because duplicated toMS:1001844.
After this point, several mails re-opened the debate (mails from Oct12th 
- Oct25th).

Pending things 2 -> Some comments in Eric Deutsch mail (Oct 10th) not 
yet implemented in the controlled vocabulary and to be discussed :
2) Is there really a difference between “peak area” and “XIC area”. I 
suspect not. If there really is an intended subtle difference (e.g. 
“peak area” takes into account background removal, which “XIC area” is 
irrespective of background) then we should define this.
3) It seems to me that all these term names are incomplete and 
potentially misleading. For example, the “peak area” term is not really 
for the concept of “peak area”; it is the concept of “quantifying signal 
by measuring peak area”. One can infer this by knowing the parent, but 
if our goal is to create term names that can stand on their own, I think 
these should be clarified. It will be tempting to users to use the “peak 
area” term to provide a measurement of a peak area.
4) For 1859, normalized to what?
5) For 1130, can peptides have an area? Mass specs don’t see peptides, 
they see peptide ions. And they see them as peaks. So it would see that 
“peptide raw area” is a badly named term that probably when decomposed 
means the same as “peak area”. Or, if I’m wrong, can we improve the 
definition?

Pending things 3 -> Some comments by David Ovelleiro (mail Sept 27th, 
"Possible need of changing some things under "identification result 
details" (MS:1001405)") not yet implemented in the controlled vocabulary:
- comment 1: there are two terms, MS:1001362 and MS:1001114, which in 
addition to be children to their respective parents (MS:1001116 and 
MS:1001105 resp), are also direct children to MS:1001405. The problem I 
see here is that the two parents, are also direct descendants of 
MS:1001405. Is this not redundant and unnecessary? My proposal is to 
remove the is_a (direct) relationship to MS:1001405.
Please, check the picture "screen1.jpg" for a more graphical description.
- comment 2: the term "Mascot query number" (MS:1001528) is direct child 
to "spectrum identification result details" (MS:1001405). Don't you 
think that this term would be better placed under "search engine 
specific score" (MS:1001153) (child to the previous MS:1001528)
- comment 3: the terms related to the "False Discovery Rate" are, in my 
opinion, some confusing at this point. I attach a screen-shot called 
screen2.jpg to illustrate what I'm saying. At least two of the terms 
("pep:global FDR" and "prot:global FDR") seem miss located to me. Maybe 
they should work like "local FDR", with a unique term called "global 
FDR" child to both "peptide" and "proteine" / "identification confidence 
metric" (MS:1001198 and MS:1001092). Or maybe two terms could be used 
(the way is now), but children to MS:1001198 and MS:1001092 and changing 
the prefix "pep:" and "prot:" by the proper "peptide" and "protein".

Two replies (Eric Deutsch and David Creasy, mails Sept 27th) seem to 
give support to the first point. Second point rejected. Third point 
extended in Eric Deutsch mail.

Pending things 4 -> the "modification specificity N-term/C-term" related 
terms were NOT modified following the proposal in Martin Eisenacher mail 
(Sept 1st). In mail sent by David Ovelleiro (Sept 16th) changes related 
to modifications specificity were put to a stop until more consensus was 
reached. This should be clarified (pretty sure a final soultion for this 
is needed).




-- 
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] [Psidev-ms-vocab] peak intensity discussion

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

Height and area are ways of measuring intensity/abundance, thus it makes sense as a parent term. Why 
not use "peak volume" when the scan time dimension is added to m/z and intensity? The peak height 
term remains the same (although the value might change).

-Matt


On 10/25/2011 10:03 AM, Jones, Andy wrote:
> Hi all,
>
> The hierarchy below implies that height and area are sub-properties of intensity – is this correct?
>
> Just to add to the complexity, I think we also need a (possibly) separate term(s) for a “feature”
> intensity – in quantification a feature is usually defined in 2D space (RT vs MZ) i.e. software can
> sum together peaks from different scans. Some software also has an additional measure called feature
> abundance e.g.
> http://nonlineardynamics.wordpress.com/2011/04/18/how-does-progenesis-lc-ms-quantify-protein-abundance/
> but it’s difficult to figure out how this is calculated, hence difficult to know how measures from
> quant software should map onto general terms in the CV.
>
> Cheers
>
> Andy
>
> *From:*Eric Deutsch [mailto:Eri...@sy...]
> *Sent:* 24 October 2011 17:47
> *To:* psi...@li...; Mass spectrometry standard development;
> psi...@li...
> *Cc:* Eric Deutsch
> *Subject:* [Psidev-ms-vocab] peak intensity discussion
>
> Hi everyone, let’s have a separate discussion on the peak intensity issue. Here’s what we had
> previously discussed:
>
> MS:1000442 spectrum
>
> + MS:1000231 peak
>
> + MS:1000042 peak intensity (has units and value) defined for mass spectrum
>
> + MS:100???? peak height (has units and value)
>
> + MS:100???? peak area (has units and value)
>
> MS:1001843 MS1 peak height quantification (no units or value) (concept of performing quant via this
> method)
>
> MS:1001844 MS1 peak area quantification (no units or value) (concept of performing quant via this
> method)
>
> Maybe these terms need units but no value?? This is for use in mzQuantML, I believe.
>
> ---
>
> Pierrie-Alain has pointed out that we’re trying to use peak intensity for chromatograms (and mass
> spectra) but the definitions are for m/z peaks.
>
> So, what shall we do?
>
> Should we have a whole second hierarchy?
>
> MS:1000625 chromatogram
>
> + MS:1000??? chromatogram peak
>
> + MS:100??? chromatogram peak intensity (has units, etc.)
>
> + MS:100???? chromatogram peak height (has units, etc.)
>
> + MS:100???? chromatogram peak area
>
> Let’s discuss this and related issues at the call tomorrow.
>
> Thanks,
>
> Eric
>
> *From:*pierre-alain binz [mailto:pie...@is... <mailto:pie...@is...>]
> *Sent:* Thursday, October 13, 2011 1:39 AM
> *To:* psi...@li... <mailto:psi...@li...>
> *Subject:* Re: [Psidev-ms-vocab] Controlled vocabulary release candidate v. 3.12.0
>
> Hi all,
>
>
> In the CV we are always using "peak" as refered to a mass spectrum signal. We also have terms for
> chromatograms such as absorption, emission, SRM, SIM, XIC, BPC chromatograms. Those have also
> signals we can use to perform detection and quantification. These signals have also intensities. How
> do we describe them? We cannot use the peak intensity, peak area, peak height for them as they are
> now defined for mass spec peaks. That's a problem.
>
> We should either make these (peak intensity, area, height, etc) more generic such as "signal
> intensity, ..." and define them as such, valid both for chromatographic and (mass) spectral signals,
> or we should add new terms for "chromatographic peaks" and all derived child terms and explicitly
> say that peak has a definition "exclusively valid for mass spectra".
> What do you think?
>
> Pierre-Alain

Re: [Psidev-ms-dev] [Psidev-ms-vocab] peak intensity discussion

[Jones, A. <And...@li...>]

Hi all,

The hierarchy below implies that height and area are sub-properties of intensity – is this correct?

Just to add to the complexity, I think we also need a (possibly) separate term(s) for a “feature” intensity – in quantification a feature is usually defined in 2D space (RT vs MZ) i.e. software can sum together peaks from different scans. Some software also has an additional measure called feature abundance e.g. http://nonlineardynamics.wordpress.com/2011/04/18/how-does-progenesis-lc-ms-quantify-protein-abundance/ but it’s difficult to figure out how this is calculated, hence difficult to know how measures from quant software should map onto general terms in the CV.

Cheers
Andy




From: Eric Deutsch [mailto:Eri...@sy...]
Sent: 24 October 2011 17:47
To: psi...@li...; Mass spectrometry standard development; psi...@li...
Cc: Eric Deutsch
Subject: [Psidev-ms-vocab] peak intensity discussion

Hi everyone, let’s have a separate discussion on the peak intensity issue. Here’s what we had previously discussed:

MS:1000442 spectrum
  +  MS:1000231 peak
      + MS:1000042 peak intensity (has units and value) defined for mass spectrum
          + MS:100???? peak height (has units and value)
          + MS:100???? peak area (has units and value)

MS:1001843 MS1 peak height quantification (no units or value) (concept of performing quant via this method)
MS:1001844 MS1 peak area quantification (no units or value) (concept of performing quant via this method)

Maybe these terms need units but no value?? This is for use in mzQuantML, I believe.

---

Pierrie-Alain has pointed out that we’re trying to use peak intensity for chromatograms (and mass spectra) but the definitions are for m/z peaks.

So, what shall we do?

Should we have a whole second hierarchy?

MS:1000625 chromatogram
  +  MS:1000??? chromatogram peak
      + MS:100??? chromatogram peak intensity (has units, etc.)
          + MS:100???? chromatogram peak height (has units, etc.)
          + MS:100???? chromatogram peak area

Let’s discuss this and related issues at the call tomorrow.

Thanks,
Eric



From: pierre-alain binz [mailto:pie...@is...<mailto:pie...@is...>]
Sent: Thursday, October 13, 2011 1:39 AM
To: psi...@li...<mailto:psi...@li...>
Subject: Re: [Psidev-ms-vocab] Controlled vocabulary release candidate v. 3.12.0

Hi all,



In the CV we are always using "peak" as refered to a mass spectrum signal. We also have terms for chromatograms such as  absorption, emission, SRM, SIM, XIC, BPC chromatograms. Those have also signals we can use to perform detection and quantification. These signals have also intensities. How do we describe them? We cannot use the peak intensity, peak area, peak height for them as they are now defined for mass spec peaks. That's a problem.

We should either make these (peak intensity, area, height, etc) more generic such as "signal intensity, ..." and define them as such, valid both for chromatographic and (mass) spectral signals, or we should add new terms for "chromatographic peaks" and all derived child terms and explicitly say that peak has a definition "exclusively valid for mass spectra".
What do you think?

Pierre-Alain






On 11.10.2011 18:26, Eric Deutsch wrote:

Hi David, many thanks for this. Steffen, Matt, and I went through this on the call today. And our consensus suggestions are below in red..





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

> From: David Ovelleiro [mailto:do...@eb...<mailto:do...@eb...>]

> Sent: Tuesday, October 11, 2011 5:48 AM

> To: 'psi...@li...<mailto:psi...@li...>'; Mass spectrometry standard

> development; psi...@li...<mailto:psi...@li...>;

> Ste...@le...<mailto:Ste...@le...>

> Subject: [Psidev-ms-vocab] Controlled vocabulary release candidate v.

> 3.12.0

>

> Dear all,

>

> Sorry about the really long mail.

> I've divided the several things we had to do in two blocks: changes

> that

> I considered for the next release ("Changes and additions" section) and

> pending changes related to things not clarified ("Pending things").

> Attached to this mail, there's a release candidate (new version number

> will be 3.12.0). Please check the changes and additions. I expect

> everything is OK. If you don't agree with the changes, please, email

> the

> list and we'll change whatever is needed. As soon everything is agreed,

> I'll publish the new version.

>

> =====================================================

> Changes and additions

> =====================================================

>

> - Two new terms proposed by Steve Robles (last mail Oct 10th, "Request

> for new terms"): MS:1001878 ("Offset Voltage") and MS:1001879

> ("In-source collision-induced dissociation").

> Eric Deutsch commented a possible overlapping between the first one

> (MS:1001878-> "Offset Voltage") and the next two terms MS:1000876

> ("cone

> voltage") and MS:1000877 ("tube lens").

> No mails following this point.

> I should add that the last term's name ("tube lens"), maybe is better

> described as "tube lens voltage". (change not included in the temporal



I agree, let’s change to “tube lens voltage”. Any dissent to that change?





> obo file).

> The two new terms:

>

> [Term]

> id: MS:1001878

> name: Offset Voltage



Lower case except for proper names is the convention. Please change to “offset voltage”.





> def: "The potential difference between two adjacent interface voltages

> affecting in-source collision induced dissociation." [PSI:MS]

> is_a: MS:1000482 ! source attribute

> relationship: has_units UO:0000218 ! volt

>

> [Term]

> id: MS:1001879

> name: In-source collision-induced dissociation



As above. “in-source collision-induced dissociation”





> def: "The dissociation of an ion as a result of collisional excitation

> during ion transfer from an atmospheric pressure ion source and the

> mass

> spectrometer vacuum." [PSI:MS]

> is_a: MS:1000044 ! dissociation method

>

> - Change in definition for MS:1000932 ("...MDS SCIEX TripleTOF 5500..."

> changed by "...MDS SCIEX TripleTOF 5600...") (last mail Oct 10th,

> "Request for new terms")



Let’s also go with the modern name of the company:



"AB SCIEX TripleTOF 5600, a quadrupole - quadrupole - time-of-flight mass spectrometer."





> - A definition for the term MS:1000672 (name: Cliquid) (last mail Oct

> 10th, "Request for new terms"). Is an Applied Biosystems software.

> Browsing I found that maybe the definition could be something like

> this:

> def: "AB SCIEX or Applied Biosystems software for data analysis and

> quantitation." [PSI:MS]



Let’s go with modern name:



"AB SCIEX Cliquid software for data analysis and quantitation."





> I found the most complete descripcion of the software in this link:

> http://www.mass-spec-capital.com/product/cliquid-software-applied-

> biosystems-abi-unit-life-technologies-2001-18662.html

>

>

> - New term added for the mz5 format (last mail Oct 10th, "Request for

> new terms")(last mail Oct 10th, "Request for new terms"):

> [Term]

> id: MS:1001880

> name: mz5 file

> def: "mz5 file format, modeled after mzML, developed by the Steen Lab."

> [PSI:MS]

> is_a: MS:1000560 ! mass spectrometer file format



Def: "mz5 file format, modeled after mzML." [http://software.steenlab.org/mz5/]





> - Space removed in 1000139 name "4000 Q TRAP" à “4000 QTRAP”. (last

> mail

> Oct 10th, "Request for new terms")

> Does this cause a problem with obsoleted term of same name (id:

> MS:1000870)? No problems reported.

>

> - Adding 3 transition validation attributes (last mail Oct 10th,

> "Request for new terms"):

> [Term]

> id: MS:1001881

> name: transition validation attribute

> def: "Attributes of the quality of a transition that affect its

> selection as appropriate." [PSI:MS]

> relationship: part_of MS:1000908 ! transition

>

> [Term]

> id: MS:1001882

> name: coefficient of variation

> def: "Variation of a set of signal measurements calculated as the

> standard deviation relative to the mean." [PSI:MS]

> xref: value-type:xsd\:float "The allowed value-type for this CV term."

> is_a: MS:1001881 ! transition validation attribute

>

> [Term]

> id: MS:1001883

> name: signal-to-noise ratio

> def: "Unitless number providing the ratio of the total measured

> intensity of a signal relative to the estimated noise level for that

> signal." [PSI:MS]

> xref: value-type:xsd\:float "The allowed value-type for this CV term."

> is_a: MS:1001881 ! transition validation attribute



Good.





>

> - Adding 1 command-line parameter term as suggested by Magnus (last

> mail

> Oct 10th, "Request for new terms"):

>

> [Term]

> id: MS:1001884

> name: command-line parameters

> def: "Parameters string passed to a command-line interface software

> application." [PSI:MS]

> xref: value-type:xsd\:string "The allowed value-type for this CV term."

> is_a: MS:1000630 ! data processing parameter



def: "Parameters string passed to a command-line interface software application, omitting the executable name." [PSI:MS]





>

> - Two terms (MS:1001843 and id: MS:1001844 -peak intensity and area-

> now

> sons of MS:1000042 ! peak intensity) proposed by Eric Deutsch about

> “peak area” and “peak height” (last email Oct 10th "PSI-MS CV: peak

> intensity area terms").



We don’t think this is a very good state for things. Here’s a revised proposal:



[Term]

id: MS:1000042

name: peak intensity

def: "Intensity of ions as measured by the height or area of a peak in a mass spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000455 ! ion selection attribute

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit

relationship: part_of MS:1000231 ! peak

(no change)



[Term]

id: MS:1001843

name: peak intensity

def: "Maximum intensity of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype

Change to:

name: MS1 peak height quantification

def: "Quantification value determined via MS1 peak maximum intensity." [PSI:PI]



[Term]

id: MS:1001844

name: peak area

def: "Area of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype

Change to:

name: MS1 peak area quantification

def: "Quantification value determined via MS1 peak area." [PSI:PI]



Add:



[Term]

id: MS:100????

name: peak height

def: "Intensity of ions as measured by the height of a peak in a mass spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit



[Term]

id: MS:100????

name: peak area

def: "Intensity of ions as measured by the area of a peak in a mass spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit





> Related to this, the term MS:1001845 ("peak area" too) has been

> obsoleted because duplicated toMS:1001844.



Good.



[stopped here.]





>

> =====================================================

> Pending things

> =====================================================

>

> Pending things 1 -> Some comments in Eric Deutsch mail (Oct 10th) not

> yet implemented in the controlled vocabulary and to be discussed :

> 2) Is there really a difference between “peak area” and “XIC area”. I

> suspect not. If there really is an intended subtle difference (e.g.

> “peak area” takes into account background removal, which “XIC area” is

> irrespective of background) then we should define this.

> 3) It seems to me that all these term names are incomplete and

> potentially misleading. For example, the “peak area” term is not really

> for the concept of “peak area”; it is the concept of “quantifying

> signal

> by measuring peak area”. One can infer this by knowing the parent, but

> if our goal is to create term names that can stand on their own, I

> think

> these should be clarified. It will be tempting to users to use the

> “peak

> area” term to provide a measurement of a peak area.

> 4) For 1859, normalized to what?

> 5) For 1130, can peptides have an area? Mass specs don’t see peptides,

> they see peptide ions. And they see them as peaks. So it would see that

> “peptide raw area” is a badly named term that probably when decomposed

> means the same as “peak area”. Or, if I’m wrong, can we improve the

> definition?

>

> Pending things 2 -> Some comments by David Ovelleiro (mail Sept 27th,

> "Possible need of changing some things under "identification result

> details" (MS:1001405)") not yet implemented in the controlled

> vocabulary:

> - comment 1: there are two terms, MS:1001362 and MS:1001114, which in

> addition to be children to their respective parents (MS:1001116 and

> MS:1001105 resp), are also direct children to MS:1001405. The problem I

> see here is that the two parents, are also direct descendants of

> MS:1001405. Is this not redundant and unnecessary? My proposal is to

> remove the is_a (direct) relationship to MS:1001405.

> Please, check the picture "screen1.jpg" for a more graphical

> description.

> - comment 2: the term "Mascot query number" (MS:1001528) is direct

> child

> to "spectrum identification result details" (MS:1001405). Don't you

> think that this term would be better placed under "search engine

> specific score" (MS:1001153) (child to the previous MS:1001528)

> - comment 3: the terms related to the "False Discovery Rate" are, in my

> opinion, some confusing at this point. I attach a screen-shot called

> screen2.jpg to illustrate what I'm saying. At least two of the terms

> ("pep:global FDR" and "prot:global FDR") seem miss located to me. Maybe

> they should work like "local FDR", with a unique term called "global

> FDR" child to both "peptide" and "proteine" / "identification

> confidence

> metric" (MS:1001198 and MS:1001092). Or maybe two terms could be used

> (the way is now), but children to MS:1001198 and MS:1001092 and

> changing

> the prefix "pep:" and "prot:" by the proper "peptide" and "protein".

>

> Two replies (Eric Deutsch and David Creasy, mails Sept 27th) seem to

> give support to the first point. Second point rejected. Third point

> extended in Eric Deutsch mail.

>

> Pending things 3 -> the "modification specificity N-term/C-term"

> related

> terms were NOT modified following the proposal in Martin Eisenacher

> mail

> (Sept 1st). In mail sent by David Ovelleiro (Sept 16th) changes related

> to modifications specificity were put to a stop until more consensus

> was

> reached. This should be clarified (pretty sure a final soultion for

> this

> is needed).

>

>

> =======================================================================

> ==========

>

>

> Thanks for your attention.

>

> --

> David Ovelleiro

> Bioinformatician

> PRIDE Group

> Proteomics Services Team, PANDA Group

> EMBL European Bioinformatics Institute

> Wellcome Trust Genome Campus

> Hinxton, Cambridge, UK

> CB10 1SD





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

All the data continuously generated in your IT infrastructure contains a

definitive record of customers, application performance, security

threats, fraudulent activity and more. Splunk takes this data and makes

sense of it. Business sense. IT sense. Common sense.

http://p.sf.net/sfu/splunk-d2d-oct



_______________________________________________

Psidev-ms-vocab mailing list

Psi...@li...<mailto:Psi...@li...>

https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab

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

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

Hi everyone, I apologize for the quick change, but I am now unable to make
the call tomorrow, so let’s postpone. Let’s tentatively reschedule for
Tuesday in a week then.



Sorry about the change,

Eric





*From:* Eric Deutsch [mailto:Eri...@sy...]
*Sent:* Monday, October 24, 2011 9:53 AM
*To:* Mass spectrometry standard development
*Cc:* Eric Deutsch
*Subject:* PSI MSS WG call reminder



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



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ Finland: 080011569

+ UK: 08081095644

+ USA: NEW NUMBER: 1-866-832-8490

Generic international: +44 2083222500 (UK number)



access code: 297427 #





Agenda:

1) TraML development

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

- TraML manuscript is submitted



----

2) MIAPE-MS revision

- Action items for MIAPE – MS



----

3) Improving the controlled vocabulary

- Discuss proposed terms cleanup thread(s)





Next meeting:

- In 1 week Tue Nov 1 8am Seattle Time? <EU/US DST mismatch alert!>

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

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

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



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ Finland: 080011569

+ UK: 08081095644

+ USA: NEW NUMBER: 1-866-832-8490

Generic international: +44 2083222500 (UK number)



access code: 297427 #





Agenda:

1) TraML development

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

- TraML manuscript is submitted



----

2) MIAPE-MS revision

- Action items for MIAPE – MS



----

3) Improving the controlled vocabulary

- Discuss proposed terms cleanup thread(s)





Next meeting:

- In 1 week Tue Nov 1 8am Seattle Time? <EU/US DST mismatch alert!>

[Psidev-ms-dev] peak intensity discussion

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

Hi everyone, let’s have a separate discussion on the peak intensity issue.
Here’s what we had previously discussed:



MS:1000442 spectrum

  +  MS:1000231 peak

      + MS:1000042 peak intensity (has units and value) defined for mass
spectrum

          + MS:100???? peak height (has units and value)

          + MS:100???? peak area (has units and value)



MS:1001843 MS1 peak height quantification (no units or value) (concept of
performing quant via this method)

MS:1001844 MS1 peak area quantification (no units or value) (concept of
performing quant via this method)



Maybe these terms need units but no value?? This is for use in mzQuantML, I
believe.



---



Pierrie-Alain has pointed out that we’re trying to use peak intensity for
chromatograms (and mass spectra) but the definitions are for m/z peaks.



So, what shall we do?



Should we have a whole second hierarchy?



MS:1000625 chromatogram

  +  MS:1000??? chromatogram peak

      + MS:100??? chromatogram peak intensity (has units, etc.)

          + MS:100???? chromatogram peak height (has units, etc.)

          + MS:100???? chromatogram peak area



Let’s discuss this and related issues at the call tomorrow.



Thanks,

Eric







*From:* pierre-alain binz [mailto:pie...@is...]
*Sent:* Thursday, October 13, 2011 1:39 AM
*To:* psi...@li...
*Subject:* Re: [Psidev-ms-vocab] Controlled vocabulary release candidate v.
3.12.0



Hi all,




In the CV we are always using "peak" as refered to a mass spectrum signal.
We also have terms for chromatograms such as  absorption, emission, SRM,
SIM, XIC, BPC chromatograms. Those have also signals we can use to perform
detection and quantification. These signals have also intensities. How do we
describe them? We cannot use the peak intensity, peak area, peak height for
them as they are now defined for mass spec peaks. That's a problem.

We should either make these (peak intensity, area, height, etc) more generic
such as "signal intensity, ..." and define them as such, valid both for
chromatographic and (mass) spectral signals, or we should add new terms for
"chromatographic peaks" and all derived child terms and explicitly say that
peak has a definition "exclusively valid for mass spectra".
What do you think?

Pierre-Alain






On 11.10.2011 18:26, Eric Deutsch wrote:

Hi David, many thanks for this. Steffen, Matt, and I went through this on
the call today. And our consensus suggestions are below in red..





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

> From: David Ovelleiro [mailto:do...@eb...]

> Sent: Tuesday, October 11, 2011 5:48 AM

> To: 'psi...@li...'; Mass spectrometry standard

> development; psi...@li...;

> Ste...@le...

> Subject: [Psidev-ms-vocab] Controlled vocabulary release candidate v.

> 3.12.0

>

> Dear all,

>

> Sorry about the really long mail.

> I've divided the several things we had to do in two blocks: changes

> that

> I considered for the next release ("Changes and additions" section) and

> pending changes related to things not clarified ("Pending things").

> Attached to this mail, there's a release candidate (new version number

> will be 3.12.0). Please check the changes and additions. I expect

> everything is OK. If you don't agree with the changes, please, email

> the

> list and we'll change whatever is needed. As soon everything is agreed,

> I'll publish the new version.

>

> =====================================================

> Changes and additions

> =====================================================

>

> - Two new terms proposed by Steve Robles (last mail Oct 10th, "Request

> for new terms"): MS:1001878 ("Offset Voltage") and MS:1001879

> ("In-source collision-induced dissociation").

> Eric Deutsch commented a possible overlapping between the first one

> (MS:1001878-> "Offset Voltage") and the next two terms MS:1000876

> ("cone

> voltage") and MS:1000877 ("tube lens").

> No mails following this point.

> I should add that the last term's name ("tube lens"), maybe is better

> described as "tube lens voltage". (change not included in the temporal



I agree, let’s change to “tube lens voltage”. Any dissent to that change?





> obo file).

> The two new terms:

>

> [Term]

> id: MS:1001878

> name: Offset Voltage



Lower case except for proper names is the convention. Please change to
“offset voltage”.





> def: "The potential difference between two adjacent interface voltages

> affecting in-source collision induced dissociation." [PSI:MS]

> is_a: MS:1000482 ! source attribute

> relationship: has_units UO:0000218 ! volt

>

> [Term]

> id: MS:1001879

> name: In-source collision-induced dissociation



As above. “in-source collision-induced dissociation”





> def: "The dissociation of an ion as a result of collisional excitation

> during ion transfer from an atmospheric pressure ion source and the

> mass

> spectrometer vacuum." [PSI:MS]

> is_a: MS:1000044 ! dissociation method

>

> - Change in definition for MS:1000932 ("...MDS SCIEX TripleTOF 5500..."

> changed by "...MDS SCIEX TripleTOF 5600...") (last mail Oct 10th,

> "Request for new terms")



Let’s also go with the modern name of the company:



"AB SCIEX TripleTOF 5600, a quadrupole - quadrupole - time-of-flight mass
spectrometer."





> - A definition for the term MS:1000672 (name: Cliquid) (last mail Oct

> 10th, "Request for new terms"). Is an Applied Biosystems software.

> Browsing I found that maybe the definition could be something like

> this:

> def: "AB SCIEX or Applied Biosystems software for data analysis and

> quantitation." [PSI:MS]



Let’s go with modern name:



"AB SCIEX Cliquid software for data analysis and quantitation."





> I found the most complete descripcion of the software in this link:

> http://www.mass-spec-capital.com/product/cliquid-software-applied-

> biosystems-abi-unit-life-technologies-2001-18662.html

>

>

> - New term added for the mz5 format (last mail Oct 10th, "Request for

> new terms")(last mail Oct 10th, "Request for new terms"):

> [Term]

> id: MS:1001880

> name: mz5 file

> def: "mz5 file format, modeled after mzML, developed by the Steen Lab."

> [PSI:MS]

> is_a: MS:1000560 ! mass spectrometer file format



Def: "mz5 file format, modeled after mzML." [
http://software.steenlab.org/mz5/]





> - Space removed in 1000139 name "4000 Q TRAP" à “4000 QTRAP”. (last

> mail

> Oct 10th, "Request for new terms")

> Does this cause a problem with obsoleted term of same name (id:

> MS:1000870)? No problems reported.

>

> - Adding 3 transition validation attributes (last mail Oct 10th,

> "Request for new terms"):

> [Term]

> id: MS:1001881

> name: transition validation attribute

> def: "Attributes of the quality of a transition that affect its

> selection as appropriate." [PSI:MS]

> relationship: part_of MS:1000908 ! transition

>

> [Term]

> id: MS:1001882

> name: coefficient of variation

> def: "Variation of a set of signal measurements calculated as the

> standard deviation relative to the mean." [PSI:MS]

> xref: value-type:xsd\:float "The allowed value-type for this CV term."

> is_a: MS:1001881 ! transition validation attribute

>

> [Term]

> id: MS:1001883

> name: signal-to-noise ratio

> def: "Unitless number providing the ratio of the total measured

> intensity of a signal relative to the estimated noise level for that

> signal." [PSI:MS]

> xref: value-type:xsd\:float "The allowed value-type for this CV term."

> is_a: MS:1001881 ! transition validation attribute



Good.





>

> - Adding 1 command-line parameter term as suggested by Magnus (last

> mail

> Oct 10th, "Request for new terms"):

>

> [Term]

> id: MS:1001884

> name: command-line parameters

> def: "Parameters string passed to a command-line interface software

> application." [PSI:MS]

> xref: value-type:xsd\:string "The allowed value-type for this CV term."

> is_a: MS:1000630 ! data processing parameter



def: "Parameters string passed to a command-line interface software
application, omitting the executable name." [PSI:MS]





>

> - Two terms (MS:1001843 and id: MS:1001844 -peak intensity and area-

> now

> sons of MS:1000042 ! peak intensity) proposed by Eric Deutsch about

> “peak area” and “peak height” (last email Oct 10th "PSI-MS CV: peak

> intensity area terms").



We don’t think this is a very good state for things. Here’s a revised
proposal:



[Term]

id: MS:1000042

name: peak intensity

def: "Intensity of ions as measured by the height or area of a peak in a
mass spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000455 ! ion selection attribute

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit

relationship: part_of MS:1000231 ! peak

(no change)



[Term]

id: MS:1001843

name: peak intensity

def: "Maximum intensity of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype

Change to:

name: MS1 peak height quantification

def: "Quantification value determined via MS1 peak maximum intensity."
[PSI:PI]



[Term]

id: MS:1001844

name: peak area

def: "Area of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype

Change to:

name: MS1 peak area quantification

def: "Quantification value determined via MS1 peak area." [PSI:PI]



Add:



[Term]

id: MS:100????

name: peak height

def: "Intensity of ions as measured by the height of a peak in a mass
spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit



[Term]

id: MS:100????

name: peak area

def: "Intensity of ions as measured by the area of a peak in a mass
spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit





> Related to this, the term MS:1001845 ("peak area" too) has been

> obsoleted because duplicated toMS:1001844.



Good.



[stopped here.]





>

> =====================================================

> Pending things

> =====================================================

>

> Pending things 1 -> Some comments in Eric Deutsch mail (Oct 10th) not

> yet implemented in the controlled vocabulary and to be discussed :

> 2) Is there really a difference between “peak area” and “XIC area”. I

> suspect not. If there really is an intended subtle difference (e.g.

> “peak area” takes into account background removal, which “XIC area” is

> irrespective of background) then we should define this.

> 3) It seems to me that all these term names are incomplete and

> potentially misleading. For example, the “peak area” term is not really

> for the concept of “peak area”; it is the concept of “quantifying

> signal

> by measuring peak area”. One can infer this by knowing the parent, but

> if our goal is to create term names that can stand on their own, I

> think

> these should be clarified. It will be tempting to users to use the

> “peak

> area” term to provide a measurement of a peak area.

> 4) For 1859, normalized to what?

> 5) For 1130, can peptides have an area? Mass specs don’t see peptides,

> they see peptide ions. And they see them as peaks. So it would see that

> “peptide raw area” is a badly named term that probably when decomposed

> means the same as “peak area”. Or, if I’m wrong, can we improve the

> definition?

>

> Pending things 2 -> Some comments by David Ovelleiro (mail Sept 27th,

> "Possible need of changing some things under "identification result

> details" (MS:1001405)") not yet implemented in the controlled

> vocabulary:

> - comment 1: there are two terms, MS:1001362 and MS:1001114, which in

> addition to be children to their respective parents (MS:1001116 and

> MS:1001105 resp), are also direct children to MS:1001405. The problem I

> see here is that the two parents, are also direct descendants of

> MS:1001405. Is this not redundant and unnecessary? My proposal is to

> remove the is_a (direct) relationship to MS:1001405.

> Please, check the picture "screen1.jpg" for a more graphical

> description.

> - comment 2: the term "Mascot query number" (MS:1001528) is direct

> child

> to "spectrum identification result details" (MS:1001405). Don't you

> think that this term would be better placed under "search engine

> specific score" (MS:1001153) (child to the previous MS:1001528)

> - comment 3: the terms related to the "False Discovery Rate" are, in my

> opinion, some confusing at this point. I attach a screen-shot called

> screen2.jpg to illustrate what I'm saying. At least two of the terms

> ("pep:global FDR" and "prot:global FDR") seem miss located to me. Maybe

> they should work like "local FDR", with a unique term called "global

> FDR" child to both "peptide" and "proteine" / "identification

> confidence

> metric" (MS:1001198 and MS:1001092). Or maybe two terms could be used

> (the way is now), but children to MS:1001198 and MS:1001092 and

> changing

> the prefix "pep:" and "prot:" by the proper "peptide" and "protein".

>

> Two replies (Eric Deutsch and David Creasy, mails Sept 27th) seem to

> give support to the first point. Second point rejected. Third point

> extended in Eric Deutsch mail.

>

> Pending things 3 -> the "modification specificity N-term/C-term"

> related

> terms were NOT modified following the proposal in Martin Eisenacher

> mail

> (Sept 1st). In mail sent by David Ovelleiro (Sept 16th) changes related

> to modifications specificity were put to a stop until more consensus

> was

> reached. This should be clarified (pretty sure a final soultion for

> this

> is needed).

>

>

> =======================================================================

> ==========

>

>

> Thanks for your attention.

>

> --

> David Ovelleiro

> Bioinformatician

> PRIDE Group

> Proteomics Services Team, PANDA Group

> EMBL European Bioinformatics Institute

> Wellcome Trust Genome Campus

> Hinxton, Cambridge, UK

> CB10 1SD






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

All the data continuously generated in your IT infrastructure contains a

definitive record of customers, application performance, security

threats, fraudulent activity and more. Splunk takes this data and makes

sense of it. Business sense. IT sense. Common sense.

http://p.sf.net/sfu/splunk-d2d-oct




_______________________________________________

Psidev-ms-vocab mailing list

Psi...@li...

https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab

[Psidev-ms-dev] Dropbox folder to share MIAPE Quant examples

[Salvador M. de B. <sma...@pr...>]

Hi all:

                The example files for different quantification techniques
has been updated to the latest version of the MIAPE Quant (v0.81).

                So here you have the dropbox link to join to the shared
folder containing all the files. Feel free to join: 

https://www.dropbox.com/link/17.By0sd77JCd?k=da1fbbfd88a31f901c08189ee21c7bf
c

The MIAPE Quant document is in “MIAPE Quant\Latest
Version\0.81\MIAPE_Quant_v0.81.docx” and example files in “MIAPE
Quant\Latest Version\0.81\examples” folder.

Regards,

 

 

Salvador Martínez de Bartolomé Izquierdo 

Bioinformatics Support - ProteoRed

Lab- B1, National Center for Biotechnology 

C/ Darwin, 3 Universidad Autónoma de Madrid Cantoblanco, 

28049 Madrid Spain

Phone: +34 91 585 4613

Fax: +34 91 585 4506

 

 <http://www.proteored.org> http://www.proteored.org

 <http://proteo.cnb.csic.es/trac> http://proteo.cnb.csic.es/trac

 <https://sites.google.com/site/bioinformaticaproteomica/>
https://sites.google.com/site/bioinformaticaproteomica/

 

 

De: Salvador Martínez de Bartolomé [mailto:sma...@pr...] 
Enviado el: 04 October 2011 13:33
Para: 'PSI PI Dev'; 'psi...@li...'
(psi...@li...)
Asunto: Latest MIAPE Quant guidelines definition

 

Hi all:

                Below you will find the last conference call minutes
regarding the MIAPE Quant discussion.

                Attached, the latest version of the MIAPE Quant document
(version 0.81)

               Example documents will be shared to the list as soon as they
were updated.

                As usual, any comment will be appreciated.

                Best regards,

 

 

Salvador Martínez de Bartolomé Izquierdo 

Bioinformatics Support - ProteoRed

Lab- B1, National Center for Biotechnology 

C/ Darwin, 3 Universidad Autónoma de Madrid Cantoblanco, 

28049 Madrid Spain

Phone: +34 91 585 4613

Fax: +34 91 585 4506

 

 <http://www.proteored.org> http://www.proteored.org

 <http://proteo.cnb.csic.es/trac> http://proteo.cnb.csic.es/trac

 <https://sites.google.com/site/bioinformaticaproteomica/>
https://sites.google.com/site/bioinformaticaproteomica/

 

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

PSI teleconference. September, 29th 2011.

 

1.- MIAPE Quant.

 

There are a couple of minimal issues to discuss from the proposed latest
version. 

 

a)      Sections 4.2 (Feature selection and/or matching method) and 4.4
(Description of the method of the basic / raw quantification values
determination for each feature (optional) / peptide) should be merged due to
the same information could be written in any of both. The attendees decided
to join both in only one section  (4.2).

 

b)      Section 5 should be reformatted to describe the results according to
the resulting level (feature, peptide and protein) only when they were
available.  

 

During this debate, a new need should be analyzed to distinguish between
input data (from ms) and basic raw data for quantification (features).

In fact, there was an agreement for renaming ‘basic/raw data’ as ‘primary
extracted quantitation values’.

In that case the general MIAPE purpose is to report only the relevant data
that are part of the results and the way to obtain them (parameters).

The need of reporting the estimation of correctness for each quantification
value was also discussed. (I’m not sure which was the agreement).

 

Finally the results section will be as follows:

 

5.1. (Features and peptides results):

            5.1.1.- Results at feature level (primary extracted
quantification values): Peptide signal with several charges states or
different PTMs. 

            5.1.2.- Results at peptide entity level: aggregated of 5.1.1
features with the same peptide sequence.

 

                5.2.- (Protein results):

                                5.2.1.- Individual proteins.

                                5.2.2.- replicates/assays aggregation: Same
quantified protein across the several replicates/assays defined in the
experiment.

 

c)      The new version (and the examples provided by ProteoRed’s labs)
should be shared by DropBox folder to revised them.

 

d)      John Cottrell proposed to create a glossary of terms to prevent
misunderstanding of acronyms (f.i. SRM, MRM, etc…). All attendees approved
with this idea. 

 

 

 

 

 

Re: [Psidev-ms-dev] [Psidev-ms-vocab] Controlled vocabulary release candidate v. 3.12.0

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

Hi David, many thanks for this. Steffen, Matt, and I went through this on
the call today. And our consensus suggestions are below in red..





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

> From: David Ovelleiro [mailto:do...@eb...]

> Sent: Tuesday, October 11, 2011 5:48 AM

> To: 'psi...@li...'; Mass spectrometry standard

> development; psi...@li...;

> Ste...@le...

> Subject: [Psidev-ms-vocab] Controlled vocabulary release candidate v.

> 3.12.0

>

> Dear all,

>

> Sorry about the really long mail.

> I've divided the several things we had to do in two blocks: changes

> that

> I considered for the next release ("Changes and additions" section) and

> pending changes related to things not clarified ("Pending things").

> Attached to this mail, there's a release candidate (new version number

> will be 3.12.0). Please check the changes and additions. I expect

> everything is OK. If you don't agree with the changes, please, email

> the

> list and we'll change whatever is needed. As soon everything is agreed,

> I'll publish the new version.

>

> =====================================================

> Changes and additions

> =====================================================

>

> - Two new terms proposed by Steve Robles (last mail Oct 10th, "Request

> for new terms"): MS:1001878 ("Offset Voltage") and MS:1001879

> ("In-source collision-induced dissociation").

> Eric Deutsch commented a possible overlapping between the first one

> (MS:1001878-> "Offset Voltage") and the next two terms MS:1000876

> ("cone

> voltage") and MS:1000877 ("tube lens").

> No mails following this point.

> I should add that the last term's name ("tube lens"), maybe is better

> described as "tube lens voltage". (change not included in the temporal



I agree, let’s change to “tube lens voltage”. Any dissent to that change?





> obo file).

> The two new terms:

>

> [Term]

> id: MS:1001878

> name: Offset Voltage



Lower case except for proper names is the convention. Please change to
“offset voltage”.





> def: "The potential difference between two adjacent interface voltages

> affecting in-source collision induced dissociation." [PSI:MS]

> is_a: MS:1000482 ! source attribute

> relationship: has_units UO:0000218 ! volt

>

> [Term]

> id: MS:1001879

> name: In-source collision-induced dissociation



As above. “in-source collision-induced dissociation”





> def: "The dissociation of an ion as a result of collisional excitation

> during ion transfer from an atmospheric pressure ion source and the

> mass

> spectrometer vacuum." [PSI:MS]

> is_a: MS:1000044 ! dissociation method

>

> - Change in definition for MS:1000932 ("...MDS SCIEX TripleTOF 5500..."

> changed by "...MDS SCIEX TripleTOF 5600...") (last mail Oct 10th,

> "Request for new terms")



Let’s also go with the modern name of the company:



"AB SCIEX TripleTOF 5600, a quadrupole - quadrupole - time-of-flight mass
spectrometer."





> - A definition for the term MS:1000672 (name: Cliquid) (last mail Oct

> 10th, "Request for new terms"). Is an Applied Biosystems software.

> Browsing I found that maybe the definition could be something like

> this:

> def: "AB SCIEX or Applied Biosystems software for data analysis and

> quantitation." [PSI:MS]



Let’s go with modern name:



"AB SCIEX Cliquid software for data analysis and quantitation."





> I found the most complete descripcion of the software in this link:

> http://www.mass-spec-capital.com/product/cliquid-software-applied-

> biosystems-abi-unit-life-technologies-2001-18662.html

>

>

> - New term added for the mz5 format (last mail Oct 10th, "Request for

> new terms")(last mail Oct 10th, "Request for new terms"):

> [Term]

> id: MS:1001880

> name: mz5 file

> def: "mz5 file format, modeled after mzML, developed by the Steen Lab."

> [PSI:MS]

> is_a: MS:1000560 ! mass spectrometer file format



Def: "mz5 file format, modeled after mzML." [
http://software.steenlab.org/mz5/]





> - Space removed in 1000139 name "4000 Q TRAP" à “4000 QTRAP”. (last

> mail

> Oct 10th, "Request for new terms")

> Does this cause a problem with obsoleted term of same name (id:

> MS:1000870)? No problems reported.

>

> - Adding 3 transition validation attributes (last mail Oct 10th,

> "Request for new terms"):

> [Term]

> id: MS:1001881

> name: transition validation attribute

> def: "Attributes of the quality of a transition that affect its

> selection as appropriate." [PSI:MS]

> relationship: part_of MS:1000908 ! transition

>

> [Term]

> id: MS:1001882

> name: coefficient of variation

> def: "Variation of a set of signal measurements calculated as the

> standard deviation relative to the mean." [PSI:MS]

> xref: value-type:xsd\:float "The allowed value-type for this CV term."

> is_a: MS:1001881 ! transition validation attribute

>

> [Term]

> id: MS:1001883

> name: signal-to-noise ratio

> def: "Unitless number providing the ratio of the total measured

> intensity of a signal relative to the estimated noise level for that

> signal." [PSI:MS]

> xref: value-type:xsd\:float "The allowed value-type for this CV term."

> is_a: MS:1001881 ! transition validation attribute



Good.





>

> - Adding 1 command-line parameter term as suggested by Magnus (last

> mail

> Oct 10th, "Request for new terms"):

>

> [Term]

> id: MS:1001884

> name: command-line parameters

> def: "Parameters string passed to a command-line interface software

> application." [PSI:MS]

> xref: value-type:xsd\:string "The allowed value-type for this CV term."

> is_a: MS:1000630 ! data processing parameter



def: "Parameters string passed to a command-line interface software
application, omitting the executable name." [PSI:MS]





>

> - Two terms (MS:1001843 and id: MS:1001844 -peak intensity and area-

> now

> sons of MS:1000042 ! peak intensity) proposed by Eric Deutsch about

> “peak area” and “peak height” (last email Oct 10th "PSI-MS CV: peak

> intensity area terms").



We don’t think this is a very good state for things. Here’s a revised
proposal:



[Term]

id: MS:1000042

name: peak intensity

def: "Intensity of ions as measured by the height or area of a peak in a
mass spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000455 ! ion selection attribute

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit

relationship: part_of MS:1000231 ! peak

(no change)



[Term]

id: MS:1001843

name: peak intensity

def: "Maximum intensity of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype

Change to:

name: MS1 peak height quantification

def: "Quantification value determined via MS1 peak maximum intensity."
[PSI:PI]



[Term]

id: MS:1001844

name: peak area

def: "Area of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype

Change to:

name: MS1 peak area quantification

def: "Quantification value determined via MS1 peak area." [PSI:PI]



Add:



[Term]

id: MS:100????

name: peak height

def: "Intensity of ions as measured by the height of a peak in a mass
spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit



[Term]

id: MS:100????

name: peak area

def: "Intensity of ions as measured by the area of a peak in a mass
spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000042 ! peak intensity

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit





> Related to this, the term MS:1001845 ("peak area" too) has been

> obsoleted because duplicated toMS:1001844.



Good.



[stopped here.]





>

> =====================================================

> Pending things

> =====================================================

>

> Pending things 1 -> Some comments in Eric Deutsch mail (Oct 10th) not

> yet implemented in the controlled vocabulary and to be discussed :

> 2) Is there really a difference between “peak area” and “XIC area”. I

> suspect not. If there really is an intended subtle difference (e.g.

> “peak area” takes into account background removal, which “XIC area” is

> irrespective of background) then we should define this.

> 3) It seems to me that all these term names are incomplete and

> potentially misleading. For example, the “peak area” term is not really

> for the concept of “peak area”; it is the concept of “quantifying

> signal

> by measuring peak area”. One can infer this by knowing the parent, but

> if our goal is to create term names that can stand on their own, I

> think

> these should be clarified. It will be tempting to users to use the

> “peak

> area” term to provide a measurement of a peak area.

> 4) For 1859, normalized to what?

> 5) For 1130, can peptides have an area? Mass specs don’t see peptides,

> they see peptide ions. And they see them as peaks. So it would see that

> “peptide raw area” is a badly named term that probably when decomposed

> means the same as “peak area”. Or, if I’m wrong, can we improve the

> definition?

>

> Pending things 2 -> Some comments by David Ovelleiro (mail Sept 27th,

> "Possible need of changing some things under "identification result

> details" (MS:1001405)") not yet implemented in the controlled

> vocabulary:

> - comment 1: there are two terms, MS:1001362 and MS:1001114, which in

> addition to be children to their respective parents (MS:1001116 and

> MS:1001105 resp), are also direct children to MS:1001405. The problem I

> see here is that the two parents, are also direct descendants of

> MS:1001405. Is this not redundant and unnecessary? My proposal is to

> remove the is_a (direct) relationship to MS:1001405.

> Please, check the picture "screen1.jpg" for a more graphical

> description.

> - comment 2: the term "Mascot query number" (MS:1001528) is direct

> child

> to "spectrum identification result details" (MS:1001405). Don't you

> think that this term would be better placed under "search engine

> specific score" (MS:1001153) (child to the previous MS:1001528)

> - comment 3: the terms related to the "False Discovery Rate" are, in my

> opinion, some confusing at this point. I attach a screen-shot called

> screen2.jpg to illustrate what I'm saying. At least two of the terms

> ("pep:global FDR" and "prot:global FDR") seem miss located to me. Maybe

> they should work like "local FDR", with a unique term called "global

> FDR" child to both "peptide" and "proteine" / "identification

> confidence

> metric" (MS:1001198 and MS:1001092). Or maybe two terms could be used

> (the way is now), but children to MS:1001198 and MS:1001092 and

> changing

> the prefix "pep:" and "prot:" by the proper "peptide" and "protein".

>

> Two replies (Eric Deutsch and David Creasy, mails Sept 27th) seem to

> give support to the first point. Second point rejected. Third point

> extended in Eric Deutsch mail.

>

> Pending things 3 -> the "modification specificity N-term/C-term"

> related

> terms were NOT modified following the proposal in Martin Eisenacher

> mail

> (Sept 1st). In mail sent by David Ovelleiro (Sept 16th) changes related

> to modifications specificity were put to a stop until more consensus

> was

> reached. This should be clarified (pretty sure a final soultion for

> this

> is needed).

>

>

> =======================================================================

> ==========

>

>

> Thanks for your attention.

>

> --

> 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] Controlled vocabulary release candidate v. 3.12.0

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

Dear all,

Sorry about the really long mail.
I've divided the several things we had to do in two blocks: changes that 
I considered for the next release ("Changes and additions" section) and 
pending changes related to things not clarified ("Pending things").
Attached to this mail, there's a release candidate (new version number 
will be 3.12.0). Please check the changes and additions. I expect 
everything is OK. If you don't agree with the changes, please, email the 
list and we'll change whatever is needed. As soon everything is agreed, 
I'll publish the new version.

=====================================================
Changes and additions
=====================================================

- Two new terms proposed by Steve Robles (last mail Oct 10th, "Request 
for new terms"): MS:1001878 ("Offset Voltage") and MS:1001879 
("In-source collision-induced dissociation").
Eric Deutsch commented a possible overlapping between the first one 
(MS:1001878-> "Offset Voltage") and the next two terms MS:1000876 ("cone 
voltage") and MS:1000877 ("tube lens").
No mails following this point.
I should add that the last term's name ("tube lens"), maybe is better 
described as "tube lens voltage". (change not included in the temporal 
obo file).
The two new terms:

[Term]
id: MS:1001878
name: Offset Voltage
def: "The potential difference between two adjacent interface voltages 
affecting in-source collision induced dissociation." [PSI:MS]
is_a: MS:1000482 ! source attribute
relationship: has_units UO:0000218 ! volt

[Term]
id: MS:1001879
name: In-source collision-induced dissociation
def: "The dissociation of an ion as a result of collisional excitation 
during ion transfer from an atmospheric pressure ion source and the mass 
spectrometer vacuum." [PSI:MS]
is_a: MS:1000044 ! dissociation method

- Change in definition for MS:1000932 ("...MDS SCIEX TripleTOF 5500..." 
changed by "...MDS SCIEX TripleTOF 5600...") (last mail Oct 10th, 
"Request for new terms")

- A definition for the term MS:1000672 (name: Cliquid) (last mail Oct 
10th, "Request for new terms"). Is an Applied Biosystems software. 
Browsing I found that maybe the definition could be something like this:
def: "AB SCIEX or Applied Biosystems software for data analysis and 
quantitation." [PSI:MS]
I found the most complete descripcion of the software in this link:
http://www.mass-spec-capital.com/product/cliquid-software-applied-biosystems-abi-unit-life-technologies-2001-18662.html 


- New term added for the mz5 format (last mail Oct 10th, "Request for 
new terms")(last mail Oct 10th, "Request for new terms"):
[Term]
id: MS:1001880
name: mz5 file
def: "mz5 file format, modeled after mzML, developed by the Steen Lab." 
[PSI:MS]
is_a: MS:1000560 ! mass spectrometer file format

- Space removed in 1000139 name "4000 Q TRAP" à “4000 QTRAP”. (last mail 
Oct 10th, "Request for new terms")
Does this cause a problem with obsoleted term of same name (id: 
MS:1000870)? No problems reported.

- Adding 3 transition validation attributes (last mail Oct 10th, 
"Request for new terms"):
[Term]
id: MS:1001881
name: transition validation attribute
def: "Attributes of the quality of a transition that affect its 
selection as appropriate." [PSI:MS]
relationship: part_of MS:1000908 ! transition

[Term]
id: MS:1001882
name: coefficient of variation
def: "Variation of a set of signal measurements calculated as the 
standard deviation relative to the mean." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1001881 ! transition validation attribute

[Term]
id: MS:1001883
name: signal-to-noise ratio
def: "Unitless number providing the ratio of the total measured 
intensity of a signal relative to the estimated noise level for that 
signal." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1001881 ! transition validation attribute


- Adding 1 command-line parameter term as suggested by Magnus (last mail 
Oct 10th, "Request for new terms"):

[Term]
id: MS:1001884
name: command-line parameters
def: "Parameters string passed to a command-line interface software 
application." [PSI:MS]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1000630 ! data processing parameter


- Two terms (MS:1001843 and id: MS:1001844 -peak intensity and area- now 
sons of MS:1000042 ! peak intensity) proposed by Eric Deutsch about 
“peak area” and “peak height” (last email Oct 10th "PSI-MS CV: peak 
intensity area terms").
Related to this, the term MS:1001845 ("peak area" too) has been 
obsoleted because duplicated toMS:1001844.


=====================================================
Pending things
=====================================================

Pending things 1 -> Some comments in Eric Deutsch mail (Oct 10th) not 
yet implemented in the controlled vocabulary and to be discussed :
2) Is there really a difference between “peak area” and “XIC area”. I 
suspect not. If there really is an intended subtle difference (e.g. 
“peak area” takes into account background removal, which “XIC area” is 
irrespective of background) then we should define this.
3) It seems to me that all these term names are incomplete and 
potentially misleading. For example, the “peak area” term is not really 
for the concept of “peak area”; it is the concept of “quantifying signal 
by measuring peak area”. One can infer this by knowing the parent, but 
if our goal is to create term names that can stand on their own, I think 
these should be clarified. It will be tempting to users to use the “peak 
area” term to provide a measurement of a peak area.
4) For 1859, normalized to what?
5) For 1130, can peptides have an area? Mass specs don’t see peptides, 
they see peptide ions. And they see them as peaks. So it would see that 
“peptide raw area” is a badly named term that probably when decomposed 
means the same as “peak area”. Or, if I’m wrong, can we improve the 
definition?

Pending things 2 -> Some comments by David Ovelleiro (mail Sept 27th, 
"Possible need of changing some things under "identification result 
details" (MS:1001405)") not yet implemented in the controlled vocabulary:
- comment 1: there are two terms, MS:1001362 and MS:1001114, which in 
addition to be children to their respective parents (MS:1001116 and 
MS:1001105 resp), are also direct children to MS:1001405. The problem I 
see here is that the two parents, are also direct descendants of 
MS:1001405. Is this not redundant and unnecessary? My proposal is to 
remove the is_a (direct) relationship to MS:1001405.
Please, check the picture "screen1.jpg" for a more graphical description.
- comment 2: the term "Mascot query number" (MS:1001528) is direct child 
to "spectrum identification result details" (MS:1001405). Don't you 
think that this term would be better placed under "search engine 
specific score" (MS:1001153) (child to the previous MS:1001528)
- comment 3: the terms related to the "False Discovery Rate" are, in my 
opinion, some confusing at this point. I attach a screen-shot called 
screen2.jpg to illustrate what I'm saying. At least two of the terms 
("pep:global FDR" and "prot:global FDR") seem miss located to me. Maybe 
they should work like "local FDR", with a unique term called "global 
FDR" child to both "peptide" and "proteine" / "identification confidence 
metric" (MS:1001198 and MS:1001092). Or maybe two terms could be used 
(the way is now), but children to MS:1001198 and MS:1001092 and changing 
the prefix "pep:" and "prot:" by the proper "peptide" and "protein".

Two replies (Eric Deutsch and David Creasy, mails Sept 27th) seem to 
give support to the first point. Second point rejected. Third point 
extended in Eric Deutsch mail.

Pending things 3 -> the "modification specificity N-term/C-term" related 
terms were NOT modified following the proposal in Martin Eisenacher mail 
(Sept 1st). In mail sent by David Ovelleiro (Sept 16th) changes related 
to modifications specificity were put to a stop until more consensus was 
reached. This should be clarified (pretty sure a final soultion for this 
is needed).


=================================================================================


Thanks for your attention.

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

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

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



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ Finland: 080011569

+ UK: 08081095644

+ USA: NEW NUMBER: 1-866-832-8490

Generic international: +44 2083222500 (UK number)



access code: 297427 #





Agenda:

1) Meetings and workshops

- PSI Spring Workshop March 12-14 (+ProteomeXchange 15-16)

- Note nearby US HUPO March 4-7 and ABRF March 17-20

-



----

2) mzML 1.1.0

- imzML

- mz5 and mzDB

-



----

3) TraML development

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

- TraML was resubmitted to PSI document process

- Currently in community review period

- Discuss manuscript and new terms



----

4) MIAPE-MS revision

- Action items for MIAPE – MS



----

5) Improving the controlled vocabulary

- Discuss proposed terms cleanup email



----

6) SRM analysis guidelines and format

- Review MIAPE-Quant for SRM

- Review mzQuantML for SRM





Next meeting:

- Tue Oct 25 8am Seattle Time?

[Psidev-ms-dev] PSI-MS CV: peak intensity area terms

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

Hi everyone, in considering to add a peak height term, I reviewed the CV and
bit and wonder if we can tidy things up a bit. Here’s what I find:



[Term]

id: MS:1000042

name: peak intensity

def: "Intensity of ions as measured by the height or area of a peak in a
mass spectrum." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000455 ! ion selection attribute

relationship: has_units MS:1000131 ! number of counts

relationship: has_units MS:1000132 ! percent of base peak

relationship: has_units MS:1000814 ! counts per second

relationship: has_units MS:1000905 ! percent of base peak times 100

relationship: has_units UO:0000269 ! absorbance unit

relationship: part_of MS:1000231 ! peak



[Term]

id: MS:1000232

name: peak intensity

def: "OBSOLETE The height or area of a peak in a mass spectrum." [PSI:MS]

comment: This term was made obsolete because it was replaced by base peak
intensity (MS:1000505)

is_obsolete: true



This is fine. I suggest that we could use terms for both “peak area” and
“peak height”. Can we add these as children of “peak intensity” which seems
that it can mean either? What do you think?



Now in the “quantification datatype” region, there are a whole slew of terms
added (I assume) for mzQuantML. I have a couple comments:



1) 1844 and 1845 appear to be exact duplicates. Can we obsolete one, please?



2) Is there really a difference between “peak area” and “XIC area”. I
suspect not. If there really is an intended subtle difference (e.g. “peak
area” takes into account background removal, which “XIC area” is
irrespective of background) then we should define this.



3) It seems to me that all these term names are incomplete and potentially
misleading. For example, the “peak area” term is not really for the concept
of “peak area”; it is the concept of “quantifying signal by measuring peak
area”. One can infer this by knowing the parent, but if our goal is to
create term names that can stand on their own, I think these should be
clarified. It will be tempting to users to use the “peak area” term to
provide a measurement of a peak area.



4) For 1859, normalized to what?



5) For 1130, can peptides have an area? Mass specs don’t see peptides, they
see peptide ions. And they see them as peaks. So it would see that “peptide
raw area” is a badly named term that probably when decomposed means the same
as “peak area”. Or, if I’m wrong, can we improve the definition?



Thanks,

Eric







[Term]

id: MS:1001844

name: peak area

def: "Area of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype



[Term]

id: MS:1001845

name: peak area

def: "Area of MS1 peak (e.g. SILAC, 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype



[Term]

id: MS:1001846

name: isotopic pattern area

def: "Area of all peaks belonging to the isotopic pattern of light or heavy
peak (e.g. 15N)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype



[Term]

id: MS:1001858

name: XIC area

def: "Area of the extracted ion chromatogram (e.g. of a transition in SRM)."
[PSI:PI]

is_a: MS:1001805 ! quantification datatype



[Term]

id: MS:1001859

name: normalized XIC area

def: "Normalized area of the extracted ion chromatogram (e.g. of a
transition in SRM)." [PSI:PI]

is_a: MS:1001805 ! quantification datatype



[Term]

id: MS:1001130

name: peptide raw area

def: "Peptide raw area." [PSI:PI]

is_a: MS:1001805 ! quantification datatype



[Term]

id: MS:1001131

name: error on peptide area

def: "Error on peptide area." [PSI:PI]

is_a: MS:1001805 ! quantification datatype



[Term]

id: MS:1001841

name: LC-MS feature volume

def: "Real (intensity times area) volume of the LC-MS feature." [PSI:PI]

is_a: MS:1001805 ! quantification datatype

[Psidev-ms-dev] Proposed changes to PSI-MS CV

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

Hi everyone, below are some suggested changes to the PSI-MS CV. Please let
us know if there are any objections/suggestions for these changes. David,
would you process these changes?



Thanks,

Eric





1) Term MS:1000932 should be "5600" instead of "5500" in definition



2) Need a real definition for:

[Term]

id: MS:1000672

name: Cliquid

def: "AB SCIEX or Applied Biosystems software." [PSI:MS]

is_a: MS:1000690 ! AB SCIEX software



3) Add term for mz5:

[Term]

id: MS:100????

name: mz5 file

def: "mz5 file format, modeled after mzML, developed by the Steen Lab."
[PSI:MS]

is_a: MS:1000560 ! mass spectrometer file format



4) Remove space in 1000139 name "4000 Q TRAP" à “4000 QTRAP”. Does this
cause a problem with obsoleted term

of same name? Rename obsolete term to the "4000 Q TRAP" if necessary?



5) Add transition validation attributes:

[Term]

id: MS:100????

name: transition validation attribute

def: "Attributes of the quality of a transition that affect its selection as
appropriate." [PSI:MS]

relationship: part_of MS:1000908 ! transition



[Term]

id: MS:100????

name: coefficient of variation

def: "Variation of a set of signal measurements calculated as the standard
deviation relative to the mean." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:100???? ! transition validation attribute



[Term]

id: MS:100????

name: signal-to-noise ratio

def: "Unitless number providing the ratio of the total measured intensity of
a signal relative to the estimated noise level for that signal." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:100???? ! transition validation attribute



6) Add command-line parameters term as suggested by Magnus:

[Term]

id: MS:100????

name: command-line parameters

def: "Parameters string passed to a command-line interface software
application." [PSI:MS]

xref: value-type:xsd\:string "The allowed value-type for this CV term."

is_a: MS:1000630 ! data processing parameter



thanks,

Eric

[Psidev-ms-dev] Controlled vocabulary version released (3.11.0)

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

Dear,

Nem controlled vocabulary version released (3.11.0).
Addition of 9 terms, 1 term obsolete and 10 changed terms  related to 
mzIdentML (Tracker ID: 3414441). Change of 5 terms and 1 obsolete 
related to Applied Biosystems instruments (Tracker ID: 3414442). v.3.11.0

Changes detailed in Tracker ID: 3414441 and Tracker ID: 3414442 
(http://sourceforge.net/tracker/?group_id=65472&atid=848524).

Best,
David

-- 
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] [Psidev-pi-dev] contribute in the MIAPE Quant definition

[Jones, A. <And...@li...>]

Some quick comments on MIAPE Quant prior to today’s call. I think the main parts that need some work are:


-          Section 4.2 Feature selection / matching: there is rather a lot that could be covered in here, so we run the risk of getting very variable responses in here. As one example, in OpenMS there are different processes and parameters for feature detection/quant, alignment of different runs, over-laying of peptide identifications etc. A slightly alternative design here would be to specify a repeatable protocol bullet point in which the relevant parameters are reported?

o   There is the potential for overlap with section 4.4, feature detection and quantification are often performed in the same step, so while they could be separated out for the purposes of MIAPE, this may be counter-intuitive.

o   Also, does feature selection have a specific meaning, is this a synonym for feature detection? If so, I prefer the latter.

-          Section 5 – do we require peptide and protein values? If we assume “peptide value” to mean for a given peptide with a given charge state and given modification, then peptide abundance value is the same as the feature abundance value (in my opinion). I presume we do not want a list of quantified features that haven’t been matched to peptides though

Otherwise the module looks pretty good to me and not far off being ready for submission once there are some instance examples,
Cheers
Andy

From: Salvador Martínez de Bartolomé [mailto:sma...@pr...]
Sent: 19 September 2011 09:30
To: 'PSI PI Dev'; psi...@li...
Subject: [Psidev-pi-dev] contribute in the MIAPE Quant definition

Hi all:
                As you know, definition of MIAPE guidelines for quantification experiments (MIAPE Quant) is now in an advanced stage.
                However some non-trivial issues have still to be discussed and so, we need your collaboration and opinion.
                The planning is to have two weeks of discussion under the mailing list and then, to have a conference call on 29th September, at 4pm UK time (the usual mzIdentML / mzQuantML slot) to discuss over the received comments and to decide the last changes.
                You have almost two weeks to review the document and to contribute with some comments and opinions.
The main issue that is pending and that needs an agreement is the discussion about section 5, that is, which data levels are needed (protein, peptide, feature) and in which cases (in which quantification techniques). I hope you can contribute with this.
Below you can also see the last discussions from a small group of people. For sure that you can contribute also there.
                Attached, you will also find the last document.
                Best regards,

Salvador Martínez de Bartolomé Izquierdo
Bioinformatics Support - ProteoRed
Lab- B1, National Center for Biotechnology
C/ Darwin, 3 Universidad Autónoma de Madrid Cantoblanco,
28049 Madrid Spain
Phone: +34 91 585 4613
Fax: +34 91 585 4506

http://www.proteored.org
http://proteo.cnb.csic.es/trac
https://sites.google.com/site/bioinformaticaproteomica/


De: Jones, Andy [mailto:And...@li...]<mailto:[mailto:And...@li...]>
Enviado el: 03 August 2011 10:36
Para: Martin Eisenacher; 'Salvador Martínez de Bartolomé'; 'Alex Campos'; 'John Cottrell'
CC: jp...@pr...<mailto:jp...@pr...>
Asunto: RE: Last changes in MIAPE Quant

Hi all,

I had another review of the document and have made some minor changes and comments in the document. A couple of points:

1. I didn't see anywhere where feature matching (e.g. finding SILAC pairs or chromatogram alignment) is described?
Section “4.2 Parameters used in the quantitative process” seemed to me too general, and I think that feature matching could be there. So, I have renamed that section to “4.2 Feature selection and/or matching method” and I have added to the description the pair finding for SILAC and the chromatogram alignment.

2. The document states that Feature level quantitation reporting is optional, implying that peptide level quantitation is mandatory. To me, this needs further clarification, remembering that nothing in MIAPE is really optional.
It is true that this topic is not really clear. In the appendix, section 5.1, the description is the following, “Quantification values at peptide and, optionally, at feature level: Actual quantification values achieved for each peptide and, in case of feature-based quantification, for the corresponding features (mapped back to each peptide), together with their estimated confidence.“, which wants to mean that if you have performed a feature-based quantification, you must report the corresponding features, as it is said, mapped back to each peptide. Maybe that explanation is not enough. So, do we should state the level of reporting that is needed for each quantitation technique?

We worked a lot on modelling the relationship between Feature and Peptide in mzQuantML. For a given peptide, there could be multiple different features even within one assay (different modifications, different charge states) and thus multiple different matched features across different assays. Different workflows model this differently, but we currently model that a Peptide element can reference 1: many matched features, which references 1:many features.

For the MIAPE Quant document, we perhaps don't need this level of detail but the language of what must be reported must be really clear. The following need to be resolved:

- Is it okay to merge results from different peptide charge states, modifications, or do we want "unique" peptides reported in this case?
In my opinion, it depends on the researcher, I mean, some people will want to report „unique“ peptides and some others will not care about modifications and charge states and will not want to report as „unique“. Anyway, the researcher should report if he has considered only unique peptides or not to quantify them, and therefore, we should add that requierement to the MIAPE. What do you think?

- If we expect unique peptides to be reported, then I don't see there is much difference between peptide level quantitation and feature level quantitation, unless it is okay to only report feature ratios in the case of SILAC pairs. In the document, the sentence " In the case of feature-based quantification, provide the same information for the corresponding features that are mapped back from the peptides." doesn't make sense to me, since these should be the same.
I’m not sure if I have understood properly the question. Do you mean that we should add some text to clarify that feature level reporting is only needed just in the case in which „a peptide“ is not the same as „a feature“? If so, any suggestion?

- Clarification of whether intensity values should be reported in a SILAC or if ratios are okay.
In my opinion, even in case of SILAC or for example, in iTRAQ, the MIAPE only should require the ratios. I doesn’t see any use case in which the intensities are needed in a reported experiment. Maybe the mzQuantML could include them, but I don’t think that intensities should be required in the MIAPE.

- I think there is nothing in here about quantitation of protein groups, rather than proteins where there is ambiguity.
I agree. I have added the following red text in section 5.2:
5.2 Quantification values at protein level:  Actual quantification values achieved for each protein and for each protein ambiguity group, together with the confidence in the quantification value.


Finally, I think we need to add a note at the start of section 5, saying in what cases it is okay to omit peptide level quantitation (e.g.  in spectral counting approaches?) or protein level quantitation (e.g. in phosphopeptidome), in all other cases, both are needed
Maybe I’m wrong but, in spectral counting, the number of MS/MS spectra are counted, isn’t it? Is there any other type of spectral counting that only takes into account the MS spectra? (in that case, the peptide level could be omitted).
In case of approaches like phosphopeptidome, I agree that the protein level could be omitted.

Re: [Psidev-ms-dev] MIAPE call this week

[Jones, A. <And...@li...>]

Reminder call later today:

Agenda:

-          MIAPE Quant
-          MIAPE MSI
-          CV / validation issues – what is needed for ProteomExchange?
-          AOB – let me know
Cheers
Andy

Dial in details:
+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ Generic international: +44 2083222500 (UK number)
Note, new US number: 877-420-0272

access code: 297427




From: Jones, Andy [mailto:And...@li...]
Sent: 26 September 2011 13:05
To: 'psi...@li...'; 'psi...@li...'
Subject: [Psidev-ms-dev] MIAPE call this week

Hi all,

Quick reminder – we have a call this week on Thurs at 4pm UK time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20110929T16&p1=136 to discuss MIAPE modules Quant, MSI etc

Agenda:


-          MIAPE Quant

-          MIAPE MSI

-          CV / validation issues – what is needed for ProteomExchange?

-          AOB – let me know

I realise this is quite a lot to get through, so can everyone look at documents before the call so you’re up to speed. Salvador sent round the latest MIAPE Quant draft recently. I think the most recent MIAPE MSI is here: http://www.psidev.info/miape/MIAPE_MSI_1.1.pdf, prior to the removal of the quant parts. A small working group is going to look at this, but if you want to give any opinions, we can have a quick discussion about it in the call.

I’m not sure if there is anything about MIAPE MS to discuss in this forum, let me know if so,
Best wishes
Andy

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

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

Notes from today’s teleconference.



Present: Matt, Jim, Richard, Eric, Pierre-Alain, Alexey,



Agenda:

1) Meetings and workshops

- PSI Spring Workshop San Diego March 12-14 (+ProteomeXchange 15-16)

- Note nearby US HUPO March 4-7 and ABRF March 17-20

-



----

2) mzML 1.1.0

- mzML for metabolics

+ We need some CV terms for GC-GC coupling:

  + “modulation time” ?

  + There was a discussion a few months ago. Try to revive this.

- mz5 and mzDB

+ mz5 is exact schema for mzML but with HDF5

+ Matt is using it and performance is good

+ Developed by Steen Lab and contributed to ProteoWizard

+ mzDB uses SQLite as back end and uses mzML snippets for metadata

- digital signatures

-



----

3) TraML development

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

- TraML was resubmitted to PSI document process

- Currently in community review period

+ Clarify with Christian when this is officially over

- Discuss response to 5th reviewer

+ Clarify the scope of TraML at the beginning of the response as the list of
transitions between vendor software, repositories,

+ Amplify the response to “no one wants to parse .sky files”

+ Clarify that “neutral loss scans” and “precursor ion scans” are not
supported in section 1.3.5



- Discuss Alexey’s use case and needed terms

+ Signal to noise probably better than intensity even

+ Alexey’s proposal seems quite reasonable to try

+ Eric will send an email with the terms proposed



+ Steffen has an R package for writing inclusion lists

+ Steffen will find a hyperlink to it and we will post on the TraML dev page



----

4) MIAPE-MS revision

- Special call on Thursday for MIAPE - *



----

5) Improving the controlled vocabulary

- Proposed “command line parameters” CV term and implications

+ This sounds quite sensible to us. Follow up with an email to list

+ Would this include the executable/path or just everything after that.
Probably after.

+ Matt points out that pretty much all options are encoded in the file. But
gathering them is difficult to recreate the step

+ Everyone agreed that it was useful to add

- CV term requests from Sean



----

6) SRM analysis guidelines and format

- Review MIAPE-Quant for SRM

- Review mzQuantML for SRM

+ We need to create a sample mzQuantML document for an SRM experiment. Who
will try?

+ Steffen may try



Next meeting:

- Tue Oct 11 8am PDT?

+ Yes

[Psidev-ms-dev] psi-ms controlled vocabulary: Changes to be made related to mzIdentML if everybody is happy (with the changes)

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

Dear community,

I've done all the changes summarized in the last email about this (sept 
16th). I attach the resultant "obo" (compressed as psi-ms.zip), to give 
the community the opportunity to check things. Please, any feedback will 
be really appreciated. If everybody is fine with this, I'll submit it on 
Thursday.

Summary of changes proposed in the previous mail (see attachment 
"changes.zip"):
- Addition of 9 terms, MS:1001868 to MS:1001876 (q/p/E values to protein 
and peptides -6 first terms-, FDRScore, modification motif and 
modification probability)
- 1 term obsolete (MS:1001191, p-value)
- changed terms: 10 direct changes and 11 "is_a" related changes (5 
terms where "is_a: MS:1001092 ! peptide identification confidence 
metric" and 6 terms where "is_a: MS:1001198 ! protein identification 
confidence metric").

In addition to the changes proposed in the last email, I've taken into 
account in the psi-ms update all the proposal made by Sean Seymour in 
his last email (Sept 24th). Because all the changes are quite 
straightforward and related to Applied Biosystems hardware, and he's 
working in that company, I found no need to postpone more the update of 
the controlled vocabulary. Please, as these changes are included in the 
attached obo file (not in the "changes" log, only related to my last 
email), feel free to check if everything is correct.
Summary of the changes made after proposal by Sean Seymour:
- MS:10006452 -> "-" changed by "/", and "Analyzer" removed
- "AB SCIEX2 removed from MS:1000931, MS:1000932 and MS:1001482 definitions
- MS:1000870 is now obsolete (because was redundant to MS:1000139)
- the "?" has been removed from MS:1000672

Please, comment at discretion.

David

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