psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

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

It would seem to me that often the inlet is a component of a source, and
if an attribute is clearly an attribute of an inlet, then it would be tidy
to classify it as such. However, from a practical use in mzML, it doesn't
matter. So I would lean to the side of keeping them separate where it
makes sense if David is willing to organize this. However, I don't feel
very strongly either way.

David, I am fine with your proposal if that's the way you'd like to
organize it.

We should remember that this will likely require a change to the mzML
mapping file.

Thanks,
Eric


> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@gm...]
> Sent: Tuesday, May 31, 2011 12:25 PM
> To: psi...@li...
> Subject: Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 !
> source
>
> Is there a good reason to separate "inlet attributes" from "source
> attributes?" After all, they are
> going under the same XML element (source).
>
> -Matt
>
>
> On 5/31/2011 12:19 PM, David Ovelleiro wrote:
> > Dear Steffen and Eric,
> >
> > At this moment I'm working in the "source" members.
> > The problem here, as discussed in the PSI meeting in Heidelberg, is
> that
> > the distinction between a source and and inlet is not very clear in
> some
> > cases.
> > Let's have one example:
> > MS:1000055: continuous flow fast atom bombardment (defined as an
> inlet)
> > ->  "Fast atom bombardment ionization in which the analyte in
> solution is
> > entrained in a flowing liquid matrix."
> > MS:1000074: fast atom bombardment ionization (defined as a ionization
> > type) ->  "The ionization of any species by the interaction of a
> focused
> > beam of neutral atoms having a translational energy of several
> thousand
> > eV with a sample that is typically dissolved in a solvent matrix. See
> > also secondary ionization."
> >
> > We found this kind of ambiguities. The problem is that depending on
> the
> > instrument design, in some cases, inlet and source are the same, or
> > share components.
> >
> > Taking this into account, I'd propose an slightly different approach:
> >
> > [Term]
> > id: MS:1000XXX
> > name: inlet attribute
> > def: "Property of an inlet device that needs a value." [PSI:MS]
> > is_a: MS:1000458 ! source
> >
> >    Here, the inlet attribute is son to source, at the same level than
> > "source attribute". Doing this, in the cases that the inlet is
> something
> > completely different from the source, using an "inlet attribute"
> outside
> > the "source attribute" seems more correct to me....
> >
> > What do you think?
> >
> > David
> >
> >
> >
> >
> >
> > On 28/05/2011 13:09, Neumann, Steffen wrote:
> >> Hi,
> >>
> >> yes, that's fine with me.
> >>
> >> Yours,
> >> Steffen
> >>
> >> ________________________________________
> >> From: Eric Deutsch [ede...@sy...]
> >> Sent: 28 May 2011 08:05
> >> To: Mass spectrometry standard development
> >> Cc: Eric Deutsch
> >> Subject: Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 !
> source
> >>
> >> Hi Steffen, this is a pretty messy situation. Maybe David would like
> to
> >> take this on sometime. For now, I think what you propose is fine,
> except I
> >> don't think the second relationship is useful, so just:
> >>
> >> [Term]
> >> id: MS:1000XXX
> >> name: inlet attribute
> >> def: "Property of an inlet device that needs a value." [PSI:MS]
> >> is_a: MS:1000482 ! source attribute
> >>
> >> Regards,
> >> Eric
> >>
> >>
> >> --------------------------------------------------------------------
> ----------
> >> vRanger cuts backup time in half-while increasing security.
> >> With the market-leading solution for virtual backup and recovery,
> >> you get blazing-fast, flexible, and affordable data protection.
> >> Download your free trial now.
> >> http://p.sf.net/sfu/quest-d2dcopy1
> >> _______________________________________________
> >> Psidev-ms-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
> >
>
> -----------------------------------------------------------------------
> -------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] [Psidev-pi-dev] PSI controlled vocabularies maintenance

[Trish W. <plw...@gm...>]

Hi all,

I'm the Outreach Coordinator with the National Center for Biomedical Ontology (NCBO) and have worked on psi-ms in the past. At NCBO we have a system for proposing new terms and adding comments for the ontology maintainers to review and discuss with the submitter along with other features for ontology curation. I'd love to demo the system to your group. Does this sound of interest? 

Best regards,
Trish 

Sent from my iPhone

On May 31, 2011, at 3:21 PM, Steffen Neumann <sne...@ip...> wrote:

> Hi,
> 
> On Tue, 2011-05-31 at 17:04 +0100, David Ovelleiro wrote: 
>> Maybe it makes not much sense for people who is registered in the 
>> mailing lists to use it, and it also seems that is not a prodigy of 
>> performance....
> 
> So the form for CV terms doesn't really work, 
> 
> On Tue, 2011-05-31 at 12:55 +0100, David Ovelleiro wrote:
> ...
>> The proposals/changes/.... will be included also in the googleDoc
>> located there (starting in some hours):
>> https://spreadsheets.google.com/pub?hl=en_US&hl=en_US&key=0Av19CsTVDoOQdENWSmJDS3ZfN2tPdEhaaldzcWVNY3c&output=html
> 
> but I think the spreadsheet is hardly maintainable
> in the long run. What about the approach to use a (bug) tracker, 
> as shown (mostly by the psi-pi folks) for several of the mz* formats ?
> 
> There could be types for reparenting, definition editing, adding,
> deleting, ... Updates would go the the (which ?) list etc.
> Commits could include which issue was fixed etc.
> 
> Yours,
> Steffen
> 
> -- 
> IPB Halle                    AG Massenspektrometrie & Bioinformatik
> Dr. Steffen Neumann          http://www.IPB-Halle.DE
> Weinberg 3                   http://msbi.bic-gh.de
> 06120 Halle                  Tel. +49 (0) 345 5582 - 1470
>                                  +49 (0) 345 5582 - 0
> sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409
> 
> 
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger. 
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today. 
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

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

