Thread: [Psidev-ms-dev] LTQ Velos vs. LTQ Orbitrap Velos

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

We have no term for "LTQ Orbitrap Velos" in the CV. I seem to recall that this was done on purpose 
but I can't recall why. Can anyone shed light on that?

-Matt

Dear all,

As announced in one of the last phone conferences, we proposed to 
restructure the PSI-MS controlled vocabularies/ontology, to facilitate 
maintenance as well as use in tools like the semantic validator.

Our proposal has to main points:

1. Restructuration of the controlled vocabularies

Our intention at this level can be summarized in the following points:
. Keep things as simple as possible
. Respect present id’s as much as possible: we’ll try to keep the 
present id’s in order to maintain the maximal backwards compatibility. 
On the other hand, the overall structure will change. In practical 
terms: that the software generating mzIdentML will work perfectly, but 
the semantic validators will need to be updated.
. We’ll document things: every major definition will be carefully built. 
All definitions, when possible, will be generated using all the 
information inside MIAPE specifications. References to the mzML and 
mzIdentML formats will be made when possible. The proper documentation 
of everything will make possible the maintenance of the controlled 
vocabulary and will make things easier when semantic validators are built.

2. Maintain and update the controlled vocabularies.

Once the first step is finished, we’ll begin with the update and 
introduction of new terms proposed by the community. The exact mechanism 
how the CV will be updated needs to be discussed in detail in 
Heidelberg. I think we all agree that at the moment it is completely 
impractical, too lengthy and troublesome. We need to come up with a new 
strategy to do it

The restructuration and update of the controlled vocabularies will be 
made in a single step, sometime this year: there’ll be a single update 
with all the changes. In the meantime, we’ll make public all the 
proposals in the PSI mail list. We’ll discuss with the community the 
changes to be made (structure and definitions).

A detailed example of the changes we have in mind will be shown in the 
PSI meeting in Heidelberg. This example will take into account only the 
“software” section of the controlled vocabularies.
We are expecting to hear your opinions about this proposal, and go into 
detail in Heidelberg.

Best regards,

-- 
David Ovelleiro
Bioinformatician
PRIDE Group
Proteomics Services Team, PANDA Group
EMBL European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, UK
CB10 1SD

Hi David,

My understanding of the main problem with adding terms to the CV is a lack of consensus and/or 
expertise. AFAIK, the largest outstanding CV request is from 7/19/2010 from Salvador Martinez at 
ProteoRed. It was a big batch of terms spanning multiple subfields of expertise. The bulk of the 
terms are MALDI sample prep related and we have a decided lack of MALDI expertise in our working 
groups (AFAIK). My reply regarding those terms was:
> I think most of the sample preparation terms should go into http://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
 > Incidentally, has there been discussion about merging sep.obo with psi-ms.obo?
This met with no comment.

Some of the other terms were raw data signal processing related and I was the only one to comment on 
them which was not enough consensus to make me comfortable adding them.

The software terms were quickly added by Martin because there's little to "control" about them.

Since I'm not going to be at Heidelberg, I'd appreciate a preview of your detailed example changes 
to the software hierarchy. But I think that the CV structure is a small part of our CV worries. :) 
Perhaps we would benefit from an editorial dispatch mechanism like the journals use?

Thanks,
-Matt

On 4/5/2011 7:47 AM, David Ovelleiro wrote:
> Dear all,
>
> As announced in one of the last phone conferences, we proposed to
> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
> maintenance as well as use in tools like the semantic validator.
>
> Our proposal has to main points:
>
> 1. Restructuration of the controlled vocabularies
>
> Our intention at this level can be summarized in the following points:
> . Keep things as simple as possible
> . Respect present id’s as much as possible: we’ll try to keep the
> present id’s in order to maintain the maximal backwards compatibility.
> On the other hand, the overall structure will change. In practical
> terms: that the software generating mzIdentML will work perfectly, but
> the semantic validators will need to be updated.
> . We’ll document things: every major definition will be carefully built.
> All definitions, when possible, will be generated using all the
> information inside MIAPE specifications. References to the mzML and
> mzIdentML formats will be made when possible. The proper documentation
> of everything will make possible the maintenance of the controlled
> vocabulary and will make things easier when semantic validators are built.
>
>
> 2. Maintain and update the controlled vocabularies.
>
> Once the first step is finished, we’ll begin with the update and
> introduction of new terms proposed by the community. The exact mechanism
> how the CV will be updated needs to be discussed in detail in
> Heidelberg. I think we all agree that at the moment it is completely
> impractical, too lengthy and troublesome. We need to come up with a new
> strategy to do it
>
> The restructuration and update of the controlled vocabularies will be
> made in a single step, sometime this year: there’ll be a single update
> with all the changes. In the meantime, we’ll make public all the
> proposals in the PSI mail list. We’ll discuss with the community the
> changes to be made (structure and definitions).
>
> A detailed example of the changes we have in mind will be shown in the
> PSI meeting in Heidelberg. This example will take into account only the
> “software” section of the controlled vocabularies.
> We are expecting to hear your opinions about this proposal, and go into
> detail in Heidelberg.
>
>
> Best regards,
>

Dear Matt,

I'll be glad to send you our example material. I'll assume that the 
extension of your email(m*a*t*t.c*h*a*m*b*e*r*s*42) is gmail.

I'll send you (tomorrow, maybe in two days) a couple of attachments with 
the information. We'd really appreciate knowing your opinion about this.

I agree with you when you say that sometimes, you can find things out of 
the scope of the PSI-MS cv… that is something that we’ll need to handle.

On the other hand, I don’t agree when you say that there’s little to 
control in software. Maybe is one of the simplest sets of information, 
but if we are going to use the c.v. to validate data, we need some 
criteria… for example: in software, you’ll find the Xcalibur software in 
“adquisition”, “processing” and “analysis”… everywhere. And, although 
Xcalibur is clearly an “adquisition” software, performing several 
“processing” steps… I wouldn’t say that XCalibur is also an “analysis 
software”. If you allow this, further steps of validation are impossible 
(like “what kind of software are you using to adquire-process-analyse 
your data?”). That’s the reason why we’ll suggest a clear effort on 
documenting things… Having this documentation, we would be able to know 
why there’s an LTQ-velos and not an Orbitrap-velos, for example ;)

I’m not very sure what “editorial dispatch mechanism” means when talking 
about new terms in controlled vocabularies… but if you can detail it 
further, we’ll take it into account. Anyway, I think that our proposal 
will take a simpler (and maybe more practical) approach for the new 
candidates…

Anyway, I think it’s a pity that we are not going to be able to discuss 
all this at Heidelberg. I’ll send you the information ASAP.

Regards,

David

On 05/04/2011 16:05, Matthew Chambers wrote:
> Hi David,
>
> My understanding of the main problem with adding terms to the CV is a lack of consensus and/or
> expertise. AFAIK, the largest outstanding CV request is from 7/19/2010 from Salvador Martinez at
> ProteoRed. It was a big batch of terms spanning multiple subfields of expertise. The bulk of the
> terms are MALDI sample prep related and we have a decided lack of MALDI expertise in our working
> groups (AFAIK). My reply regarding those terms was:
>> I think most of the sample preparation terms should go into http://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
>   >  Incidentally, has there been discussion about merging sep.obo with psi-ms.obo?
> This met with no comment.
>
> Some of the other terms were raw data signal processing related and I was the only one to comment on
> them which was not enough consensus to make me comfortable adding them.
>
> The software terms were quickly added by Martin because there's little to "control" about them.
>
> Since I'm not going to be at Heidelberg, I'd appreciate a preview of your detailed example changes
> to the software hierarchy. But I think that the CV structure is a small part of our CV worries. :)
> Perhaps we would benefit from an editorial dispatch mechanism like the journals use?
>
> Thanks,
> -Matt
>
>
> On 4/5/2011 7:47 AM, David Ovelleiro wrote:
>> Dear all,
>>
>> As announced in one of the last phone conferences, we proposed to
>> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
>> maintenance as well as use in tools like the semantic validator.
>>
>> Our proposal has to main points:
>>
>> 1. Restructuration of the controlled vocabularies
>>
>> Our intention at this level can be summarized in the following points:
>> . Keep things as simple as possible
>> . Respect present id’s as much as possible: we’ll try to keep the
>> present id’s in order to maintain the maximal backwards compatibility.
>> On the other hand, the overall structure will change. In practical
>> terms: that the software generating mzIdentML will work perfectly, but
>> the semantic validators will need to be updated.
>> . We’ll document things: every major definition will be carefully built.
>> All definitions, when possible, will be generated using all the
>> information inside MIAPE specifications. References to the mzML and
>> mzIdentML formats will be made when possible. The proper documentation
>> of everything will make possible the maintenance of the controlled
>> vocabulary and will make things easier when semantic validators are built.
>>
>>
>> 2. Maintain and update the controlled vocabularies.
>>
>> Once the first step is finished, we’ll begin with the update and
>> introduction of new terms proposed by the community. The exact mechanism
>> how the CV will be updated needs to be discussed in detail in
>> Heidelberg. I think we all agree that at the moment it is completely
>> impractical, too lengthy and troublesome. We need to come up with a new
>> strategy to do it
>>
>> The restructuration and update of the controlled vocabularies will be
>> made in a single step, sometime this year: there’ll be a single update
>> with all the changes. In the meantime, we’ll make public all the
>> proposals in the PSI mail list. We’ll discuss with the community the
>> changes to be made (structure and definitions).
>>
>> A detailed example of the changes we have in mind will be shown in the
>> PSI meeting in Heidelberg. This example will take into account only the
>> “software” section of the controlled vocabularies.
>> We are expecting to hear your opinions about this proposal, and go into
>> detail in Heidelberg.
>>
>>
>> Best regards,
>>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

-- 
David Ovelleiro
Bioinformatician
PRIDE Group
Proteomics Services Team, PANDA Group
EMBL European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, UK
CB10 1SD

Xcalibur is perhaps misclassified, but aren't the classifications themselves sound? In other words, 
the structure itself is fine, but the way some of the terms are assigned into it may not be. I think 
there are plenty of misclassifications to be cleaned up, but the hierarchy seems more or less ok.

The way we get new terms into the CV is more inconsistent and represents the bigger problem IMO. For 
"editorial dispatch" I mean the way that journals send out papers to subfield experts because the 
journal doesn't staff an expert editor for every subfield. Perhaps we can just start sending 
unsolicited review requests to various experts. ;)

-Matt

On 4/5/2011 11:14 AM, David Ovelleiro wrote:
> Dear Matt,
>
> I'll be glad to send you our example material. I'll assume that the extension of your
> email(m*a*t*t.c*h*a*m*b*e*r*s*42) is gmail.
>
> I'll send you (tomorrow, maybe in two days) a couple of attachments with the information. We'd
> really appreciate knowing your opinion about this.
>
> I agree with you when you say that sometimes, you can find things out of the scope of the PSI-MS cv…
> that is something that we’ll need to handle.
>
> On the other hand, I don’t agree when you say that there’s little to control in software. Maybe is
> one of the simplest sets of information, but if we are going to use the c.v. to validate data, we
> need some criteria… for example: in software, you’ll find the Xcalibur software in “adquisition”,
> “processing” and “analysis”… everywhere. And, although Xcalibur is clearly an “adquisition”
> software, performing several “processing” steps… I wouldn’t say that XCalibur is also an “analysis
> software”. If you allow this, further steps of validation are impossible (like “what kind of
> software are you using to adquire-process-analyse your data?”). That’s the reason why we’ll suggest
> a clear effort on documenting things… Having this documentation, we would be able to know why
> there’s an LTQ-velos and not an Orbitrap-velos, for example ;)
>
> I’m not very sure what “editorial dispatch mechanism” means when talking about new terms in
> controlled vocabularies… but if you can detail it further, we’ll take it into account. Anyway, I
> think that our proposal will take a simpler (and maybe more practical) approach for the new candidates…
>
> Anyway, I think it’s a pity that we are not going to be able to discuss all this at Heidelberg. I’ll
> send you the information ASAP.
>
> Regards,
>
> David
>
>
>
>
> On 05/04/2011 16:05, Matthew Chambers wrote:
>> Hi David,
>>
>> My understanding of the main problem with adding terms to the CV is a lack of consensus and/or
>> expertise. AFAIK, the largest outstanding CV request is from 7/19/2010 from Salvador Martinez at
>> ProteoRed. It was a big batch of terms spanning multiple subfields of expertise. The bulk of the
>> terms are MALDI sample prep related and we have a decided lack of MALDI expertise in our working
>> groups (AFAIK). My reply regarding those terms was:
>>> I think most of the sample preparation terms should go intohttp://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
>>   >  Incidentally, has there been discussion about merging sep.obo with psi-ms.obo?
>> This met with no comment.
>>
>> Some of the other terms were raw data signal processing related and I was the only one to comment on
>> them which was not enough consensus to make me comfortable adding them.
>>
>> The software terms were quickly added by Martin because there's little to "control" about them.
>>
>> Since I'm not going to be at Heidelberg, I'd appreciate a preview of your detailed example changes
>> to the software hierarchy. But I think that the CV structure is a small part of our CV worries. :)
>> Perhaps we would benefit from an editorial dispatch mechanism like the journals use?
>>
>> Thanks,
>> -Matt
>>
>>
>> On 4/5/2011 7:47 AM, David Ovelleiro wrote:
>>> Dear all,
>>>
>>> As announced in one of the last phone conferences, we proposed to
>>> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
>>> maintenance as well as use in tools like the semantic validator.
>>>
>>> Our proposal has to main points:
>>>
>>> 1. Restructuration of the controlled vocabularies
>>>
>>> Our intention at this level can be summarized in the following points:
>>> . Keep things as simple as possible
>>> . Respect present id’s as much as possible: we’ll try to keep the
>>> present id’s in order to maintain the maximal backwards compatibility.
>>> On the other hand, the overall structure will change. In practical
>>> terms: that the software generating mzIdentML will work perfectly, but
>>> the semantic validators will need to be updated.
>>> . We’ll document things: every major definition will be carefully built.
>>> All definitions, when possible, will be generated using all the
>>> information inside MIAPE specifications. References to the mzML and
>>> mzIdentML formats will be made when possible. The proper documentation
>>> of everything will make possible the maintenance of the controlled
>>> vocabulary and will make things easier when semantic validators are built.
>>>
>>>
>>> 2. Maintain and update the controlled vocabularies.
>>>
>>> Once the first step is finished, we’ll begin with the update and
>>> introduction of new terms proposed by the community. The exact mechanism
>>> how the CV will be updated needs to be discussed in detail in
>>> Heidelberg. I think we all agree that at the moment it is completely
>>> impractical, too lengthy and troublesome. We need to come up with a new
>>> strategy to do it
>>>
>>> The restructuration and update of the controlled vocabularies will be
>>> made in a single step, sometime this year: there’ll be a single update
>>> with all the changes. In the meantime, we’ll make public all the
>>> proposals in the PSI mail list. We’ll discuss with the community the
>>> changes to be made (structure and definitions).
>>>
>>> A detailed example of the changes we have in mind will be shown in the
>>> PSI meeting in Heidelberg. This example will take into account only the
>>> “software” section of the controlled vocabularies.
>>> We are expecting to hear your opinions about this proposal, and go into
>>> detail in Heidelberg.

Hi David, Matt, thanks for this summary and discussion. I look forward to
the discussion in Heidelberg. I think this is all good, although I might
suggest doing updates in smaller chunks rather than one grand update, but we
can debate this.

Thanks!
Eric

> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@gm...]
> Sent: Tuesday, April 05, 2011 9:49 AM
> To: psi...@li...
> Subject: Re: [Psidev-ms-dev] PSI-MS controlled vocabularies proposal
> 
> Xcalibur is perhaps misclassified, but aren't the classifications
> themselves sound? In other words,
> the structure itself is fine, but the way some of the terms are assigned
> into it may not be. I think
> there are plenty of misclassifications to be cleaned up, but the hierarchy
> seems more or less ok.
> 
> The way we get new terms into the CV is more inconsistent and represents
> the bigger problem IMO. For
> "editorial dispatch" I mean the way that journals send out papers to
> subfield experts because the
> journal doesn't staff an expert editor for every subfield. Perhaps we can
> just start sending
> unsolicited review requests to various experts. ;)
> 
> -Matt
> 
> 
> On 4/5/2011 11:14 AM, David Ovelleiro wrote:
> > Dear Matt,
> >
> > I'll be glad to send you our example material. I'll assume that the
> extension of your
> > email(m*a*t*t.c*h*a*m*b*e*r*s*42) is gmail.
> >
> > I'll send you (tomorrow, maybe in two days) a couple of attachments with
> the information. We'd
> > really appreciate knowing your opinion about this.
> >
> > I agree with you when you say that sometimes, you can find things out of
> the scope of the PSI-MS cv.
> > that is something that we'll need to handle.
> >
> > On the other hand, I don't agree when you say that there's little to
> control in software. Maybe is
> > one of the simplest sets of information, but if we are going to use the
> c.v. to validate data, we
> > need some criteria. for example: in software, you'll find the Xcalibur
> software in "adquisition",
> > "processing" and "analysis". everywhere. And, although Xcalibur is
> clearly an "adquisition"
> > software, performing several "processing" steps. I wouldn't say that
> XCalibur is also an "analysis
> > software". If you allow this, further steps of validation are impossible
> (like "what kind of
> > software are you using to adquire-process-analyse your data?"). That's
> the reason why we'll suggest
> > a clear effort on documenting things. Having this documentation, we
> would be able to know why
> > there's an LTQ-velos and not an Orbitrap-velos, for example ;)
> >
> > I'm not very sure what "editorial dispatch mechanism" means when talking
> about new terms in
> > controlled vocabularies. but if you can detail it further, we'll take it
> into account. Anyway, I
> > think that our proposal will take a simpler (and maybe more practical)
> approach for the new candidates.
> >
> > Anyway, I think it's a pity that we are not going to be able to discuss
> all this at Heidelberg. I'll
> > send you the information ASAP.
> >
> > Regards,
> >
> > David
> >
> >
> >
> >
> > On 05/04/2011 16:05, Matthew Chambers wrote:
> >> Hi David,
> >>
> >> My understanding of the main problem with adding terms to the CV is a
> lack of consensus and/or
> >> expertise. AFAIK, the largest outstanding CV request is from 7/19/2010
> from Salvador Martinez at
> >> ProteoRed. It was a big batch of terms spanning multiple subfields of
> expertise. The bulk of the
> >> terms are MALDI sample prep related and we have a decided lack of MALDI
> expertise in our working
> >> groups (AFAIK). My reply regarding those terms was:
> >>> I think most of the sample preparation terms should go
> intohttp://code.google.com/p/gelml/source/browse/trunk/CV/sep.obo.
> >>   >  Incidentally, has there been discussion about merging sep.obo with
> psi-ms.obo?
> >> This met with no comment.
> >>
> >> Some of the other terms were raw data signal processing related and I
> was the only one to comment on
> >> them which was not enough consensus to make me comfortable adding them.
> >>
> >> The software terms were quickly added by Martin because there's little
> to "control" about them.
> >>
> >> Since I'm not going to be at Heidelberg, I'd appreciate a preview of
> your detailed example changes
> >> to the software hierarchy. But I think that the CV structure is a small
> part of our CV worries. :)
> >> Perhaps we would benefit from an editorial dispatch mechanism like the
> journals use?
> >>
> >> Thanks,
> >> -Matt
> >>
> >>
> >> On 4/5/2011 7:47 AM, David Ovelleiro wrote:
> >>> Dear all,
> >>>
> >>> As announced in one of the last phone conferences, we proposed to
> >>> restructure the PSI-MS controlled vocabularies/ontology, to facilitate
> >>> maintenance as well as use in tools like the semantic validator.
> >>>
> >>> Our proposal has to main points:
> >>>
> >>> 1. Restructuration of the controlled vocabularies
> >>>
> >>> Our intention at this level can be summarized in the following points:
> >>> . Keep things as simple as possible
> >>> . Respect present id's as much as possible: we'll try to keep the
> >>> present id's in order to maintain the maximal backwards compatibility.
> >>> On the other hand, the overall structure will change. In practical
> >>> terms: that the software generating mzIdentML will work perfectly, but
> >>> the semantic validators will need to be updated.
> >>> . We'll document things: every major definition will be carefully
> built.
> >>> All definitions, when possible, will be generated using all the
> >>> information inside MIAPE specifications. References to the mzML and
> >>> mzIdentML formats will be made when possible. The proper documentation
> >>> of everything will make possible the maintenance of the controlled
> >>> vocabulary and will make things easier when semantic validators are
> built.
> >>>
> >>>
> >>> 2. Maintain and update the controlled vocabularies.
> >>>
> >>> Once the first step is finished, we'll begin with the update and
> >>> introduction of new terms proposed by the community. The exact
> mechanism
> >>> how the CV will be updated needs to be discussed in detail in
> >>> Heidelberg. I think we all agree that at the moment it is completely
> >>> impractical, too lengthy and troublesome. We need to come up with a
> new
> >>> strategy to do it
> >>>
> >>> The restructuration and update of the controlled vocabularies will be
> >>> made in a single step, sometime this year: there'll be a single update
> >>> with all the changes. In the meantime, we'll make public all the
> >>> proposals in the PSI mail list. We'll discuss with the community the
> >>> changes to be made (structure and definitions).
> >>>
> >>> A detailed example of the changes we have in mind will be shown in the
> >>> PSI meeting in Heidelberg. This example will take into account only
> the
> >>> "software" section of the controlled vocabularies.
> >>> We are expecting to hear your opinions about this proposal, and go
> into
> >>> detail in Heidelberg.
> 
> --------------------------------------------------------------------------
> ----
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev