Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add initiator methionine? #29

Open
edeutsch opened this issue Oct 31, 2018 · 6 comments
Open

add initiator methionine? #29

edeutsch opened this issue Oct 31, 2018 · 6 comments

Comments

@edeutsch
Copy link
Contributor

We do not currently have a term for initiator methionine. Is this an oversight or intentional?

Do we want to add this term and be specific about initiator methionines in the PEFF? I would guess yes, but what do you think?

Example in neXtProt:
https://www.nextprot.org/entry/P60484/sequence

@MSCypher
Copy link

MSCypher commented Oct 31, 2018 via email

@pabinz
Copy link
Collaborator

pabinz commented Dec 12, 2018

There is a PSI-MOD term for this: MOD:01643
Therefore: \ModResPsi=(1|MOD:01643|L-methionine removal)

Or \ModResUnimod=(1|UNIMOD:765|Met-loss)

Also valid: \VariantComplex=(1|1|) but might not be as ideal: VariantComplex might be neglected by search engine whereas ModResPsi is easier to handle (like phospho, oxydation or other PTMs)

I would not add a specific term (exception for this)

@edeutsch
Copy link
Contributor Author

Lydie wrote in an email on the topic:

I think that having initiator methionine would be redundant with having "Mature protein" starting at position 2 .

There do seem to be several ways to do it, but we should pick one and recommend it in the spec.

I would vote against the \VariantComplex solution because it may not be implemented until late by many programs. And variant in my mind generally implies a genetic difference from the reference, although this is not strict.

The \ModResXxxx way seems a bit weird because then there would start the precedent of displaying and listing peptides with sequences longer than what's there with some masses set to 0. i.e. if a search engine got a match for this, it would be tempted to display it with something like M[Met-loss]ELVIS, and sequence mapping software would map it with the M, but then it would presumably not map to another protein with .....KELVISR..... or .....PELVIS...... because there's no M. I don't think that's a good solution.

Dealing with it in \Processed seems like the right way to handle it. As Lydie said, it is already implicit with a \Processed=(2|542|PEFF:0001020|mature protein). For a search engine that wants to treat mature protein boundaries as fully tryptic, this is all it really needs to know. Also having (1|1|PEFF:000nnnn|initiator methionine) would be very explicit in the annotations, and would avoid annotater software needing to infer this information, but perhaps not necessary for the searching task. But, of course, by that argument, why bother having 'signal peptide' and 'propeptide' if search engines are just going to make inferences from 'mature protein'?

@MSCypher
Copy link

MSCypher commented Dec 13, 2018 via email

@edeutsch
Copy link
Contributor Author

Realistically if you imagine writing search engine code, I suspect all the code needs to look at are the "mature protein" boundaries. Everything else could be ignored? Maybe not. in my experience, you never see "signal peptide" sequence, but you do sometimes see "propeptide" sequence. In the end you can search it all parts of the protein and just treat the boundaries as hard boundaries.

I agree that including a term for init met makes it easier to annotate a sequence without making a hard-coded assumption (if (mature_protein.start == 2) then position_1 = init_met)

Maybe we can voice a few more opinions and then have a vote...

@pabinz
Copy link
Collaborator

pabinz commented Dec 14, 2018

With all the comments above, I would also support a \Processed=(1|1|PEFF:nnn|initiator methionine) term.
It is clean, biologically relevant and does not create an exception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants