Menu
▾
▴
Re: [Psidev-pi-dev] Fragment Ions in analysisXML - how it is currently handled in PRIDE (Issue 28)
|
From: David C. <dc...@ma...> - 2008-07-21 14:55:00
|
What about internal fragments, immonium ions, side chain cleavages? Or would we just ignore these... David Matthew Chambers wrote: > By standard grammar are you referring to the little format I came up with? > > <a|b|c|x|y|z><# between 1 and peptide_length>[<+|-><formula>][,(<+|-><charge>] > > It seems pretty easy to verify to me - easier than some of the other > features in mzML and analysisXML. :) The hardest part is the <formula> > and verifying that the ion series # is between 1 and peptide_length. > Those may have to be semantic rather than syntactic verification steps. > Making the charge part mandatory would simplify the format. I think the > auxiliary file would rarely be written and/or copied along with the > original file, so it wouldn't do much good. If it's a concern, the > <formula> part could wait until a later version. > > -Matt > > > Jones, Andy wrote: >> Hi Matt, >> >>> As for mapping to the observed ion(s), I think it's not relevant for the >>> purposes of basic annotation. For clarity of presentation, viewers >>> usually show the ion as either a logical point in the spectrum >>> independent of the data itself, or they map it to the most abundant peak >>> in the window. These approaches can be combined by changing the >>> annotation when the user zooms in. >>> >> Agreed, I can see the use case for viewers. Are there any others...? >> >> The problem I have at the moment is that we're a long way from having this standard grammar specified in a formal way which could be verified. One option to consider is defining an auxiliary (non-XML) file which could be transferred in parallel - this way we can keep it outside the formal analysisXML standard, in which we try out something similar to your proposal and see if we can get the main search engines to output something consistent. If successful, roll it into analysisXML v2...? >> >> Andy >> >> >> >> >> >> >> >> >> >>> -----Original Message----- >>> From: Matt Chambers [mailto:mat...@va...] >>> Sent: 21 July 2008 14:23 >>> To: Jones, Andy >>> Cc: psi...@li... >>> Subject: Re: [Psidev-pi-dev] Fragment Ions in analysisXML - how it is currently >>> handled in PRIDE (Issue 28) >>> >>> Hi Andy, >>> >>> As we have both said, it's important to determine the use cases for this >>> information. :) The only reasonable use case that doesn't take up oodles >>> of disk space is simply knowing the ion types that were predicted. >>> >>> Unless I planned to reproduce the search engine's comparison exactly, I >>> don't see the point in knowing the exact mass(es) that the search engine >>> expected and the observed ion(s) that it matched to. And if I plan to >>> reproduce the score, that probably means I have access to the search >>> engine's algorithm, so I'd just regenerate the comparison. >>> >>> As for mapping to the observed ion(s), I think it's not relevant for the >>> purposes of basic annotation. For clarity of presentation, viewers >>> usually show the ion as either a logical point in the spectrum >>> independent of the data itself, or they map it to the most abundant peak >>> in the window. These approaches can be combined by changing the >>> annotation when the user zooms in. >>> >>> So yes, in this approach we have information loss. But I think it's >>> better than not having the information at all (and depending on a >>> vendor-supplied and version-dependent script to regenerate it) and >>> certainly better than choking on 10gb analysis files. ;) >>> >>> -Matt >>> >>> >>> Jones, Andy wrote: >>> >>>> Hi all, >>>> >>>> >>>> >>>>> An example to show how compact it could be: >>>>> fragmentIons="b3 y7,+2 b4 y5 y4 b7-H2O y3 y2 b7-H2O,+2 y3 y2" >>>>> >>>>> >>>> I have a couple of queries about this proposal... >>>> >>>> Given a peptide sequence, we would be able to work out what were the >>>> >>> expected masses of these fragments, assuming a standard method of calculating >>> the masses of the b and y ions (and losses) - do all search engines use the same >>> equation to calculate ion masses? >>> >>>> We wouldn't really know which peaks in the source spectrum corresponded with >>>> >>> which ion. For many of the peaks we would be able to make a fair guess i.e. there >>> is an observed peak within the tolerance window matching the expected mass but >>> this doesn't help when there are multiple peaks within the window - I don't think we >>> could correctly assume it would always be the most abundant peak...? >>> >>>> In other words, we still have information loss. Perhaps one way forward would >>>> >>> be for us to list the use cases that fragment ions must be reported for - do we >>> have a list of use cases anywhere? >>> >>>> I think getting this right will be a long process, so we have to make sure that we >>>> >>> have a strong enough use case if we really want to get this into analysisXML >>> version1. >>> >>>> Cheers >>>> Andy >>>> >>>> >>>> >>>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Psidev-pi-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev -- David Creasy Matrix Science 64 Baker Street London W1U 7GB, UK Tel: +44 (0)20 7486 1050 Fax: +44 (0)20 7224 1344 dc...@ma... http://www.matrixscience.com Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
