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.