Hi all, As mentioned on the Comet mailing list, it would be very nice to have an identifier for the modification in the results. This would allow us to track back whether the modification was searched fixed or variable, terminal, etc. Currently we have to "guess" the modification from the mass and this can be source of errors when many modifications are searched simultaneously.
Also, while working on this, would be great if you could add a charge to the identified peptide in case it is different from the spectrum :) Best regards, Marc On Thursday, August 11, 2016 at 9:55:46 PM UTC+2, Jimmy Eng wrote: > > To address Harald's point, we should simple add something like "static" > and "variable" attributes to the "mod_aminoacid_mass" elements as below. I > think it makes a lot of sense to do something like this especially if we're > going to be adding other (optional?) attributes such as "source". > > <mod_aminoacid_mass position="6" mass="181.014010" variable="79.966331" > source="peff"/> > <mod_aminoacid_mass position="10" mass="166.109380" static="57.021494" > /> > <mod_aminoacid_mass position="14" mass="176.109380" static="57.021494" > variable="10.00000" source="param" /> > > The only issue I see with something like this that n-terminal and > c-terminal static and variable modifications are handled differently and > there's no good way to denote the static and variable modifications on > them. Back in January on the spctools-dev group, I brought up this issue > with respect to terminal mods. They're really no different than amino acid > modifications but there just needs to be a way to denote the terminal > positions. There was objection to change where the proposed change was > removing the "mod_nterm_mass" attribute from the "modification_info" > element and encoding the terminal mods the way we do amino acid mods: > > <mod_aminoacid_mass position="n" mass="230.170757" static="229.162932" > /> > > Is there an adequate, backwards compatible work-around where terminal > static and variable modifications can be encapsulated? To keep things as > backwards compatible as possible, we can leave the existing > "mod_nterm_mass" and "mod_cterm_mass" where they are and simply allow > terminal mods to be represented as above? If a non-integer "position" > value is an issue then use "0" to represent the n-term and whatever the > integer value of peptidelength+1 to represent the c-term? > > > On Thu, Aug 11, 2016 at 12:16 PM, Harald Barsnes <[email protected] > <javascript:>> wrote: > >> >> Hi Eric, >> >> We use these elements to detect which modifications that are fixed and >> which that are variable. I don't see how we could extract this information >> without the aminoacid_modification elements? As this information is not >> part of the mod_aminoacid_mass elements? Or is there something I'm missing? >> >> Best regards, >> Harald >> >> >> >> >> On Wednesday, August 10, 2016 at 9:44:09 PM UTC+2, Eric Deutsch wrote: >> >>> Hi everyone, I have a question about use of some pepXML tags. It’s a bit >>> technical and mostly for other developers who use the pepXML format. >>> >>> >>> >>> The issue involves the amino_acid tags at the top of a pepXML file under >>> search_summary, like this: >>> >>> <search_summary"> >>> >>> <aminoacid_modification aminoacid="M" massdiff="15.994915" >>> mass="147.035400" variable="Y" symbol="*"/> >>> >>> <aminoacid_modification aminoacid="S" massdiff="79.966331" >>> mass="166.998359" variable="Y" symbol="#"/> >>> >>> >>> >>> Comet and some other search engines write out these entries for the >>> specified search mass mod parameters. >>> >>> >>> >>> But SpectraST at least does not put these there, in part because it >>> doesn’t really know what mods will appear in later in the file, because it >>> depends on the library. And we now have another case where it is awkward to >>> put them at the top of the file because they’re not an input parameter, but >>> a result of the reference. >>> >>> >>> >>> So the question to all is: does anyone use these data elements at the >>> top for something important? Would it cause any troubles if for some search >>> results they are not there or are incomplete? As currently for SpectraST? >>> >>> >>> >>> What do you think? >>> >>> >>> >>> Thanks, >>> >>> Eric >>> >>> >>> >>> >>> >>> >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "spctools-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/spctools-discuss. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/spctools-discuss. For more options, visit https://groups.google.com/d/optout.
