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: Gerhard M. <not...@gi...> - 2016-04-29 14:22:34
|
Done all CV stuff and added README.md file with a download link for the validator --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/1#issuecomment-215733284 |
From: Gerhard M. <not...@gi...> - 2016-04-29 14:18:17
|
Resolved. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/11#issuecomment-215732021 |
From: Gerhard M. <not...@gi...> - 2016-04-29 14:18:11
|
Closed #11. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/11#event-645643287 |
From: Gerhard M. <not...@gi...> - 2016-04-29 14:17:59
|
Closed #12. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/12#event-645642846 |
From: Gerhard M. <not...@gi...> - 2016-04-29 14:17:54
|
Resolved. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/12#issuecomment-215731905 |
From: andrewrobertjones <not...@gi...> - 2016-04-29 13:02:06
|
Hi @enetz Anyone is free to add any types of CV terms you want to SpectrumIdentificationItem. Please make some suggestion for what such a term would look like, and then we will add it in. It doesn't need to be part of the formal standard --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/14#issuecomment-215705113 |
From: Eugen N. <not...@gi...> - 2016-04-29 12:33:49
|
We briefly discussed at the PSI meeting, that manual annotations would be possible by manually setting the passThreshold value in SpectrumIdentificationItem. Since manual examination of spectra is still very important in cross-linking pipelines, could we add more flexible annotations, maybe a CV term for free text comments? Manually changing the passThreshold flag would not be transparent and reproducible. Or is there a good reason to generally avoid such free text comments? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/14 |
From: mayerg97 <ger...@ru...> - 2016-04-29 09:22:46
|
Dear proteomics community, attached there's the new version 3.86.2 of the psi-ms.obo file. Changed CV terms in version 3.86.2 of psi-ms.obo: ================================================= ************ Updated the import links to pato.obo and unit.obo (pointing now to GitHub) import: https://raw.githubusercontent.com/pato-ontology/pato/master/pato.obo import: https://raw.githubusercontent.com/bio-ontology-research-group/unit-ontology/master/unit.obo remark: URL: https://raw.githubusercontent.com/HUPO-PSI/psi-ms-CV/master/psi-ms.obo ************ Renamed cross-link receiver --> cross-link acceptor [Term] id: MS:1002510 name: cross-link acceptor def: "Cross-linking acceptor, assigned according to the following rules: the export software SHOULD use the following rules to choose the cross-link donor as the: longer peptide, then higher peptide neutral mass, then alphabetical order." [PSI:PI] xref: value-type:xsd\:string "The allowed value-type for this CV term." is_a: MS:1002508 ! cross-linking attribute *********** Changed the regular expression [Term] id: MS:1002505 name: regular expression for modification localization scoring def: "([:digit:]+:[0|1]\{1\}.[:digit:]+[Ee]{0,1}[+-]{0,1}[:digit:]*:[:digit:]+[|]\{1\}[:digit:]+:(true|false)\{1\})" [PSI:PI] is_a: MS:1002479 ! regular expression ************ Re-added units to the following two terms [Term] id: MS:1002225 name: average product ion intensity def: "Average value of product ion intensity in a collection of identified spectra." [PSI:PI] is_a: MS:1001226 ! product ion intensity relationship: has_units MS:1000131 ! number of detector counts relationship: has_units MS:1000132 ! percent of base peak relationship: has_units MS:1000814 ! counts per second relationship: has_units MS:1000905 ! percent of base peak times 100 [Term] id: MS:1002226 name: product ion intensity standard deviation def: "Standard deviation of product ion intensity in a collection of identified spectra." [PSI:PI] is_a: MS:1001226 ! product ion intensity relationship: has_units MS:1000131 ! number of detector counts relationship: has_units MS:1000132 ! percent of base peak relationship: has_units MS:1000814 ! counts per second relationship: has_units MS:1000905 ! percent of base peak times 100 Best Regards, Gerhard -- *--* *Dipl. Inform. med., Dipl. Wirtsch. **Inf. GERHARD MAYER* *PhD student* *Medizinisches Proteom-Center* *DEPARTMENT Medical Bioinformatics* *Building *ZKF E.049a | Universitätsstraße 150 | D-44801 Bochum *Fon *+49 (0)234 32-21006 | *Fax *+49 (0)234 32-14554 *E-mail***ger...@ru... <mailto:ger...@ru...> www.medizinisches-proteom-center.de <http://www.medizinisches-proteom-center.de/> |
From: Timo S. <not...@gi...> - 2016-04-29 07:45:43
|
Hi, I wanted to point out that the current format e.g. "(K,L,n-term)" might be insufficient to represent site-specific and site-unspecific terminal cross-linker. e.g. in unimod there is the distinction between a terminal modification e.g. ("N-term") and a terminal modification at a specific site e.g. ("N-term K"). Maybe we could also adapt this notation. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/13 |
From: Julian U. <not...@gi...> - 2016-04-29 07:40:31
|
That is right, this information would be lost in the merged file. I think to keep this, any kind of mapping, maybe something like a metafile suggested by @javizca would be a good idea. Regarding the SpectrumIdentificationProtocol: currently, when PIA is exporting a merged PSM list, an additional SpectrumIdentificationProtocol for the merging is generated. This, though, only contains the merging settings and not the original search settings, and does not solve the problem shown by @smdb21 --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/5#issuecomment-215650123 |
From: Juan A. V. <ju...@eb...> - 2016-04-29 07:33:31
|
Hi all, Summary of the call yesterday. People attending: I apologise because I am missing at least one person (I did not get who she was) -> Andy, Oliver and the rest of the Tuebingen people (Mathias, Timo, etc), Gerhard, Robert, Alexander, Lutz, Juan. -> After reviewing the specification document (Figure 3 there): 1)- At the moment, at the peptide level restrict the specification to "pairs". In the future, new CV params could be added to support the cases where a single linker connects multiple peptides in multiple positions. Loop links in the same peptide and more than two peptides linked by different linkers are supported right now. 2) Change in the CV the term “receiver” to the more correct (from a chemical point of view) “acceptor”. 3) The specification document needs to be updated with the latest version of the figures (including hyphenated cross-link terms and the correct accession numbers for the CV terms). Andy will do it. After reviewing the list of cross-linkers (generated by Lutz, available at https://github.com/HUPO-PSI/mzIdentML/blob/master/cv/XLMOD.csv <https://github.com/HUPO-PSI/mzIdentML/blob/master/cv/XLMOD.csv>). 4) Some improvements need to be done: long name for some of the reagents needs to be agreed in some cases (for instance L-Photo-Leucine is not a systematic name), ideally publications or CAS numbers should be available as a more stable reference). This discussion will continue off-line via e-mail between Lutz, Oliver and others. At this point, we just need a identifier and a long name. Other details can be updated later. This would be version 1.0 of the CV. 5) Keep the file it as a csv file at the moment. Discussion about protein-protein interaction (PPI) evidences (Figure 4 in the specification document): 6) Not all the complexity related to PPI should be encoded in mzIdentML. The right balance needs to be kept. If more complexity is needed, links to external PSI MI and/or PSI XML files could be added. So, it should be enough adding which proteins are interacting plus some scores. 7) There was one proposal made in the GitHub issues page (https://github.com/HUPO-PSI/mzIdentML/issues/2 <https://github.com/HUPO-PSI/mzIdentML/issues/2>). However, in order to capture more structural information (for instance the position of the interaction for each protein), this information needs to go at the Protein level (ProteinDetectionHypothesis), not at the ProteinGroup level. Andy has already posted in GitHub a possible solution. TO DO next: 1) Lutz -> Update examples with real CV terms, and check that the validator works. Use temporary CV terms for the scores, that have not been added yet to the PSI MS CV (which also needs to be done). 2) Tuebingen -> Not far from having example files. Check with the validator. Next phone call next Wednesday May 4th at 4 pm UK time. Best regards, Juan |
From: Salvador M. de B. <not...@gi...> - 2016-04-28 17:40:21
|
But, then, what about the search parameters? In case of having a single mzIdentML file with a single SIList merging PSMs coming from different searches with different parameters, can we have in AnalysisCollection, two different SpectrumIdentification elements referencing to different SpectrumIdentificationProtocols (different search parameters) and same SIList? like: ``` ... <SpectrumIdentificationList id="SIL_1"> ... </> ... <AnalysisCollection> <SpectrumIdentification spectrumIdentificationProtocol_ref="parameters_1" spectrumIdentificationList_ref="SIL_1"> ... </> <SpectrumIdentification spectrumIdentificationProtocol_ref="parameters_2" spectrumIdentificationList_ref="SIL_1"> ... </> </AnalysisCollection> ... ``` In this case, we lose the ability to know with which parameters an specific PSM was searched, right? We know that SIL_1 is the combination of 2 searches, but each PSM we don't know from which one is coming from. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/5#issuecomment-215505909 |
From: andrewrobertjones <not...@gi...> - 2016-04-28 16:18:55
|
I think changing interaction id to be integer.a integer.b e.g. 1001.a 1001.b for the interacting partners would work for this. Then the same value could be shared amongst different proteins within same group, showing ambiguity rather than implying they are interacting. Coupled with my proposal higher up, this would seem to cover most cases needed? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/2#issuecomment-215482358 |
From: Lutz F. <not...@gi...> - 2016-04-28 15:03:48
|
@andrewrobertjones if we put the info on individual proteins we probably need to flag up the site as well. Otherwise we have problems to distinguish a link that could come from protein A residue X and could end in either protein B residue Y OR protein C residue Z. E.g. extend the info to INTERACTION_PAIR_ID:CROSSLINK_ID:SITE_ID:PROTEIN_SEQ_POSTION:SCORE:PASS_THRESHOLD As to if we need a another info on protein group level - I would say yes. A link could have a 5% chance of being wrong - bit the supported protein interaction could actually have something a lot worse or better than that. So we would want to be able to flag that up as well. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/2#issuecomment-215455219 |
From: Lutz F. <not...@gi...> - 2016-04-28 14:53:54
|
@andrewrobertjones would it make sense to abstract the cross-linker position to a modification localisation? The problem there would be that you would have to encode more complicated cases then we currently have/usually care about in cross-linking. E.g. that two sites are mutual exclusive. But how much more would we need to have general modifications covert? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/2#issuecomment-215452015 |
From: Jones, A. <And...@li...> - 2016-04-28 14:37:22
|
Summary of items we will discuss on the call (30 mins time): 1. Overview of encoding as written in spec doc: https://github.com/HUPO-PSI/mzIdentML/blob/master/specification_document/specdoc1_2/mzIdentML1%202-draft.docx (section 5.2.8 and Figure 3 and Figure 4) a. Note Figure 4 is subject to change following our discussions 2. Work through issues flagged here, particularly those mentioned by Lutz: https://github.com/HUPO-PSI/mzIdentML/issues/2; a. For this we will also need to look at the proposed XL CV: https://github.com/HUPO-PSI/mzIdentML/blob/master/cv/XLMOD.csv 3. Action points towards getting the XL part of mzid 1.2 complete Best wishes Andy From: Jones, Andy [mailto:And...@li...] Sent: 27 April 2016 10:22 To: psi...@li... Cc: eug...@tu...; le...@im...; Andrea Sinz <and...@ph...>; Robert Chalkley <cha...@cg...>; eli...@ug...; ju...@ed...; sul...@ug... Subject: Re: [Psidev-pi-dev] Cross-linking discussions at PSI meeting Hi all, This is to confirm that we will have a call at 4pm UK, 5pm EU, 8am California: http://www.timeanddate.com/worldclock/fixedtime.html?msg=PSI-PI+call+on+crosslinking&iso=20160428T16&p1=301&ah=1 The main topic for discussion will be encoding cross-linking in mzIdentML 1.2. Current issues with mzIdentML 1.2 are being discussed on GitHub here: https://github.com/HUPO-PSI/mzIdentML/issues, I will update it with open issues around cross-linking by tomorrow. The current version of the specifications are here (rather long I’m afraid) along with a powerpoint explaining the encodings for new features: https://github.com/HUPO-PSI/mzIdentML/tree/master/specification_document/specdoc1_2 If Lutz is able to create a CV file for reagents before the call, we will also post that online for discussions. Best wishes Andy Numbers: + UK: 0808 109 5644 + US: 877-420-0272 + Belgium: 0800 509 80 + Germany: 0800 101 2079 + Switzerland: 0800 000 860 + Generic international: +44 (0) 20 8322 2500 (UK number) Access code: 297427 # From: Jones, Andy Sent: 19 April 2016 15:56 To: tobias <to...@eb...<mailto:to...@eb...>> Cc: eug...@tu...<mailto:eug...@tu...>; le...@im...<mailto:le...@im...>; sul...@ug...<mailto:sul...@ug...>; ju...@ed...<mailto:ju...@ed...>; eli...@ug...<mailto:eli...@ug...>; Lutz Fischer <lfi...@st...<mailto:lfi...@st...>>; Robert Chalkley <cha...@cg...<mailto:cha...@cg...>>; Juan Antonio Vizcaino <ju...@eb...<mailto:ju...@eb...>>; Yasset Perez-Riverol <yp...@eb...<mailto:yp...@eb...>>; psi...@li...<mailto:psi...@li...> Subject: Cross-linking discussions at PSI meeting Hi all, This email is addressed to those who participated in the XL session at PSI today, plus Lutz and Robert (and plus Yasset for GitHub issues). Please forward this on to others who should be consulted. I have also copied to the PSI-PI list. The major outcomes from today are as follows: 1. General agreement that we are nearly there with the mzid 1.2 encoding of XL info. 2. Plan for Lutz to maintain (via mzIdentML GitHub for example), a separate CV of crosslinker reagents, based off the attached sheet (converted to CSV format, with unique IDs per row e.g. XL:0001, XL:0002, more discussion needed to finalise format) 3. Some additions to mzid 1.2 to cover: - cases of combined evidence from multiple input spectra (L v H isotopes; ETD+HCD; MS3 etc) to make an identification (not post-processing but intrinsic to the ID mechanism) - Adding protein-level interaction evidence - Re-using additions already proposed in mzid 1.2 for mod or XL localization ambiguity 4. No major interest at this stage to encode XL info in mztab, we may do this at our side following same model as mzid 1.2 5. Plan for wider project over medium to long term to write a cross-linking standards paper, including mzid 1.2 plus a minimum reporting guidelines doc (Juri / Alexander to progress this), with wider authorship 6. We will role these changes into mzid 1.2 specifications, and publish that paper separately (submitted in the short term). For those that contribute example files or major input of the specs, I will invite to join the author list of that paper. I have started to write this up in the mzid 1.2 specification document (attached here and committed to our GitHub) - see pages 20-23), and an XML snippet for how the protein interaction part will look. ACTION items: - We discussed Lutz updating the xi export examples to include protein interaction scores, following our proposed spec - Alexander and Eugen to update the examples exported from OpenMS and add to the mzid GitHub (please email Yasset - cc'd to get write access to the GitHub) - Ideally, would be great if the Edinburgh visualisation software could read the mzid 1.2 files to see if all info is really covered - Andy to continue cleaning and updating specification document I would like to propose a conference call to progress this for 4pm UK/5pm Europe on Thurs 28th April - please reply to let me know if you can make it. best wishes Andy |
From: andrewrobertjones <not...@gi...> - 2016-04-28 14:25:57
|
@javizca I would vote for the coordinate system being used in mzIdentML is always zero based. If you writing back to GFF afterwards, you would need to do a conversion. This seems safer than having two ways of doing it, and then assuming a reading software will check this parameter. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/4#issuecomment-215442939 |
From: andrewrobertjones <not...@gi...> - 2016-04-28 14:24:01
|
In response to @lutzfischer I agree that cross-linker site localisation evidence could be added at the level of the protein, and this would need to go on ProteinDetectionHypothesis in mzid (i.e. accession level rather than protein group level), something like as follows: INTERACTION_PAIR_ID:PROTEIN_SEQ_POSTION:SCORE:PASS_THRESHOLD - similar to mod localization. Question - is anything needed at the ProteinGroup level simply assessing the evidence that a pair of proteins are interacting, where you don't care about positional info? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/2#issuecomment-215441954 |
From: Lutz F. <not...@gi...> - 2016-04-28 13:27:34
|
https://github.com/HUPO-PSI/mzIdentML/blob/master/cv/XLMOD.csv --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/2#issuecomment-215422294 |
From: Mathias W. <not...@gi...> - 2016-04-28 13:02:53
|
> If the lists are kept separate (in one file with 2 lists) or 2 files (with one list), a reader might double count the number of spectra queried (and possibly over count PSMs), or would need its own logic for combining the same spectrum in different list - which would probably not exist. I agree with Andy here, _not_ having separate lists reduces the number of ways a reader could interpret the consumed mzid(s) --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/5#issuecomment-215416113 |
From: Mathias W. <not...@gi...> - 2016-04-28 12:49:28
|
@lutzfischer > I uploaded a initial list of cross-linker. Can you post a link, please? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/2#issuecomment-215412962 |
From: Mathias W. <not...@gi...> - 2016-04-28 12:35:51
|
we might consider breaking that list up into several. Maybe keeping a list of all with their names and links to .md files describing the single metric in more detail. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/qcML-development/pull/21#issuecomment-215409871 |
From: Mathias W. <not...@gi...> - 2016-04-28 12:34:36
|
Reopened #20. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/qcML-development/pull/20#event-644239173 |
From: Mathias W. <not...@gi...> - 2016-04-28 12:34:11
|
Merged #20. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/qcML-development/pull/20#event-644239323 |
From: Mathias W. <not...@gi...> - 2016-04-28 12:33:48
|
Closed #20. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/qcML-development/pull/20#event-644239063 |