Re: [Psidev-ms-dev] Spectra with length 0 in mzData files

[Tom B. <tb...@um...>]

Simon and Randy  -

Both of you are pointing to the need for explicit "missing value" codes
in the schema -- in this case, a "missing spectrum" code.  Either it's
a separate field, "spectrum supplied" which is normally true, or it's a
reserved value in some other field, say 'length="0"' as below, with an
explanation in the schema explaining that 'length="0"' MEANS that the
actual spectrum is missing, and what's there in its place should have
length 1 and should be ignored.

I'm not much of an xml hacker, but I should think that the preference
among these two representations is clearly in favor of an additional
field, since this allows straightforward validation logic, even though
the extra field may seem pointless in normal usage.

Tom Blackwell
Univ Michigan Bioinformatics
Ann Arbor, Michigan USA

On Mon, 22 Aug 2005, Randy Julian wrote:

> This question is a good one to address again as we consider various changes 
> to the schema.  The essential goal is to allow schema-level validation where 
> the content of the <data> element is required in the schema definition. 
> Thus, the element cannot be left empty, but what should we do when the mass 
> spectrometer reports (and records) a totally empty spectrum?  Currently we 
> are suggesting this be handled as given below - report a 0 length data array 
> and put 0 in for mass and intensity.  Several instrument vendor do it this 
> way (and report this information using their API's).  This seems preferable 
> over not recording the spectrum, or putting length="1" and then having an 
> invalid mass value of 0.  This most often occurs when the export from the 
> vendor format file is performed with a threshold which sets a minimum 
> intensity value on what is exported - a spectrum full of noise might be 
> reported as 'empty'.  Even when no user threshold is set, I have seen 'empty' 
> spectra recorded in the raw binary data for an instrument even through 
> electronically this makes almost no sense.
>
> Does anyone have any other suggestions which improve the reporting of an 
> empty (but recorded) spectrum?
>
> Your other question is language dependent.  If you map to Java, 
> precision="32" is a float, and precision="64" is a double.  Other languages 
> have other precisions for internal representations, but the idea is the "32" 
> is an IEEE 4 byte float and "64" is an IEEE 8 byte float.
>
> Has anyone else had any problems using the precision attribute?
>
> Randy
>
>> I'm writing a viewer for mzData files and have come across a small
>> problem where I'm not sure if it's me or the data files which are wrong.
>> 
>> I'm decoding the Base64 data in the spectra and am using the myo_ms2.xml
>> file from sourceforge as an example.  However my parser is falling over
>> on the following lines:
>> 
>> <mzArrayBinary>
>>                 <data precision="32" endian="little" 
>> length="0">AAAAAA==</data>
>> </mzArrayBinary>
>> <intenArrayBinary>
>>                 <data precision="32" endian="little" 
>> length="0">AAAAAA==</data>
>> </intenArrayBinary>
>> 
>> In these cases the file specifies a length of 0, despite there being 1
>> value in the entry (albeit 0 and 0).  Is this the correct way of
>> denoting an empty spectrum, or should this file really quote a length of
>> 1?
>> 
>> Also whilst I'm asking - can anyone point me to a reference for the
>> correct way to handle 64 bit precision data on a 32bit machine and vice
>> versa?  I'm kind of new to a lot of this low level binary stuff!
>> 
>> Cheers
>> 
>> Simon.
>> 
>> -- 
>> Simon Andrews PhD
>> Bioinformatics Dept
>> The Babraham Institute
>> 
>> sim...@bb...
>> +44 (0)1223 496463
>> 
>> 
>> 
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>> 
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>