Menu
▾
▴
Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
|
From: Matthew C. <mat...@va...> - 2008-02-18 22:38:47
|
Randy Julian wrote: > ADC data with a time stamp could be stored under a <chromatogram> > element, but if the data were coming from a positional encoding system > (like might be used for DESI or DART), then this would not be a > chromatogram. > > I too am in favor of a generically named data location with named > vectors that work like the current <binaryDataArray> element. > > TOF instruments have a true time-domain x-axis, and FT could first have > a time-domain (for the FID), which could then be transformed into a > frequency-domain axis prior to calibration into a m/z axis. All of > these are a legitimate spectrum axes (from a journal editors point of > view). PDA are also two dimensional (like MS) with the independent > variable normally given in terms of wavelength. > Technically you're right, any axis which could be transformed to the m/z axis could be considered a legitimate spectrum axis, but practically speaking I think the mzML standard should semantically (not schematically, given the current form of the schema) require that every spectrum have an m/z array and an intensity array. I was under the impression that this was already the case with the mapping file that the validator uses. Am I mistaken? I think it's absurd to expect every MS application to be able to understand the time representation of m/zs, the frequency representation, and the m/z representation, so we should stick to the m/z common denominator. Therefore, if a file writer added those other axes (frequency/time/wavelength) they would be "auxiliary" (in the spectrum element). Those axes might be the primary axis in a different (either specific or generic) element type, though (e.g. a pda element). > When you say 'auxiliary' array, do you mean just another > <binaryDataArray> within <spectrum>? There is no specific "primary > independent variable" indicated for <spectrum> in the current schema - > it looks like it has to be assumed based on an interpretation of a > cvParam. > > If we go with a generic data element with a binary vector, the only use > case we lose is providing labels to individual peaks using non-binary > data (like strings). This did not get much use in mzData, so maybe > doesn't matter much. > I have no idea how you arrived at this last statement. It seems to be more related to the previous discussion about allowing data arrays of differing length. -Matt > > -----Original Message----- > From: Matthew Chambers [mailto:mat...@va...] > Sent: Monday, February 18, 2008 4:04 PM > To: Mass spectrometry standard development > Cc: Randy Julian > Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008 > > 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 >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > |
