ProForma

[douweschulte]

Problem

As requested in #10. Here is the separate thread to discuss ProForma related things. ProForma is a very extensive spec, and we could support this in many different ways. Two obvious ways of supporting this are: reading and writing ProForma. My own reasoning to support ProForma was to have the most fully fledged spec as baseline for what my code should be able to support. So if we want to have a library that is able to handle pretty much all complexity in proteomic mass spectrometry data we should look into ProForma for what features that should entail. If we do not want to allow for the full complexity, we could look into supporting ProForma at a lesser level of support (see below), but some kind of hard things to support are already in the lowest levels so that could also be somewhat hard to pull off.

ProForma levels of support

These are my personal notes of the levels, with inline the section in the spec discussing the feature

1. Base Level Support (Technical name: Base-ProForma Compliant)
   Represents the lowest level of compliance, this level involves providing support for:

• 4.1 Amino acid sequences
• 4.2.1/4.2.2 Protein modifications using two of the supported CVs/ontologies: Unimod and PSI-MOD.
  • Prepare Unimod and parse modifications
  • Prepare PSI-MOD and parse modifications
• 4.2.6 Protein modifications using delta masses (without prefixes)
• 4.3 N-terminal, C-terminal and labile modifications.
• 4.4 Ambiguity in the modification position, including support for localisation scores.
  • Global: [Phospho]^2?
  • Local/named: [Phospho#g1(0.01)]
  • Stretch: (AAA)[Phospho] (note: also handle multiple modifications on a group + scores)
• 4.7 Ambiguity in the amino acid sequence. (?DQ)N
• 4.8 INFO tag.

2. Additional Separate Support (Technical name: level 2-ProForma compliant)
   These features are independent from each other:

• 4.1 Unusual amino acids (O and U).
• 4.1 Ambiguous amino acids (e.g. X, B, Z). This would include support for sequence tags of known mass (using the character X).
• 4.2.6 Protein modifications using delta masses (using prefixes for the different CVs/ontologies).
• 4.2.1 Use of prefixes for Unimod (U:) and PSI-MOD (M:) names.
• 4.9 Support for the joint representation of experimental data and its interpretation. (see 4.9)

3. Top-Down Extensions (Technical name: level 2-ProForma + top-down compliant)

• 4.2.1 Additional CV/ontologies for protein modifications: RESID (the prefix R MUST be used for RESID CV/ontology term names)
• 4.2.8 Chemical formulas (this feature occurs in two places in this list).

4. Cross-Linking Extensions (Technical name: level 2-ProForma + cross-linking compliant)

• 4.2.1/4.2.3 Cross-linked peptides (using the XL-MOD CV/ontology, the prefix X MUST be used for XL-MOD CV/ontology term names).

5. Glycan Extensions (Technical name: level 2-ProForma + glycans compliant)

• 4.2.5 Additional CV/ontologies for protein modifications: GNO (the prefix G MUST be used for GNO CV/ontology term names)
• 4.2.9 Glycan composition.
• 4.2.8 Chemical formulas (this feature occurs in two places in this list).

6. Spectral Support (Technical name: level 2-ProForma + mass spectrum compliant)

• 7 Charge and chimeric spectra are special cases (see Appendix II).
  • Parse chimeric spectra
  • Annotate chimeric spectra
  • Parse charge state/adduct ions
  • Handle/annotate charge state/adduct ions
• 4.6 Global modifications (e.g., every C is C13).
  • 4.6.1 Isotope modifications <15N> (applied as a post filter after generating the MolecularFormula for generated fragments and full peptide, not applied on single aminoacids)
  • 4.6.2 Fixed modifications <[Formula:H-1]@A>

Some things to discuss

• Traits
  • Do we want to support the full complexity of the peptides that you can encode in ProForma in our traits, I lean to doing this, as I am using quite some of the complex ProForma stuff on a nearly daily basis
• Reading
  • Do we want to support reading at all
  • Only a simple version, leave all the complex stuff up to users of the lib to do on their own
  • A full support version, supporting the whole breadth of the spec
  • Or a full support validating parser (same as above for the user, but also fully validates the input to the spec)
• Writing (somewhat easier to pull off properly)
  • Do we want to support this at all
  • Do we provide output capabilities for our standard implementations
  • Do we (if we end up creating a reader) normalise the sequences in any way, do we need to discuss details of this, or does it just automatically happen when reading+writing

My view

• Traits: I would love rusteomics to provide the full complexity at the trait level, otherwise anyone having a somewhat harder dataset has to write a new library from scratch. I am already using quite a lot of the complex features needed at the trait level, and I try to keep those in mind when discussing the traits in other places for rusteomics.
• Reading: I have a nearly done (only missing RESID, cross linking, and branched peptides) full implementation for ProForma and I would be happy to move that over into the shared project (this needs a bit of rework though, and is not set up to be a validating parser)
• Writing: I think it makes sense to provide a writer, writing is quite easy in comparison with reading
• Reading+Writing: both are of course something we can only provide on the struct level, so we can provide functions that do the conversion to and from the provided data structures

[david-bouyssie]

I would go for full support but I would try to set it up as an optional system (optional feature), if doesn't make things too complicated of course.

[douweschulte]

I do not really know what you envision for an optional feature. If we want to be able to support all complexity in the standard all our traits have to be exhaustive for these cases so that has to be backed in in all the code. Then the only real code that we could make optional is the parser (and maybe export), which will be a kind of small extension (for any end user only a single method). Unless the parsing needs a lot of dependencies I do not really see the point in only removing a single method with an additional feature.