Re: [Psidev-ms-dev] PDA spectrum example + nativeIDs + component references

[Kessner, D. E. <Dar...@cs...>]

Hi all,

I support the fully qualified nativeIDs for Thermo that Matt suggests.

I also think we should add the component references (sourceRef, 
analyzerRef, detectorRef).  This would resolve the issue Matt and I were
debating a month or so ago about encoding instrument information in the
individual <spectrum> elements.  We had left the discussion with the
problem that using "virtual instrument" references to distinguish
between mass analyzer types in a hybrid instrument wouldn't scale well
to handle more options.  Being able to refer to specific components
handles both issues of scalability and non-redundancy of information in
<spectrum>.


Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Thursday, April 17, 2008 8:18 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] PDA spectrum example

Other than a few syntactical problems and some missing metadata, it 
looks good. Thanks Jim (and Eric for forwarding)! Would it be possible 
to get the corresponding RAW file for such a PDA example for use with 
developing converters? And even better would be a RAW file with both MS 
and PDA spectra intermixed.

In the Thermo context, this brings up an issue with nativeID. I think 
everybody wants to see Thermo nativeID simply be a scan number like been

for so long, but I am thinking that is not quite true to what the file 
is storing. As I understand it, each "controller" has its own list of 
scan numbers, so a file-scoped spectrum id is a combination of the 
controller and the scan number. Now in the vast majority of cases we are

only dealing with controller 0 for MS data, but I am wary of treating 
this technically degenerate case (i.e. where one dimension of the ID is 
always the same so it could potentially be excluded) specially. I think 
it will cause considerable confusion when implementors look up the 
format of the nativeID after they encounter a "non-degenerate" case 
where the multi-dimensional ID is necessary. I would propose a Thermo 
nativeID look like: "<controller #>,<scan #>", e.g. "0,1" "0,2" "0,3" 
"0,4" ... "0,10000" for an average MS file with 10k scans. For a 
"non-degenerate" case where MS are intermixed with PDA spectra, it would

look like (3 is the controller # for PDA):
0,1
...
0,1000
3,1
...
3,500
Here I iterate on controller first and then on scan number because 
switching between controllers is presumably more intensive in the API 
than switching scan numbers.

Also the "non-degenerate" case reintroduces the issue of having multiple

components within a single instrument. It seems like we can have 
multiples of all three components (source/analyzer/detector). Unless I 
am mistaken and the PDA acquiring component is considered to be a 
separate instrument? If it is indeed part of the same instrument, we 
might look at some kind of component referencing attributes (sourceRef, 
analyzerRef, detectorRef) for scan or spectrum. How does that sound? We 
could fabricate a hypothetical example with an instrument that has MALDI

and ESI sources used in tandem with both IT, Orbitrap, and TOF analyzers

in tandem, and EM and PDA detectors...coming soon to a lab near you.

-Matt


Eric Deutsch wrote:
>
> Hi everyone, attached is a PDA example mzML file from Jim Shofstahl. 
> Here's what Jim said with it:
>
> Hopefully the rest of the format matches the current standard. Any new

> terms have CV values that begin with 9's.
>
> When PDA data is stored in an Xcalibur raw file, there isn't that much

> information that goes In the scan header, so the format is rather 
> sparse when it comes to descriptive information.
>
> Thanks,
>
> Jim Shofstahl
>
>

------------------------------------------------------------------------
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.