Re: [Psidev-ms-dev] [Psidev-pi-dev] One of these dissociation methods doesn't belong...

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

Youch! Thanks for tugging on the string to reveal this. Maybe some
distress is appropriate after all.

I think the policy has to be that if we're adding in free-text slots for
search engine parameter values, we cannot multi-parent these throughout
the CV otherwise we have a mess.

I have not been part of the conversation on search engine parameters, but
clearly the current state is a problem. It seems like the 3 options are:

1) Just use userParams like Matt apparently suggested

2) Use a set of free-text descriptions for concepts, like is currently
done, but without multiparenting these things to wreck the rest of the CV.

3) Actually use the CV properly. Instead of allow a free-text term
"Fragmentation method used (CID, MPD, ECD, PQD, ETD, HCD, Any)", make the
writer specify the exact fragmentation method used using a proper CV term.
Allowing these free-text terms somewhat defeats the purpose of the CV.

4) Option 4 is what seems to be the current state, but that creates many
problems and cannot stand.

I don't know if this has already been hashed out, but I think we need an
explanation from Martin because the current state is a problem.

Martin?

Thanks,
Eric

> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@gm...]
> Sent: Tuesday, April 19, 2011 9:49 AM
> To: psi...@li...
> Cc: psi...@li...; psidev-ms-
> vo...@li...
> Subject: Re: [Psidev-ms-dev] [Psidev-pi-dev] One of these dissociation
> methods doesn't belong...
>
> Hi all,
>
> It turns out the problem was much more significant than I saw at first.
> I just looked at the first
> instance and posted it to the list. There are dozens of other issues.
> And then there's this:
>
> [Term]
> id: MS:1001754
> name: ProteomeDiscoverer:Mascot:Please Do not Touch this
> def: "Unknown Mascot parameter which ProteomeDiscoverer uses for mascot
> searches." [PSI:MS]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1001302 ! search engine specific input parameter
>
> Was I so wrong to want these to be UserParams after all? ;)
>
> Here is the diff so far. These are just the ones I'm sure about.
>
> --- psi-ms.1.157.obo	Fri Apr  8 01:54:31 2011
> +++ psi-ms.obo	Tue Apr 19 11:38:17 2011
> @@ -9808,7 +9808,6 @@
>   def: "Ionization source (electro-, nano-, thermospray, electron
> impact, APCI, MALDI, FAB, ...)."
> [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1000008 ! ionization type
>
>   [Term]
>   id: MS:1001604
> @@ -9816,7 +9815,6 @@
>   def: "Fragmentation method used (CID, MPD, ECD, PQD, ETD, HCD, Any)."
> [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1000044 ! dissociation method
>
>   [Term]
>   id: MS:1001605
> @@ -9824,7 +9822,6 @@
>   def: "Lower retention-time limit." [PSI:MS]
>   xref: value-type:xsd\:float "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1000894 ! retention time
>   relationship: has_units UO:0000010 ! second
>   relationship: has_units UO:0000031 ! minute
>
> @@ -9834,7 +9831,6 @@
>   def: "Type of mass spectrometer used (ITMS, FTMS, TOFMS, SQMS, TQMS,
> SectorMS)." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1000451 ! mass analyzer
>
>   [Term]
>   id: MS:1001607
> @@ -9865,7 +9861,6 @@
>   def: "Level of the mass spectrum (MS/MS=MS2 ... MS10)." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1000511 ! ms level
>
>   [Term]
>   id: MS:1001611
> @@ -9873,7 +9868,6 @@
>   def: "Polarity mode (positive or negative)." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1000037 ! polarity
>
>   [Term]
>   id: MS:1001612
> @@ -9944,7 +9938,6 @@
>   def: "Upper retention-time limit." [PSI:MS]
>   xref: value-type:xsd\:float "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1000894 ! retention time
>   relationship: has_units UO:0000010 ! second
>   relationship: has_units UO:0000031 ! minute
>
> @@ -10178,7 +10171,6 @@
>   def: "Number of attempts to submit the Mascot search." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1001266 ! role type
>
>   [Term]
>   id: MS:1001653
> @@ -10194,7 +10186,6 @@
>   def: "Specifies the enzyme reagent used for protein digestion."
> [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1001045 ! cleavage agent name
>
>   [Term]
>   id: MS:1001655
> @@ -10248,8 +10239,6 @@
>   def: "Database to use in the search (configured on the Mascot
> server)." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1001011 ! search database details
> -is_a: MS:1001013 ! database name
>
>   [Term]
>   id: MS:1001662
> @@ -10284,8 +10273,6 @@
>   def: "Limits searches to entries from a particular species or group
> of species." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is-a: MS:1001468 ! taxonomy: common name
> -is-a: MS:1001469 ! taxonomy: scientific name
>
>   [Term]
>   id: MS:1001666
> @@ -10539,7 +10526,6 @@
>   def: "Format of the exported spectra (*.dta, *.mgf or *.mzData.)"
> [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1001459 ! file format
>
>   [Term]
>   id: MS:1001702
> @@ -10771,8 +10757,6 @@
>   def: "Sample organism (used for annotation purposes)." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is-a: MS:1001468 ! taxonomy: common name
> -is-a: MS:1001469 ! taxonomy: scientific name
>
>   [Term]
>   id: MS:1001735
> @@ -10780,7 +10764,6 @@
>   def: "Full path database name." [PSI:MS]
>   xref: value-type:xsd\:string  "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1001011 ! search database details
>
>   [Term]
>   id: MS:1001736
> @@ -10795,8 +10778,6 @@
>   def: "File type (if not pepXML)." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1001459 ! file format
> -is_a: MS:1001040 ! intermediate analysis format
>
>   [Term]
>   id: MS:1001738
> @@ -10821,7 +10802,6 @@
>   def: "Windows full path for database." [PSI:MS]
>   xref: value-type:xsd\:string "The allowed value-type for this CV
> term."
>   is_a: MS:1001302 ! search engine specific input parameter
> -is_a: MS:1001011 ! search database details
>
>
> It appears Martin tried to use the is_a relationship to be a CV-aware
> specific version of the "xref:
> value-type". It's a very interesting idea, but not one the semantic
> validators currently support and
> the way he did it would actually break the validators (cause them to
> call invalid files valid).
>
> So I guess we need to decide whether to just delete these outright or
> perhaps comment them out so
> they can be used later if we do develop a CV-aware "xref: value-type"?
>
> -Matt
>
>
> On 4/18/2011 12:03 PM, Eric Deutsch wrote:
> > Hi David, Matt, thank you for the discussion. Mistakes will happen,
> so
> > let's just move forward with minimum distress. This is an easy fix,
> so I
> > would be grateful if you would just go ahead and make it, Matt,
> thanks.
> >
> > I would like to recommend the following policy: any addition or
> change to
> > the CV be pre-announced to the PI list or the MS list (as
> appropriate) and
> > the vocab list shortly before they are committed. This is will let
> > everyone know what is happening, and allows the opportunity to catch
> > mistakes (if the new entries are posted verbatim, which I encourage
> when
> > modest).
> >
> > Second, I would again urge you, David, to stay fairly current with
> the CV
> > so your reorganization attempts do not stray too far from the version
> in
> > CVS. I would urge you to announce and check in the changes you have
> worked
> > on at the meeting during this week. I plan on checking in some more
> items
> > this week and the greater we diverge, the more difficult your job
> will be
> > to merge the two branches.
> >
> > Thank you,
> > Eric
> >
> >
> >> -----Original Message-----
> >> From: David Ovelleiro [mailto:do...@eb...]
> >> Sent: Monday, April 18, 2011 7:57 AM
> >> To: psi...@li...
> >> Subject: Re: [Psidev-pi-dev] One of these dissociation methods
> doesn't
> >> belong...
> >>
> >> I completely agree with the action proposed by Matt.
> >> The way in which this term was introduced (badly ;) ) and when was
> >> introduced (a couple of days before the PSI meeting :( ) and without
> >> previous publication in the PSI mailing list... is in my opinion a
> >> distressing precedent, and will make very difficult the actions we
> >> proposed in Heidelberg.
> >>
> >> David
> >>
> >> On 18/04/2011 15:46, Matthew Chambers wrote:
> >>> I agree with your suggestion assuming that nobody has started using
> >> the broken parent relationship
> >>> yet (a fairly safe assumption I guess). This sets a precedent for
> >> handling similar cases in the
> >>> future. Does anybody disagree with this? If not, I'll make the fix
> >> later today or tomorrow.
> >>>
> >>> -Matt
> >>>
> >>>
> >>> On 4/16/2011 7:56 AM, Eric Deutsch wrote:
> >>>> Hi Matt, normally moving a term to a new location would require a
> >> level 2
> >>>> version number change, but if I understand the situation here,
> this
> >> term
> >>>> is in the correct location via one parent, but has a second,
> >> spurious
> >>>> parent probably due to cut and paste error. I think it is fine to
> >> simply
> >>>> remove the errant parent and increment the minor version number,
> >> because
> >>>> this is just an error fix. Or am I misunderstanding?
> >>>>
> >>>> Thanks,
> >>>> Eric
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Matt Chambers [mailto:mat...@gm...]
> >>>>> Sent: Friday, April 15, 2011 5:28 PM
> >>>>> To: psi...@li...
> >>>>> Subject: Re: [Psidev-pi-dev] One of these dissociation methods
> >> doesn't
> >>>>> belong...
> >>>>>
> >>>>> I would be surprised if this was a typo since the term has both
> the
> >>>>> search
> >>>>> engine input parameter and dissociation method parent terms. What
> >> is
> >>>>> the PSI
> >>>>> process for moving terms in the hierarchy? What is our versioning
> >>>>> policy for it?
> >>>>>
> >>>>> -Matt
> >>>>>
> >>>>>
> >>>>> On 4/15/2011 2:31 PM, Eric Deutsch wrote:
> >>>>>> Hi Matt, thanks for noticing this. The solution, of course, if
> >> just
> >>>>> to
> >>>>>> reparent the term to where it was intended. Probably a simple
> >> typo.
> >>>>>>
> >>>>>> David Ovelleiro, Andreas Roempp and others were doing some CV
> >>>>>> reorganization here at the PSI meeting and were looking at the
> >> list
> >>>>> of
> >>>>>> dissociation types, although curiously I didn't notice this
> >> problem
> >>>>> at the
> >>>>>> time.
> >>>>>>
> >>>>>> David, shall we fix this problem right away, or will you check
> in
> >> the
> >>>>>> changes you have made so far and have already fixed this?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Eric
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Matthew Chambers [mailto:mat...@gm...]
> >>>>>>> Sent: Thursday, April 14, 2011 2:07 PM
> >>>>>>> To: psi...@li...
> >>>>>>> Subject: [Psidev-pi-dev] One of these dissociation methods
> >> doesn't
> >>>>>>> belong...
> >>>>>>>
> >>>>>>> This is why we post proposed CV terms to the list before adding
> >>>>> them.
> >>>>>>> ;)
> >>>>>>>
> >>>>>>> It's clearly wrong for a search engine input parameter to show
> up
> >> in
> >>>>> an
> >>>>>>> mzML's activation element!
> >>>>>>> Now what do we do about it?
> >>>>>>>
> >>>>>>> -Matt
> >>> -------------------------------------------------------------------
> --
> >> ---------
> >>> Benefiting from Server Virtualization: Beyond Initial Workload
> >>> Consolidation -- Increasing the use of server virtualization is a
> top
> >>> priority.Virtualization can reduce costs, simplify management, and
> >> improve
> >>> application availability and disaster protection. Learn more about
> >> boosting
> >>> the value of server virtualization. http://p.sf.net/sfu/vmware-
> >> sfdev2dev
> >>> _______________________________________________
> >>> Psidev-pi-dev mailing list
> >>> Psi...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> >>
> >>
> >> --
> >> David Ovelleiro
> >> Bioinformatician
> >> PRIDE Group
> >> Proteomics Services Team, PANDA Group
> >> EMBL European Bioinformatics Institute
> >> Wellcome Trust Genome Campus
> >> Hinxton, Cambridge, UK
> >> CB10 1SD
> >>
> >>
> >> --------------------------------------------------------------------
> ---
> >> -------
> >> Benefiting from Server Virtualization: Beyond Initial Workload
> >> Consolidation -- Increasing the use of server virtualization is a
> top
> >> priority.Virtualization can reduce costs, simplify management, and
> >> improve
> >> application availability and disaster protection. Learn more about
> >> boosting
> >> the value of server virtualization. http://p.sf.net/sfu/vmware-
> >> sfdev2dev
> >> _______________________________________________
> >> Psidev-pi-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> >
> > ---------------------------------------------------------------------
> ---------
> > Benefiting from Server Virtualization: Beyond Initial Workload
> > Consolidation -- Increasing the use of server virtualization is a top
> > priority.Virtualization can reduce costs, simplify management, and
> improve
> > application availability and disaster protection. Learn more about
> boosting
> > the value of server virtualization. http://p.sf.net/sfu/vmware-
> sfdev2dev
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
> -----------------------------------------------------------------------
> -------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and
> improve
> application availability and disaster protection. Learn more about
> boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-
> sfdev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev