Re: [Psidev-ms-dev] CV Mapping file (MAY)

[Eric D. <ede...@sy...>]

Hi Alan, thanks for the questions, these are good ones



1) The definitions of MAY SHOULD MUST are official definitions as per
RFC-2219 as described at the beginning of section 2 in the spec doc:

http://psidev.cvs.sourceforge.net/*checkout*/psidev/psi/psi-ms/mzML/document/mzML1.1.0_specificationDocument.doc



2) In this context, MAY means that you permitted to specify the term(s)
referenced, but are not required to do so. Nothing more. Except for a
slight qualification in #3.



3) Regarding terms that are **not** specified in a given context:

  3a) for any term that is mentioned in another rule, it MUST not be used
in a context that doesn’t allow it. For example, since there is a rule
somewhere that specifies where an instrument model can be specified, it is
invalid to reference an instrument model in any place that does not specify
that it can be there.

  3b) however, for any term that is **not** constrained anywhere, then its
use anywhere is a warning, but not an error. And that file is valid. For
example, say we had a term “room air temperature”, and there is no
constraint anywhere in the mzML mapping file that applies to that term
(directly or by parentage), then it is not illegal to specify it anywhere
the write wants.

I believe that is what we have agreed. I am uncertain if it is fully
implemented in the validator. Does anyone wish to clarify this?



4) Regarding the ambiguous nature of parent terms, I believe our policy is
as follows: if a writer writes a parent term instead of a specific child
term, then the writer is trying to tell the reader explicitly that they do
not have that information. The writer is in effect saying “yes, there is a
reflectron state here.. but I just don’t know what it is, sorry”. This
might have some different connotation than not providing any information.
Similarly, when a format says that an instrument model MUST be specified,
if the writer simply uses the parent term “instrument model”, this means
the writer does not know. Perhaps it is a tool that is converting an MGF
file of unknown pedigree to an mzML file. This is a little weird perhaps,
but it solves the problem of littering the ontology with “unknown
instrument”, “unknown reflectron state”, etc. This would be untidy and not
something that true ontologies have anyway. Although would be a bit
explicit. This was discussed to death, and that’s the consensus.



That’s my best answer to your questions. Further clarifications welcome,
especially if I got something wrong.



Regards,

Eric





*From:* Race, Alan [mailto:Ala...@un...]
*Sent:* Monday, March 20, 2017 8:53 AM
*To:* Mass spectrometry standard development
*Subject:* [Psidev-ms-dev] CV Mapping file (MAY)



Hello,

I have a question regarding the intent for the MUST, SHOULD, MAY
requirement levels within the mapping file that I couldn’t find a clear
definition of online. The question relates to determination of a valid mzML
file. With MAY, is the intent that:



a) A set of terms that may be included, but is not exhaustive. I.e. The MAY
rules are for guidance only.

b) Only terms mentioned here may be included within the defined scope, any
others would render the mzML technically invalid.

c) Something else?



On a related note, the analyzer_may rule states that any child of
MS:1000480 (mass analyser attribute) can be included. However, one of the
children is MS:1000021 (reflectron state) – so inclusion of this ‘parent’
term (whose child terms define on and off) would satisfy the validity of
mzML, but including the MS:1000021 term makes no sense. Is there anything
within the obo/mapping file that I’m missing that would enable
filtering/checking of these parent terms that ideally shouldn’t be allowed
to be included?



Thank you for your help,



Alan