Menu
▾
▴
Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
|
From: Matthew C. <mat...@va...> - 2008-02-18 21:03:44
|
If non-spectral data is intended to be supported by mzML, I like the idea of a generic spectrum-level element in which the data array terms are much more flexible than they are in spectrum elements. Just to clarify, would ADC and PDA data always be chromatographic (time vs. something else)? If so, I am partial to your <chromatogram> element. If the independent variable might not be time, then <chromatogram> wouldn't be generic enough. If non-spectral data is not intended to be supported by mzML, then it should not be acceptable to hack in support for such data by manipulating the spectrum element. The frequency domain for TOF and FT instruments is an interesting question as well; I don't think it would make sense as the primary independent variable of a <spectrum> element, but it could be an auxiliary array. -Matt Randy Julian wrote: > I think we've hit at some of the key points for the discussion tomorrow. > > > What is your recommendation for storing ADC (or PDA) data? > > Also, does the current idea for the data vectors support storing the > original time axis from a TOF or an FT instrument? > > Thanks, > Randy > > -----Original Message----- > From: Matthew Chambers [mailto:mat...@va...] > Sent: Monday, February 18, 2008 3:19 PM > To: Mass spectrometry standard development > Cc: Randy Julian > Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008 > > > > Randy Julian wrote: > >> 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. >> >> > Yes, as I understand the term, a chromatogram is a generic concept for > any data stored with time as one axis. > > >> "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... >> >> > OK. I can't say I like that nickname to refer to an extra/auxiliary data > > channel, but so be it. > > >> 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. >> >> > Yes, the vectors are generic, but their parent element is not > (<spectrum*>), so the only thing they should be generic for are things > within the domain of the "spectrum" concept. You are suggesting that we > take away the (intuitive) attribute requirements of a spectrum so that > it can be used as a generic concept. I am not at all opposed to the idea > > of a generic concept at the level of <spectrum> in the data hierarchy, > I'm just opposed to the idea that such a concept be called a "spectrum". > > If you were to suggest that we rename the spectrum element to something > generic like "runItem" (and spectrumList possibly to "runItemList") I > could live with that. It looks silly, but it wouldn't be flat-out wrong > and counter-intuitive! :) I would prefer to keep the spectrum element > and add a generic sibling concept instead, though. > > -Matt > > >> 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 >>> >>> >>> >>> >> >> > > |
