Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Joshua T. <jt...@sy...>]

I'm with Matt on this one, and like his solution.  There are unfortunately lots of real use cases (combining dta, mgfs) where the information will really be unknown, and we should accurately represent the lack of information.  If it's not too much effort to add a little more code to the validator, I would much prefer the accurate addition of an "unknown" term.  There has been so much effort getting the CV and document to line up with reality, it looks very strange to me to force this ontological 'hack' by allowing the category to appear as a value, as Matt has said.

Josh


Matthew Chambers wrote:
> Lennart Martens wrote:
>> Hi Matt, and Colleagues,
>>
>>
>>   
>>> I don't really prefer one to the other very much, but I don't see how 
>>> the parent term would be easier to validate ("all but X children of a 
>>> term" doesn't make sense to me, do you mean "all children of a term 
>>> except X"?)
>>>     
>> You are right; I provided bad shorthand for: 'all children of a term, 
>> except X (and Y, and Z, ... -- potentially).
>>
>> The reason why it it is easier to validate is due to the way the 
>> validator mapping file is designed, e.g. (example verbatim from current 
>> 0.99.1 mapping file):
>>
>> 	    <CvTerm termAccession="MS:1000031" useTerm="false" 
>> termName="instrument model" isRepeatable="false" 
>> scope="/mzML/instrumentList/instrument" allowChildren="true" 
>> cvIdentifier="MS"></CvTerm>
>>
>> this means that although all children of term 'MS:1000031 -- instrument 
>> model' are allowed (allowChildren="true"), the term itself is not 
>> allowed (useTerm="false"). By flipping this latter boolean, we can allow 
>> the parent term, thus separating between MIAPE requirements (current 
>> configuration) and the 'usable mzML requirements' (flipped boolean as 
>> explained above) -- for the instrument model at least.
>>   
> OK, so it's an implementation thing. That's fine.
> 
>>> What about data converted from DTAs or MGFs 
>>> where the user doesn't even remember (or never knew) what kind of 
>>> instrument it came from?
>>>     
>> When the instrument is really unknown (which is unfortunate and 
>> constitutes dramatic metadata loss whichever way you look at it), the 
>> proposed scenario (usage of toplevel term) provides solace. For all 
>> other scenarios (where an incentive to adapt convertor software or 
>> report the development of a new instrument is concerned), the relative 
>> obscurity of the 'fix' might contribute to 'going the extra mile' 
>> (upgrading the convertor, mailing in the new instrument name).
>>   
> While the toplevel term does provide some solace, it is obscure enough 
> that a casual user might look at it and think that something was wrong 
> because it does not intuitively make sense for the category to appear as 
> a value. What about this alternative: provide an "unknown instrument" 
> term with a unique accession #, but make the term name something like 
> "unknown (instrument type not specified or not in CV)". That would be 
> intuitive but still eye-catching (and it would be the eye-catching part 
> that implementors would want to minimize, because it makes them look 
> bad). ;)
> 
> -Matt
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev