[Psidev-pi-dev] [HUPO-PSI/mzIdentML] Consensus Spectra (labelled
and unlabelled cross-linkers) (#19)
From: Eugen N. <not...@gi...> - 2016-04-30 09:46:12
|
Current state: As it is specified now, the two spectra are referenced as an unordered list of spectrum IDs in the SpectrumIdentificationResult. For some use cases it could be useful to know which of these is the light and which is the heavy spectrum, since they are not necessarily treated equally. Also the experimentalMassToCharge and chargeState from only one spectrum are written in SpectrumIdentificationItem and it is not specified from which, while it would actually be useful to have both. For cleavable cross-linkers it was agreed to use different values here for the two SpectrumIdentificationItems corresponding to the MS3 spectra each containing one peptide. Although the information is there, it is still unclear here, which spectrum ID in the list belongs to which SpectrumIdentificationItem, MassToCharge and chargeState, since one only has the IDs and the other only the other values. But I think MassToCharge and chargeState values for each spectrum ID should be in the file and somehow linked to their corresponding IDs. Proposals: Could we add CV terms to make that more clear? One easy thing to do would be to specify, that in the case of labelled cross-linkers there is a fixed order for the spectrumIDs, e.g. the first ID must be the unlabelled or light spectrum, or more generally the IDs should be in ascending order of label weight or MassToCharge. That would already add a crucial bit of information. Or we could add lists of MassToCharge and chargeState values, that must have the same order as the list of IDs. I would like to avoid specific CV terms for light and heavy spectra and come up with something general enough to cover labelled and cleavable cross-linkers. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19 |
From: andrewrobertjones <not...@gi...> - 2016-05-03 12:54:23
|
I recall the idea is to have SpectrumIdentificationItem elements for each peptide chain within the group. As such, if there is a light-alpha; heavy-alpha; light-beta and heavy-beta, there would be four SpectrumIdentificationItems elements, each with the correct expMassToCharge and charge value. Does this not work? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19#issuecomment-216517941 |
From: andrewrobertjones <not...@gi...> - 2016-05-03 15:01:00
|
Further note - I've spotted there is a problem with this encoding. The chargeState is not specified whether it is experimental or calculated. We need to know the charge value for both calculated and experimental, if we go down this route of using the values in this way. The documentation is not very helpful here: `<xsd:attribute name="chargeState" type="xsd:int" use="required"> <xsd:annotation> <xsd:documentation>The charge state of the identified peptide.</xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="experimentalMassToCharge" type="xsd:double" use="required"> <xsd:annotation> <xsd:documentation>The mass-to-charge value measured in the experiment in Daltons / charge. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="calculatedMassToCharge" type="xsd:double"> <xsd:annotation> <xsd:documentation>The theoretical mass-to-charge value calculated for the peptide in Daltons / charge. </xsd:documentation> </xsd:annotation> </xsd:attribute>` --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19#issuecomment-216556301 |
From: Eugen N. <not...@gi...> - 2016-05-03 15:04:48
|
In the case of labelled linkers we do not have a mapping of one peptide chain to one spectrum, both the light and heavy spectrum are used to identify both peptides and contain fragments from both peptides. Using light-alpha, light-beta, heavy-alpha, heavy-beta SIItems would store the information, but is very redundant and each SIItem now means something different for each experimental setup (normal identification / labelled CLs / cleavable CLs). Since that is the case anyway, we could actually reduce redundancy by only writing half of the combinations, e.g. light-alpha and heavy-beta. It would look exactly like a case of cleavable cross-linkers and all the information would be there, a reader would just have to know what class of cross-linker was used to interpret the data correctly. But I guess we can live with the redundancy anyway. Still for both CL cases, cleavable and labelled, the precise mapping of each spectrumID in the list to the corresponding expMassToCharge and charge values of the SIItems is lost. This mapping was obvious before CLs were introduced as far as I can tell (since all SIItems under one SIResult referenced the same one spectrum) and I think it would be good to keep it obvious somehow. Now an unordered list of IDs has to be mapped to an unordered list of expMassToCharge values. I guess this could be solved by specifying a certain order in each case, e.g. by ascending expMassToCharge in the ID list and in the order of SIItems (either in the context of one specific "cross-link identification item", or in the context of the whole SIResult block). --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19#issuecomment-216557630 |
From: andrewrobertjones <not...@gi...> - 2016-05-04 09:01:32
|
I would like to keep the cardinality such that one SII references one Peptide chain identified, so for the case of L&H, we require four SII elements. Given the problem identified above with "chargeState" attribute, I think we should require that the calculatedMassToCharge and chargeState attributes for each cross-linked pair store identifical values for the calculatedMassToCharge of the whole cross-linked entity, whereby a pair of light would store different values from the pair of heavy. If it is felt necessary, we could also store the calculated neutral mass of each individual chain as a cvParam on each SII. Neutral mass would be better than calculatedMassToCharge anyway, since you may not have a charge value for each chain --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19#issuecomment-216799348 |
From: andrewrobertjones <not...@gi...> - 2016-05-18 15:36:51
|
Think this is solved, please re-open if anything was missed. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19#issuecomment-220066188 |
From: andrewrobertjones <not...@gi...> - 2016-05-18 15:36:56
|
Closed #19. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19#event-664584743 |