Search engine input parameters in the CV

[GoogleCodeExporter]

On the call this was discussed at some length. There are two main aspects to 
the discussion:

1. Many search-engine specific CV terms have been added that duplicate 
information stored in a standard search-engine independent way:
ProteomeDiscoverer:Precursor Mass Tolerance
ProteomeDiscoverer:Spectrum Files:Raw File names
Sequest:matched ions
Mascot:total ions

There seemed to be a consensus on the call that these redundant terms should 
not be in the CV, so presumably the already existing ones should be obsoleted.

2. I want a way to distinguish between input parameters that change the 
analysis space and those that don't. I proposed that the distinction between 
userParam/cvParam be drawn along these lines for search engine input 
parameters. This idea crashed and burned because individual mzIdentML producers 
shouldn't have to worry about which of their parameters they make userParams 
and which they make cvParams. But the use case was found to be reasonable, so 
(rising from the ashes) I had the idea that the CV could encode not just that 
these terms are "search engine input parameters" but also whether they change 
the analysis space. There was some controversy about whether changing the 
analysis space can be determined objectively and that doing so could be a 
burden on the CV maintainer, but no concrete examples were given for the 
objectivity complaint and the CV maintenance burden could be taken on largely 
by the people who want the CV terms to be divided in this way (i.e. me).

Original issue reported on code.google.com by matt.cha...@gmail.com on 7 Apr 2011 at 4:47

[GoogleCodeExporter]

Heidelberg:
reg. 1: will be done by the restructuring of the PSI-MS CV
reg. 2: seems to be difficult for a non-expert; makes CV maintenance much harder

Original comment by eisena...@googlemail.com on 12 Apr 2011 at 10:12

• Changed state: Accepted
• Added labels: Milestone-Release1.1

[GoogleCodeExporter]

1. This seems independent of the "restructuring". It's a large-scale term 
obsoletion, not a movement of terms within the hierarchy.

2. Of course it's difficult for a non-expert, that's why we have a group of 
experts maintaining the CV! :) In this case, I'm happy to go through the list 
and make an "expert" decision as to which parameters change the search space, 
at least for the search engines I know and/or the terms that are obviously 
irrelevant.

Original comment by matt.cha...@gmail.com on 12 Apr 2011 at 1:29

[GoogleCodeExporter]

Some of the discussion was necessary after we added the "ProteomeDiscoverer" CV 
terms.
That generated three problems: 
1) some of them had wrong "is_a" relations (now corrected in the CVS)
2) some of them repeat schema elements (like PMF mass tolerance)
3) some of them were not really "search engine" parameters, but have more to do 
with spectra generation, spectra processing, data transformation etc. and 
should be rectructured into other branches of the ontology. (see also mail to 
David, Matt, Juan-Antonio and mailing list: we could correct also the CV terms 
of problem 2), now or after clean-up).

Original comment by eisena...@googlemail.com on 21 Apr 2011 at 4:54

• Changed state: Fixed

[GoogleCodeExporter]

Agreement in TeleCon 21.4.2011: THis seems to be a CV / obo issue, so it is set 
to "Fixed" for the schema 1.1 release.
(feel free to un-fix it again)

Original comment by eisena...@googlemail.com on 21 Apr 2011 at 4:56