psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] Release candidate 4.0.9_rc1 of psi-ms.obo

[mayerg97 <ger...@ru...>]

Dear proteomics community,

attached there's the release candidate 4.0.9_rc1 of the psi-ms.obo file.

It contains new terms for binary data arrays and their compression
and for spectral library searches.


New CV terms in version 4.0.9_rc1 of psi-ms.obo:
================================================
[Term]
id: MS:1002742
name: noise array
def: "A data array of noise values." [PSI:MS]
xref: binary-data-type:MS\:1000521 "32-bit float"
xref: binary-data-type:MS\:1000523 "64-bit float"
is_a: MS:1000513 ! binary data array

[Term]
id: MS:1002743
name: sampled noise m/z array
def: "A data array of parallel, independent m/z values for a sampling of 
noise across a spectrum (typically much smaller than MS:1000514, the m/z 
array)." [PSI:MS]
xref: binary-data-type:MS\:1000521 "32-bit float"
xref: binary-data-type:MS\:1000523 "64-bit float"
is_a: MS:1000513 ! binary data array
relationship: has_units MS:1000040 ! m/z

[Term]
id: MS:1002744
name: sampled noise intensity array
def: "A data array of intensity values for a sampling of noise across a 
spectrum (for use with MS:0000000, sampled noise m/z array)." [PSI:MS]
xref: binary-data-type:MS\:1000521 "32-bit float"
xref: binary-data-type:MS\:1000523 "64-bit float"
is_a: MS:1000513 ! binary data array
relationship: has_units MS:1000131 ! number of detector counts

[Term]
id: MS:1002745
name: sampled noise baseline array
def: "A data array of signal baseline values (the signal in the absence 
of analytes) for a sampling of noise across a spectrum (for use with 
MS:0000000, sampled noise m/z array)." [PSI:MS]
xref: binary-data-type:MS\:1000521 "32-bit float"
xref: binary-data-type:MS\:1000523 "64-bit float"
is_a: MS:1000513 ! binary data array

[Term]
id: MS:1002746
name: MS-Numpress linear prediction compression followed by zlib compression
def: "Compression using MS-Numpress linear prediction compression and 
zlib." [https://github.com/ms-numpress/ms-numpress]
is_a: MS:1000572 ! binary data compression type

[Term]
id: MS:1002747
name: MS-Numpress positive integer compression followed by zlib compression
def: "Compression using MS-Numpress positive integer compression and 
zlib." [https://github.com/ms-numpress/ms-numpress]
is_a: MS:1000572 ! binary data compression type

[Term]
id: MS:1002748
name: MS-Numpress short logged float compression followed by zlib 
compression
def: "Compression using MS-Numpress short logged float compression and 
zlib." [https://github.com/ms-numpress/ms-numpress]
is_a: MS:1000572 ! binary data compression type

[Term]
id: MS:1002749
name: Mascot:IntegratedSpectralLibrarySearch
def: "Means that Mascot has integrated the search results of database 
and spectral library search into a single data set." [PSI:PI]
xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
is_a: MS:1002095 ! Mascot input parameter

[Term]
id: MS:1002750
name: NIST MSPepSearch
def: "Search tool of the NIST (National Institute of Standrads and 
Technology) for spectral library searches." [PSI:PI]
is_a: MS:1001456 ! analysis software

[Term]
id: MS:1002751
name: NIST MSP format
def: "MSP text format defined by the NIST." [PSI:PI]
is_a: MS:1001347 ! database file formats

[Term]
id: MS:1002752
name: database type spectral library
def: "Database containing spectra." [PSI:PI]
is_a: MS:1001073 ! database type

[Term]
id: MS:1002753
name: value between 0 and 1000 inclusive
def: "Value range for scores." [PSI:PI]
is_a: MS:1002304 ! domain range

[Term]
id: MS:1002754
name: MSPepSearch:score
def: "MSPepSearch score (0 for entirely dissimilar and 1000 for 
identical observed spectrum and library spectrum." [PSI:PI]
is_a: MS:1001143 ! PSM-level search engine specific statistic
relationship: has_order MS:1002108 ! higher score better
relationship: has_domain MS:1002753 ! value between 0 and 1000 inclusive

[Term]
id: MS:1002755
name: combined ms-ms + spectral library search
def: "A combined MS2 (with fragment ions) and spectral library search." 
[PSI:PI]
is_a: MS:1001080 ! search type


Changed CV terms in version 4.0.9_rc1 of psi-ms.obo:
====================================================
************ Changed web link to the new GitHub adress 
https://github.com/ms-numpress/ms-numpress
[Term]
id: MS:1002312
name: MS-Numpress linear prediction compression
def: "Compression using MS-Numpress linear prediction compression." 
[https://github.com/ms-numpress/ms-numpress]
is_a: MS:1000572 ! binary data compression type

[Term]
id: MS:1002313
name: MS-Numpress positive integer compression
def: "Compression using MS-Numpress positive integer compression." 
[https://github.com/ms-numpress/ms-numpress]
is_a: MS:1000572 ! binary data compression type

[Term]
id: MS:1002314
name: MS-Numpress short logged float compression
def: "Compression using MS-Numpress short logged float compression." 
[https://github.com/ms-numpress/ms-numpress]
is_a: MS:1000572 ! binary data compression type

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

Re: [Psidev-ms-dev] CV Mapping file (MAY)

[Race, A. <Ala...@un...>]

Hi Eric,
Thank you for the detailed reply. It seems I missed that link to the RFC, sorry about that.

Point 3 is interesting. I hadn’t read that anywhere before and is certainly good to know, so thank you for explaining that. I would also be very interested to know if the validator does indeed check for this.

Speaking of the validator – I was trying this recently and I get an error when checking against the MIAPE due to “inclusion of an obsolete term MS:1000843 (wavelength)”. It looks as if this is because the source_maldi_must rule in miape-rules.xml actually requires this term, but in the latest psi-ms.obo this is obsolete.

Okay, point 4 also makes sense in terms of policy and keeping the ontology clear. I guess any (MIAPE) validator must then just trust that the user/software has selected the most appropriate child term, to the best of their abilities.

Thanks again,

Alan

From: Eric Deutsch [mailto:ede...@sy...]
Sent: 21 March 2017 01:10
To: Mass spectrometry standard development <psi...@li...>
Cc: Eric Deutsch <ede...@sy...>
Subject: Re: [Psidev-ms-dev] CV Mapping file (MAY)

Hi Alan, thanks for the questions, these are good ones

1) The definitions of MAY SHOULD MUST are official definitions as per RFC-2219 as described at the beginning of section 2 in the spec doc:
http://psidev.cvs.sourceforge.net/*checkout*/psidev/psi/psi-ms/mzML/document/mzML1.1.0_specificationDocument.doc

2) In this context, MAY means that you permitted to specify the term(s) referenced, but are not required to do so. Nothing more. Except for a slight qualification in #3.

3) Regarding terms that are *not* specified in a given context:
  3a) for any term that is mentioned in another rule, it MUST not be used in a context that doesn’t allow it. For example, since there is a rule somewhere that specifies where an instrument model can be specified, it is invalid to reference an instrument model in any place that does not specify that it can be there.
  3b) however, for any term that is *not* constrained anywhere, then its use anywhere is a warning, but not an error. And that file is valid. For example, say we had a term “room air temperature”, and there is no constraint anywhere in the mzML mapping file that applies to that term (directly or by parentage), then it is not illegal to specify it anywhere the write wants.
I believe that is what we have agreed. I am uncertain if it is fully implemented in the validator. Does anyone wish to clarify this?

4) Regarding the ambiguous nature of parent terms, I believe our policy is as follows: if a writer writes a parent term instead of a specific child term, then the writer is trying to tell the reader explicitly that they do not have that information. The writer is in effect saying “yes, there is a reflectron state here.. but I just don’t know what it is, sorry”. This might have some different connotation than not providing any information. Similarly, when a format says that an instrument model MUST be specified, if the writer simply uses the parent term “instrument model”, this means the writer does not know. Perhaps it is a tool that is converting an MGF file of unknown pedigree to an mzML file. This is a little weird perhaps, but it solves the problem of littering the ontology with “unknown instrument”, “unknown reflectron state”, etc. This would be untidy and not something that true ontologies have anyway. Although would be a bit explicit. This was discussed to death, and that’s the consensus.

That’s my best answer to your questions. Further clarifications welcome, especially if I got something wrong.

Regards,
Eric


From: Race, Alan [mailto:Ala...@un...<mailto:Ala...@un...>]
Sent: Monday, March 20, 2017 8:53 AM
To: Mass spectrometry standard development
Subject: [Psidev-ms-dev] CV Mapping file (MAY)

Hello,
I have a question regarding the intent for the MUST, SHOULD, MAY requirement levels within the mapping file that I couldn’t find a clear definition of online. The question relates to determination of a valid mzML file. With MAY, is the intent that:

a) A set of terms that may be included, but is not exhaustive. I.e. The MAY rules are for guidance only.
b) Only terms mentioned here may be included within the defined scope, any others would render the mzML technically invalid.
c) Something else?

On a related note, the analyzer_may rule states that any child of MS:1000480 (mass analyser attribute) can be included. However, one of the children is MS:1000021 (reflectron state) – so inclusion of this ‘parent’ term (whose child terms define on and off) would satisfy the validity of mzML, but including the MS:1000021 term makes no sense. Is there anything within the obo/mapping file that I’m missing that would enable filtering/checking of these parent terms that ideally shouldn’t be allowed to be included?

Thank you for your help,

Alan

Re: [Psidev-ms-dev] Data analysis description

[Race, A. <Ala...@un...>]

Hi Mathias,
I thought that seemed most sensible too - the confusion just came from the fact that the softwareRef is defined on the processingMethod rather than the dataProcessing tag, which seems the wrong way around to me.

Thanks again,

Alan

-----Original Message-----
From: Mathias Walzer [mailto:wa...@in...] 
Sent: 21 March 2017 10:36
To: Mass spectrometry standard development <psi...@li...>
Subject: Re: [Psidev-ms-dev] Data analysis description

Hi Alan,

I'd roll with the name of the tag. One software with multiple methods/steps, multiple method tags.

best,
 mths

----- Original Message -----
From: "Alan Race" <Ala...@un...>
To: "Mass spectrometry standard development" <psi...@li...>
Sent: Monday, 20 March, 2017 3:41:14 PM
Subject: Re: [Psidev-ms-dev] Data analysis description

Hi Mathias,
Thank you for your reply. Okay that sounds good, I'll put together a list and submit it to the vocab mailing list. 

With regards to the one software application per processingMethod tag - if one software applied multiple methods that have the same parameter names (e.g. Gaussian smoothing with a window size, and TopHat baseline correction with a window size) would you recommend putting these in the same processingMethod tag because they are the same software? Or separate them out into two processingMethod tags to avoid confusion with the window size CVParams?

Thanks,

Alan

-----Original Message-----
From: Mathias Walzer [mailto:wa...@in...]
Sent: 20 March 2017 10:53
To: Mass spectrometry standard development <psi...@li...>
Subject: Re: [Psidev-ms-dev] Data analysis description

Hi, Alan!

yes, you can reflect all parameters of a workflow, one software application per processionmethod tag. If there is no adequate cvParam for one used parameter, then you have the choice of using a userParam (http://www.peptideatlas.org/tmp/mzML1.1.0.html#userParam) for the short term and suggest a new cv term - best at psi...@li.... Or stick with userParam representation if that param won't be any good for any other software. For the latter, you should probably also consider if there is the chance of misinterpretation if the userParam cannot be read or interpreted (e.g. submission software).

best,
 mths

----- Original Message -----
From: "Alan Race" <Ala...@un...>
To: psi...@li...
Sent: Friday, 17 March, 2017 8:56:25 AM
Subject: [Psidev-ms-dev] Data analysis description





Hello, 

I have a question regarding recommended implementation of a full description of data analysis steps, for example. Say that I wanted to include a description of a full preprocessing workflow – how would you suggest to include the parameters related to each method? I assumed that it would be through the inclusion of additional cvParam tags, but I couldn’t see anything obvious in the obo. Perhaps I am missing something? 



Assuming that there are tags, then should each processingMethod tag only describe (fully) a single method and it’s corresponding parameters (as below)? the example on the mzML website ( http://www.peptideatlas.org/tmp/mzML1.1.0.html#processingMethod ) suggests that the processingMethod tag can include a whole preprocessing workflow including multiple methods, and, the way that I see it, including parameters for each method in this situation may result in them being attributed incorrectly to a given method. 



<dataProcessingList count="2"> 

<dataProcessing id="preprocessing"> 

<processingMethod order="1" softwareRef="test"> 

<cvParam cvRef="MS" accession="MS:1000782" name="Savitzky-Golay smoothing" value=""/> 

<cvParam cvRef="MS" accession="MS:???????" name="Polynomial order" value="2"/> 

<cvParam cvRef="MS" accession="MS:???????" name="Window size" value=""/> 

</processingMethod> 

… 

</dataProcessing> 

… 



Thanks for your help, 

Alan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Data analysis description

[Mathias W. <wa...@in...>]

Hi Alan,

I'd roll with the name of the tag. One software with multiple methods/steps, multiple method tags.

best,
 mths

----- Original Message -----
From: "Alan Race" <Ala...@un...>
To: "Mass spectrometry standard development" <psi...@li...>
Sent: Monday, 20 March, 2017 3:41:14 PM
Subject: Re: [Psidev-ms-dev] Data analysis description

Hi Mathias,
Thank you for your reply. Okay that sounds good, I'll put together a list and submit it to the vocab mailing list. 

With regards to the one software application per processingMethod tag - if one software applied multiple methods that have the same parameter names (e.g. Gaussian smoothing with a window size, and TopHat baseline correction with a window size) would you recommend putting these in the same processingMethod tag because they are the same software? Or separate them out into two processingMethod tags to avoid confusion with the window size CVParams?

Thanks,

Alan

-----Original Message-----
From: Mathias Walzer [mailto:wa...@in...] 
Sent: 20 March 2017 10:53
To: Mass spectrometry standard development <psi...@li...>
Subject: Re: [Psidev-ms-dev] Data analysis description

Hi, Alan!

yes, you can reflect all parameters of a workflow, one software application per processionmethod tag. If there is no adequate cvParam for one used parameter, then you have the choice of using a userParam (http://www.peptideatlas.org/tmp/mzML1.1.0.html#userParam) for the short term and suggest a new cv term - best at psi...@li.... Or stick with userParam representation if that param won't be any good for any other software. For the latter, you should probably also consider if there is the chance of misinterpretation if the userParam cannot be read or interpreted (e.g. submission software).

best,
 mths

----- Original Message -----
From: "Alan Race" <Ala...@un...>
To: psi...@li...
Sent: Friday, 17 March, 2017 8:56:25 AM
Subject: [Psidev-ms-dev] Data analysis description





Hello, 

I have a question regarding recommended implementation of a full description of data analysis steps, for example. Say that I wanted to include a description of a full preprocessing workflow – how would you suggest to include the parameters related to each method? I assumed that it would be through the inclusion of additional cvParam tags, but I couldn’t see anything obvious in the obo. Perhaps I am missing something? 



Assuming that there are tags, then should each processingMethod tag only describe (fully) a single method and it’s corresponding parameters (as below)? the example on the mzML website ( http://www.peptideatlas.org/tmp/mzML1.1.0.html#processingMethod ) suggests that the processingMethod tag can include a whole preprocessing workflow including multiple methods, and, the way that I see it, including parameters for each method in this situation may result in them being attributed incorrectly to a given method. 



<dataProcessingList count="2"> 

<dataProcessing id="preprocessing"> 

<processingMethod order="1" softwareRef="test"> 

<cvParam cvRef="MS" accession="MS:1000782" name="Savitzky-Golay smoothing" value=""/> 

<cvParam cvRef="MS" accession="MS:???????" name="Polynomial order" value="2"/> 

<cvParam cvRef="MS" accession="MS:???????" name="Window size" value=""/> 

</processingMethod> 

… 

</dataProcessing> 

… 



Thanks for your help, 

Alan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] CV Mapping file (MAY)

[Eric D. <ede...@sy...>]

Hi Alan, thanks for the questions, these are good ones



1) The definitions of MAY SHOULD MUST are official definitions as per
RFC-2219 as described at the beginning of section 2 in the spec doc:

http://psidev.cvs.sourceforge.net/*checkout*/psidev/psi/psi-ms/mzML/document/mzML1.1.0_specificationDocument.doc



2) In this context, MAY means that you permitted to specify the term(s)
referenced, but are not required to do so. Nothing more. Except for a
slight qualification in #3.



3) Regarding terms that are **not** specified in a given context:

  3a) for any term that is mentioned in another rule, it MUST not be used
in a context that doesn’t allow it. For example, since there is a rule
somewhere that specifies where an instrument model can be specified, it is
invalid to reference an instrument model in any place that does not specify
that it can be there.

  3b) however, for any term that is **not** constrained anywhere, then its
use anywhere is a warning, but not an error. And that file is valid. For
example, say we had a term “room air temperature”, and there is no
constraint anywhere in the mzML mapping file that applies to that term
(directly or by parentage), then it is not illegal to specify it anywhere
the write wants.

I believe that is what we have agreed. I am uncertain if it is fully
implemented in the validator. Does anyone wish to clarify this?



4) Regarding the ambiguous nature of parent terms, I believe our policy is
as follows: if a writer writes a parent term instead of a specific child
term, then the writer is trying to tell the reader explicitly that they do
not have that information. The writer is in effect saying “yes, there is a
reflectron state here.. but I just don’t know what it is, sorry”. This
might have some different connotation than not providing any information.
Similarly, when a format says that an instrument model MUST be specified,
if the writer simply uses the parent term “instrument model”, this means
the writer does not know. Perhaps it is a tool that is converting an MGF
file of unknown pedigree to an mzML file. This is a little weird perhaps,
but it solves the problem of littering the ontology with “unknown
instrument”, “unknown reflectron state”, etc. This would be untidy and not
something that true ontologies have anyway. Although would be a bit
explicit. This was discussed to death, and that’s the consensus.



That’s my best answer to your questions. Further clarifications welcome,
especially if I got something wrong.



Regards,

Eric





*From:* Race, Alan [mailto:Ala...@un...]
*Sent:* Monday, March 20, 2017 8:53 AM
*To:* Mass spectrometry standard development
*Subject:* [Psidev-ms-dev] CV Mapping file (MAY)



Hello,

I have a question regarding the intent for the MUST, SHOULD, MAY
requirement levels within the mapping file that I couldn’t find a clear
definition of online. The question relates to determination of a valid mzML
file. With MAY, is the intent that:



a) A set of terms that may be included, but is not exhaustive. I.e. The MAY
rules are for guidance only.

b) Only terms mentioned here may be included within the defined scope, any
others would render the mzML technically invalid.

c) Something else?



On a related note, the analyzer_may rule states that any child of
MS:1000480 (mass analyser attribute) can be included. However, one of the
children is MS:1000021 (reflectron state) – so inclusion of this ‘parent’
term (whose child terms define on and off) would satisfy the validity of
mzML, but including the MS:1000021 term makes no sense. Is there anything
within the obo/mapping file that I’m missing that would enable
filtering/checking of these parent terms that ideally shouldn’t be allowed
to be included?



Thank you for your help,



Alan

[Psidev-ms-dev] CV Mapping file (MAY)

[Race, A. <Ala...@un...>]

Hello,
I have a question regarding the intent for the MUST, SHOULD, MAY requirement levels within the mapping file that I couldn't find a clear definition of online. The question relates to determination of a valid mzML file. With MAY, is the intent that:

a) A set of terms that may be included, but is not exhaustive. I.e. The MAY rules are for guidance only.
b) Only terms mentioned here may be included within the defined scope, any others would render the mzML technically invalid.
c) Something else?

On a related note, the analyzer_may rule states that any child of MS:1000480 (mass analyser attribute) can be included. However, one of the children is MS:1000021 (reflectron state) - so inclusion of this 'parent' term (whose child terms define on and off) would satisfy the validity of mzML, but including the MS:1000021 term makes no sense. Is there anything within the obo/mapping file that I'm missing that would enable filtering/checking of these parent terms that ideally shouldn't be allowed to be included?

Thank you for your help,

Alan

Re: [Psidev-ms-dev] Data analysis description

[Race, A. <Ala...@un...>]

Hi Mathias,
Thank you for your reply. Okay that sounds good, I'll put together a list and submit it to the vocab mailing list. 

With regards to the one software application per processingMethod tag - if one software applied multiple methods that have the same parameter names (e.g. Gaussian smoothing with a window size, and TopHat baseline correction with a window size) would you recommend putting these in the same processingMethod tag because they are the same software? Or separate them out into two processingMethod tags to avoid confusion with the window size CVParams?

Thanks,

Alan

-----Original Message-----
From: Mathias Walzer [mailto:wa...@in...] 
Sent: 20 March 2017 10:53
To: Mass spectrometry standard development <psi...@li...>
Subject: Re: [Psidev-ms-dev] Data analysis description

Hi, Alan!

