Menu
▾
▴
Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
|
From: Randy J. <rkj...@in...> - 2008-02-18 19:45:03
|
I originally presented a draft of mzData 1.1 which had chromatogram elements in it, and it worked just fine for all sorts of acquisitions an instrument can perform in addition to acquiring a spectrum. I appreciate that this suggestion also created some other difficulties (like multiple ways to store the same data), and I dropped the draft as a serious suggestion in favor of a merger between mzData and mzXML. "Analog Channel" is a nickname for the typical analog-to-digital converters available on most mass spectrometers for recording data from external devices which generate either a voltage or current output. These ADC inputs, and everything else recorded by the data system, undergo digitization. And yes, historically detectors were mostly analog, but over the past decade or so, they are increasingly pulse counting systems with all sorts of signal processing possibilities. Most people don't consider pulse counting systems to be analog... We have already gone to generic vectors where the name (like mz and intensity) have to be provided in a cvParam. It is easy already to name the vectors anything you like. This is important, especially since we got rid of the supplemental data vectors for holding things like individual peak annotations, and alternative processing of the spectrum (like digital filtering, etc.). This is all really good, and pretty generic already. I'm not suggesting that we complicate things more with specialization, but acknowledge the generalization which is already present and needed to record common extensions to the base use case. Because of the generic, unnamed vectors, a display program will already have to sort out what it's looking at when it reads each vector. They are not ordered, for example, and there is not a schema-enforced requirement that there are always two - or even that they are named at all. I'm suggesting that since a robust viewing program is going to have to do a lot of checking to determine how the vectors are used in the current scheme, we would not have to do much to make the schema much more broadly applicable. Since the schema is being considered for use in metabolomics and other small molecule work, I think this is important. Randy -----Original Message----- From: Matthew Chambers [mailto:mat...@va...] Sent: Monday, February 18, 2008 2:23 PM To: Mass spectrometry standard development Cc: Randy Julian Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008 Have you previously made a detailed proposal about what the representation of these non-MS signals should look like? And to my (limited) knowledge, calling them "analog" signals is rather misleading, because by necessity they must be digitized to be represented digitally. :) Don't MS signals come from analog detectors as well? It sounds like you either want a specialized way to encode each non-spectral data type, or a generic way to encode any non-spectral data type. In the former case, the schema and the validator mapping would define semantics for which data axes are allowed in which data type (e.g. "mz vs. intensity in a <spectrum>", "time vs. intensity in a <chromatogram>", "x vs. y in a <uvChannel>", etc.), and in the latter case, there would be a generic <channel> element which would have a variable set of binary data arrays and the names/types of those arrays would be determined by the file creator. Or both approaches could be combined. But either (or both) approaches are superior to trying to shove generic "channel" data into a <spectrum> element IMO. Like you said, it should be possible for readers which only care about spectral data to easily skip the non-spectral data and that would be vastly more intuitive if there were other element names to put the non-spectra data in. -Matt Randy Julian wrote: > Matt, > > I'm only talking about data which is collected by the mass spectrometer > data system in conjunction with the mass spectral experiment. > > When we did LC-LC experiments in my lab, we would sometimes put a UV > detector between the two columns, and collect data on analog channels > recorded by XCalibur. Most instruments have this capability. > > Since there seems to be resistance to the whole idea of a <chromatogram> > element (which I appreciate), it leaves open the question about what to > do with data collected by the data system during the LC-MS experiment. > > I don't understand why we don't want to acknowledge that almost all MS > data systems can be used to collect analog signals during experiments > along with spectra. This is simple stuff, and very useful. I don't > want to lose this use case, and we've no place else to put this data. > > Randy > > > -----Original Message----- > From: psi...@li... > [mailto:psi...@li...] On Behalf Of > Matthew Chambers > Sent: Monday, February 18, 2008 1:53 PM > To: Mass spectrometry standard development > Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008 > > Is there a reason to accommodate non-spectral data inside spectrum > elements? If the file should be able to handle non-spectral data, then I > > think we should have other kinds of elements instead of introducing > strange logic about deciding whether a spectrum is really spectrum or > not based on its MS level. Working out the other data representations > would take time, though. It's worth discussing in the teleconference. > > As for the scanNumber vs. scan element question, I'm a bit confused > about that so I'd also like to cover it tomorrow. > > When are we going to open the cvParam-format can of worms? > > -Matt > > > Randy Julian wrote: > >> I'd like to get a couple of schema items on the agenda tomorrow. >> >> I've been asking about a possible change in the schema regarding >> msLevel. As an alternative to moving the attribute, or making it >> optional, I would like to propose that we allow non-MS channels >> > acquired > >> by the MS data system and stored in the raw file to be marked as >> msLevel=0. This would require a change to the specification document >> but would allow software to ignore non-spectral content (whatever it >> might be) if the level is not at least 1. >> >> Another approach which is also consistent with the rest of the schema >> > is > >> to make the attribute a cvParam like the axis names. This would >> > require > >> a schema change and shift the validation of msLevel to the validator >> program. If there is strong support for a required msLevel attribute >> > in > >> the current location, we could still represent the other signals with >> the suggestion above. >> >> Also, I haven't heard back about the relationship between the 'scan' >> number attributes and the scan elements. Has anyone looked at this >> > yet? > >> Can we also discuss how this is supposed to work tomorrow? >> >> Thanks, >> Randy >> >> >> -----Original Message----- >> From: psi...@li... >> [mailto:psi...@li...] On Behalf Of >> Lennart Martens >> Sent: Monday, February 18, 2008 1:07 PM >> To: Mass spectrometry standard development >> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008 >> >> Dear PSI-MS Enthousiasts, >> >> >> The next telephone conference for the PSI-MS development group will >> > take > >> place on Tuesday, 19 february 2008. >> >> The phone conference will take place at the time indicated below >> > (please > >> find a location near you ): >> >> >> > http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year > >> =2008&hour=17&min=0&sec=0&p1=0 >> >> phone numbers are: >> >> + Germany: 08001012079 >> >> + Switzerland: 0800000860 >> >> + UK: 08081095644 >> >> + USA: 1-866-314-3683 >> >> + Generic international: +44 2083222500 (UK number) >> >> access code: 297427 >> >> >> You can also view these details online on the PSI website: >> >> http://www.psidev.info/index.php?q=node/313 >> >> >> Best regards, >> >> lnnrt. >> >> >> > ------------------------------------------------------------------------ > >> - >> 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 > > |
