Re: [Psidev-ms-dev] TraML::Interpretation and Modification: - attributes as cvParams?

[Matthew C. <mat...@va...>]

Eric Deutsch wrote:
 >
 > Okay, I'm fine with changing this to a CvParam. Instead of:
 >   <Interpretation primary="true">
 >     <CvParam cvRef="MS" accession="MS:1001220" name="frag: y ion"/>
 >     <CvParam cvRef="MS" accession="MS:1000903" name="product ion 
series ordinal" value="8"/>
 >     <CvParam cvRef="MS" accession="MS:1000904" name="product ion m/z 
delta" value="0.03"/>
 >   </Interpretation>
 >
 > We'll have:
 >   <Interpretation>
 >     <CvParam cvRef="MS" accession="MS:100xxxx" name="fragment 
interpretation rank" value="1"/>
 >     <CvParam cvRef="MS" accession="MS:1001220" name="frag: y ion"/>
 >     <CvParam cvRef="MS" accession="MS:1000903" name="product ion 
series ordinal" value="8"/>
 >     <CvParam cvRef="MS" accession="MS:1000904" name="product ion m/z 
delta" value="0.03"/>
 >   </Interpretation>
 >
 > Yes?
Looks great to me. On a related note, perhaps when we refactor the 
neutral loss terms related to "frag: y ion" we should rename those terms 
to be "product: y ion" because according to the IUPAC description of 
product ion, "fragment ion" is deprecated. Plus it would be more 
consistent with its sibling CvParams.


 > > For modification, I think that optional double-valued attributes are
 > > very annoying for an object model. How does a program test if the value
 > > is not set? It either needs a reference-centric implementation
 > > (Java/.NET but not C/C++) with null testing, or it needs an extra
 > > boolean attribute like "hasSomeValue".
 >
 > I’m not sure I understand the problem here.  Is the problem that the 
datatype is <double> and it’s optional? OR is it that it can be either 
monoisotopicMassDelta or averageMassDelta and really should
 > have one of the two, although maybe that information is not known. So 
either one or the other could be present. Or neither. But preferably not 
both. Although no major reason why not both...

Yes, the problem is that it's double and optional. Optional strings are 
fine, mandatory numerics are fine, but optional numerics are rather 
annoying in the object model. It's not a big issue. As for masses, I 
think both should be there unless one of them isn't known. MzIdentML 
requires both of them, so we could follow suit.


 > You want:
 >   <Modification location="1">
 >     <CvParam cvRef="MS" accession="MS:1000xxx" name="monoisotopic 
mass delta" value="15.994919"/>
 >     <CvParam cvRef="UNIMOD" accession="UNIMOD:35" name="Oxidation"/>
 >   </Modification>
Indeed, I think having the masses as CvParams is better. The semantic 
validator could also require the mass terms when a unimod term is 
present (presumably there are no unimod terms without a known formula 
and thus calculable masses?)


 > > Modification's optional location attribute could probably be mandatory.
 > > Or is it supposed to be omitted for terminal mods?
 > As far as I can see from the xsd and docs <Modification>’s location 
attribute is a required attribute. Am I misunderstanding?
Nevermind. I must have misread the XSD.

Thanks,
Matt