-
Notifications
You must be signed in to change notification settings - Fork 3
Open
Labels
ImplementationIssue related with one of the implementationsIssue related with one of the implementationsdocumentationThis issue is related with the documentation or repository structureThis issue is related with the documentation or repository structureenhancementNew feature or requestNew feature or requestproxi-schemasThis issue or PR is schemas relatedThis issue or PR is schemas related
Description
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?
- 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?
Does the random order of mzs at PRIDE match the same order of intensities? One risk of separate arrays is that they become unaligned.
Metadata
Metadata
Assignees
Labels
ImplementationIssue related with one of the implementationsIssue related with one of the implementationsdocumentationThis issue is related with the documentation or repository structureThis issue is related with the documentation or repository structureenhancementNew feature or requestNew feature or requestproxi-schemasThis issue or PR is schemas relatedThis issue or PR is schemas related