Thread: Re: [Psidev-ms-dev] [proteowizard-developer] mzML output and the mzML specification: problem, maybe

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Bryson, I believe that your impression is correct. In practice, most
documents use the spectrumRef. The alternate use of (sourceFileRef and
externalSpectrumID) is rare, but supported. My very vague recollection is
that it is not possible in XML schema to enforce mandatory attribute (A and
B) or C. So our solution is to make them all optional. Originally we had
only spectrumRefs. But then someone what the ability to refer to spectra
external to the document. There is a semantic validator software that is
supposed to flag incorrect use of this as an error, but I am not certain
that it does. And it is not universally used. This is a good lesson in “any
disagreeable shortcut left unblocked will be taken!”.

So is your question: is the fact that some writers like Bruker software do
not write spectrumRefs (or the alternative) a problem?

Regards

Eric

*From:* Gibbons, Bryson C [mailto:bry...@pn...]
*Sent:* Monday, May 4, 2015 3:19 PM
*To:* pro...@li...
*Subject:* [proteowizard-developer] mzML output and the mzML specification:
problem, maybe?

In some of my improvements to the mzRefinery filter (in particular for
adjusting precursor metadata using the scan start time from the precursor
itself) I ended up breaking part of its functionality: updating precursor
metadata for MSn scans. I hadn’t noticed this previously because I was
primarily using it on mzML files produced from Thermo instruments, but when
I tried it again recently on some Bruker QqTOF I found that precursor
metadata was not being updated. After some testing to determine why this
was happening, I found that while the Thermo reader populates precursor
element spectrumRef attribute, the Bruker reader (and apparently most of
the other vendor readers as well) do not, instead leaving no attributes on
the precursor element. I’m assuming that a good part of this is probably
because the vendor files/dlls don’t provide a good process to determine
which scan is the precursor.

The mzML 1.1.0 specification for the <precursor> element states: (
http://www.peptideatlas.org/tmp/mzML1.1.0.html#precursor)

*Attribute Name*

*Data Type*

*Use*

*Definition*

externalSpectrumID

xs:string

optional

For precursor spectra that are external to this document, this string MUST
correspond to the 'id' attribute of a spectrum in the external document
indicated by 'sourceFileRef'.

sourceFileRef

xs:IDREF

optional

For precursor spectra that are external to this document, this attribute
MUST reference the 'id' attribute of a sourceFile representing that
external document.

spectrumRef

xs:string

optional

For precursor spectra that are local to this document, this attribute MUST
be used to reference the 'id' attribute of the spectrum corresponding to
the precursor spectrum.

Though all are listed as optional attributes, the descriptions leave the
impression of “you must either use externalSpectrumID and sourceFileRef, or
use spectrumRef”. I don’t know if that is what it is supposed to mean,
because the mzML 1.0.0 specification left the “spectrumRef” attribute
optional with the definition of “Reference to the id attribute of the
spectrum from which the precursor was selected.”

Is this a problem, or am I misreading the mzML specification?

Thank you,

Bryson Gibbons

Thread: Re: [Psidev-ms-dev] [proteowizard-developer] mzML output and the mzML specification: problem, maybe

psidev-ms-dev