Is there a good reason to separate "inlet attributes" from "source attributes?" After all, they are 
going under the same XML element (source).

-Matt


On 5/31/2011 12:19 PM, David Ovelleiro wrote:
> Dear Steffen and Eric,
>
> At this moment I'm working in the "source" members.
> The problem here, as discussed in the PSI meeting in Heidelberg, is that
> the distinction between a source and and inlet is not very clear in some
> cases.
> Let's have one example:
> MS:1000055: continuous flow fast atom bombardment (defined as an inlet)
> ->  "Fast atom bombardment ionization in which the analyte in solution is
> entrained in a flowing liquid matrix."
> MS:1000074: fast atom bombardment ionization (defined as a ionization
> type) ->  "The ionization of any species by the interaction of a focused
> beam of neutral atoms having a translational energy of several thousand
> eV with a sample that is typically dissolved in a solvent matrix. See
> also secondary ionization."
>
> We found this kind of ambiguities. The problem is that depending on the
> instrument design, in some cases, inlet and source are the same, or
> share components.
>
> Taking this into account, I'd propose an slightly different approach:
>
> [Term]
> id: MS:1000XXX
> name: inlet attribute
> def: "Property of an inlet device that needs a value." [PSI:MS]
> is_a: MS:1000458 ! source
>
>    Here, the inlet attribute is son to source, at the same level than
> "source attribute". Doing this, in the cases that the inlet is something
> completely different from the source, using an "inlet attribute" outside
> the "source attribute" seems more correct to me....
>
> What do you think?
>
> David
>
>
>
>
>
> On 28/05/2011 13:09, Neumann, Steffen wrote:
>> Hi,
>>
>> yes, that's fine with me.
>>
>> Yours,
>> Steffen
>>
>> ________________________________________
>> From: Eric Deutsch [ede...@sy...]
>> Sent: 28 May 2011 08:05
>> To: Mass spectrometry standard development
>> Cc: Eric Deutsch
>> Subject: Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source
>>
>> Hi Steffen, this is a pretty messy situation. Maybe David would like to
>> take this on sometime. For now, I think what you propose is fine, except I
>> don't think the second relationship is useful, so just:
>>
>> [Term]
>> id: MS:1000XXX
>> name: inlet attribute
>> def: "Property of an inlet device that needs a value." [PSI:MS]
>> is_a: MS:1000482 ! source attribute
>>
>> Regards,
>> Eric
>>
>>
>> ------------------------------------------------------------------------------
>> vRanger cuts backup time in half-while increasing security.
>> With the market-leading solution for virtual backup and recovery,
>> you get blazing-fast, flexible, and affordable data protection.
>> Download your free trial now.
>> http://p.sf.net/sfu/quest-d2dcopy1
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>

Re: [Psidev-ms-dev] PSI controlled vocabularies maintenance

[Steffen N. <sne...@ip...>]

Hi,

On Tue, 2011-05-31 at 17:04 +0100, David Ovelleiro wrote: 
> Maybe it makes not much sense for people who is registered in the 
> mailing lists to use it, and it also seems that is not a prodigy of 
> performance....

So the form for CV terms doesn't really work, 

On Tue, 2011-05-31 at 12:55 +0100, David Ovelleiro wrote:
...
> The proposals/changes/.... will be included also in the googleDoc
> located there (starting in some hours):
> https://spreadsheets.google.com/pub?hl=en_US&hl=en_US&key=0Av19CsTVDoOQdENWSmJDS3ZfN2tPdEhaaldzcWVNY3c&output=html

but I think the spreadsheet is hardly maintainable
in the long run. What about the approach to use a (bug) tracker, 
as shown (mostly by the psi-pi folks) for several of the mz* formats ?

There could be types for reparenting, definition editing, adding,
deleting, ... Updates would go the the (which ?) list etc.
Commits could include which issue was fixed etc.

Yours,
Steffen

-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

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

Dear Steffen and Eric,

At this moment I'm working in the "source" members.
The problem here, as discussed in the PSI meeting in Heidelberg, is that 
the distinction between a source and and inlet is not very clear in some 
cases.
Let's have one example:
MS:1000055: continuous flow fast atom bombardment (defined as an inlet) 
-> "Fast atom bombardment ionization in which the analyte in solution is 
entrained in a flowing liquid matrix."
MS:1000074: fast atom bombardment ionization (defined as a ionization 
type) -> "The ionization of any species by the interaction of a focused 
beam of neutral atoms having a translational energy of several thousand 
eV with a sample that is typically dissolved in a solvent matrix. See 
also secondary ionization."

We found this kind of ambiguities. The problem is that depending on the 
instrument design, in some cases, inlet and source are the same, or 
share components.

Taking this into account, I'd propose an slightly different approach:

[Term]
id: MS:1000XXX
name: inlet attribute
def: "Property of an inlet device that needs a value." [PSI:MS]
is_a: MS:1000458 ! source

  Here, the inlet attribute is son to source, at the same level than  
"source attribute". Doing this, in the cases that the inlet is something 
completely different from the source, using an "inlet attribute" outside 
the "source attribute" seems more correct to me....

What do you think?

David





On 28/05/2011 13:09, Neumann, Steffen wrote:
> Hi,
>
> yes, that's fine with me.
>
> Yours,
> Steffen
>
> ________________________________________
> From: Eric Deutsch [ede...@sy...]
> Sent: 28 May 2011 08:05
> To: Mass spectrometry standard development
> Cc: Eric Deutsch
> Subject: Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source
>
> Hi Steffen, this is a pretty messy situation. Maybe David would like to
> take this on sometime. For now, I think what you propose is fine, except I
> don't think the second relationship is useful, so just:
>
> [Term]
> id: MS:1000XXX
> name: inlet attribute
> def: "Property of an inlet device that needs a value." [PSI:MS]
> is_a: MS:1000482 ! source attribute
>
> Regards,
> Eric
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> 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

Re: [Psidev-ms-dev] PSI controlled vocabularies maintenance

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

Hi all,

I've updated the controlled vocabulary:

Revision *1.159 -> *
Broken dependency import: "?revision=1.21" removed from unit.obo dependency
Two definitions changed: MS:1000876 and MS:1000877
New parent to MS:1000857 (is_a: MS:1000547 ! object attribute)

Revision*1.160 ->*
Corrected date and version
(This last is because I forgot to change the date and version in all places... there's two lines with the version and two for the date.... sorry about that)


The committed version takes into account some very clear changes that 
where accepted in the mail list. I'll publish the more recent proposals 
progressively in the mail list (psidev-pi-dev and psidev-ms-dev).
If you are waiting for some change and, in the next days/weeks is not 
taken into account, please, publish it again. I'll do my best through 
the proposals, but is not easy to find some of them...

The proposals/changes/.... will be included also in the googleDoc 
located there (starting in some hours):
https://spreadsheets.google.com/pub?hl=en_US&hl=en_US&key=0Av19CsTVDoOQdENWSmJDS3ZfN2tPdEhaaldzcWVNY3c&output=html

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

Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

[Neumann, S. <sne...@ip...>]

Hi, 

yes, that's fine with me.

Yours,
Steffen

________________________________________
From: Eric Deutsch [ede...@sy...]
Sent: 28 May 2011 08:05
To: Mass spectrometry standard development
Cc: Eric Deutsch
Subject: Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

Hi Steffen, this is a pretty messy situation. Maybe David would like to
take this on sometime. For now, I think what you propose is fine, except I
don't think the second relationship is useful, so just:

[Term]
id: MS:1000XXX
name: inlet attribute
def: "Property of an inlet device that needs a value." [PSI:MS]
is_a: MS:1000482 ! source attribute

Regards,
Eric

Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

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

Hi Steffen, this is a pretty messy situation. Maybe David would like to
take this on sometime. For now, I think what you propose is fine, except I
don't think the second relationship is useful, so just:

[Term]
id: MS:1000XXX
name: inlet attribute
def: "Property of an inlet device that needs a value." [PSI:MS]
is_a: MS:1000482 ! source attribute

Regards,
Eric


-----Original Message-----
From: Steffen Neumann [mailto:sne...@ip...]
Sent: Friday, May 27, 2011 12:37 AM
To: psi...@li...
Subject: [Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

Hi,

while working on some GC-MS terms, I found that we have have

MS:1000458 / source / relationship: part_of MS:1000463 ! instrument
+ MS:1000482 / source attribute / part_of MS:1000458 ! source
+ MS:1000007 / inlet type / part_of MS:1000458 ! source

and my question is, where would an "inlet attribute"
like inlet temperature go ? Will it be an "MS:1000482 / source attribute"
or do we want a new sub-category "inlet attribute" ? Question to
the Ontology experts: are the relationship / is_a suggestions below
reasonable ?

[Term]
id: MS:1000XXX
name: inlet attribute
def: "Property of an inlet device that need a value." [PSI:MS]
relationship: part_of MS:1000007 ! inlet type
is_a: MS:1000482 ! source attribute

Yours,
Steffen

-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409



--------------------------------------------------------------------------
----
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML for GCxGC/MS ?

[Steffen N. <sne...@ip...>]

Hi,

On Sun, 2011-03-20 at 19:00 +0100, Oliver Kohlbacher wrote:
...
> Conceptually, I would consider those just a single {L|G}C-MS run.
> Information on how the 1D RT should be mapped to 2D coordinates
> should be provided in addition to that. We could basically 
> store a relation assigning each scan two or more retention 
> coordinates (retention times or an index for the primary separation,
> which would also make it comparable to offline fractionation).

I now got my hands on some example data from Nils Hoffmann 
http://www.cebitec.uni-bielefeld.de/~hoffmann/files/GCxGC-MS-LECO.tar.bz2
which I converted with the OpenMS-1.8 FileConverter 
http://msbi.ipb-halle.de/~sneumann/GCxGC_leco.mzML.bz2

1) OpenMS is already able to extract some information from the netCDF 
   where we lack the proper cvTerms. I would suggest 
   (also see separate mail on "inlet attribute")

[Term]
id: MS:1000XXX
name: inlet temperature 
def: "Inlet temperature." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
is_a: MS:1000XXX ! inlet attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius

[Term] 
id: MS:1000XXX
name: source temperature 
def: "Source temperature ... ." [PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000482 ! source attribute
relationship: has_units UO:0000012 ! kelvin
relationship: has_units UO:0000027 ! degree celsius

2a) For GCxGC, we need to specify the 2D coordinate / time system. 
   I would minimally suggest a new "run attribute":

[Term]
id: MS:1000XXX
name: modulation time
def: "The duration of a complete cycle of modulation in a comprehensive two-dimensional separation system, equals the length of a second
dimension chromatogram, i.e., the time between two successive injections
into the second column." [not PSI:MS ?]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1000857 ! run attribute
relationship: has_units UO:0000010 ! second 
relationship: has_units UO:0000031 ! minute

   BTW: how do we "cite" the definition ? I it took from 
   http://chromatographyonline.findanalytichem.com/lcgc/Column:+Coupling+Matters/Nomenclature-and-Conventions-in-Comprehensive-Mult/ArticleStandard/Article/detail/58429
   There are tons more terms in this paper.

2b) Alternatively/additionally, we'd need to be able to add 
    several dimensions to the scan attribute "elution time". 

     MS:1000503 ! scan attribute
     + MS:1000826 ! elution time 
       + MS:1000XXX ! first column elution time (def: Retention time of a
                                   peak in the first dimension of a
                                   comprehensive two-dimensional system)
       + MS:1000XXX ! second column elution time (def: ... second ...)
       + MS:1000XXX ! third column elution time 
       ...
       + MS:1000XXX ! seventh column elution time (you get the idea ...)

     Does anyone have a better idea ? Please ? Or is this reasonable 
     with current (and anticipated) seperation techniques ?
     The paper above also lists GCϫGCϫGC, LC–GCϫGC or ...
     I don't like the ordering in the name, but anything else would 
     rather be in the scope of sepML, and we still need to reference 
     several elution times.

