Menu
▾
▴
Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number
|
From: Matthew C. <mat...@va...> - 2008-02-25 21:57:54
|
I considered the fleshed out XML-style identifier, but IMO it's too verbose to go into the index. What we really need is an external id that can fit in a single attribute, and of course that's going to depend on convention. I agree it's not pretty, but it can be well-defined and validated (just not schematically). The convention would also be more in line with the CV paradigm (compared to each component of the identifier having a separate, custom-named attribute) because the conventions could be defined in the CV. The schematic validation for the custom-named attributes could be done, but it would be tricky and confusing (i.e. no mixing and matching from different id schemes, if you use part of a scheme, you must use all of it, etc.). The idea Darren just posted is better in that it relies on convention but defines (part of) the convention in the file itself. However, unless it was carefully implemented and incorporated into the semantic validator, it would allow people to specify the id only partially (i.e. sample, period, and cycle, but no experiment). The same is true of my suggestion too, though, so that's not really an issue. The semantic validator would need to be modified either way. -Matt Joshua Tasman wrote: > Thanks, Darren. Your version would work for Thermo, but not for other vendor schemes that doesn't have a flat scalar index for denoting scans. Others have various "coordinate systems" to determine each scan, such as requiring 'cycle', 'period', 'method', 'scan' (off the top of my head, maybe slightly different) so you'd need something like 'externalIDTypeAccession1', 'externalIDTypeAccession2', 'externalIDTypeAccession3'... > > Ah-- but my "fixed attributes" propose requires an indexedmzXML schema rev when a new coordinate system is introduced. Can anyone out there think of a way to flexibly use varying numbers of accessions without taking up too much space at the index? I'm back to thinking you'd need a "nativeScanRef" subelement with unbounded number of cvParams, but this would be pretty big. Maybe that's just what's needed for this. > > Josh > > Kessner, Darren E. wrote: > >> I'm fine with that, Josh. >> >> Here's another idea, to make use of the existing vocabulary terms: >> >> <index> >> >> <offset id="S19" externalID="19" externalIDTypeAccession="MS:1000532" >> externalIDTypeName="Xcalibur" >4826</offset> >> >> ... >> >> </index> >> >> >> Darren >> >> >> >> -----Original Message----- >> From: psi...@li... >> [mailto:psi...@li...] On Behalf Of Joshua >> Tasman >> Sent: Monday, February 25, 2008 12:21 PM >> To: Mass spectrometry standard development >> Subject: Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition >> number >> >> Darren and Matt: >> >> Thinking about it-- why not just have a slew of optional named >> attributes for the <index>, like: "XcaliburNum", "MassLynxCycle", >> "MassLynxPeriod", >> "AnalystCycle", etc.? Less elegant, but should do the trick for fast >> index parsing, and make me happy by avoiding a convention-based string >> for each vendor and keeping it human readable? I'd propose that if, in >> a specific file, these are used in the index, they should be enumerated >> more fully in the <spectrum> with cvParams, as previously suggested. >> >> Josh >> IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by >> applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED. >> >> If you have received this message in error, please notify us immediately >> by calling (310) 423-6428 and destroy the related message. Thank You for your cooperation. >> >> ------------------------------------------------------------------------- >> 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 > > |
