Re: [Psidev-ms-dev] mzML pick file question

[Matt C. <mat...@va...>]

*cough cough*

This is a good example of why the standard should support multiple runs 
in a single file.  I can't imagine that analysisXML would be suited to 
handle this unless it too supports multiple runs?  And even then, the 
separate mzML files would have to be externally referenced instead of 
including them in the file itself since the standards are not supposed 
to overlap in purpose.

-Matt

Fredrik Levander wrote:
> Hi Henk, Randy and others,
>
> I think that normally you will produce two separate mzML files from that 
> workflow. The first one will represent all the MS spectra collected in 
> the first run, and the second one will contain a mixture of MS scans and 
> MS/MS scans from the run that is performed with an inclusion list (pick 
> list). The second  file would look similar to the file: 
> http://psidev.cvs.sourceforge.net/*checkout*/psidev/psi/psi-ms/mzML/instanceFile/1min.mzML
> where some spectra are MS (level one) and some MSMS (level two). The 
> picked masses are found under 'precursor' for the MS/MS spectra. In 
> addition, probably the complete inclusion list should be given as 
> cvParams or userParams in a 'referencableParamGroup' to specify which 
> peaks the instrument was programmed to look for.
>
> One could imagine that you construct a third mzML file which is 
> assembled from the first two files, but I'm not sure if that is allowed 
> within the standard, since only one 'run' can be specified. What would 
> be the preferred way to accomplish this? analysisXML or mzML? Has anyone 
> created an mzML file from multiple runs?
>
> Regards
>
> Fredrik
>
> Randy Julian wrote:
>   
>> Hi Henk,
>>
>> mzML was designed for the application you described.  Take a look at the
>> specification document:
>>
>> http://www.psidev.info/index.php?q=node/303
>>
>> In this public comment release, the spectrum element allows multiple
>> binary arrays to be stored.  The main ones would be m/z and intensity.
>> The thought was there could be others - like picked peaks.  We have
>> wrestled with allowing human readable arrays and I think the group
>> concluded they would be too confusing.  There are many ways to do human
>> readable arrays and that violates the goal of minimizing 'ways to
>> represent the same thing' in the standard - a very good goal.
>>
>> This means that you will either have to encode the peak list in binary,
>> or you could use either the cvParam or userParam elements.  I would
>> recommend that we adopt a standard nomenclature for picked peaks and
>> represent this in cvParams for situations where there are not too many.
>>
>> The fragmentation spectra can be stored directly and are best
>> represented in the binaryDataArray - this is what it was meant for.  If
>> you have a large number of picked peaks, this binary array is also the
>> best way to store this type of data.
>>
>> As for 'fragments' of mzML, the spectrum element does have an ID
>> attribute.  In theory, this means that each is uniquely identified in
>> the file and could be returned as part of a query (I'm thinking XQuery
>> style extraction from the document).  While the spectrum element is not
>> self contained, it is 'identifiable' so is a candidate for a return
>> value from an XQuery or an LSID request - I don't think we have not
>> gotten that far - any suggestions?
>>
>> Read through the specification and let us know if you think it's unclear
>> on how the standard could do what you want.  We are at the point where
>> external readers are needed.
>>
>> Thanks,
>> Randy Julian
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of Toorn,
>> H.W.P. van den (Henk)
>> Sent: Thursday, November 22, 2007 10:23 AM
>> To: Mass spectrometry standard development
>> Subject: [Psidev-ms-dev] mzML pick file question
>>
>> Dear developers,
>>
>> I have some questions concerning the mzML format.
>> We have some collaborators who are forced to use MS-peak pick files in
>> order to target peaks for MS-MS in a later run. To be more clear, the
>> workflow would be: do an MS run, pick the peaks you are interested in,
>> rerun the MS, use the list of picked peaks to do further fragmentation. 
>>
>> My questions are: would it be possible to store such picked peaks in a
>> part of the mzML file, together with the original MS-spectra and the
>> resulting MS-MS fragmentations? Are there any obvious ways that
>> fragments of the mzML files could be used as an intermediary file
>> format?
>>
>> Thanks in advance, Henk van den Toorn
>>     
>