Menu
▾
▴
Re: [Psidev-ms-dev] FW: Why base64?
|
From: Brian P. <bri...@in...> - 2006-10-06 15:18:12
|
If one were to pursue the ASCII course then the structured approach Mike presents is clearly the way to go. I still think it doesn't scale well, though, and can't imagine the mass spec vendors actually writing such files. To those on the thread saying "if there is a need for an eyeballable format, let it be part of this standard instead of Yet Another standard", I heartily agree. But when we talk of using XSLT to make peak tables, etc, well heck, that's just more software translation and isn't really eyeballing, so why mess with another format? But... It becomes apparent (or am I just slow to catch on?) that we may be discussing two different ideas - I think Mike thinks of a "peak" as a postprocessed idea, something coming out of a peak picking algorithm, while others of us think of a "peak" as an m/z pair in an unprocessed raw mass spec output (not deconvoluted, deisotoped, denoised, de-anything-ed). Both are of interest, of course, but the latter isn't really amenable to an ASCII representation due to its sheer bulk. So maybe what we should be looking at is two different data elements, each with its own represetation - and ASCII is arguably the right one for a postprocessed peak pick list. - Brian > -----Original Message----- > From: psi...@li... > [mailto:psi...@li...] On > Behalf Of Mike Coleman > Sent: Thursday, October 05, 2006 11:48 PM > To: bri...@in... > Cc: psi...@li... > Subject: Re: [Psidev-ms-dev] FW: Why base64? > > On 10/5/06, Brian Pratt <bri...@in...> wrote: > >...the unsuitability of XML for eyeballing what is essentially > columnar data, ... > > I do think "eyeballability" is important, but I also feel uneasy > placing the key spectrum data beyond the reach of XML in an XML > spectrum format. In essence, in the current version the XML encodes > spectrum metadata--the peaks themselves become an afterthought, hidden > away in a relatively inaccessible appendix. > > This would be easier to justify if this were image data, for which > there is no reasonable textual representation. But in this case there > is a trivial representation, and the code to read and write it is > probably simpler than for the base64-encoded case. > > There's some discussion here > > http://c2.com/cgi/wiki?IsolateEachDatum > > that touches on this issue. Also, an example on that page suggests > another possibility for the encoding of peaklists that I prefer to > those discussed so far: > > <peaklist> > <peak mz="234.56" i="789" /> > <peak mz="3456.43" i="2" /> > <peak mz="3457.22" i="234" /> > </peaklist> > > This would have the virtue of being highly accessible to eyeball and > quick-and-dirty scripts as well. It would also clearly compress well. > And it keeps the peak data within the realm of XML. It would be > conceivable, I think, to use XSLT to create a table of peak data or > even an SVG image of the spectrum, for example, since everything would > be living in XML-land. > > > > ...A standard that provides n>1 ways > > to state the same thing is n times as difficult to > implement and maintain, > > which reduces vendor enthusiasm by a factor of n > (squared?), which hinders > > widespread adoption. ... > > I generally agree with this, and in particular, I suspect that if the > specification allowed both representations, possibly most vendors > would only produce base64 output. For this reason, if the textual > representation is preferred, maybe the base64 alternative should be > deprecated and marked for removal in a future version. > > However, I think that there is still an advantage to having the > textual alternative in the specification, even if instrument vendors > never produce it. It would allow those of us who prefer the textual > format to do convert to it in a standard way, in a way that > coordinates with the mzData standard. > > Mike > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys -- and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV _______________________________________________ Psidev-ms-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
