15N metabolic labeling -- mods output

[Farshad Abdollah-Nia]

Hello all,

I am using comet to search for 15N-labled peptides where all the residues are labeled with 15N. The search works fine with appropriate mass shifts specified as static modifications in the params file. However, this approach results in a long list modifications for each peptide to be reported in the output (1 for each residue). This makes it difficult to look for genuine modifications of interest (whether variable or static) or combine the results with those of natural amino acids.

Is there a way to re-define residue masses without declaring them as modifications? For example, X! Tandem has the option to do this in a modified residue mass file. Could something similar be achieved with comet?

Thank you,

Farshad

[Jimmy Eng]

You can define the mass of each residue using the static mods aka "add_G_glycine" thru "add_W_tryptophan".  See this page covering that topic; I think this is what you're looking for.  But if it doesn't address your question, please reply with a bit for info.

[Farshad AbdollahNia]

Thank you for your quick response, Jimmy. As I described, this approach returns correct search hits, but the output will contain a modification for each and every residue. 15N labeling is not technically a PTM (it is supplied in the growth medium), so reporting it as mods on all residues by comet is quite problematic, especially when merging with unlabeled search results.

I hope this clarifies the problem. 

Also thanks for the link to the page you have on this topic. About that, and unrelated to the problem at hand, I noticed that it says:

If you need to account for carboxyamidomethylation, adjust the cysteine mass accordingly (57.021464 + 0.997035 + 0.997035 = 59.015534) as there is a nitrogen in cysteine and a nitrogen in the iodoacetamide derivative.

I think the additional +0.997035 for the iodoacetamide derivative should not usually be added because 15N is often supplied in the growth medium whereas natural IAA is used for post-processing. The other masses seem correct. But again, it would help here to have a separate file to define the unmodified residue masses and use only 57.021464 for cysteine (and 0's for others) for consistency with unlabeled experiments and results. I hope this makes sense.

Thanks again for your help.

Farshad

--
You received this message because you are subscribed to a topic in the Google Groups "Comet ms/ms db search support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/comet-ms/gl-VToCR3TU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to comet-ms+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/comet-ms/6acc4a41-173f-42ac-86af-77c6fa6569f4n%40googlegroups.com.

[Jimmy Eng]

As I re-read your original post, I see you were already able to do the searches which means my previous reply was pretty useless!  How are you looking for modifications (that aren't 15N) in the results?  Using the PepXML Viewer?  If so, it almost seems like it makes more sense for that tool to be updated with some flag to not annotate static mods in the peptide string.  Otherwise anything I do with Comet will likely not properly work with one or two downstream tools.

One quick option, at least for testing, is that I can supply you with a custom version of Comet where the amino acid masses are defined with 15N.  This would be pretty easy to do.  But things like the Lorikeet spectral viewer in the TPP wouldn't correctly be able to display the spectra for these identifications because it wouldn't know about the default 15N amino acid masses.  I'm not sure what other tools might be affected ... presumably something like PTMProphet would.

Thoughts?

[Farshad AbdollahNia]

Thank you for considering this problem. About your question:

How are you looking for modifications (that aren't 15N) in the results?  Using the PepXML Viewer?

I am directly using the .pep.xml output from comet, as well as the .pep.xml outputs from PeptideProphet and iProphet, to parse and combine the results from labeled and unlabeled experiments into consensus libraries with aligned retention times. But PepXML Viewer also shows all residues as modified. If you pass a flag to not annotate static mods then I would not be able to see the cysteine and other potential true static mods (if searched for) in the results. So, this would not be a good solution.

I understand that the TPP tools need to be further developed to handle metabolic labeling for the general use cases, whether 15N, 13C, or SILAC where PTMs occur after isotope labeling. I believe X! Tandem has a good way to handle this (although I prefer Comet for better search algorithm and continued support). In X!Tandem's XML output, it has a section for the unmodified residue masses if provided by the user. All downstream processing tools (beginning with Tandem2XML) can look up the masses in that section and define the unmodified residue masses accordingly. Would this be a sensible thing to do?

Thanks,

Farshad

To view this discussion on the web visit https://groups.google.com/d/msgid/comet-ms/effa1736-5092-4a0d-a578-8cbe4fee0bcen%40googlegroups.com.

[Jimmy Eng]

I could extend Comet to do this, pretty easily.  If I end up doing this, how would you like this information get encoded in Comet's pepXML output?  Presumably if downstream tools will need to be updated, this means getting the TPP devs on board to extend the pepXML schema (and eventually update any affected tools).

And this also means it would only be pertinent to pepXML output as there's no way to encapsulate this information in a Percolator pin file or SQT output that folks use.

[Farshad AbdollahNia]

Thank you, Jimmy. I believe the current PepXML <search summary> entry has the structure for outputting the unmodified mass information (see screenshot below). So hopefully the schema won't need to be updated. But please let me know if I am wrong.

I think it would be fine to stick with pepXML output for now, and updating the other affected tools would be ideal. If you would like to make a binary (on linux) for testing I would be more than happy to give it a try with PeptideProphet/xinteract, iProphet, ProteinProphet, PTMProphet, and StPeter. This would also help our current in-house workflow development which we plan to publish for community use. It would certainly help to know which direction to take for compatibility with TPP down the road.

Thanks so much, again!

Farshad

On Thu, Feb 22, 2024 at 6:37 PM Farshad AbdollahNia <m.f.abd...@gmail.com> wrote:

Thank you, Jimmy. I believe the current PepXML <search summary> entry has the structure for outputting the unmodified mass information (see screenshot below). So hopefully the schema won't need to be updated. But please let me know if I am wrong.

I think it would be fine to stick with pepXML output for now, and updating the other affected tools would be ideal. If you would like to make a binary (on linux) for testing I would be more than happy to give it a try with PeptideProphet/xinteract, iProphet, ProteinProphet, PTMProphet, and StPeter. This would also help our current in-house workflow development which we plan to publish for community use. It would certainly help to know which direction to take for compatibility with TPP down the road.

Thanks so much, again!

Farshad

To view this discussion on the web visit https://groups.google.com/d/msgid/comet-ms/34138ae7-d6ac-4b5f-93a0-6df6fc0d621fn%40googlegroups.com.

[Jimmy Eng]

OK, I'll throw something together for you, hopefully by Monday.  I still questions but those can be addressed as they come up.

[Farshad AbdollahNia]

Thank you so much, Jimmy. On some more thought, my suggestion to present the unmodified masses within <aminoacid_modification> entries might have been too hasty. But they could still be new search parameters within the <search_summary> section. If you are thinking of a standard that all search engines could follow (ideal), then yes, the schema would need to be updated.

Please take your time with this, and definitely let me know the questions or ideas that come up.

Thanks again,

Farshad

To view this discussion on the web visit https://groups.google.com/d/msgid/comet-ms/e3620a66-8afd-4fda-89fe-e53369c181a7n%40googlegroups.com.

[Jimmy Eng]

As you likely have seen already, I sent you an email with an initial implementation of this.  We can correspond off line via email for any future details/issues.