From: Randy J. <rkj...@in...> - 2006-11-11 16:35:59
|
Hi everyone, Short version: This is confusing and we need to deal with it directly in the CV. Below is a long discussion - the short version is that 1000038/1000039 are meant to be relative acquisition times which in chromatography system would be 'retention time' but this is not true for non-chromatography systems, so we need to clean up the nomenclature. Long version: There are two terms in the CV which are meant to represent relative acquitisiton time from the start of overall acquisition process. The data type is expected to be a floating point number - not a date/time stamp. As such, it is ideally suited (and intentionally designed) to hold a retention time. However, since 'retention time' is not globally applicable to all separation methods, and since not all flow-based methods or sequential acquisition methods involve separation at all (flow-injection, etc.), then calling this term 'retention time' was overly specific. For MALDI system where multiple spectra would be collected from a single spot, the idea of recoring the time from the first spectrum acquired for a spot seemed to match this defintion of acquisition time, and since mzData 1.05 files cannot handle multiple samples, then each spot on the plate would get it's own mzData file whose admin description could include creation dates and times. As for the precise meaning of a relative acquisition time (in minutes or seconds), we are somewhat at the mercy of the base acquisition system. There are two time-frames which need be considered: analyzer time, and flow-system time. A typical analyzer takes some finite time to perform a single acquisition. Most systems combine multiple low-level acquisitions into a single reported acquisition (like most ion traps and TOF systems). Some systems record the time representing the start of an atomic operation which results in the production of a single reported spectrum. Other systems record the concluding time of the spectrum. It is not usually critical to determine if the time indicated is at the start of the spectrum scan, or the end, since it is a very short time in almost all systems and is consistently done within individual analyzers. For most systems used in protoemics, there flow-system time is a completely different thing. In data-dependent acquisitions, there can be large variations is the cycle-time of the instrument, so there will usually not be a 'sampling frequency' in the usual sense - although you can configure experiments so have s fixed sampling frequency. This means that the acquisition time marks the time from the start of the acquisition at which the particular spectrum is recorded. If several spectra are combined then you are working in flow-system time, and there are several ways to describe what has been done. The very best way to handle this is to use the 'acqSpecification/acquisition' elements to record exactly which acquisitions are combined - including their acquisition times. As for the acquitision time of the combined spectrum, it is then possible to indicate either the start of the sequence, or, if you are processing chromatographic peaks, you can record a peak parameter like the apex time, or the centroid of the peak (which is what most chromatographers think of as 'retention time'). This suggests that we should have new CV terms to allow the specification of 'retention time' from the chromatographic point of view, and perhaps clean up the nomenclature to specify that 1000038/1000039 are relative acquisition times. We should also consider adding a true datetime stamp CV term which could be used to store a timestamp for the sample - especially if we move to allowing multiple samples in a single file (proposed for dataXML). Suggestions about additions/changes to the CV? Randy -----Original Message----- From: psi...@li... [mailto:psi...@li...] On Behalf Of David Creasy Sent: Thursday, November 09, 2006 11:23 AM To: len...@eb... Cc: psi...@li... Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology Hi Lennart, The intention was certainly that these are for the retention time, but I can't see any documentation that confirms this. Certainly Mascot Distiller, Mascot, Bruker CompassXport, the Sciex wiff converter, Bioworks and the Insilicos viewer all assume that this is the case. Best regards, David Lennart Martens wrote: > Hi Kent, > > > Thanks for pointing that out, but I had seen these myself and assumed > that they were used to document the actual acquisition time during which > the final spectrum was acquired (the final spectrum represented in the > mzData binary arrays is thus a summation over all the individual > detector recordings during that time slot). > > As such, I would expect this value to be either constant (I guess most > mass specs do not allow dynamic setting of this value, but I could be > wrong) and certainly small (say from 0.5 to 8 seconds). Having '900' in > the seconds field, say, would therefore probably lead to confusion? > > > Cheers, > > lnnrt. > > Kent Laursen wrote: >> Hi Lennart, >> >> There is not currently a term labeled retention time in the MS CV. The >> current terms for the purpose are: >> >> [Term] >> id: PSI:1000038 >> name: Time In Minutes >> def: "Acquisition time in minutes." [PSI:GPS] >> is_a: PSI:1000460 ! Unit >> relationship: part_of PSI:1000459 ! Spectrum Instrument Description >> >> [Term] >> id: PSI:1000039 >> name: Time In Seconds >> def: "Acquisition time in seconds." [PSI:GPS] >> is_a: PSI:1000460 ! Unit >> relationship: part_of PSI:1000459 ! Spectrum Instrument Description >> >> Regards, >> >> Kent >> >>> -----Original Message----- >>> From: psi...@li... [mailto:psidev-ms-dev- >>> bo...@li...] On Behalf Of Lennart Martens >>> Sent: Thursday, November 09, 2006 9:27 AM >>> To: psi...@li... >>> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology >>> >>> Hi, >>> >>> >>> >>> I am processing some mzXML files into mzData for insertion into the >>> PRIDE database, and I can't seem to find an ontology term for 'retention >>> time' in the PSI-MS ontology. >>> >>> If there is one, and I just can't find it for some silly reason, please >>> let me know. >>> >>> If there isn't any, could this be added? It seems like a sensible thing >>> as it is a common enough piece of data. >>> >>> >>> Thanks in advance, >>> >>> >>> lnnrt. >>> >>> ------------------------------------------------------------------------- >>> Using Tomcat but need to do more? Need to support web services, security? >>> Get stuff done quickly with pre-integrated technology to make your job >>> easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>> _______________________________________________ >>> Psidev-ms-dev mailing list >>> Psi...@li... >>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> > -- David Creasy Matrix Science 64 Baker Street London W1U 7GB, UK Tel: +44 (0)20 7486 1050 Fax: +44 (0)20 7224 1344 dc...@ma... http://www.matrixscience.com *** please note change of address *** ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Psidev-ms-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |