psidev-ms-dev

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

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

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

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

[David O. <do...@eb...>]

Dear all,

This message is organized in three different sections to make things 
easier. The first section is about a couple of little problems that we 
think that must be fixed in the general structure of the c.v. The second 
section focuses on the issues discussed about the ionization sources 
described in the c.v. The third section describes the “several steps 
reorganization” we have in mind at the PRIDE team, starting with the 
software members (MS:1000531).
All this information has been checked using the 2.51.0 version of the 
PSI-MS controlled vocabulary (released April 7th).

Section 1: General issues:
1. The dependency import: 
http://obo.cvs.sourceforge.net/*checkout*/obo/obo/ontology/phenotype/unit.obo?revision=1.21 
produces the following “Load error” in the OboEdit tool: “2 unrecognized 
parent terms…”. Both errors are related to the term PATO:0000081 , not 
included in the unit ontology, but in the PATO ontology (a “unit” 
dependence). Removed the “?revision=1.21” fragment in the PSI-MS, the 
loading of the obo file using OBO-Edit is successful.
2. The term MS:1000857 (“run attribute”) has no parent. Maybe including 
it as a son of “spectrum generation information” (MS:1001458) will fix this.

Section 2: Ionization sources
In a short meeting with Juan Pablo Albar, Andreas Roempp and Kenny 
Helsens, we discussed several actions to be taken in the “source” 
(MS:1000458) descendants.
2.1 New terms to be added
2.1.1 Add LESA (Liquid Extraction Surface Analysis) as a new inlet
2.1.2 Add NanoMate as a new inlet
2.1.2 Add DESI (Desorption Electrospray Ionization) as a new source
2.1.3 Add DART (Direct Analysis in Real Time) as a new source
2.1.4 Add REIMS Rapid evaporative ionization mass spectrometry as a new 
source
2.1.5 Add SIMS Secondary ionization mass spectrometry as a new source
2.2 Frequently used terms
In this meeting, the possibility of “highlighting” some terms was also 
discussed. The list of different ionization sources includes more than 
thirty terms. Some of the terms are not frequently used by the community 
and some of them overlap or are synonyms. One example: the “Electro 
Spray Ionization” (MS:1000073) is a “soft ionization” (MS:1000403) and a 
particular kind of “atmospheric pressure ionization” (MS:1000240). The 
three terms are at the same hierarchical level under “ionization type”. 
To simplify this, four “highlighted” terms were suggested:
- “Electro Spray Ionization”
- “DESI (Desorption Electrospray Ionization)” (new term)
- “SIMS Secondary ionization mass spectrometry” (new term)
- “matrix-assisted laser desorption ionization”
Two ways of doing this where proposed: selecting the “usual/more used” 
terms or selecting the “unusual” terms. The use of “Xref”’s was 
suggested as the way to flag these terms.
2.3 Use of acronyms
The inclusion of highly used acronyms related to some terms was 
discussed, not only at the “ionization source”, but also in other places 
in the controlled vocabulary. To do this, the use of Synonyms was 
suggested. The two
2.1 At the ionization sources level an intense use of acronyms was 
suggested: ESI, MALDI, SELDI, API… almost all of the terms would have 
newly associated acronyms.
2.2 Out of the range of the “ionization sources”, we realised that the 
term “precursor activation” (MS:1000456) would need some kind of 
synonym: “Fragmentation technique”, “Fragmentation”… were candidates. We 
also found useful to include some acronyms to the different 
fragmentation techniques (CID, ETD, PQD…). The use of synonyms would do.


