psidev-pi-dev Mailing List for Proteomics Standards Initiative (Page 16)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Closed #23.

---
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/23#event-657358777
Closed #17.

---
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/17#event-657348720
Gerhard unable to reproduce issue. Harald re-open if it is still a problem

---
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/17#issuecomment-218495366
Closed #16.

---
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/16#event-657337800
This is part of the documentation in the schema: "For any other ions not related to the position within the peptide sequence e.g. quantification reporter ions, the index value MUST be 0."

Please request the terms for PSI-MS CV for specific reporter ions you want to annotate

---
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/16#issuecomment-218493356
Documentation in the XSD explains this: 
For immonium ions, the index is the position of the identified ion within the peptide sequence - if the peptide contains the same amino acid in multiple positions that cannot be distinguished, all positions should be given.

---
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/9#issuecomment-218492327
Closed #9.

---
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/9#event-657331554
Closed #8.

---
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/8#event-657325688
Seems to be solved, closing. Can be re-opened if issue still exists

---
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/8#issuecomment-218491241
Agreed to use mechanism and closing

---
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-218489968
Closed #5.

---
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#event-657317684
@fghali  can you let us know when this has been checked versus example files, then close this issue

---
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-218488936
All moved to other issues or done, closing

---
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-218488250
Closed #1.

---
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#event-657307566
Thanks for the clarification.
The case we currently (as far as I understood it and mainly from a theoretical point) are not able to represent is e.g.:
Linking K to Y or S to T but at the same time disallowing K to T. I don't know if these cases exist in practice (or might exist in the future - e.g. for special types of zero length cross-linker).

---
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#issuecomment-218465225
Ok first point - terminal cross-links: One reason I did not want to put Protein-C/N-term in is that basically for all non-natural cross-linkers that distinction depends on when you add the cross-linker - e.g. before or after digest. So it's not an inherent feature of the cross-linker. Admittedly there are probably not many experiments that would do cross-linking after a digest...

But I guess we could change to Protein N-Term to keep in line with uniprot. Does anybody else here have an opinion on it?

So we could define a cross-linker that links Protein-N-terminal methionine or KSTY anywhere else  to anything as : 
(N-Term M,K,S,T,Y)&(*)
or
(Protein N-Term M,K,S,T,Y)&(*)
For the uniprot-version.
What ever cross-linker that would be...

Point two : Yes the ampersand means that the cross-linker can link anything from the left side with anything  on the right side but not within the left or the right. E.g. for EDC:
(K,S,T,Y,n-term)&(E,D,c-term)
means 
it links K or S or T or Y or the n-terminal to either E or D or the C-terminal but not K to S or E to D.
Compared to BS3:
(K,S,T,Y,N-term)&(K,S,T,Y,N-term)
- can link any K,S,T,Y or N-Term to any K,S,T,Y or N-Term
e.g K to K, K to S, K to T, K to Y, K to N-term, S to K, S to S ... 

I am not sure if I understand your example right but would that not have been already covered?
Linking K to Y only:
(K)&(Y)
Linking K to K or Y
(K)&(K,Y)
Linking K to K
(K)&(K)

---
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#issuecomment-218460126
Some of the cross-linkers have CV terms in Unimod, e.g. the mono-links for DSS (but not the cross-link).
If there are CV terms in Unimod available, should the Unimod terms be used, or should the XLMOD terms from the csv file have priority for cross-linking specific information?
The cross-link CV terms in Unimod are patchy, so if we prioritize Unimod we will have both Unimod and XLMOD terms in most files. Otherwise we could cover all cross-linking specific information with XLMOD terms and be more uniform.

---
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/28
Can we make the following term obsolete?

[Term]
id: MS:1001355
name: peptide descriptions
def: "Descriptions of peptides." [PSI:PI]
is_a: MS:1001105 ! peptide result details

It has no children and no associated value, so it makes not much sense.

---
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/27
The files validate using the mzIdentMLValidator-1.4.16-SNAPSHOT and have only one SIL per file now
You can view, comment on, or merge this pull request online at:

  https://github.com/HUPO-PSI/mzIdentML/pull/26

-- Commit Summary --

  * adding new versions of PIA example files

-- File Changes --

    M examples/1_2examples/multi_search/MSGFplus_tandem.pia.1.2.mzid.gz (0)
    M examples/1_2examples/multi_search/mouse_dataset_-_combination.pia.1.2.mzid.gz (0)
    M examples/1_2examples/protein_inference/PIA_Rosetta_peak_list_2a_+_Ecoli_spectra.mzid.gz (0)
    M examples/1_2examples/protein_inference/PIA_Rosetta_peak_list_2a_-_neat.mzid.gz (0)
    M examples/1_2examples/protein_inference/PIA_Rosetta_peak_list_2b_+_Ecoli_spectra.mzid.gz (0)
    M examples/1_2examples/protein_inference/PIA_Rosetta_peak_list_2b_-_neat.mzid.gz (0)

-- Patch Links --

https://github.com/HUPO-PSI/mzIdentML/pull/26.patch
https://github.com/HUPO-PSI/mzIdentML/pull/26.diff

---
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/pull/26

Maybe this should go to a new issue, but:
Do we have a recommendation on how to handle <SpectrumIdentificationItem>s with multiple instances of the same score (or any other Param)? For example if identifications from different search engines are merged using the FDRScore and CombinedFDRScore. So for each search engine run there is (optimally) one FDRScore in the combined <SpectrumIdentificationItem>, should these be reported? Otherwise, you could have multiple say Mascot Scores, if you searched with different modifications, etc.

