Protein quant values

[ypriverol]

Standardization of Protein Quantification Across quantms.io Workflows

In quantms.io, we aim to establish a unified standard for representing protein quantification across all supported workflows: TMT-quantms, LFQ-quantms, DIANN, and MaxQuant (MQ). The main protein intensity (protein_total_intensity) will represent the total intensity as reported by each workflow, while complementary metrics will provide harmonized and comparable quantification values across methods.

Proposed Combinations and Computations

1. quantms + LFQ

• Default total quantification:

  • total_sum_unique_peptides (as provided in the mzTab output).

• Additional computed metrics:

  • total_intensity_all_peptides: Total intensity including all peptides mapping to the protein group (including shared and modified peptidoforms).
  • top3_intensity: Intensity from the top 3 most intense peptides per protein group and RAW file (considering all peptidoforms).

2. quantms + TMT

• Default total quantification:

  • top3_intensity (TMT reporter ion intensities from the three most intense peptides).

• Additional computed metrics:

  • total_unique_peptides_intensity: Total intensity from unique peptides only.
  • total_all_peptides_intensity: Total intensity including all peptides and peptidoforms per protein group and RAW file.

3. MaxQuant (MQ) and DIANN

• Use native workflow outputs:

  • MQ: LFQ intensity, iBAQ, RAW intensity (as provided).
  • DIANN: PG.MaxLFQ, PG.Quantity, or equivalent fields.

• Optional harmonized metrics (if raw intensities available):

  • Compute total_all_peptides_intensity and top3_intensity analogous to quantms workflows for cross-workflow comparability.

Summary of Target Quant Fields

Workflow	Main Quant Field	Complementary Metrics
quantms + LFQ	total_sum_unique_peptides	total_all_peptides_intensity, top3_intensity
quantms + TMT	top3_intensity	total_unique_peptides_intensity, total_all_peptides_intensity
MQ	LFQ intensity / iBAQ / RAW intensity	total_all_peptides_intensity, top3_intensity (optional)
DIANN	PG.MaxLFQ / PG.Quantity	total_all_peptides_intensity, top3_intensity (optional)

Rationale

This approach ensures:

• Consistent quantification fields across workflows.
• Compatibility with mzTab outputs and protein group (pg) tables.
• Flexibility to compare absolute and relative protein intensities.
• A clear mapping between workflow-specific and quantms-standardized quant values.

[enryH]

For quantms + LFQ I still aim to at least add DirectLFQ - bigbio/quantms#592

[jpfeuffer]

Makes sense overall.

Can we get a more detailed description on what the columns of MaxQuant and DIANN mean (maybe they are the same or similar to the basic ones? I.e. links to the algorithms or some kind of grouping into types of algorithms? How are we storing the settings again? Because the "main" quants probably heavily depend on the settings (potentially if the users chooses a number for the number of peptides per protein to be considered).

And I also think we should offer something more elaborate for OpenMS based workflows.

One general question when looking at this: Do we really need a main quant? What speaks against having the name or type of quant as the column name?

What is the difference between:

• total_sum_unique_peptides
• total_unique_peptides_intensity
  Mistake?

[Shen-YuFei]

MaxQuant already has intensities (RAW intensity) and additional_intensities (LFQ intensity, iBAQ), so we don't need major changes.
I recommend clarifying quantification values in documentation, and then consider calculating two harmonized metrics (total_all_peptides_intensity and top3_intensity) from evidence.txt to add in additional_intensities, to see if we can compare results with quantms and DIANN.

[Shen-YuFei]

Makes sense overall.  

Can we get a more detailed description on what the columns of MaxQuant and DIANN mean (maybe they are the same or similar to the basic ones? I.e. links to the algorithms or some kind of grouping into types of algorithms? How are we storing the settings again? Because the "main" quants probably heavily depend on the settings (potentially if the users chooses a number for the number of peptides per protein to be considered).

And I also think we should offer something more elaborate for OpenMS based workflows.

One general question when looking at this: Do we really need a main quant? What speaks against having the name or type of quant as the column name?

What is the difference between:

• total_sum_unique_peptides
• total_unique_peptides_intensity
  Mistake?  

For MaxQuant, the three quantification columns use different algorithms: RAW Intensity directly sums MS1 peaks without normalization, LFQ Intensity applies the MaxLFQ algorithm with median normalization across samples, and iBAQ divides protein intensity by theoretical peptide count for absolute abundance.
Currently, quantms.io doesn't store MaxQuant's run settings, which is problematic since these parameters affect the quantification results. We might be able to store MaxQuant parameters in the parquet file like:

{
  "maxquant_lfq_min_ratio_count": 2,
  "maxquant_match_between_runs": true
}

or create a separate parameters JSON file alongside the output.

[ypriverol]

This is a really good point @Shen-YuFei, I always thought that would be good to have a table like:

model view | column name | ontology accession | full name | settings
psm | charge | MS:XXXX | charge | computed as provided by the mzml

This could help to store all the information of the format columns, from were they were computed, and how. mzPeak is trying to do something similar @mobiusklein what is your suggestion here?