Usually, the 2a) modulation time is the "run attribute" that is programmed 
into the GCxGC-MS system when you run your samples. The actual elution
times for each scan could be 2b) adjusted / corrected if there are any 
shifts/deviations (for whatever reason) within the run.

Thoughts ?

Yours,
Steffen

Just for reference, here is the netCDF metadata from above file(s):

netcdf header information GCxGC {
dimensions:
...
	point_number = UNLIMITED ; // (43969157 currently)
	scan_number = 100001 ;
variables:
...
// global attributes:
		:netcdf_file_date_time_stamp = "20090325161325+0100" ;
		:experiment_date_time_stamp = "20090306200015+0100" ;
		:experiment_type = "Centroided Mass Spectrum" ;
		:test_separation_type = "Gas-Liquid Chromatography" ;
		:test_ms_inlet = "Capillary Direct" ;
		:test_ms_inlet_temperature = 275.f ;
		:test_ionization_mode = "Electron Impact" ;
		:test_ionization_polarity = "Positive Polarity" ;
		:test_source_temperature = 200.f ;
		:test_accelerating_potential = -600.f ;
		:test_detector_type = "Electron Multiplier" ;
		:test_detector_potential = -1600.f ;
		:test_resolution_type = "Constant Resolution" ;
		:test_scan_function = "Mass Scan" ;
		:test_scan_direction = "Up" ;
		:test_scan_law = "Linear" ;
		:test_scan_time = 0.0002f ;
...
}


-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

[Psidev-ms-dev] ontology hierarchy below MS:1000458 ! source

[Steffen N. <sne...@ip...>]

Hi,

while working on some GC-MS terms, I found that we have have 

MS:1000458 / source / relationship: part_of MS:1000463 ! instrument
+ MS:1000482 / source attribute / part_of MS:1000458 ! source
+ MS:1000007 / inlet type / part_of MS:1000458 ! source

and my question is, where would an "inlet attribute" 
like inlet temperature go ? Will it be an "MS:1000482 / source attribute"
or do we want a new sub-category "inlet attribute" ? Question to 
the Ontology experts: are the relationship / is_a suggestions below 
reasonable ?

[Term]
id: MS:1000XXX
name: inlet attribute
def: "Property of an inlet device that need a value." [PSI:MS]
relationship: part_of MS:1000007 ! inlet type
is_a: MS:1000482 ! source attribute

Yours,
Steffen

-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

Re: [Psidev-ms-dev] Python mzML reader?

[Gerhard M. <Ger...@ru...>]

Hi Eric,

I never used this mzAPI, but maybe the following link is interesting for 
you:

http://nullege.com/codes/search/mzAPI

Gerhard


Am 25.05.2011 16:56, schrieb Eric Deutsch:
>
> Hi, does anyone know of an mzML reader in Python?
>
> Thanks,
>
> Eric
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
>
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
BioInformatik
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.042
Universitätsstrasse 150
D-44801 Bochum

Phone:	+49(0)234/32-29836
Fax:	+49(0)234/32-14554
Email:	Ger...@ru...
Web:	http://www.medizinisches-proteom-center.de

Re: [Psidev-ms-dev] Python mzML reader?

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

Thanks for the pointers, Matt. Has anyone done just this already?

Thanks,
Eric


-----Original Message-----
From: Matthew Chambers [mailto:mat...@gm...]
Sent: Wednesday, May 25, 2011 8:04 AM
To: psi...@li...
Subject: Re: [Psidev-ms-dev] Python mzML reader?

The pwiz CLI bindings can be accessed from IronPython (on Windows). It'd
probably be pretty easy for
Brian's RAMPAdapter SWIG bindings to be built for Python too.

-Matt


On 5/25/2011 9:56 AM, Eric Deutsch wrote:
> Hi, does anyone know of an mzML reader in Python?
>
> Thanks,
>
> Eric

--------------------------------------------------------------------------
----
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Python mzML reader?

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

The pwiz CLI bindings can be accessed from IronPython (on Windows). It'd probably be pretty easy for 
Brian's RAMPAdapter SWIG bindings to be built for Python too.

-Matt


On 5/25/2011 9:56 AM, Eric Deutsch wrote:
> Hi, does anyone know of an mzML reader in Python?
>
> Thanks,
>
> Eric

[Psidev-ms-dev] Python mzML reader?

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