Maybe we could also introduce a CvParam which indicates from which original runs each single  <SpectrumIdentificationItem> gets its evidence, or is there one already which I missed? Alternatively something like a new optional evidence-element could be added to the combined <SpectrumIdentificationItem>s, which holds the original scores etc. but as that is a schema change I guess we don't want to do that now.

---
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-218385650
Uploaded a minimal version of XLMOD as
XLMOD-1.0.0.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/20#issuecomment-218147429
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/mzIdentML/issues/20#event-655704567
Ok thanks for the comment. 

Maybe it's not really relevant at this point but I give some information how it is done in unimod.

If we decide to be consistent with the naming scheme in unimod, we could use:
"Protein N-term" or "Protein C-term" for protein terminal cross-linker
"N-term" or "C-term" for peptide terminal cross-linker (probably less relevant as you pointed out)
(or the empty string for non-terminal ones)
and then add the residue (if it is site specific cross-linker):

What I currently did not understand (sorry I did not make it to the calls) how the pairs are specified. Is it possible to say (and does it make sense?), e.g. the cross-linker can link K and Y, but not K and K or Y and Y? How would this definition differ from a cross-linker that can link e.g. K and K, too?

If we need to express something like this (sorry again if this has already been discussed) is this already possible using the encoding in the column?

I am asking, because as I understand it, the & currently stands for the cross-product of the two sets (=all combinations pairs between the left side and the right side). 

If we want to support the general case this could be easily extended.

---
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#issuecomment-218146338
Dear proteomics community,

attached there's the new version 3.87.0 of the psi-ms.obo file.

New CV terms in version 3.87.0 of psi-ms.obo:
=============================================
[Term]
id: MS:1002659
name: UniProtKB text sequence format
def: "Text-based format used by UniProtKB for sequence entries." [PSI:PI]
xref: SWO:http://edamontology.org/format_2187
is_a: MS:1001347 ! database file formats

[Term]
id: MS:1002660
name: UniProtKB XML sequence format
def: "XML-based format used by UniProtKB for sequence entries." [PSI:PI]
is_a: MS:1001347 ! database file formats

[Term]
id: MS:1002661
name: Morpheus
def: "Morpheus search engine." [PMID:23323968]
is_a: MS:1001456 ! analysis software

[Term]
id: MS:1002662
name: Morpheus:Morpheus score
def: "Morpheus score for PSMs." [PSI:PI]
xref: value-type:xsd\:double "The allowed value-type for this CV term."
is_a: MS:1001143 ! search engine specific score for PSMs
is_a: MS:1001153 ! search engine specific score
is_a: MS:1001405 ! spectrum identification result details
relationship: has_order MS:1002108 ! higher score better

[Term]
id: MS:1002663
name: Morpheus:summed Morpheus score
def: "Summed Morpheus score for protein groups." [PSI:PI]
xref: value-type:xsd\:double "The allowed value-type for this CV term."
is_a: MS:1002368 ! search engine specific score for protein groups
is_a: MS:1001153 ! search engine specific score
is_a: MS:1001147 ! protein ambiguity group result details
relationship: has_order MS:1002108 ! higher score better

[Term]
id: MS:1002664
name: protein interaction scores derived from cross-linking
def: "Parent term for protein interaction scores derived from 
cross-linking." [PSI:PI]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1002508 ! cross-linking attribute
relationship: has_regexp MS:1002665 ! 
([:digit:]+[.][a|b]:[:digit:]+:[:digit:]+[.][:digit:]+([Ee][+-][0-9]+)*:(true|false]\{1\})

[Term]
id: MS:1002665
name: regular expression for protein interaction scores derived from 
cross-linking
def: 
"([:digit:]+[.][a|b]:[:digit:]+:[:digit:]+[.][:digit:]+([Ee][+-][0-9]+)*:(true|false]\{1\})" 
[PSI:PI]
is_a: MS:1002479 ! regular expression

Changed CV terms in version 3.87.0 of psi-ms.obo:
=================================================
************ added is_a: MS:1001405 ! spectrum identification result details
[Term]
id: MS:1002600
name: PRIDE XML
def: "Internal data and submission format of the PRIDE database." 
[http://ftp.pride.ebi.ac.uk/pride/resources/schema/pride/pride.xsd]
is_a: MS:1002130 ! identification file format
is_a: MS:1001405 ! spectrum identification result details

************ obsoleted the following term
[Term]
id: MS:1002639
name: peptide start on chromosome
def: "OBSOLETE The overall start position on the chromosome to which a 
peptide has been mapped i.e. the position of the first base of the first 
codon, using a zero-based counting system." [PSI:PI]
comment: This term was obsoleted because it contains redundant info 
contained in term MS:1002643 - peptide start positions on chromosome.
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1002636 ! proteogenomics attribute
is_obsolete: true

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/>

RUB Logo

ANNOUNCEMENT de.NBI summer school September 2016:

*Analysis of Mass-Spectrometric Data - *

*Big Data Bioinformatics in Proteomics and Metabolomics*

http://www.denbi.de/index.php/11-training-cat/95-lss2016

I agree that this would make sense. Hoever at the moment we don't have a cross-linker of type "N-term K" or equivalent.
Currently used are:
* Amino-Acids - signifies that the cross-linker reacts with these amino-acids
* N-term/C-term - refers to N-terminal or C-terminal end of the protein

If we want to specify now how things will be treated even if we don't have examples of them then we need a separate document to keep these information.

One more related question would be whether it make sense to distinguish protein and peptide terminal. This probably only meaning full if looking at natural occurring cross-links e.g. Ubiguitilation - not sure if there are any natural occurring peptide  C-/N-terminal cross-links.

---
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#issuecomment-218140043

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

psidev-pi-dev Mailing List for Proteomics Standards Initiative (Page 16)

psidev-pi-dev — General Development List for Proteomics Informatics