Open edeutsch opened 3 years ago
Fetching a spectrum from PRIDE via PROXI such as: http://wwwdev.ebi.ac.uk/pride/proxi/archive/v0.1/spectra?resultType=full&usi=mzspec:PXD000966:CPTAC_CompRef_00_iTRAQ_12_5Feb12_Cougar_11-10-11.mzML:scan:11850:[UNIMOD:214]YYWGGLYSWDMSK[UNIMOD:214]/2
returns the mzs in random order. This is not against the current spec, which does not specify. But it is breaking the Lorikeet viewer at ProteomeCentral. Seems like many applications may assume mzs in order.
What should be the resolution?
sorting is fine!!!
- Should we update the documentation to allow mzs in any order? Write some code to compensate for out of order mzs in ProteomeCentral and all other applications?
- Should we update the documentation to require mzs in ascending order? And update the PRIDE implementation?
If we decided the do it in that way we can change our implementation.
Does the random order of mzs at PRIDE match the same order of intensities? One risk of separate arrays is that they become unaligned.
@edeutsch as far as I know they match the intensities.
@ypriverol, what do you mean by "sorting is fine!!!"?
Will PRIDE start returning sorted mzs?
@edeutsch it means that what ever we decided we can implemented.
Fetching a spectrum from PRIDE via PROXI such as: http://wwwdev.ebi.ac.uk/pride/proxi/archive/v0.1/spectra?resultType=full&usi=mzspec:PXD000966:CPTAC_CompRef_00_iTRAQ_12_5Feb12_Cougar_11-10-11.mzML:scan:11850:[UNIMOD:214]YYWGGLYSWDMSK[UNIMOD:214]/2
returns the mzs in random order. This is not against the current spec, which does not specify. But it is breaking the Lorikeet viewer at ProteomeCentral. Seems like many applications may assume mzs in order.
What should be the resolution?
Does the random order of mzs at PRIDE match the same order of intensities? One risk of separate arrays is that they become unaligned.