Re: [Psidev-ms-dev] binaryArrayData lengths

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

It's true that identification output doesn't belong in mzML, but peak 
charge state assignments and isotope assignments (to name two examples) 
do not fall under that umbrella. Such annotation does belong in the mzML 
IMO, either in the same file or in a new one, it doesn't really matter. 
And such advanced annotation is unlikely to be available for every peak 
(much less every data point for profile data!). I fail to see the harm 
of allowing the length attribute of binaryDataArrays to be optional, and 
if not present for a given binaryDataArray, readers would be instructed 
to treat it the same as the required length attribute (given as an 
attribute on the corresponding spectrum element). As for how this will 
allow for user-defined craziness, "userParam" does already allow for 
that, but binary data cannot be encoded in a userParam to my knowledge.

-Matt


Lennart Martens wrote:
> Hi Marc,
>
>
>   
>> i like that idea of being able to annotate a small subset of the peaks 
>> in a spectrum.
>> This is e.g. needed when assigning ion types for MS/MS: b1, b2, ..., y1, 
>> y2, ..., y7-H2O, ...
>> Most of the peaks are simply noise and so only a minority of peaks will 
>> have an annotation.
>> Using a full-sized array would be possible, but a waste of space.
>> In my opinion, there should be a recommended way to do such a thing. 
>> What do you suggest?
>>
>> Before i forget: Is it possible to annotate peaks with strings? 
>> Otherwise we would have to use some kind of dictionary to assign ion 
>> type an integer index.
>>     
>
> The annotation of a mass spectrum with fragment ion types and indices 
> presents a significant amount of processing of the original mass spec 
> data, as well as a certain type of 'inference' (uncertainty, and often 
> ambiguity!) that has nothing to do with the mass spectrometer, but 
> relates to an identification algorithm of some description.
>
> As such, I don't think we want to annotate this information in mzML at 
> all, or encourage people to do so. The scope of mzML should remain 
> limited to the instrument output (with possibly some signal processing 
> done by the instrument software).
>
> Fragment ion annotation should therefore be held elsewhere, and the PSI 
> is actually creating analysisXML for the purpose of recording 
> identification algorithm output (such as fragment ion assignment). 
> analysisXML will link back to the mzML files used as input, and through 
> this link, peak annotation can be extracted.
>
>
> Cheers,
>
> lnnrt.
>   
>> -Marc
>>
>> -------------------------------------------------------------------------
>> 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
>
>