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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi everyone, by my tally, we now stand like this on the unknown cv param
topic:

A) <cvParam cvLabel="MS" accession="MS:1000031" name="instrument model">
value=""/>
B) <cvParam cvLabel="MS" accession="MS:1099931" name="unknown instrument
model" value=""/>
C) 

Votes for A: 3 (Lennart, Luisa and Angel)
Votes for B: 5 (Matt, Josh, Eric, Darren, Marc, Randy)

Any other votes/comments?

Thanks,
Eric

> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Randy Julian
> Sent: Wednesday, February 13, 2008 1:29 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Some additional 'Unknown
> instrument'CVparameter thoughts
> 
> Eric,
> 
> I am in favor of 'B', I think mzML validity and MIAPE compliance are
two
> different things.  If a journal won't let you publish your old
> convertered .dta files because you cannot remember the instrument
> doesn't mean you can't continue to search them internal to your group
or
> share them with another group.
> 
> Randy
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Eric
> Deutsch
> Sent: Tuesday, February 12, 2008 2:52 PM
> To: Mass spectrometry standard development
> Cc: Eric Deutsch
> Subject: Re: [Psidev-ms-dev] Some additional 'Unknown instrument'
> CVparameter thoughts
> 
> 
> 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
> 
>
------------------------------------------------------------------------
-
> 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