Re: [Psidev-ms-dev] mzML's binary arrays

[Marc S. <st...@in...>]

Hi Mat,
> I admit I was hasty to say there was no difference. As you point out, 
> the CV way makes it a "categorized" comment wheres the userParam is 
> totally uncategorized. I still think a special term for such a comment 
> is counter-productive for encouraging inter-compatible software.
>
> Instead, a small modification to your software would allow you to 
> enumerate all the userParams and cvParams in the array and output them 
> in name-value pairs. So you'd have:
> array 0:
>   name="array name" type="array type" units="signal-to-noise ratio"
>   min: 234
>   max: 435435
>   avg: 4545
>
> Putting in "categorized" comment terms is a slippery slope IMO. It would 
> lead to other similar terms in other places and ultimately we'd be like 
> mzData with little or no control over the values of string variables, 
> doom and gloom notwithstanding. ;)  At least is could lead to 
> implementations of mzML that are widely incompatible.
>   
No offense , but your suggestion is only a workaround and ignores the
real problem. What if there are 10, 20 or 50. We also have a GUI for the
statistics output. There, we simply do not have the space to display all
userParams.

I still think there should be a designated place for a user-definable
name or identifier. Otherwise, the meaning of all arrays that have no
explicit CV name is lost (@Eric - this is what i meant when i said that
the userParam is unusable for other tools). I really do not care, how
this is implemented, but it should exist. Putting vital information like
this into userParam is the best way to produce non-inter-compatible
files IMHO.
> As for 528 parameters across all your tools, how many of those are just 
> for your data processing algorithms (that take raw data mzML as input 
> and could write processed mzML as output, as opposed to a search engine 
> which would write pepXML or analysisXML)? For dataProcessing, I at least 
> would prefer algorithm-centric terms instead of tool-centric terms since 
> many tools could implement the same algorithm and more importantly, many 
> tools will run multiple algorithms. So we would have a term for boxcar 
> smoothing, Savitzky-Golay smoothing, etc. Some algorithms might be 
> coupled tightly with proprietary tools (e.g. Mascot Distiller or Protein 
> Pilot's peak picking) but we can still call it something like the 
> "Protein Pilot Peak Picker". :)
>   
All of out tools only perform one algorithm. The parameters are used to
fine-tune the behavior of the algorithm. They are quite
implementation-specific and therefor sometimes change. We can see about
that after we've compiled the list of tools and short descriptions.


Best,
  Marc