psidev-ms-dev

[Psidev-ms-dev] Some comments on the mzML schema from today's call

[Randy J. <rkj...@in...>]

There are a couple of questions regarding the schema following today's
teleconference:

 

1.	spectrumDescription is currently marked as a required element,
but it has no required attributes, or sub-elements.  This should
probably be made optional if we keep the current optional status on all
the elements below it.
2.	The required attribute 'scanNumber' within <spectrum> seems
redundant with <scan> under spectrumDescription (maybe not - see my
comment below).
3.	Both scanNumber and msLevel have been moved far up in the
hierarchy and are required - they should be lower and msLevel should be
optional.

 

If we make a change to the <spectrum> element and remove scanNumber (and
use the element <scan> instead), and make msLevel either optional, or an
attribute or a cvParam somewhere, then we could use cvParams to name the
data vectors and allow for analog channels, UV channels and even PDA
data (I know, I sound like a broken record here).

 

Maybe I just missed something, but the original purpose of the
acquisitionList was to allow for a spectrum to be the sum or average of
a collection (list, ranges, etc) of individual spectra, each of which
has some of the attributes of the current <scan> element.  What is the
value in having both the <acquisition> element and the <scan> element?
Can they be combined?

 

Thanks,

Randy 

 

Randall K Julian, Jr. Ph.D.
President
Indigo BioSystems,  Inc.
(317) 536-2736 x101
(317) 306-5447 mobile

www.indigobio.com <http://www.indigobio.com/> 

NOTICE: This message may contain confidential or privileged information
that is for the sole use of the intended recipient. Any unauthorized
review, use, disclosure, copying or distribution is strictly prohibited.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.

 

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

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthousiasts,


After Tuesdays (5 Feb 2008) phone conference, I've given the addition of 
an 'unknown instrument' term some further thought, since it made me feel 
ever so slightly uncomfortable to add this 'escape hatch' to the CV.

Upon consulting with Luisa Montecchi about this, she suggested a 
potentially viable alternative: why not simply use the top-level CV term 
instead? So whenever the actual instrument model is not known, we would 
annotate as 'MS:1000031 -- instrument model'.

I see two benefits in this approach:

  1) no need to include a term called 'unknown instrument' in the CV, 
which to me at least feels a bit awkward;
  2) the validator can cope easily with allowing/disallowing this parent 
term while allowing all children regardless, whereas allowing all but X 
children of a term (as we would have to do in the case of adding an 
'unknown instrument' child term to 'instrument model') is possible, but 
ugly.


There is also a downside to this approach -- which I will also try to 
subvert into an upside :)

  the knowledge that the top-level term is to be used for 'unknown 
instrument' will be documented in the spec doc, but it is likely that 
few people will read this document in earnest. So the ability to flag an 
instrument as 'unknown' will be an 'expert feature' only. The upside of 
this is that it provides a ready incentive to convertor implementers and 
  instrument manufacturers to go the very short extra distance to 
accommodate (interactive) user input of the instrument, or addition of 
the new instrument model to the CV, respectively. Interestingly, 
enabling/encouraging both of these solutions were actually raised as 
important points during the phone conference.


What are your opinions on this proposal?


Cheers,

lnnrt.

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

[Angel P. <an...@ma...>]

On Feb 6, 2008 10:48 AM, Lennart Martens <len...@eb...> wrote:

> potentially viable alternative: why not simply use the top-level CV term
> instead? So whenever the actual instrument model is not known, we would
> annotate as 'MS:1000031 -- instrument model'.
>

I like it. -angel

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

[Mike C. <tu...@gm...>]

On Feb 6, 2008 9:48 AM, Lennart Martens <len...@eb...> wrote:
>   the knowledge that the top-level term is to be used for 'unknown
> instrument' will be documented in the spec doc, but it is likely that
> few people will read this document in earnest.

Indeed.  I suspect that a significant number of users will be reading
mzML without carefully studying the spec, and without bothering with
the CV (or having an up-to-date CV), with the simple goal of
extracting the basic spectra (parent mass, charge, peaks).  I hope
that this will basically work.  If there are any potential problems
with this, it might be worth considering whether they can be
mitigated.

As for your question, I don't really have an opinion--I'm afraid I
don't have time at the moment to study the spec...  :-)

