Comments on current form of Spectrum class

[edeutsch]

Regarding the current schema: https://raw.githubusercontent.com/HUPO-PSI/proxi-schemas/master/specs/swagger.yaml

Here is a toy example of a Spectrum object as defined by the current schema: http://www.peptideatlas.org/api/proxi/v0/spectra/238293 UI: http://www.peptideatlas.org/api/proxi/v0/ui/

• Comments/questions:
  • usi is great, but what is accession? Anything the repo wants? preferably in usi notation? (like an lsi {local spectrum identifier})
  • charge: this already has a very specific meaning (assuming this means precursor_charge) Do we really need a CV term?
  • mz: this already has a very specific meaning (assuming this means precursor_mz) Do we really need a CV term?
  • If so, what is the proper term? MS:1000744 selected ion m/z is what mzML uses
  • I suggest the very limited number of fixed slots don't need OntologyTerm since they are clearly defined
  • What if there are multiple precursors in the selection window? rarely supported but a common occurrence..
  • In addition to the standard set of attributes, how about a container for additional CV terms e.g. spectrumAttributes = [ OntologyTerm, OntologyTerm, ... ]
  • In OntlogyTerm, can we omit cvLabel? I don't mzML et al. have it, but since our accessions are full CURIEs, the CURIE prefix is the cvLabel UNLESS, we defining a cvList in the documentheader somewhere, which we're not. So how about remove cvLabel and always use the common CURIE prefixes. CURIE prefixes are not completely unambiguous (e.g. PMID: vs PUBMED: but in our little MS world, effectively it is)
  • What is the desired format of peakList? Array of peaks, yes, but what is each peak? 3-element array? dict of attributes?

[ypriverol]

@edeutsch both urls provided are broken.

[ypriverol]

• [x] usi is great, but what is accession? Anything the repo wants? preferably in usi notation? (like an lsi {local spectrum identifier})

A new field has been included lsi

• [x] charge: this already has a very specific meaning (assuming this means precursor_charge) Do we really need a CV term?

I have change the name to precursor_charge and to an int type.

• [x] mz: this already has a very specific meaning (assuming this means precursor_mz) Do we really need a CV term?

Precursor mz has been changed to precursor_mz .

• [x] If so, what is the proper term? MS:1000744 selected ion m/z is what mzML uses. I suggest the very limited number of fixed slots don't need OntologyTerm since they are clearly defined

Done

• [ ] What if there are multiple precursors in the selection window? rarely supported but a common occurrence..

This is possible, an in mzML is supported but we need to think if we want to support 1 precursor 1 MS2 or the other relation. We can discuss this in a meeting.

• [x] In addition to the standard set of attributes, how about a container for additional CV terms e.g. spectrumAttributes = [ OntologyTerm, OntologyTerm, ... ]

Good suggestion @edeutsch . I have included this in the present version.

• [x] In OntlogyTerm, can we omit cvLabel? I don't mzML et al. have it, but since our accessions are full CURIEs, the CURIE prefix is the cvLabel

Good suggestion. Removed in the present version.

• [x] UNLESS, we defining a cvList in the documentheader somewhere, which we're not. So how about remove cvLabel and always use the common CURIE prefixes. CURIE prefixes are not completely unambiguous (e.g. PMID: vs PUBMED: but in our little MS world, effectively it is)

• [x] What is the desired format of peakList? Array of peaks, yes, but what is each peak? 3-element array? dict of attributes?

[edeutsch]

excellent progress! The two URLs are back up with the new schema: spectra toy test: http://www.peptideatlas.org/api/proxi/v0/spectra/238293 UI: http://www.peptideatlas.org/api/proxi/v0/ui/

Note that /spectra is not returning a real spectrum yet, just a toy example for discussion.