Validation behaviour and (other's) CV term compatibility with our metric requirements

[mwalzer]

How do we, on a validation level, deal with 'grafted' CV terms for use in mzQC using the full depth of mzQC json data modelling?
Consider this metric, which has a unit added which is not explicitly contained in the definition of the term.

          {
            "accession": "MS:1003251",
            "name": "count of identified spectra",
            "description": "The number of spectra that pass the threshold to be considered identified with sufficient confidence.",
            "value": 24765,
            "unit": {
              "accession": "UO:0000189",
              "name": "count unit"
            }
          }

Of course the 'count' value is of obvious 'count unit', so one might argue it superfluous, but can you imagine not-so-obvious or outright ambiguous scenarios (seconds vs minutes)?

At the moment, the validation will:
INFO: Metric value undefined unit - Metric CV term used value unit without specification in CV. accession(s) = MS:1003251

[mwalzer]

Do we want to continue the INFO or cut fluff?
Do we want to discourage the use of 'undefined' extra info courtesy of mzQC or encourage more info?

[bittremieux]

I don't really understand what you mean by "grafted," so I'm a bit unclear about the general issue that you're raising. Do you mean using CV terms that are not specifically under the QC subtree in the CV or even from external CVs?

For this metric, if we're regularly using it (which is very clear in this case), I'd say that the term needs to be extended to add a unit. It doesn't affect usage of this metric in other contexts, but would make it properly compatible with mzQC, so I don't see an issue with adding the unit.

I think the warning message from the validator is correct, it should flag such cases. But as I mentioned above, the term should be updated to avoid such warnings.