From: Fredrik L. <Fre...@im...> - 2008-03-04 15:13:29
|
As I get it nativeID is the about the same as what we currently have in acquistion number + spectrumRef + sourceFileId (or number + externalSpectrumID + sourceFileId), if the source file is a vendor raw data file. If the source file is a mzML file, the externalSpectrumRef would equal the spectrum id in that file. If the spectrum id could be parsed to get native scan id everything is there to get the native scan. <acquisition number="1" externalSpectrumRef="S1F1" sourceFileRef="SF1"/> where SF1 is a MassLynx raw data folder. If SF1 is an mzML file and the same convention was used for the spectrum id as for the externalSpectrumRef, we could easily retrieve the native scan. The question is what to put into spectrum id if the spectrum (or probably peak list) is a combination of spectra. It could be the first external spectrum id in the acquisitionList plus maybe a letter to indicate combination. I see no need to further complicate things by introducing a <metaspectrum> or similar though, the current <spectrum> works fine for both single scans or combined spectra. Fredrik Matt Chambers wrote: > That's an interesting edge case for the nativeID. I am inclined to > suggest that the nativeID be put in the acquisition, or that spectral > combination be rethought entirely. Since a combined spectrum is > essentially a "meta-spectrum" and not a real spectrum (at least I would > think about it that way), we could use a separate element entirely to > encode combinations. The combinations themselves would not have any of > the normal attributes or cvParams of a <spectrum>, just a list of > references to the actual <spectrum> elements elsewhere in the file. This > would be a better way in terms of avoiding (meta)data loss. It would be > reasonable to allow the <metaspectrum> or <combined_spectrum> to have > binaryDataArrays containing the combined data, though, since that would > take the most time to regenerate. But if the spectra are combined before > putting them in the file, you lose the data from the individual > acquisitions. > > -Matt > > > Rune Schjellerup Philosof wrote: > >> Eric Deutsch wrote: >> >> >>> So it seems like the final suggestion is something like: >>> <spectrum index="18" id="S2,4,6" > >>> <scan nativeScanReference="2,4,6"> >>> </scan> >>> </spectrum> >>> >>> >>> >> that would be >> <spectrum><spectrumDescription><scan nativeScanReference="2,4,6"> >> >> This would work for cases when each spectrum refers to a single native scan. >> But aren't there support for having a spectrum that is for instance a >> combination of several native scans? >> >> [Term] >> id: MS:1000570 >> name: spectra combination >> def: "Method used to combine the mass spectra." [PSI:MS] >> relationship: part_of MS:1000442 ! spectrum >> >> >> What to do in this case? >> >> >> -- >> Rune >> > > > ------------------------------------------------------------------------- > 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 > |