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: <cod...@go...> - 2009-04-29 06:17:20
|
Updates: Status: Fixed Labels: -Milestone-Release1.0 Milestone-Release2.0 Comment #3 on issue 27 by eisenachM: Tidy up the schema http://code.google.com/p/psi-pi/issues/detail?id=27 At the moment leave it as it is. May be done later, if programmers request it. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
From: David C. <dc...@ma...> - 2009-04-24 13:15:15
|
Better late than never... PSI-PI group sessions in Turku next week. Most of the time at the meeting in Turku will be spent planning and designing the quantitation support for version 2 of AnalysisXML. However, we have a few short talks scheduled: Monday 27th April ----------------- 14:30 - 17:30 Introduction and status of AnalysisXML - David Creasy Overview of version 1 schema - Andy Jones Example instance documents - Martin Eisenacher Description of CV and validation tools - Andreas Bertsch We've only received minimal feedback from the public review process for version 1.0 of AnalysisXML, so this is a good opportunity to ensure further review. Suggest we split into groups for a final review of the different deliverables: http://psidev.info/index.php?q=node/319#deliverablequicklinks An additional benefit of this review is that it will help bring us all up to speed and ready to contribute towards the quantitation design. Use cases for quantitation support - whole group. Tuesday 28 April ---------------- 09:00 - 13:00 PSI-MOD - Luisa Montecchi (PSI-MOD is not currently used by AnalysisXML, but we would like this to be possible. Discussion of issues and possible solutions.) Small groups for design of quantitation support in AnalysisXML 14:30 - 16:00 Sequence database issues for search results - Kyung-Hoon Kwon PEFF - discussion lead by Eugene Kapp, Pierre-Alain Binz http://psidev.info/index.php?q=node/317 http://psidev.info/index.php?q=node/363 Wednesday 29 April ------------------ 09:00 - 13:00 Small groups for design of quantitation support in AnalysisXML 17:00 - 18:30 Wrap up We can of course be very flexible with how we use the time. Finally, for those attending, there's a handy guide of useful phrases here ;) http://www.kisa.ca/finnish-phrases.html -- 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: Garry C. <gar...@bt...> - 2009-04-06 22:36:18
|
Dear Colleagues, I am writing to you to bring to your attention the upcoming HUPO Proteomics Standards Initiative (PSI) meeting that will be held in Turku at the end of this month. The HUPO-PSI defines community standards for data representation in proteomics to facilitate data comparison, exchange and verification. Details about the activities and impact of HUPO-PSI can be found, for example, in numerous publications (see, http://www.psidev.info/index.php?q=node/93). For this years meeting we also warmly welcome you to the Second HUPO Joint PSI/Publication Committee workshop which will commence on day prior to the HUPO-PSI meeting on Sunday 26th April. The annual HUPO- PSI Spring Meeting will be held from 27-29th April, immediately following the Joint PSI/Publication Committee workshop. Registration is still open to the meeting and all are welcome to attend. For catering purposes will need to know exact numbers on attendance and strongly encourage you to make your registration for the meeting before 15 April. For a link to the registration page see below. Meeting Agenda April 26 The Second HUPO Joint PSI/Publication Committee workshop, Sunday 26th April April 27-29 HUPO-PSI Spring Meeting 2009 April 30 Vappu! http://en.wikipedia.org/wiki/Walpurgis_Night#Finland Important URLs General information http://www.psidev.info/index.php?q=node/333 Meeting program http://www.psidev.info/files/TurkuAgenda-1.pdf Registration http://www.psidev.info/index.php?q=node/309 Hotel Use the booking code "HUPO-PSI". Please contact: res...@ra... The impact and success of the HUPO-PSI has to a great extent been facilitated by participation and discussions at the meetings, and this year will likely be no different. Therefore, you are welcome to contribute and join us in Turku! The HUPO-PSI local organising committee, Katri Kaunismaa Anne Rokka Eliza Ralph Garry Corthals -- Turku Centre for Biotechnology University of Turku & Åbo Akademi University Tykistökatu 6, 20521 Turku, Finland t +358 23338889 | f +358 23338000 | HUPO-PSI Contact kat...@bt... P Save Paper - Do you really need to print this e-mail? |
From: Jones, A. <And...@li...> - 2009-03-02 09:36:47
|
Hi all, In case this message from Norman doesn't reach you via the announcements mailing list, AnalysisXML is now in the public comment phase of the document process. Please distribute the link to any colleagues who may be interested in commenting on the specifications - once it gets passed the next stage, the specifications will be fixed at version 1! Cheers Andy > -----Original Message----- > From: Norman Paton [mailto:no...@cs...] > Sent: 27 February 2009 18:06 > To: psi...@li... > Subject: [Psidev-announce] AnalysisXML Enters Public Comment > > > The "AnalysisXML: exchange format for peptides and proteins identified > from mass spectra" is now available for Public Comment on the PSI Web > site at: > > http://www.psidev.info/index.php?q=node/403 > > The public comment period enables the wider community to provide feedback on a > proposed standard before it is formally accepted, and thus is an important step in > the standardisation process. > > This message is to encourage you to contribute to the standards development > activity by commenting on the material that is available online. We invite both > positive and negative comments. If negative comments are being made, these > could be on the relevance, clarity, correctness, appropriateness, etc, of the > proposal as a whole or of specific parts of the proposal. > > If you do not feel well placed to comment on this document, but know someone > who may be, please consider forwarding this request. There is no requirement that > people commenting should have had any prior contact with the PSI. > > If you have comments that you would like to make but would prefer not to make > public, please email these to me directly. > > Regards, > > Norman Paton > PSI Editor > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Psidev-announce mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-announce |
From: Andreas B. <be...@in...> - 2009-02-18 16:23:18
|
Hi all, we had this discussion in may and the majority voted for *.axml. See http://code.google.com/p/psi-pi/issues/detail?id=20&can=1 for documentation. I do not see any reason why to reopen this task, as long as the name of the format does not change. Cheers, A. -- Div. for Simulation of Biological Systems, WSI, University of Tuebingen Room C322, Sand 14, 72076 Tuebingen, Germany phone: +49-7071-29-70461 fax: +49-7071-29-5152 http://www-bs.informatik.uni-tuebingen.de |
From: Matthew C. <mat...@va...> - 2009-02-18 16:16:25
|
I definitely recommend against using .xml - anybody who does file management using standard tools will know why. You can only tell what an XML file is by looking inside, and that's just not cool if all you want to do is "delete all analysisXML files but not mzML files". AnalysisXML is amusingly generic, but survivable. :) -Matt Pierre-Alain Binz wrote: > Either analysisXML or possibly xml as generic (but less preferred). > > For mzML the extension is ... mzML (maybe we'll get the same comment > from the SG). > but mzXML has also ... mzXML > > I am a bit reluctant to invent a name for an extension that has > nothing to do with the standard name. > > Pierre-Alain > > > Chris Taylor wrote: >> Hmm. >> >> There's a PIML, but the project behind it is dead... >> >> And anyway I worked for a couple of years with PEDRo and Pedro, >> which were a data model and a software tool respectively. >> Case over-sensitivity anyone? >> >> PIML... (bottom): >> http://staff.vbi.vt.edu/pathport//pathinfo/#format >> >> ...is most likely dead or dying: >> http://pathport.vbi.vt.edu/main/home.php >> >> Anyway, was just a thought. >> >> Cheers, Chris. >> >> >> Chris Taylor wrote: >> >>> Is 'piML' too obvious..? >>> >>> Perhaps it exlcludes a wider potential user base though -- lipid >>> / sugar / nucleotide / metabolite people, etc.? >>> >>> C. >>> >>> >>> cod...@go... wrote: >>> >>>> Updates: >>>> Labels: Milestone-Release2.0 >>>> >>>> Comment #3 on issue 47 by eisenachM: The name of AnalysisXML >>>> http://code.google.com/p/psi-pi/issues/detail?id=47 >>>> >>>> minor comment from SG during DocProc: >>>> "File extension. It seems more appropriate to use '.xml'." >>>> >>>> ACTION: For discussion, pros / cons of having a specific file extension? >>>> Since this >>>> was agreed by the PSI-PI working group I think it is our decision to take. >>>> >>>> >>>> -- >>>> You received this message because you are listed in the owner >>>> or CC fields of this issue, or because you starred this issue. >>>> You may adjust your issue notification preferences at: >>>> http://code.google.com/hosting/settings >>>> >>>> ------------------------------------------------------------------------------ >>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>> -Strategies to boost innovation and cut costs with open source participation >>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>> http://p.sf.net/sfu/XcvMzF8H >>>> _______________________________________________ >>>> Psidev-pi-dev mailing list >>>> Psi...@li... >>>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev >>>> >>>> >> >> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ------------------------------------------------------------------------ > > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > |
From: Martin E. <mar...@ru...> - 2009-02-18 16:11:10
|
"piml" has funny connotations in german... > -----Ursprüngliche Nachricht----- > Von: Chris Taylor [mailto:chr...@eb...] > Gesendet: Wednesday, February 18, 2009 4:41 PM > An: PSI PI Dev > Betreff: Re: [Psidev-pi-dev] Issue 47 in psi-pi: The name of AnalysisXML > > Hmm. > > There's a PIML, but the project behind it is dead... > > And anyway I worked for a couple of years with PEDRo and Pedro, > which were a data model and a software tool respectively. > Case over-sensitivity anyone? > > PIML... (bottom): > http://staff.vbi.vt.edu/pathport//pathinfo/#format > > ...is most likely dead or dying: > http://pathport.vbi.vt.edu/main/home.php > > Anyway, was just a thought. > > Cheers, Chris. > > > Chris Taylor wrote: > > Is 'piML' too obvious..? > > > > Perhaps it exlcludes a wider potential user base though -- lipid > > / sugar / nucleotide / metabolite people, etc.? > > > > C. > > > > > > cod...@go... wrote: > >> Updates: > >> Labels: Milestone-Release2.0 > >> > >> Comment #3 on issue 47 by eisenachM: The name of AnalysisXML > >> http://code.google.com/p/psi-pi/issues/detail?id=47 > >> > >> minor comment from SG during DocProc: > >> "File extension. It seems more appropriate to use '.xml'." > >> > >> ACTION: For discussion, pros / cons of having a specific file extension? > >> Since this > >> was agreed by the PSI-PI working group I think it is our decision to take. > >> > >> > >> -- > >> You received this message because you are listed in the owner > >> or CC fields of this issue, or because you starred this issue. > >> You may adjust your issue notification preferences at: > >> http://code.google.com/hosting/settings > >> > >> ------------------------------------------------------------------------------ > >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > >> -Strategies to boost innovation and cut costs with open source participation > >> -Receive a $600 discount off the registration fee with the source code: SFAD > >> http://p.sf.net/sfu/XcvMzF8H > >> _______________________________________________ > >> Psidev-pi-dev mailing list > >> Psi...@li... > >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > >> > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~ > chr...@eb... > http://www.mibbi.org/ > ~~~~~~~~~~~~~~~~~~~~~~~~ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
From: Pierre-Alain B. <pie...@is...> - 2009-02-18 16:09:07
|
Either analysisXML or possibly xml as generic (but less preferred). For mzML the extension is ... mzML (maybe we'll get the same comment from the SG). but mzXML has also ... mzXML I am a bit reluctant to invent a name for an extension that has nothing to do with the standard name. Pierre-Alain Chris Taylor wrote: > Hmm. > > There's a PIML, but the project behind it is dead... > > And anyway I worked for a couple of years with PEDRo and Pedro, > which were a data model and a software tool respectively. > Case over-sensitivity anyone? > > PIML... (bottom): > http://staff.vbi.vt.edu/pathport//pathinfo/#format > > ...is most likely dead or dying: > http://pathport.vbi.vt.edu/main/home.php > > Anyway, was just a thought. > > Cheers, Chris. > > > Chris Taylor wrote: > >> Is 'piML' too obvious..? >> >> Perhaps it exlcludes a wider potential user base though -- lipid >> / sugar / nucleotide / metabolite people, etc.? >> >> C. >> >> >> cod...@go... wrote: >> >>> Updates: >>> Labels: Milestone-Release2.0 >>> >>> Comment #3 on issue 47 by eisenachM: The name of AnalysisXML >>> http://code.google.com/p/psi-pi/issues/detail?id=47 >>> >>> minor comment from SG during DocProc: >>> "File extension. It seems more appropriate to use '.xml'." >>> >>> ACTION: For discussion, pros / cons of having a specific file extension? >>> Since this >>> was agreed by the PSI-PI working group I think it is our decision to take. >>> >>> >>> -- >>> You received this message because you are listed in the owner >>> or CC fields of this issue, or because you starred this issue. >>> You may adjust your issue notification preferences at: >>> http://code.google.com/hosting/settings >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>> -Strategies to boost innovation and cut costs with open source participation >>> -Receive a $600 discount off the registration fee with the source code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Psidev-pi-dev mailing list >>> Psi...@li... >>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev >>> >>> > > |
From: Chris T. <chr...@eb...> - 2009-02-18 15:41:18
|
Hmm. There's a PIML, but the project behind it is dead... And anyway I worked for a couple of years with PEDRo and Pedro, which were a data model and a software tool respectively. Case over-sensitivity anyone? PIML... (bottom): http://staff.vbi.vt.edu/pathport//pathinfo/#format ...is most likely dead or dying: http://pathport.vbi.vt.edu/main/home.php Anyway, was just a thought. Cheers, Chris. Chris Taylor wrote: > Is 'piML' too obvious..? > > Perhaps it exlcludes a wider potential user base though -- lipid > / sugar / nucleotide / metabolite people, etc.? > > C. > > > cod...@go... wrote: >> Updates: >> Labels: Milestone-Release2.0 >> >> Comment #3 on issue 47 by eisenachM: The name of AnalysisXML >> http://code.google.com/p/psi-pi/issues/detail?id=47 >> >> minor comment from SG during DocProc: >> "File extension. It seems more appropriate to use '.xml'." >> >> ACTION: For discussion, pros / cons of having a specific file extension? >> Since this >> was agreed by the PSI-PI working group I think it is our decision to take. >> >> >> -- >> You received this message because you are listed in the owner >> or CC fields of this issue, or because you starred this issue. >> You may adjust your issue notification preferences at: >> http://code.google.com/hosting/settings >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Psidev-pi-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev >> > -- ~~~~~~~~~~~~~~~~~~~~~~~~ chr...@eb... http://www.mibbi.org/ ~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Chris T. <chr...@eb...> - 2009-02-18 15:28:48
|
Is 'piML' too obvious..? Perhaps it exlcludes a wider potential user base though -- lipid / sugar / nucleotide / metabolite people, etc.? C. cod...@go... wrote: > Updates: > Labels: Milestone-Release2.0 > > Comment #3 on issue 47 by eisenachM: The name of AnalysisXML > http://code.google.com/p/psi-pi/issues/detail?id=47 > > minor comment from SG during DocProc: > "File extension. It seems more appropriate to use '.xml'." > > ACTION: For discussion, pros / cons of having a specific file extension? > Since this > was agreed by the PSI-PI working group I think it is our decision to take. > > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > -- ~~~~~~~~~~~~~~~~~~~~~~~~ chr...@eb... http://www.mibbi.org/ ~~~~~~~~~~~~~~~~~~~~~~~~ |
From: <cod...@go...> - 2009-02-18 15:01:39
|
Updates: Labels: Milestone-Release2.0 Comment #3 on issue 47 by eisenachM: The name of AnalysisXML http://code.google.com/p/psi-pi/issues/detail?id=47 minor comment from SG during DocProc: "File extension. It seems more appropriate to use '.xml'." ACTION: For discussion, pros / cons of having a specific file extension? Since this was agreed by the PSI-PI working group I think it is our decision to take. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
From: Jones, A. <And...@li...> - 2009-02-09 11:53:46
|
Hi all, We've received some minor comments back on the AnalysisXML specs from the steering committee, which we need to fix before it can enter the public comment phase. I've added some action/discussion items beneath in each one, feel free to comment. The Steering Committee has the following minor comments which should be addressed before the document enters public comment. 1. Page 1: The intra-group versioning information is not relevant to the review process, which acts on a snapshot, so details on earlier internal versions should be removed. ACTION: Agreed, Andy to fix. 2. Page 6: molecules (iii) -> molecules; and (iii) ACTION: Andy to fix. 3. Page 6: detail in Section 6.1. -> detail in Section 7. ACTION: Andy to fix. 4. Page 13: deems have passed -> deems to have passed ACTION: Andy to fix. 5. Page 14: commonly analyses -> commonly analyse ACTION: Andy to fix. 6. Page 16: Graphical context: the text in this figure and many of the other XML schema diagrams is too small to be readable. ACTION: Andy to fix. 7. Page 17: The XML schema examples are labeled “Example Context”, whereas “Example” or “Schema Fragment” might be clearer. ACTION: These match the mzML specifications, so I think we should argue that consistency is better here so keep as is. 8. Page 23: “Examples might include a p” – this broken sentence appears several times (e.g. Page 25, 26, 28) and needs completed or removed. ACTION: This is part of the auto-generated docs but I will fix manually (I think this is part that was generated incorrectly so I copied and pasted the docs in manually first time around, and presumably made a copy/paste error). 9. Page 58: File extension. It seems more appropriate to use “.xml”. ACTION: For discussion, pros / cons of having a specific file extension? Since this was agreed by the PSI-PI working group I think it is our decision to take. 10. Page 60: “using any of the currently known methods” – a bit too strong, in the absence of a list of the ones you consider are currently known. ACTION: Andy to fix > -----Original Message----- > From: Norman Paton [mailto:no...@cs...] > Sent: 08 February 2009 12:58 > To: Jones, Andy > Cc: Norman Paton > Subject: Analysis Steering Committee Comments > > > Andy, > > Your document has now completed its steering committee review. Please find > attached feedback that has been received. To progress to public review, please > revise your submission taking into account the comments attached. When you > have done this, please upload the changed document and associated material to > the PSI site, and let me know this has happened. As the requested changes are > minor, when addressed the document will be able to enter public review. > > Thank you for your continuing work on behalf of the biological data standards > community. > > Regards, Norman |
From: David C. <dc...@ma...> - 2009-02-04 09:43:25
|
Hi, It appears that someone registered the domain name analysisxml.com on the 30th September last year. Just wondering who that is!? Thanks, David -- 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: Samuel K. <sam...@gm...> - 2009-01-07 17:37:23
|
Hi all, Sorry for the spam, if you don't know anything or are not interested in XML namespaces [1], please save yourself some time/headache and delete this email ;) We are, in the PSI-MI group, just about to announce the release of a new version of the MIF format (2.5.4) in which we have, amongst other things, updated our namespace definition. It has been brought to me that the PSI-MS group is currently discussing similar matter and I am now wondering if we shouldn't be adopting a common guideline for defining XML namespaces so that naming can easily translate across PSI groups. I bet other groups will be asking themselves the same questions (if not already) sooner or later. The namespace PSI-MI has chosen for MIF 2.5.4 [2] is : http://psi.hupo.org/mi/mif And from what I have gathered from PSI-MS, the last naming proposal I am aware of is: http://psidev.info/ms/mzML/xsd/mzML1.1.0 Now looking at the namespaces above, I am also wondering if having the data format version encoded is a recommended practice. Can anyone think of a use case ? My intuition was that we could adopt a rather simple scheme where, in the template below, one would replace the values prefixed by $ by what is appropriate for your format: http://psidev.info/$GROUP/$FORMAT so MzML would have http://psidev.info/ms/mzML and MIF: http://psidev.info/mi/MIF I am by no mean an XML namespace expert so my views could be rather simplistic. Hence I hope someone will be able to shed some light on this matter. Any opinions and comments appreciated ;) Cheers Sam [1] http://www.w3.org/TR/REC-xml-names/ [2] http://psidev.sourceforge.net/mi/rel25/src/MIF254.xsd |
From: Jones, A. <And...@li...> - 2009-01-05 12:42:49
|
Hi all, Can you send me (off the list), suggestions for possible reviewers of the specs. Cheers Andy > -----Original Message----- > From: Norman Paton [mailto:no...@cs...] > Sent: 05 January 2009 10:20 > To: Jones, Andy > Cc: Christian Stephan; Norman Paton > Subject: Re: Submission of AnalysisXML specifications to PSI document process > > > Andy, > > Thanks for your submission, which I will take on as editor. In > anticipation of future feedback, I note that the submission is not > accompanied by the three example instance documents required by the > document process > (http://www.psidev.info/files/PSI_Document_Process.doc), without which > it will not be able to enter the public comment phase. Please can you > also think of 5 people who we could approach for reviews in due course. > > Regards, Norman > > > Jones, Andy wrote: > > > > Dear PSI editors, > > > > > > > > On behalf of the PSI-PI group I am submitting the AnalysisXML > > specifications to the PSI document process. The specifications are > > here: http://www.psidev.info/index.php?q=node/403. > > > > > > > > The submission comprises the specification document, the XSD for > > AnalysisXML and for FuGE light (from which it inherits several > > elements) and a README file. The README file contains links to ten > > example instance documents, the CV and the mapping file, which are all > > stored under SVN at googlecode. There is a link to semantic validation > > software provided by OpenMS and a link is also provided to a webpage > > which has MIAPE-MSI conformance information. > > > > > > > > Let me know if I need to provide any further files for the PSI > > document process. > > > > > > > > Best wishes, > > > > Andy > > |
From: Jones, A. <And...@li...> - 2009-01-05 12:31:11
|
Hi Mike, Thanks for your comments, it's much appreciated! Some responses in line below. Cheers Andy > -----Original Message----- > From: Coleman, Michael [mailto:MK...@st...] > Sent: 31 December 2008 20:25 > To: psi...@li... > Subject: [Psidev-pi-dev] AnalysisXML comments wrt greylag search program > > Greetings! > > We are working on a database search program, called 'greylag', and there are > several things we currently include in the output that don't appear to be > expressable in analysisXML. Perhaps some of these would be worth adding. > > 1. Atomic masses (and proton mass). Greylag can calculate masses for amino > acids and modifications from symbolic formulas (e.g., 'C3H5ON' for alanine, > 'C2H2O' for acetylation, etc.), for greater accuracy and to make life easier > for users. To support this, the atomic masses, both monoisotopic and > average, are given in the output file, along with the (monoisotopic) proton > mass. Amino acid masses are given as well. This seems useful because > different programs and users tend to use somewhat different values for > these, either through error, limited interest in accuracy, or ongoing > progress in measurement. If you wish to interpret and reproduce previous > results, it's useful to know the exact foundation of the calculations. The format can include a mass table for amino acids (e.g. see Mascot MS/MS example) although it does not show the basis for these calculations i.e. the atomic masses of the elements. I can see there may be some benefit knowing which atomic masses were used for calculation but these could be deduced from the amino acid masses (with some difficult admittedly) and it is perhaps a fairly niche use case - other opinions on this? My preference is that search engines publish the atomic masses they use, then they don't need to be reported in every instance document. > 2. Mass "regimes". A mass regime is a pair of amino acid mass tables: one > for precursor mass calculations and one for fragment mass calculations. > Pairing like this allows one to (for example) use average masses for > precursor calculations and monoisotopic masses for fragment calculations. > Perhaps with newer instruments this wouldn't be as useful, but there's a lot > of historical data that was searched this way, and it would be nice to be > able to convert this output to AnalysisXML format. If I'm reading the spec > correctly, currently there is no way to express this, except perhaps to > infer it from the program-specific parameters. This information can be encoded since multiple mass tables can be given so one could be provided for say average masses for precursors and one for monoisotopic masses for fragments. However, mass tables can only be referenced from the Peptide element to demonstrate how the sequenceMass was calculated - which (presumably) is intended for precursor mass. I wonder if we need the ability to reference a different mass table for the fragmentation products as well, say from <IonType> or <Fragmentation>. This needs some more discussion. > 3. Symbolic modification formulas. It's useful to have the symbolic > formula available for modifications, if possible. This allows the exact > masses to be recalculated for different mass tables/regimes, and especially > in the case of unusual modifications, makes it clear exactly what > modification is meant. > > (We omit the symbolic formulas for amino acids under the assumption that > they are truly fixed. If this is not always true, perhaps they should be > included as well.) We currently use Unimod as a controlled vocabulary so for all standard mods, the formula can be retrieved for there. If the matched modification is not in a controlled vocabulary there is no mechanism for providing it (except by providing the delta only for an "unmatched" mod) i.e. negotiation is required with UniMod or elsewhere to add a new term. If we get the PSI-MOD CV working, there will be a mechanism for adding new mods as CV terms when needed. > 4. Calculated masses (precursor and fragment) for all modifications. In a > simultaneous N14/N15 search, for example, this shows what specific mass is > being searched for each. (e.g., What mass delta is used for ubiquitination > for the N14 search? For the N15 search?) I think the calculated precursor mass can be given, this is from the Mascot N15 example: <Peptide id="peptide_9_2" sequenceMass="846.353195" sequenceLength="7" MassTable_ref="MT_heavy"> <Modification location="1" residues="C" monoisotopicMassDelta="57.021469"> <pf:cvParam accession="UNIMOD:4" name="Carbamidomethyl" cvRef="UNIMOD" /> </Modification> <peptideSequence>CNSLNTK</peptideSequence> </Peptide> <Peptide id="peptide_165_2" sequenceMass="1979.106644" sequenceLength="16" MassTable_ref="MT_light"> <Modification location="1" residues="C" monoisotopicMassDelta="57.021469"> <pf:cvParam accession="UNIMOD:4" name="Carbamidomethyl" cvRef="UNIMOD" /> </Modification> <peptideSequence>CFWKEILFTAILAIVR</peptideSequence> </Peptide> But in fact the same mod mass is given for both the heavy and light, is this a mistake in the example? As for fragment masses, I think the calculated masses could be output as an extra <FragmentArray> under each IonType, although this should be redundant information since these values can be calculated independently (as long as we know which mass table to use). > > 5. Isotope prevalence. For an N14/N15 search, for example, it would be > useful to know the prevalence of N15 in the enriched sample. That is, is it > 95%, 99%, etc.? This could be added as a cvParam but I have a feeling that it must be assumed that the enriched sample is 100% N15 for searching, otherwise N-containing amino acids could exist in various forms that would not be accounted for in the search (see below) > > 6. For searches involving multiple mass regimes, it may be that some > modifications should always be calculated using the primary mass regime. > For example, in an N14/N15 search, perhaps some modifications happen in such > a way that even for the N15 sample, the N's in the modification will have > normal ("N14") prevalence. It seems useful to have a way to indicate this, > since it describes what was actually searched. > > This implies that the mass table for the modification might not be the same > as the mass table for the peptide match itself. If this is something that > might realistically happen, it would be useful to support it in the output > format. I think this comes down to a more general point about whether there is complete incorporation of N15 into the sample. If it is incomplete, calculating theoretical peptide masses becomes combinatorially complex, so I think it would have to be assumed that a "heavy" peptide has a "heavy" modification. > > I'm a computer scientist, and learning the chemistry and biology as I go > along. If any of the above seems impossible or ill-conceived, I would very > much like to hear the details. > > The greylag search program is Open Source and available at > > http://greylag.org/ > > It's somewhat unpolished but quite usable and has some unique > advantages--I'd be delighted to have anyone feeling adventurous try it out. > > Happy New Year, > Mike Coleman > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
From: Coleman, M. <MK...@st...> - 2008-12-31 20:25:19
|
Greetings! We are working on a database search program, called 'greylag', and there are several things we currently include in the output that don't appear to be expressable in analysisXML. Perhaps some of these would be worth adding. 1. Atomic masses (and proton mass). Greylag can calculate masses for amino acids and modifications from symbolic formulas (e.g., 'C3H5ON' for alanine, 'C2H2O' for acetylation, etc.), for greater accuracy and to make life easier for users. To support this, the atomic masses, both monoisotopic and average, are given in the output file, along with the (monoisotopic) proton mass. Amino acid masses are given as well. This seems useful because different programs and users tend to use somewhat different values for these, either through error, limited interest in accuracy, or ongoing progress in measurement. If you wish to interpret and reproduce previous results, it's useful to know the exact foundation of the calculations. 2. Mass "regimes". A mass regime is a pair of amino acid mass tables: one for precursor mass calculations and one for fragment mass calculations. Pairing like this allows one to (for example) use average masses for precursor calculations and monoisotopic masses for fragment calculations. Perhaps with newer instruments this wouldn't be as useful, but there's a lot of historical data that was searched this way, and it would be nice to be able to convert this output to AnalysisXML format. If I'm reading the spec correctly, currently there is no way to express this, except perhaps to infer it from the program-specific parameters. 3. Symbolic modification formulas. It's useful to have the symbolic formula available for modifications, if possible. This allows the exact masses to be recalculated for different mass tables/regimes, and especially in the case of unusual modifications, makes it clear exactly what modification is meant. (We omit the symbolic formulas for amino acids under the assumption that they are truly fixed. If this is not always true, perhaps they should be included as well.) 4. Calculated masses (precursor and fragment) for all modifications. In a simultaneous N14/N15 search, for example, this shows what specific mass is being searched for each. (e.g., What mass delta is used for ubiquitination for the N14 search? For the N15 search?) 5. Isotope prevalence. For an N14/N15 search, for example, it would be useful to know the prevalence of N15 in the enriched sample. That is, is it 95%, 99%, etc.? 6. For searches involving multiple mass regimes, it may be that some modifications should always be calculated using the primary mass regime. For example, in an N14/N15 search, perhaps some modifications happen in such a way that even for the N15 sample, the N's in the modification will have normal ("N14") prevalence. It seems useful to have a way to indicate this, since it describes what was actually searched. This implies that the mass table for the modification might not be the same as the mass table for the peptide match itself. If this is something that might realistically happen, it would be useful to support it in the output format. I'm a computer scientist, and learning the chemistry and biology as I go along. If any of the above seems impossible or ill-conceived, I would very much like to hear the details. The greylag search program is Open Source and available at http://greylag.org/ It's somewhat unpolished but quite usable and has some unique advantages--I'd be delighted to have anyone feeling adventurous try it out. Happy New Year, Mike Coleman |
From: Coleman, M. <MK...@st...> - 2008-12-31 00:19:23
|
Here are some comments on the draft of 16th December 2008: - In 1.1, I don't understand the description of T1. Maybe it could be reworded? - In 1.1, should "allow the results to be critically evaluated" also say "and reproduced"? This would be a valuable capability, since the essence of science is reproducibility of experiments. - It would be useful to store a checksum (e.g. SHA-1) for the sequence database in the document, to confirm specifically which sequences were searched against. - Expunge the use of the word "forward" as in "forward database". Better to use something like "real database" and "decoy database"--the fact that the decoys might be reversed sequences is a only a possible detail of implementation, and "forward" seems just to be a vestigial reference to "reverse". - In 2., point 4., it's really not practical to store *all* results, even for an MS-MS search, as there might typically be hundreds of thousands for each spectrum. - In 6.79, specify whether a peptide that matches multiple times (at different positions) within a sequence database locus has multiple PeptideEvidence elements. Is this required, allowed, or forbidden? Is it expected? If they are not required, it would be useful to say something about how "pre" and "post" are chosen from among the alternatives. - In 6.79, specify whether attribute 'end' gives the index of the last residue in the peptide, or the next residue after the match (i.e., last + 1) - In 7.9, it would be better if a specific version of PCRE were named, so that confusion doesn't result if/when PCRE is changed in the future. - In 7.9, it should be clearly stated that the cleavage point is at the start of the match. This is implied but not clearly stated. - For 11., is there any more that can be done about Intellectual Property? If someone does pop up later with a claim, that may render this spec practically worthless. - If at all possible, amino acids (and nucleotides) should be specified to be uppercase letters. If not, it should be stated explicitly what the effects of mixed case will be. For example, is "a" always equivalent to "A"? - For filters, it seems like it might be better to simply disallow mixing "include" and "exclude". Is this ever useful? - It would be very nice to have this document available in PDF format as well, as it looks somewhat odd in OpenOffice and not everyone can read Word docs. - It seems like there should be some way to identify decoy sequences in the database (e.g., by specifying a decoy locus prefix). Currently matches are identified as decoys or not, but if one wants to re-run the search, that information is not sufficient. It might be the case that not all decoys originate as database loci, but I suspect that this is the usual case. - At our site, we often *search* nonspecifically even for samples that were digested with trypsin, filtering later. It doesn't look like there's any way to specify these two enzyme uses ("what's in the sample?" and "how was it searched"). Should there be? - It looks like there is no way to specify multiple mods for a residue, or for either terminus. The current assumption seems to be that if two mods are specified, it means A *or* B, but there is no way to specify A *and* B. I'm not aware of any mods that can occur in conjunction, and I'm not a chemist, but I'm a little uneasy writing this possibility off. Does this really never happen? Here's a hypothetical scenario. Suppose I somehow introduced N15-enriched methionine into an organism, which incorporated it directly into proteins. In that situation, I might want to search for peptides that had a "dynamic" M+1 mod (for the N15) and an M+O (met oxidation) mod or both. Mass tables won't help here because even within a single peptide, there might be methionines with N14 and some with N15. You could always invent a "N15 - N14 + metox" mod, but that seems like a pretty ugly hack--the kind of thing it would be nice to be rid of. As I said, I'm not a chemist (or a biologist)--maybe someone more knowledgeable can comment on whether anything like this is possible. Happy New Year, Mike |
From: Coleman, M. <MK...@st...> - 2008-12-30 23:48:49
|
Here are some likely typos observed in the draft of 16th December 2008: - In 2., point 5 is missing a final period. - In 2., point 7, "peaks list" -> "peak list" - In 2., "enumerate through" should either be just "enumerate" or else "iterate through" - In 2., "tagged together" needs rewording. Perhaps "joined together in pipelines" or just "used" - In 5.3, "Each ... have ... exercise ... provide" should be "Each ... has ... exercises ... provides" - In 5.3, in "Authors of AnalysisXML writing software", there should probably be a hyphen before "writing", or better yet reword. - In 5.3.1, "groups ... analyses" should be "groups ... analyze" - In 6.77, the wide formatting makes this section unreadable. This appears to be due to the long Path. - In 7.2, "integretity" -> "integrity" - In 7.3, in the formula for 'index', the multiplication symbols are not showing, at least in my copies of Word and OpenOffice. Maybe better to just give up and use an '*' or 'x' for multiplication. - In 7.5, "MAY" should be "may". That is, this "may" is not normative ("you are allowed to do this"), but rather just says that something might be possible. - In 7.9, "siteregexp" should be "SiteRegexp", to match other use in the spec. - In 7.9, "2)" should be something like ", and 2)" Regards, Mike |
From: Martin E. <mar...@ru...> - 2008-12-22 15:16:49
|
I added and changed some CV terms according to the discussion in the last TeleCon (mainly thresholds and decoy terms). Changed: "quality estimation method" -> "quality estimation details" "forward+reverse decoy DB" -> "DB composition forward+decoy" "reverse decoy DB" -> "decoy DB type reverse" "randomized decoy DB" -> "decoy DB type randomized" Added: data stored in database prot:FDR threshold pep:FDR threshold OMSSA e-value threshold ProteinExtractor input parameters decoy DB details decoy DB generation algorithm decoy DB type shuffle DB composition only decoy quality estimation with implicite decoy sequences Only MPC_example became non-valid as it used "forward+decoy DB", so I commented out this line, until Andreas updated the obo used for validation. Bye Martin > -----Ursprüngliche Nachricht----- > Von: Martin Eisenacher [mailto:mar...@ru...] > Gesendet: Monday, December 22, 2008 3:59 PM > An: 'Jones, Andy'; psi...@li... > Betreff: Re: [Psidev-pi-dev] Reporting identifications passing threshold > > Hi! > > I added "prot:FDR threshold" and "pep:FDR threshold" > as child terms of "search input details / quality estimation details". > > Does that solve this issue? > Jenny encountered a similar problem with "OMSSA e-value threshold", which I added to > "search-engine specific input parameter". > > Bye > Martin > > > > -----Ursprüngliche Nachricht----- > > Von: Jones, Andy [mailto:And...@li...] > > Gesendet: Monday, December 15, 2008 5:16 PM > > An: psi...@li... > > Betreff: Re: [Psidev-pi-dev] Reporting identifications passing threshold > > > > Hi David, > > > > > Text looks fine to me. Having PI:00364 under SpectrumIdentificationItem > > > really looks wrong to me - it's a global value, so we shouldn't have to > > > report it for each spectrum... (Not to be confused with "PI:00250" > > > name="local FDR" which is also under SpectrumIdentificationItem) > > > > Agreed but I wasn't suggesting this ;-) I put it under > > SpectrumIdentificationProtocol. > > > > Currently, PI:00364 is set as a child term of: > > > > [Term] > > id: PI:00213 > > name: search result details > > def: "Scores and global result characteristics > > > > So I guess it would be fine to map to this from either AdditionalSearchParams or > > from SpectrumIdentificationList. Just to be clear, I was suggesting the term be > > used for a very specific purpose though - documenting which identifications are > > flagged with passThreshold = "true". It shouldn't impact how many results are > > actually output by the search engine. I would also vote for putting this as > > AdditionalSearchParams. > > > > Cheers, > > Andy > > > > > > > > > > > -----Original Message----- > > > From: David Creasy [mailto:dc...@ma...] > > > Sent: 15 December 2008 16:03 > > > To: psi...@li... > > > Subject: Re: [Psidev-pi-dev] Reporting identifications passing threshold > > > > > > Hi, > > > > > > Text looks fine to me. Having PI:00364 under SpectrumIdentificationItem > > > really looks wrong to me - it's a global value, so we shouldn't have to > > > report it for each spectrum... (Not to be confused with "PI:00250" > > > name="local FDR" which is also under SpectrumIdentificationItem) > > > > > > However, there are arguments for putting it in two separate places: > > > a) <AdditionalSearchParams> > > > You choose a FDR and the search/analysis software only creates a list of > > > peptides within that FDR - therefore it is a 'search' parameter. > > > > > > b) <SpectrumIdentificationList> > > > You do the search against a forward and decoy database. From the results > > > you calculate the global FDR. In this case, I suppose it's part of the > > > results. > > > > > > As far as I'm aware, the net effect for the consumer of the AnalysisXML > > > document is the same. > > > > > > We don't want to allow the same cv term in two places, so I'd vote for > > > having it under <AdditionalSearchParams> > > > > > > Any other thoughts? > > > > > > David > > > > > > > > > Jones, Andy wrote: > > > > Hi all, > > > > > > > > I want to insert the following text into the spec document but the first > > example > > > > probably will not validate, since this would not be counted as a valid > > mapping > > > > for AdditionalSearchParams: > > > > > > > > <pf:cvParam accession="PI:00364" name="pep:global FDR" cvRef="PSI-PI" > > > value = > > > > "0.01"/> > > > > > > > > Can we update this mapping or someone suggest a suitable example CV term for > > > > setting a threshold for peptide-spectrum matches. > > > > > > > > Also, feel free to suggest any amendments to this text. > > > > > > > > Cheers > > > > Andy > > > > > > > > > > > > > > > > 7.1.4 Reporting peptide and protein identifications passing a > > significance > > > > threshold > > > > > > > > The elements <SpectrumIdentificationItem> and <ProteinDetectionHypothesis> > > > have > > > > a mandatory Boolean attribute passThreshold that allows a file producer to > > > > indicate that an identification has passed a given threshold or that it has > > been > > > > manually validated. Depending on the intended purpose of the file, the file > > > > producer MAY wish to report a number of identifications that fall below the > > > > given significance threshold, for example to allow global statistics to be > > > > performed which is not possible if only identifications passing the > > threshold > > > > are reported. If the file producer does not want to indicate that a > > threshold > > > > has been set, all identifications MUST have passThreshold = true. > > Thresholds > > > > for peptide-spectrum matches or for protein identification can be encoded as > > > > instances of <cvParam> within <SpectrumDetectionProtocol> or > > > > <ProteinDetectionProtocol> for example as follows: > > > > > > > > <SpectrumIdentificationProtocol id="SEQUEST_proto" > > > > AnalysisSoftware_ref="SEQUEST_SW"> > > > > <SearchType> > > > > <pf:cvParam accession="PI:00083" name="ms-ms search" > > > > cvRef="PSI-PI"/> > > > > </SearchType> > > > > <AdditionalSearchParams> > > > > <pf:cvParam accession="PI:00364" name="pep:global FDR" > > > > cvRef="PSI-PI" value = "0.01"/> > > > > ... > > > > > > > > > > > > <ProteinDetectionProtocol id="PDP_MascotParser_1" > > > > AnalysisSoftware_ref="AS_mascot_parser"> > > > > <AnalysisParams> > > > > <pf:cvParam accession="PI:00316" name="mascot:SigThreshold" > > > cvRef="PSI-PI" > > > > value="0.05"/> > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > > > > The future of the web can't happen without you. Join us at MIX09 to help > > > > pave the way to the Next Web now. Learn more and register at > > > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > > > _______________________________________________ > > > > 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 > > > > > > ------------------------------------------------------------------------------ > > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > > > The future of the web can't happen without you. Join us at MIX09 to help > > > pave the way to the Next Web now. Learn more and register at > > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > > _______________________________________________ > > > Psidev-pi-dev mailing list > > > Psi...@li... > > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > > > > ------------------------------------------------------------------------------ > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > > The future of the web can't happen without you. Join us at MIX09 to help > > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > _______________________________________________ > > Psidev-pi-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > > > ------------------------------------------------------------------------------ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
From: Martin E. <mar...@ru...> - 2008-12-22 14:59:20
|
Hi! I added "prot:FDR threshold" and "pep:FDR threshold" as child terms of "search input details / quality estimation details". Does that solve this issue? Jenny encountered a similar problem with "OMSSA e-value threshold", which I added to "search-engine specific input parameter". Bye Martin > -----Ursprüngliche Nachricht----- > Von: Jones, Andy [mailto:And...@li...] > Gesendet: Monday, December 15, 2008 5:16 PM > An: psi...@li... > Betreff: Re: [Psidev-pi-dev] Reporting identifications passing threshold > > Hi David, > > > Text looks fine to me. Having PI:00364 under SpectrumIdentificationItem > > really looks wrong to me - it's a global value, so we shouldn't have to > > report it for each spectrum... (Not to be confused with "PI:00250" > > name="local FDR" which is also under SpectrumIdentificationItem) > > Agreed but I wasn't suggesting this ;-) I put it under > SpectrumIdentificationProtocol. > > Currently, PI:00364 is set as a child term of: > > [Term] > id: PI:00213 > name: search result details > def: "Scores and global result characteristics > > So I guess it would be fine to map to this from either AdditionalSearchParams or > from SpectrumIdentificationList. Just to be clear, I was suggesting the term be > used for a very specific purpose though - documenting which identifications are > flagged with passThreshold = "true". It shouldn't impact how many results are > actually output by the search engine. I would also vote for putting this as > AdditionalSearchParams. > > Cheers, > Andy > > > > > > -----Original Message----- > > From: David Creasy [mailto:dc...@ma...] > > Sent: 15 December 2008 16:03 > > To: psi...@li... > > Subject: Re: [Psidev-pi-dev] Reporting identifications passing threshold > > > > Hi, > > > > Text looks fine to me. Having PI:00364 under SpectrumIdentificationItem > > really looks wrong to me - it's a global value, so we shouldn't have to > > report it for each spectrum... (Not to be confused with "PI:00250" > > name="local FDR" which is also under SpectrumIdentificationItem) > > > > However, there are arguments for putting it in two separate places: > > a) <AdditionalSearchParams> > > You choose a FDR and the search/analysis software only creates a list of > > peptides within that FDR - therefore it is a 'search' parameter. > > > > b) <SpectrumIdentificationList> > > You do the search against a forward and decoy database. From the results > > you calculate the global FDR. In this case, I suppose it's part of the > > results. > > > > As far as I'm aware, the net effect for the consumer of the AnalysisXML > > document is the same. > > > > We don't want to allow the same cv term in two places, so I'd vote for > > having it under <AdditionalSearchParams> > > > > Any other thoughts? > > > > David > > > > > > Jones, Andy wrote: > > > Hi all, > > > > > > I want to insert the following text into the spec document but the first > example > > > probably will not validate, since this would not be counted as a valid > mapping > > > for AdditionalSearchParams: > > > > > > <pf:cvParam accession="PI:00364" name="pep:global FDR" cvRef="PSI-PI" > > value = > > > "0.01"/> > > > > > > Can we update this mapping or someone suggest a suitable example CV term for > > > setting a threshold for peptide-spectrum matches. > > > > > > Also, feel free to suggest any amendments to this text. > > > > > > Cheers > > > Andy > > > > > > > > > > > > 7.1.4 Reporting peptide and protein identifications passing a > significance > > > threshold > > > > > > The elements <SpectrumIdentificationItem> and <ProteinDetectionHypothesis> > > have > > > a mandatory Boolean attribute passThreshold that allows a file producer to > > > indicate that an identification has passed a given threshold or that it has > been > > > manually validated. Depending on the intended purpose of the file, the file > > > producer MAY wish to report a number of identifications that fall below the > > > given significance threshold, for example to allow global statistics to be > > > performed which is not possible if only identifications passing the > threshold > > > are reported. If the file producer does not want to indicate that a > threshold > > > has been set, all identifications MUST have passThreshold = true. > Thresholds > > > for peptide-spectrum matches or for protein identification can be encoded as > > > instances of <cvParam> within <SpectrumDetectionProtocol> or > > > <ProteinDetectionProtocol> for example as follows: > > > > > > <SpectrumIdentificationProtocol id="SEQUEST_proto" > > > AnalysisSoftware_ref="SEQUEST_SW"> > > > <SearchType> > > > <pf:cvParam accession="PI:00083" name="ms-ms search" > > > cvRef="PSI-PI"/> > > > </SearchType> > > > <AdditionalSearchParams> > > > <pf:cvParam accession="PI:00364" name="pep:global FDR" > > > cvRef="PSI-PI" value = "0.01"/> > > > ... > > > > > > > > > <ProteinDetectionProtocol id="PDP_MascotParser_1" > > > AnalysisSoftware_ref="AS_mascot_parser"> > > > <AnalysisParams> > > > <pf:cvParam accession="PI:00316" name="mascot:SigThreshold" > > cvRef="PSI-PI" > > > value="0.05"/> > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > > > The future of the web can't happen without you. Join us at MIX09 to help > > > pave the way to the Next Web now. Learn more and register at > > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > > _______________________________________________ > > > 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 > > > > ------------------------------------------------------------------------------ > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > > The future of the web can't happen without you. Join us at MIX09 to help > > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > _______________________________________________ > > Psidev-pi-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
From: <cod...@go...> - 2008-12-22 12:29:09
|
Updates: Status: Fixed Comment #6 on issue 41 by eisenachM: Things to submit into DocProc http://code.google.com/p/psi-pi/issues/detail?id=41 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
From: Jones, A. <And...@li...> - 2008-12-17 15:18:19
|
Dear PSI editors, On behalf of the PSI-PI group I am submitting the AnalysisXML specifications to the PSI document process. The specifications are here: http://www.psidev.info/index.php?q=node/403. The submission comprises the specification document, the XSD for AnalysisXML and for FuGE light (from which it inherits several elements) and a README file. The README file contains links to ten example instance documents, the CV and the mapping file, which are all stored under SVN at googlecode. There is a link to semantic validation software provided by OpenMS and a link is also provided to a webpage which has MIAPE-MSI conformance information. Let me know if I need to provide any further files for the PSI document process. Best wishes, Andy |
From: <cod...@go...> - 2008-12-17 15:00:40
|
Comment #2 on issue 47 by rkjulian: The name of AnalysisXML http://code.google.com/p/psi-pi/issues/detail?id=47 I have been talking to several different groups, and I'm not sure 'analysisXML' is so widely recognized as to present a problem with a formal release name change. My only suggestion would be to keep the name general enough so that anyone who could use the format to hold results from MS experiment analysis would think the name makes sense. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
From: <cod...@go...> - 2008-12-17 14:12:29
|
Comment #1 on issue 47 by dcreasy: The name of AnalysisXML http://code.google.com/p/psi-pi/issues/detail?id=47 (and Pierre-Alain replied 05/12/2008 08:59) Hi Eric, in principle, and for the sake of homogeneity, it would be nice. mzML has got a new name due to a merge, and this is a good justification for it. However, there might be some difficulties to do so. Here are some thoughts: Pros: - To homogenize / standardize namings, nnnnnnML could be nice - We could say that AnalysisXML it is a draft name and would get a stable name together with version 1.0. Contra: - AnalysisXML is already well known under this name and is being mentioned as is in a number of publications. - It is not sufficient to change to nnnnML to homogenize within PSI: MIF25 (for the molecular interaction group) is not a nnnnnML formated name. (Also MIAPE for MI is named MIMIx and not MIAPE-MI). - AnalysisXML.com exists and is linked to PSI (although only the domain name is reserved, no info is there) Names: - piML, paML exist already as Markup Language acronyms - piaML does not exist - AnalysisML does not exist as markup language - analysis(X)ML vs analysis(X)ML -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |