RE: [Psidev-ms-dev] mzData issues

[Brian P. <bri...@in...>]

> If everyone who has a working mzData=20
> tool will drop a line to this mailing list, I will make sure=20
> the tools=20
> section gets updated.

InsilicosViewer (available at www.insilicos.com) supports mzData. =20

The Trans-Proteomic Pipeline from the ISB also supports mzData (see =
http://tools.proteomecenter.org/software.php).

- Brian Pratt, Insilicos

> -----Original Message-----
> From: psi...@li...=20
> [mailto:psi...@li...] On Behalf=20
> Of Randy Julian
> Sent: Tuesday, November 29, 2005 7:47 PM
> To: Andy Jones
> Cc: psi...@li...
> Subject: Re: [Psidev-ms-dev] mzData issues
>=20
> PSI-MS Developers,
>=20
> Just a quick note regarding mzData 1.1 prototype. It now=20
> looks like the=20
> smart way to go is to provide a mzData 1.1 for review in January (as=20
> agreed in Geneva) with the goal of completing the release at=20
> the Spring=20
> 2006 meeting. My preference is for mzData 1.1 to be a maintenance=20
> release adding new 'optional' elements which mean anyone=20
> generating 1.05=20
> files can continue to do so, and anyone who wants to use the new=20
> features of 1.1 will not break any current parsers. The main=20
> reason for=20
> the proposed schedule is that we are making plans to merge=20
> mzData with=20
> mzXML, and I don't see how this could be done easily before January=20
> allowing sufficient review time before a meeting in the Spring. What=20
> does seem possible is to keep mzData as stable as possible while=20
> addressing the main complaints regarding redundancy of instrument=20
> parameters by grouping of 'scans' into 'experiments' and providing a=20
> mechanism for providing all of the instrument parameters for=20
> a 'group'=20
> of scans. We could have the merged mzData/mzXML in draft mode by the=20
> Spring meeting (if we get help) and finalized by the Fall=20
> meeting which=20
> could mean adoption in the Fall, or if there is more=20
> refinement needed=20
> by the end of 2006.
>=20
> Keeping mzData stable should allow developers to add tools=20
> without the=20
> worry you are expressing - that the thing will move too fast=20
> and prevent=20
> stable development. This is countered by people who say 'why=20
> should it=20
> take so long? fix it and be done with it...' We could use=20
> more feedback=20
> on this.
>=20
> I have heard that the XSLT-based translator is slow on large=20
> files. This=20
> is because there is a script which splits the mzXML joint=20
> mz/inten data=20
> vector into the separated vectors used in mzData. This could be done=20
> very quickly in C/C++ or in Java. No one has written such a=20
> program yet,=20
> but given the example of the ProteomeSystems converter, it would not=20
> take anyone with a serious number of mzXML files to convert long to=20
> write - I am not aware of anyone who has done this yet.
>=20
> I have also not heard of any attempt to resurrect the=20
> original Java GUI=20
> application Kai Runte wrote while at the EBI which could perform the=20
> type of ASCII->mzData conversion you mentioned. This code=20
> base is in the=20
> CVS tree and could be picked up by a Java-capable volunteer and made=20
> compatible with 1.05 (and beyond). Anyone wishing to work on=20
> this please=20
> contact me.
>=20
> Finally, there are reports of a number of viewers - several=20
> groups seem=20
> to be working on them, and we have our own (which I'll share if you=20
> want), so I don't have experience with anyone else's. This is how I=20
> check the base64 strings. There are other base64/IEEE-float analysis=20
> tools which you could use if you want to strip out the string for=20
> testing, but I just use an mzData parsing viewer. It would be=20
> helpful if=20
> we organized the toolset for mzData and gave pointers to things like=20
> viewers, parsers and converters. If everyone who has a working mzData=20
> tool will drop a line to this mailing list, I will make sure=20
> the tools=20
> section gets updated.
>=20
> Randy Julian
>=20
>=20
> Andy Jones wrote:
>=20
> > Hi,
> >
> > I'm trying to convert data from various different instruments into=20
> > mzData and I have a few questions.
> >
> >    1. One of the instruments produces plain text output for the peak
> >       list (peak [tab] intensity). Does anyone have a script or some
> >       code for turning this into the mzData base 64 binary.=20
> Otherwise,
> >       any advice for how best to do this would be welcome.
> >    2. What is the current time scale for the updated=20
> version of mzData
> >       that is being discussed. If I produce parsers that convert to
> >       mzData v 1.05, will I need to re-write them fairly=20
> soon for the
> >       next version?
> >    3. What are the current plans with respect to future versions of
> >       mzXML and mzData. I have tried out the ProteomeSystems
> >       converter. It runs very slowly over large files but it does
> >       produce valid mzData files, although I don't know how to check
> >       if the peak list conversion is correct. Is this a=20
> viable way of
> >       producing mzData if I can get mzXML files first? Does anyone
> >       have any experience of using the converter in practice.
> >
> > Any advice would be most appreciated, cheers,
> >
> > Andy
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>=20