Hi, does anyone know of an mzML reader in Python?



Thanks,

Eric

Re: [Psidev-ms-dev] [Psidev-pi-dev] PSI controlled vocabularies maintenance

[Gerhard M. <Ger...@ru...>]

Hallo David,
hi all,

1. In contrast to Matt and in accord with the PRIDE team I think one 
should have all the search engine specific parameters in the ontology.

In my opinion to have a general "Common search engine input parameter" 
category as proposed by you and Eric, which contains the common CV terms
occurring in several distinct search engines makes sense, because it 
reduces redundancy by otherwise duplicate terms and one needs to add
a new CV term to the "engine-specific search input parameter" list only 
if a term is really specific for a search engine and does not occur in 
other search engines.
On the other side such a general "Common search engine input parameter" 
category can only be a current snapshot because we cannot forsee
which input parameters will be introduced by the search engines in 
future, but i see no way how to overcome this problem.

If there is a problem with the workflow-oriented CV terms of ProteomeDiscoverer (see our mail from April 21st, 18:46)
concerning spectral processing, data transformation, filtering or other operations (e.g. ProteomeDiscoverer:Spectrum Files: ...,
ProteomeDiscoverer:Non-Fragment Filter: ..., ProteomeDiscoverer:Xtract: ..., ProteomeDiscoverer:Spectrum Grouper: ...),
then you can delete them for now and we (I and Martin) will incorporate them later in the spectra generation branch of the CV.

2. Sorry, I think we forgot to update the version number and release 
date inside the .obo file - it's safe
to regard the last version from 21st April as the actual one.

3+4. That's fine.

Best regards,
Gerhard


Am 23.05.2011 19:08, schrieb David Ovelleiro:
> Dear all,
>
> As promised in Heidelberg, we're going to start maintaining the addition
> of new terms to the PSI controlled vocabulary.
>
> 1. At this point, and before starting with a new version, or add/change
> anything, I'd like to have clear something: What are we going to do with
> MS:1001302 (“search engine specific input parameter”). This single term
> has 216 direct sons (or descendants, or whatever). More than 70% of them
> are “ProteomeDiscoverer:”. In my opinion, a general “Search engine
> input” makes sense (input parameters used by many search engines, like
> “Precursor tolerance”,...). Not this huge (more than huge, huger...)
> list. But I'd like to hear more opinions about this.
> 2. The last 3 revisions of psi-ms.obo have the same version (2.51.0) and
> release date (2011-04-07). The three have been published between 7th and
> 21st April.
> 3. Today, I've contacted again (second time) the people from UNIT
> ontology. The repository of PATO had changed (and not reflected in the
> UNIT ontology), and made impossible to open the PSI-MS ontology using
> OBO-Edit. Now is fixed.
> 4. When the point 1 is clear and fixed, I'll start to compile the
> changes, publish them in the mail list and, when accepted by everybody,
> I'll generate a new release of the CV. I've generated a non-editable
> list of the changes I'm working with, with three possible estates:
> “Published in mail list”, “Accepted in mail list”, “Rejected in mail
> list” and “Done”. There's a link in the 10th column directing to the
> thread that suggested the CV param. The link to the list (it will be
> bigger in the next days) is (I know... too long):
> https://spreadsheets.google.com/pub?hl=en_US&hl=en_US&key=0Av19CsTVDoOQdENWSmJDS3ZfN2tPdEhaaldzcWVNY3c&output=html
>
> I'd like to have some answer to the first point before starting with a
> new release: is everything OK in the present version?
> And I'd also appreciate that the new CV proposals (at least those I'm
> going to take care) would be sent to the
> psi...@li...  and
> psi...@li...  lists... why both??? We could use
> only one list (that's the perfect solution for me), but using
> alternatively one or the other is a pain when you try to compile a list
> of new terms.
>
> Best,
>
-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
BioInformatik
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.042
Universitätsstrasse 150
D-44801 Bochum

Phone:	+49(0)234/32-29836
Fax:	+49(0)234/32-14554
Email:	Ger...@ru...
Web:	http://www.medizinisches-proteom-center.de

Re: [Psidev-ms-dev] PSI controlled vocabularies maintenance

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

Thank you, David and Matt, my own comments below..

1) Maybe it would be better to add a little more structure to the
hierarchy, something like:
search engine input parameter
  +- common search engine input parameter
    +- (terms shared by more than one engine)
  +- engine-specific search engine input parameter
    +- ProteomeDiscoverer input parameter
       +- (terms specific to PD)
    +- Mascot input parameter
This may not solve the sheet number of terms, but it will avoid a huge
flat list to some extent.

2) Clear the version number should be incremented on change and it is a
careless error that it is has not. We should all make sure that we
increment the version number when changing.

3) Good, thanks. This sort of thing could be avoided if we referred to a
specific version of UNIT *and* we got UNIT to refer to a specific version
of PATO.

4) Both lists is fine with me. There is the vocab list, but membership is
pretty small. It does make sense to do it there, but we would need to
expand the readership to relevant parties first. i.e. add anyone who is
likely to care of about CV terms.

Thanks,
Eric





> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@gm...]
> Sent: Monday, May 23, 2011 2:37 PM
> To: psi...@li...; psidev-pi-
> de...@li...
> Subject: Re: [Psidev-ms-dev] PSI controlled vocabularies maintenance
>
> 1. I agree there are a lot of ProteomeDiscoverer terms that never
> should have been added. We already
> discussed it on a conference call. I don't really understand what
> you're saying after "In my
> opinion" though. The point of the "search engine specific input
> parameter" hierarchy is to support
> parameters that are unique to a subset of search engines.
> 3. Glad to hear it.
> 4. I assume you'll expand the "source descendents" row into one row for
> each new term? It'll be good
> to review it that way.
>
> We have a psidev-ms-vocab list which is intended for discussing the CV
> - especially since MS and PI
> CVs merged. This would be easy to enforce on a forum (moderators simply
> move CV discussions to the
> appropriate subforum), but very easy to get mixed up between 3 mailing
> lists.
>
> Thanks,
> -Matt
>
>
> On 5/23/2011 12:08 PM, David Ovelleiro wrote:
> > Dear all,
> >
> > As promised in Heidelberg, we're going to start maintaining the
> addition
> > of new terms to the PSI controlled vocabulary.
> >
> > 1. At this point, and before starting with a new version, or
> add/change
> > anything, I'd like to have clear something: What are we going to do
> with
> > MS:1001302 ("search engine specific input parameter"). This single
> term
> > has 216 direct sons (or descendants, or whatever). More than 70% of
> them
> > are "ProteomeDiscoverer:". In my opinion, a general "Search engine
> > input" makes sense (input parameters used by many search engines,
> like
> > "Precursor tolerance",...). Not this huge (more than huge, huger...)
> > list. But I'd like to hear more opinions about this.
> > 2. The last 3 revisions of psi-ms.obo have the same version (2.51.0)
> and
> > release date (2011-04-07). The three have been published between 7th
> and
> > 21st April.
> > 3. Today, I've contacted again (second time) the people from UNIT
> > ontology. The repository of PATO had changed (and not reflected in
> the
> > UNIT ontology), and made impossible to open the PSI-MS ontology using
> > OBO-Edit. Now is fixed.
> > 4. When the point 1 is clear and fixed, I'll start to compile the
> > changes, publish them in the mail list and, when accepted by
> everybody,
> > I'll generate a new release of the CV. I've generated a non-editable
> > list of the changes I'm working with, with three possible estates:
> > "Published in mail list", "Accepted in mail list", "Rejected in mail
> > list" and "Done". There's a link in the 10th column directing to the
> > thread that suggested the CV param. The link to the list (it will be
> > bigger in the next days) is (I know... too long):
> >
> https://spreadsheets.google.com/pub?hl=en_US&hl=en_US&key=0Av19CsTVDoOQ
> dENWSmJDS3ZfN2tPdEhaaldzcWVNY3c&output=html
> >
> > I'd like to have some answer to the first point before starting with
> a
> > new release: is everything OK in the present version?
> > And I'd also appreciate that the new CV proposals (at least those I'm
> > going to take care) would be sent to the
> > psi...@li... and
> > psi...@li... lists... why both??? We could use
> > only one list (that's the perfect solution for me), but using
> > alternatively one or the other is a pain when you try to compile a
> list
> > of new terms.
> >
> > Best,
> >
>
> -----------------------------------------------------------------------
> -------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI controlled vocabularies maintenance

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

1. I agree there are a lot of ProteomeDiscoverer terms that never should have been added. We already 
discussed it on a conference call. I don't really understand what you're saying after "In my 
opinion" though. The point of the "search engine specific input parameter" hierarchy is to support 
parameters that are unique to a subset of search engines.
3. Glad to hear it.
4. I assume you'll expand the "source descendents" row into one row for each new term? It'll be good 
to review it that way.

We have a psidev-ms-vocab list which is intended for discussing the CV - especially since MS and PI 
CVs merged. This would be easy to enforce on a forum (moderators simply move CV discussions to the 
appropriate subforum), but very easy to get mixed up between 3 mailing lists.

Thanks,
-Matt


On 5/23/2011 12:08 PM, David Ovelleiro wrote:
> Dear all,
>
> As promised in Heidelberg, we're going to start maintaining the addition
> of new terms to the PSI controlled vocabulary.
>
> 1. At this point, and before starting with a new version, or add/change
> anything, I'd like to have clear something: What are we going to do with
> MS:1001302 (“search engine specific input parameter”). This single term
> has 216 direct sons (or descendants, or whatever). More than 70% of them
> are “ProteomeDiscoverer:”. In my opinion, a general “Search engine
> input” makes sense (input parameters used by many search engines, like
> “Precursor tolerance”,...). Not this huge (more than huge, huger...)
> list. But I'd like to hear more opinions about this.
> 2. The last 3 revisions of psi-ms.obo have the same version (2.51.0) and
> release date (2011-04-07). The three have been published between 7th and
> 21st April.
> 3. Today, I've contacted again (second time) the people from UNIT
> ontology. The repository of PATO had changed (and not reflected in the
> UNIT ontology), and made impossible to open the PSI-MS ontology using
> OBO-Edit. Now is fixed.
> 4. When the point 1 is clear and fixed, I'll start to compile the
> changes, publish them in the mail list and, when accepted by everybody,
> I'll generate a new release of the CV. I've generated a non-editable
> list of the changes I'm working with, with three possible estates:
> “Published in mail list”, “Accepted in mail list”, “Rejected in mail
> list” and “Done”. There's a link in the 10th column directing to the
> thread that suggested the CV param. The link to the list (it will be
> bigger in the next days) is (I know... too long):
> https://spreadsheets.google.com/pub?hl=en_US&hl=en_US&key=0Av19CsTVDoOQdENWSmJDS3ZfN2tPdEhaaldzcWVNY3c&output=html
>
> I'd like to have some answer to the first point before starting with a
> new release: is everything OK in the present version?
> And I'd also appreciate that the new CV proposals (at least those I'm
> going to take care) would be sent to the
> psi...@li... and
> psi...@li... lists... why both??? We could use
> only one list (that's the perfect solution for me), but using
> alternatively one or the other is a pain when you try to compile a list
> of new terms.
>
> Best,
>

[Psidev-ms-dev] PSI controlled vocabularies maintenance

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

Dear all,

As promised in Heidelberg, we're going to start maintaining the addition 
of new terms to the PSI controlled vocabulary.

1. At this point, and before starting with a new version, or add/change 
anything, I'd like to have clear something: What are we going to do with 
MS:1001302 (“search engine specific input parameter”). This single term 
has 216 direct sons (or descendants, or whatever). More than 70% of them 
are “ProteomeDiscoverer:”. In my opinion, a general “Search engine 
input” makes sense (input parameters used by many search engines, like 
“Precursor tolerance”,...). Not this huge (more than huge, huger...) 
list. But I'd like to hear more opinions about this.
2. The last 3 revisions of psi-ms.obo have the same version (2.51.0) and 
release date (2011-04-07). The three have been published between 7th and 
21st April.
3. Today, I've contacted again (second time) the people from UNIT 
ontology. The repository of PATO had changed (and not reflected in the 
UNIT ontology), and made impossible to open the PSI-MS ontology using 
OBO-Edit. Now is fixed.
4. When the point 1 is clear and fixed, I'll start to compile the 
changes, publish them in the mail list and, when accepted by everybody, 
I'll generate a new release of the CV. I've generated a non-editable 
list of the changes I'm working with, with three possible estates: 
“Published in mail list”, “Accepted in mail list”, “Rejected in mail 
list” and “Done”. There's a link in the 10th column directing to the 
thread that suggested the CV param. The link to the list (it will be 
bigger in the next days) is (I know... too long):
https://spreadsheets.google.com/pub?hl=en_US&hl=en_US&key=0Av19CsTVDoOQdENWSmJDS3ZfN2tPdEhaaldzcWVNY3c&output=html

I'd like to have some answer to the first point before starting with a 
new release: is everything OK in the present version?
And I'd also appreciate that the new CV proposals (at least those I'm 
going to take care) would be sent to the 
psi...@li... and 
psi...@li... lists... why both??? We could use 
only one list (that's the perfect solution for me), but using 
alternatively one or the other is a pain when you try to compile a list 
of new terms.

Best,

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

Re: [Psidev-ms-dev] Minor PSI-MS CV changes

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

Looks better to me. And if it's actually wrong, it's better to look professional about it. ;)

-Matt


On 5/3/2011 3:49 PM, Eric Deutsch wrote:
> Hi everyone, while adding some terms to the CV, I thought I tidy up a few items. I propose these
> following changes. Since I don’t know the difference between a cone and a lens, I would be grateful
> if someone can improve on these. If there are no suggestions for improvements, I’ll just commit the
> changes since I can blissfully imagine that these are at least not worse.

Re: [Psidev-ms-dev] IntermediateProduct?

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

Hi Eric,

This solution seems good. Maybe a required 'order' attribute at the 
IntermediateProduct element would be easier to validate instead of the 
ms level terms. On the other hand, the Product list in mzML is ordered 
just by order of appearance. Any of these solutions would do, since more 
than one IntermediateProduct will be extremely rare. So I'm fine with 
'ms level' if this is what the majority prefers.

More important is how to define different collision energies for the 
different steps as Steffen brought up some time ago. Is the proposal to 
have configuration elements in IntermediateProduct and Product?

Regards

Fredrik

On 2011-05-04 01:49, Eric Deutsch wrote:
>
> Hi everyone, at the last call it seems like the preferred plan to 
> support MS3 in TraML as suggested by the reviewers was via an 
> <intermediateProduct> element, so this would look something like this:
>
> <Transition>
>
> <Precursor>
>
> <cvParam cvRef="MS" accession="MS:1000827" name="isolation window 
> target m/z" value="862.94" …../>
>
> <cvParam cvRef="MS" accession="MS:1000041" name="charge state" value="2"/>
>
> </Precursor>
>
> <intermediateProduct>
>
> <cvParam cvRef="MS" accession="MS:1000827" name="isolation window 
> target m/z" value="427.34" …../>
>
> <cvParam cvRef="MS" accession="MS:1000041" name="charge state" value="2"/>
>
> </intermediateProduct>
>
> <Product>
>
> <cvParam cvRef="MS" accession="MS:1000827" name="selection window 
> target m/z" value="540.57" ……/>
>
> <cvParam cvRef="MS" accession="MS:1000041" name="charge state" value="1"/>
>
> </Product>
>
> <InterpretationList>...</InterpretationList>
>
> <RetentionTime>...</RetentionTime>
>
> <ConfigurationList>...</ConfigurationList>
>
> </Transition>
>
> This seems to neatly solve the problem that the intermediate product 
> is a product but is also a precursor and trying to shove them in 
> either <Precursor> or <Product> led to problems.
>
> Note also that Precursor and IntermediateProduct have the term 
> "isolation window target m/z".
>
> While Product has a "selection window target m/z".
>
> I believe this was the consensus on the call and seems to make sense.
>
> Comments from anyone out there on this? Does this seem like a tidy 
> solution?
>
> Since order matters, how do we differentiate between the possibility 
> of multiple intermediate products? Shall we require the ms level term?
>
> <intermediateProduct>
>
> <cvParam cvRef="MS" accession="MS:1000827" name="isolation window 
> target m/z" value="427.34" …../>
>
> <cvParam cvRef="MS" accession="MS:1000041" name="charge state" value="2"/>
>
> <cvParam cvRef="MS" accession="MS:1000511" name="ms level" value="2"/>
>
> </intermediateProduct>
>
> In theory a validator could enforce sequential ms levels beginning 
> with 2, but it might not be easy with the current framework.
>
> What do you think?
>
> Thanks,
>
> Eric
>

[Psidev-ms-dev] IntermediateProduct?

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

Hi everyone, at the last call it seems like the preferred plan to support
MS3 in TraML as suggested by the reviewers was via an <intermediateProduct>
element, so this would look something like this:



<Transition>

  <Precursor>

    <cvParam cvRef="MS" accession="MS:1000827" name="isolation window target
m/z" value="862.94" …../>

    <cvParam cvRef="MS" accession="MS:1000041" name="charge state"
value="2"/>

  </Precursor>

  <intermediateProduct>

    <cvParam cvRef="MS" accession="MS:1000827" name="isolation window target
m/z" value="427.34" …../>

    <cvParam cvRef="MS" accession="MS:1000041" name="charge state"
value="2"/>

  </intermediateProduct>

  <Product>

    <cvParam cvRef="MS" accession="MS:1000827" name="selection window target
m/z" value="540.57" ……/>

    <cvParam cvRef="MS" accession="MS:1000041" name="charge state"
value="1"/>

  </Product>

  <InterpretationList>...</InterpretationList>

  <RetentionTime>...</RetentionTime>

  <ConfigurationList>...</ConfigurationList>

</Transition>



This seems to neatly solve the problem that the intermediate product is a
product but is also a precursor and trying to shove them in either
<Precursor> or <Product> led to problems.



Note also that Precursor and IntermediateProduct have the term "isolation
window target m/z".

While Product has a "selection window target m/z".

I believe this was the consensus on the call and seems to make sense.



Comments from anyone out there on this? Does this seem like a tidy solution?



Since order matters, how do we differentiate between the possibility of
multiple intermediate products? Shall we require the ms level term?



  <intermediateProduct>

    <cvParam cvRef="MS" accession="MS:1000827" name="isolation window target
m/z" value="427.34" …../>

    <cvParam cvRef="MS" accession="MS:1000041" name="charge state"
value="2"/>

    <cvParam cvRef="MS" accession="MS:1000511" name="ms level" value="2"/>

  </intermediateProduct>



In theory a validator could enforce sequential ms levels beginning with 2,
but it might not be easy with the current framework.



What do you think?



Thanks,

Eric

[Psidev-ms-dev] Minor PSI-MS CV changes

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

Hi everyone, while adding some terms to the CV, I thought I tidy up a few
items. I propose these following changes. Since I don’t know the difference
between a cone and a lens, I would be grateful if someone can improve on
these. If there are no suggestions for improvements, I’ll just commit the
changes since I can blissfully imagine that these are at least not worse.



Update:



[Term]

id: MS:1000877

name: tube lens

def: "No ideas." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000482 ! source attribute

relationship: has_units UO:0000218 ! volt



to:



[Term]

id: MS:1000877

name: tube lens voltage

def: "Potential difference setting of the tube lens in volts." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000482 ! source attribute

relationship: has_units UO:0000218 ! volt



-------------------------------------------------------------



Update:



[Term]

id: MS:1000876

name: cone voltage

def: "Potential difference between the sampling cone/orifice and the what?
in volts." [PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000482 ! source attribute

relationship: has_units UO:0000218 ! volt



to:



[Term]

id: MS:1000876

name: cone voltage

def: "Potential difference setting of the sampling cone/orifice in volts."
[PSI:MS]

xref: value-type:xsd\:float "The allowed value-type for this CV term."

is_a: MS:1000482 ! source attribute

relationship: has_units UO:0000218 ! volt

[Psidev-ms-dev] Corrections on CV terms belonging to ProteomeDiscoverer

[Gerhard M. <Ger...@ru...>]

Hi David,
hi Matt,
hi Juan-Antonio,

we already corrected the multi-parenting "is-a" problems concerning the
ProteomeDiscoverer - search engine specific input parameters in the obo 
file and uploaded
it to the CVS (see also mail to mailing list on 21.4.2011, approx 15:19).
(If you have a concurrent version of the obo file you may overwrite our 
changes and we could
repeat the correction in your current version, it took only approx. 5 
minutes).

The other two cases of problems are, that
1) some of these ProteomeDiscoverer CV terms 
(e.g.ProteomeDiscoverer:Precursor Mass Tolerance) duplicate terms 
already present in the OBO-file
2) ProteomeDiscoverer is a workflow-oriented tool which also contains 
operations concerning spectral processing, data transformation, filtering or
     other operations which are not really search engine related things 
(e.g. ProteomeDiscoverer:Spectrum Files: ...,
     ProteomeDiscoverer:Non-Fragment Filter: ..., 
ProteomeDiscoverer:Xtract: ..., ProteomeDiscoverer:Spectrum Grouper: ...)

Sorry for the inconvenience we introduced with problem 1).
We could correct all terms regarding problem 1) (they should be simply 
deleted);
Please decide, whether we should do it now or when you cleaned up!

The terms regarding case 2) should not be deleted, but somehow 
incorporated in the existing spectra generation branch.
That is something which should really be done by mzML experts and during 
your restructuring...

Thanks,
Gerhard + Martin

-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
BioInformatik
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.042
Universitätsstrasse 150
D-44801 Bochum

Phone:	+49(0)234/32-29836
Fax:	+49(0)234/32-14554
Email:	Ger...@ru...
Web:	http://www.medizinisches-proteom-center.de

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

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