yes, you can reflect all parameters of a workflow, one software application per processionmethod tag. If there is no adequate cvParam for one used parameter, then you have the choice of using a userParam (http://www.peptideatlas.org/tmp/mzML1.1.0.html#userParam) for the short term and suggest a new cv term - best at psi...@li.... Or stick with userParam representation if that param won't be any good for any other software. For the latter, you should probably also consider if there is the chance of misinterpretation if the userParam cannot be read or interpreted (e.g. submission software).

best,
 mths

----- Original Message -----
From: "Alan Race" <Ala...@un...>
To: psi...@li...
Sent: Friday, 17 March, 2017 8:56:25 AM
Subject: [Psidev-ms-dev] Data analysis description





Hello, 

I have a question regarding recommended implementation of a full description of data analysis steps, for example. Say that I wanted to include a description of a full preprocessing workflow – how would you suggest to include the parameters related to each method? I assumed that it would be through the inclusion of additional cvParam tags, but I couldn’t see anything obvious in the obo. Perhaps I am missing something? 



Assuming that there are tags, then should each processingMethod tag only describe (fully) a single method and it’s corresponding parameters (as below)? the example on the mzML website ( http://www.peptideatlas.org/tmp/mzML1.1.0.html#processingMethod ) suggests that the processingMethod tag can include a whole preprocessing workflow including multiple methods, and, the way that I see it, including parameters for each method in this situation may result in them being attributed incorrectly to a given method. 



<dataProcessingList count="2"> 

<dataProcessing id="preprocessing"> 

<processingMethod order="1" softwareRef="test"> 

<cvParam cvRef="MS" accession="MS:1000782" name="Savitzky-Golay smoothing" value=""/> 

<cvParam cvRef="MS" accession="MS:???????" name="Polynomial order" value="2"/> 

<cvParam cvRef="MS" accession="MS:???????" name="Window size" value=""/> 

</processingMethod> 

… 

</dataProcessing> 

… 



Thanks for your help, 

Alan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Data analysis description

[Mathias W. <wa...@in...>]

Hi, Alan!

yes, you can reflect all parameters of a workflow, one software application per processionmethod tag. If there is no adequate cvParam for one used parameter, then you have the choice of using a userParam (http://www.peptideatlas.org/tmp/mzML1.1.0.html#userParam) for the short term and suggest a new cv term - best at psi...@li.... Or stick with userParam representation if that param won't be any good for any other software. For the latter, you should probably also consider if there is the chance of misinterpretation if the userParam cannot be read or interpreted (e.g. submission software).

best,
 mths

----- Original Message -----
From: "Alan Race" <Ala...@un...>
To: psi...@li...
Sent: Friday, 17 March, 2017 8:56:25 AM
Subject: [Psidev-ms-dev] Data analysis description





Hello, 

I have a question regarding recommended implementation of a full description of data analysis steps, for example. Say that I wanted to include a description of a full preprocessing workflow – how would you suggest to include the parameters related to each method? I assumed that it would be through the inclusion of additional cvParam tags, but I couldn’t see anything obvious in the obo. Perhaps I am missing something? 



Assuming that there are tags, then should each processingMethod tag only describe (fully) a single method and it’s corresponding parameters (as below)? the example on the mzML website ( http://www.peptideatlas.org/tmp/mzML1.1.0.html#processingMethod ) suggests that the processingMethod tag can include a whole preprocessing workflow including multiple methods, and, the way that I see it, including parameters for each method in this situation may result in them being attributed incorrectly to a given method. 



<dataProcessingList count="2"> 

<dataProcessing id="preprocessing"> 

<processingMethod order="1" softwareRef="test"> 

<cvParam cvRef="MS" accession="MS:1000782" name="Savitzky-Golay smoothing" value=""/> 

<cvParam cvRef="MS" accession="MS:???????" name="Polynomial order" value="2"/> 

<cvParam cvRef="MS" accession="MS:???????" name="Window size" value=""/> 

</processingMethod> 

… 

</dataProcessing> 

… 



Thanks for your help, 

Alan 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Data analysis description

[Race, A. <Ala...@un...>]

Hello,
I have a question regarding recommended implementation of a full description of data analysis steps, for example. Say that I wanted to include a description of a full preprocessing workflow - how would you suggest to include the parameters related to each method? I assumed that it would be through the inclusion of additional cvParam tags, but I couldn't see anything obvious in the obo. Perhaps I am missing something?

Assuming that there are tags, then should each processingMethod tag only describe (fully) a single method and it's corresponding parameters (as below)? the example on the mzML website (http://www.peptideatlas.org/tmp/mzML1.1.0.html#processingMethod) suggests that the processingMethod tag can include a whole preprocessing workflow including multiple methods, and, the way that I see it, including parameters for each method in this situation may result in them being attributed incorrectly to a given method.

<dataProcessingList count="2">
    <dataProcessing id="preprocessing">
      <processingMethod order="1" softwareRef="test">
               <cvParam cvRef="MS" accession="MS:1000782" name="Savitzky-Golay smoothing" value=""/>
                <cvParam cvRef="MS" accession="MS:???????" name="Polynomial order" value="2"/>
                <cvParam cvRef="MS" accession="MS:???????" name="Window size" value=""/>
      </processingMethod>
                ...
    </dataProcessing>
...

Thanks for your help,
Alan

[Psidev-ms-dev] namespace in mzIdentML

[Witold E W. <wew...@gm...>]

Sorry if this is not the appropriate list but did not find any list
dedicated for users here: http://www.psidev.info/mailing-lists

I just have a brief question. I am trying to write the following
xpath/xquery statement

db:open("extracted","20160312_15_B1_myrimatch_2_2_140.mzid")/*:MzIdentML/*:SequenceCollection/*:Peptide

and would like to be more specific about the namespace than to use the *.

However, namespaces  are not mentioned even once in the
http://www.psidev.info/sites/default/files/mzIdentML1.1.0.pdf

Thanks

[Psidev-ms-dev] REVISED VERSION R1: PSI recommendation document (file format proBed), 14-days public review

[Martin E. <mar...@ru...>]

Dear colleague,

dear member of the Proteomics community,

 

please forward this message to potentially interested colleagues!

 

I received a revised version (R1) of the proBed format specification:

http://www.psidev.info/proBed-in-docproc

A “responses to reviewers” document is also included.

 

It would be great to receive your comments within two 

weeks (13th March 2017).

 

PLEASE ADD COMMENTS to the submission page

(http://www.psidev.info/proBed-in-docproc) 

(or send them directly to martin.eisenacher: at : rub.de) for 

 example regarding the following criteria:

 

- That it is well formed – that is, it is presented in accordance with the
templates and is clearly written.

- That it is sufficiently detailed and clearly contains and comprehensively
describes the necessary and sufficient explanation of the format.

- That the examples are in accordance with the specification.> >

 

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.

 

    Many thanks for your valuable time and participation

      Martin Eisenacher (PSI Editor)

 

 

--

PD DR. MARTIN EISENACHER

Department Leader

DEPARTMENT Medical Bioinformatics

Medizinisches Proteom-Center

Ruhr-University Bochum

Building ZKF E.141 | Universitätsstraße 150 | D-44801 Bochum

Fon +49 (0)234 32-29288 | Fax +49 (0)234 32-14554

E-mail  <mailto:mar...@ru...> mar...@ru...

 <http://www.medizinisches-proteom-center.de/>
www.medizinisches-proteom-center.de

 



 

 

 

Von: Martin Eisenacher [mailto:mar...@ru...] 
Gesendet: Donnerstag, 20. Oktober 2016 11:11
An: psi...@li...;
psi...@li...; psi...@li...;
ps...@eb...; psi...@eb...
Betreff: [Psidev-qc-dev] PSI recommendation document (file format proBed),
60-days public review

 

Dear colleague,

dear member of the Proteomics community,

 

please forward this message to potentially interested colleagues!

 

The HUPO Proteomics Standards Initiative (PSI) develops standards 

for documentation and storage of Proteomics data (see 

 <http://www.psidev.info> http://www.psidev.info for an overview of
activities).

 

A recommendation document specifying the proBed file format

has been submitted to the PSI document process.

The submission can be found here:

http://www.psidev.info/proBed-in-docproc

 

After having passed a 30-day review of the PSI steering group 

with minor changes, the proposed document version 1.0.0 DRAFT 

now goes through 60-days public comments and external 

review phase (end: 19th December 2016).

 

"The format represents systematically the output of proteogenomics

analyses, by mapping peptide identification data retrieved from 

mass spectrometry (MS)-based experiments to the genome."

(see also Cover Letter attached to the submission page)

 

The format is based on the BED format (Browser Extensive Data,

 <https://genome.ucsc.edu/FAQ/FAQformat.html#format1>
https://genome.ucsc.edu/FAQ/FAQformat.html#format1),

developed by the UCSC (University of California, Santa Cruz) team.

 

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.

 

PLEASE ADD COMMENTS to the submission page

(http://www.psidev.info/proBed-in-docproc) 

(or send them directly to martin.eisenacher: at : rub.de) for 

 example regarding the following criteria:

 

- That it is well formed – that is, it is presented in accordance with the
templates and is clearly written.

- That it is sufficiently detailed and clearly contains and comprehensively
describes the necessary and sufficient explanation of the format.

- That the examples are in accordance with the specification.> >

 

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.

 

    Many thanks for your valuable time and participation

      Martin Eisenacher (PSI Editor)

 

--

PD DR. MARTIN EISENACHER

Department Leader

DEPARTMENT Medical Bioinformatics

Medizinisches Proteom-Center

Ruhr-University Bochum

Building ZKF E.141 | Universitätsstraße 150 | D-44801 Bochum

Fon +49 (0)234 32-29288 | Fax +49 (0)234 32-14554

E-mail  <mailto:mar...@ru...> mar...@ru...

 <http://www.medizinisches-proteom-center.de/>
www.medizinisches-proteom-center.de

 



 

Re: [Psidev-ms-dev] New version 4.0.8 of psi-ms.obo

[Jones, A. <And...@li...>]

Thanks Gerhard

From: mayerg97 [mailto:ger...@ru...]
Sent: 02 February 2017 13:05
To: psi...@li...; psi...@li...; psi...@li...
Subject: [Psidev-ms-dev] New version 4.0.8 of psi-ms.obo


Dear proteomics community,

attached there's the new version 4.0.8 of the psi-ms.obo file.
It contains two new terms for proteogenomics.


New CV terms in version 4.0.8 of psi-ms.obo:
============================================
[Term]
id: MS:1002740
name: unmapped peptide
def: "Within the context of a proteogenomics approach, a peptide sequence that has not been mapped to a genomic location." [PSI:PI]
is_a: MS:1002636 ! proteogenomics attribute

[Term]
id: MS:1002741
name: unmapped protein
def: "Within the context of a proteogenomics approach, a protein sequence that has not been mapped to a genomic location." [PSI:PI]
is_a: MS:1002636 ! proteogenomics attribute

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

[Psidev-ms-dev] New version 4.0.8 of psi-ms.obo

[mayerg97 <ger...@ru...>]

Dear proteomics community,

attached there's the new version 4.0.8 of the psi-ms.obo file.
It contains two new terms for proteogenomics.


New CV terms in version 4.0.8 of psi-ms.obo:
============================================
[Term]
id: MS:1002740
name: unmapped peptide
def: "Within the context of a proteogenomics approach, a peptide 
sequence that has not been mapped to a genomic location." [PSI:PI]
is_a: MS:1002636 ! proteogenomics attribute

[Term]
id: MS:1002741
name: unmapped protein
def: "Within the context of a proteogenomics approach, a protein 
sequence that has not been mapped to a genomic location." [PSI:PI]
is_a: MS:1002636 ! proteogenomics attribute

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

Re: [Psidev-ms-dev] [Psidev-ms-vocab] New version 4.0.7 of psi-ms

[Jones, A. <And...@li...>]

Looks good to me, thanks

From: mayerg97 [mailto:ger...@ru...]
Sent: 30 January 2017 15:39
To: psi...@li...; psi...@li...; psi...@li...
Subject: [Psidev-ms-vocab] New version 4.0.7 of psi-ms


Dear proteomics community,

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


Changed CV terms in version 4.0.7 of psi-ms.obo:
================================================
************ parent term of the new sub-terms
************ changed the definition
[Term]
id: MS:1001805
name: quantification datatype
def: "The data type of the value reported in a QuantLayer." [PSI:MS]
is_a: MS:1001129 ! quantification information

************ former childs of MS:1001805
************ are now childs of the new sub-terms of MS:1001805, e.g.
[Term]
id: MS:1001842
name: sequence-level spectral count
def: "The number of MS2 spectra identified for a raw peptide sequence without PTMs and charge state in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1002737 ! peptide-level quantification datatype

[Term]
id: MS:1002733
name: peptide-level spectral count
def: "The number of MS2 spectra identified for a peptide sequence specified by the amino acid one-letter codes plus optional PTMs in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1002737 ! peptide-level quantification datatype

[Term]
id: MS:1002734
name: peptide ion-level spectral count
def: "The number of MS2 spectra identified for a molecular ion defined by the peptide sequence represented by the amino acid one-letter codes, plus optional PTMs plus optional charged aducts plus the charge state, in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1002737 ! peptide-level quantification datatype


New CV terms in version 4.0.7 of psi-ms.obo:
============================================
************ added new sub-childs to MS:1001805
[Term]
id: MS:1002735
name: feature-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a feature." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002736
name: PSM-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a PSM." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002737
name: peptide-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a peptide." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002738
name: protein-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a protein." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002739
name: protein group-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a protein group." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

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

[Psidev-ms-dev] New version 4.0.7 of psi-ms

[mayerg97 <ger...@ru...>]

Dear proteomics community,

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


Changed CV terms in version 4.0.7 of psi-ms.obo:
================================================
************ parent term of the new sub-terms
************ changed the definition
[Term]
id: MS:1001805
name: quantification datatype
def: "The data type of the value reported in a QuantLayer." [PSI:MS]
is_a: MS:1001129 ! quantification information

************ former childs of MS:1001805
************ are now childs of the new sub-terms of MS:1001805, e.g.
[Term]
id: MS:1001842
name: sequence-level spectral count
def: "The number of MS2 spectra identified for a raw peptide sequence 
without PTMs and charge state in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1002737 ! peptide-level quantification datatype

[Term]
id: MS:1002733
name: peptide-level spectral count
def: "The number of MS2 spectra identified for a peptide sequence 
specified by the amino acid one-letter codes plus optional PTMs in 
spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1002737 ! peptide-level quantification datatype

[Term]
id: MS:1002734
name: peptide ion-level spectral count
def: "The number of MS2 spectra identified for a molecular ion defined 
by the peptide sequence represented by the amino acid one-letter codes, 
plus optional PTMs plus optional charged aducts plus the charge state, 
in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1002737 ! peptide-level quantification datatype


New CV terms in version 4.0.7 of psi-ms.obo:
============================================
************ added new sub-childs to MS:1001805
[Term]
id: MS:1002735
name: feature-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a 
feature." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002736
name: PSM-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a PSM." 
[PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002737
name: peptide-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a 
peptide." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002738
name: protein-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a 
protein." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002739
name: protein group-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a protein 
group." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

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

Re: [Psidev-ms-dev] [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

[mayerg97 <ger...@ru...>]

Hallo Andy,

in that case I would simply propose to add some sub-terms to

[Term]
id: MS:1001805
name: quantification datatype
def: "The data type of the value reported in a QuantLayer for a feature, 
peptide, protein, protein group." [PSI:MS]
is_a: MS:1001129 ! quantification information

e.g.

[Term]
id: MS:1002735
name: feature-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a 
feature." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002736
name: PSM-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a PSM." 
[PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002737
name: peptide-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a 
peptide." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002738
name: protein-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a 
protein." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002739
name: protein group-level quantification datatype
def: "The data type of the value reported in a QuantLayer for a protein 
group." [PSI:PI]
is_a: MS:1001805 ! quantification datatype

and to rearrange the current childs of MS:1001805 under these new sub-terms.
Would that make sense to you?

Best regards,
Gerhard


Am 26.01.2017 um 10:47 schrieb Jones, Andy:
>
> Hi Gerhard,
>
> The part I’m not understanding yet is that we have some CV terms that 
> are intended to be for peptides in mzid 1.2, meaning a set of grouped 
> PSMs. Reading software would have to know that they refer to the 
> grouped peptide concept and not the PSM in which it located them. As 
> an example:
>
> [Term]
>
> id: MS:1002551
>
> name: peptide:Ascore
>
> def: "A-score for PTM site location at the peptide-level." [PSI:PI]
>
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
>
> is_a: MS:1002549 ! PTM localization distinct peptide-level statistic
>
> relationship: has_regexp MS:1002505 ! regular expression for 
> modification localization scoring
>
> Which is different from:
>
> [Term]
>
> id: MS:1001985
>
> name: Ascore
>
> def: "A-score for PTM site location at the PSM-level." 
> [DOI:10.1038/nbt1240, PMID:16964243]
>
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
>
> is_a: MS:1001968 ! PTM localization PSM-level statistic
>
> relationship: has_regexp MS:1002505 ! regular expression for 
> modification localization scoring
>
> Somewhere higher up in the hierarchy there should be a branch for PSMs 
> and a branch for peptide level stats or measures. The new terms 
> proposed need to be within the peptide branch, that’s all I was 
> suggesting.
>
> Best wishes
>
> Andy
>
> *From:*mayerg97 [mailto:ger...@ru...]
> *Sent:* 24 January 2017 11:55
> *To:* psi...@li...
> *Subject:* Re: [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews
>
> Hi Andy,
>
> yes I think you're right that the parent term 'spectral count peptide 
> level quantitation' is wrong here,
>
> since we have the following hierarchy:
>
> quantitation analysis summary
>
>     spectral counting quantitation analysis
>
>         spectral count peptide level quantitation
>
> and quantitation analysis summary is defined as "The overall workflow 
> of this quantitation report."
>
>
> On the other side I don't really understand, why the parent 
> 'quantification datatype' is
> not enough, since by the name of the following three terms it should 
> be clear that they
> are intended as spectral count terms for peptides and not PSM's:
>
> [Term]
> id: MS:1001842
> name: sequence-level spectral count
> def: "The number of MS2 spectra identified for a raw peptide sequence 
> without PTMs and charge state in spectral counting." [PSI:PI]
> xref: value-type:xsd\:int "The allowed value-type for this CV term."
> is_a: MS:1001805 ! quantification datatype
>
> [Term]
> id: MS:1002733
> name: peptide-level spectral count
> def: "The number of MS2 spectra identified for a peptide sequence 
> specified by the amino acid one-letter codes plus optional PTMs in 
> spectral counting." [PSI:PI]
> xref: value-type:xsd\:int "The allowed value-type for this CV term."
> is_a: MS:1001805 ! quantification datatype
>
> [Term]
> id: MS:1002734
> name: peptide ion-level spectral count
> def: "The number of MS2 spectra identified for a molecular ion defined 
> by the peptide sequence represented by the amino acid one-letter 
> codes, plus optional PTMs plus optional charged aducts plus the charge 
> state, in spectral counting." [PSI:PI]
> xref: value-type:xsd\:int "The allowed value-type for this CV term."
> is_a: MS:1001805 ! quantification datatype
>
> Best regards,
> Gerhard
>
> Am 20.01.2017 um 12:24 schrieb Jones, Andy:
>
>     Hi Gerhard,
>
>     Thanks for this. Can I check – we want to have these as
>     peptide-level data types. Can you recall the mapping mechanism
>     that would tell reading software that these are for peptides
>     rather than PSMs i.e. they would be repeated for all the PSMs
>     grouped as the same peptide? The parent terms are not completely
>     clear to me.
>
>     Best wishes
>
>     Andy
>
>     *From:*mayerg97 [mailto:ger...@ru...]
>     *Sent:* 20 January 2017 09:41
>     *To:* psi...@li...
>     <mailto:psi...@li...>;
>     psi...@li...
>     <mailto:psi...@li...>;
>     psi...@li...
>     <mailto:psi...@li...>
>     *Subject:* Re: [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews
>
>     Hello all,
>
>     so according Pierre-Alains proposal we would have
>
>     [Term]
>     id: MS:1001842
>     name: sequence-level spectral count
>     def: "The number of MS2 spectra identified for a raw peptide
>     sequence without PTMs and charge state in spectral counting." [PSI:PI]
>     xref: value-type:xsd\:int "The allowed value-type for this CV term."
>     is_a: MS:1001805 ! quantification datatype
>     is_a: MS:1002015 ! spectral count peptide level quantitation
>
>     [Term]
>     id: MS:1002733
>     name: peptide-level spectral count
>     def: "The number of MS2 spectra identified for a peptide sequence
>     specified by the amino acid one-letter codes plus optional PTMs in
>     spectral counting." [PSI:PI]
>     xref: value-type:xsd\:int "The allowed value-type for this CV term."
>     is_a: MS:1001805 ! quantification datatype
>     is_a: MS:1002015 ! spectral count peptide level quantitation
>
>     [Term]
>     id: MS:1002734
>     name: peptide ion-level spectral count
>     def: "The number of MS2 spectra identified for a molecular ion
>     defined by the peptide sequence represented by the amino acid
>     one-letter codes, plus optional PTMs plus optional charged aducts
>     plus the charge state, in spectral counting." [PSI:PI]
>     xref: value-type:xsd\:int "The allowed value-type for this CV term."
>     is_a: MS:1001805 ! quantification datatype
>     is_a: MS:1002015 ! spectral count peptide level quantitation
>
>     any futher comments?
>
>     Best regards,
>     Gerhard
>
>     Am 19.01.2017 um 09:16 schrieb Binz Pierre-Alain:
>
>         Hi all,
>
>         Yep, we are redundantly coming to thosse definitions and
>         interpretations of what those peptidic things are...
>
>
>           A peptide is, according to IUPAC gold book
>           https://goldbook.iupac.org/P04479.html:
>
>
>           Peptides : Amides
>           <https://goldbook.iupac.org/A00266.html> derived from two or
>           more amino carboxylic acid molecules (the same or different)
>           by formation of a covalent bond
>           <https://goldbook.iupac.org/C01384.html> from the carbonyl
>           carbon of one to the nitrogen atom of another with formal
>           loss of water. The term is usually applied to structures
>           formed from α-amino acids, but it includes those derived
>           from any amino carboxylic acid.
>
>         Therefore it includes a combination of all 20 amino acids +
>         all kinds of modifications
>
>         A peptide is not a peptide ion in the sense of a MS ion as it
>         is usually the charge neutral  representation of a combination
>         of a-aminoacids in the case of protein peptides
>
>         What we represent here are either the molecular ion (peptide
>         sequence represented by one-letter codes + optional PTMs +
>         charged aduct (H+) + charge state) which we can call peptide
>         ion   : [ANSpK +2H] 2+  (where Sp is a phosphoserine) which we
>         can interpret with only the sequence with PTMs  ANSpK   or
>         only with the primary sequence with no PTM  ANSK
>
>         My suggestion then is to keep the term peptide as the most
>         generic and does not need to specify whether it carries PTMs
>         or not:
>
>         name: peptide-level spectral
>         count                                           # of  ANSpK
>
>         name: sequence-level spectral count                   # of  ANSK
>
>         name: peptide ion-level  spectral
>         count                                   # of  [ANSpK+2H]2+
>
>         Now if you feel that the term “peptide-level” will be
>         ambiguous (people will not know that peptide sequence and
>         peptide (with or without mods) are different, we can give a
>         clear definition with example or I could recommend using
>         “peptide form level” or “peptide species level” as analogy to
>         protein form or protein species vs protein  (top-down inspired
>         definition), but this adds a new definition and make our
>         filkes larger for no good reasons.
>
>         Pierre-Alain
>
>         *De :*Juan Antonio Vizcaino [mailto:ju...@eb...]
>         *Envoyé :* mercredi 18 janvier 2017 18:23
>         *À :* Eric Deutsch
>         *Cc :* Tobias Ternent; psi...@li...
>         <mailto:psi...@li...>; Robert
>         Chalkley; le...@im...
>         <mailto:le...@im...>;
>         jul...@ru...
>         <mailto:jul...@ru...>; Ghali, Fawaz;
>         mar...@ru... <mailto:mar...@ru...>;
>         mayerg97; Andy Jones; Perkins, Simon;
>         psi...@li...
>         <mailto:psi...@li...>; ju...@ed...
>         <mailto:ju...@ed...>; Eugen Netz; Harald Barsnes
>         *Objet :* Re: [Psidev-pi-dev] mzid 1.2 reviews
>
>         Fine for me. Sorry, I did not realise about what Eric
>         mentioned. He is completely right.
>
>         Cheers,
>
>         Juan
>
>             On 18 Jan 2017, at 17:18, Eric Deutsch
>             <ede...@sy...
>             <mailto:ede...@sy...>> wrote:
>
>             Hi everyone, I agree that splitting this into 3 terms is
>             good. I disagree that we should misuse the term “peptide”
>             and then try to clarify it with a parenthetical
>             expression. I don’t think this is good controlled
>             vocabulary practice. I suspect the true ontology devotees
>             would be horrified by this practice.
>
>             May I suggest that we use the style that I adopted for the
>             mzIdentML CV reorg? This keeps the term name concise, and
>             we should rely on the definition to remove any ambiguity.
>             I suggest these names instead:
>
>             name: distinct peptide sequence-level spectral count
>
>             name: modified peptide sequence-level spectral count
>             name: peptide ion-level spectral count
>
>             What do you think? Does this capture the desired concepts
>             clearly?
>
>             Regards,
>
>             Eric
>
>             *From:*Juan Antonio Vizcaino [mailto:ju...@eb...
>             <mailto:ju...@eb...>]
>             *Sent:*Wednesday, January 18, 2017 1:42 AM
>             *To:*Eric Deutsch <ede...@sy...
>             <mailto:ede...@sy...>>
>             *Cc:*mayerg97 <ger...@ru...
>             <mailto:ger...@ru...>>; Andy Jones
>             <And...@li...
>             <mailto:And...@li...>>;psi...@li...
>             <mailto:psi...@li...>; Perkins,
>             Simon <Sim...@li...
>             <mailto:Sim...@li...>>; Harald Barsnes
>             <Har...@ui... <mailto:Har...@ui...>>;
>             Yasset Perez-Riverol <yp...@eb...
>             <mailto:yp...@eb...>>; Tobias Ternent
>             <to...@eb...
>             <mailto:to...@eb...>>;jul...@ru...
>             <mailto:jul...@ru...>;mar...@ru...
>             <mailto:mar...@ru...>;lfi...@st...
>             <mailto:lfi...@st...>;ju...@ed...
>             <mailto:ju...@ed...>; Eugen Netz
>             <eug...@tu...
>             <mailto:eug...@tu...>>; Mathias Walzer
>             <wa...@in...
>             <mailto:wa...@in...>>; Oliver
>             Kohlbacher <oli...@un...
>             <mailto:oli...@un...>>;le...@im...
>             <mailto:le...@im...>; Robert Chalkley
>             <cha...@cg... <mailto:cha...@cg...>>;
>             Ghali, Fawaz <F....@li...
>             <mailto:F....@li...>>; Salvador Martínez de
>             Bartolomé <sma...@pr...
>             <mailto:sma...@pr...>>;psi...@li...
>             <mailto:psi...@li...>
>             *Subject:*Re: mzid 1.2 reviews
>
>             Hi all,
>
>             I agree with Eric on this. The more clarity the better.
>             What about?
>
>             [Term]
>             id: MS:1001842
>             name: peptide PSM count (peptide as the raw peptide sequence)
>
>             def: "The number of MS2 spectra identified for a given
>             peptide (considering the raw peptide sequence, and merging
>             all charge states, modifications in the same peptide
>             sequence are not considered separately) in spectral
>             counting." [PSI:PI]
>             xref: value-type:xsd\:int "The allowed value-type for this
>             CV term."
>             is_a: MS:1001805 ! quantification datatype
>             is_a: MS:1002015 ! spectral count peptide level quantitation
>
>             [Term]
>             id: MS:1001xxx
>             name: peptide PSM count (peptide as the combination
>             between peptide sequence and modifications)
>             def: "The number of MS2 spectra identified for a given
>             peptide (considering the peptide sequence plus
>             modifications, and merging all charge states) in spectral
>             counting." [PSI:PI]
>             xref: value-type:xsd\:int "The allowed value-type for this
>             CV term."
>             is_a: MS:1001805 ! quantification datatype
>             is_a: MS:1002015 ! spectral count peptide level quantitation
>
>             [Term]
>             id: MS:1001xxx
>             name: peptide PSM count (peptide as the combination
>             between peptide sequence, modifications and charge state)
>
>             def: "The number of MS2 spectra identified for a given
>             peptide (considering the peptide sequence and
>             modifications, and one single charge state) in spectral
>             counting." [PSI:PI]
>             xref: value-type:xsd\:int "The allowed value-type for this
>             CV term."
>             is_a: MS:1001805 ! quantification datatype
>             is_a: MS:1002015 ! spectral count peptide level quantitation
>
>             Of course more variants would need to be created if we
>             would want to mix the definitions above with different
>             charge states, but I think these three definitions would
>             be ok.
>
>             What happens also in the case of ambiguity in the
>             modification position? So, it could be even more complex.
>             But I think this level is probably ok for the current
>             state of things.
>
>             Cheers,
>
>             Juan
>
>                 On 17 Jan 2017, at 15:08, Eric Deutsch
>                 <ede...@sy...
>                 <mailto:ede...@sy...>> wrote:
>
>                 This is pretty good, but I think we should make it
>                 completely clear whether it is the number of PSMs per
>                 peptide sequence, per peptide with modifications, or
>                 per peptide ion (including separate charge states).
>                 The plain word peptide is often used as a standin for
>                 any of these 3 concepts..
>
>                 Thanks,
>
>                 Eric
>
>                 *From:*mayerg97 [mailto:ger...@ru...
>                 <mailto:ger...@ru...>]
>                 *Sent:*Tuesday, January 17, 2017 4:39 AM
>                 *To:*Jones, Andy;psi...@li...
>                 <mailto:psi...@li...>
>                 *Cc:*Juan Antonio Vizcaino (ju...@eb...
>                 <mailto:ju...@eb...>); Perkins, Simon; 'Harald
>                 Barsnes'; 'Yasset Perez-Riverol';to...@eb...
>                 <mailto:to...@eb...>;jul...@ru...
>                 <mailto:jul...@ru...>;mar...@ru...
>                 <mailto:mar...@ru...>;lfi...@st...
>                 <mailto:lfi...@st...>;ju...@ed...
>                 <mailto:ju...@ed...>; Eugen Netz; Mathias Walzer;
>                 Oliver Kohlbacher;le...@im...
>                 <mailto:le...@im...>; 'Robert Chalkley';
>                 Ghali, Fawaz;sma...@pr...
>                 <mailto:sma...@pr...>; 'Eric
>                 Deutsch;psi...@li...
>                 <mailto:psi...@li...>
>                 *Subject:*Re: mzid 1.2 reviews
>
>                 Hi Andy,
>
>                 yes we did a CV restructuring,
>                 seehttps://github.com/HUPO-PSI/mzIdentML/issues/25,
>                 but I think this problem is not related to the
>                 restructuring.
>
>                 What about
>
>                 [Term]
>                 id: MS:1001842
>                 name: peptide PSM count
>                 def: "The number of MS2 spectra identified for this
>                 peptide in spectral counting." [PSI:PI]
>                 xref: value-type:xsd\:int "The allowed value-type for
>                 this CV term."
>                 is_a: MS:1001805 ! quantification datatype
>                 is_a: MS:1002015 ! spectral count peptide level
>                 quantitation
>
>                 Best regards,
>                 Gerhard
>
>                 Am 11.01.2017 um 16:56 schrieb Jones, Andy:
>
>                     Hi all,
>
>                     (Sent to PSI-PI mailing list plus authors of the
>                     mzid paper, in case any of you are not on the
>                     mailing list).
>
>                     We have received 5 reviews of the mzid 1.2
>                     specifications via the PSI process, as well as the
>                     2 reviews received on the manuscript from MCP, for
>                     which it makes sense to consider together. I think
>                     most of these can be addressed fairly simply. I
>                     have already fixed a few typos in the
>                     specification document that were identified, and
>                     made one or two other sensible clarifications to
>                     wording. These changes have been checked into
>                     GitHub. I have started response documents to both
>                     processes in the relevant zip files.
>
>                     *If you would like to contribute, please could you
>                     send me any feedback within one week (by 19^th
>                     Jan) if possible.*After that point, I will submit
>                     the mzid 1.2 specs back to the PSI process (for
>                     which Sylvie the editor recommended minor
>                     corrections), unless anything comes up that needs
>                     extensive further discussion. Once they are
>                     accepted, I will resubmit the paper to MCP, as
>                     reporting the mzid 1.2 final specifications.
>
>                     Just flagging a few points for specific people to
>                     address:
>
>                     -Robert and Alexander: one of the reviewer asks
>                     whether your cross-linking software will export
>                     mzid 1.2, anything you can say here?
>
>                     -Fawaz – one of the reviewers seemed to find some
>                     validation errors with some of our mzid 1.2 files,
>                     please could you take a look
>
>                     -Juan – one of the MCP reviewers suggests we
>                     change the figures. Can you give me a view on
>                     whether you think we need to do this? I’m of the
>                     view to make minor improvements, but not radically
>                     change them.
>
>                     -Gerhard – see response to MCP reviews. One of the
>                     reviewers would like to know how spectral counts
>                     can be added at the peptide-level. I think this
>                     may need a new parent term for one given CV term
>                     (see my notes in the response to reviews doc),
>                     could you take a look?
>
>                     Best wishes
>
>                     Andy
>
>                 --
>
>                 *--------------------------------------------------------------------*
>
>                 *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/>
>
>
>
>
>
>         ------------------------------------------------------------------------------
>
>         Check out the vibrant tech community on one of the world's most
>
>         engaging tech sites, SlashDot.org!http://sdm.link/slashdot
>
>
>
>
>
>         _______________________________________________
>
>         Psidev-ms-vocab mailing list
>
>         Psi...@li...
>         <mailto:Psi...@li...>
>
>         https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab
>
>     -- 
>
>     *--------------------------------------------------------------------*
>
>     *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/>
>
>
>
>
>     ------------------------------------------------------------------------------
>
>     Check out the vibrant tech community on one of the world's most
>
>     engaging tech sites, SlashDot.org!http://sdm.link/slashdot
>
>
>
>
>     _______________________________________________
>
>     Psidev-ms-vocab mailing list
>
>     Psi...@li...
>     <mailto:Psi...@li...>
>
>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab
>
> -- 
>
> *--------------------------------------------------------------------*
>
> *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/>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Psidev-ms-vocab mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab

-- 

*--------------------------------------------------------------------*

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

[Psidev-ms-dev] New version 4.0.6 of psi-ms.obo

[mayerg97 <ger...@ru...>]

Dear proteomics community,

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


Changed CV terms in version 4.0.6 of psi-ms.obo:
================================================
************ Changed
[Term]
id: MS:1001842
name: peptide PSM count
def: "The number of MS2 spectra identified for this peptide in spectral 
counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype

************ into

[Term]
id: MS:1001842
name: sequence-level spectral count
def: "The number of MS2 spectra identified for a raw peptide sequence 
without PTMs and charge state in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype


New CV terms in version 4.0.6 of psi-ms.obo:
============================================
[Term]
id: MS:1002733
name: peptide-level spectral count
def: "The number of MS2 spectra identified for a peptide sequence 
specified by the amino acid one-letter codes plus optional PTMs in 
spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype

[Term]
id: MS:1002734
name: peptide ion-level spectral count
def: "The number of MS2 spectra identified for a molecular ion defined 
by the peptide sequence represented by the amino acid one-letter codes, 
plus optional PTMs plus optional charged aducts plus the charge state, 
in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype

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

Re: [Psidev-ms-dev] [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

[Jones, A. <And...@li...>]

These seem okay to me.
Best wishes
Andy

From: Eric Deutsch [mailto:ede...@sy...]
Sent: 20 January 2017 17:42
To: psi...@li...; psi...@li...; psi...@li...
Subject: Re: [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

I think I would prefer the longer, somewhat more pedantic and explicit names, but I am content enough with these if these have broader support.

Thanks,
Eric


From: mayerg97 [mailto:ger...@ru...<mailto:ger...@ru...>]
Sent: Friday, January 20, 2017 1:41 AM
To: psi...@li...<mailto:psi...@li...>; psi...@li...<mailto:psi...@li...>; psi...@li...<mailto:psi...@li...>
Subject: Re: [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

Hello all,

so according Pierre-Alains proposal we would have

[Term]
id: MS:1001842
name: sequence-level spectral count
def: "The number of MS2 spectra identified for a raw peptide sequence without PTMs and charge state in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002733
name: peptide-level spectral count
def: "The number of MS2 spectra identified for a peptide sequence specified by the amino acid one-letter codes plus optional PTMs in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002734
name: peptide ion-level spectral count
def: "The number of MS2 spectra identified for a molecular ion defined by the peptide sequence represented by the amino acid one-letter codes, plus optional PTMs plus optional charged aducts plus the charge state, in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

any futher comments?

Best regards,
Gerhard
Am 19.01.2017 um 09:16 schrieb Binz Pierre-Alain:
Hi all,
Yep, we are redundantly coming to thosse definitions and interpretations of what those peptidic things are...
A peptide is, according to IUPAC gold book https://goldbook.iupac.org/P04479.html:
Peptides : Amides<https://goldbook.iupac.org/A00266.html> derived from two or more amino carboxylic acid molecules (the same or different) by formation of a covalent bond<https://goldbook.iupac.org/C01384.html> from the carbonyl carbon of one to the nitrogen atom of another with formal loss of water. The term is usually applied to structures formed from α-amino acids, but it includes those derived from any amino carboxylic acid.

Therefore it includes a combination of all 20 amino acids + all kinds of modifications

A peptide is not a peptide ion in the sense of a MS ion as it is usually the charge neutral  representation of a combination of a-aminoacids in the case of protein peptides

What we represent here are either the molecular ion (peptide sequence represented by one-letter codes + optional PTMs + charged aduct (H+) + charge state) which we can call peptide ion   : [ANSpK +2H] 2+  (where Sp is a phosphoserine) which we can interpret with only the sequence with PTMs  ANSpK   or only with the primary sequence with no PTM  ANSK

My suggestion then is to keep the term peptide as the most generic and does not need to specify whether it carries PTMs or not:

name: peptide-level spectral count                                           # of  ANSpK
name: sequence-level spectral count                                       # of  ANSK
name: peptide ion-level  spectral count                                   # of  [ANSpK+2H]2+


Now if you feel that the term “peptide-level” will be ambiguous (people will not know that peptide sequence and peptide (with or without mods) are different, we can give a clear definition with example or I could recommend using “peptide form level” or “peptide species level” as analogy to protein form or protein species vs protein  (top-down inspired definition), but this adds a new definition and make our filkes larger for no good reasons.


Pierre-Alain



De : Juan Antonio Vizcaino [mailto:ju...@eb...]
Envoyé : mercredi 18 janvier 2017 18:23
À : Eric Deutsch
Cc : Tobias Ternent; psi...@li...<mailto:psi...@li...>; Robert Chalkley; le...@im...<mailto:le...@im...>; jul...@ru...<mailto:jul...@ru...>; Ghali, Fawaz; mar...@ru...<mailto:mar...@ru...>; mayerg97; Andy Jones; Perkins, Simon; psi...@li...<mailto:psi...@li...>; ju...@ed...<mailto:ju...@ed...>; Eugen Netz; Harald Barsnes
Objet : Re: [Psidev-pi-dev] mzid 1.2 reviews

Fine for me. Sorry, I did not realise about what Eric mentioned. He is completely right.

Cheers,

Juan



On 18 Jan 2017, at 17:18, Eric Deutsch <ede...@sy...<mailto:ede...@sy...>> wrote:

Hi everyone, I agree that splitting this into 3 terms is good. I disagree that we should misuse the term “peptide” and then try to clarify it with a parenthetical expression. I don’t think this is good controlled vocabulary practice. I suspect the true ontology devotees would be horrified by this practice.

May I suggest that we use the style that I adopted for the mzIdentML CV reorg? This keeps the term name concise, and we should rely on the definition to remove any ambiguity. I suggest these names instead:

name: distinct peptide sequence-level spectral count
name: modified peptide sequence-level spectral count
name: peptide ion-level spectral count

What do you think? Does this capture the desired concepts clearly?

Regards,
Eric



From: Juan Antonio Vizcaino [mailto:ju...@eb...<mailto:ju...@eb...>]
Sent: Wednesday, January 18, 2017 1:42 AM
To: Eric Deutsch <ede...@sy...<mailto:ede...@sy...>>
Cc: mayerg97 <ger...@ru...<mailto:ger...@ru...>>; Andy Jones <And...@li...<mailto:And...@li...>>; psi...@li...<mailto:psi...@li...>; Perkins, Simon <Sim...@li...<mailto:Sim...@li...>>; Harald Barsnes <Har...@ui...<mailto:Har...@ui...>>; Yasset Perez-Riverol <yp...@eb...<mailto:yp...@eb...>>; Tobias Ternent <to...@eb...<mailto:to...@eb...>>; jul...@ru...<mailto:jul...@ru...>; mar...@ru...<mailto:mar...@ru...>; lfi...@st...<mailto:lfi...@st...>; ju...@ed...<mailto:ju...@ed...>; Eugen Netz <eug...@tu...<mailto:eug...@tu...>>; Mathias Walzer <wa...@in...<mailto:wa...@in...>>; Oliver Kohlbacher <oli...@un...<mailto:oli...@un...>>; le...@im...<mailto:le...@im...>; Robert Chalkley <cha...@cg...<mailto:cha...@cg...>>; Ghali, Fawaz <F....@li...<mailto:F....@li...>>; Salvador Martínez de Bartolomé <sma...@pr...<mailto:sma...@pr...>>; psi...@li...<mailto:psi...@li...>
Subject: Re: mzid 1.2 reviews

Hi all,

I agree with Eric on this. The more clarity the better. What about?

[Term]
id: MS:1001842
name: peptide PSM count (peptide as the raw peptide sequence)
def: "The number of MS2 spectra identified for a given peptide (considering the raw peptide sequence, and merging all charge states, modifications in the same peptide sequence are not considered separately) in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1001xxx
name: peptide PSM count (peptide as the combination between peptide sequence and modifications)
def: "The number of MS2 spectra identified for a given peptide (considering the peptide sequence plus modifications, and merging all charge states) in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1001xxx
name: peptide PSM count (peptide as the combination between peptide sequence, modifications and charge state)
def: "The number of MS2 spectra identified for a given peptide (considering the peptide sequence and modifications, and one single charge state) in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

Of course more variants would need to be created if we would want to mix the definitions above with different charge states, but I think these three definitions would be ok.

What happens also in the case of ambiguity in the modification position? So, it could be even more complex. But I think this level is probably ok for the current state of things.

Cheers,

Juan



On 17 Jan 2017, at 15:08, Eric Deutsch <ede...@sy...<mailto:ede...@sy...>> wrote:

This is pretty good, but I think we should make it completely clear whether it is the number of PSMs per peptide sequence, per peptide with modifications, or per peptide ion (including separate charge states). The plain word peptide is often used as a standin for any of these 3 concepts..

Thanks,
Eric


From: mayerg97 [mailto:ger...@ru...<mailto:ger...@ru...>]
Sent: Tuesday, January 17, 2017 4:39 AM
To: Jones, Andy; psi...@li...<mailto:psi...@li...>
Cc: Juan Antonio Vizcaino (ju...@eb...<mailto:ju...@eb...>); Perkins, Simon; 'Harald Barsnes'; 'Yasset Perez-Riverol'; to...@eb...<mailto:to...@eb...>; jul...@ru...<mailto:jul...@ru...>; mar...@ru...<mailto:mar...@ru...>; lfi...@st...<mailto:lfi...@st...>; ju...@ed...<mailto:ju...@ed...>; Eugen Netz; Mathias Walzer; Oliver Kohlbacher; le...@im...<mailto:le...@im...>; 'Robert Chalkley'; Ghali, Fawaz; sma...@pr...<mailto:sma...@pr...>; 'Eric Deutsch; psi...@li...<mailto:psi...@li...>
Subject: Re: mzid 1.2 reviews

Hi Andy,

yes we did a CV restructuring, see https://github.com/HUPO-PSI/mzIdentML/issues/25,
but I think this problem is not related to the restructuring.

What about

[Term]
id: MS:1001842
name: peptide PSM count
def: "The number of MS2 spectra identified for this peptide in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

Best regards,
Gerhard
Am 11.01.2017 um 16:56 schrieb Jones, Andy:
Hi all,

(Sent to PSI-PI mailing list plus authors of the mzid paper, in case any of you are not on the mailing list).

We have received 5 reviews of the mzid 1.2 specifications via the PSI process, as well as the 2 reviews received on the manuscript from MCP, for which it makes sense to consider together. I think most of these can be addressed fairly simply. I have already fixed a few typos in the specification document that were identified, and made one or two other sensible clarifications to wording. These changes have been checked into GitHub. I have started response documents to both processes in the relevant zip files.

If you would like to contribute, please could you send me any feedback within one week (by 19th Jan) if possible. After that point, I will submit the mzid 1.2 specs back to the PSI process (for which Sylvie the editor recommended minor corrections), unless anything comes up that needs extensive further discussion. Once they are accepted, I will resubmit the paper to MCP, as reporting the mzid 1.2 final specifications.

Just flagging a few points for specific people to address:

-          Robert and Alexander: one of the reviewer asks whether your cross-linking software will export mzid 1.2, anything you can say here?
-          Fawaz – one of the reviewers seemed to find some validation errors with some of our mzid 1.2 files, please could you take a look
-          Juan – one of the MCP reviewers suggests we change the figures. Can you give me a view on whether you think we need to do this? I’m of the view to make minor improvements, but not radically change them.
-          Gerhard – see response to MCP reviews. One of the reviewers would like to know how spectral counts can be added at the peptide-level. I think this may need a new parent term for one given CV term (see my notes in the response to reviews doc), could you take a look?

Best wishes
Andy





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




------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, SlashDot.org! http://sdm.link/slashdot



_______________________________________________

Psidev-ms-vocab mailing list

Psi...@li...<mailto:Psi...@li...>

https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab

--

--------------------------------------------------------------------

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

Re: [Psidev-ms-dev] [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

[Eric D. <ede...@sy...>]

I think I would prefer the longer, somewhat more pedantic and explicit
names, but I am content enough with these if these have broader support.



Thanks,

Eric





*From:* mayerg97 [mailto:ger...@ru...]
*Sent:* Friday, January 20, 2017 1:41 AM
*To:* psi...@li...;
psi...@li...; psi...@li...
*Subject:* Re: [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews



Hello all,

so according Pierre-Alains proposal we would have

[Term]
id: MS:1001842
name: sequence-level spectral count
def: "The number of MS2 spectra identified for a raw peptide sequence
without PTMs and charge state in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002733
name: peptide-level spectral count
def: "The number of MS2 spectra identified for a peptide sequence specified
by the amino acid one-letter codes plus optional PTMs in spectral
counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002734
name: peptide ion-level spectral count
def: "The number of MS2 spectra identified for a molecular ion defined by
the peptide sequence represented by the amino acid one-letter codes, plus
optional PTMs plus optional charged aducts plus the charge state, in
spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

any futher comments?

Best regards,
Gerhard

Am 19.01.2017 um 09:16 schrieb Binz Pierre-Alain:

Hi all,

Yep, we are redundantly coming to thosse definitions and interpretations of
what those peptidic things are...
A peptide is, according to IUPAC gold book
https://goldbook.iupac.org/P04479.html:Peptides : Amides
<https://goldbook.iupac.org/A00266.html> derived from two or more amino
carboxylic acid molecules (the same or different) by formation of a covalent
bond <https://goldbook.iupac.org/C01384.html> from the carbonyl carbon of
one to the nitrogen atom of another with formal loss of water. The term is
usually applied to structures formed from α-amino acids, but it includes
those derived from any amino carboxylic acid.



Therefore it includes a combination of all 20 amino acids + all kinds of
modifications



A peptide is not a peptide ion in the sense of a MS ion as it is usually
the charge neutral  representation of a combination of a-aminoacids in the
case of protein peptides



What we represent here are either the molecular ion (peptide sequence
represented by one-letter codes + optional PTMs + charged aduct (H+) +
charge state) which we can call peptide ion   : [ANSpK +2H] 2+  (where Sp
is a phosphoserine) which we can interpret with only the sequence with
PTMs  ANSpK   or only with the primary sequence with no PTM  ANSK



My suggestion then is to keep the term peptide as the most generic and does
not need to specify whether it carries PTMs or not:



name: peptide-level spectral
count                                           # of  ANSpK

name: sequence-level spectral count                                       #
of  ANSK

name: peptide ion-level  spectral count                                   #
of  [ANSpK+2H]2+





Now if you feel that the term “peptide-level” will be ambiguous (people
will not know that peptide sequence and peptide (with or without mods) are
different, we can give a clear definition with example or I could recommend
using “peptide form level” or “peptide species level” as analogy to protein
form or protein species vs protein  (top-down inspired definition), but
this adds a new definition and make our filkes larger for no good reasons.





Pierre-Alain







*De :* Juan Antonio Vizcaino [mailto:ju...@eb... <ju...@eb...>]
*Envoyé :* mercredi 18 janvier 2017 18:23
*À :* Eric Deutsch
*Cc :* Tobias Ternent; psi...@li...; Robert
Chalkley; le...@im...; jul...@ru...;
Ghali, Fawaz; mar...@ru...; mayerg97; Andy Jones; Perkins,
Simon; psi...@li...; ju...@ed...; Eugen Netz;
Harald Barsnes
*Objet :* Re: [Psidev-pi-dev] mzid 1.2 reviews



Fine for me. Sorry, I did not realise about what Eric mentioned. He is
completely right.



Cheers,



Juan







On 18 Jan 2017, at 17:18, Eric Deutsch <ede...@sy...> wrote:



Hi everyone, I agree that splitting this into 3 terms is good. I disagree
that we should misuse the term “peptide” and then try to clarify it with a
parenthetical expression. I don’t think this is good controlled vocabulary
practice. I suspect the true ontology devotees would be horrified by this
practice.



May I suggest that we use the style that I adopted for the mzIdentML CV
reorg? This keeps the term name concise, and we should rely on the
definition to remove any ambiguity. I suggest these names instead:



name: distinct peptide sequence-level spectral count

name: modified peptide sequence-level spectral count
name: peptide ion-level spectral count



What do you think? Does this capture the desired concepts clearly?



Regards,

Eric







*From:* Juan Antonio Vizcaino [mailto:ju...@eb...]
*Sent:* Wednesday, January 18, 2017 1:42 AM
*To:* Eric Deutsch <ede...@sy...>
*Cc:* mayerg97 <ger...@ru...>; Andy Jones <
And...@li...>; psi...@li...;
Perkins, Simon <Sim...@li...>; Harald Barsnes <
Har...@ui...>; Yasset Perez-Riverol <yp...@eb...>; Tobias
Ternent <to...@eb...>; jul...@ru...;
mar...@ru...; lfi...@st...; ju...@ed...; Eugen
Netz <eug...@tu...>; Mathias Walzer <
wa...@in...>; Oliver Kohlbacher <
oli...@un...>; le...@im...; Robert
Chalkley <cha...@cg...>; Ghali, Fawaz <F....@li...>;
Salvador Martínez de Bartolomé <sma...@pr...>;
psi...@li...
*Subject:* Re: mzid 1.2 reviews



Hi all,



I agree with Eric on this. The more clarity the better. What about?



[Term]
id: MS:1001842
name: peptide PSM count (peptide as the raw peptide sequence)

def: "The number of MS2 spectra identified for a given peptide (considering
the raw peptide sequence, and merging all charge states, modifications in
the same peptide sequence are not considered separately) in spectral
counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation



[Term]
id: MS:1001xxx
name: peptide PSM count (peptide as the combination between peptide
sequence and modifications)
def: "The number of MS2 spectra identified for a given peptide (considering
the peptide sequence plus modifications, and merging all charge states) in
spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation



[Term]
id: MS:1001xxx
name: peptide PSM count (peptide as the combination between peptide
sequence, modifications and charge state)

def: "The number of MS2 spectra identified for a given peptide (considering
the peptide sequence and modifications, and one single charge state) in
spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation



Of course more variants would need to be created if we would want to mix
the definitions above with different charge states, but I think these three
definitions would be ok.



What happens also in the case of ambiguity in the modification position?
So, it could be even more complex. But I think this level is probably ok
for the current state of things.



Cheers,



Juan







On 17 Jan 2017, at 15:08, Eric Deutsch <ede...@sy...> wrote:



This is pretty good, but I think we should make it completely clear whether
it is the number of PSMs per peptide sequence, per peptide with
modifications, or per peptide ion (including separate charge states). The
plain word peptide is often used as a standin for any of these 3 concepts..



Thanks,

Eric





*From:* mayerg97 [mailto:ger...@ru...]
*Sent:* Tuesday, January 17, 2017 4:39 AM
*To:* Jones, Andy; psi...@li...
*Cc:* Juan Antonio Vizcaino (ju...@eb...); Perkins, Simon; 'Harald
Barsnes'; 'Yasset Perez-Riverol'; to...@eb...;
jul...@ru...; mar...@ru...;
lfi...@st...; ju...@ed...; Eugen Netz; Mathias Walzer;
Oliver Kohlbacher; le...@im...; 'Robert Chalkley'; Ghali,
Fawaz; sma...@pr...; 'Eric Deutsch;
psi...@li...
*Subject:* Re: mzid 1.2 reviews



Hi Andy,

yes we did a CV restructuring, see
https://github.com/HUPO-PSI/mzIdentML/issues/25,
but I think this problem is not related to the restructuring.

What about

[Term]
id: MS:1001842
name: peptide PSM count
def: "The number of MS2 spectra identified for this peptide in spectral
counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

Best regards,
Gerhard

Am 11.01.2017 um 16:56 schrieb Jones, Andy:

Hi all,



(Sent to PSI-PI mailing list plus authors of the mzid paper, in case any of
you are not on the mailing list).



We have received 5 reviews of the mzid 1.2 specifications via the PSI
process, as well as the 2 reviews received on the manuscript from MCP, for
which it makes sense to consider together. I think most of these can be
addressed fairly simply. I have already fixed a few typos in the
specification document that were identified, and made one or two other
sensible clarifications to wording. These changes have been checked into
GitHub. I have started response documents to both processes in the relevant
zip files.



*If you would like to contribute, please could you send me any feedback
within one week (by 19th Jan) if possible. *After that point, I will submit
the mzid 1.2 specs back to the PSI process (for which Sylvie the editor
recommended minor corrections), unless anything comes up that needs
extensive further discussion. Once they are accepted, I will resubmit the
paper to MCP, as reporting the mzid 1.2 final specifications.



Just flagging a few points for specific people to address:



-          Robert and Alexander: one of the reviewer asks whether your
cross-linking software will export mzid 1.2, anything you can say here?

-          Fawaz – one of the reviewers seemed to find some validation
errors with some of our mzid 1.2 files, please could you take a look

-          Juan – one of the MCP reviewers suggests we change the figures.
Can you give me a view on whether you think we need to do this? I’m of the
view to make minor improvements, but not radically change them.

-          Gerhard – see response to MCP reviews. One of the reviewers
would like to know how spectral counts can be added at the peptide-level. I
think this may need a new parent term for one given CV term (see my notes
in the response to reviews doc), could you take a look?



Best wishes

Andy











-- 

*--------------------------------------------------------------------*

*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...

www.medizinisches-proteom-center.de






------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, SlashDot.org! http://sdm.link/slashdot




_______________________________________________

Psidev-ms-vocab mailing list

Psi...@li...

https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab



-- 

*--------------------------------------------------------------------*

*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...

www.medizinisches-proteom-center.de

Re: [Psidev-ms-dev] [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

[Jones, A. <And...@li...>]

Hi Gerhard,

Thanks for this. Can I check – we want to have these as peptide-level data types. Can you recall the mapping mechanism that would tell reading software that these are for peptides rather than PSMs i.e. they would be repeated for all the PSMs grouped as the same peptide? The parent terms are not completely clear to me.

Best wishes
Andy

From: mayerg97 [mailto:ger...@ru...]
Sent: 20 January 2017 09:41
To: psi...@li...; psi...@li...; psi...@li...
Subject: Re: [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

Hello all,

so according Pierre-Alains proposal we would have

[Term]
id: MS:1001842
name: sequence-level spectral count
def: "The number of MS2 spectra identified for a raw peptide sequence without PTMs and charge state in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002733
name: peptide-level spectral count
def: "The number of MS2 spectra identified for a peptide sequence specified by the amino acid one-letter codes plus optional PTMs in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002734
name: peptide ion-level spectral count
def: "The number of MS2 spectra identified for a molecular ion defined by the peptide sequence represented by the amino acid one-letter codes, plus optional PTMs plus optional charged aducts plus the charge state, in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

any futher comments?

Best regards,
Gerhard
Am 19.01.2017 um 09:16 schrieb Binz Pierre-Alain:
Hi all,
Yep, we are redundantly coming to thosse definitions and interpretations of what those peptidic things are...
A peptide is, according to IUPAC gold book https://goldbook.iupac.org/P04479.html:
Peptides : Amides<https://goldbook.iupac.org/A00266.html> derived from two or more amino carboxylic acid molecules (the same or different) by formation of a covalent bond<https://goldbook.iupac.org/C01384.html> from the carbonyl carbon of one to the nitrogen atom of another with formal loss of water. The term is usually applied to structures formed from α-amino acids, but it includes those derived from any amino carboxylic acid.

Therefore it includes a combination of all 20 amino acids + all kinds of modifications

A peptide is not a peptide ion in the sense of a MS ion as it is usually the charge neutral  representation of a combination of a-aminoacids in the case of protein peptides

What we represent here are either the molecular ion (peptide sequence represented by one-letter codes + optional PTMs + charged aduct (H+) + charge state) which we can call peptide ion   : [ANSpK +2H] 2+  (where Sp is a phosphoserine) which we can interpret with only the sequence with PTMs  ANSpK   or only with the primary sequence with no PTM  ANSK

My suggestion then is to keep the term peptide as the most generic and does not need to specify whether it carries PTMs or not:

name: peptide-level spectral count                                           # of  ANSpK
name: sequence-level spectral count                                       # of  ANSK
name: peptide ion-level  spectral count                                   # of  [ANSpK+2H]2+


Now if you feel that the term “peptide-level” will be ambiguous (people will not know that peptide sequence and peptide (with or without mods) are different, we can give a clear definition with example or I could recommend using “peptide form level” or “peptide species level” as analogy to protein form or protein species vs protein  (top-down inspired definition), but this adds a new definition and make our filkes larger for no good reasons.


Pierre-Alain



De : Juan Antonio Vizcaino [mailto:ju...@eb...]
Envoyé : mercredi 18 janvier 2017 18:23
À : Eric Deutsch
Cc : Tobias Ternent; psi...@li...<mailto:psi...@li...>; Robert Chalkley; le...@im...<mailto:le...@im...>; jul...@ru...<mailto:jul...@ru...>; Ghali, Fawaz; mar...@ru...<mailto:mar...@ru...>; mayerg97; Andy Jones; Perkins, Simon; psi...@li...<mailto:psi...@li...>; ju...@ed...<mailto:ju...@ed...>; Eugen Netz; Harald Barsnes
Objet : Re: [Psidev-pi-dev] mzid 1.2 reviews

Fine for me. Sorry, I did not realise about what Eric mentioned. He is completely right.

Cheers,

Juan



On 18 Jan 2017, at 17:18, Eric Deutsch <ede...@sy...<mailto:ede...@sy...>> wrote:

Hi everyone, I agree that splitting this into 3 terms is good. I disagree that we should misuse the term “peptide” and then try to clarify it with a parenthetical expression. I don’t think this is good controlled vocabulary practice. I suspect the true ontology devotees would be horrified by this practice.

May I suggest that we use the style that I adopted for the mzIdentML CV reorg? This keeps the term name concise, and we should rely on the definition to remove any ambiguity. I suggest these names instead:

name: distinct peptide sequence-level spectral count
name: modified peptide sequence-level spectral count
name: peptide ion-level spectral count

What do you think? Does this capture the desired concepts clearly?

Regards,
Eric



From: Juan Antonio Vizcaino [mailto:ju...@eb...<mailto:ju...@eb...>]
Sent: Wednesday, January 18, 2017 1:42 AM
To: Eric Deutsch <ede...@sy...<mailto:ede...@sy...>>
Cc: mayerg97 <ger...@ru...<mailto:ger...@ru...>>; Andy Jones <And...@li...<mailto:And...@li...>>; psi...@li...<mailto:psi...@li...>; Perkins, Simon <Sim...@li...<mailto:Sim...@li...>>; Harald Barsnes <Har...@ui...<mailto:Har...@ui...>>; Yasset Perez-Riverol <yp...@eb...<mailto:yp...@eb...>>; Tobias Ternent <to...@eb...<mailto:to...@eb...>>; jul...@ru...<mailto:jul...@ru...>; mar...@ru...<mailto:mar...@ru...>; lfi...@st...<mailto:lfi...@st...>; ju...@ed...<mailto:ju...@ed...>; Eugen Netz <eug...@tu...<mailto:eug...@tu...>>; Mathias Walzer <wa...@in...<mailto:wa...@in...>>; Oliver Kohlbacher <oli...@un...<mailto:oli...@un...>>; le...@im...<mailto:le...@im...>; Robert Chalkley <cha...@cg...<mailto:cha...@cg...>>; Ghali, Fawaz <F....@li...<mailto:F....@li...>>; Salvador Martínez de Bartolomé <sma...@pr...<mailto:sma...@pr...>>; psi...@li...<mailto:psi...@li...>
Subject: Re: mzid 1.2 reviews

Hi all,

I agree with Eric on this. The more clarity the better. What about?

[Term]
id: MS:1001842
name: peptide PSM count (peptide as the raw peptide sequence)
def: "The number of MS2 spectra identified for a given peptide (considering the raw peptide sequence, and merging all charge states, modifications in the same peptide sequence are not considered separately) in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1001xxx
name: peptide PSM count (peptide as the combination between peptide sequence and modifications)
def: "The number of MS2 spectra identified for a given peptide (considering the peptide sequence plus modifications, and merging all charge states) in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1001xxx
name: peptide PSM count (peptide as the combination between peptide sequence, modifications and charge state)
def: "The number of MS2 spectra identified for a given peptide (considering the peptide sequence and modifications, and one single charge state) in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

Of course more variants would need to be created if we would want to mix the definitions above with different charge states, but I think these three definitions would be ok.

What happens also in the case of ambiguity in the modification position? So, it could be even more complex. But I think this level is probably ok for the current state of things.

Cheers,

Juan



On 17 Jan 2017, at 15:08, Eric Deutsch <ede...@sy...<mailto:ede...@sy...>> wrote:

This is pretty good, but I think we should make it completely clear whether it is the number of PSMs per peptide sequence, per peptide with modifications, or per peptide ion (including separate charge states). The plain word peptide is often used as a standin for any of these 3 concepts..

Thanks,
Eric


From: mayerg97 [mailto:ger...@ru...<mailto:ger...@ru...>]
Sent: Tuesday, January 17, 2017 4:39 AM
To: Jones, Andy; psi...@li...<mailto:psi...@li...>
Cc: Juan Antonio Vizcaino (ju...@eb...<mailto:ju...@eb...>); Perkins, Simon; 'Harald Barsnes'; 'Yasset Perez-Riverol'; to...@eb...<mailto:to...@eb...>; jul...@ru...<mailto:jul...@ru...>; mar...@ru...<mailto:mar...@ru...>; lfi...@st...<mailto:lfi...@st...>; ju...@ed...<mailto:ju...@ed...>; Eugen Netz; Mathias Walzer; Oliver Kohlbacher; le...@im...<mailto:le...@im...>; 'Robert Chalkley'; Ghali, Fawaz; sma...@pr...<mailto:sma...@pr...>; 'Eric Deutsch; psi...@li...<mailto:psi...@li...>
Subject: Re: mzid 1.2 reviews

Hi Andy,

yes we did a CV restructuring, see https://github.com/HUPO-PSI/mzIdentML/issues/25,
but I think this problem is not related to the restructuring.

What about

[Term]
id: MS:1001842
name: peptide PSM count
def: "The number of MS2 spectra identified for this peptide in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

Best regards,
Gerhard
Am 11.01.2017 um 16:56 schrieb Jones, Andy:
Hi all,

(Sent to PSI-PI mailing list plus authors of the mzid paper, in case any of you are not on the mailing list).

We have received 5 reviews of the mzid 1.2 specifications via the PSI process, as well as the 2 reviews received on the manuscript from MCP, for which it makes sense to consider together. I think most of these can be addressed fairly simply. I have already fixed a few typos in the specification document that were identified, and made one or two other sensible clarifications to wording. These changes have been checked into GitHub. I have started response documents to both processes in the relevant zip files.

If you would like to contribute, please could you send me any feedback within one week (by 19th Jan) if possible. After that point, I will submit the mzid 1.2 specs back to the PSI process (for which Sylvie the editor recommended minor corrections), unless anything comes up that needs extensive further discussion. Once they are accepted, I will resubmit the paper to MCP, as reporting the mzid 1.2 final specifications.

Just flagging a few points for specific people to address:

-          Robert and Alexander: one of the reviewer asks whether your cross-linking software will export mzid 1.2, anything you can say here?
-          Fawaz – one of the reviewers seemed to find some validation errors with some of our mzid 1.2 files, please could you take a look
-          Juan – one of the MCP reviewers suggests we change the figures. Can you give me a view on whether you think we need to do this? I’m of the view to make minor improvements, but not radically change them.
-          Gerhard – see response to MCP reviews. One of the reviewers would like to know how spectral counts can be added at the peptide-level. I think this may need a new parent term for one given CV term (see my notes in the response to reviews doc), could you take a look?

Best wishes
Andy





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





------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, SlashDot.org! http://sdm.link/slashdot




_______________________________________________

Psidev-ms-vocab mailing list

Psi...@li...<mailto:Psi...@li...>

https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab

--

--------------------------------------------------------------------

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

Re: [Psidev-ms-dev] [Psidev-ms-vocab] [Psidev-pi-dev] mzid 1.2 reviews

[mayerg97 <ger...@ru...>]

Hello all,

so according Pierre-Alains proposal we would have

[Term]
id: MS:1001842
name: sequence-level spectral count
def: "The number of MS2 spectra identified for a raw peptide sequence 
without PTMs and charge state in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002733
name: peptide-level spectral count
def: "The number of MS2 spectra identified for a peptide sequence 
specified by the amino acid one-letter codes plus optional PTMs in 
spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

[Term]
id: MS:1002734
name: peptide ion-level spectral count
def: "The number of MS2 spectra identified for a molecular ion defined 
by the peptide sequence represented by the amino acid one-letter codes, 
plus optional PTMs plus optional charged aducts plus the charge state, 
in spectral counting." [PSI:PI]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1001805 ! quantification datatype
is_a: MS:1002015 ! spectral count peptide level quantitation

any futher comments?

Best regards,
Gerhard

Am 19.01.2017 um 09:16 schrieb Binz Pierre-Alain:
>
> Hi all,
>
> Yep, we are redundantly coming to thosse definitions and 
> interpretations of what those peptidic things are...
>
>
>   A peptide is, according to IUPAC gold book
>   https://goldbook.iupac.org/P04479.html:
>
>
>   Peptides : Amides <https://goldbook.iupac.org/A00266.html> derived
>   from two or more amino carboxylic acid molecules (the same or
>   different) by formation of a covalent bond
>   <https://goldbook.iupac.org/C01384.html> from the carbonyl carbon of
>   one to the nitrogen atom of another with formal loss of water. The
>   term is usually applied to structures formed from α-amino acids, but
>   it includes those derived from any amino carboxylic acid.
>
> Therefore it includes a combination of all 20 amino acids + all kinds 
> of modifications
>
> A peptide is not a peptide ion in the sense of a MS ion as it is 
> usually the charge neutral  representation of a combination of 
> a-aminoacids in the case of protein peptides
>
> What we represent here are either the molecular ion (peptide sequence 
> represented by one-letter codes + optional PTMs + charged aduct (H+) + 
> charge state) which we can call peptide ion   : [ANSpK +2H] 2+  (where 
> Sp is a phosphoserine) which we can interpret with only the sequence 
> with PTMs  ANSpK   or only with the primary sequence with no PTM  ANSK
>
> My suggestion then is to keep the term peptide as the most generic and 
> does not need to specify whether it carries PTMs or not:
>
> name: peptide-level spectral 
> count                                           # of  ANSpK
>
> name: sequence-level spectral count                     
>                   # of  ANSK
>
> name: peptide ion-level  spectral 
> count                                   # of  [ANSpK+2H]2+
>
> Now if you feel that the term “peptide-level” will be ambiguous 
> (people will not know that peptide sequence and peptide (with or 
> without mods) are different, we can give a clear definition with 
> example or I could recommend using “peptide form level” or “peptide 
> species level” as analogy to protein form or protein species vs 
> protein  (top-down inspired definition), but this adds a new 
> definition and make our filkes larger for no good reasons.
>
> Pierre-Alain
>
> *De :*Juan Antonio Vizcaino [mailto:ju...@eb...]
> *Envoyé :* mercredi 18 janvier 2017 18:23
> *À :* Eric Deutsch
> *Cc :* Tobias Ternent; psi...@li...; Robert 
> Chalkley; le...@im...; 
> jul...@ru...; Ghali, Fawaz; 
> mar...@ru...; mayerg97; Andy Jones; Perkins, Simon; 
> psi...@li...; ju...@ed...; Eugen Netz; Harald 
> Barsnes
> *Objet :* Re: [Psidev-pi-dev] mzid 1.2 reviews
>
> Fine for me. Sorry, I did not realise about what Eric mentioned. He is 
> completely right.
>
> Cheers,
>
> Juan
>
>     On 18 Jan 2017, at 17:18, Eric Deutsch
>     <ede...@sy... <mailto:ede...@sy...>>
>     wrote:
>
>     Hi everyone, I agree that splitting this into 3 terms is good. I
>     disagree that we should misuse the term “peptide” and then try to
>     clarify it with a parenthetical expression. I don’t think this is
>     good controlled vocabulary practice. I suspect the true ontology
>     devotees would be horrified by this practice.
>
>     May I suggest that we use the style that I adopted for the
>     mzIdentML CV reorg? This keeps the term name concise, and we
>     should rely on the definition to remove any ambiguity. I suggest
>     these names instead:
>
>     name: distinct peptide sequence-level spectral count
>
>     name: modified peptide sequence-level spectral count
>     name: peptide ion-level spectral count
>
>     What do you think? Does this capture the desired concepts clearly?
>
>     Regards,
>
>     Eric
>
>     *From:*Juan Antonio Vizcaino [mailto:ju...@eb...
>     <mailto:ju...@eb...>]
>     *Sent:*Wednesday, January 18, 2017 1:42 AM
>     *To:*Eric Deutsch <ede...@sy...
>     <mailto:ede...@sy...>>
>     *Cc:*mayerg97 <ger...@ru...
>     <mailto:ger...@ru...>>; Andy Jones
>     <And...@li...
>     <mailto:And...@li...>>;psi...@li...
>     <mailto:psi...@li...>; Perkins, Simon
>     <Sim...@li...
>     <mailto:Sim...@li...>>; Harald Barsnes
>     <Har...@ui... <mailto:Har...@ui...>>; Yasset
>     Perez-Riverol <yp...@eb... <mailto:yp...@eb...>>; Tobias
>     Ternent <to...@eb...
>     <mailto:to...@eb...>>;jul...@ru...
>     <mailto:jul...@ru...>;mar...@ru...
>     <mailto:mar...@ru...>;lfi...@st...
>     <mailto:lfi...@st...>;ju...@ed...
>     <mailto:ju...@ed...>; Eugen Netz <eug...@tu...
>     <mailto:eug...@tu...>>; Mathias Walzer
>     <wa...@in...
>     <mailto:wa...@in...>>; Oliver Kohlbacher
>     <oli...@un...
>     <mailto:oli...@un...>>;le...@im...
>     <mailto:le...@im...>; Robert Chalkley
>     <cha...@cg... <mailto:cha...@cg...>>; Ghali,
>     Fawaz <F....@li... <mailto:F....@li...>>;
>     Salvador Martínez de Bartolomé <sma...@pr...
>     <mailto:sma...@pr...>>;psi...@li...
>     <mailto:psi...@li...>
>     *Subject:*Re: mzid 1.2 reviews
>
>     Hi all,
>
>     I agree with Eric on this. The more clarity the better. What about?
>
>     [Term]
>     id: MS:1001842
>     name: peptide PSM count (peptide as the raw peptide sequence)
>
>     def: "The number of MS2 spectra identified for a given peptide
>     (considering the raw peptide sequence, and merging all charge
>     states, modifications in the same peptide sequence are not
>     considered separately) in spectral counting." [PSI:PI]
>     xref: value-type:xsd\:int "The allowed value-type for this CV term."
>     is_a: MS:1001805 ! quantification datatype
>     is_a: MS:1002015 ! spectral count peptide level quantitation
>
>     [Term]
>     id: MS:1001xxx
>     name: peptide PSM count (peptide as the combination between
>     peptide sequence and modifications)
>     def: "The number of MS2 spectra identified for a given peptide
>     (considering the peptide sequence plus modifications, and merging
>     all charge states) in spectral counting." [PSI:PI]
>     xref: value-type:xsd\:int "The allowed value-type for this CV term."
>     is_a: MS:1001805 ! quantification datatype
>     is_a: MS:1002015 ! spectral count peptide level quantitation
>
>     [Term]
>     id: MS:1001xxx
>     name: peptide PSM count (peptide as the combination
>     between peptide sequence, modifications and charge state)
>
>     def: "The number of MS2 spectra identified for a given peptide
>     (considering the peptide sequence and modifications, and one
>     single charge state) in spectral counting." [PSI:PI]
>     xref: value-type:xsd\:int "The allowed value-type for this CV term."
>     is_a: MS:1001805 ! quantification datatype
>     is_a: MS:1002015 ! spectral count peptide level quantitation
>
>     Of course more variants would need to be created if we would want
>     to mix the definitions above with different charge states, but I
>     think these three definitions would be ok.
>
>     What happens also in the case of ambiguity in the modification
>     position? So, it could be even more complex. But I think this
>     level is probably ok for the current state of things.
>
>     Cheers,
>
>     Juan
>
>         On 17 Jan 2017, at 15:08, Eric Deutsch
>         <ede...@sy...
>         <mailto:ede...@sy...>> wrote:
>
>         This is pretty good, but I think we should make it completely
>         clear whether it is the number of PSMs per peptide sequence,
>         per peptide with modifications, or per peptide ion (including
>         separate charge states). The plain word peptide is often used
>         as a standin for any of these 3 concepts..
>
>         Thanks,
>
>         Eric
>
>         *From:*mayerg97 [mailto:ger...@ru...
>         <mailto:ger...@ru...>]
>         *Sent:*Tuesday, January 17, 2017 4:39 AM
>         *To:*Jones, Andy;psi...@li...
>         <mailto:psi...@li...>
>         *Cc:*Juan Antonio Vizcaino (ju...@eb...
>         <mailto:ju...@eb...>); Perkins, Simon; 'Harald Barsnes';
>         'Yasset Perez-Riverol';to...@eb...
>         <mailto:to...@eb...>;jul...@ru...
>         <mailto:jul...@ru...>;mar...@ru...
>         <mailto:mar...@ru...>;lfi...@st...
>         <mailto:lfi...@st...>;ju...@ed...
>         <mailto:ju...@ed...>; Eugen Netz; Mathias Walzer; Oliver
>         Kohlbacher;le...@im...
>         <mailto:le...@im...>; 'Robert Chalkley'; Ghali,
>         Fawaz;sma...@pr...
>         <mailto:sma...@pr...>; 'Eric
>         Deutsch;psi...@li...
>         <mailto:psi...@li...>
>         *Subject:*Re: mzid 1.2 reviews
>
>         Hi Andy,
>
>         yes we did a CV restructuring,
>         seehttps://github.com/HUPO-PSI/mzIdentML/issues/25,
>         but I think this problem is not related to the restructuring.
>
>         What about
>
>         [Term]
>         id: MS:1001842
>         name: peptide PSM count
>         def: "The number of MS2 spectra identified for this peptide in
>         spectral counting." [PSI:PI]
>         xref: value-type:xsd\:int "The allowed value-type for this CV
>         term."
>         is_a: MS:1001805 ! quantification datatype
>         is_a: MS:1002015 ! spectral count peptide level quantitation
>
>         Best regards,
>         Gerhard
>
>         Am 11.01.2017 um 16:56 schrieb Jones, Andy:
>
>             Hi all,
>
>             (Sent to PSI-PI mailing list plus authors of the mzid
>             paper, in case any of you are not on the mailing list).
>
>             We have received 5 reviews of the mzid 1.2 specifications
>             via the PSI process, as well as the 2 reviews received on
>             the manuscript from MCP, for which it makes sense to
>             consider together. I think most of these can be addressed
>             fairly simply. I have already fixed a few typos in the
>             specification document that were identified, and made one
>             or two other sensible clarifications to wording. These
>             changes have been checked into GitHub. I have started
>             response documents to both processes in the relevant zip
>             files.
>
>             *If you would like to contribute, please could you send me
>             any feedback within one week (by 19^th Jan) if
>             possible.*After that point, I will submit the mzid 1.2
>             specs back to the PSI process (for which Sylvie the editor
>             recommended minor corrections), unless anything comes up
>             that needs extensive further discussion. Once they are
>             accepted, I will resubmit the paper to MCP, as reporting
>             the mzid 1.2 final specifications.
>
>             Just flagging a few points for specific people to address:
>
>             -Robert and Alexander: one of the reviewer asks whether
>             your cross-linking software will export mzid 1.2, anything
>             you can say here?
>
>             -Fawaz – one of the reviewers seemed to find some
>             validation errors with some of our mzid 1.2 files, please
>             could you take a look
>
>             -Juan – one of the MCP reviewers suggests we change the
>             figures. Can you give me a view on whether you think we
>             need to do this? I’m of the view to make minor
>             improvements, but not radically change them.
>
>             -Gerhard – see response to MCP reviews. One of the
>             reviewers would like to know how spectral counts can be
>             added at the peptide-level. I think this may need a new
>             parent term for one given CV term (see my notes in the
>             response to reviews doc), could you take a look?
>
>             Best wishes
>
>             Andy
>
>         --
>
>         *--------------------------------------------------------------------*
>
>         *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/>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Psidev-ms-vocab mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab

-- 

*--------------------------------------------------------------------*

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

Re: [Psidev-ms-dev] List of ion species, anyone ?

[Joel R. <joe...@wa...>]

Hi Steffen,

I'd be very keen to see such a list developed/help with the RFC.
I think Tobias Kind's list 
(http://fiehnlab.ucdavis.edu/staff/kind/Metabolomics/MS-Adduct-Calculator/) 
would be a useful list to include.

Cheers,
Joel

On Wednesday, January 4, 2017 at 8:06:12 PM UTC, Steffen Neumann wrote:
>
> Hi, 
>
> are there any efforts to collect ion species for psi-ms.obo, 
> such as [M+H]+ or [M-Cl]- ? 
>
> I was able to find "(M+H)+" in [1], but nothing in psi-ms.obo. 
> I know a few groups interested in such a list, and would be  
> happy to collect terms and send a proposal to Gerhard for inclusion. 
>
> If there are no proposals or suggestions, I would start-off 
> the stuff Michael Witting has collected, and come back with an RFC. 
>
> Yours,  
> Steffen 
>
>
> [1] 
> http://www.ebi.ac.uk/ols/ontologies/pride/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FPRIDE_0000051 
>

[Psidev-ms-dev] List of ion species, anyone ?

[Neumann, S. <sne...@ip...>]

Hi,

are there any efforts to collect ion species for psi-ms.obo,
such as [M+H]+ or [M-Cl]- ?

I was able to find "(M+H)+" in [1], but nothing in psi-ms.obo.
I know a few groups interested in such a list, and would be 
happy to collect terms and send a proposal to Gerhard for inclusion.

If there are no proposals or suggestions, I would start-off
the stuff Michael Witting has collected, and come back with an RFC.

Yours, 
Steffen


[1] http://www.ebi.ac.uk/ols/ontologies/pride/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FPRIDE_0000051

[Psidev-ms-dev] New version 4.0.5 of psi-ms.obo

[mayerg97 <ger...@ru...>]

Dear proteomics community,

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

Changed CV terms in version 4.0.5 of psi-ms.obo:
================================================
************ Removed is_a: PATO:0002186 ! polarity
************ from the following two terms
[Term]
id: MS:1000129
name: negative scan
def: "Polarity of the scan is negative." [PSI:MS]
is_a: MS:1000465 ! scan polarity
is_a: MS:1000808 ! chromatogram attribute

[Term]
id: MS:1000130
name: positive scan
def: "Polarity of the scan is positive." [PSI:MS]
is_a: MS:1000465 ! scan polarity
is_a: MS:1000808 ! chromatogram attribute

************ Added is_a: MS:1000503 ! scan attribute
[Term]
id: MS:1002476
name: ion mobility drift time
def: "Drift time of an ion or spectrum of ions as measured in an ion 
mobility mass spectrometer. This time might refer to the central value 
of a bin into which all ions within a narrow range of drift time have 
been aggregated." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000455 ! ion selection attribute
is_a: MS:1000503 ! scan attribute
relationship: has_units UO:0000028 ! millisecond

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

[Psidev-ms-dev] Release candidate 4.0.5_rc2 od psi-ms.obo

[mayerg97 <ger...@ru...>]

Dear proteomics community,

attached there's the release candidate 4.0.5_rc2 of the psi-ms.obo file.

Changed CV terms in version 4.0.5_rc2 of psi-ms.obo:
====================================================
************ Removed is_a: PATO:0002186 ! polarity
************ from the following two terms
[Term]
id: MS:1000129
name: negative scan
def: "Polarity of the scan is negative." [PSI:MS]
is_a: MS:1000465 ! scan polarity
is_a: MS:1000808 ! chromatogram attribute

[Term]
id: MS:1000130
name: positive scan
def: "Polarity of the scan is positive." [PSI:MS]
is_a: MS:1000465 ! scan polarity
is_a: MS:1000808 ! chromatogram attribute

************ Added is_a: MS:1000503 ! scan attribute
[Term]
id: MS:1002476
name: ion mobility drift time
def: "Drift time of an ion or spectrum of ions as measured in an ion 
mobility mass spectrometer. This time might refer to the central value 
of a bin into which all ions within a narrow range of drift time have 
been aggregated." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000455 ! ion selection attribute
is_a: MS:1000503 ! scan attribute
relationship: has_units UO:0000028 ! millisecond

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