Mike

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

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

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"?) and I don't see it so much as an "expert feature" as a 
(slightly) obfuscated one. 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?

-Matt


Lennart Martens wrote:
> Dear PSI-MS Enthousiasts,
>
>
> After Tuesdays (5 Feb 2008) phone conference, I've given the addition of 
> an 'unknown instrument' term some further thought, since it made me feel 
> ever so slightly uncomfortable to add this 'escape hatch' to the CV.
>
> Upon consulting with Luisa Montecchi about this, she suggested a 
> potentially viable alternative: why not simply use the top-level CV term 
> instead? So whenever the actual instrument model is not known, we would 
> annotate as 'MS:1000031 -- instrument model'.
>
> I see two benefits in this approach:
>
>   1) no need to include a term called 'unknown instrument' in the CV, 
> which to me at least feels a bit awkward;
>   2) the validator can cope easily with allowing/disallowing this parent 
> term while allowing all children regardless, whereas allowing all but X 
> children of a term (as we would have to do in the case of adding an 
> 'unknown instrument' child term to 'instrument model') is possible, but 
> ugly.
>
>
> There is also a downside to this approach -- which I will also try to 
> subvert into an upside :)
>
>   the knowledge that the top-level term is to be used for 'unknown 
> instrument' will be documented in the spec doc, but it is likely that 
> few people will read this document in earnest. So the ability to flag an 
> instrument as 'unknown' will be an 'expert feature' only. The upside of 
> this is that it provides a ready incentive to convertor implementers and 
>   instrument manufacturers to go the very short extra distance to 
> accommodate (interactive) user input of the instrument, or addition of 
> the new instrument model to the CV, respectively. Interestingly, 
> enabling/encouraging both of these solutions were actually raised as 
> important points during the phone conference.
>
>
> What are your opinions on this proposal?
>
>
> Cheers,
>
> lnnrt.
>
>
>   

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

[Lennart M. <len...@eb...>]

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.

> and I don't see it so much as an "expert feature" as a 
> (slightly) obfuscated one.

You have seen straight through my euphemism :). But it is important to 
note that this is not intentionally obfuscated -- it will be in the spec 
doc after all.

> 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).

Hope this further clarifies my thoughts,


Cheers,

lnnrt.

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

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

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

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

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

[Fredrik L. <Fre...@im...>]

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
>   

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

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

Thanks for the input and useful example, Fredrik.  You've identified an important question to focus on: the intended usage of the schema with extra-CV items, like new machines or software tools.

I personally feel that the spec should be as complete as possible, and not encourage adding extra information in a non-validating way.  What I'd like to see is a very active and well publicized mechanism for getting new terms added to the CV in a timely way, after the standardization is met.  The model I'd imagine is that companies/institutions beta-test their tools with modified mzML such as you created, and perhaps modify the validator for in-house usage.  When the time comes to share these file externally, they would contact the standards group to add their term-- hopefully a painless and routine issue taking no more than a week or two.

(Again speaking only for myself, I would have preferred a much more strongly typed format, such as almost entirely element-based XML with traditional XML schema validation, rather than using cvParam and an external validator.  Since we're doing this the cvParam way, I'd still like to keep things strictly conforming to the format.)

This is just my two cents.  I'd like to hear from Lennart and everyone else too :)

Josh


Fredrik Levander wrote:
> 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

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

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

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

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

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

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
>
>   

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

[Angel P. <an...@ma...>]

On Feb 12, 2008 2:52 PM, Eric Deutsch <ede...@sy...> 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
>

Its not counterintuitive to me, but I don't care much which way we go. E.g.
I am not invested in this scheme the way that the validator folks might be.
-angel

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

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

Hi Eric,

You missed my strong vote for "B)".

-Josh


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

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

[Kessner, D. E. <Dar...@cs...>]

I'd like to vote for B also.  I think the meaning is clearer to the
human reader, both in the mzML, and in the code that reads it.


Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Tuesday, February 12, 2008 2:16 PM
To: Mass spectrometry standard development
Cc: Eric Deutsch
Subject: Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV
parameter thoughts

Hi Eric,

You missed my strong vote for "B)".

-Josh


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

------------------------------------------------------------------------
-
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
IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

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

[Marc S. <st...@in...>]

Hi all,

if the vote is still up, i vote for B) too!

- Marc

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

[Randy J. <rkj...@in...>]

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

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

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

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