Menu
▾
▴
Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
|
From: Matthew C. <mat...@va...> - 2008-02-18 20:19:25
|
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 >> >> >> > > |
