You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
(4) |
Oct
(10) |
Nov
(1) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(8) |
May
(40) |
Jun
(30) |
Jul
(61) |
Aug
(21) |
Sep
(12) |
Oct
(56) |
Nov
(99) |
Dec
(83) |
2009 |
Jan
(3) |
Feb
(9) |
Mar
(1) |
Apr
(5) |
May
(88) |
Jun
(43) |
Jul
(60) |
Aug
(54) |
Sep
(4) |
Oct
(18) |
Nov
(9) |
Dec
(5) |
2010 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(8) |
May
(10) |
Jun
(8) |
Jul
(10) |
Aug
(18) |
Sep
(11) |
Oct
(19) |
Nov
(14) |
Dec
(26) |
2011 |
Jan
(27) |
Feb
(38) |
Mar
(50) |
Apr
(128) |
May
(54) |
Jun
(116) |
Jul
(79) |
Aug
(163) |
Sep
(21) |
Oct
(14) |
Nov
(19) |
Dec
(9) |
2012 |
Jan
(7) |
Feb
(34) |
Mar
(34) |
Apr
(50) |
May
(70) |
Jun
(23) |
Jul
(8) |
Aug
(24) |
Sep
(35) |
Oct
(40) |
Nov
(276) |
Dec
(34) |
2013 |
Jan
(25) |
Feb
(23) |
Mar
(12) |
Apr
(59) |
May
(31) |
Jun
(11) |
Jul
(21) |
Aug
(7) |
Sep
(18) |
Oct
(11) |
Nov
(12) |
Dec
(18) |
2014 |
Jan
(37) |
Feb
(22) |
Mar
(9) |
Apr
(10) |
May
(38) |
Jun
(20) |
Jul
(15) |
Aug
(4) |
Sep
(4) |
Oct
(3) |
Nov
(8) |
Dec
(5) |
2015 |
Jan
(13) |
Feb
(34) |
Mar
(27) |
Apr
(5) |
May
(12) |
Jun
(10) |
Jul
(12) |
Aug
(3) |
Sep
(1) |
Oct
(13) |
Nov
|
Dec
(6) |
2016 |
Jan
(1) |
Feb
(1) |
Mar
(17) |
Apr
(139) |
May
(120) |
Jun
(90) |
Jul
(10) |
Aug
|
Sep
|
Oct
(11) |
Nov
(6) |
Dec
(2) |
2017 |
Jan
(24) |
Feb
(8) |
Mar
(7) |
Apr
(2) |
May
(5) |
Jun
(11) |
Jul
(5) |
Aug
(9) |
Sep
(6) |
Oct
(4) |
Nov
(2) |
Dec
(4) |
2018 |
Jan
(7) |
Feb
|
Mar
(4) |
Apr
(6) |
May
(10) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(3) |
Dec
(3) |
2019 |
Jan
(3) |
Feb
|
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(6) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(12) |
Dec
(1) |
2020 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Phil J. @ E. <pj...@eb...> - 2008-10-02 13:50:56
|
Hi, If you are not actively committing anything to the PSI-PI Google Code Subversion repository, you can stop reading now.... I have created a new WIKI page describing how to use SVN tagging to manage versions of XML instance documents, so they can always be retrieved together with the corresponding version of the XML schema. This is instead of just creating new folders in the trunk. You can see the page here: http://code.google.com/p/psi-pi/wiki/UsingSVNTagsToOrganiseInstanceDocs The example given has been performed, so you can see the result in SVN on the Google Code SVN browser: http://code.google.com/p/psi-pi/source/browse/#svn/tags So - please feed back on what you think about changing to this way of working - it may be that you consider it not worth the effort! Can be discussed briefly at today's telecon I suppose. best regards, Phil. -- Phil Jones Senior Software Engineer InterPro Team PANDA Group, EMBL-EBI Wellcome Trust Genome Campus Hinxton, Cambridge, CB10 1SD UK. Work phone: +44 1223 494406 (NEW NUMBER) Skype: philip-jones |
From: Phil J. @ E. <pj...@eb...> - 2008-10-02 13:49:12
|
Hi, A couple of weeks ago a few potential terms related to the annotation of fragment ions were added to the issues list. Since then, David Creasy has added a few additional terms too. Please take a look and add your comments: http://code.google.com/p/psi-pi/issues/detail?id=28#c15 Once the list of terms have been agreed, I can then add them to the OBO file. (So any opinions about the term relationships in the OBO file to support this would also be welcome!) best regards, Phil. -- Phil Jones Senior Software Engineer InterPro Team PANDA Group, EMBL-EBI Wellcome Trust Genome Campus Hinxton, Cambridge, CB10 1SD UK. Work phone: +44 1223 494406 (NEW NUMBER) Skype: philip-jones |
From: David C. <dc...@ma...> - 2008-10-02 11:05:37
|
Hi, I've added an enzyme section for a mixed enzyme (CNBr+Trypsin) to the Mascot_MSMS_example.axml file in the examples directory. At the moment, for a mixed enzyme there is no place for the name chosen from the search form drop down list for the enzyme. Likewise, if in any search engine someone chose to call Trypsin, say "Bovine Trypsin", there's no place for this name as we should just give the accession for Trypsin? In the schema, we could restrict CTermGain and NTermGain to what we would expect in hemical formulae? [A-Z][a-z][0..9][ ] to stop someone entering a decimal number? I've put the regex plus the CV, don't know if that is what is intended. David -------- Original Message -------- Subject: [psi-pi commit] r167 - trunk/examples Date: Thu, 02 Oct 2008 03:50:47 -0700 From: cod...@go... To: dc...@ma... Author: dcreasy Date: Thu Oct 2 03:50:39 2008 New Revision: 167 Modified: trunk/examples/Mascot_MSMS_example.axml Log: Added enzyme section Modified: trunk/examples/Mascot_MSMS_example.axml ============================================================================== --- trunk/examples/Mascot_MSMS_example.axml (original) +++ trunk/examples/Mascot_MSMS_example.axml Thu Oct 2 03:50:39 2008 @@ -501,6 +501,20 @@ <SpecificityRule accession="" cvRef="" name="" unitAccession="" unitName="" /> </SearchModification> </ModificationParams> + <Enzymes independent="0"> + <Enzyme id="ENZ_0" CTermGain="OH" NTermGain="H" missedCleavages="1" semiSpecific="0"> + <SiteRegexp><![CDATA[(?<=[M])|(?=[])]]></SiteRegexp> + <EnzymeName> + <pf:cvParam accession="PI:TODO" name="CNBr" cvRef="PSI-PI" /> + </EnzymeName> + </Enzyme> + <Enzyme id="ENZ_1" CTermGain="OH" NTermGain="H" missedCleavages="1" semiSpecific="0"> + <SiteRegexp><![CDATA[(?<=[KR])|(?=[P])]]></SiteRegexp> + <EnzymeName> + <pf:cvParam accession="PI:TODO" name="Trypsin" cvRef="PSI-PI" /> + </EnzymeName> + </Enzyme> + </Enzymes> <MassTable id="0"> <Residue Code="A" Mass="71.037114"/> <Residue Code="B" Mass="114.53494"/> -- 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 |
From: David C. <dc...@ma...> - 2008-10-01 16:28:44
|
Hi everyone, There will be an AnalysisXML working group conference call on Thursday at: http://www.timeanddate.com/worldclock/fixedtime.html?day=2&month=10&year=2008&hour=16&min=0&sec=0&p1=136 Minutes from last meeting at: http://psidev.info/index.php?q=node/372 Agenda: 1. Is a later time for calls possible to make it easier for Eric? 2. Review of comments on the use cases at: http://psidev.info/index.php?q=node/371 3. Issues 3 and 35 from the issues list http://code.google.com/p/psi-pi/issues/list and subsequent email discussion on the list 4. Feedback from example instance docs 5. Progress with CV (Jenny) 6. Documentation (Andy, Martin, Eric) 7. Progress on outstanding issues from previous telecons: - MIAPE table (David) - Mascot N15 example (David) - SVN tags for example instance docs (Phil) - Mono/average masses (Martin) - Enzyme examples (David + others) - Issue 28 - fragmentation CV (Phil) 8. AOB Dial in details: + Germany: 08001012079 + Switzerland: 0800000860 + UK: 08081095644 + USA: 1-866-314-3683 + Generic international: +44 2083222500 (UK number) access code: 297427 -- 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 ------------------------------------------------------------------------- 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 |
From: Jones, A. <And...@li...> - 2008-09-30 13:24:00
|
I think the count attribute is just confusing, if two modifications have been identified, just have two entries of the Modification element? I don't personally find the count attribute confusing, but don't have a strong preference. Also, see next item. There would still be an issue of how to specify which residue has been modified but basically this is the same issue for standard and custom mods i.e. the CV tells you the mod and the residue? Not necessarily. Suppose that you have 2 phosphorylated residues, PMF and the peptide is STYSTYSTYK I still don't see how to encode this? These two things are sort of related in that I’d like to only have one mechanism for describing mods if possible. My suggestion is that it is done as follows: <Modification> <cvParam name = “phosphorylation”/> </Modification> <Modification> <cvParam name = “phosphorylation”/> </Modification> Since from PMF this is all the information we have i.e. we don’t know the location or the residue (we may have a mass delta value though?). If we know the residues modified, then it is encoded as follows: <Modification location = “3”> <cvParam name = “phosphorylation to tyrosine”/> </Modification> <Modification location = “6”> <cvParam name = “phosphorylation to tyrosine”/> </Modification> I agree this use of CV terms doesn’t appear ideal but the current schema allows you to encode the same information in lots of different ways, say two tyrosines are phosphorylated: <CustomMod count = “2” residue = “Y”> <cvParam name = “phosphorylation”/> </CustomMod> OR <Modification> <cvParam name = “phosphorylation to tyrosine”/> </Modification> <Modification> <cvParam name = “phosphorylation to tyrosine”/> </Modification> OR <CustomMod count = “2” > <cvParam name = “phosphorylation to tyrosine”/> </CustomMod> I think we ought to discuss the pros and cons of encoding the mod and the residue modified in one single CV term – it should work in theory but it seems like more work for parsers than just having an attribute for residue = “Y”... Cheers, Andy From: David Creasy [mailto:dc...@ma...] Sent: 30 September 2008 10:55 To: psi...@li... Cc: psi...@li... Subject: Re: [Psidev-pi-dev] Modifications Hi, Comments in line below: Jones, Andy wrote: Hi all, I’d like to get the mods part of the schema sorted in time for the call this week if possible. There are quite a few different aspects in issues 3 and 35 so I’ll try to summarise it here: In the SpectrumIdentificationProtocol we have: <SearchModification fixedMod="false" > <ModName accession="MOD:TODO" name="SMA (N-term)" cvRef="PSI-MOD" /> <MassValue value="127.063324" unitAccession="PSI:xxxx" unitName="Da" /> <SpecificityRule accession="" cvRef="" name="" unitAccession="" unitName="" /> </SearchModification> On Peptide we have: <Modification location="13"> <pf:cvParam accession="TODO: (requires quite a bit of code)" name="SMA (K)" cvRef="PSI-MOD" /> </Modification> OR <SubstitutionModification originalResidue="K" replacementResidue="M" location="2"> <pf:cvParam cvRef="" accession="" name=""/> </SubstitutionModification> (Note the datatypes were set to int for original and replaceResidue so I have fixed this to be the same alphabet as for pre and post). OR <CustomModification location="2" monoisotopicMassDelta="21.21" count="1" residue = “M”> <pf:cvParam cvRef="" accession="" name=""/> </CustomModification> PSI-MOD can specify a modification and the residue that has been modified, although the terms are not always intuitive for our purposes. For example, as far as I can tell “oxidation to L-methionine sulfoxide” would be the standard term for a methionine oxidation, correct? Um, I don't think so. It looks to me as though Oxidation of Methionine is possibly missing PSI-MOD at the moment... I would expect there to be a DiffFormula: "O 1" and from unimod the PSI-MS name is "Oxidation". So, it looks as though something may be wrong here... I've cc'd psi...@li... so hopefully someone will correct/enlighten us. (The .obo file hasn't been updated since 20th April, and I know that there have been changes since then.) Comments on current schema: I’m not sure we need CustomModification, I would prefer just to have the Modification element, making location optional and adding the mass delta attributes to Modification. Sounds fine. And the CV would be optional too? I think the count attribute is just confusing, if two modifications have been identified, just have two entries of the Modification element? I don't personally find the count attribute confusing, but don't have a strong preference. Also, see next item. There would still be an issue of how to specify which residue has been modified but basically this is the same issue for standard and custom mods i.e. the CV tells you the mod and the residue? Not necessarily. Suppose that you have 2 phosphorylated residues, PMF and the peptide is STYSTYSTYK I still don't see how to encode this? I disagree that we should use the same element for the searched and the found modification. We do not need to report the specificity on the found modifications and in most cases you would not report the mass delta for a found modification (presumably this would only make any sense for MS1 data?) OK On SearchModification, are we agreed that we want to report the MassValue (i.e. mass of residue +/- mod) rather than say a MassDelta (mass of mod only)? No! I think a delta is better. Suppose that you are performing an 14N/15N experiment and want to use Oxidation. That would mean having two separate SearchModifications. (Also, I don't think that PSI-MOD should have this, but that's a separate issue...) I think we should add documentation that MassValue is optional since the mod mass is part of the CV, but if reported the MassValue “overrides” the mass value from the CV. SubstitutionMod inherits a mandatory association to Param, this needs to be changed since in most cases a CV term would not be required. Thoughts? 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 -- 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 |
From: David C. <dc...@ma...> - 2008-09-30 09:54:58
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi,<br> <br> Comments in line below:<br> <br> Jones, Andy wrote: <blockquote cite="mid:08D...@EV..." type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta name="Generator" content="Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:1515344470; mso-list-type:hybrid; mso-list-template-ids:-1276846134 1420610800 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;} @list l0:level1 {mso-level-start-at:0; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:Calibri; mso-bidi-font-family:"Times New Roman";} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="Section1"> <p class="MsoNormal">Hi all,<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I’d like to get the mods part of the schema sorted in time for the call this week if possible. There are quite a few different aspects in issues 3 and 35 so I’ll try to summarise it here:<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">In the SpectrumIdentificationProtocol we have:<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> <SearchModification fixedMod="false" ><o:p></o:p></p> <p class="MsoNormal"> <ModName accession="MOD:TODO" name="SMA (N-term)" cvRef="PSI-MOD" /><o:p></o:p></p> <p class="MsoNormal"> <MassValue value="127.063324" unitAccession="PSI:xxxx" unitName="Da" /><o:p></o:p></p> <p class="MsoNormal"> <SpecificityRule accession="" cvRef="" name="" unitAccession="" unitName="" /><o:p></o:p></p> <p class="MsoNormal"> </SearchModification><o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">On Peptide we have:<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> <Modification location="13"><o:p></o:p></p> <p class="MsoNormal"> <pf:cvParam accession="TODO: (requires quite a bit of code)" name="SMA (K)" cvRef="PSI-MOD" /><o:p></o:p></p> <p class="MsoNormal"> </Modification><o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">OR<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> <SubstitutionModification originalResidue="K" replacementResidue="M" location="2"><o:p></o:p></p> <p class="MsoNormal"> <pf:cvParam cvRef="" accession="" name=""/><o:p></o:p></p> <p class="MsoNormal"> </SubstitutionModification><o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">(Note the datatypes were set to int for original and replaceResidue so I have fixed this to be the same alphabet as for pre and post).<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">OR<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> <CustomModification location="2" monoisotopicMassDelta="21.21" count="1" residue = “M”><o:p></o:p></p> <p class="MsoNormal"> <pf:cvParam cvRef="" accession="" name=""/><o:p></o:p></p> <p class="MsoNormal"> </CustomModification><o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal">PSI-MOD can specify a modification and the residue that has been modified, although the terms are not always intuitive for our purposes. For example, as far as I can tell “oxidation to L-methionine sulfoxide” would be the standard term for a methionine oxidation, correct?</p> </div> </blockquote> Um, I don't think so. It looks to me as though Oxidation of Methionine is possibly missing PSI-MOD at the moment...<br> I would expect there to be a DiffFormula: "O 1" and from unimod the PSI-MS name is "Oxidation".<br> So, it looks as though something may be wrong here... I've cc'd <a class="moz-txt-link-abbreviated" href="mailto:psi...@li...">psi...@li...</a> so hopefully someone will correct/enlighten us.<br> (The .obo file hasn't been updated since 20th April, and I know that there have been changes since then.)<br> <br> <blockquote cite="mid:08D...@EV..." type="cite"> <div class="Section1"> <p class="MsoNormal"><o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Comments on current schema:<o:p></o:p></p> <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span style="">-<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->I’m not sure we need CustomModification, I would prefer just to have the Modification element, making location optional and adding the mass delta attributes to Modification.</p> </div> </blockquote> Sounds fine. And the CV would be optional too?<br> <blockquote cite="mid:08D...@EV..." type="cite"> <div class="Section1"> <p class="MsoListParagraph" style="text-indent: -18pt;"> I think the count attribute is just confusing, if two modifications have been identified, just have two entries of the Modification element? </p> </div> </blockquote> I don't personally find the count attribute confusing, but don't have a strong preference. Also, see next item.<br> <blockquote cite="mid:08D...@EV..." type="cite"> <div class="Section1"> <p class="MsoListParagraph" style="text-indent: -18pt;">There would still be an issue of how to specify which residue has been modified but basically this is the same issue for standard and custom mods i.e. the CV tells you the mod and the residue?</p> </div> </blockquote> Not necessarily. Suppose that you have 2 phosphorylated residues, PMF and the peptide is STYSTYSTYK<br> I still don't see how to encode this?<br> <blockquote cite="mid:08D...@EV..." type="cite"> <div class="Section1"> <p class="MsoListParagraph" style="text-indent: -18pt;"> <o:p></o:p></p> <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span style="">-<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->I disagree that we should use the same element for the searched and the found modification. We do not need to report the specificity on the found modifications and in most cases you would not report the mass delta for a found modification (presumably this would only make any sense for MS1 data?)</p> </div> </blockquote> OK<br> <blockquote cite="mid:08D...@EV..." type="cite"> <div class="Section1"> <p class="MsoListParagraph" style="text-indent: -18pt;"><o:p></o:p></p> <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span style="">-<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->On SearchModification, are we agreed that we want to report the MassValue (i.e. mass of residue +/- mod) rather than say a MassDelta (mass of mod only)?</p> </div> </blockquote> No! I think a delta is better. Suppose that you are performing an 14N/15N experiment and want to use Oxidation. That would mean having two separate SearchModifications.<br> (Also, I don't think that PSI-MOD should have this, but that's a separate issue...)<br> <blockquote cite="mid:08D...@EV..." type="cite"> <div class="Section1"> <p class="MsoListParagraph" style="text-indent: -18pt;"><o:p></o:p></p> <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span style="">-<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->I think we should add documentation that MassValue is optional since the mod mass is part of the CV, but if reported the MassValue “overrides” the mass value from the CV.<o:p></o:p></p> <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span style="">-<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->SubstitutionMod inherits a mandatory association to Param, this needs to be changed since in most cases a CV term would not be required.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Thoughts?<o:p></o:p></p> <p class="MsoNormal">Cheers, Andy<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> </div> <pre wrap=""> <hr size="4" width="90%"> ------------------------------------------------------------------------- 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 <a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a></pre> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ Psidev-pi-dev mailing list <a class="moz-txt-link-abbreviated" href="mailto:Psi...@li...">Psi...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev">https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev</a> </pre> </blockquote> <br> <pre class="moz-signature" cols="72">-- David Creasy Matrix Science 64 Baker Street London W1U 7GB, UK Tel: +44 (0)20 7486 1050 Fax: +44 (0)20 7224 1344 <a class="moz-txt-link-abbreviated" href="mailto:dc...@ma...">dc...@ma...</a> <a class="moz-txt-link-freetext" href="http://www.matrixscience.com">http://www.matrixscience.com</a> Matrix Science Ltd. is registered in England and Wales Company number 3533898</pre> </body> </html> |
From: Jones, A. <And...@li...> - 2008-09-29 15:22:38
|
Hi all, I'd like to get the mods part of the schema sorted in time for the call this week if possible. There are quite a few different aspects in issues 3 and 35 so I'll try to summarise it here: In the SpectrumIdentificationProtocol we have: <SearchModification fixedMod="false" > <ModName accession="MOD:TODO" name="SMA (N-term)" cvRef="PSI-MOD" /> <MassValue value="127.063324" unitAccession="PSI:xxxx" unitName="Da" /> <SpecificityRule accession="" cvRef="" name="" unitAccession="" unitName="" /> </SearchModification> On Peptide we have: <Modification location="13"> <pf:cvParam accession="TODO: (requires quite a bit of code)" name="SMA (K)" cvRef="PSI-MOD" /> </Modification> OR <SubstitutionModification originalResidue="K" replacementResidue="M" location="2"> <pf:cvParam cvRef="" accession="" name=""/> </SubstitutionModification> (Note the datatypes were set to int for original and replaceResidue so I have fixed this to be the same alphabet as for pre and post). OR <CustomModification location="2" monoisotopicMassDelta="21.21" count="1" residue = "M"> <pf:cvParam cvRef="" accession="" name=""/> </CustomModification> PSI-MOD can specify a modification and the residue that has been modified, although the terms are not always intuitive for our purposes. For example, as far as I can tell "oxidation to L-methionine sulfoxide" would be the standard term for a methionine oxidation, correct? Comments on current schema: - I'm not sure we need CustomModification, I would prefer just to have the Modification element, making location optional and adding the mass delta attributes to Modification. I think the count attribute is just confusing, if two modifications have been identified, just have two entries of the Modification element? There would still be an issue of how to specify which residue has been modified but basically this is the same issue for standard and custom mods i.e. the CV tells you the mod and the residue? - I disagree that we should use the same element for the searched and the found modification. We do not need to report the specificity on the found modifications and in most cases you would not report the mass delta for a found modification (presumably this would only make any sense for MS1 data?) - On SearchModification, are we agreed that we want to report the MassValue (i.e. mass of residue +/- mod) rather than say a MassDelta (mass of mod only)? - I think we should add documentation that MassValue is optional since the mod mass is part of the CV, but if reported the MassValue "overrides" the mass value from the CV. - SubstitutionMod inherits a mandatory association to Param, this needs to be changed since in most cases a CV term would not be required. Thoughts? Cheers, Andy |
From: David C. <dc...@ma...> - 2008-09-29 09:56:26
|
Hi everyone, Minutes for the meeting (thanks Jenny) now at: http://psidev.info/index.php?q=node/372 Next meeting this Thursday: http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=2&year=2008&hour=16&min=0&sec=0&p1=136 I'll post an agenda on Wednesday. David David Creasy wrote: > Hi everyone, > > There will be an AnalysisXML working group conference call on Thursday at: > http://www.timeanddate.com/worldclock/fixedtime.html?day=25&month=9&year=2008&hour=16&min=0&sec=0&p1=136 > > Minutes from last meeting at: > http://psidev.info/index.php?q=node/369 > > > Agenda: > 1. Changes to the use cases > The list of use cases was rather out of date. Update at: > http://psidev.info/index.php?q=node/371 > Please either add a comment at the bottom of that page or send a > message to the list or be prepared to discuss this at the > teleconference tomorrow. > > 2. Is issue 26 closed? > http://code.google.com/p/psi-pi/issues/detail?id=18 > > 3. Review of SpectraST_example.xml > There is an example instance document for a spectraST in the SVN. > http://code.google.com/p/psi-pi/source/browse/trunk/examples/SpectraST_example.xml > See also the issue in the issue list: > http://code.google.com/p/psi-pi/issues/detail?id=18#c2 > > 4. Other items still to be actioned from last weeks minutes. > > 5. Other items on the issues list: > http://code.google.com/p/psi-pi/issues/list > > Dial in details: > > + Germany: 08001012079 > + Switzerland: 0800000860 > + UK: 08081095644 > + USA: 1-866-314-3683 > + Generic international: +44 2083222500 (UK number) > > access code: 297427 > -- 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 |
From: David C. <dc...@ma...> - 2008-09-28 18:02:47
|
All looks good to me. I've updated the three Mascot examples in the examples directory so these now validate again. David Jones, Andy wrote: > Another schema committed by SVN, added several additional KeyRef that were missing. > > Each instance of cvParam should have a KeyRef for cvList (cvRef) but it would require putting in the XPath of each one individually (I don't think XSD:KeyRef supports an XPath to select of node of a particular name anywhere in the document). I can't be bothered adding all these KeyRefs at this stage but we should probably try to do this before submission... > > Cheers, Andy > > >> -----Original Message----- >> From: Jones, Andy [mailto:And...@li...] >> Sent: 26 September 2008 10:44 >> To: psi...@li... >> Subject: [Psidev-pi-dev] New schema committed >> >> Some changes to the schema uploaded by SVN. As discussed on the call, it seems >> to make sense to have the summary collections at the top of the file e.g. cvList, >> AnalysisSoftware etc. >> >> >> >> ------------------------------------------------------------------------- >> 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 |
From: Jones, A. <And...@li...> - 2008-09-26 14:12:52
|
Another schema committed by SVN, added several additional KeyRef that were missing. Each instance of cvParam should have a KeyRef for cvList (cvRef) but it would require putting in the XPath of each one individually (I don't think XSD:KeyRef supports an XPath to select of node of a particular name anywhere in the document). I can't be bothered adding all these KeyRefs at this stage but we should probably try to do this before submission... Cheers, Andy > -----Original Message----- > From: Jones, Andy [mailto:And...@li...] > Sent: 26 September 2008 10:44 > To: psi...@li... > Subject: [Psidev-pi-dev] New schema committed > > Some changes to the schema uploaded by SVN. As discussed on the call, it seems > to make sense to have the summary collections at the top of the file e.g. cvList, > AnalysisSoftware etc. > > > > ------------------------------------------------------------------------- > 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 |
From: Jones, A. <And...@li...> - 2008-09-26 11:13:33
|
A few more minor changes I want to make to the schema: - Remove the rest of the underscores that precede some of the element names in FuGElight (e.g. "_role" --> "role") - Make AnalysisProtocol and AnalysisProtocolApplication abstract - I think they are supposed to be anyway? - ProteinDetection has an element called _runtimeParams, I would prefer this to be just "params" (since this is effectively a protocol not a protocol application so these are not strictly runtime parameters) - AnalysisProtocolCollection allows any subclasses of Protocol to be included so this allows a FuGE GenericProtocol to be reported. I think we should restrict the protocol collection to only reporting subclasses of AnalysisProtocol i.e. SpectrumIdentificationProtocol and ProteinDetectionProtocol I also plan to strip more out of FuGE light so it only contains classes that we are using now or are likely to want to use in axml v2. I would like to upload these changes today if possible while I have time to do it, so let me know if anyone seems an obvious problem with any of these changes? We can always role them back if I've missed something Cheers Andy > -----Original Message----- > From: Jones, Andy [mailto:And...@li...] > Sent: 26 September 2008 10:44 > To: psi...@li... > Subject: [Psidev-pi-dev] New schema committed > > Some changes to the schema uploaded by SVN. As discussed on the call, it seems > to make sense to have the summary collections at the top of the file e.g. cvList, > AnalysisSoftware etc. > > > > ------------------------------------------------------------------------- > 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 |
From: Jones, A. <And...@li...> - 2008-09-26 09:44:15
|
Some changes to the schema uploaded by SVN. As discussed on the call, it seems to make sense to have the summary collections at the top of the file e.g. cvList, AnalysisSoftware etc. |
From: David C. <dc...@ma...> - 2008-09-24 15:10:35
|
Hi everyone, There will be an AnalysisXML working group conference call on Thursday at: http://www.timeanddate.com/worldclock/fixedtime.html?day=25&month=9&year=2008&hour=16&min=0&sec=0&p1=136 Minutes from last meeting at: http://psidev.info/index.php?q=node/369 Agenda: 1. Changes to the use cases The list of use cases was rather out of date. Update at: http://psidev.info/index.php?q=node/371 Please either add a comment at the bottom of that page or send a message to the list or be prepared to discuss this at the teleconference tomorrow. 2. Is issue 26 closed? http://code.google.com/p/psi-pi/issues/detail?id=18 3. Review of SpectraST_example.xml There is an example instance document for a spectraST in the SVN. http://code.google.com/p/psi-pi/source/browse/trunk/examples/SpectraST_example.xml See also the issue in the issue list: http://code.google.com/p/psi-pi/issues/detail?id=18#c2 4. Other items still to be actioned from last weeks minutes. 5. Other items on the issues list: http://code.google.com/p/psi-pi/issues/list Dial in details: + Germany: 08001012079 + Switzerland: 0800000860 + UK: 08081095644 + USA: 1-866-314-3683 + Generic international: +44 2083222500 (UK number) access code: 297427 -- 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 |
From: David C. <dc...@ma...> - 2008-09-17 16:25:55
|
Hi everyone, There will be an AnalysisXML working group conference call on Thursday at: http://www.timeanddate.com/worldclock/fixedtime.html?day=18&month=9&year=2008&hour=16&min=0&sec=0&p1=136 Minutes from last meeting at: http://psidev.info/index.php?q=node/366 See the issues list: http://code.google.com/p/psi-pi/issues/list Dial in details: + Germany: 08001012079 + Switzerland: 0800000860 + UK: 08081095644 + USA: 1-866-314-3683 + Generic international: +44 2083222500 (UK number) access code: 297427 -- 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 |
From: Jennifer S. <jen...@ma...> - 2008-09-17 16:24:36
|
Hi, Julian and I have been having a look at spectraST and trying to generate an example analysisXML document. Although from what we have done so far it seems it is possible to get the basic spectraST details into the file with the current schema there are some issues which I will discuss below. Basically the software takes as input a 'database' of spectra to which it matches the query spectrum according to a set of user defined parameters and assigns some score - this basic information of course can be captured by analysisXML. Each entry in the search database is therefore a peptide and what is actually searched is the spectrum - a set of peaks and ion assignments. Each entry in the database - so each peptide/spectrum - has a set of parameters associated with it. For example modifications on the peptide, mass differences between this database spectrum and the theoretical spectrum for the peptide and also the possibilty of various scores depending on how the spectrum was generated. Some of these details are easy to deal with, for example modifications. As I understand it modifications maybe set in the user parameters file for spectraST which can limit the search - additionally however peptides may be identified by spectraST with modifications that were not defined in the user parameter file but were present in the search database. In analysisXML this means that the peptide in the SequenceCollection may have a modification assigned that is not present in the search parameters described in the AnalysisCollection, which I don't think will cause any problems. The interesting part is how the 'database' is generated and we need to decide if we think this information is useful. I downloaded an example from NIST and have extracted a very small part of that and pasted it below - the start of one database entry (I have not included the entire spectra). You can see from the example that the database contains the peptide sequence, various parameters associated with the assignment of the peptide to the spectrum and the spectrum itself with the ion assignments. If we were to do a sequence database search and assign peptides then in the analysisXML file we would capture the protein sequence from the database and the peptide sequence, in the SpectraST example the equivalent to the sequence searched is the spectrum. Before we spend any time producing the example document Julian and I thought it would be useful to highlight the issues and discuss in a conference call (perhaps tomorrow). Thanks, Jenny -------------------------- example from NIST_sigmaups1_v2.0_2008-07-09.msp ---------------------------------------------------------------- Name: AAAQPHTEIPEGTTAEEAGIGDTPSLEDEAAGHVTQAR/4 MW: 3830.819 Comment: Spec=Consensus Pep=N-Semitryp_insource_confirmed Fullname=Q.AAAQPHTEIPEGTTAEEAGIGDTPSLEDEAAGHVTQAR.M/4 Mods=0 Parent=957.705 Inst=it Mz_diff=0.835 Mz_exact=957.7048 Mz_av=958.263 Protein="IPI00025499.1|SWISS-PROT:P10636-8|REFSEQ_NP:NP_005901|ENSEMBL:ENSP00000303214 Tax_Id=9606 Microtubule-associated protein tau isoforM 2" Pseq=92 Organism="human" Se=1^O2:ex=2.005e-011/2.005e-011,td=372925/3.721e+005,pr=1.1e-015/1.1e-015,bs=4.11e-299,b2=4.01e-011,bd=850 Sample=1/sigma_proof_of_concept_cam,2,2 Nreps=2/2 Missing=0.0901/0.0119 Parent_med=958.54/0.03 Max2med_orig=136.6/20.3 Dotfull=0.847/0.000 Dot_cons=0.933/0.019 Unassign_all=0.053 Unassigned=0.047 Dotbest=0.95 Flags=2,1,0 Naa=38 DUScorr=1.9/1.9/0.38 Dottheory=0.78 Pfin=2.7e+009 Probcorr=0.82 Tfratio=9.7e+008 Pfract=0 Num peaks: 120 476.3 117 "? 2/2 1.4" 578.5 154 "b17^3/-0.10,b12-46^2/-0.29 2/2 0.4" 579.6 62 "b12-44^2/-0.19,b12-45^2/0.31 2/2 0.0" 643.4 78 "b13-18^2/0.09,b20-46^3/-0.24 2/2 0.1" 649.6 123 "a7/0.27 2/2 1.4" 673.1 95 "? 2/2 1.0" 686.6 73 "b28-46^4/0.03,b28-45^4/-0.22 2/2 0.1" 694.3 181 "b14-18^2/0.47,b14-17^2/-0.03 2/2 1.1" 703.1 106 "b14^2/0.27 2/2 0.1" 706.3 66 "? 2/2 0.3" 711.8 101 "y6/0.41 2/2 0.2" 729.5 291 "b15-18^2/0.15,b15-17^2/-0.35 2/2 0.3" 738.5 255 "b15^2/0.15 2/2 1.1" 744.1 93 "b23-18^3/0.09,b23-17^3/-0.24 2/2 0.4" 746.8 76 "? 2/2 0.4" 761.7 58 "b31-17^4/0.10,b31-18^4/0.35 2/1 0.2" ----------------------------------------------------------------------------------------------------------- |
From: David C. <dc...@ma...> - 2008-09-08 17:10:48
|
Hi everyone, There will be an AnalysisXML working group conference call on Thursday at: http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=9&year=2008&hour=16&min=0&sec=0&p1=136 Minutes from last meeting at: http://www.psidev.info/index.php?q=node/361 We've not had a telecon since the end of July, so we need to discuss the progress and assign actions using the minutes of last meeting and the issues list: http://code.google.com/p/psi-pi/issues/list Dial in details: + Germany: 08001012079 + Switzerland: 0800000860 + UK: 08081095644 + USA: 1-866-314-3683 + Generic international: +44 2083222500 (UK number) access code: 297427 -- 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 |
From: Jones, A. <And...@li...> - 2008-08-19 10:42:42
|
Hi all, A few minor updates to the schema today (mainly tidying it up): · Generally added documentation; · Changed data type of frames from string to list of integers (space separated); · Removed all complex types in the quantitation package (convexHull, features etc.); · Removed PolypeptideProcess and PolypeptideProcessProtocol (these were not reachable from the root anyway); · Removed TerminalSpecificityType (not used anywhere). I think almost all elements are now documented - we should continue to work on improving the docs within the XSD then auto-generate the content of the spec document from this (as for mzML). Cheers Andy |
From: Jones, A. <And...@li...> - 2008-08-08 13:10:19
|
I had a vague recollection we discussed it on the call but I couldn't remember what we agreed :-) Schema now updated with these changes, cheers Andy > -----Original Message----- > From: David Creasy [mailto:dc...@ma...] > Sent: 08 August 2008 13:41 > To: Jones, Andy > Cc: psi...@li... > Subject: Re: N15 example > > Hi Andy, > > Jones, Andy wrote: > > Hi David, > > > > I'm trying to understand how best to model differential labelling e.g. the N15 file. > I think we should view this as similar to searching for different variable mods. For > example, if this was an ICAT, we would search for C+ICATlight and C+ICAT heavy > within one single search. > It's not quite the same really. The problem is that any (naturally > occurring) modification that contains nitrogen will also have a > different delta for that modification. And you wouldn't want to consider > a modification with 15N masses occurring in a peptide made from 14N > masses. However, for the sake of simplicity, I think that we can ignore > this little detail. > > As such, I don't think it makes sense to separate out an N15 labelling into two > different search protocols. > > > Yes, (and I think that this what we agreed at the conference call). > > > I think we should allow multiple mass tables within one > SpectrumIdentificationProtocol. The MassTable also will need an id and an optional > cv terms to explain the purpose of this particular mass table and perhaps to say if it > is monoisotopic or average. We could then add a MassTable_ref to Peptide, > documented saying that it is only required if more than one MassTable has been > given. > > > Yes, this is what we agreed on the call: > http://www.psidev.info/index.php?q=node/361 > > If we also have: > > > > <FragmentationTable> > > <Measure id="m_mz"> > > <pf:cvParam cvRef="PSI-PI" accession="PI:xxxx" name="product ion > monoisotopic m/z"/> > > > > To say that reported fragment ions are monoisotopic, does this also solve the > problem if someone wants to report that precursor ions are average mass and > product ions are monoisotopic? > > > Yes. > > > > Just to be clear however, in SpectrumIdentificationProtocol we have: > > > > <SpectrumIdentificationProtocol id="SIP_1" > AnalysisSoftware_ref="AS_mascot_server"> > > <AdditionalSearchParams> > > > > ... > > <pf:cvParam accession="PI:00211" name="mass type setting monoisotopic" > cvRef="PSI-PI"/> > > > > I didn't understand why we couldn't have two CV terms here for product and > precursor mass setting, this is how X!Tandem sets up its searches. > Yes, this is also what we agreed on the call - Phil's suggestion > (although it didn't make it into the minutes). > I've added the change request to the CV to: > http://code.google.com/p/psi-pi/issues/detail?id=42#c2 > > > Was there something else that I missed here that would stop this working? > > > Can't think of anything (= = probably!) > Once you've made the schema changes, I'll update the N15 example. > > Thanks, > David > > Cheers > > Andy > > > > > > > > > > > > > > -- > 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 |
From: David C. <dc...@ma...> - 2008-08-08 12:41:03
|
Hi Andy, Jones, Andy wrote: > Hi David, > > I'm trying to understand how best to model differential labelling e.g. the N15 file. I think we should view this as similar to searching for different variable mods. For example, if this was an ICAT, we would search for C+ICATlight and C+ICAT heavy within one single search. It's not quite the same really. The problem is that any (naturally occurring) modification that contains nitrogen will also have a different delta for that modification. And you wouldn't want to consider a modification with 15N masses occurring in a peptide made from 14N masses. However, for the sake of simplicity, I think that we can ignore this little detail. > As such, I don't think it makes sense to separate out an N15 labelling into two different search protocols. > Yes, (and I think that this what we agreed at the conference call). > I think we should allow multiple mass tables within one SpectrumIdentificationProtocol. The MassTable also will need an id and an optional cv terms to explain the purpose of this particular mass table and perhaps to say if it is monoisotopic or average. We could then add a MassTable_ref to Peptide, documented saying that it is only required if more than one MassTable has been given. > Yes, this is what we agreed on the call: http://www.psidev.info/index.php?q=node/361 > If we also have: > > <FragmentationTable> > <Measure id="m_mz"> > <pf:cvParam cvRef="PSI-PI" accession="PI:xxxx" name="product ion monoisotopic m/z"/> > > To say that reported fragment ions are monoisotopic, does this also solve the problem if someone wants to report that precursor ions are average mass and product ions are monoisotopic? > Yes. > > Just to be clear however, in SpectrumIdentificationProtocol we have: > > <SpectrumIdentificationProtocol id="SIP_1" AnalysisSoftware_ref="AS_mascot_server"> > <AdditionalSearchParams> > > ... > <pf:cvParam accession="PI:00211" name="mass type setting monoisotopic" cvRef="PSI-PI"/> > > I didn't understand why we couldn't have two CV terms here for product and precursor mass setting, this is how X!Tandem sets up its searches. Yes, this is also what we agreed on the call - Phil's suggestion (although it didn't make it into the minutes). I've added the change request to the CV to: http://code.google.com/p/psi-pi/issues/detail?id=42#c2 > Was there something else that I missed here that would stop this working? > Can't think of anything (= = probably!) Once you've made the schema changes, I'll update the N15 example. Thanks, David > Cheers > Andy > > > > > > -- 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 |
From: Martin E. <mar...@ru...> - 2008-08-08 12:30:51
|
Hi! The schema now contains the most important primary and foreign key constraints. That means, id attributes must be unique within their schema hierarchy level and ..._ref attributes must point to correct and existing elements (identified by their id attribute). If not, schema-validation results in an error message like (XMLSpy): 'The value "bla" matched by the <keyref> identity constraint "bla2" was not matched by the referenced key "bla3" within the scope of element <AnalysisXML>.' I tried to make "bla2" following a simple nomenclature, e.g. FK_DATAADSILSIR_SD Meaning: SpectraData_ref (SD) attribute of element DataCollection(DATA)/AnalysisData(AD)/SpectrumIdentificationList(SIL)/SpectrumIdentificationResult(SIR) must point to a SpectraData element. XMLSpy jumps to the wrong reference, so human parsing of the FK_guru_meditation is normally not necessary... Bye Martin |
From: Jones, A. <And...@li...> - 2008-08-08 12:06:38
|
Hi David, I'm trying to understand how best to model differential labelling e.g. the N15 file. I think we should view this as similar to searching for different variable mods. For example, if this was an ICAT, we would search for C+ICATlight and C+ICAT heavy within one single search. As such, I don't think it makes sense to separate out an N15 labelling into two different search protocols. I think we should allow multiple mass tables within one SpectrumIdentificationProtocol. The MassTable also will need an id and an optional cv terms to explain the purpose of this particular mass table and perhaps to say if it is monoisotopic or average. We could then add a MassTable_ref to Peptide, documented saying that it is only required if more than one MassTable has been given. If we also have: <FragmentationTable> <Measure id="m_mz"> <pf:cvParam cvRef="PSI-PI" accession="PI:xxxx" name="product ion monoisotopic m/z"/> To say that reported fragment ions are monoisotopic, does this also solve the problem if someone wants to report that precursor ions are average mass and product ions are monoisotopic? Just to be clear however, in SpectrumIdentificationProtocol we have: <SpectrumIdentificationProtocol id="SIP_1" AnalysisSoftware_ref="AS_mascot_server"> <AdditionalSearchParams> ... <pf:cvParam accession="PI:00211" name="mass type setting monoisotopic" cvRef="PSI-PI"/> I didn't understand why we couldn't have two CV terms here for product and precursor mass setting, this is how X!Tandem sets up its searches. Was there something else that I missed here that would stop this working? Cheers Andy |
From: Jones, A. <And...@li...> - 2008-08-08 10:55:37
|
Hi all, I updated the schema in SVN with the addition of the fragmentation ions proposal. The schema is also copied in the example/working8Aug with a sample file. Can people review the example to see if we're happy with it, Cheers Andy |
From: David C. <dc...@ma...> - 2008-08-07 14:38:22
|
Martin Eisenacher wrote: >>>>>> I notice also that there is a small error in the schema in that on PeptideEvidence DBSequence_ref >>>>>> >> should be >> >>>>>> mandatory (and it is missing from the instance docs). I can fix this if there is agreement on this? >>>>>> >>>>> Yes, if <PeptideEvidence> stays optional. >>>>> >>>> What about denovo where there is no database... >>>> >>> That is an argument to have PeptideEvidence optional, isn't it? >>> But DBSequence_ref as attribute of it should be mandatory. >>> >> Doh, sorry, yes you are totally correct. It should be mandatory. >> > Now it is. > ANd next problem: WE have two "Sequence_Ref" attributes, > in <PeptideEvidence> and <ProteinHypothesis> (now both mandatory). > What if they are contradictory (validator?)? > If they are not contradictory, at least the one in <ProteinHypothesis> is redundant. > With current use cases, I think it's always redundant, but I'm trying to think of a case where it wouldn't be. However, since the <ProteinDetectionHypothesis> has to have at least one <PeptideHypothesis>, you must be right. Suggest that we remove the reference from <ProteinHypothesis> > >> >(and it is missing from the instance docs). >> I believe it's in all the Mascot ones? >> > It is. > > >>>>>> It is a database search parameter: >>>>>> <AdditionalSearchParams> >>>>>> <pf:cvParam accession="PRIDE:0000162" name="Mass value type setting monoisotopic" cvRef="PRIDE"/> >>>>>> >>>>> Yes, it is, but in case we have more than one SpectrumIdentification, that could be conflicting. >>>>> http://code.google.com/p/psi-pi/issues/detail?id=37 >>>>> >>>> I'm not sure I understand whether this is OK or not now? (And why use >>>> Pride CV?) >>>> >>> I think the current schema is not okay, because it allows "average" in one SpecIdent and "mono" in >>> >> another, >> >>> so it is not well-defined for the masses in elements or attributes. >>> We need a global attribute :-) or element. Or it can be done later in semantic validation :-( . >>> >> I think it's actually _required_ to be like this. For example, at least >> one search engine allows you to specify mono for masses below x and >> average for masses above x. So, in this case, the output should be >> similar to the N15 example that I've supplied, with two separate mass >> tables. Maybe you could look at the Mascot_N15_example.xml and see if >> you think that this is OK. >> > It is okay with me; to answer Pierre-Alains original question then: > all mass values for peptides then depend on > the type of search performed and the residue table used. ;-) > > Bye > Martin > > > > >> Talk soon, >> >> David >> >> >>> Bye >>> Martin >>> >>> >>> >>>>>>> -----Original Message----- >>>>>>> From: psi...@li... [mailto:psidev-pi-dev- >>>>>>> bo...@li...] On Behalf Of Martin Eisenacher >>>>>>> Sent: 30 July 2008 13:05 >>>>>>> To: 'Pierre-Alain Binz' >>>>>>> Cc: psi...@li... >>>>>>> Subject: Re: [Psidev-pi-dev] FW: Representing Sequences >>>>>>> >>>>>>> Hi Pierre-Alain, quite old posting, but I saw no answer yet, so I will try: >>>>>>> >>>>>>> >>>>>>>> 2nd July, 2008: >>>>>>>> a couple of questions, just to make sure: >>>>>>>> 1) in case of top-down approach, do we have to duplicate sequenceCollection >>>>>>>> >>>>>>> information? >>>>>>> I hope not, by referencing the same identifier. >>>>>>> >>>>>>> >>>>>>>> as SpectrumIdentificationResult contains a PeptideEvidence refering to a Peptide >>>>>>>> >>>>>>> element >>>>>>> >>>>>>>> (and not to a DBSequence), identification is obligatory a Peptide? >>>>>>>> >>>>>>> At the moment I think it's possible to directly reference a DBSeq. At the time the >>>>>>> foreign key definitions are implemented we can forbid that. >>>>>>> But we should have in mind, that a peptide is a sequence plus modifications, so if >>>>>>> top-down >>>>>>> identifies only a sequence, we should allow that and if top-down identifies with >>>>>>> mods, >>>>>>> we should forbid that. >>>>>>> It would be quite helpful to have a top-down instance doc. To check >>>>>>> whether our thoughts are really deep enough... >>>>>>> >>>>>>> >>>>>>>> 2) and what about spectral library searches, do we have to have Peptide >>>>>>>> elements with possibly undefined explicit sequences to refer to >>>>>>>> >>>>>>> >from the SpectrumIdentificationResult (because non peptidic, or because not >>>>>>> identified >>>>>>> >>>>>>>> but good spectrum) >>>>>>>> >>>>>>> At the moment the sequence element can be empty or even left out. >>>>>>> User or CV params are allowed. >>>>>>> How do they report results in spectral lib search if they identify non-peptidic or >>>>>>> unidentified? >>>>>>> We need CV terms for that... >>>>>>> >>>>>>> >>>>>>>> 3) in the Peptide element, the Modifications are defined in a much more >>>>>>>> detailed manner than in ModificationParams (PSI-MOD is there for >>>>>>>> instance). Does this simply mean that The ModificationParams codes >>>>>>>> the search engine settings and the Peptide includes the formal PSI >>>>>>>> definition of the Mod? And the only reference is the ModName value? >>>>>>>> >>>>>>> I think that has changed meanwhile, in the MPC use case I used PSI-MOD terms >>>>>>> for both. If a search engine has its "own" mods, we need CV for that in PSI-PI CV >>>>>>> or >>>>>>> they can define their own. >>>>>>> >>>>>>> >>>>>>>> 4) all mass values (sequenceMass, calculatedMassToCharge, >>>>>>>> >>>>>>> experimentalMassToCharge, >>>>>>> >>>>>>>> are not specified whether monoisotopic or averaged. >>>>>>>> Do we assume that averaged does not exist anymore? >>>>>>>> >>>>>>> No, we decided to have only one type of masses in the whole analysisXML. >>>>>>> But I cannot find a note for that or a schema attribute... I will add an issue for that. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 5) is sequenceMass the mass value with/without the mods? If with, the >>>>>>>> name might be missleading (peptideMass would be more appropriate) >>>>>>>> >>>>>>> It is indeed the mass of the sequence without mods. >>>>>>> THAT is described in http://code.google.com/p/psi-pi/wiki/NotesForFocumentation >>>>>>> >>>>>>> >>>>>>>> 6) in case the DBSequence is nucleotide, is there a tag for saying >>>>>>>> this? (NB: MS on nucleotide molecules can be performed and analysed, >>>>>>>> not only MS on AA sequences that are interpreting nucleotide sequences). >>>>>>>> Or do we neglect MS experiments done on nucleotide molecules (and by >>>>>>>> the way on glycans...) and only represent the DBSequences as AA >>>>>>>> sequences (frame translations)? (and what about glycans?) >>>>>>>> Probaly can be solved if one can replace SequenceCollection by >>>>>>>> something else if needed (SmallMoleculeCollection, GlycanCollection, >>>>>>>> MoleculeCollection)... but the validator might not like this. >>>>>>>> >>>>>>> Mh, these can be extensions, I think they are not possible at the moment. >>>>>>> But a tag for the type can indeed be useful, it could be a CV param. >>>>>>> I will create an issue for that. >>>>>>> >>>>>>> >>>>>>>> 7) in case that DBSequence is nucleotide, do we represent the >>>>>>>> Peptide as AA sequence in case of MS done on proteins? >>>>>>>> >>>>>>> I hope the following answers this: >>>>>>> >>>>>>> <DBSequence> is the nucleotide seq from the nucleotide DB, >>>>>>> <Peptide> is the identified amino acid sequence plus mods (without any translation >>>>>>> frame or something). >>>>>>> <PeptideEvidence> contains the DBSequence_Ref together with a frame and a >>>>>>> TranslationTable_Ref attribute. >>>>>>> (The Peptide_Ref is done in SpectrumIdentificationItem as in the amino acid DB >>>>>>> case.) >>>>>>> If a protein detection is performed, there are <PeptideHypothesis> elements >>>>>>> referencing >>>>>>> PeptideEvidence elements from SpectrumIdentificationItem sections. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bye >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> David Creasy wrote: >>>>>>> Thanks Andy, >>>>>>> >>>>>>> I've added an updated example document to SVN: >>>>>>> http://code.google.com/p/psi- >>>>>>> pi/source/browse/trunk/examples/schema_usecase_examples/working27June/F00 >>>>>>> 1350.xml >>>>>>> >>>>>>> Problem is that we have now removed the main point of these recent changes >>>>>>> which was to add the decoy flag... I think >>>>>>> that we need to add isDecoy to SpectrumIdentificationItem. >>>>>>> >>>>>>> And yes, I suspect that we should go back to using the >>>>>>> ConceptualMoleculeCollection >>>>>>> Um, and since we've not actually ended up adding anything to DBSequence... we >>>>>>> haven't actually achieved anything? >>>>>>> I think we need to discuss this again at the next telecon. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> Jones, Andy wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I’ve updated the schema in SVN with the following main changes: >>>>>>> >>>>>>> PeptideEvidence is now part of SpectrumIdentificationItem as discussed on the >>>>>>> call (simple mappings to proteins are done >>>>>>> at this level) >>>>>>> Added DBSequence that should be used instead of Sequence (following some of >>>>>>> the discussion below) >>>>>>> Created a new collection class SequenceCollection (rather than >>>>>>> ConceptualMoleculeCollection) so that only references can >>>>>>> be given to DBSequence and Peptide >>>>>>> In fact, I’m not sure if this is sensible since it prevents other types of >>>>>>> ConceptualMolecule being added later... to >>>>>>> discuss >>>>>>> In FuGE on cvParam, the value attribute is no longer mandatory >>>>>>> >>>>>>> I’ve added a simple example that validates under >>>>>>> examples\schema_usecase_examples\working27June >>>>>>> >>>>>>> Feel free to mail me any changes to make on Monday, >>>>>>> Cheers >>>>>>> Andy >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: psi...@li... [mailto:psidev-pi-dev- >>>>>>> bo...@li...] On Behalf Of >>>>>>> Jones, Andy >>>>>>> Sent: 27 June 2008 16:24 >>>>>>> To: Angel Pizarro >>>>>>> Cc: psi...@li... >>>>>>> Subject: Re: [Psidev-pi-dev] FW: Representing Sequences >>>>>>> >>>>>>> I think Angel’s response below might not have made it round the list yet. >>>>>>> >>>>>>> I tend to agree that isDecoy is redundant information and perhaps this is not the >>>>>>> best place to encode semantic >>>>>>> information. An alternative would be to have a parameter, say on >>>>>>> SpectrumIdentification for cvParam = “decoy_string” >>>>>>> value = “Rev”. This would be a more compact representation and we would not >>>>>>> have to add what is quite a specific >>>>>>> attribute type (isDecoy) to Sequence. >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: an...@it... [mailto:an...@it...] On Behalf Of Angel >>>>>>> Pizarro >>>>>>> Sent: 27 June 2008 15:59 >>>>>>> To: Jones, Andy >>>>>>> Cc: psi...@li... >>>>>>> Subject: Re: [Psidev-pi-dev] FW: Representing Sequences >>>>>>> >>>>>>> my 2¢ : >>>>>>> You need to be able to extend this to all molecule types, or am I missing the point >>>>>>> of this thread, and you mean that >>>>>>> this would be a suclass of the conceptual molecule element? >>>>>>> >>>>>>> Second, and this is is tangentially related, but are decoy sequences really a >>>>>>> problem we should be putting our effort >>>>>>> into? Is it in our domain to encode semantic information about a sequence, and >>>>>>> possibly relating reported sequences as >>>>>>> part of our schema? >>>>>>> On a personal level I could care less if "isDecoy" is an attribute or not, but the >>>>>>> temptation then would be for folks to >>>>>>> encode the same accession for two different sequences, effectively making the >>>>>>> primary key of the sequence object >>>>>>> (accession, isDecoy) >>>>>>> >>>>>>> >>>>>>> Do we want to go there? >>>>>>> On Fri, Jun 27, 2008 at 10:21 AM, Jones, Andy <And...@li...> >>>>>>> wrote: >>>>>>> So how about include length as an attribute and then let all other things go in the >>>>>>> CV (pI, mass, etc.)? >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Jones, Andy >>>>>>> Sent: 27 June 2008 14:54 >>>>>>> To: 'David Creasy' >>>>>>> Subject: RE: [Psidev-pi-dev] Representing Sequences >>>>>>> >>>>>>> id and name are standard for all elements that inherit from FuGE identifiable – this >>>>>>> is perhaps a separate discussion as >>>>>>> to whether the optional name attribute should be there. >>>>>>> >>>>>>> I agree that length may be useful – is this just an integer value with no unit? >>>>>>> Yes, I think so. >>>>>>> I'm less sure about pI and mass since mass at least can be calculated very simply >>>>>>> Only if you have the sequence... (we have residue masses in the file). >>>>>>> >>>>>>> >>>>>>> , and pI values (in my opinion) are pretty inaccurate and fairly meaningless >>>>>>> Scandalous! (I happen to agree, but now some people will never speak to either of >>>>>>> us ever again). >>>>>>> >>>>>>> The main problem with mass and pI is that these are 'irrelevant' if the sequence is >>>>>>> nuleic acid rather than residues. >>>>>>> Why not just allow CV there? We can share the same CV as the PEFF format, >>>>>>> which includes, taxonomy, sequence type, gene >>>>>>> ID, and lots of wonderful other things? >>>>>>> >>>>>>> >>>>>>> – unless someone can convince me otherwise? >>>>>>> Cheers >>>>>>> Andy >>>>>>> >>>>>>> >>>>>>> From: David Creasy [mailto:dc...@ma...] >>>>>>> Sent: 27 June 2008 14:51 >>>>>>> To: Jones, Andy >>>>>>> Cc: psi...@li... >>>>>>> Subject: Re: [Psidev-pi-dev] Representing Sequences >>>>>>> >>>>>>> Hi Andy, >>>>>>> >>>>>>> length may be useful, because some people won't want to output the actual >>>>>>> sequence for space reasons. The other things >>>>>>> we wanted to add before were pI and mass. >>>>>>> Why do we want name? Is this for, say, a description line? >>>>>>> (Also, identifier -> id?) >>>>>>> >>>>>>> David >>>>>>> >>>>>>> Jones, Andy wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> It was decided on the call that we would like to flag that Sequences in the >>>>>>> ConceptualMoleculeCollection should have a >>>>>>> Boolean attribute to capture if they are decoy sequences. At the moment we are >>>>>>> using the FuGE:Sequence element. I don't >>>>>>> really want to add another attribute to this (it's less problematic cutting down FuGE >>>>>>> than adding new things), so I'm >>>>>>> wondering if we should define our own Sequence type in AnalysisXML. This >>>>>>> would also allow us to choose exactly the >>>>>>> relevant attributes. At the moment, Sequence can have all of the following: >>>>>>> >>>>>>> <pf:Sequence isCircular="true" sequence="String" length="0" >>>>>>> isApproximateLength="true" >>>>>>> SequenceAnnotationSet_ref="String" start="0" end="0" identifier="String" >>>>>>> name="String"> >>>>>>> >>>>>>> Several of these attributes were created to represent concepts that probably will >>>>>>> never be required or implemented in >>>>>>> AnalysisXML. How about the following: >>>>>>> >>>>>>> <DBSequence identifier = "" name = "" isDecoy = "true"> >>>>>>> <seq>MCTMG...</seq> >>>>>>> <pf:DatabaseReference Database_ref="" >>>>>>> accession="Rev_IPI00013808.1"/> >>>>>>> </DBSequence> >>>>>>> >>>>>>> Are any of the other attributes on Sequence actually required? I'll post a new >>>>>>> version of the schema with other changes >>>>>>> WRT to PeptideEvidence shortly, >>>>>>> Cheers >>>>>>> Andy >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> Check out the new SourceForge.net Marketplace. >>>>>>> It's the best place to buy or sell services for >>>>>>> just about anything Open Source. >>>>>>> http://sourceforge.net/services/buy/index.php >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> Check out the new SourceForge.net Marketplace. >>>>>>> It's the best place to buy or sell services for >>>>>>> just about anything Open Source. >>>>>>> http://sourceforge.net/services/buy/index.php >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> Check out the new SourceForge.net Marketplace. >>>>>>> It's the best place to buy or sell services for >>>>>>> just about anything Open Source. >>>>>>> http://sourceforge.net/services/buy/index.php >>>>>>> _______________________________________________ >>>>>>> Psidev-pi-dev mailing list >>>>>>> Psi...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Angel Pizarro >>>>>>> Director, ITMAT Bioinformatics Facility >>>>>>> 806 Biological Research Building >>>>>>> 421 Curie Blvd. >>>>>>> Philadelphia, PA 19104-6160 >>>>>>> 215-573-3736 >>>>>>> ________________________________________ >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> Check out the new SourceForge.net Marketplace. >>>>>>> It's the best place to buy or sell services for >>>>>>> just about anything Open Source. >>>>>>> http://sourceforge.net/services/buy/index.php >>>>>>> ________________________________________ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> Check out the new SourceForge.net Marketplace. >>>>>>> It's the best place to buy or sell services for >>>>>>> just about anything Open Source. >>>>>>> http://sourceforge.net/services/buy/index.php >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>> ------------------------------------------------------------------------- >>>>> 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 >>>> >> -- >> 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 >> > > -- 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 |
From: Martin E. <mar...@ru...> - 2008-08-07 14:23:03
|
Yes, agree, no chance to do it in a sensible way with mods (as I see now)... > -----Ursprüngliche Nachricht----- > Von: David Creasy [mailto:dc...@ma...] > Gesendet: Thursday, August 07, 2008 4:04 PM > An: Martin Eisenacher > Cc: 'Angel Pizarro'; psi...@li... > Betreff: Re: AW: [Psidev-pi-dev] Added an example for N15 labelling > > Hi Martin, Angel, > > The use of 15N (or other metabolic labelling) isn't really a > modification. We'd have to duplicate every nitrogen containing > modification in PSI-MOD - once with standard 14N and once with 15N. > And then maybe the same for 13C... > > David > > > Martin Eisenacher wrote: > >>> This seems to work pretty well (as expected!!) > >>> The interesting thing is that there are two sets of residue masses, two > >>> SpectrumIdentificationList (one for light, one for heavy) but just one > >>> ProteinDetectionList. > > At first glance I thought it would be better to have one residue mass list > > and a modification for N15 (see below). But I saw it was a bad solution. > > > > It indeed works like you modeled it, because we don't report any masses > > for DBSequences or Proteins. > > > > > >>> And (possibly confusing at first glance!) unmodified peptides with > >>> different masses like this: > >>> > >>> <Peptide id="peptide_48_1" sequenceMass="1025.481796" > > >>> <peptideSequence>STNLDWYK</peptideSequence> > >>> </Peptide> > >>> > >>> <Peptide id="peptide_53_1" sequenceMass="1036.449188"> > >>> <peptideSequence>STNLDWYK</peptideSequence> > >>> </Peptide> > >> I think this is where I come in with the mod specifications for > >> peptide results. I'll try and add this as an example to issue 35 > > It could be possible in the current schema with the CustomModification element. > > But that should be "extended" to report "elements" (N, C, O) instead > > of "locations". > > Or PSI-MOD has to include "N15 mod of amino acid X" with the respective mass > > or delta mass, which maybe there already. But that would be quite verbose. > > > > Bye > > Martin > > > > -- > 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 |
From: Martin E. <mar...@ru...> - 2008-08-07 14:17:30
|
> >>>> I notice also that there is a small error in the schema in that on PeptideEvidence DBSequence_ref > should be > >>>> mandatory (and it is missing from the instance docs). I can fix this if there is agreement on this? > >>> Yes, if <PeptideEvidence> stays optional. > >> What about denovo where there is no database... > > That is an argument to have PeptideEvidence optional, isn't it? > > But DBSequence_ref as attribute of it should be mandatory. > Doh, sorry, yes you are totally correct. It should be mandatory. Now it is. ANd next problem: WE have two "Sequence_Ref" attributes, in <PeptideEvidence> and <ProteinHypothesis> (now both mandatory). What if they are contradictory (validator?)? If they are not contradictory, at least the one in <ProteinHypothesis> is redundant. > >(and it is missing from the instance docs). > I believe it's in all the Mascot ones? It is. > >>>> It is a database search parameter: > >>>> <AdditionalSearchParams> > >>>> <pf:cvParam accession="PRIDE:0000162" name="Mass value type setting monoisotopic" cvRef="PRIDE"/> > >>> Yes, it is, but in case we have more than one SpectrumIdentification, that could be conflicting. > >>> http://code.google.com/p/psi-pi/issues/detail?id=37 > >> I'm not sure I understand whether this is OK or not now? (And why use > >> Pride CV?) > > I think the current schema is not okay, because it allows "average" in one SpecIdent and "mono" in > another, > > so it is not well-defined for the masses in elements or attributes. > > We need a global attribute :-) or element. Or it can be done later in semantic validation :-( . > I think it's actually _required_ to be like this. For example, at least > one search engine allows you to specify mono for masses below x and > average for masses above x. So, in this case, the output should be > similar to the N15 example that I've supplied, with two separate mass > tables. Maybe you could look at the Mascot_N15_example.xml and see if > you think that this is OK. It is okay with me; to answer Pierre-Alains original question then: all mass values for peptides then depend on the type of search performed and the residue table used. ;-) Bye Martin > Talk soon, > > David > > > > > Bye > > Martin > > > > > >>>>> -----Original Message----- > >>>>> From: psi...@li... [mailto:psidev-pi-dev- > >>>>> bo...@li...] On Behalf Of Martin Eisenacher > >>>>> Sent: 30 July 2008 13:05 > >>>>> To: 'Pierre-Alain Binz' > >>>>> Cc: psi...@li... > >>>>> Subject: Re: [Psidev-pi-dev] FW: Representing Sequences > >>>>> > >>>>> Hi Pierre-Alain, quite old posting, but I saw no answer yet, so I will try: > >>>>> > >>>>>> 2nd July, 2008: > >>>>>> a couple of questions, just to make sure: > >>>>>> 1) in case of top-down approach, do we have to duplicate sequenceCollection > >>>>> information? > >>>>> I hope not, by referencing the same identifier. > >>>>> > >>>>>> as SpectrumIdentificationResult contains a PeptideEvidence refering to a Peptide > >>>>> element > >>>>>> (and not to a DBSequence), identification is obligatory a Peptide? > >>>>> At the moment I think it's possible to directly reference a DBSeq. At the time the > >>>>> foreign key definitions are implemented we can forbid that. > >>>>> But we should have in mind, that a peptide is a sequence plus modifications, so if > >>>>> top-down > >>>>> identifies only a sequence, we should allow that and if top-down identifies with > >>>>> mods, > >>>>> we should forbid that. > >>>>> It would be quite helpful to have a top-down instance doc. To check > >>>>> whether our thoughts are really deep enough... > >>>>> > >>>>>> 2) and what about spectral library searches, do we have to have Peptide > >>>>>> elements with possibly undefined explicit sequences to refer to > >>>>> >from the SpectrumIdentificationResult (because non peptidic, or because not > >>>>> identified > >>>>>> but good spectrum) > >>>>> At the moment the sequence element can be empty or even left out. > >>>>> User or CV params are allowed. > >>>>> How do they report results in spectral lib search if they identify non-peptidic or > >>>>> unidentified? > >>>>> We need CV terms for that... > >>>>> > >>>>>> 3) in the Peptide element, the Modifications are defined in a much more > >>>>>> detailed manner than in ModificationParams (PSI-MOD is there for > >>>>>> instance). Does this simply mean that The ModificationParams codes > >>>>>> the search engine settings and the Peptide includes the formal PSI > >>>>>> definition of the Mod? And the only reference is the ModName value? > >>>>> I think that has changed meanwhile, in the MPC use case I used PSI-MOD terms > >>>>> for both. If a search engine has its "own" mods, we need CV for that in PSI-PI CV > >>>>> or > >>>>> they can define their own. > >>>>> > >>>>>> 4) all mass values (sequenceMass, calculatedMassToCharge, > >>>>> experimentalMassToCharge, > >>>>>> are not specified whether monoisotopic or averaged. > >>>>>> Do we assume that averaged does not exist anymore? > >>>>> No, we decided to have only one type of masses in the whole analysisXML. > >>>>> But I cannot find a note for that or a schema attribute... I will add an issue for that. > >>>>> > >>>>> > >>>>>> 5) is sequenceMass the mass value with/without the mods? If with, the > >>>>>> name might be missleading (peptideMass would be more appropriate) > >>>>> It is indeed the mass of the sequence without mods. > >>>>> THAT is described in http://code.google.com/p/psi-pi/wiki/NotesForFocumentation > >>>>> > >>>>>> 6) in case the DBSequence is nucleotide, is there a tag for saying > >>>>>> this? (NB: MS on nucleotide molecules can be performed and analysed, > >>>>>> not only MS on AA sequences that are interpreting nucleotide sequences). > >>>>>> Or do we neglect MS experiments done on nucleotide molecules (and by > >>>>>> the way on glycans...) and only represent the DBSequences as AA > >>>>>> sequences (frame translations)? (and what about glycans?) > >>>>>> Probaly can be solved if one can replace SequenceCollection by > >>>>>> something else if needed (SmallMoleculeCollection, GlycanCollection, > >>>>>> MoleculeCollection)... but the validator might not like this. > >>>>> Mh, these can be extensions, I think they are not possible at the moment. > >>>>> But a tag for the type can indeed be useful, it could be a CV param. > >>>>> I will create an issue for that. > >>>>> > >>>>>> 7) in case that DBSequence is nucleotide, do we represent the > >>>>>> Peptide as AA sequence in case of MS done on proteins? > >>>>> I hope the following answers this: > >>>>> > >>>>> <DBSequence> is the nucleotide seq from the nucleotide DB, > >>>>> <Peptide> is the identified amino acid sequence plus mods (without any translation > >>>>> frame or something). > >>>>> <PeptideEvidence> contains the DBSequence_Ref together with a frame and a > >>>>> TranslationTable_Ref attribute. > >>>>> (The Peptide_Ref is done in SpectrumIdentificationItem as in the amino acid DB > >>>>> case.) > >>>>> If a protein detection is performed, there are <PeptideHypothesis> elements > >>>>> referencing > >>>>> PeptideEvidence elements from SpectrumIdentificationItem sections. > >>>>> > >>>>> > >>>>> > >>>>> Bye > >>>>> Martin > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> David Creasy wrote: > >>>>> Thanks Andy, > >>>>> > >>>>> I've added an updated example document to SVN: > >>>>> http://code.google.com/p/psi- > >>>>> pi/source/browse/trunk/examples/schema_usecase_examples/working27June/F00 > >>>>> 1350.xml > >>>>> > >>>>> Problem is that we have now removed the main point of these recent changes > >>>>> which was to add the decoy flag... I think > >>>>> that we need to add isDecoy to SpectrumIdentificationItem. > >>>>> > >>>>> And yes, I suspect that we should go back to using the > >>>>> ConceptualMoleculeCollection > >>>>> Um, and since we've not actually ended up adding anything to DBSequence... we > >>>>> haven't actually achieved anything? > >>>>> I think we need to discuss this again at the next telecon. > >>>>> > >>>>> David > >>>>> > >>>>> Jones, Andy wrote: > >>>>> Hi all, > >>>>> > >>>>> Ive updated the schema in SVN with the following main changes: > >>>>> > >>>>> PeptideEvidence is now part of SpectrumIdentificationItem as discussed on the > >>>>> call (simple mappings to proteins are done > >>>>> at this level) > >>>>> Added DBSequence that should be used instead of Sequence (following some of > >>>>> the discussion below) > >>>>> Created a new collection class SequenceCollection (rather than > >>>>> ConceptualMoleculeCollection) so that only references can > >>>>> be given to DBSequence and Peptide > >>>>> In fact, Im not sure if this is sensible since it prevents other types of > >>>>> ConceptualMolecule being added later... to > >>>>> discuss > >>>>> In FuGE on cvParam, the value attribute is no longer mandatory > >>>>> > >>>>> Ive added a simple example that validates under > >>>>> examples\schema_usecase_examples\working27June > >>>>> > >>>>> Feel free to mail me any changes to make on Monday, > >>>>> Cheers > >>>>> Andy > >>>>> > >>>>> > >>>>> > >>>>> From: psi...@li... [mailto:psidev-pi-dev- > >>>>> bo...@li...] On Behalf Of > >>>>> Jones, Andy > >>>>> Sent: 27 June 2008 16:24 > >>>>> To: Angel Pizarro > >>>>> Cc: psi...@li... > >>>>> Subject: Re: [Psidev-pi-dev] FW: Representing Sequences > >>>>> > >>>>> I think Angels response below might not have made it round the list yet. > >>>>> > >>>>> I tend to agree that isDecoy is redundant information and perhaps this is not the > >>>>> best place to encode semantic > >>>>> information. An alternative would be to have a parameter, say on > >>>>> SpectrumIdentification for cvParam = decoy_string > >>>>> value = Rev. This would be a more compact representation and we would not > >>>>> have to add what is quite a specific > >>>>> attribute type (isDecoy) to Sequence. > >>>>> > >>>>> > >>>>> > >>>>> From: an...@it... [mailto:an...@it...] On Behalf Of Angel > >>>>> Pizarro > >>>>> Sent: 27 June 2008 15:59 > >>>>> To: Jones, Andy > >>>>> Cc: psi...@li... > >>>>> Subject: Re: [Psidev-pi-dev] FW: Representing Sequences > >>>>> > >>>>> my 2¢ : > >>>>> You need to be able to extend this to all molecule types, or am I missing the point > >>>>> of this thread, and you mean that > >>>>> this would be a suclass of the conceptual molecule element? > >>>>> > >>>>> Second, and this is is tangentially related, but are decoy sequences really a > >>>>> problem we should be putting our effort > >>>>> into? Is it in our domain to encode semantic information about a sequence, and > >>>>> possibly relating reported sequences as > >>>>> part of our schema? > >>>>> On a personal level I could care less if "isDecoy" is an attribute or not, but the > >>>>> temptation then would be for folks to > >>>>> encode the same accession for two different sequences, effectively making the > >>>>> primary key of the sequence object > >>>>> (accession, isDecoy) > >>>>> > >>>>> > >>>>> Do we want to go there? > >>>>> On Fri, Jun 27, 2008 at 10:21 AM, Jones, Andy <And...@li...> > >>>>> wrote: > >>>>> So how about include length as an attribute and then let all other things go in the > >>>>> CV (pI, mass, etc.)? > >>>>> > >>>>> > >>>>> > >>>>> From: Jones, Andy > >>>>> Sent: 27 June 2008 14:54 > >>>>> To: 'David Creasy' > >>>>> Subject: RE: [Psidev-pi-dev] Representing Sequences > >>>>> > >>>>> id and name are standard for all elements that inherit from FuGE identifiable this > >>>>> is perhaps a separate discussion as > >>>>> to whether the optional name attribute should be there. > >>>>> > >>>>> I agree that length may be useful is this just an integer value with no unit? > >>>>> Yes, I think so. > >>>>> I'm less sure about pI and mass since mass at least can be calculated very simply > >>>>> Only if you have the sequence... (we have residue masses in the file). > >>>>> > >>>>> > >>>>> , and pI values (in my opinion) are pretty inaccurate and fairly meaningless > >>>>> Scandalous! (I happen to agree, but now some people will never speak to either of > >>>>> us ever again). > >>>>> > >>>>> The main problem with mass and pI is that these are 'irrelevant' if the sequence is > >>>>> nuleic acid rather than residues. > >>>>> Why not just allow CV there? We can share the same CV as the PEFF format, > >>>>> which includes, taxonomy, sequence type, gene > >>>>> ID, and lots of wonderful other things? > >>>>> > >>>>> > >>>>> unless someone can convince me otherwise? > >>>>> Cheers > >>>>> Andy > >>>>> > >>>>> > >>>>> From: David Creasy [mailto:dc...@ma...] > >>>>> Sent: 27 June 2008 14:51 > >>>>> To: Jones, Andy > >>>>> Cc: psi...@li... > >>>>> Subject: Re: [Psidev-pi-dev] Representing Sequences > >>>>> > >>>>> Hi Andy, > >>>>> > >>>>> length may be useful, because some people won't want to output the actual > >>>>> sequence for space reasons. The other things > >>>>> we wanted to add before were pI and mass. > >>>>> Why do we want name? Is this for, say, a description line? > >>>>> (Also, identifier -> id?) > >>>>> > >>>>> David > >>>>> > >>>>> Jones, Andy wrote: > >>>>> Hi all, > >>>>> > >>>>> It was decided on the call that we would like to flag that Sequences in the > >>>>> ConceptualMoleculeCollection should have a > >>>>> Boolean attribute to capture if they are decoy sequences. At the moment we are > >>>>> using the FuGE:Sequence element. I don't > >>>>> really want to add another attribute to this (it's less problematic cutting down FuGE > >>>>> than adding new things), so I'm > >>>>> wondering if we should define our own Sequence type in AnalysisXML. This > >>>>> would also allow us to choose exactly the > >>>>> relevant attributes. At the moment, Sequence can have all of the following: > >>>>> > >>>>> <pf:Sequence isCircular="true" sequence="String" length="0" > >>>>> isApproximateLength="true" > >>>>> SequenceAnnotationSet_ref="String" start="0" end="0" identifier="String" > >>>>> name="String"> > >>>>> > >>>>> Several of these attributes were created to represent concepts that probably will > >>>>> never be required or implemented in > >>>>> AnalysisXML. How about the following: > >>>>> > >>>>> <DBSequence identifier = "" name = "" isDecoy = "true"> > >>>>> <seq>MCTMG...</seq> > >>>>> <pf:DatabaseReference Database_ref="" > >>>>> accession="Rev_IPI00013808.1"/> > >>>>> </DBSequence> > >>>>> > >>>>> Are any of the other attributes on Sequence actually required? I'll post a new > >>>>> version of the schema with other changes > >>>>> WRT to PeptideEvidence shortly, > >>>>> Cheers > >>>>> Andy > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------------- > >>>>> Check out the new SourceForge.net Marketplace. > >>>>> It's the best place to buy or sell services for > >>>>> just about anything Open Source. > >>>>> http://sourceforge.net/services/buy/index.php > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------------- > >>>>> Check out the new SourceForge.net Marketplace. > >>>>> It's the best place to buy or sell services for > >>>>> just about anything Open Source. > >>>>> http://sourceforge.net/services/buy/index.php > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>>> > >>>>> ------------------------------------------------------------------------- > >>>>> Check out the new SourceForge.net Marketplace. > >>>>> It's the best place to buy or sell services for > >>>>> just about anything Open Source. > >>>>> http://sourceforge.net/services/buy/index.php > >>>>> _______________________________________________ > >>>>> Psidev-pi-dev mailing list > >>>>> Psi...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Angel Pizarro > >>>>> Director, ITMAT Bioinformatics Facility > >>>>> 806 Biological Research Building > >>>>> 421 Curie Blvd. > >>>>> Philadelphia, PA 19104-6160 > >>>>> 215-573-3736 > >>>>> ________________________________________ > >>>>> > >>>>> ------------------------------------------------------------------------- > >>>>> Check out the new SourceForge.net Marketplace. > >>>>> It's the best place to buy or sell services for > >>>>> just about anything Open Source. > >>>>> http://sourceforge.net/services/buy/index.php > >>>>> ________________________________________ > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> ------------------------------------------------------------------------- > >>>>> Check out the new SourceForge.net Marketplace. > >>>>> It's the best place to buy or sell services for > >>>>> just about anything Open Source. > >>>>> http://sourceforge.net/services/buy/index.php > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> ------------------------------------------------------------------------- > >>> 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 > > > > -- > 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 |