I agree with "static" and "variable" attributes to the "mod_aminoacid_mass" suggestion. Can we add an optional "term" attribute to denote N/C term-
<aminoacid_modification aminoacid="M" term="N-term" massdiff="15.994915" mass="147.035400" variable="Y" symbol="*"/> Regards Amit Kumar Yadav, PhD Scientist C, Drug Discovery Research Center (DDRC), Translational Health Science and Technology Institute (THSTI), India *Google Scholar* <http://scholar.google.co.in/citations?user=OtAgRoIAAAAJ&hl=en>* || **MassWiz <https://sourceforge.net/projects/masswiz>* <http://www2.technologyreview.com/tr35/profile.aspx?TRID=1364> On Fri, Aug 12, 2016 at 1:25 AM, Jimmy Eng <[email protected]> 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] > > 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]. >> 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. >> > > -- > 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. > -- 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.
