[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[<cod...@go...>]

Comment #45 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

OK, I can see the argument of skipping the MGF and going straight to the  
native
spectrum or spectra in a controlled manner, but I'll make a slightly more  
generic
proposal. For example, many input formats may provide retention time  
information as
an alternative way of identifying a scan, so that should be a generic  
concept. We
already have it in the PSI-MS CV of course: the "scan time" term.

So...now we are back to the original discussion about including mzML  
attributes in
analysisXML (the other MGF attributes also probably belong in the MS CV,  
perhaps
under an "alternative identifier" category). I'm not sure if your use case  
came up at
the time though - I seem to recall it was mainly considered as a way of  
forwarding
commonly-used attributes and not as an alternative identifier. So I would  
support the
alternative identifier approach for TITLE, SCANS, and RAWSCANS (I could not  
find any
documentation on the last one?), but not the retention time(s). That should  
re-use
the existing term, multiple times if necessary.

Also consider the use case of running a search straight from a native  
format. In such
a case, the nativeID is well defined (and can be adopted now, without using  
mzML as
an intermediate if that is not yet desired), the spectrumID is not. I think  
this use
case is perfectly legitimate too, we do it often with MyriMatch which can  
read
whatever formats pwiz can (currently Thermo RAW w/ Xcalibur, Waters RAW w/  
MassLynx,
Bruker/Agilent YEP, Bruker BAF/FID). And when we need to go back and view a  
spectrum
in either the raw data or in an associated mzML, the best bet is to use the  
nativeID
because it's well defined in either case.

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings