Menu
▾
▴
Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts
|
From: Matthew C. <mat...@va...> - 2008-02-12 20:06:25
|
Hi all, Eric, you judge correctly that I prefer B, but there is a third option (just for completeness) C) Yes, it's blank on purpose. :) It's conceivable that for parameters which are acceptably unknown (in at least non-MIAPE mode, but possibly MIAPE as well), such parameters could just be absent from the parameter group it would be valid to appear in. Benefits of C) - No need to litter the CV with "xxx unknown" terms - Should be easy for the existing validator to accommodate - Intuitive Drawbacks of C) - Could be confused for "I didn't think that parameter belong in that section" or "I didn't think that parameter was applicable in my circumstances;" i.e. "unknown" would become synonymous with "n/a" which is clearly undesirable. -Matt Eric Deutsch wrote: > Hi everyone, I'm trying to see if we can get to some consensus on some > of these ongoing threads. Regarding the "unknown instrument" problem, I > think there has been some confusion, so let me see if I can clarify and > ask for a final round of opinions. I agree with Fredrik's comments > below that his examples below are *not* what is intended. Here is what I > believe Lennart intended: > > A) > <cvParam cvLabel="MS" accession="MS:1000031" name="instrument model" > value=""/> > > Or the other alternative is to create a term for unknown: > > B) > <cvParam cvLabel="MS" accession="MS:1099931" name="unknown instrument > model" value=""/> > (where the number is obviously made up by me right now, but would be in > the CV) > > So those are the choices. Putting something in the value attribute is > not an option as Fredrik concludes below. > > Benefits of A) > - No need to litter the CV with "xxx unknown" terms > - Happenstance very easy for the existing validator software to > accommodate > - Somewhat counterintuitive and thus dissuades laziness > Drawbacks of A) > - Somewhat counterintuitive and awkward > > Benefits of B) > - Very intuitive and straightforward: the concept of what instrument > generated these spectra is captured by the concept "sorry, I just don't > know which instrument it was" > Drawbacks of B) > - Opens the door to perhaps needing to sprinkle other unknowns in the CV > - Is a little more inviting to users to be lazy and claim they don't > know, when with a little more effort they could find out and report > properly (because "unknown" is not an *obvious* option) > - Would require more development in the validator to properly handle a > special term like this. > > Based on the feedback I saw so far, Lennart, Luisa and Angel like A. > Matt seemed more in favor of B. No clear reads on others. > > I myself prefer B. To me it feels like A is a convenient but > counterintuitive trick to working around the problem. B feels like the > right solution even if it facilitates laziness. I don't think that will > be a big problem. I'm sure we can come up with some syntax for the > validator to permit or disallow "ambiguity terms" as desired. > > So, what say ye? > > > > > >> From: psi...@li... >> > [mailto:psidev-ms-dev- > >> Hi Lennart, Josh, Matt and others, >> >> If the top level term is allowed it will be possible to define not >> > only > >> instrument value='unknown', but also instruments that are not in the >> > CV > >> by putting something in the value field: >> <cvParam cvLabel="MS" accession="MS:1000031" name="instrument model" >> value="The new mass spec not in CV"/> >> <cvParam cvLabel="MS" accession="MS:1000031" name="instrument model" >> value="unknown"/> >> Instead of the intended: >> <cvParam cvLabel="MS" accession="MS:1000189" name="q-tof ultima" >> value=""/> >> I'm not so sure that this is wanted. Especially since unknown could be >> written as 'not known', 'not specified' etcetera. It make sense to >> > have > >> a CV term for 'unknown', but it would be quite a few 'unknown' terms >> > to > >> add to the CV to get one for each required category in the mzML >> schema...At some places it would be enough with just 'unknown' >> (source,detector etc), but at other places it must be specified what >> > is > >> unknown! >> >> Anyway, I am still for usage of top level elements :-) , see line 16 >> > at: > >> http://trac.thep.lu.se/trac/fp6- >> prodac/browser/trunk/mzML/FF_070504_MSMS_5B.mzML >> >> cheers >> >> Fredrik >> >> Joshua Tasman skrev: >> >>> 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 >>>> >>>> >>> > ------------------------------------------------------------------------ > >> - >> >>> 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 >>> >>> >> > ------------------------------------------------------------------------ > - > >> 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 >> > > ------------------------------------------------------------------------- > 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 > > |