Section 3: Software
Some rearrangement of the software section was proposed by the PRIDE 
people (more concretely me…). The two main points discussed about this 
reorganization were:
3.1 Give some structure to the “software” section. What we had in mind was:
- Divide the “software” into two main categories: “software classified 
by functionality” and “software classified by manufacturer”.
- The “software classified by manufacturer” will take into account the 
different manufacturers. We were told about an incorrect description of 
the company name “Thermo Finnigan software”. At this point I must say 
that I’m quite confused with the “Thermo” several terms used. Maybe the 
more general term of “ThermoFisher Scientific” is the one to use…. I’m 
not sure.
- The “software classified by functionality” is divided in 6 categories:
. acquisition software (MS:1001455): Software used to acquire the data 
generated by a Mass Spectrometer. This includes RAW files generation.
. data processing software (MS:1001457): Software used to process the 
data generated by a Mass Spectrometer. This includes peaks lists 
generation, spectra annotation (charge assignment and precursor m/z 
characterization) and spectra processing (deisotoping, deconvolution, 
peak picking, smoothing, baseline reduction and related processes).
. conversion software (MS:1010002): Software used for the conversion 
from one given format to other. Libraries and API for accessing the 
information contained in spectra/identification files are included.
. analysis software (MS:1001456): Software used for the identification 
and/or qualitative characterization of proteins and peptides.
. quantitation software (MS:1001139): Software used for the quantitative 
characterization of proteins and peptides using Mass Spectrometry 
derived data.
. SRM software (MS:1000871): Software used to predict, select, or 
optimize transitions and/or analyse the results of selected reaction 
monitoring runs.
As maybe some of you have deduced, I’m not a native English 
speaker/writer: please, feel free to improve these definitions. But I 
think that this is the most important point at the software level: 
define exactly what means “processing software”, “adquisition software”. 
This done, we’ll be able to validate, using this c.v., if some user has 
described the software used for the acquisition (e.g. Xcalibur), the 
processing (maybe also Xcalibur) the search (e.g. Bioworks) and 
quantitation (maybe also Bioworks).
When all this definitions are clear and assumed by us, we’ll try to 
reorganize the different software: taking Xcalibur out of “analysis” is 
a clear example. Some of the definitions are not easy: in my opinion, 
the “processing software” is a complicate concept sometimes… but I’m 
sure that it can’t be described as it’s now (v 2.51.0): data processing 
software -> “Conversion software.”

We’ll be waiting for your comments, corrections, contributions…

Best,
David

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

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

Hi David, many thanks for taking this on and laying it out clearly. I
think all that you propose here is fine with me and I encourage you to go
ahead after waiting a little longer to see if there are other reactions. I
have only the following comments on your presentation below:

1) We had originally put in "?revision=1.21" to avoid the CV breaking for
users in case of changes in the unit ontology. However, it seems that the
unit ontology has not returned the favor, so unless we can get the unit
ontology to refer to a specific version of PATO et al., I guess I am
resigned to removing this as you have suggested.

2) run attribute probably belongs under MS:1000547. I don't know how it
got separated from its parent. I'm pretty sure it was there previously.

2.2) I suggest labeling rare terms as "uncommon". The would enable
functionality to allow certain terms that we know are rare to be hidden
from users unless they ask for uncommon terms. If we do the opposite,
there is a risk that a new term is not labeled "common" and may be hidden.
It seems less likely that a new term would be accidentally labeled
"uncommon".

2.8) Use of acronyms as synonyms is encouraged. Acronyms should not be
used as primary term names is our policy.

2.9) Policy is that terms are written and capitalized as they would appear
embedded in written text, i.e. NOT capitalized unless English rules
dictate capitalization due to a proper name such as Thermo or Dalton.

3) Software reclassification sounds good to me.

4) Prior to checking in your updates, please verify that any check-ins
since your fork are included.

Many thanks!
Eric




> -----Original Message-----
> From: David Ovelleiro [mailto:do...@eb...]
> Sent: Tuesday, April 19, 2011 7:47 AM
> To: Eric Deutsch
> Cc: psi...@li...; Mass spectrometry standard
> development; jp...@pr...; and...@an...emie.uni-
> giessen.de; ken...@ug...
> Subject: Re: [Psidev-pi-dev] One of these dissociation methods doesn't
> belong...
>
> Dear all,
>
> This message is organized in three different sections to make things
> easier. The first section is about a couple of little problems that we
> think that must be fixed in the general structure of the c.v. The
> second
> section focuses on the issues discussed about the ionization sources
> described in the c.v. The third section describes the "several steps
> reorganization" we have in mind at the PRIDE team, starting with the
> software members (MS:1000531).
> All this information has been checked using the 2.51.0 version of the
> PSI-MS controlled vocabulary (released April 7th).
>
> Section 1: General issues:
> 1. The dependency import:
> http://obo.cvs.sourceforge.net/*checkout*/obo/obo/ontology/phenotype/un
> it.obo?revision=1.21
> produces the following "Load error" in the OboEdit tool: "2
> unrecognized
> parent terms.". Both errors are related to the term PATO:0000081 , not
> included in the unit ontology, but in the PATO ontology (a "unit"
> dependence). Removed the "?revision=1.21" fragment in the PSI-MS, the
> loading of the obo file using OBO-Edit is successful.
> 2. The term MS:1000857 ("run attribute") has no parent. Maybe including
> it as a son of "spectrum generation information" (MS:1001458) will fix
> this.
>
> Section 2: Ionization sources
> In a short meeting with Juan Pablo Albar, Andreas Roempp and Kenny
> Helsens, we discussed several actions to be taken in the "source"
> (MS:1000458) descendants.
> 2.1 New terms to be added
> 2.1.1 Add LESA (Liquid Extraction Surface Analysis) as a new inlet
> 2.1.2 Add NanoMate as a new inlet
> 2.1.2 Add DESI (Desorption Electrospray Ionization) as a new source
> 2.1.3 Add DART (Direct Analysis in Real Time) as a new source
> 2.1.4 Add REIMS Rapid evaporative ionization mass spectrometry as a new
> source
> 2.1.5 Add SIMS Secondary ionization mass spectrometry as a new source
> 2.2 Frequently used terms
> In this meeting, the possibility of "highlighting" some terms was also
> discussed. The list of different ionization sources includes more than
> thirty terms. Some of the terms are not frequently used by the
> community
> and some of them overlap or are synonyms. One example: the "Electro
> Spray Ionization" (MS:1000073) is a "soft ionization" (MS:1000403) and
> a
> particular kind of "atmospheric pressure ionization" (MS:1000240). The
> three terms are at the same hierarchical level under "ionization type".
> To simplify this, four "highlighted" terms were suggested:
> - "Electro Spray Ionization"
> - "DESI (Desorption Electrospray Ionization)" (new term)
> - "SIMS Secondary ionization mass spectrometry" (new term)
> - "matrix-assisted laser desorption ionization"
> Two ways of doing this where proposed: selecting the "usual/more used"
> terms or selecting the "unusual" terms. The use of "Xref"'s was
> suggested as the way to flag these terms.
> 2.3 Use of acronyms
> The inclusion of highly used acronyms related to some terms was
> discussed, not only at the "ionization source", but also in other
> places
> in the controlled vocabulary. To do this, the use of Synonyms was
> suggested. The two
> 2.1 At the ionization sources level an intense use of acronyms was
> suggested: ESI, MALDI, SELDI, API. almost all of the terms would have
> newly associated acronyms.
> 2.2 Out of the range of the "ionization sources", we realised that the
> term "precursor activation" (MS:1000456) would need some kind of
> synonym: "Fragmentation technique", "Fragmentation". were candidates.
> We
> also found useful to include some acronyms to the different
> fragmentation techniques (CID, ETD, PQD.). The use of synonyms would
> do.
>
>
> Section 3: Software
> Some rearrangement of the software section was proposed by the PRIDE
> people (more concretely me.). The two main points discussed about this
> reorganization were:
> 3.1 Give some structure to the "software" section. What we had in mind
> was:
> - Divide the "software" into two main categories: "software classified
> by functionality" and "software classified by manufacturer".
> - The "software classified by manufacturer" will take into account the
> different manufacturers. We were told about an incorrect description of
> the company name "Thermo Finnigan software". At this point I must say
> that I'm quite confused with the "Thermo" several terms used. Maybe the
> more general term of "ThermoFisher Scientific" is the one to use.. I'm
> not sure.
> - The "software classified by functionality" is divided in 6
> categories:
> . acquisition software (MS:1001455): Software used to acquire the data
> generated by a Mass Spectrometer. This includes RAW files generation.
> . data processing software (MS:1001457): Software used to process the
> data generated by a Mass Spectrometer. This includes peaks lists
> generation, spectra annotation (charge assignment and precursor m/z
> characterization) and spectra processing (deisotoping, deconvolution,
> peak picking, smoothing, baseline reduction and related processes).
> . conversion software (MS:1010002): Software used for the conversion
> from one given format to other. Libraries and API for accessing the
> information contained in spectra/identification files are included.
> . analysis software (MS:1001456): Software used for the identification
> and/or qualitative characterization of proteins and peptides.
> . quantitation software (MS:1001139): Software used for the
> quantitative
> characterization of proteins and peptides using Mass Spectrometry
> derived data.
> . SRM software (MS:1000871): Software used to predict, select, or
> optimize transitions and/or analyse the results of selected reaction
> monitoring runs.
> As maybe some of you have deduced, I'm not a native English
> speaker/writer: please, feel free to improve these definitions. But I
> think that this is the most important point at the software level:
> define exactly what means "processing software", "adquisition
> software".
> This done, we'll be able to validate, using this c.v., if some user has
> described the software used for the acquisition (e.g. Xcalibur), the
> processing (maybe also Xcalibur) the search (e.g. Bioworks) and
> quantitation (maybe also Bioworks).
> When all this definitions are clear and assumed by us, we'll try to
> reorganize the different software: taking Xcalibur out of "analysis" is
> a clear example. Some of the definitions are not easy: in my opinion,
> the "processing software" is a complicate concept sometimes. but I'm
> sure that it can't be described as it's now (v 2.51.0): data processing
> software -> "Conversion software."
>
> We'll be waiting for your comments, corrections, contributions.
>
> Best,
> David

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

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

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

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

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

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