Menu
▾
▴
Re: [Psidev-ms-dev] binaryArrayData lengths
|
From: Fredrik L. <Fre...@el...> - 2008-02-13 17:25:33
|
As Eric concluded, a problem with arrays of different lengths is that you would normally want pairs of data, i.e. an m/z and charge state pair. This would require two m/z arrays in the set. OK, you could identify pairs by looking at the arrayLength of the different arrays and use that for pairing, but it seems suboptimal to me. Also, if the spectrum element represents a list of picked peaks I think you would have charge assignments for all the peaks, even if some would be zero or another dummy value if the assignment failed. So, I also vote for binary arrays of the same length for a spectrum. Fredrik 13 feb 2008 kl. 17.12 skrev Matthew Chambers: > It's true that identification output doesn't belong in mzML, but peak > charge state assignments and isotope assignments (to name two > examples) > do not fall under that umbrella. Such annotation does belong in the > mzML > IMO, either in the same file or in a new one, it doesn't really > matter. > And such advanced annotation is unlikely to be available for every > peak > (much less every data point for profile data!). I fail to see the harm > of allowing the length attribute of binaryDataArrays to be optional, > and > if not present for a given binaryDataArray, readers would be > instructed > to treat it the same as the required length attribute (given as an > attribute on the corresponding spectrum element). As for how this will > allow for user-defined craziness, "userParam" does already allow for > that, but binary data cannot be encoded in a userParam to my > knowledge. > > -Matt > > > Lennart Martens wrote: >> Hi Marc, >> >> >> >>> i like that idea of being able to annotate a small subset of the >>> peaks >>> in a spectrum. >>> This is e.g. needed when assigning ion types for MS/MS: b1, >>> b2, ..., y1, >>> y2, ..., y7-H2O, ... >>> Most of the peaks are simply noise and so only a minority of peaks >>> will >>> have an annotation. >>> Using a full-sized array would be possible, but a waste of space. >>> In my opinion, there should be a recommended way to do such a thing. >>> What do you suggest? >>> >>> Before i forget: Is it possible to annotate peaks with strings? >>> Otherwise we would have to use some kind of dictionary to assign ion >>> type an integer index. >>> >> >> The annotation of a mass spectrum with fragment ion types and indices >> presents a significant amount of processing of the original mass spec >> data, as well as a certain type of 'inference' (uncertainty, and >> often >> ambiguity!) that has nothing to do with the mass spectrometer, but >> relates to an identification algorithm of some description. >> >> As such, I don't think we want to annotate this information in mzML >> at >> all, or encourage people to do so. The scope of mzML should remain >> limited to the instrument output (with possibly some signal >> processing >> done by the instrument software). >> >> Fragment ion annotation should therefore be held elsewhere, and the >> PSI >> is actually creating analysisXML for the purpose of recording >> identification algorithm output (such as fragment ion assignment). >> analysisXML will link back to the mzML files used as input, and >> through >> this link, peak annotation can be extracted. >> >> >> Cheers, >> >> lnnrt. >> >>> -Marc >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Psidev-ms-dev mailing list >>> Psi...@li... >>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >>> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
