psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

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

On 4/20/07, Coleman, Michael <MK...@st...> wrote:
>
>  Angel, thanks for the clarification.
>

no prob

I agree that there'd generally be no reason not to zlib-compress--the base6=
4
> string is already quite opaque.  The only factors I'd see would be (a)
> occasionally zlib will make strings larger (though not by too much), and
>

this does happen occasionally for spectra without any "real" data in it, bu=
t
as you say, this does not increase much and this is an edge case anyway. By
way of (b) I sincerely doubt that any instrument vendor will use dataxml as
their native format, so there will always be some sort of native-format to
dataxml conversion process, which usually lives on a "smart" data analysis
machine ;)

-angel

(b) whether it'd be a burden for dumb instruments to have to know zlib.
>
> Mike
>
>
>  -----Original Message-----
> *From:* Brian Pratt [mailto:bri...@in...]
> *Sent:* Friday, April 20, 2007 3:04 PM
> *To:* 'Angel Pizarro'; Coleman, Michael
> *Cc:* psi...@li...; 'Andreas R=F6mpp'
> *Subject:* RE: [Psidev-ms-dev] Separate binary file for very large data
> sets?
>
> Angel is correct - I did mean compression (base64 encoding actually bloat=
s
> the data a bit).
>
> I believe the proposed next version of mzData adopts Patrick Pedrioli's
> mzXML 3.0 technique of optionally first compressing (with zlib) the binar=
y
> data before encoding it (with base64).    I'd argue for making it mandito=
ry,
> since it's not like there's any loss of human-readability, and the files =
do
> shrink admirably.
>
> - Brian
>
>  ------------------------------
> *From:* psi...@li... [mailto:
> psi...@li...] *On Behalf Of *Angel Pizarro
> *Sent:* Friday, April 20, 2007 12:43 PM
> *To:* Coleman, Michael
> *Cc:* psi...@li...; Brian Pratt; Andreas R=F6mpp
> *Subject:* Re: [Psidev-ms-dev] Separate binary file for very large data
> sets?
>
> Brian is refering to the way mzXML 3.0 (and the new dataXML format) zlib
> compress the "base64-encoded" spectra. While not an official part of the
> mzData 1.05 schema, I believe there are several groups that use this
> technique in-house for storage of mzData files.
>
> -angel
>
>
> On 4/20/07, Coleman, Michael <MK...@st...> wrote:
> >
> > If by "compressed" you mean "base64-encoded", I think it's important to
> > use the latter term, to avoid giving the wrong impression.  As far as I
> > know, compression is not a feature--nor a goal--of mzData.
> >
> > For what it's worth, I encountered my first mzData file in a work
> > situation this week.  It's 2.7 times as large as the corresponding ms2
> > file.
> >
> > Mike
> >
> >
> >
> > > -----Original Message-----
> > > From: psi...@li...
> > > [mailto:psi...@li... ] On
> > > Behalf Of Brian Pratt
> > > Sent: Friday, April 20, 2007 2:02 PM
> > > To: 'Andreas R=F6mpp'; psi...@li...
> > > Subject: Re: [Psidev-ms-dev] Separate binary file for very
> > > large data sets?
> > >
> > >
> > > I wonder if it wouldn't make as much sense to treat the
> > > mzData file as the
> > > "binary file" and come up with a sort of summary schema of
> > > your own that
> > > could point into the mzData file.  You'd get maximum reuse of
> > > community
> > > source code that way.
> > >
> > > But first, I'd say try it with straight-up mzData with
> > > compressed peak lists
> > > and see if you really need to go to the bother of a separate
> > > file.  I'm
> > > guessing you'll be pleasantly surprised.  Plus, I really,
> > > really dislike the
> > > use of interdependent files - one or the other is forever
> > > getting out of
> > > synch, lost, renamed, etc.
> > >
> > > Hope this helps,
> > >
> > > Brian Pratt
> > > www.insilicos.com
> > >
> > > -----Original Message-----
> > > From: psi...@li...
> > > [mailto:psi...@li... ] On
> > > Behalf Of Andreas
> > > R=F6mpp
> > > Sent: Friday, April 20, 2007 8:45 AM
> > > To: psi...@li...;
> > > And...@an...
> > > Subject: [Psidev-ms-dev] Separate binary file for very large
> > > data sets?
> > >
> > > Hello everybody,
> > >
> > > We develop software for imaging mass spectrometry in the
> > > framework of a
> > > project funded by the European Union. We intend to use
> > > dataXML as a standard
> > > format to exchange data between the different partner labs
> > > and also (as far
> > > as possible) as the internal data format for a joint
> > > processing software
> > > suite. However, we run into the problem of very large data
> > > sets which can
> > > easily exceed 1GB (e.g. 256
> > > *256 pixels with one high resolution mass spectrum each). Therefore w=
e
> >
> > > thought about storing the spectrum data
> > > ('MassToChargeRatioArray' and '
> > > 'IntensityArray') in a separate binary file. This would make
> > > data handling
> > > much faster and easier ( e.g. when parsing the XML file). So instead
> > of
> > > writing the binary data in the XML file we plan to include a link to =
a
> > > separate file (file location, start and end position of
> > > spectrum in binary
> > > file).
> > > This problem is somewhat similar to the already discussed
> > > issue of an index
> > > file.
> > > Would it be possible to include such an option (external
> > > binary file) into
> > > the dataXML standard?
> > >
> > > Best regards,
> > > Andreas
> > >
> > > --
> > > --------------------------------------------------------------
> > > --------------
> > > -------------
> > > Dr. Andreas Roempp
> > > Institute of Inorganic and Analytical Chemistry
> > > - Analytical Chemistry -
> > > Justus Liebig University Giessen
> > > Schubertstrasse 60, Build. 16
> > > D-35392 Giessen
> > > Germany
> > >
> > > phone:  +49-641-99 34802
> > > fax:    +49-641-99 34809
> > > email: And...@an...
> > > Internet: http://www.uni-giessen.de/analytik/
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > -----------
> > > This SF.net email is sponsored by DB2 Express Download DB2
> > > Express C - the
> > > FREE version of DB2 express and take control of your XML. No
> > > limits. Just
> > > data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > Psidev-ms-dev mailing list
> > > Psi...@li...
> > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> > >
> > >
> > > --------------------------------------------------------------
> > > -----------
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > Psidev-ms-dev mailing list
> > > Psi...@li...
> > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> > >
> >
> >
> > -----------------------------------------------------------------------=
--
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
>
>
>
> --
> Angel Pizarro
> Director, Bioinformatics Facility
> Institute for Translational Medicine and Therapeutics
> University of Pennsylvania
> 806 BRB II/III
> 421 Curie Blvd.
> Philadelphia, PA 19104-6160
>
> P: 215-573-3736
> F: 215-573-9004
>
>


--=20
Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

[Coleman, M. <MK...@St...>]

Angel, thanks for the clarification. =20
=20
I agree that there'd generally be no reason not to zlib-compress--the =
base64 string is already quite opaque.  The only factors I'd see would =
be (a) occasionally zlib will make strings larger (though not by too =
much), and (b) whether it'd be a burden for dumb instruments to have to =
know zlib.
=20
Mike
=20

	-----Original Message-----
	From: Brian Pratt [mailto:bri...@in...]=20
	Sent: Friday, April 20, 2007 3:04 PM
	To: 'Angel Pizarro'; Coleman, Michael
	Cc: psi...@li...; 'Andreas R=F6mpp'
	Subject: RE: [Psidev-ms-dev] Separate binary file for very large data =
sets?
=09
=09
	Angel is correct - I did mean compression (base64 encoding actually =
bloats the data a bit). =20
	=20
	I believe the proposed next version of mzData adopts Patrick Pedrioli's =
mzXML 3.0 technique of optionally first compressing (with zlib) the =
binary data before encoding it (with base64).    I'd argue for making it =
manditory, since it's not like there's any loss of human-readability, =
and the files do shrink admirably.
	=20
	- Brian

________________________________

	From: psi...@li... =
[mailto:psi...@li...] On Behalf Of Angel =
Pizarro
	Sent: Friday, April 20, 2007 12:43 PM
	To: Coleman, Michael
	Cc: psi...@li...; Brian Pratt; Andreas R=F6mpp
	Subject: Re: [Psidev-ms-dev] Separate binary file for very large data =
sets?
=09
=09
	Brian is refering to the way mzXML 3.0 (and the new dataXML format) =
zlib compress the "base64-encoded" spectra. While not an official part =
of the mzData 1.05 schema, I believe there are several groups that use =
this technique in-house for storage of mzData files.=20
=09
	-angel
=09
=09
=09
	On 4/20/07, Coleman, Michael <MK...@st...> wrote:=20

		If by "compressed" you mean "base64-encoded", I think it's important =
to use the latter term, to avoid giving the wrong impression.  As far as =
I know, compression is not a feature--nor a goal--of mzData.=20
	=09
		For what it's worth, I encountered my first mzData file in a work =
situation this week.  It's 2.7 times as large as the corresponding ms2 =
file.
	=09
		Mike
	=09
	=09
	=09
		> -----Original Message-----
		> From: psi...@li...
		> [mailto:psi...@li... ] On
		> Behalf Of Brian Pratt
		> Sent: Friday, April 20, 2007 2:02 PM
		> To: 'Andreas R=F6mpp'; psi...@li...
		> Subject: Re: [Psidev-ms-dev] Separate binary file for very=20
		> large data sets?
		>
		>
		> I wonder if it wouldn't make as much sense to treat the
		> mzData file as the
		> "binary file" and come up with a sort of summary schema of
		> your own that=20
		> could point into the mzData file.  You'd get maximum reuse of
		> community
		> source code that way.
		>
		> But first, I'd say try it with straight-up mzData with
		> compressed peak lists=20
		> and see if you really need to go to the bother of a separate
		> file.  I'm
		> guessing you'll be pleasantly surprised.  Plus, I really,
		> really dislike the
		> use of interdependent files - one or the other is forever=20
		> getting out of
		> synch, lost, renamed, etc.
		>
		> Hope this helps,
		>
		> Brian Pratt
		> www.insilicos.com
		>
		> -----Original Message-----=20
		> From: psi...@li...
		> [mailto:psi...@li... ] On
		> Behalf Of Andreas
		> R=F6mpp
		> Sent: Friday, April 20, 2007 8:45 AM
		> To: psi...@li...;
		> And...@an...
		> Subject: [Psidev-ms-dev] Separate binary file for very large
		> data sets?
		>
		> Hello everybody,
		>
		> We develop software for imaging mass spectrometry in the=20
		> framework of a
		> project funded by the European Union. We intend to use
		> dataXML as a standard
		> format to exchange data between the different partner labs
		> and also (as far
		> as possible) as the internal data format for a joint=20
		> processing software
		> suite. However, we run into the problem of very large data
		> sets which can
		> easily exceed 1GB (e.g. 256
		> *256 pixels with one high resolution mass spectrum each). Therefore =
we=20
		> thought about storing the spectrum data
		> ('MassToChargeRatioArray' and '
		> 'IntensityArray') in a separate binary file. This would make
		> data handling
		> much faster and easier ( e.g. when parsing the XML file). So instead =
of
		> writing the binary data in the XML file we plan to include a link to =
a
		> separate file (file location, start and end position of
		> spectrum in binary
		> file).=20
		> This problem is somewhat similar to the already discussed
		> issue of an index
		> file.
		> Would it be possible to include such an option (external
		> binary file) into
		> the dataXML standard?=20
		>
		> Best regards,
		> Andreas
		>
		> --
		> --------------------------------------------------------------
		> --------------
		> -------------
		> Dr. Andreas Roempp
		> Institute of Inorganic and Analytical Chemistry=20
		> - Analytical Chemistry -
		> Justus Liebig University Giessen
		> Schubertstrasse 60, Build. 16
		> D-35392 Giessen
		> Germany
		>
		> phone:  +49-641-99 34802
		> fax:    +49-641-99 34809=20
		> email: And...@an...
		> Internet: http://www.uni-giessen.de/analytik/=20
		>
		>
		>
		>
		> --------------------------------------------------------------
		> -----------
		> This SF.net email is sponsored by DB2 Express Download DB2
		> Express C - the
		> FREE version of DB2 express and take control of your XML. No
		> limits. Just
		> data. Click to get it now.
		> http://sourceforge.net/powerbar/db2/
		> _______________________________________________
		> Psidev-ms-dev mailing list
		> Psi...@li...
		> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
		>
		>
		> --------------------------------------------------------------
		> -----------
		> This SF.net email is sponsored by DB2 Express=20
		> Download DB2 Express C - the FREE version of DB2 express and take
		> control of your XML. No limits. Just data. Click to get it now.
		> http://sourceforge.net/powerbar/db2/=20
		> _______________________________________________
		> Psidev-ms-dev mailing list
		> Psi...@li...
		> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
		>
	=09
		=
-------------------------------------------------------------------------=

		This SF.net email is sponsored by DB2 Express
		Download DB2 Express C - the FREE version of DB2 express and take=20
		control of your XML. No limits. Just data. Click to get it now.
		http://sourceforge.net/powerbar/db2/
		_______________________________________________
		Psidev-ms-dev mailing list=20
		Psi...@li...
		https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev=20
	=09




	--=20
	Angel Pizarro
	Director, Bioinformatics Facility
	Institute for Translational Medicine and Therapeutics
	University of Pennsylvania
	806 BRB II/III
	421 Curie Blvd.=20
	Philadelphia, PA 19104-6160
=09
	P: 215-573-3736
	F: 215-573-9004=20

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

[Brian P. <bri...@in...>]

Oops, right.  "dataXML" and "mzData" aren't the same thing.
=20
I think my brain keeps saying "mzData" because it just can't handle the
awfulness of saying "dataXML".
=20
- Brian

  _____ =20

From: Brian Pratt [mailto:bri...@in...]=20
Sent: Friday, April 20, 2007 1:04 PM
To: 'Angel Pizarro'; 'Coleman, Michael'
Cc: 'psi...@li...'; 'Andreas R=F6mpp'
Subject: RE: [Psidev-ms-dev] Separate binary file for very large data =
sets?


Angel is correct - I did mean compression (base64 encoding actually =
bloats
the data a bit). =20
=20
I believe the proposed next version of mzData adopts Patrick Pedrioli's
mzXML 3.0 technique of optionally first compressing (with zlib) the =
binary
data before encoding it (with base64).    I'd argue for making it =
manditory,
since it's not like there's any loss of human-readability, and the files =
do
shrink admirably.
=20
- Brian

  _____ =20

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Angel
Pizarro
Sent: Friday, April 20, 2007 12:43 PM
To: Coleman, Michael
Cc: psi...@li...; Brian Pratt; Andreas R=F6mpp
Subject: Re: [Psidev-ms-dev] Separate binary file for very large data =
sets?


Brian is refering to the way mzXML 3.0 (and the new dataXML format) zlib
compress the "base64-encoded" spectra. While not an official part of the
mzData 1.05 schema, I believe there are several groups that use this
technique in-house for storage of mzData files.=20

-angel



On 4/20/07, Coleman, Michael <MK...@st...> wrote:=20

If by "compressed" you mean "base64-encoded", I think it's important to =
use
the latter term, to avoid giving the wrong impression.  As far as I =
know,
compression is not a feature--nor a goal--of mzData.=20

For what it's worth, I encountered my first mzData file in a work =
situation
this week.  It's 2.7 times as large as the corresponding ms2 file.

Mike



> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...
<mailto:psi...@li...> ] On
> Behalf Of Brian Pratt
> Sent: Friday, April 20, 2007 2:02 PM
> To: 'Andreas R=F6mpp'; psi...@li...
> Subject: Re: [Psidev-ms-dev] Separate binary file for very=20
> large data sets?
>
>
> I wonder if it wouldn't make as much sense to treat the
> mzData file as the
> "binary file" and come up with a sort of summary schema of
> your own that=20
> could point into the mzData file.  You'd get maximum reuse of
> community
> source code that way.
>
> But first, I'd say try it with straight-up mzData with
> compressed peak lists=20
> and see if you really need to go to the bother of a separate
> file.  I'm
> guessing you'll be pleasantly surprised.  Plus, I really,
> really dislike the
> use of interdependent files - one or the other is forever=20
> getting out of
> synch, lost, renamed, etc.
>
> Hope this helps,
>
> Brian Pratt
> www.insilicos.com
>
> -----Original Message-----=20
> From: psi...@li...
> [mailto:psi...@li...
<mailto:psi...@li...> ] On
> Behalf Of Andreas
> R=F6mpp
> Sent: Friday, April 20, 2007 8:45 AM
> To: psi...@li...;
> And...@an...
> Subject: [Psidev-ms-dev] Separate binary file for very large
> data sets?
>
> Hello everybody,
>
> We develop software for imaging mass spectrometry in the=20
> framework of a
> project funded by the European Union. We intend to use
> dataXML as a standard
> format to exchange data between the different partner labs
> and also (as far
> as possible) as the internal data format for a joint=20
> processing software
> suite. However, we run into the problem of very large data
> sets which can
> easily exceed 1GB (e.g. 256
> *256 pixels with one high resolution mass spectrum each). Therefore we =

> thought about storing the spectrum data
> ('MassToChargeRatioArray' and '
> 'IntensityArray') in a separate binary file. This would make
> data handling
> much faster and easier ( e.g. when parsing the XML file). So instead =
of
> writing the binary data in the XML file we plan to include a link to a
> separate file (file location, start and end position of
> spectrum in binary
> file).=20
> This problem is somewhat similar to the already discussed
> issue of an index
> file.
> Would it be possible to include such an option (external
> binary file) into
> the dataXML standard?=20
>
> Best regards,
> Andreas
>
> --
> --------------------------------------------------------------
> --------------
> -------------
> Dr. Andreas Roempp
> Institute of Inorganic and Analytical Chemistry=20
> - Analytical Chemistry -
> Justus Liebig University Giessen
> Schubertstrasse 60, Build. 16
> D-35392 Giessen
> Germany
>
> phone:  +49-641-99 34802
> fax:    +49-641-99 34809=20
> email: And...@an...
> Internet: http://www.uni-giessen.de/analytik/
<http://www.uni-giessen.de/analytik/>=20
>
>
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express Download DB2
> Express C - the
> FREE version of DB2 express and take control of your XML. No
> limits. Just
> data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express=20
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
<http://sourceforge.net/powerbar/db2/>=20
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take=20
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Psidev-ms-dev mailing list=20
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
<https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev>=20





--=20
Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.=20
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004=20

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

[Brian P. <bri...@in...>]

Angel is correct - I did mean compression (base64 encoding actually =
bloats
the data a bit). =20
=20
I believe the proposed next version of mzData adopts Patrick Pedrioli's
mzXML 3.0 technique of optionally first compressing (with zlib) the =
binary
data before encoding it (with base64).    I'd argue for making it =
manditory,
since it's not like there's any loss of human-readability, and the files =
do
shrink admirably.
=20
- Brian

  _____ =20

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Angel
Pizarro
Sent: Friday, April 20, 2007 12:43 PM
To: Coleman, Michael
Cc: psi...@li...; Brian Pratt; Andreas R=F6mpp
Subject: Re: [Psidev-ms-dev] Separate binary file for very large data =
sets?


Brian is refering to the way mzXML 3.0 (and the new dataXML format) zlib
compress the "base64-encoded" spectra. While not an official part of the
mzData 1.05 schema, I believe there are several groups that use this
technique in-house for storage of mzData files.=20

-angel



On 4/20/07, Coleman, Michael <MK...@st...> wrote:=20

If by "compressed" you mean "base64-encoded", I think it's important to =
use
the latter term, to avoid giving the wrong impression.  As far as I =
know,
compression is not a feature--nor a goal--of mzData.=20

For what it's worth, I encountered my first mzData file in a work =
situation
this week.  It's 2.7 times as large as the corresponding ms2 file.

Mike



> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...
<mailto:psi...@li...> ] On
> Behalf Of Brian Pratt
> Sent: Friday, April 20, 2007 2:02 PM
> To: 'Andreas R=F6mpp'; psi...@li...
> Subject: Re: [Psidev-ms-dev] Separate binary file for very=20
> large data sets?
>
>
> I wonder if it wouldn't make as much sense to treat the
> mzData file as the
> "binary file" and come up with a sort of summary schema of
> your own that=20
> could point into the mzData file.  You'd get maximum reuse of
> community
> source code that way.
>
> But first, I'd say try it with straight-up mzData with
> compressed peak lists=20
> and see if you really need to go to the bother of a separate
> file.  I'm
> guessing you'll be pleasantly surprised.  Plus, I really,
> really dislike the
> use of interdependent files - one or the other is forever=20
> getting out of
> synch, lost, renamed, etc.
>
> Hope this helps,
>
> Brian Pratt
> www.insilicos.com
>
> -----Original Message-----=20
> From: psi...@li...
> [mailto:psi...@li...
<mailto:psi...@li...> ] On
> Behalf Of Andreas
> R=F6mpp
> Sent: Friday, April 20, 2007 8:45 AM
> To: psi...@li...;
> And...@an...
> Subject: [Psidev-ms-dev] Separate binary file for very large
> data sets?
>
> Hello everybody,
>
> We develop software for imaging mass spectrometry in the=20
> framework of a
> project funded by the European Union. We intend to use
> dataXML as a standard
> format to exchange data between the different partner labs
> and also (as far
> as possible) as the internal data format for a joint=20
> processing software
> suite. However, we run into the problem of very large data
> sets which can
> easily exceed 1GB (e.g. 256
> *256 pixels with one high resolution mass spectrum each). Therefore we =

> thought about storing the spectrum data
> ('MassToChargeRatioArray' and '
> 'IntensityArray') in a separate binary file. This would make
> data handling
> much faster and easier ( e.g. when parsing the XML file). So instead =
of
> writing the binary data in the XML file we plan to include a link to a
> separate file (file location, start and end position of
> spectrum in binary
> file).=20
> This problem is somewhat similar to the already discussed
> issue of an index
> file.
> Would it be possible to include such an option (external
> binary file) into
> the dataXML standard?=20
>
> Best regards,
> Andreas
>
> --
> --------------------------------------------------------------
> --------------
> -------------
> Dr. Andreas Roempp
> Institute of Inorganic and Analytical Chemistry=20
> - Analytical Chemistry -
> Justus Liebig University Giessen
> Schubertstrasse 60, Build. 16
> D-35392 Giessen
> Germany
>
> phone:  +49-641-99 34802
> fax:    +49-641-99 34809=20
> email: And...@an...
> Internet: http://www.uni-giessen.de/analytik/
<http://www.uni-giessen.de/analytik/>=20
>
>
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express Download DB2
> Express C - the
> FREE version of DB2 express and take control of your XML. No
> limits. Just
> data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express=20
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
<http://sourceforge.net/powerbar/db2/>=20
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take=20
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Psidev-ms-dev mailing list=20
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
<https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev>=20





--=20
Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.=20
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004=20

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

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

Brian is refering to the way mzXML 3.0 (and the new dataXML format) zlib
compress the "base64-encoded" spectra. While not an official part of the
mzData 1.05 schema, I believe there are several groups that use this
technique in-house for storage of mzData files.

-angel


On 4/20/07, Coleman, Michael <MK...@st...> wrote:
>
> If by "compressed" you mean "base64-encoded", I think it's important to
> use the latter term, to avoid giving the wrong impression.  As far as I
> know, compression is not a feature--nor a goal--of mzData.
>
> For what it's worth, I encountered my first mzData file in a work
> situation this week.  It's 2.7 times as large as the corresponding ms2
> file.
>
> Mike
>
>
>
> > -----Original Message-----
> > From: psi...@li...
> > [mailto:psi...@li...] On
> > Behalf Of Brian Pratt
> > Sent: Friday, April 20, 2007 2:02 PM
> > To: 'Andreas R=F6mpp'; psi...@li...
> > Subject: Re: [Psidev-ms-dev] Separate binary file for very
> > large data sets?
> >
> >
> > I wonder if it wouldn't make as much sense to treat the
> > mzData file as the
> > "binary file" and come up with a sort of summary schema of
> > your own that
> > could point into the mzData file.  You'd get maximum reuse of
> > community
> > source code that way.
> >
> > But first, I'd say try it with straight-up mzData with
> > compressed peak lists
> > and see if you really need to go to the bother of a separate
> > file.  I'm
> > guessing you'll be pleasantly surprised.  Plus, I really,
> > really dislike the
> > use of interdependent files - one or the other is forever
> > getting out of
> > synch, lost, renamed, etc.
> >
> > Hope this helps,
> >
> > Brian Pratt
> > www.insilicos.com
> >
> > -----Original Message-----
> > From: psi...@li...
> > [mailto:psi...@li...] On
> > Behalf Of Andreas
> > R=F6mpp
> > Sent: Friday, April 20, 2007 8:45 AM
> > To: psi...@li...;
> > And...@an...
> > Subject: [Psidev-ms-dev] Separate binary file for very large
> > data sets?
> >
> > Hello everybody,
> >
> > We develop software for imaging mass spectrometry in the
> > framework of a
> > project funded by the European Union. We intend to use
> > dataXML as a standard
> > format to exchange data between the different partner labs
> > and also (as far
> > as possible) as the internal data format for a joint
> > processing software
> > suite. However, we run into the problem of very large data
> > sets which can
> > easily exceed 1GB (e.g. 256
> > *256 pixels with one high resolution mass spectrum each). Therefore we
> > thought about storing the spectrum data
> > ('MassToChargeRatioArray' and '
> > 'IntensityArray') in a separate binary file. This would make
> > data handling
> > much faster and easier (e.g. when parsing the XML file). So instead of
> > writing the binary data in the XML file we plan to include a link to a
> > separate file (file location, start and end position of
> > spectrum in binary
> > file).
> > This problem is somewhat similar to the already discussed
> > issue of an index
> > file.
> > Would it be possible to include such an option (external
> > binary file) into
> > the dataXML standard?
> >
> > Best regards,
> > Andreas
> >
> > --
> > --------------------------------------------------------------
> > --------------
> > -------------
> > Dr. Andreas Roempp
> > Institute of Inorganic and Analytical Chemistry
> > - Analytical Chemistry -
> > Justus Liebig University Giessen
> > Schubertstrasse 60, Build. 16
> > D-35392 Giessen
> > Germany
> >
> > phone:  +49-641-99 34802
> > fax:    +49-641-99 34809
> > email: And...@an...
> > Internet: http://www.uni-giessen.de/analytik/
> >
> >
> >
> >
> > --------------------------------------------------------------
> > -----------
> > This SF.net email is sponsored by DB2 Express Download DB2
> > Express C - the
> > FREE version of DB2 express and take control of your XML. No
> > limits. Just
> > data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
> >
> > --------------------------------------------------------------
> > -----------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>



--=20
Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

[Coleman, M. <MK...@St...>]

If by "compressed" you mean "base64-encoded", I think it's important to =
use the latter term, to avoid giving the wrong impression.  As far as I =
know, compression is not a feature--nor a goal--of mzData.

For what it's worth, I encountered my first mzData file in a work =
situation this week.  It's 2.7 times as large as the corresponding ms2 =
file.

Mike



> -----Original Message-----
> From: psi...@li...=20
> [mailto:psi...@li...] On=20
> Behalf Of Brian Pratt
> Sent: Friday, April 20, 2007 2:02 PM
> To: 'Andreas R=F6mpp'; psi...@li...
> Subject: Re: [Psidev-ms-dev] Separate binary file for very=20
> large data sets?
>=20
>=20
> I wonder if it wouldn't make as much sense to treat the=20
> mzData file as the
> "binary file" and come up with a sort of summary schema of=20
> your own that
> could point into the mzData file.  You'd get maximum reuse of=20
> community
> source code that way.
>=20
> But first, I'd say try it with straight-up mzData with=20
> compressed peak lists
> and see if you really need to go to the bother of a separate=20
> file.  I'm
> guessing you'll be pleasantly surprised.  Plus, I really,=20
> really dislike the
> use of interdependent files - one or the other is forever=20
> getting out of
> synch, lost, renamed, etc.
>=20
> Hope this helps,
>=20
> Brian Pratt
> www.insilicos.com
>=20
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On=20
> Behalf Of Andreas
> R=F6mpp
> Sent: Friday, April 20, 2007 8:45 AM
> To: psi...@li...;
> And...@an...
> Subject: [Psidev-ms-dev] Separate binary file for very large=20
> data sets?
>=20
> Hello everybody,
>=20
> We develop software for imaging mass spectrometry in the=20
> framework of a
> project funded by the European Union. We intend to use=20
> dataXML as a standard
> format to exchange data between the different partner labs=20
> and also (as far
> as possible) as the internal data format for a joint=20
> processing software
> suite. However, we run into the problem of very large data=20
> sets which can
> easily exceed 1GB (e.g. 256
> *256 pixels with one high resolution mass spectrum each). Therefore we
> thought about storing the spectrum data=20
> ('MassToChargeRatioArray' and '=20
> 'IntensityArray') in a separate binary file. This would make=20
> data handling
> much faster and easier (e.g. when parsing the XML file). So instead of
> writing the binary data in the XML file we plan to include a link to a
> separate file (file location, start and end position of=20
> spectrum in binary
> file).
> This problem is somewhat similar to the already discussed=20
> issue of an index
> file.
> Would it be possible to include such an option (external=20
> binary file) into
> the dataXML standard?
>=20
> Best regards,
> Andreas
>=20
> --
> --------------------------------------------------------------
> --------------
> -------------
> Dr. Andreas Roempp
> Institute of Inorganic and Analytical Chemistry
> - Analytical Chemistry -
> Justus Liebig University Giessen
> Schubertstrasse 60, Build. 16
> D-35392 Giessen
> Germany
>=20
> phone:  +49-641-99 34802
> fax:    +49-641-99 34809
> email: And...@an...
> Internet: http://www.uni-giessen.de/analytik/
>=20
>=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express Download DB2=20
> Express C - the
> FREE version of DB2 express and take control of your XML. No=20
> limits. Just
> data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>=20
>=20
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>=20

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

[Brian P. <bri...@in...>]

I wonder if it wouldn't make as much sense to treat the mzData file as =
the
"binary file" and come up with a sort of summary schema of your own that
could point into the mzData file.  You'd get maximum reuse of community
source code that way.

But first, I'd say try it with straight-up mzData with compressed peak =
lists
and see if you really need to go to the bother of a separate file.  I'm
guessing you'll be pleasantly surprised.  Plus, I really, really dislike =
the
use of interdependent files - one or the other is forever getting out of
synch, lost, renamed, etc.

Hope this helps,

Brian Pratt
www.insilicos.com

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of =
Andreas
R=F6mpp
Sent: Friday, April 20, 2007 8:45 AM
To: psi...@li...;
And...@an...
Subject: [Psidev-ms-dev] Separate binary file for very large data sets?

Hello everybody,

We develop software for imaging mass spectrometry in the framework of a
project funded by the European Union. We intend to use dataXML as a =
standard
format to exchange data between the different partner labs and also (as =
far
as possible) as the internal data format for a joint processing software
suite. However, we run into the problem of very large data sets which =
can
easily exceed 1GB (e.g. 256
*256 pixels with one high resolution mass spectrum each). Therefore we
thought about storing the spectrum data ('MassToChargeRatioArray' and '=20
'IntensityArray') in a separate binary file. This would make data =
handling
much faster and easier (e.g. when parsing the XML file). So instead of
writing the binary data in the XML file we plan to include a link to a
separate file (file location, start and end position of spectrum in =
binary
file).
This problem is somewhat similar to the already discussed issue of an =
index
file.
Would it be possible to include such an option (external binary file) =
into
the dataXML standard?

Best regards,
Andreas

--
-------------------------------------------------------------------------=
---
-------------
Dr. Andreas Roempp
Institute of Inorganic and Analytical Chemistry
- Analytical Chemistry -
Justus Liebig University Giessen
Schubertstrasse 60, Build. 16
D-35392 Giessen
Germany

phone:  +49-641-99 34802
fax:    +49-641-99 34809
email: And...@an...
Internet: http://www.uni-giessen.de/analytik/




-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express Download DB2 Express C - =
the
FREE version of DB2 express and take control of your XML. No limits. =
Just
data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Pierre-Alain B. <pie...@is...>]

Yes, presumably.
If it has to change for some reasons, we'll let you know.

Pierre-Alain

Trish Whetzel wrote:
>> we can make a ccall from the main room. So let's say we'll use the usual
>> numbers and codes (the same as for the WG ccalls)
>> Talk to you soon
> Excellent - will that be for both days?
>
> Trish
>
>
>>> Both of those times are fine with me as well.
>>>
>>> Trish
>>>
>>>> I am fine with both timings. Lyon time is 9 hours ahead of PDT.
>>>> Please let me know the conf call number and such.
>>>>
>>>> Have a good time in Lyon,
>>>>
>>>>
>>>> Pete.
>>>>
>>>>
>>>> Eric Deutsch wrote:
>>>>>
>>>>> Hi everyone, here is a summary of discussion on the CV at today's 
>>>>> call:
>>>>>
>>>>> At the end of the call, we discussed the possibility of having Trish
>>>>> and Pete (who cannot attended Lyon) (and possibly others) be on a
>>>>> conference call for selected times during the meeting, specifically
>>>>>
>>>>> - Monday 4:30p -- 6:00p Lyon time for full CV session
>>>>>
>>>>> - Tuesday 5:00p -- 6:00p Lyon time for final MS CV discussion
>>>>>
>>>>> Can this be arranged at the Lyon facilities?
>>>>>
>>>>> Terms that need debate:
>>>>>
>>>>> - msLevel - The term appears as Precursor Ion Scan (PSI:1000100),
>>>>> Product Ion Scan (PSI:1000101) and Nth Generation Product Ion
>>>>> (PSI:1000337). What term should we use for ms 4th, ms 5th and such?
>>>>> We have to keep precursor ion and product ion. Terms such as
>>>>> daughter ion and parent ion are deprecated. We still use Fragment
>>>>> ion though. These are some additional related terms that I could
>>>>> find in the CV.
>>>>>
>>>>> Both mzXML and mzData had a "msLevel" **attribute**. The decision
>>>>> was made to put msLevel as a CV term in dataXML.  However, if we add
>>>>> msLevel, it appears there would be some redundancy with existing
>>>>> terms in the CV (as above). Decide how to proceed in Lyon.
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000364
>>>>>
>>>>> name: Fragment Ion
>>>>>
>>>>> def: "A product ion resulting from the dissociation of a precursor
>>>>> ion." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000365 ! Ion
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000344
>>>>>
>>>>> name: Progeny Ion
>>>>>
>>>>> def: "A charged product of a series of consecutive reactions that
>>>>> includes product ions, 1st generation product ions, 2nd generation
>>>>> product ions, etc. Given the sequential fragmentation scheme: M1+ ?
>>>>> M2+ ? M3+ ? M4+ ? M5+ M4+ is the precursor ion of M5+, a 1st
>>>>> generation product ion of M3+, a 2nd generation product ion of M2+
>>>>> and a 3rd generation product ion of M1+. " [PSI:GPS]
>>>>>
>>>>> exact_synonym: "Progeny Fragment Ion" []
>>>>>
>>>>> is_a: PSI:1000365 ! Ion
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000342
>>>>>
>>>>> name: Product Ion
>>>>>
>>>>> def: "An ion formed as the product of a reaction involving a
>>>>> particular precursor ion. The reaction can unimolecular
>>>>> dissociation, an ion/molecule reaction, or involve simply a change
>>>>> in the number of charges. The terms daughter ion and parent ion are
>>>>> not recommended." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000365 ! Ion
>>>>>
>>>>>
>>>>>
>>>>> - mzRangeStart, mzRangeStop
>>>>>
>>>>> According to Eric it would be useful to have a start and stop rather
>>>>> than a single mass range which can be confusing. I think we need all
>>>>> three terms: mass range, mzRangeStart and mzRangeStop. Is there
>>>>> anyway to do that?
>>>>>
>>>>> Keep them as attributes instead? Discuss more in Lyon. Both previous
>>>>> formats had them as separate attributes, not CV terms.
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000313
>>>>>
>>>>> name: Mass Range
>>>>>
>>>>> def: "The limit of m/z over which a mass spectrometer can detect
>>>>> ions." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000444 ! m/z Separation Method
>>>>>
>>>>>
>>>>> - I dont know what is this term for?:
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000104
>>>>>
>>>>> name: None
>>>>>
>>>>> def: "None." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000021 ! Reflectron State
>>>>>
>>>>> History of this term unknown.  Maybe Randy knows? Eric will ask him.
>>>>>
>>>>> - Instrument Name
>>>>>
>>>>> i think Instrument name is same as model because Instrument's model
>>>>> name is everything but the Vendor's name. Also, each instrument will
>>>>> be defined, such as LTQ-FT LTQ Orbitrap. The definition of each
>>>>> model would contain the vendor name. That means we are keeping Model
>>>>> as it is and Instrument Name will not be used?
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000463
>>>>>
>>>>> name: Instrument
>>>>>
>>>>> def: "Device which performs a measurement." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000031
>>>>>
>>>>> name: Model
>>>>>
>>>>> def: "Instrument's model name (everything but the vendor's name)"
>>>>> [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:1000454 ! Instrument Additional Description
>>>>>
>>>>> Use the term "InstrumentModel" and not "InstrumentName" or "Model"
>>>>>
>>>>> Maybe make new term "InstrumentModel" and deprecate "Model" and will
>>>>> not use "InstrumentName"
>>>>>
>>>>> Bring up in Lyon, to find out what the recommendation is for tidying
>>>>> up the ontology.
>>>>>
>>>>> - Should we replace all ThermoFinnigan with Thermo Fisher Scientific
>>>>> because the company name has changed?
>>>>>
>>>>> Create a new vendor term "Thermo Fisher Scientific" instead of
>>>>> renaming previous one.  The vendor for many existing years-old mass
>>>>> specs was ThermoFinnigan at the time.  Maybe putting a date range in
>>>>> the definitions would be helpful?
>>>>>
>>>>> - LowestMzValue - Is this within a spectrum or within a experiment.
>>>>> A clear definition is needed.
>>>>>
>>>>> - HighestMzValue - Again what is the reference for this term. I have
>>>>> to know what is it for in order                    to get a clear
>>>>> definintion. Lowest and highest observed values in a spectrum. Used
>>>>> by some software instead of opening up all spectra.
>>>>>
>>>>> - Scan Type - "Dictates the type of scan used to generate the
>>>>> spectrum. Usually refers to the range but can also include linked,
>>>>> precursor, product and neutral mass loss types of scan."
>>>>>
>>>>> What is the difference between Scan Type and Scan Mode?
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000036
>>>>>
>>>>> name: Scan Mode
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_obsolete: true
>>>>>
>>>>> Pete will research this more and report back.
>>>>>
>>>>> Try to get Trish and Pete to the Monday 4:30 -- 6:00, and maybe
>>>>> Tuesday 5:00 -- 6:00p
>>>>>
>>>>> Lyon is currently GMT+2
>>>>>
>>>>> Encourage vendors to enter items via the term tracker including
>>>>> definitions
>>>>>
>>>>> Eric will email Pierre-Alain and others about joining in on Monday,
>>>>> Tuesday
>>>>>
>>>>> Terms to be added:
>>>>>
>>>>>
>>>>> - We need to add:  LCQ Deca and LCQ Deca XP. Others are there.
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000169
>>>>>
>>>>> name: LCQ Deca XP Plus
>>>>>
>>>>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000168
>>>>>
>>>>> name: LCQ Classic
>>>>>
>>>>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000167
>>>>>
>>>>> name: LCQ Advantage
>>>>>
>>>>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>>
>>>>> - Add InstrumentSerialNumber as a term. We are not using
>>>>> InstrumentIdentifier because serial number is unique.
>>>>>
>>>>> Okay.
>>>>>
>>>>> - Add -FileFormatConversion as a term.
>>>>>
>>>>> Used, e.g., to describe how ReAdW converts RAW to dataXML
>>>>>
>>>>> - MaldiSpotIdentifier - sample spot, analyte spot or MALDIspot would
>>>>> be a better term.
>>>>>
>>>>>
>>>>> Terms whose definitions needs to be updated:
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000441
>>>>>
>>>>> name: Scan
>>>>>
>>>>> def: "A function of the mass spectrometer in which it employs the
>>>>> mass analyzer to generate the mass spectrum of a range of ions or a
>>>>> specific ion" [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000036
>>>>>
>>>>> name: Scan Mode
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_obsolete: true
>>>>>
>>>>> -DataArrayContentType
>>>>>
>>>>>
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000139
>>>>>
>>>>> name: 4000 Q TRAP
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX Q 4000 TRAP MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000140
>>>>>
>>>>> name: 4700 Proteomic Analyzer
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX 4700 Proteomic Analyzer MS"
>>>>> [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000141
>>>>>
>>>>> name: APEX IV
>>>>>
>>>>> def: "Bruker Daltonics APEX IV MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000142
>>>>>
>>>>> name: APEX-Q
>>>>>
>>>>> def: "Bruker Daltonics APEX-Q MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000143
>>>>>
>>>>> name: API 150EX
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX API 150EX MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000144
>>>>>
>>>>> name: API 150EX Prep
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX API 150EX Prep MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000145
>>>>>
>>>>> name: API 2000
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX API 2000 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000146
>>>>>
>>>>> name: API 3000
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX API 3000 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000147
>>>>>
>>>>> name: API 4000
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX API 4000 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000148
>>>>>
>>>>> name: autoFlex II
>>>>>
>>>>> def: "Bruker Daltonics autoFlex II MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000149
>>>>>
>>>>> name: autoFlex TOF/TOF
>>>>>
>>>>> def: "Bruker Daltonics autoFlex TOF/TOF MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000150
>>>>>
>>>>> name: Auto Spec Ultima NT
>>>>>
>>>>> def: "Waters AutoSpec Ultima NT MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000151
>>>>>
>>>>> name: Bio TOF II
>>>>>
>>>>> def: "Bruker Daltonics BioTOF II MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000152
>>>>>
>>>>> name: Bio TOF Q
>>>>>
>>>>> def: "Bruker Daltonics BioTOF Q MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000153
>>>>>
>>>>> name: DELTA plusAdvantage
>>>>>
>>>>> def: "ThermoFinnigan DELTAplusAdvantage MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000154
>>>>>
>>>>> name: DELTAplusXP
>>>>>
>>>>> def: "ThermoFinnigan DELTAplusXP MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000155
>>>>>
>>>>> name: ELEMENT2
>>>>>
>>>>> def: "ThermoFinnigan ELEMENT2 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000156
>>>>>
>>>>> name: esquire4000
>>>>>
>>>>> def: "Bruker Daltonics esquire4000 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000157
>>>>>
>>>>> name: esquire6000
>>>>>
>>>>> def: "Bruker Daltonics esquire6000 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000158
>>>>>
>>>>> name: Explorer
>>>>>
>>>>> def: "IonSpec Explorer MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000159
>>>>>
>>>>> name: GCT
>>>>>
>>>>> def: "Waters GCT MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000160
>>>>>
>>>>> name: HCT
>>>>>
>>>>> def: "Bruker Daltonics HCT MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000161
>>>>>
>>>>> name: HCT Plus
>>>>>
>>>>> def: "Bruker Daltonics HCTPlus MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000162
>>>>>
>>>>> name: HiRes ESI
>>>>>
>>>>> def: "IonSpec HiResESI MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000163
>>>>>
>>>>> name: HiRes MALDI
>>>>>
>>>>> def: "IonSpec HiResMALDI MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000164
>>>>>
>>>>> name: IsoPrime
>>>>>
>>>>> def: "Waters IsoPrime MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000165
>>>>>
>>>>> name: IsoProbe
>>>>>
>>>>> def: "Waters IsoProbe MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000166
>>>>>
>>>>> name: IsoProbe T
>>>>>
>>>>> def: "Waters IsoProbe T MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000167
>>>>>
>>>>> name: LCQ Advantage
>>>>>
>>>>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000168
>>>>>
>>>>> name: LCQ Classic
>>>>>
>>>>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000169
>>>>>
>>>>> name: LCQ Deca XP Plus
>>>>>
>>>>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000170
>>>>>
>>>>> name: M@LDI L
>>>>>
>>>>> def: "Waters M@LDI L MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000171
>>>>>
>>>>> name: M@LDI LR
>>>>>
>>>>> def: "Waters M@LDI LR MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000172
>>>>>
>>>>> name: MAT253
>>>>>
>>>>> def: "ThermoFinnigan MAT253 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000173
>>>>>
>>>>> name: MAT900XP
>>>>>
>>>>> def: "ThermoFinnigan MAT900XP MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000174
>>>>>
>>>>> name: MAT900XP Trap
>>>>>
>>>>> def: "ThermoFinnigan MAT900XP Trap MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000175
>>>>>
>>>>> name: MAT95XP
>>>>>
>>>>> def: "ThermoFinnigan MAT95XP MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000176
>>>>>
>>>>> name: MAT95XP Trap
>>>>>
>>>>> def: "ThermoFinnigan MAT95XP Trap MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000177
>>>>>
>>>>> name: microFlex
>>>>>
>>>>> def: "Bruker Daltonics microFlex MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000178
>>>>>
>>>>> name: microTOFLC
>>>>>
>>>>> def: "Bruker Daltonics microTOFLC MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000179
>>>>>
>>>>> name: Neptune
>>>>>
>>>>> def: "ThermoFinnigan NEPTUNE MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000180
>>>>>
>>>>> name: NG-5400
>>>>>
>>>>> def: "Waters NG-5400 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000181
>>>>>
>>>>> name: OMEGA
>>>>>
>>>>> def: "IonSpec OMEGA MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000182
>>>>>
>>>>> name: OMEGA-2001
>>>>>
>>>>> def: "IonSpec OMEGA-2001 MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000183
>>>>>
>>>>> name: OmniFlex
>>>>>
>>>>> def: "Bruker Daltonics OminFlex MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000184
>>>>>
>>>>> name: Platform ICP
>>>>>
>>>>> def: "Waters Platform ICP MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000185
>>>>>
>>>>> name: PolarisQ
>>>>>
>>>>> def: "ThermoFinnigan PolarisQ MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000186
>>>>>
>>>>> name: Proteomics Solution 1
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX Proteomics Solution 1 MS" 
>>>>> [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000187
>>>>>
>>>>> name: Q TRAP
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX Q TRAP MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000188
>>>>>
>>>>> name: Q-Tof micro
>>>>>
>>>>> def: "Waters Q-Tof micro MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000189
>>>>>
>>>>> name: Q-Tof Ultima
>>>>>
>>>>> def: "Waters Q-Tof Ultima MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000190
>>>>>
>>>>> name: QSTAR
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX QSTAR MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000191
>>>>>
>>>>> name: Quattro micro
>>>>>
>>>>> def: "Waters Quattro micro MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000192
>>>>>
>>>>> name: Quattro UItima
>>>>>
>>>>> def: "Waters Quattro Uitima MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000193
>>>>>
>>>>> name: Surveyor MSQ
>>>>>
>>>>> def: "ThermoFinnigan Surveyor MSQ MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000194
>>>>>
>>>>> name: SymBiot I
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX SymBiot I MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000195
>>>>>
>>>>> name: SymBiot XVI
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX SymBiot XVI MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000196
>>>>>
>>>>> name: TEMPUS TOF
>>>>>
>>>>> def: "ThermoFinnigan TEMPUS TOF MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000197
>>>>>
>>>>> name: TRACE DSQ
>>>>>
>>>>> def: "ThermoFinnigan TRACE DSQ MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000198
>>>>>
>>>>> name: TRITON
>>>>>
>>>>> def: "ThermoFinnigan TRITON MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000199
>>>>>
>>>>> name: TSQ QUANTUM
>>>>>
>>>>> def: "ThermoFinnigan TSQ QUANTUM MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000200
>>>>>
>>>>> name: Ultima
>>>>>
>>>>> def: "IonSpec Ultima MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000201
>>>>>
>>>>> name: ultraFlex
>>>>>
>>>>> def: "Bruker Daltonics ultraFlex MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000202
>>>>>
>>>>> name: ultraFlex TOF/TOF
>>>>>
>>>>> def: "Bruker Daltonics ultraFlex TOF/TOF MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000203
>>>>>
>>>>> name: Voyager-DE PRO
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX Voyager-DE PRO MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000204
>>>>>
>>>>> name: Voyager-DE STR
>>>>>
>>>>> def: "Applied Biosystems/MDS SCIEX Voyager-DE STR MS" [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000031 ! Model
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000441
>>>>>
>>>>> name: Scan
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000442
>>>>>
>>>>> name: Spectrum
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000443
>>>>>
>>>>> name: Mass Analyzer
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000444
>>>>>
>>>>> name: m/z Separation Method
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000445
>>>>>
>>>>> name: Sequential m/z Separation Method
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000036
>>>>>
>>>>> name: Scan Mode
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_obsolete: true
>>>>>
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000127
>>>>>
>>>>> name: Centroid Mass Spectrum
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000035 ! Peak Processing
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000128
>>>>>
>>>>> name: Continuum Mass Spectrum
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000035 ! Peak Processing
>>>>>
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000131
>>>>>
>>>>> name: Number Of Counts
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000043 ! Intensity Unit
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000132
>>>>>
>>>>> name: Percent Of Base Peak
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000043 ! Intensity Unit
>>>>>
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000138
>>>>>
>>>>> name: Percent
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> is_a: PSI:1000046 ! Energy Unit
>>>>>
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000441
>>>>>
>>>>> name: Scan
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000442
>>>>>
>>>>> name: Spectrum
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000443
>>>>>
>>>>> name: Mass Analyzer
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000444
>>>>>
>>>>> name: m/z Separation Method
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>> [Term]
>>>>>
>>>>> id: PSI:1000445
>>>>>
>>>>> name: Sequential m/z Separation Method
>>>>>
>>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>>
>>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>>
>>>>>
>>>>>
>>>>> Terms we decided not to add:
>>>>>
>>>>>
>>>>> - AnalyteIdentifier - same as Sample Name (PSI:1000002), and/or 
>>>>> Sample
>>>>>
>>>>> Number (PSI:1000001)
>>>>>
>>>>> - BasePeakMz - same as Base Peak, PSI:1000210
>>>>>
>>>>>
>>>>> - InstrumentIdentifier. Same as InstrumentSerialNumber.
>>>>>
>>>>>
>>>>> _____________________________________________
>>>>> *From:* Eric Deutsch
>>>>> *Sent:* Monday, April 16, 2007 8:05 PM
>>>>> *To:* 'Pierre-Alain Binz'; 'Trish Whetzel'; 'Puneet Souda';
>>>>> 'psi...@li...'
>>>>> *Cc:* Eric Deutsch
>>>>> *Subject:* RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>>>>>
>>>>> Hi everyone, this is a reminder of the conference call Tuesday, 9am
>>>>> PDT, 12n EDT, 4pm GMT. Agenda items are:
>>>>>
>>>>> - Review recent work on the CV (see attached list of items to
>>>>> discuss from Pete)
>>>>>
>>>>> - Discuss required preparation for next week
>>>>>
>>>>>  << File: PSI_TermsReview_Merge.txt >>
>>>>>
>>>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>>>>
>>>>> - Phone numbers:
>>>>>
>>>>>   + Germany: 08001012079
>>>>>
>>>>>   + Switzerland: 0800000860
>>>>>
>>>>>   + UK: 08081095644
>>>>>
>>>>>   + USA: 1-866-314-3683
>>>>>
>>>>>   + Generic international: +44 2083222500 (UK number)
>>>>>
>>>>> access code: 297427
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eric
>>>>>
>>>>> _____________________________________________
>>>>> *From:* Eric Deutsch
>>>>> *Sent:* Monday, April 09, 2007 1:07 AM
>>>>> *To:* 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent
>>>>> Laursen; psi...@li...
>>>>> *Cc:* Eric Deutsch
>>>>> *Subject:* PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>>>>>
>>>>> Hi everyone, here is a summary of the issues before us regarding
>>>>> dataXML. Please read it over and let's discuss at the conference
>>>>> call on Tuesday. Call information:
>>>>>
>>>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>>>>
>>>>> - Phone numbers:
>>>>>
>>>>>   + Germany: 08001012079
>>>>>
>>>>>   + Switzerland: 0800000860
>>>>>
>>>>>   + UK: 08081095644
>>>>>
>>>>>   + USA: 18663143683
>>>>>
>>>>>   + Generic international: +44 2083222500 (UK number)
>>>>>
>>>>> access code: 297427
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>>
>>>>> Open issues with dataXML
>>>>>
>>>>> - Need documentation of each element and attribute
>>>>>
>>>>>   Mike Coleman  2007-02-06
>>>>>
>>>>>   Agreed. Does Kent have some start of documentation from
>>>>> current/previous XMLSpy docs?
>>>>>
>>>>> Eric will contact Kent directly
>>>>>
>>>>> - Need more specifics on the desired numerical formats (e.g., IEEE,
>>>>> etc.)
>>>>>
>>>>>   Mike Coleman  2007-02-06
>>>>>
>>>>>   To be discussed in Lyon
>>>>>
>>>>> - Should there be "count" attributes?
>>>>>
>>>>>   Frederik Levander  2007-02-06
>>>>>
>>>>>   This is useful for some parsers. Probably leave in place. Discuss
>>>>> in Lyon
>>>>>
>>>>> - Should file index be within the file or in a separate file?
>>>>>
>>>>>   Frederik Levander  2007-02-06
>>>>>
>>>>>   The implementation of dataXML to be presented at Lyon will include
>>>>> this information in the same file. Further discussion deferred to
>>>>> the Lyon meeting The question was there: Should the file name /
>>>>> checksum information be held in a separate file?
>>>>>
>>>>> - Encoded filename should be element content instead of an
>>>>> attribute, so that CDATA could be used
>>>>>
>>>>>   Alex Masselot  2007-02-07
>>>>>
>>>>>   To be discussed in Lyon
>>>>>
>>>>> - Should controlled vocabulary term values also be element content
>>>>> instead of attribute so that CDATA could be used?
>>>>>
>>>>>   Alex Masselot  2007-02-07
>>>>>
>>>>>   To be discussed in Lyon
>>>>>
>>>>> - How will we handle multiple charges for parent peak, and
>>>>> fragmentation peaks?
>>>>>
>>>>>   Alex Masselot  2007-02-07
>>>>>
>>>>>   This is already handled -- mutliple cvParams of the same type can
>>>>> be used to annotate one peak / spectrum.
>>>>>
>>>>> - How can we allow two cv terms to be linked, such as concept with
>>>>> value and the associated units (a separate cv term). (e.g.
>>>>> "collision energy"=35.0 & "energy units"="joules")
>>>>>
>>>>>   Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
>>>>>
>>>>>   Phil to post to list for further responses
>>>>>
>>>>> Phil suggested 2 possibilities: <annotation> and additional 
>>>>> attributes
>>>>>
>>>>> Angel suggested doing the FuGE way. Maybe overkill? Difficult for
>>>>> software to handle?
>>>>>
>>>>> Do we really need having both or could we encode the units within
>>>>> the terms, e.g. "collision energy in joules"
>>>>>
>>>>> Most other relevant CVs don't seem to encode units as part of the 
>>>>> term
>>>>>
>>>>> Defer this to Lyon? Try to include the CV folks in a conference call
>>>>> during meeting
>>>>>
>>>>> Do we need to have specific types of relationships between linked
>>>>> terms, like "has_units"?
>>>>>
>>>>> - People still wrinkle their nose when hearing the "dataXML" name.
>>>>> We have a suggestion on the floor to rename to "mzDataXML".  
>>>>> Comments?
>>>>>
>>>>> - Make sure dataXML web site is up to date as can be
>>>>>
>>>>> - DONE Add link to XMLSpy-generated documentation at:
>>>>>
>>>>>
>>>>> _http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.html_ 
>>>>>
>>>>>
>>>>>
>>>>> - Get the indexing wrapper schema working properly
>>>>>
>>>>>   Jayson Falkner  2006-11-15
>>>>>
>>>>> - Make sure that Karl Klauser is invited to be involved
>>>>>
>>>>> Eric will send email.
>>>>>
>>>>> - Do we support properly the spectrum "library" use case?
>>>>>
>>>>>   Karl Klauser 2007-01-18
>>>>>
>>>>>   dataXML is supposed to be for MS instrument raw data, not
>>>>> interpreted data, i.e. with assignments. That is what analysisXML is
>>>>> intended for.
>>>>>
>>>>> Still open questions here. If analysisXML doesn't includes spectra,
>>>>> this would be tricky.
>>>>>
>>>>> - Examine the mapping with MIAPE. Do we support everything MIAPE
>>>>> requires?
>>>>>
>>>>>   Pierre-Alain Binz  2007-03-30
>>>>>
>>>>>   This will be addressed in Lyon
>>>>>
>>>>> - Revisit the chromatogram use case and develop a good example
>>>>>
>>>>>
>>>>> Controlled Vocabulary Issues:
>>>>>
>>>>> Trish sent out a new version of the CV this morning.
>>>>>
>>>>> New terms from Dave Horn added
>>>>>
>>>>> Will start keeping and posting release notes
>>>>>
>>>>> Pete should start working on this new version now
>>>>>
>>>>> Pete, Trish, and I will iterate on CV a little and there will be
>>>>> another ccall in 1 week exactly to discuss further
>>>>>
>>>>> We should post the OBO file soon on OBO.
>>>>>
>>>>> We will meet again in a week roughly, but Pete can't do next Tue 9am
>>>>>
>>>>> - DONE. Add hyperlink to the current CV on the web site
>>>>>
>>>>>   _http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo_
>>>>>
>>>>> - Should we change the ontology namespace to PSI-MS?
>>>>>
>>>>>   Trish Whetzel  2007-03-27
>>>>>
>>>>>   Was suggested in Washington already and we decided no?
>>>>>
>>>>> - What is the overlap/division between the PSI-MS CV, the main PSI
>>>>> CV, OBI?
>>>>>
>>>>>   Trish Whetzel, Luisa Montecchi  2007-03-30
>>>>>
>>>>>   To be sorted out in a special working session in Lyon?
>>>>>
>>>>> - Should we even have an InstrumentIdentifier (local to lab) term at
>>>>> all?
>>>>>
>>>>>   Trish Whetzel  2007-03-19
>>>>>
>>>>> - What is required from vendors?
>>>>>
>>>>>   Pierre-Alain  2007-04-03
>>>>>
>>>>> - How do we deal with the common PSI CV?
>>>>>
>>>>>   Pierre-Alain  2007-04-03
>>>>>
>>>>> - What is the overlap with OBO ontology "ProPreo"?
>>>>>
>>>>>   ProPreo: A comprehensive proteomics data and process provenance
>>>>> ontology
>>>>>
>>>>>   _http://lsdis.cs.uga.edu/projects/glycomics/propreo/_
>>>>>
>>>>>   Eric Deutsch  2007-04-03
>>>>>
>>>>> Trish says there was a quick review of this ~ 8 months ago
>>>>>
>>>>> ProPreo is broader but not deep enough
>>>>>
>>>>> - Try to reconcile the latest instance document and the current PSI
>>>>> ontology:
>>>>>
>>>>>   Trish Whetzel  2007-03-30
>>>>>
>>>>>   Eric Deutsch responded 2007-04-03
>>>>>
>>>>>   (full exchange not repro'ed here)
>>>>>
>>>>>   Pete or someone trying to resolve based on discussion thus far and
>>>>> identify unresolved?
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> This SF.net email is sponsored by DB2 Express
>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>> http://sourceforge.net/powerbar/db2/
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Psidev-ms-dev mailing list
>>>>> Psi...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>>
>>>
>>
>> -- 
>> -- 
>> Dr. Pierre-Alain Binz
>> Swiss Institute of Bioinformatics
>> Proteome Informatics Group
>> 1, Rue Michel Servet
>> CH-1211 Geneve 4
>> Switzerland
>> - - - - - - - - - - - - - - - - -
>> Tel: +41-22-379 50 50
>> Fax: +41-22-379 58 58
>> Pie...@is...
>> http://www.expasy.org/people/Pierre-Alain.Binz.html
>>
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

[Psidev-ms-dev] Separate binary file for very large data sets?

[<And...@an...>]

Hello everybody,

We develop software for imaging mass spectrometry in the framework of a 
project funded by the European Union. We intend to use dataXML as a 
standard format to exchange data between the different partner labs and 
also (as far as possible) as the internal data format for a joint 
processing software suite. However, we run into the problem of very 
large data sets which can easily exceed 1GB (e.g. 256
*256 pixels with one high resolution mass spectrum each). Therefore we 
thought about storing the spectrum data ('MassToChargeRatioArray' and ' 
'IntensityArray') in a separate binary file. This would make data 
handling much faster and easier (e.g. when parsing the XML file). So 
instead of writing the binary data in the XML file we plan to include a 
link to a separate file (file location, start and end position of 
spectrum in binary file).
This problem is somewhat similar to the already discussed issue of an 
index file.
Would it be possible to include such an option (external binary file) 
into the dataXML standard?

Best regards,
Andreas

-- 
-----------------------------------------------------------------------------------------
Dr. Andreas Roempp
Institute of Inorganic and Analytical Chemistry
- Analytical Chemistry -
Justus Liebig University Giessen
Schubertstrasse 60, Build. 16
D-35392 Giessen
Germany

phone:  +49-641-99 34802
fax:    +49-641-99 34809
email: And...@an...
Internet: http://www.uni-giessen.de/analytik/

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Trish W. <wh...@pc...>]

> we can make a ccall from the main room. So let's say we'll use the usual
> numbers and codes (the same as for the WG ccalls)
> Talk to you soon
Excellent - will that be for both days?

Trish


>> Both of those times are fine with me as well.
>>
>> Trish
>>
>>> I am fine with both timings. Lyon time is 9 hours ahead of PDT.
>>> Please let me know the conf call number and such.
>>>
>>> Have a good time in Lyon,
>>>
>>>
>>> Pete.
>>>
>>>
>>> Eric Deutsch wrote:
>>>>
>>>> Hi everyone, here is a summary of discussion on the CV at today's call:
>>>>
>>>> At the end of the call, we discussed the possibility of having Trish
>>>> and Pete (who cannot attended Lyon) (and possibly others) be on a
>>>> conference call for selected times during the meeting, specifically
>>>>
>>>> - Monday 4:30p -- 6:00p Lyon time for full CV session
>>>>
>>>> - Tuesday 5:00p -- 6:00p Lyon time for final MS CV discussion
>>>>
>>>> Can this be arranged at the Lyon facilities?
>>>>
>>>> Terms that need debate:
>>>>
>>>> - msLevel - The term appears as Precursor Ion Scan (PSI:1000100),
>>>> Product Ion Scan (PSI:1000101) and Nth Generation Product Ion
>>>> (PSI:1000337). What term should we use for ms 4th, ms 5th and such?
>>>> We have to keep precursor ion and product ion. Terms such as
>>>> daughter ion and parent ion are deprecated. We still use Fragment
>>>> ion though. These are some additional related terms that I could
>>>> find in the CV.
>>>>
>>>> Both mzXML and mzData had a "msLevel" **attribute**. The decision
>>>> was made to put msLevel as a CV term in dataXML.  However, if we add
>>>> msLevel, it appears there would be some redundancy with existing
>>>> terms in the CV (as above). Decide how to proceed in Lyon.
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000364
>>>>
>>>> name: Fragment Ion
>>>>
>>>> def: "A product ion resulting from the dissociation of a precursor
>>>> ion." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000365 ! Ion
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000344
>>>>
>>>> name: Progeny Ion
>>>>
>>>> def: "A charged product of a series of consecutive reactions that
>>>> includes product ions, 1st generation product ions, 2nd generation
>>>> product ions, etc. Given the sequential fragmentation scheme: M1+ ?
>>>> M2+ ? M3+ ? M4+ ? M5+ M4+ is the precursor ion of M5+, a 1st
>>>> generation product ion of M3+, a 2nd generation product ion of M2+
>>>> and a 3rd generation product ion of M1+. " [PSI:GPS]
>>>>
>>>> exact_synonym: "Progeny Fragment Ion" []
>>>>
>>>> is_a: PSI:1000365 ! Ion
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000342
>>>>
>>>> name: Product Ion
>>>>
>>>> def: "An ion formed as the product of a reaction involving a
>>>> particular precursor ion. The reaction can unimolecular
>>>> dissociation, an ion/molecule reaction, or involve simply a change
>>>> in the number of charges. The terms daughter ion and parent ion are
>>>> not recommended." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000365 ! Ion
>>>>
>>>>
>>>>
>>>> - mzRangeStart, mzRangeStop
>>>>
>>>> According to Eric it would be useful to have a start and stop rather
>>>> than a single mass range which can be confusing. I think we need all
>>>> three terms: mass range, mzRangeStart and mzRangeStop. Is there
>>>> anyway to do that?
>>>>
>>>> Keep them as attributes instead? Discuss more in Lyon. Both previous
>>>> formats had them as separate attributes, not CV terms.
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000313
>>>>
>>>> name: Mass Range
>>>>
>>>> def: "The limit of m/z over which a mass spectrometer can detect
>>>> ions." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000444 ! m/z Separation Method
>>>>
>>>>
>>>> - I dont know what is this term for?:
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000104
>>>>
>>>> name: None
>>>>
>>>> def: "None." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000021 ! Reflectron State
>>>>
>>>> History of this term unknown.  Maybe Randy knows? Eric will ask him.
>>>>
>>>> - Instrument Name
>>>>
>>>> i think Instrument name is same as model because Instrument's model
>>>> name is everything but the Vendor's name. Also, each instrument will
>>>> be defined, such as LTQ-FT LTQ Orbitrap. The definition of each
>>>> model would contain the vendor name. That means we are keeping Model
>>>> as it is and Instrument Name will not be used?
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000463
>>>>
>>>> name: Instrument
>>>>
>>>> def: "Device which performs a measurement." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000031
>>>>
>>>> name: Model
>>>>
>>>> def: "Instrument's model name (everything but the vendor's name)"
>>>> [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:1000454 ! Instrument Additional Description
>>>>
>>>> Use the term "InstrumentModel" and not "InstrumentName" or "Model"
>>>>
>>>> Maybe make new term "InstrumentModel" and deprecate "Model" and will
>>>> not use "InstrumentName"
>>>>
>>>> Bring up in Lyon, to find out what the recommendation is for tidying
>>>> up the ontology.
>>>>
>>>> - Should we replace all ThermoFinnigan with Thermo Fisher Scientific
>>>> because the company name has changed?
>>>>
>>>> Create a new vendor term "Thermo Fisher Scientific" instead of
>>>> renaming previous one.  The vendor for many existing years-old mass
>>>> specs was ThermoFinnigan at the time.  Maybe putting a date range in
>>>> the definitions would be helpful?
>>>>
>>>> - LowestMzValue - Is this within a spectrum or within a experiment.
>>>> A clear definition is needed.
>>>>
>>>> - HighestMzValue - Again what is the reference for this term. I have
>>>> to know what is it for in order                    to get a clear
>>>> definintion. Lowest and highest observed values in a spectrum. Used
>>>> by some software instead of opening up all spectra.
>>>>
>>>> - Scan Type - "Dictates the type of scan used to generate the
>>>> spectrum. Usually refers to the range but can also include linked,
>>>> precursor, product and neutral mass loss types of scan."
>>>>
>>>> What is the difference between Scan Type and Scan Mode?
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000036
>>>>
>>>> name: Scan Mode
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_obsolete: true
>>>>
>>>> Pete will research this more and report back.
>>>>
>>>> Try to get Trish and Pete to the Monday 4:30 -- 6:00, and maybe
>>>> Tuesday 5:00 -- 6:00p
>>>>
>>>> Lyon is currently GMT+2
>>>>
>>>> Encourage vendors to enter items via the term tracker including
>>>> definitions
>>>>
>>>> Eric will email Pierre-Alain and others about joining in on Monday,
>>>> Tuesday
>>>>
>>>> Terms to be added:
>>>>
>>>>
>>>> - We need to add:  LCQ Deca and LCQ Deca XP. Others are there.
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000169
>>>>
>>>> name: LCQ Deca XP Plus
>>>>
>>>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000168
>>>>
>>>> name: LCQ Classic
>>>>
>>>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000167
>>>>
>>>> name: LCQ Advantage
>>>>
>>>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>>
>>>> - Add InstrumentSerialNumber as a term. We are not using
>>>> InstrumentIdentifier because serial number is unique.
>>>>
>>>> Okay.
>>>>
>>>> - Add -FileFormatConversion as a term.
>>>>
>>>> Used, e.g., to describe how ReAdW converts RAW to dataXML
>>>>
>>>> - MaldiSpotIdentifier - sample spot, analyte spot or MALDIspot would
>>>> be a better term.
>>>>
>>>>
>>>> Terms whose definitions needs to be updated:
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000441
>>>>
>>>> name: Scan
>>>>
>>>> def: "A function of the mass spectrometer in which it employs the
>>>> mass analyzer to generate the mass spectrum of a range of ions or a
>>>> specific ion" [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000036
>>>>
>>>> name: Scan Mode
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_obsolete: true
>>>>
>>>> -DataArrayContentType
>>>>
>>>>
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000139
>>>>
>>>> name: 4000 Q TRAP
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX Q 4000 TRAP MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000140
>>>>
>>>> name: 4700 Proteomic Analyzer
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX 4700 Proteomic Analyzer MS"
>>>> [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000141
>>>>
>>>> name: APEX IV
>>>>
>>>> def: "Bruker Daltonics APEX IV MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000142
>>>>
>>>> name: APEX-Q
>>>>
>>>> def: "Bruker Daltonics APEX-Q MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000143
>>>>
>>>> name: API 150EX
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX API 150EX MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000144
>>>>
>>>> name: API 150EX Prep
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX API 150EX Prep MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000145
>>>>
>>>> name: API 2000
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX API 2000 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000146
>>>>
>>>> name: API 3000
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX API 3000 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000147
>>>>
>>>> name: API 4000
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX API 4000 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000148
>>>>
>>>> name: autoFlex II
>>>>
>>>> def: "Bruker Daltonics autoFlex II MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000149
>>>>
>>>> name: autoFlex TOF/TOF
>>>>
>>>> def: "Bruker Daltonics autoFlex TOF/TOF MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000150
>>>>
>>>> name: Auto Spec Ultima NT
>>>>
>>>> def: "Waters AutoSpec Ultima NT MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000151
>>>>
>>>> name: Bio TOF II
>>>>
>>>> def: "Bruker Daltonics BioTOF II MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000152
>>>>
>>>> name: Bio TOF Q
>>>>
>>>> def: "Bruker Daltonics BioTOF Q MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000153
>>>>
>>>> name: DELTA plusAdvantage
>>>>
>>>> def: "ThermoFinnigan DELTAplusAdvantage MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000154
>>>>
>>>> name: DELTAplusXP
>>>>
>>>> def: "ThermoFinnigan DELTAplusXP MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000155
>>>>
>>>> name: ELEMENT2
>>>>
>>>> def: "ThermoFinnigan ELEMENT2 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000156
>>>>
>>>> name: esquire4000
>>>>
>>>> def: "Bruker Daltonics esquire4000 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000157
>>>>
>>>> name: esquire6000
>>>>
>>>> def: "Bruker Daltonics esquire6000 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000158
>>>>
>>>> name: Explorer
>>>>
>>>> def: "IonSpec Explorer MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000159
>>>>
>>>> name: GCT
>>>>
>>>> def: "Waters GCT MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000160
>>>>
>>>> name: HCT
>>>>
>>>> def: "Bruker Daltonics HCT MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000161
>>>>
>>>> name: HCT Plus
>>>>
>>>> def: "Bruker Daltonics HCTPlus MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000162
>>>>
>>>> name: HiRes ESI
>>>>
>>>> def: "IonSpec HiResESI MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000163
>>>>
>>>> name: HiRes MALDI
>>>>
>>>> def: "IonSpec HiResMALDI MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000164
>>>>
>>>> name: IsoPrime
>>>>
>>>> def: "Waters IsoPrime MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000165
>>>>
>>>> name: IsoProbe
>>>>
>>>> def: "Waters IsoProbe MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000166
>>>>
>>>> name: IsoProbe T
>>>>
>>>> def: "Waters IsoProbe T MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000167
>>>>
>>>> name: LCQ Advantage
>>>>
>>>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000168
>>>>
>>>> name: LCQ Classic
>>>>
>>>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000169
>>>>
>>>> name: LCQ Deca XP Plus
>>>>
>>>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000170
>>>>
>>>> name: M@LDI L
>>>>
>>>> def: "Waters M@LDI L MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000171
>>>>
>>>> name: M@LDI LR
>>>>
>>>> def: "Waters M@LDI LR MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000172
>>>>
>>>> name: MAT253
>>>>
>>>> def: "ThermoFinnigan MAT253 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000173
>>>>
>>>> name: MAT900XP
>>>>
>>>> def: "ThermoFinnigan MAT900XP MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000174
>>>>
>>>> name: MAT900XP Trap
>>>>
>>>> def: "ThermoFinnigan MAT900XP Trap MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000175
>>>>
>>>> name: MAT95XP
>>>>
>>>> def: "ThermoFinnigan MAT95XP MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000176
>>>>
>>>> name: MAT95XP Trap
>>>>
>>>> def: "ThermoFinnigan MAT95XP Trap MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000177
>>>>
>>>> name: microFlex
>>>>
>>>> def: "Bruker Daltonics microFlex MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000178
>>>>
>>>> name: microTOFLC
>>>>
>>>> def: "Bruker Daltonics microTOFLC MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000179
>>>>
>>>> name: Neptune
>>>>
>>>> def: "ThermoFinnigan NEPTUNE MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000180
>>>>
>>>> name: NG-5400
>>>>
>>>> def: "Waters NG-5400 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000181
>>>>
>>>> name: OMEGA
>>>>
>>>> def: "IonSpec OMEGA MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000182
>>>>
>>>> name: OMEGA-2001
>>>>
>>>> def: "IonSpec OMEGA-2001 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000183
>>>>
>>>> name: OmniFlex
>>>>
>>>> def: "Bruker Daltonics OminFlex MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000184
>>>>
>>>> name: Platform ICP
>>>>
>>>> def: "Waters Platform ICP MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000185
>>>>
>>>> name: PolarisQ
>>>>
>>>> def: "ThermoFinnigan PolarisQ MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000186
>>>>
>>>> name: Proteomics Solution 1
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX Proteomics Solution 1 MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000187
>>>>
>>>> name: Q TRAP
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX Q TRAP MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000188
>>>>
>>>> name: Q-Tof micro
>>>>
>>>> def: "Waters Q-Tof micro MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000189
>>>>
>>>> name: Q-Tof Ultima
>>>>
>>>> def: "Waters Q-Tof Ultima MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000190
>>>>
>>>> name: QSTAR
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX QSTAR MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000191
>>>>
>>>> name: Quattro micro
>>>>
>>>> def: "Waters Quattro micro MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000192
>>>>
>>>> name: Quattro UItima
>>>>
>>>> def: "Waters Quattro Uitima MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000193
>>>>
>>>> name: Surveyor MSQ
>>>>
>>>> def: "ThermoFinnigan Surveyor MSQ MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000194
>>>>
>>>> name: SymBiot I
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX SymBiot I MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000195
>>>>
>>>> name: SymBiot XVI
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX SymBiot XVI MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000196
>>>>
>>>> name: TEMPUS TOF
>>>>
>>>> def: "ThermoFinnigan TEMPUS TOF MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000197
>>>>
>>>> name: TRACE DSQ
>>>>
>>>> def: "ThermoFinnigan TRACE DSQ MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000198
>>>>
>>>> name: TRITON
>>>>
>>>> def: "ThermoFinnigan TRITON MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000199
>>>>
>>>> name: TSQ QUANTUM
>>>>
>>>> def: "ThermoFinnigan TSQ QUANTUM MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000200
>>>>
>>>> name: Ultima
>>>>
>>>> def: "IonSpec Ultima MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000201
>>>>
>>>> name: ultraFlex
>>>>
>>>> def: "Bruker Daltonics ultraFlex MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000202
>>>>
>>>> name: ultraFlex TOF/TOF
>>>>
>>>> def: "Bruker Daltonics ultraFlex TOF/TOF MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000203
>>>>
>>>> name: Voyager-DE PRO
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX Voyager-DE PRO MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000204
>>>>
>>>> name: Voyager-DE STR
>>>>
>>>> def: "Applied Biosystems/MDS SCIEX Voyager-DE STR MS" [PSI:GPS]
>>>>
>>>> is_a: PSI:1000031 ! Model
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000441
>>>>
>>>> name: Scan
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000442
>>>>
>>>> name: Spectrum
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000443
>>>>
>>>> name: Mass Analyzer
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000444
>>>>
>>>> name: m/z Separation Method
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000445
>>>>
>>>> name: Sequential m/z Separation Method
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000036
>>>>
>>>> name: Scan Mode
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_obsolete: true
>>>>
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000127
>>>>
>>>> name: Centroid Mass Spectrum
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000035 ! Peak Processing
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000128
>>>>
>>>> name: Continuum Mass Spectrum
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000035 ! Peak Processing
>>>>
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000131
>>>>
>>>> name: Number Of Counts
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000043 ! Intensity Unit
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000132
>>>>
>>>> name: Percent Of Base Peak
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000043 ! Intensity Unit
>>>>
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000138
>>>>
>>>> name: Percent
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> is_a: PSI:1000046 ! Energy Unit
>>>>
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000441
>>>>
>>>> name: Scan
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000442
>>>>
>>>> name: Spectrum
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000443
>>>>
>>>> name: Mass Analyzer
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000444
>>>>
>>>> name: m/z Separation Method
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>> [Term]
>>>>
>>>> id: PSI:1000445
>>>>
>>>> name: Sequential m/z Separation Method
>>>>
>>>> def: "TODO: Add definition." [PSI:GPS]
>>>>
>>>> relationship: part_of PSI:0000000 ! mzOntology
>>>>
>>>>
>>>>
>>>> Terms we decided not to add:
>>>>
>>>>
>>>> - AnalyteIdentifier - same as Sample Name (PSI:1000002), and/or Sample
>>>>
>>>> Number (PSI:1000001)
>>>>
>>>> - BasePeakMz - same as Base Peak, PSI:1000210
>>>>
>>>>
>>>> - InstrumentIdentifier. Same as InstrumentSerialNumber.
>>>>
>>>>
>>>> _____________________________________________
>>>> *From:* Eric Deutsch
>>>> *Sent:* Monday, April 16, 2007 8:05 PM
>>>> *To:* 'Pierre-Alain Binz'; 'Trish Whetzel'; 'Puneet Souda';
>>>> 'psi...@li...'
>>>> *Cc:* Eric Deutsch
>>>> *Subject:* RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>>>>
>>>> Hi everyone, this is a reminder of the conference call Tuesday, 9am
>>>> PDT, 12n EDT, 4pm GMT. Agenda items are:
>>>>
>>>> - Review recent work on the CV (see attached list of items to
>>>> discuss from Pete)
>>>>
>>>> - Discuss required preparation for next week
>>>>
>>>>  << File: PSI_TermsReview_Merge.txt >>
>>>>
>>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>>>
>>>> - Phone numbers:
>>>>
>>>>   + Germany: 08001012079
>>>>
>>>>   + Switzerland: 0800000860
>>>>
>>>>   + UK: 08081095644
>>>>
>>>>   + USA: 1-866-314-3683
>>>>
>>>>   + Generic international: +44 2083222500 (UK number)
>>>>
>>>> access code: 297427
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>
>>>> _____________________________________________
>>>> *From:* Eric Deutsch
>>>> *Sent:* Monday, April 09, 2007 1:07 AM
>>>> *To:* 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent
>>>> Laursen; psi...@li...
>>>> *Cc:* Eric Deutsch
>>>> *Subject:* PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>>>>
>>>> Hi everyone, here is a summary of the issues before us regarding
>>>> dataXML. Please read it over and let's discuss at the conference
>>>> call on Tuesday. Call information:
>>>>
>>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>>>
>>>> - Phone numbers:
>>>>
>>>>   + Germany: 08001012079
>>>>
>>>>   + Switzerland: 0800000860
>>>>
>>>>   + UK: 08081095644
>>>>
>>>>   + USA: 18663143683
>>>>
>>>>   + Generic international: +44 2083222500 (UK number)
>>>>
>>>> access code: 297427
>>>>
>>>>
>>>> --------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Open issues with dataXML
>>>>
>>>> - Need documentation of each element and attribute
>>>>
>>>>   Mike Coleman  2007-02-06
>>>>
>>>>   Agreed. Does Kent have some start of documentation from
>>>> current/previous XMLSpy docs?
>>>>
>>>> Eric will contact Kent directly
>>>>
>>>> - Need more specifics on the desired numerical formats (e.g., IEEE,
>>>> etc.)
>>>>
>>>>   Mike Coleman  2007-02-06
>>>>
>>>>   To be discussed in Lyon
>>>>
>>>> - Should there be "count" attributes?
>>>>
>>>>   Frederik Levander  2007-02-06
>>>>
>>>>   This is useful for some parsers. Probably leave in place. Discuss
>>>> in Lyon
>>>>
>>>> - Should file index be within the file or in a separate file?
>>>>
>>>>   Frederik Levander  2007-02-06
>>>>
>>>>   The implementation of dataXML to be presented at Lyon will include
>>>> this information in the same file. Further discussion deferred to
>>>> the Lyon meeting The question was there: Should the file name /
>>>> checksum information be held in a separate file?
>>>>
>>>> - Encoded filename should be element content instead of an
>>>> attribute, so that CDATA could be used
>>>>
>>>>   Alex Masselot  2007-02-07
>>>>
>>>>   To be discussed in Lyon
>>>>
>>>> - Should controlled vocabulary term values also be element content
>>>> instead of attribute so that CDATA could be used?
>>>>
>>>>   Alex Masselot  2007-02-07
>>>>
>>>>   To be discussed in Lyon
>>>>
>>>> - How will we handle multiple charges for parent peak, and
>>>> fragmentation peaks?
>>>>
>>>>   Alex Masselot  2007-02-07
>>>>
>>>>   This is already handled -- mutliple cvParams of the same type can
>>>> be used to annotate one peak / spectrum.
>>>>
>>>> - How can we allow two cv terms to be linked, such as concept with
>>>> value and the associated units (a separate cv term). (e.g.
>>>> "collision energy"=35.0 & "energy units"="joules")
>>>>
>>>>   Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
>>>>
>>>>   Phil to post to list for further responses
>>>>
>>>> Phil suggested 2 possibilities: <annotation> and additional attributes
>>>>
>>>> Angel suggested doing the FuGE way. Maybe overkill? Difficult for
>>>> software to handle?
>>>>
>>>> Do we really need having both or could we encode the units within
>>>> the terms, e.g. "collision energy in joules"
>>>>
>>>> Most other relevant CVs don't seem to encode units as part of the term
>>>>
>>>> Defer this to Lyon? Try to include the CV folks in a conference call
>>>> during meeting
>>>>
>>>> Do we need to have specific types of relationships between linked
>>>> terms, like "has_units"?
>>>>
>>>> - People still wrinkle their nose when hearing the "dataXML" name.
>>>> We have a suggestion on the floor to rename to "mzDataXML".  Comments?
>>>>
>>>> - Make sure dataXML web site is up to date as can be
>>>>
>>>> - DONE Add link to XMLSpy-generated documentation at:
>>>>
>>>>
>>>> _http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.html_
>>>>
>>>>
>>>> - Get the indexing wrapper schema working properly
>>>>
>>>>   Jayson Falkner  2006-11-15
>>>>
>>>> - Make sure that Karl Klauser is invited to be involved
>>>>
>>>> Eric will send email.
>>>>
>>>> - Do we support properly the spectrum "library" use case?
>>>>
>>>>   Karl Klauser 2007-01-18
>>>>
>>>>   dataXML is supposed to be for MS instrument raw data, not
>>>> interpreted data, i.e. with assignments. That is what analysisXML is
>>>> intended for.
>>>>
>>>> Still open questions here. If analysisXML doesn't includes spectra,
>>>> this would be tricky.
>>>>
>>>> - Examine the mapping with MIAPE. Do we support everything MIAPE
>>>> requires?
>>>>
>>>>   Pierre-Alain Binz  2007-03-30
>>>>
>>>>   This will be addressed in Lyon
>>>>
>>>> - Revisit the chromatogram use case and develop a good example
>>>>
>>>>
>>>> Controlled Vocabulary Issues:
>>>>
>>>> Trish sent out a new version of the CV this morning.
>>>>
>>>> New terms from Dave Horn added
>>>>
>>>> Will start keeping and posting release notes
>>>>
>>>> Pete should start working on this new version now
>>>>
>>>> Pete, Trish, and I will iterate on CV a little and there will be
>>>> another ccall in 1 week exactly to discuss further
>>>>
>>>> We should post the OBO file soon on OBO.
>>>>
>>>> We will meet again in a week roughly, but Pete can't do next Tue 9am
>>>>
>>>> - DONE. Add hyperlink to the current CV on the web site
>>>>
>>>>   _http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo_
>>>>
>>>> - Should we change the ontology namespace to PSI-MS?
>>>>
>>>>   Trish Whetzel  2007-03-27
>>>>
>>>>   Was suggested in Washington already and we decided no?
>>>>
>>>> - What is the overlap/division between the PSI-MS CV, the main PSI
>>>> CV, OBI?
>>>>
>>>>   Trish Whetzel, Luisa Montecchi  2007-03-30
>>>>
>>>>   To be sorted out in a special working session in Lyon?
>>>>
>>>> - Should we even have an InstrumentIdentifier (local to lab) term at
>>>> all?
>>>>
>>>>   Trish Whetzel  2007-03-19
>>>>
>>>> - What is required from vendors?
>>>>
>>>>   Pierre-Alain  2007-04-03
>>>>
>>>> - How do we deal with the common PSI CV?
>>>>
>>>>   Pierre-Alain  2007-04-03
>>>>
>>>> - What is the overlap with OBO ontology "ProPreo"?
>>>>
>>>>   ProPreo: A comprehensive proteomics data and process provenance
>>>> ontology
>>>>
>>>>   _http://lsdis.cs.uga.edu/projects/glycomics/propreo/_
>>>>
>>>>   Eric Deutsch  2007-04-03
>>>>
>>>> Trish says there was a quick review of this ~ 8 months ago
>>>>
>>>> ProPreo is broader but not deep enough
>>>>
>>>> - Try to reconcile the latest instance document and the current PSI
>>>> ontology:
>>>>
>>>>   Trish Whetzel  2007-03-30
>>>>
>>>>   Eric Deutsch responded 2007-04-03
>>>>
>>>>   (full exchange not repro'ed here)
>>>>
>>>>   Pete or someone trying to resolve based on discussion thus far and
>>>> identify unresolved?
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>>
>>>> This SF.net email is sponsored by DB2 Express
>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>> control of your XML. No limits. Just data. Click to get it now.
>>>> http://sourceforge.net/powerbar/db2/
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Psidev-ms-dev mailing list
>>>> Psi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>
>>
>
> -- 
> --
> Dr. Pierre-Alain Binz
> Swiss Institute of Bioinformatics
> Proteome Informatics Group
> 1, Rue Michel Servet
> CH-1211 Geneve 4
> Switzerland
> - - - - - - - - - - - - - - - - -
> Tel: +41-22-379 50 50
> Fax: +41-22-379 58 58
> Pie...@is...
> http://www.expasy.org/people/Pierre-Alain.Binz.html
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Pierre-Alain B. <pie...@is...>]

Good,
we can make a ccall from the main room. So let's say we'll use the usual 
numbers and codes (the same as for the WG ccalls)
Talk to you soon

Pierre-Alain

Trish Whetzel wrote:
> Both of those times are fine with me as well.
>
> Trish
>
>> I am fine with both timings. Lyon time is 9 hours ahead of PDT. 
>> Please let me know the conf call number and such.
>>
>> Have a good time in Lyon,
>>
>>
>> Pete.
>>
>>
>> Eric Deutsch wrote:
>>>
>>> Hi everyone, here is a summary of discussion on the CV at today's call:
>>>
>>> At the end of the call, we discussed the possibility of having Trish 
>>> and Pete (who cannot attended Lyon) (and possibly others) be on a 
>>> conference call for selected times during the meeting, specifically
>>>
>>> - Monday 4:30p -- 6:00p Lyon time for full CV session
>>>
>>> - Tuesday 5:00p -- 6:00p Lyon time for final MS CV discussion
>>>
>>> Can this be arranged at the Lyon facilities?
>>>
>>> Terms that need debate:
>>>
>>> - msLevel - The term appears as Precursor Ion Scan (PSI:1000100),  
>>> Product Ion Scan (PSI:1000101) and Nth Generation Product Ion 
>>> (PSI:1000337). What term should we use for ms 4th, ms 5th and such? 
>>> We have to keep precursor ion and product ion. Terms such as  
>>> daughter ion and parent ion are deprecated. We still use Fragment 
>>> ion though. These are some additional related terms that I could 
>>> find in the CV.
>>>
>>> Both mzXML and mzData had a "msLevel" **attribute**. The decision 
>>> was made to put msLevel as a CV term in dataXML.  However, if we add 
>>> msLevel, it appears there would be some redundancy with existing 
>>> terms in the CV (as above). Decide how to proceed in Lyon.
>>>
>>> [Term]
>>>
>>> id: PSI:1000364
>>>
>>> name: Fragment Ion
>>>
>>> def: "A product ion resulting from the dissociation of a precursor 
>>> ion." [PSI:GPS]
>>>
>>> is_a: PSI:1000365 ! Ion
>>>
>>> [Term]
>>>
>>> id: PSI:1000344
>>>
>>> name: Progeny Ion
>>>
>>> def: "A charged product of a series of consecutive reactions that 
>>> includes product ions, 1st generation product ions, 2nd generation 
>>> product ions, etc. Given the sequential fragmentation scheme: M1+ ? 
>>> M2+ ? M3+ ? M4+ ? M5+ M4+ is the precursor ion of M5+, a 1st 
>>> generation product ion of M3+, a 2nd generation product ion of M2+ 
>>> and a 3rd generation product ion of M1+. " [PSI:GPS]
>>>
>>> exact_synonym: "Progeny Fragment Ion" []
>>>
>>> is_a: PSI:1000365 ! Ion
>>>
>>> [Term]
>>>
>>> id: PSI:1000342
>>>
>>> name: Product Ion
>>>
>>> def: "An ion formed as the product of a reaction involving a 
>>> particular precursor ion. The reaction can unimolecular 
>>> dissociation, an ion/molecule reaction, or involve simply a change 
>>> in the number of charges. The terms daughter ion and parent ion are 
>>> not recommended." [PSI:GPS]
>>>
>>> is_a: PSI:1000365 ! Ion
>>>
>>>
>>>
>>> - mzRangeStart, mzRangeStop
>>>
>>> According to Eric it would be useful to have a start and stop rather 
>>> than a single mass range which can be confusing. I think we need all 
>>> three terms: mass range, mzRangeStart and mzRangeStop. Is there 
>>> anyway to do that?
>>>
>>> Keep them as attributes instead? Discuss more in Lyon. Both previous 
>>> formats had them as separate attributes, not CV terms.
>>>
>>> [Term]
>>>
>>> id: PSI:1000313
>>>
>>> name: Mass Range
>>>
>>> def: "The limit of m/z over which a mass spectrometer can detect 
>>> ions." [PSI:GPS]
>>>
>>> is_a: PSI:1000444 ! m/z Separation Method
>>>
>>>
>>> - I dont know what is this term for?:
>>>
>>> [Term]
>>>
>>> id: PSI:1000104
>>>
>>> name: None
>>>
>>> def: "None." [PSI:GPS]
>>>
>>> is_a: PSI:1000021 ! Reflectron State
>>>
>>> History of this term unknown.  Maybe Randy knows? Eric will ask him.
>>>
>>> - Instrument Name
>>>
>>> i think Instrument name is same as model because Instrument's model 
>>> name is everything but the Vendor's name. Also, each instrument will 
>>> be defined, such as LTQ-FT LTQ Orbitrap. The definition of each 
>>> model would contain the vendor name. That means we are keeping Model 
>>> as it is and Instrument Name will not be used?
>>>
>>> [Term]
>>>
>>> id: PSI:1000463
>>>
>>> name: Instrument
>>>
>>> def: "Device which performs a measurement." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000031
>>>
>>> name: Model
>>>
>>> def: "Instrument's model name (everything but the vendor's name)" 
>>> [PSI:GPS]
>>>
>>> relationship: part_of PSI:1000454 ! Instrument Additional Description
>>>
>>> Use the term "InstrumentModel" and not "InstrumentName" or "Model"
>>>
>>> Maybe make new term "InstrumentModel" and deprecate "Model" and will 
>>> not use "InstrumentName"
>>>
>>> Bring up in Lyon, to find out what the recommendation is for tidying 
>>> up the ontology.
>>>
>>> - Should we replace all ThermoFinnigan with Thermo Fisher Scientific 
>>> because the company name has changed?
>>>
>>> Create a new vendor term "Thermo Fisher Scientific" instead of 
>>> renaming previous one.  The vendor for many existing years-old mass 
>>> specs was ThermoFinnigan at the time.  Maybe putting a date range in 
>>> the definitions would be helpful?
>>>
>>> - LowestMzValue - Is this within a spectrum or within a experiment. 
>>> A clear definition is needed.
>>>
>>> - HighestMzValue - Again what is the reference for this term. I have 
>>> to know what is it for in order                    to get a clear 
>>> definintion. Lowest and highest observed values in a spectrum. Used 
>>> by some software instead of opening up all spectra.
>>>
>>> - Scan Type - "Dictates the type of scan used to generate the 
>>> spectrum. Usually refers to the range but can also include linked, 
>>> precursor, product and neutral mass loss types of scan."
>>>
>>> What is the difference between Scan Type and Scan Mode?
>>>
>>> [Term]
>>>
>>> id: PSI:1000036
>>>
>>> name: Scan Mode
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_obsolete: true
>>>
>>> Pete will research this more and report back.
>>>
>>> Try to get Trish and Pete to the Monday 4:30 -- 6:00, and maybe 
>>> Tuesday 5:00 -- 6:00p
>>>
>>> Lyon is currently GMT+2
>>>
>>> Encourage vendors to enter items via the term tracker including 
>>> definitions
>>>
>>> Eric will email Pierre-Alain and others about joining in on Monday, 
>>> Tuesday
>>>
>>> Terms to be added:
>>>
>>>
>>> - We need to add:  LCQ Deca and LCQ Deca XP. Others are there.
>>>
>>> [Term]
>>>
>>> id: PSI:1000169
>>>
>>> name: LCQ Deca XP Plus
>>>
>>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000168
>>>
>>> name: LCQ Classic
>>>
>>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000167
>>>
>>> name: LCQ Advantage
>>>
>>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>>
>>> - Add InstrumentSerialNumber as a term. We are not using 
>>> InstrumentIdentifier because serial number is unique.
>>>
>>> Okay.
>>>
>>> - Add -FileFormatConversion as a term.
>>>
>>> Used, e.g., to describe how ReAdW converts RAW to dataXML
>>>
>>> - MaldiSpotIdentifier - sample spot, analyte spot or MALDIspot would 
>>> be a better term.
>>>
>>>
>>> Terms whose definitions needs to be updated:
>>>
>>> [Term]
>>>
>>> id: PSI:1000441
>>>
>>> name: Scan
>>>
>>> def: "A function of the mass spectrometer in which it employs the 
>>> mass analyzer to generate the mass spectrum of a range of ions or a 
>>> specific ion" [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000036
>>>
>>> name: Scan Mode
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_obsolete: true
>>>
>>> -DataArrayContentType
>>>
>>>
>>>
>>> [Term]
>>>
>>> id: PSI:1000139
>>>
>>> name: 4000 Q TRAP
>>>
>>> def: "Applied Biosystems/MDS SCIEX Q 4000 TRAP MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000140
>>>
>>> name: 4700 Proteomic Analyzer
>>>
>>> def: "Applied Biosystems/MDS SCIEX 4700 Proteomic Analyzer MS" 
>>> [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000141
>>>
>>> name: APEX IV
>>>
>>> def: "Bruker Daltonics APEX IV MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000142
>>>
>>> name: APEX-Q
>>>
>>> def: "Bruker Daltonics APEX-Q MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000143
>>>
>>> name: API 150EX
>>>
>>> def: "Applied Biosystems/MDS SCIEX API 150EX MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000144
>>>
>>> name: API 150EX Prep
>>>
>>> def: "Applied Biosystems/MDS SCIEX API 150EX Prep MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000145
>>>
>>> name: API 2000
>>>
>>> def: "Applied Biosystems/MDS SCIEX API 2000 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000146
>>>
>>> name: API 3000
>>>
>>> def: "Applied Biosystems/MDS SCIEX API 3000 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000147
>>>
>>> name: API 4000
>>>
>>> def: "Applied Biosystems/MDS SCIEX API 4000 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000148
>>>
>>> name: autoFlex II
>>>
>>> def: "Bruker Daltonics autoFlex II MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000149
>>>
>>> name: autoFlex TOF/TOF
>>>
>>> def: "Bruker Daltonics autoFlex TOF/TOF MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000150
>>>
>>> name: Auto Spec Ultima NT
>>>
>>> def: "Waters AutoSpec Ultima NT MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000151
>>>
>>> name: Bio TOF II
>>>
>>> def: "Bruker Daltonics BioTOF II MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000152
>>>
>>> name: Bio TOF Q
>>>
>>> def: "Bruker Daltonics BioTOF Q MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000153
>>>
>>> name: DELTA plusAdvantage
>>>
>>> def: "ThermoFinnigan DELTAplusAdvantage MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000154
>>>
>>> name: DELTAplusXP
>>>
>>> def: "ThermoFinnigan DELTAplusXP MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000155
>>>
>>> name: ELEMENT2
>>>
>>> def: "ThermoFinnigan ELEMENT2 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000156
>>>
>>> name: esquire4000
>>>
>>> def: "Bruker Daltonics esquire4000 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000157
>>>
>>> name: esquire6000
>>>
>>> def: "Bruker Daltonics esquire6000 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000158
>>>
>>> name: Explorer
>>>
>>> def: "IonSpec Explorer MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000159
>>>
>>> name: GCT
>>>
>>> def: "Waters GCT MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000160
>>>
>>> name: HCT
>>>
>>> def: "Bruker Daltonics HCT MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000161
>>>
>>> name: HCT Plus
>>>
>>> def: "Bruker Daltonics HCTPlus MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000162
>>>
>>> name: HiRes ESI
>>>
>>> def: "IonSpec HiResESI MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000163
>>>
>>> name: HiRes MALDI
>>>
>>> def: "IonSpec HiResMALDI MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000164
>>>
>>> name: IsoPrime
>>>
>>> def: "Waters IsoPrime MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000165
>>>
>>> name: IsoProbe
>>>
>>> def: "Waters IsoProbe MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000166
>>>
>>> name: IsoProbe T
>>>
>>> def: "Waters IsoProbe T MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000167
>>>
>>> name: LCQ Advantage
>>>
>>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000168
>>>
>>> name: LCQ Classic
>>>
>>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000169
>>>
>>> name: LCQ Deca XP Plus
>>>
>>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000170
>>>
>>> name: M@LDI L
>>>
>>> def: "Waters M@LDI L MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000171
>>>
>>> name: M@LDI LR
>>>
>>> def: "Waters M@LDI LR MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000172
>>>
>>> name: MAT253
>>>
>>> def: "ThermoFinnigan MAT253 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000173
>>>
>>> name: MAT900XP
>>>
>>> def: "ThermoFinnigan MAT900XP MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000174
>>>
>>> name: MAT900XP Trap
>>>
>>> def: "ThermoFinnigan MAT900XP Trap MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000175
>>>
>>> name: MAT95XP
>>>
>>> def: "ThermoFinnigan MAT95XP MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000176
>>>
>>> name: MAT95XP Trap
>>>
>>> def: "ThermoFinnigan MAT95XP Trap MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000177
>>>
>>> name: microFlex
>>>
>>> def: "Bruker Daltonics microFlex MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000178
>>>
>>> name: microTOFLC
>>>
>>> def: "Bruker Daltonics microTOFLC MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000179
>>>
>>> name: Neptune
>>>
>>> def: "ThermoFinnigan NEPTUNE MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000180
>>>
>>> name: NG-5400
>>>
>>> def: "Waters NG-5400 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000181
>>>
>>> name: OMEGA
>>>
>>> def: "IonSpec OMEGA MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000182
>>>
>>> name: OMEGA-2001
>>>
>>> def: "IonSpec OMEGA-2001 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000183
>>>
>>> name: OmniFlex
>>>
>>> def: "Bruker Daltonics OminFlex MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000184
>>>
>>> name: Platform ICP
>>>
>>> def: "Waters Platform ICP MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000185
>>>
>>> name: PolarisQ
>>>
>>> def: "ThermoFinnigan PolarisQ MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000186
>>>
>>> name: Proteomics Solution 1
>>>
>>> def: "Applied Biosystems/MDS SCIEX Proteomics Solution 1 MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000187
>>>
>>> name: Q TRAP
>>>
>>> def: "Applied Biosystems/MDS SCIEX Q TRAP MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000188
>>>
>>> name: Q-Tof micro
>>>
>>> def: "Waters Q-Tof micro MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000189
>>>
>>> name: Q-Tof Ultima
>>>
>>> def: "Waters Q-Tof Ultima MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000190
>>>
>>> name: QSTAR
>>>
>>> def: "Applied Biosystems/MDS SCIEX QSTAR MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000191
>>>
>>> name: Quattro micro
>>>
>>> def: "Waters Quattro micro MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000192
>>>
>>> name: Quattro UItima
>>>
>>> def: "Waters Quattro Uitima MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000193
>>>
>>> name: Surveyor MSQ
>>>
>>> def: "ThermoFinnigan Surveyor MSQ MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000194
>>>
>>> name: SymBiot I
>>>
>>> def: "Applied Biosystems/MDS SCIEX SymBiot I MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000195
>>>
>>> name: SymBiot XVI
>>>
>>> def: "Applied Biosystems/MDS SCIEX SymBiot XVI MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000196
>>>
>>> name: TEMPUS TOF
>>>
>>> def: "ThermoFinnigan TEMPUS TOF MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000197
>>>
>>> name: TRACE DSQ
>>>
>>> def: "ThermoFinnigan TRACE DSQ MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000198
>>>
>>> name: TRITON
>>>
>>> def: "ThermoFinnigan TRITON MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000199
>>>
>>> name: TSQ QUANTUM
>>>
>>> def: "ThermoFinnigan TSQ QUANTUM MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000200
>>>
>>> name: Ultima
>>>
>>> def: "IonSpec Ultima MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000201
>>>
>>> name: ultraFlex
>>>
>>> def: "Bruker Daltonics ultraFlex MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000202
>>>
>>> name: ultraFlex TOF/TOF
>>>
>>> def: "Bruker Daltonics ultraFlex TOF/TOF MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000203
>>>
>>> name: Voyager-DE PRO
>>>
>>> def: "Applied Biosystems/MDS SCIEX Voyager-DE PRO MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000204
>>>
>>> name: Voyager-DE STR
>>>
>>> def: "Applied Biosystems/MDS SCIEX Voyager-DE STR MS" [PSI:GPS]
>>>
>>> is_a: PSI:1000031 ! Model
>>>
>>> [Term]
>>>
>>> id: PSI:1000441
>>>
>>> name: Scan
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000442
>>>
>>> name: Spectrum
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000443
>>>
>>> name: Mass Analyzer
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000444
>>>
>>> name: m/z Separation Method
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000445
>>>
>>> name: Sequential m/z Separation Method
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000036
>>>
>>> name: Scan Mode
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_obsolete: true
>>>
>>>
>>> [Term]
>>>
>>> id: PSI:1000127
>>>
>>> name: Centroid Mass Spectrum
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_a: PSI:1000035 ! Peak Processing
>>>
>>> [Term]
>>>
>>> id: PSI:1000128
>>>
>>> name: Continuum Mass Spectrum
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_a: PSI:1000035 ! Peak Processing
>>>
>>>
>>> [Term]
>>>
>>> id: PSI:1000131
>>>
>>> name: Number Of Counts
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_a: PSI:1000043 ! Intensity Unit
>>>
>>> [Term]
>>>
>>> id: PSI:1000132
>>>
>>> name: Percent Of Base Peak
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_a: PSI:1000043 ! Intensity Unit
>>>
>>>
>>> [Term]
>>>
>>> id: PSI:1000138
>>>
>>> name: Percent
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> is_a: PSI:1000046 ! Energy Unit
>>>
>>>
>>> [Term]
>>>
>>> id: PSI:1000441
>>>
>>> name: Scan
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000442
>>>
>>> name: Spectrum
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>>
>>> [Term]
>>>
>>> id: PSI:1000443
>>>
>>> name: Mass Analyzer
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>>
>>> [Term]
>>>
>>> id: PSI:1000444
>>>
>>> name: m/z Separation Method
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>> [Term]
>>>
>>> id: PSI:1000445
>>>
>>> name: Sequential m/z Separation Method
>>>
>>> def: "TODO: Add definition." [PSI:GPS]
>>>
>>> relationship: part_of PSI:0000000 ! mzOntology
>>>
>>>
>>>
>>> Terms we decided not to add:
>>>
>>>
>>> - AnalyteIdentifier - same as Sample Name (PSI:1000002), and/or Sample
>>>
>>> Number (PSI:1000001)
>>>
>>> - BasePeakMz - same as Base Peak, PSI:1000210
>>>
>>>
>>> - InstrumentIdentifier. Same as InstrumentSerialNumber.
>>>
>>>
>>> _____________________________________________
>>> *From:* Eric Deutsch
>>> *Sent:* Monday, April 16, 2007 8:05 PM
>>> *To:* 'Pierre-Alain Binz'; 'Trish Whetzel'; 'Puneet Souda'; 
>>> 'psi...@li...'
>>> *Cc:* Eric Deutsch
>>> *Subject:* RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>>>
>>> Hi everyone, this is a reminder of the conference call Tuesday, 9am 
>>> PDT, 12n EDT, 4pm GMT. Agenda items are:
>>>
>>> - Review recent work on the CV (see attached list of items to 
>>> discuss from Pete)
>>>
>>> - Discuss required preparation for next week
>>>
>>>  << File: PSI_TermsReview_Merge.txt >>
>>>
>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>>
>>> - Phone numbers:
>>>
>>>   + Germany: 08001012079
>>>
>>>   + Switzerland: 0800000860
>>>
>>>   + UK: 08081095644
>>>
>>>   + USA: 1-866-314-3683
>>>
>>>   + Generic international: +44 2083222500 (UK number)
>>>
>>> access code: 297427
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>> _____________________________________________
>>> *From:* Eric Deutsch
>>> *Sent:* Monday, April 09, 2007 1:07 AM
>>> *To:* 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent 
>>> Laursen; psi...@li...
>>> *Cc:* Eric Deutsch
>>> *Subject:* PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>>>
>>> Hi everyone, here is a summary of the issues before us regarding 
>>> dataXML. Please read it over and let's discuss at the conference 
>>> call on Tuesday. Call information:
>>>
>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>>
>>> - Phone numbers:
>>>
>>>   + Germany: 08001012079
>>>
>>>   + Switzerland: 0800000860
>>>
>>>   + UK: 08081095644
>>>
>>>   + USA: 18663143683
>>>
>>>   + Generic international: +44 2083222500 (UK number)
>>>
>>> access code: 297427
>>>
>>>
>>> -------------------------------------------------------------------------------------------------- 
>>>
>>>
>>> Open issues with dataXML
>>>
>>> - Need documentation of each element and attribute
>>>
>>>   Mike Coleman  2007-02-06
>>>
>>>   Agreed. Does Kent have some start of documentation from 
>>> current/previous XMLSpy docs?
>>>
>>> Eric will contact Kent directly
>>>
>>> - Need more specifics on the desired numerical formats (e.g., IEEE, 
>>> etc.)
>>>
>>>   Mike Coleman  2007-02-06
>>>
>>>   To be discussed in Lyon
>>>
>>> - Should there be "count" attributes?
>>>
>>>   Frederik Levander  2007-02-06
>>>
>>>   This is useful for some parsers. Probably leave in place. Discuss 
>>> in Lyon
>>>
>>> - Should file index be within the file or in a separate file?
>>>
>>>   Frederik Levander  2007-02-06
>>>
>>>   The implementation of dataXML to be presented at Lyon will include 
>>> this information in the same file. Further discussion deferred to 
>>> the Lyon meeting The question was there: Should the file name / 
>>> checksum information be held in a separate file?
>>>
>>> - Encoded filename should be element content instead of an 
>>> attribute, so that CDATA could be used
>>>
>>>   Alex Masselot  2007-02-07
>>>
>>>   To be discussed in Lyon
>>>
>>> - Should controlled vocabulary term values also be element content 
>>> instead of attribute so that CDATA could be used?
>>>
>>>   Alex Masselot  2007-02-07
>>>
>>>   To be discussed in Lyon
>>>
>>> - How will we handle multiple charges for parent peak, and 
>>> fragmentation peaks?
>>>
>>>   Alex Masselot  2007-02-07
>>>
>>>   This is already handled -- mutliple cvParams of the same type can 
>>> be used to annotate one peak / spectrum.
>>>
>>> - How can we allow two cv terms to be linked, such as concept with 
>>> value and the associated units (a separate cv term). (e.g. 
>>> "collision energy"=35.0 & "energy units"="joules")
>>>
>>>   Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
>>>
>>>   Phil to post to list for further responses
>>>
>>> Phil suggested 2 possibilities: <annotation> and additional attributes
>>>
>>> Angel suggested doing the FuGE way. Maybe overkill? Difficult for 
>>> software to handle?
>>>
>>> Do we really need having both or could we encode the units within 
>>> the terms, e.g. "collision energy in joules"
>>>
>>> Most other relevant CVs don't seem to encode units as part of the term
>>>
>>> Defer this to Lyon? Try to include the CV folks in a conference call 
>>> during meeting
>>>
>>> Do we need to have specific types of relationships between linked 
>>> terms, like "has_units"?
>>>
>>> - People still wrinkle their nose when hearing the "dataXML" name.  
>>> We have a suggestion on the floor to rename to "mzDataXML".  Comments?
>>>
>>> - Make sure dataXML web site is up to date as can be
>>>
>>> - DONE Add link to XMLSpy-generated documentation at:
>>>
>>>   
>>> _http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.html_ 
>>>
>>>
>>> - Get the indexing wrapper schema working properly
>>>
>>>   Jayson Falkner  2006-11-15
>>>
>>> - Make sure that Karl Klauser is invited to be involved
>>>
>>> Eric will send email.
>>>
>>> - Do we support properly the spectrum "library" use case?
>>>
>>>   Karl Klauser 2007-01-18
>>>
>>>   dataXML is supposed to be for MS instrument raw data, not 
>>> interpreted data, i.e. with assignments. That is what analysisXML is 
>>> intended for.
>>>
>>> Still open questions here. If analysisXML doesn't includes spectra, 
>>> this would be tricky.
>>>
>>> - Examine the mapping with MIAPE. Do we support everything MIAPE 
>>> requires?
>>>
>>>   Pierre-Alain Binz  2007-03-30
>>>
>>>   This will be addressed in Lyon
>>>
>>> - Revisit the chromatogram use case and develop a good example
>>>
>>>
>>> Controlled Vocabulary Issues:
>>>
>>> Trish sent out a new version of the CV this morning.
>>>
>>> New terms from Dave Horn added
>>>
>>> Will start keeping and posting release notes
>>>
>>> Pete should start working on this new version now
>>>
>>> Pete, Trish, and I will iterate on CV a little and there will be 
>>> another ccall in 1 week exactly to discuss further
>>>
>>> We should post the OBO file soon on OBO.
>>>
>>> We will meet again in a week roughly, but Pete can't do next Tue 9am
>>>
>>> - DONE. Add hyperlink to the current CV on the web site
>>>
>>>   _http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo_
>>>
>>> - Should we change the ontology namespace to PSI-MS?
>>>
>>>   Trish Whetzel  2007-03-27
>>>
>>>   Was suggested in Washington already and we decided no?
>>>
>>> - What is the overlap/division between the PSI-MS CV, the main PSI 
>>> CV, OBI?
>>>
>>>   Trish Whetzel, Luisa Montecchi  2007-03-30
>>>
>>>   To be sorted out in a special working session in Lyon?
>>>
>>> - Should we even have an InstrumentIdentifier (local to lab) term at 
>>> all?
>>>
>>>   Trish Whetzel  2007-03-19
>>>
>>> - What is required from vendors?
>>>
>>>   Pierre-Alain  2007-04-03
>>>
>>> - How do we deal with the common PSI CV?
>>>
>>>   Pierre-Alain  2007-04-03
>>>
>>> - What is the overlap with OBO ontology "ProPreo"?
>>>
>>>   ProPreo: A comprehensive proteomics data and process provenance 
>>> ontology
>>>
>>>   _http://lsdis.cs.uga.edu/projects/glycomics/propreo/_
>>>
>>>   Eric Deutsch  2007-04-03
>>>
>>> Trish says there was a quick review of this ~ 8 months ago
>>>
>>> ProPreo is broader but not deep enough
>>>
>>> - Try to reconcile the latest instance document and the current PSI 
>>> ontology:
>>>
>>>   Trish Whetzel  2007-03-30
>>>
>>>   Eric Deutsch responded 2007-04-03
>>>
>>>   (full exchange not repro'ed here)
>>>
>>>   Pete or someone trying to resolve based on discussion thus far and 
>>> identify unresolved?
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2 express and take
>>> control of your XML. No limits. Just data. Click to get it now.
>>> http://sourceforge.net/powerbar/db2/
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Trish W. <wh...@pc...>]

Both of those times are fine with me as well.

Trish

> I am fine with both timings. Lyon time is 9 hours ahead of PDT. Please let me 
> know the conf call number and such.
>
> Have a good time in Lyon,
>
>
> Pete.
>
>
> Eric Deutsch wrote:
>> 
>> Hi everyone, here is a summary of discussion on the CV at today's call:
>> 
>> At the end of the call, we discussed the possibility of having Trish and 
>> Pete (who cannot attended Lyon) (and possibly others) be on a conference 
>> call for selected times during the meeting, specifically
>> 
>> - Monday 4:30p -- 6:00p Lyon time for full CV session
>> 
>> - Tuesday 5:00p -- 6:00p Lyon time for final MS CV discussion
>> 
>> Can this be arranged at the Lyon facilities?
>> 
>> Terms that need debate:
>> 
>> - msLevel - The term appears as Precursor Ion Scan (PSI:1000100),  Product 
>> Ion Scan (PSI:1000101) and Nth Generation Product Ion (PSI:1000337). What 
>> term should we use for ms 4th, ms 5th and such? We have to keep precursor 
>> ion and product ion. Terms such as  daughter ion and parent ion are 
>> deprecated. We still use Fragment ion though. These are some additional 
>> related terms that I could find in the CV.
>> 
>> Both mzXML and mzData had a "msLevel" **attribute**. The decision was made 
>> to put msLevel as a CV term in dataXML.  However, if we add msLevel, it 
>> appears there would be some redundancy with existing terms in the CV (as 
>> above). Decide how to proceed in Lyon.
>> 
>> [Term]
>> 
>> id: PSI:1000364
>> 
>> name: Fragment Ion
>> 
>> def: "A product ion resulting from the dissociation of a precursor ion." 
>> [PSI:GPS]
>> 
>> is_a: PSI:1000365 ! Ion
>> 
>> [Term]
>> 
>> id: PSI:1000344
>> 
>> name: Progeny Ion
>> 
>> def: "A charged product of a series of consecutive reactions that includes 
>> product ions, 1st generation product ions, 2nd generation product ions, 
>> etc. Given the sequential fragmentation scheme: M1+ ? M2+ ? M3+ ? M4+ ? M5+ 
>> M4+ is the precursor ion of M5+, a 1st generation product ion of M3+, a 2nd 
>> generation product ion of M2+ and a 3rd generation product ion of M1+. " 
>> [PSI:GPS]
>> 
>> exact_synonym: "Progeny Fragment Ion" []
>> 
>> is_a: PSI:1000365 ! Ion
>> 
>> [Term]
>> 
>> id: PSI:1000342
>> 
>> name: Product Ion
>> 
>> def: "An ion formed as the product of a reaction involving a particular 
>> precursor ion. The reaction can unimolecular dissociation, an ion/molecule 
>> reaction, or involve simply a change in the number of charges. The terms 
>> daughter ion and parent ion are not recommended." [PSI:GPS]
>> 
>> is_a: PSI:1000365 ! Ion
>> 
>> 
>> 
>> - mzRangeStart, mzRangeStop
>> 
>> According to Eric it would be useful to have a start and stop rather than a 
>> single mass range which can be confusing. I think we need all three terms: 
>> mass range, mzRangeStart and mzRangeStop. Is there anyway to do that?
>> 
>> Keep them as attributes instead? Discuss more in Lyon. Both previous 
>> formats had them as separate attributes, not CV terms.
>> 
>> [Term]
>> 
>> id: PSI:1000313
>> 
>> name: Mass Range
>> 
>> def: "The limit of m/z over which a mass spectrometer can detect ions." 
>> [PSI:GPS]
>> 
>> is_a: PSI:1000444 ! m/z Separation Method
>> 
>> 
>> - I dont know what is this term for?:
>> 
>> [Term]
>> 
>> id: PSI:1000104
>> 
>> name: None
>> 
>> def: "None." [PSI:GPS]
>> 
>> is_a: PSI:1000021 ! Reflectron State
>> 
>> History of this term unknown.  Maybe Randy knows? Eric will ask him.
>> 
>> - Instrument Name
>> 
>> i think Instrument name is same as model because Instrument's model name is 
>> everything but the Vendor's name. Also, each instrument will be defined, 
>> such as LTQ-FT LTQ Orbitrap. The definition of each model would contain the 
>> vendor name. That means we are keeping Model as it is and Instrument Name 
>> will not be used?
>> 
>> [Term]
>> 
>> id: PSI:1000463
>> 
>> name: Instrument
>> 
>> def: "Device which performs a measurement." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000031
>> 
>> name: Model
>> 
>> def: "Instrument's model name (everything but the vendor's name)" [PSI:GPS]
>> 
>> relationship: part_of PSI:1000454 ! Instrument Additional Description
>> 
>> Use the term "InstrumentModel" and not "InstrumentName" or "Model"
>> 
>> Maybe make new term "InstrumentModel" and deprecate "Model" and will not 
>> use "InstrumentName"
>> 
>> Bring up in Lyon, to find out what the recommendation is for tidying up the 
>> ontology.
>> 
>> - Should we replace all ThermoFinnigan with Thermo Fisher Scientific 
>> because the company name has changed?
>> 
>> Create a new vendor term "Thermo Fisher Scientific" instead of renaming 
>> previous one.  The vendor for many existing years-old mass specs was 
>> ThermoFinnigan at the time.  Maybe putting a date range in the definitions 
>> would be helpful?
>> 
>> - LowestMzValue - Is this within a spectrum or within a experiment. A clear 
>> definition is needed.
>> 
>> - HighestMzValue - Again what is the reference for this term. I have to 
>> know what is it for in order                    to get a clear definintion. 
>> Lowest and highest observed values in a spectrum. Used by some software 
>> instead of opening up all spectra.
>> 
>> - Scan Type - "Dictates the type of scan used to generate the spectrum. 
>> Usually refers to the range but can also include linked, precursor, product 
>> and neutral mass loss types of scan."
>> 
>> What is the difference between Scan Type and Scan Mode?
>> 
>> [Term]
>> 
>> id: PSI:1000036
>> 
>> name: Scan Mode
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_obsolete: true
>> 
>> Pete will research this more and report back.
>> 
>> Try to get Trish and Pete to the Monday 4:30 -- 6:00, and maybe Tuesday 
>> 5:00 -- 6:00p
>> 
>> Lyon is currently GMT+2
>> 
>> Encourage vendors to enter items via the term tracker including definitions
>> 
>> Eric will email Pierre-Alain and others about joining in on Monday, Tuesday
>> 
>> Terms to be added:
>> 
>> 
>> - We need to add:  LCQ Deca and LCQ Deca XP. Others are there.
>> 
>> [Term]
>> 
>> id: PSI:1000169
>> 
>> name: LCQ Deca XP Plus
>> 
>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000168
>> 
>> name: LCQ Classic
>> 
>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000167
>> 
>> name: LCQ Advantage
>> 
>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> 
>> - Add InstrumentSerialNumber as a term. We are not using 
>> InstrumentIdentifier because serial number is unique.
>> 
>> Okay.
>> 
>> - Add -FileFormatConversion as a term.
>> 
>> Used, e.g., to describe how ReAdW converts RAW to dataXML
>> 
>> - MaldiSpotIdentifier - sample spot, analyte spot or MALDIspot would be a 
>> better term.
>> 
>> 
>> Terms whose definitions needs to be updated:
>> 
>> [Term]
>> 
>> id: PSI:1000441
>> 
>> name: Scan
>> 
>> def: "A function of the mass spectrometer in which it employs the mass 
>> analyzer to generate the mass spectrum of a range of ions or a specific 
>> ion" [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000036
>> 
>> name: Scan Mode
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_obsolete: true
>> 
>> -DataArrayContentType
>> 
>> 
>> 
>> [Term]
>> 
>> id: PSI:1000139
>> 
>> name: 4000 Q TRAP
>> 
>> def: "Applied Biosystems/MDS SCIEX Q 4000 TRAP MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000140
>> 
>> name: 4700 Proteomic Analyzer
>> 
>> def: "Applied Biosystems/MDS SCIEX 4700 Proteomic Analyzer MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000141
>> 
>> name: APEX IV
>> 
>> def: "Bruker Daltonics APEX IV MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000142
>> 
>> name: APEX-Q
>> 
>> def: "Bruker Daltonics APEX-Q MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000143
>> 
>> name: API 150EX
>> 
>> def: "Applied Biosystems/MDS SCIEX API 150EX MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000144
>> 
>> name: API 150EX Prep
>> 
>> def: "Applied Biosystems/MDS SCIEX API 150EX Prep MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000145
>> 
>> name: API 2000
>> 
>> def: "Applied Biosystems/MDS SCIEX API 2000 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000146
>> 
>> name: API 3000
>> 
>> def: "Applied Biosystems/MDS SCIEX API 3000 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000147
>> 
>> name: API 4000
>> 
>> def: "Applied Biosystems/MDS SCIEX API 4000 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000148
>> 
>> name: autoFlex II
>> 
>> def: "Bruker Daltonics autoFlex II MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000149
>> 
>> name: autoFlex TOF/TOF
>> 
>> def: "Bruker Daltonics autoFlex TOF/TOF MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000150
>> 
>> name: Auto Spec Ultima NT
>> 
>> def: "Waters AutoSpec Ultima NT MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000151
>> 
>> name: Bio TOF II
>> 
>> def: "Bruker Daltonics BioTOF II MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000152
>> 
>> name: Bio TOF Q
>> 
>> def: "Bruker Daltonics BioTOF Q MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000153
>> 
>> name: DELTA plusAdvantage
>> 
>> def: "ThermoFinnigan DELTAplusAdvantage MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000154
>> 
>> name: DELTAplusXP
>> 
>> def: "ThermoFinnigan DELTAplusXP MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000155
>> 
>> name: ELEMENT2
>> 
>> def: "ThermoFinnigan ELEMENT2 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000156
>> 
>> name: esquire4000
>> 
>> def: "Bruker Daltonics esquire4000 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000157
>> 
>> name: esquire6000
>> 
>> def: "Bruker Daltonics esquire6000 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000158
>> 
>> name: Explorer
>> 
>> def: "IonSpec Explorer MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000159
>> 
>> name: GCT
>> 
>> def: "Waters GCT MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000160
>> 
>> name: HCT
>> 
>> def: "Bruker Daltonics HCT MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000161
>> 
>> name: HCT Plus
>> 
>> def: "Bruker Daltonics HCTPlus MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000162
>> 
>> name: HiRes ESI
>> 
>> def: "IonSpec HiResESI MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000163
>> 
>> name: HiRes MALDI
>> 
>> def: "IonSpec HiResMALDI MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000164
>> 
>> name: IsoPrime
>> 
>> def: "Waters IsoPrime MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000165
>> 
>> name: IsoProbe
>> 
>> def: "Waters IsoProbe MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000166
>> 
>> name: IsoProbe T
>> 
>> def: "Waters IsoProbe T MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000167
>> 
>> name: LCQ Advantage
>> 
>> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000168
>> 
>> name: LCQ Classic
>> 
>> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000169
>> 
>> name: LCQ Deca XP Plus
>> 
>> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000170
>> 
>> name: M@LDI L
>> 
>> def: "Waters M@LDI L MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000171
>> 
>> name: M@LDI LR
>> 
>> def: "Waters M@LDI LR MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000172
>> 
>> name: MAT253
>> 
>> def: "ThermoFinnigan MAT253 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000173
>> 
>> name: MAT900XP
>> 
>> def: "ThermoFinnigan MAT900XP MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000174
>> 
>> name: MAT900XP Trap
>> 
>> def: "ThermoFinnigan MAT900XP Trap MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000175
>> 
>> name: MAT95XP
>> 
>> def: "ThermoFinnigan MAT95XP MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000176
>> 
>> name: MAT95XP Trap
>> 
>> def: "ThermoFinnigan MAT95XP Trap MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000177
>> 
>> name: microFlex
>> 
>> def: "Bruker Daltonics microFlex MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000178
>> 
>> name: microTOFLC
>> 
>> def: "Bruker Daltonics microTOFLC MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000179
>> 
>> name: Neptune
>> 
>> def: "ThermoFinnigan NEPTUNE MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000180
>> 
>> name: NG-5400
>> 
>> def: "Waters NG-5400 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000181
>> 
>> name: OMEGA
>> 
>> def: "IonSpec OMEGA MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000182
>> 
>> name: OMEGA-2001
>> 
>> def: "IonSpec OMEGA-2001 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000183
>> 
>> name: OmniFlex
>> 
>> def: "Bruker Daltonics OminFlex MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000184
>> 
>> name: Platform ICP
>> 
>> def: "Waters Platform ICP MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000185
>> 
>> name: PolarisQ
>> 
>> def: "ThermoFinnigan PolarisQ MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000186
>> 
>> name: Proteomics Solution 1
>> 
>> def: "Applied Biosystems/MDS SCIEX Proteomics Solution 1 MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000187
>> 
>> name: Q TRAP
>> 
>> def: "Applied Biosystems/MDS SCIEX Q TRAP MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000188
>> 
>> name: Q-Tof micro
>> 
>> def: "Waters Q-Tof micro MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000189
>> 
>> name: Q-Tof Ultima
>> 
>> def: "Waters Q-Tof Ultima MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000190
>> 
>> name: QSTAR
>> 
>> def: "Applied Biosystems/MDS SCIEX QSTAR MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000191
>> 
>> name: Quattro micro
>> 
>> def: "Waters Quattro micro MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000192
>> 
>> name: Quattro UItima
>> 
>> def: "Waters Quattro Uitima MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000193
>> 
>> name: Surveyor MSQ
>> 
>> def: "ThermoFinnigan Surveyor MSQ MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000194
>> 
>> name: SymBiot I
>> 
>> def: "Applied Biosystems/MDS SCIEX SymBiot I MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000195
>> 
>> name: SymBiot XVI
>> 
>> def: "Applied Biosystems/MDS SCIEX SymBiot XVI MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000196
>> 
>> name: TEMPUS TOF
>> 
>> def: "ThermoFinnigan TEMPUS TOF MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000197
>> 
>> name: TRACE DSQ
>> 
>> def: "ThermoFinnigan TRACE DSQ MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000198
>> 
>> name: TRITON
>> 
>> def: "ThermoFinnigan TRITON MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000199
>> 
>> name: TSQ QUANTUM
>> 
>> def: "ThermoFinnigan TSQ QUANTUM MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000200
>> 
>> name: Ultima
>> 
>> def: "IonSpec Ultima MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000201
>> 
>> name: ultraFlex
>> 
>> def: "Bruker Daltonics ultraFlex MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000202
>> 
>> name: ultraFlex TOF/TOF
>> 
>> def: "Bruker Daltonics ultraFlex TOF/TOF MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000203
>> 
>> name: Voyager-DE PRO
>> 
>> def: "Applied Biosystems/MDS SCIEX Voyager-DE PRO MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000204
>> 
>> name: Voyager-DE STR
>> 
>> def: "Applied Biosystems/MDS SCIEX Voyager-DE STR MS" [PSI:GPS]
>> 
>> is_a: PSI:1000031 ! Model
>> 
>> [Term]
>> 
>> id: PSI:1000441
>> 
>> name: Scan
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000442
>> 
>> name: Spectrum
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000443
>> 
>> name: Mass Analyzer
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000444
>> 
>> name: m/z Separation Method
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000445
>> 
>> name: Sequential m/z Separation Method
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000036
>> 
>> name: Scan Mode
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_obsolete: true
>> 
>> 
>> [Term]
>> 
>> id: PSI:1000127
>> 
>> name: Centroid Mass Spectrum
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_a: PSI:1000035 ! Peak Processing
>> 
>> [Term]
>> 
>> id: PSI:1000128
>> 
>> name: Continuum Mass Spectrum
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_a: PSI:1000035 ! Peak Processing
>> 
>> 
>> [Term]
>> 
>> id: PSI:1000131
>> 
>> name: Number Of Counts
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_a: PSI:1000043 ! Intensity Unit
>> 
>> [Term]
>> 
>> id: PSI:1000132
>> 
>> name: Percent Of Base Peak
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_a: PSI:1000043 ! Intensity Unit
>> 
>> 
>> [Term]
>> 
>> id: PSI:1000138
>> 
>> name: Percent
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> is_a: PSI:1000046 ! Energy Unit
>> 
>> 
>> [Term]
>> 
>> id: PSI:1000441
>> 
>> name: Scan
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000442
>> 
>> name: Spectrum
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> 
>> [Term]
>> 
>> id: PSI:1000443
>> 
>> name: Mass Analyzer
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> 
>> [Term]
>> 
>> id: PSI:1000444
>> 
>> name: m/z Separation Method
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> [Term]
>> 
>> id: PSI:1000445
>> 
>> name: Sequential m/z Separation Method
>> 
>> def: "TODO: Add definition." [PSI:GPS]
>> 
>> relationship: part_of PSI:0000000 ! mzOntology
>> 
>> 
>> 
>> Terms we decided not to add:
>> 
>> 
>> - AnalyteIdentifier - same as Sample Name (PSI:1000002), and/or Sample
>> 
>> Number (PSI:1000001)
>> 
>> - BasePeakMz - same as Base Peak, PSI:1000210
>> 
>> 
>> - InstrumentIdentifier. Same as InstrumentSerialNumber.
>> 
>> 
>> _____________________________________________
>> *From:* Eric Deutsch
>> *Sent:* Monday, April 16, 2007 8:05 PM
>> *To:* 'Pierre-Alain Binz'; 'Trish Whetzel'; 'Puneet Souda'; 
>> 'psi...@li...'
>> *Cc:* Eric Deutsch
>> *Subject:* RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>> 
>> Hi everyone, this is a reminder of the conference call Tuesday, 9am PDT, 
>> 12n EDT, 4pm GMT. Agenda items are:
>> 
>> - Review recent work on the CV (see attached list of items to discuss from 
>> Pete)
>> 
>> - Discuss required preparation for next week
>> 
>>  << File: PSI_TermsReview_Merge.txt >>
>> 
>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>> 
>> - Phone numbers:
>> 
>>   + Germany: 08001012079
>> 
>>   + Switzerland: 0800000860
>> 
>>   + UK: 08081095644
>> 
>>   + USA: 1-866-314-3683
>> 
>>   + Generic international: +44 2083222500 (UK number)
>> 
>> access code: 297427
>> 
>> Thanks,
>> 
>> Eric
>> 
>> _____________________________________________
>> *From:* Eric Deutsch
>> *Sent:* Monday, April 09, 2007 1:07 AM
>> *To:* 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent Laursen; 
>> psi...@li...
>> *Cc:* Eric Deutsch
>> *Subject:* PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>> 
>> Hi everyone, here is a summary of the issues before us regarding dataXML. 
>> Please read it over and let's discuss at the conference call on Tuesday. 
>> Call information:
>> 
>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>> 
>> - Phone numbers:
>> 
>>   + Germany: 08001012079
>> 
>>   + Switzerland: 0800000860
>> 
>>   + UK: 08081095644
>> 
>>   + USA: 18663143683
>> 
>>   + Generic international: +44 2083222500 (UK number)
>> 
>> access code: 297427
>> 
>> 
>> --------------------------------------------------------------------------------------------------
>> 
>> Open issues with dataXML
>> 
>> - Need documentation of each element and attribute
>> 
>>   Mike Coleman  2007-02-06
>> 
>>   Agreed. Does Kent have some start of documentation from current/previous 
>> XMLSpy docs?
>> 
>> Eric will contact Kent directly
>> 
>> - Need more specifics on the desired numerical formats (e.g., IEEE, etc.)
>> 
>>   Mike Coleman  2007-02-06
>> 
>>   To be discussed in Lyon
>> 
>> - Should there be "count" attributes?
>> 
>>   Frederik Levander  2007-02-06
>> 
>>   This is useful for some parsers. Probably leave in place. Discuss in Lyon
>> 
>> - Should file index be within the file or in a separate file?
>> 
>>   Frederik Levander  2007-02-06
>> 
>>   The implementation of dataXML to be presented at Lyon will include this 
>> information in the same file. Further discussion deferred to the Lyon 
>> meeting The question was there: Should the file name / checksum information 
>> be held in a separate file?
>> 
>> - Encoded filename should be element content instead of an attribute, so 
>> that CDATA could be used
>> 
>>   Alex Masselot  2007-02-07
>> 
>>   To be discussed in Lyon
>> 
>> - Should controlled vocabulary term values also be element content instead 
>> of attribute so that CDATA could be used?
>> 
>>   Alex Masselot  2007-02-07
>> 
>>   To be discussed in Lyon
>> 
>> - How will we handle multiple charges for parent peak, and fragmentation 
>> peaks?
>> 
>>   Alex Masselot  2007-02-07
>> 
>>   This is already handled -- mutliple cvParams of the same type can be used 
>> to annotate one peak / spectrum.
>> 
>> - How can we allow two cv terms to be linked, such as concept with value 
>> and the associated units (a separate cv term). (e.g. "collision 
>> energy"=35.0 & "energy units"="joules")
>> 
>>   Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
>> 
>>   Phil to post to list for further responses
>> 
>> Phil suggested 2 possibilities: <annotation> and additional attributes
>> 
>> Angel suggested doing the FuGE way. Maybe overkill? Difficult for software 
>> to handle?
>> 
>> Do we really need having both or could we encode the units within the 
>> terms, e.g. "collision energy in joules"
>> 
>> Most other relevant CVs don't seem to encode units as part of the term
>> 
>> Defer this to Lyon? Try to include the CV folks in a conference call during 
>> meeting
>> 
>> Do we need to have specific types of relationships between linked terms, 
>> like "has_units"?
>> 
>> - People still wrinkle their nose when hearing the "dataXML" name.  We have 
>> a suggestion on the floor to rename to "mzDataXML".  Comments?
>> 
>> - Make sure dataXML web site is up to date as can be
>> 
>> - DONE Add link to XMLSpy-generated documentation at:
>> 
>>   _http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.html_
>> 
>> - Get the indexing wrapper schema working properly
>> 
>>   Jayson Falkner  2006-11-15
>> 
>> - Make sure that Karl Klauser is invited to be involved
>> 
>> Eric will send email.
>> 
>> - Do we support properly the spectrum "library" use case?
>> 
>>   Karl Klauser 2007-01-18
>> 
>>   dataXML is supposed to be for MS instrument raw data, not interpreted 
>> data, i.e. with assignments. That is what analysisXML is intended for.
>> 
>> Still open questions here. If analysisXML doesn't includes spectra, this 
>> would be tricky.
>> 
>> - Examine the mapping with MIAPE. Do we support everything MIAPE requires?
>> 
>>   Pierre-Alain Binz  2007-03-30
>> 
>>   This will be addressed in Lyon
>> 
>> - Revisit the chromatogram use case and develop a good example
>> 
>> 
>> Controlled Vocabulary Issues:
>> 
>> Trish sent out a new version of the CV this morning.
>> 
>> New terms from Dave Horn added
>> 
>> Will start keeping and posting release notes
>> 
>> Pete should start working on this new version now
>> 
>> Pete, Trish, and I will iterate on CV a little and there will be another 
>> ccall in 1 week exactly to discuss further
>> 
>> We should post the OBO file soon on OBO.
>> 
>> We will meet again in a week roughly, but Pete can't do next Tue 9am
>> 
>> - DONE. Add hyperlink to the current CV on the web site
>> 
>>   _http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo_
>> 
>> - Should we change the ontology namespace to PSI-MS?
>> 
>>   Trish Whetzel  2007-03-27
>> 
>>   Was suggested in Washington already and we decided no?
>> 
>> - What is the overlap/division between the PSI-MS CV, the main PSI CV, OBI?
>> 
>>   Trish Whetzel, Luisa Montecchi  2007-03-30
>> 
>>   To be sorted out in a special working session in Lyon?
>> 
>> - Should we even have an InstrumentIdentifier (local to lab) term at all?
>> 
>>   Trish Whetzel  2007-03-19
>> 
>> - What is required from vendors?
>> 
>>   Pierre-Alain  2007-04-03
>> 
>> - How do we deal with the common PSI CV?
>> 
>>   Pierre-Alain  2007-04-03
>> 
>> - What is the overlap with OBO ontology "ProPreo"?
>> 
>>   ProPreo: A comprehensive proteomics data and process provenance ontology
>> 
>>   _http://lsdis.cs.uga.edu/projects/glycomics/propreo/_
>> 
>>   Eric Deutsch  2007-04-03
>> 
>> Trish says there was a quick review of this ~ 8 months ago
>> 
>> ProPreo is broader but not deep enough
>> 
>> - Try to reconcile the latest instance document and the current PSI 
>> ontology:
>> 
>>   Trish Whetzel  2007-03-30
>> 
>>   Eric Deutsch responded 2007-04-03
>> 
>>   (full exchange not repro'ed here)
>> 
>>   Pete or someone trying to resolve based on discussion thus far and 
>> identify unresolved?
>> 
>> ------------------------------------------------------------------------
>> 
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Puneet S. <ps...@ch...>]

I am fine with both timings. Lyon time is 9 hours ahead of PDT. Please 
let me know the conf call number and such.

Have a good time in Lyon,


Pete.


Eric Deutsch wrote:
>
> Hi everyone, here is a summary of discussion on the CV at today's call:
>
> At the end of the call, we discussed the possibility of having Trish 
> and Pete (who cannot attended Lyon) (and possibly others) be on a 
> conference call for selected times during the meeting, specifically
>
> - Monday 4:30p -- 6:00p Lyon time for full CV session
>
> - Tuesday 5:00p -- 6:00p Lyon time for final MS CV discussion
>
> Can this be arranged at the Lyon facilities?
>
> Terms that need debate:
>
> - msLevel - The term appears as Precursor Ion Scan (PSI:1000100),  
> Product Ion Scan (PSI:1000101) and Nth Generation Product Ion 
> (PSI:1000337). What term should we use for ms 4th, ms 5th and such? We 
> have to keep precursor ion and product ion. Terms such as  daughter 
> ion and parent ion are deprecated. We still use Fragment ion though. 
> These are some additional related terms that I could find in the CV.
>
> Both mzXML and mzData had a "msLevel" **attribute**. The decision was 
> made to put msLevel as a CV term in dataXML.  However, if we add 
> msLevel, it appears there would be some redundancy with existing terms 
> in the CV (as above). Decide how to proceed in Lyon.
>
> [Term]
>
> id: PSI:1000364
>
> name: Fragment Ion
>
> def: "A product ion resulting from the dissociation of a precursor 
> ion." [PSI:GPS]
>
> is_a: PSI:1000365 ! Ion
>
> [Term]
>
> id: PSI:1000344
>
> name: Progeny Ion
>
> def: "A charged product of a series of consecutive reactions that 
> includes product ions, 1st generation product ions, 2nd generation 
> product ions, etc. Given the sequential fragmentation scheme: M1+ ? 
> M2+ ? M3+ ? M4+ ? M5+ M4+ is the precursor ion of M5+, a 1st 
> generation product ion of M3+, a 2nd generation product ion of M2+ and 
> a 3rd generation product ion of M1+. " [PSI:GPS]
>
> exact_synonym: "Progeny Fragment Ion" []
>
> is_a: PSI:1000365 ! Ion
>
> [Term]
>
> id: PSI:1000342
>
> name: Product Ion
>
> def: "An ion formed as the product of a reaction involving a 
> particular precursor ion. The reaction can unimolecular dissociation, 
> an ion/molecule reaction, or involve simply a change in the number of 
> charges. The terms daughter ion and parent ion are not recommended." 
> [PSI:GPS]
>
> is_a: PSI:1000365 ! Ion
>
>
>
> - mzRangeStart, mzRangeStop
>
> According to Eric it would be useful to have a start and stop rather 
> than a single mass range which can be confusing. I think we need all 
> three terms: mass range, mzRangeStart and mzRangeStop. Is there anyway 
> to do that?
>
> Keep them as attributes instead? Discuss more in Lyon. Both previous 
> formats had them as separate attributes, not CV terms.
>
> [Term]
>
> id: PSI:1000313
>
> name: Mass Range
>
> def: "The limit of m/z over which a mass spectrometer can detect 
> ions." [PSI:GPS]
>
> is_a: PSI:1000444 ! m/z Separation Method
>
>
> - I dont know what is this term for?:
>
> [Term]
>
> id: PSI:1000104
>
> name: None
>
> def: "None." [PSI:GPS]
>
> is_a: PSI:1000021 ! Reflectron State
>
> History of this term unknown.  Maybe Randy knows? Eric will ask him.
>
> - Instrument Name
>
> i think Instrument name is same as model because Instrument's model 
> name is everything but the Vendor's name. Also, each instrument will 
> be defined, such as LTQ-FT LTQ Orbitrap. The definition of each model 
> would contain the vendor name. That means we are keeping Model as it 
> is and Instrument Name will not be used?
>
> [Term]
>
> id: PSI:1000463
>
> name: Instrument
>
> def: "Device which performs a measurement." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000031
>
> name: Model
>
> def: "Instrument's model name (everything but the vendor's name)" 
> [PSI:GPS]
>
> relationship: part_of PSI:1000454 ! Instrument Additional Description
>
> Use the term "InstrumentModel" and not "InstrumentName" or "Model"
>
> Maybe make new term "InstrumentModel" and deprecate "Model" and will 
> not use "InstrumentName"
>
> Bring up in Lyon, to find out what the recommendation is for tidying 
> up the ontology.
>
> - Should we replace all ThermoFinnigan with Thermo Fisher Scientific 
> because the company name has changed?
>
> Create a new vendor term "Thermo Fisher Scientific" instead of 
> renaming previous one.  The vendor for many existing years-old mass 
> specs was ThermoFinnigan at the time.  Maybe putting a date range in 
> the definitions would be helpful?
>
> - LowestMzValue - Is this within a spectrum or within a experiment. A 
> clear definition is needed.
>
> - HighestMzValue - Again what is the reference for this term. I have 
> to know what is it for in order                    to get a clear 
> definintion. 
>
> Lowest and highest observed values in a spectrum. Used by some 
> software instead of opening up all spectra.
>
> - Scan Type - "Dictates the type of scan used to generate the 
> spectrum. Usually refers to the range but can also include linked, 
> precursor, product and neutral mass loss types of scan."
>
> What is the difference between Scan Type and Scan Mode?
>
> [Term]
>
> id: PSI:1000036
>
> name: Scan Mode
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_obsolete: true
>
> Pete will research this more and report back.
>
> Try to get Trish and Pete to the Monday 4:30 -- 6:00, and maybe 
> Tuesday 5:00 -- 6:00p
>
> Lyon is currently GMT+2
>
> Encourage vendors to enter items via the term tracker including 
> definitions
>
> Eric will email Pierre-Alain and others about joining in on Monday, 
> Tuesday
>
> Terms to be added:
>
>
> - We need to add:  LCQ Deca and LCQ Deca XP. Others are there.
>
> [Term]
>
> id: PSI:1000169
>
> name: LCQ Deca XP Plus
>
> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000168
>
> name: LCQ Classic
>
> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000167
>
> name: LCQ Advantage
>
> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
>
> - Add InstrumentSerialNumber as a term. We are not using 
> InstrumentIdentifier because serial number is unique.
>
> Okay.
>
> - Add -FileFormatConversion as a term.
>
> Used, e.g., to describe how ReAdW converts RAW to dataXML
>
> - MaldiSpotIdentifier - sample spot, analyte spot or MALDIspot would 
> be a better term.
>
>
> Terms whose definitions needs to be updated:
>
> [Term]
>
> id: PSI:1000441
>
> name: Scan
>
> def: "A function of the mass spectrometer in which it employs the mass 
> analyzer to generate the mass spectrum of a range of ions or a 
> specific ion" [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000036
>
> name: Scan Mode
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_obsolete: true
>
> -DataArrayContentType
>
>
>
> [Term]
>
> id: PSI:1000139
>
> name: 4000 Q TRAP
>
> def: "Applied Biosystems/MDS SCIEX Q 4000 TRAP MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000140
>
> name: 4700 Proteomic Analyzer
>
> def: "Applied Biosystems/MDS SCIEX 4700 Proteomic Analyzer MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000141
>
> name: APEX IV
>
> def: "Bruker Daltonics APEX IV MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000142
>
> name: APEX-Q
>
> def: "Bruker Daltonics APEX-Q MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000143
>
> name: API 150EX
>
> def: "Applied Biosystems/MDS SCIEX API 150EX MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000144
>
> name: API 150EX Prep
>
> def: "Applied Biosystems/MDS SCIEX API 150EX Prep MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000145
>
> name: API 2000
>
> def: "Applied Biosystems/MDS SCIEX API 2000 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000146
>
> name: API 3000
>
> def: "Applied Biosystems/MDS SCIEX API 3000 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000147
>
> name: API 4000
>
> def: "Applied Biosystems/MDS SCIEX API 4000 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000148
>
> name: autoFlex II
>
> def: "Bruker Daltonics autoFlex II MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000149
>
> name: autoFlex TOF/TOF
>
> def: "Bruker Daltonics autoFlex TOF/TOF MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000150
>
> name: Auto Spec Ultima NT
>
> def: "Waters AutoSpec Ultima NT MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000151
>
> name: Bio TOF II
>
> def: "Bruker Daltonics BioTOF II MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000152
>
> name: Bio TOF Q
>
> def: "Bruker Daltonics BioTOF Q MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000153
>
> name: DELTA plusAdvantage
>
> def: "ThermoFinnigan DELTAplusAdvantage MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000154
>
> name: DELTAplusXP
>
> def: "ThermoFinnigan DELTAplusXP MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000155
>
> name: ELEMENT2
>
> def: "ThermoFinnigan ELEMENT2 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000156
>
> name: esquire4000
>
> def: "Bruker Daltonics esquire4000 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000157
>
> name: esquire6000
>
> def: "Bruker Daltonics esquire6000 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000158
>
> name: Explorer
>
> def: "IonSpec Explorer MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000159
>
> name: GCT
>
> def: "Waters GCT MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000160
>
> name: HCT
>
> def: "Bruker Daltonics HCT MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000161
>
> name: HCT Plus
>
> def: "Bruker Daltonics HCTPlus MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000162
>
> name: HiRes ESI
>
> def: "IonSpec HiResESI MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000163
>
> name: HiRes MALDI
>
> def: "IonSpec HiResMALDI MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000164
>
> name: IsoPrime
>
> def: "Waters IsoPrime MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000165
>
> name: IsoProbe
>
> def: "Waters IsoProbe MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000166
>
> name: IsoProbe T
>
> def: "Waters IsoProbe T MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000167
>
> name: LCQ Advantage
>
> def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000168
>
> name: LCQ Classic
>
> def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000169
>
> name: LCQ Deca XP Plus
>
> def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000170
>
> name: M@LDI L
>
> def: "Waters M@LDI L MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000171
>
> name: M@LDI LR
>
> def: "Waters M@LDI LR MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000172
>
> name: MAT253
>
> def: "ThermoFinnigan MAT253 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000173
>
> name: MAT900XP
>
> def: "ThermoFinnigan MAT900XP MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000174
>
> name: MAT900XP Trap
>
> def: "ThermoFinnigan MAT900XP Trap MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000175
>
> name: MAT95XP
>
> def: "ThermoFinnigan MAT95XP MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000176
>
> name: MAT95XP Trap
>
> def: "ThermoFinnigan MAT95XP Trap MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000177
>
> name: microFlex
>
> def: "Bruker Daltonics microFlex MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000178
>
> name: microTOFLC
>
> def: "Bruker Daltonics microTOFLC MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000179
>
> name: Neptune
>
> def: "ThermoFinnigan NEPTUNE MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000180
>
> name: NG-5400
>
> def: "Waters NG-5400 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000181
>
> name: OMEGA
>
> def: "IonSpec OMEGA MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000182
>
> name: OMEGA-2001
>
> def: "IonSpec OMEGA-2001 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000183
>
> name: OmniFlex
>
> def: "Bruker Daltonics OminFlex MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000184
>
> name: Platform ICP
>
> def: "Waters Platform ICP MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000185
>
> name: PolarisQ
>
> def: "ThermoFinnigan PolarisQ MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000186
>
> name: Proteomics Solution 1
>
> def: "Applied Biosystems/MDS SCIEX Proteomics Solution 1 MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000187
>
> name: Q TRAP
>
> def: "Applied Biosystems/MDS SCIEX Q TRAP MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000188
>
> name: Q-Tof micro
>
> def: "Waters Q-Tof micro MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000189
>
> name: Q-Tof Ultima
>
> def: "Waters Q-Tof Ultima MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000190
>
> name: QSTAR
>
> def: "Applied Biosystems/MDS SCIEX QSTAR MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000191
>
> name: Quattro micro
>
> def: "Waters Quattro micro MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000192
>
> name: Quattro UItima
>
> def: "Waters Quattro Uitima MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000193
>
> name: Surveyor MSQ
>
> def: "ThermoFinnigan Surveyor MSQ MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000194
>
> name: SymBiot I
>
> def: "Applied Biosystems/MDS SCIEX SymBiot I MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000195
>
> name: SymBiot XVI
>
> def: "Applied Biosystems/MDS SCIEX SymBiot XVI MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000196
>
> name: TEMPUS TOF
>
> def: "ThermoFinnigan TEMPUS TOF MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000197
>
> name: TRACE DSQ
>
> def: "ThermoFinnigan TRACE DSQ MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000198
>
> name: TRITON
>
> def: "ThermoFinnigan TRITON MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000199
>
> name: TSQ QUANTUM
>
> def: "ThermoFinnigan TSQ QUANTUM MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000200
>
> name: Ultima
>
> def: "IonSpec Ultima MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000201
>
> name: ultraFlex
>
> def: "Bruker Daltonics ultraFlex MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000202
>
> name: ultraFlex TOF/TOF
>
> def: "Bruker Daltonics ultraFlex TOF/TOF MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000203
>
> name: Voyager-DE PRO
>
> def: "Applied Biosystems/MDS SCIEX Voyager-DE PRO MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000204
>
> name: Voyager-DE STR
>
> def: "Applied Biosystems/MDS SCIEX Voyager-DE STR MS" [PSI:GPS]
>
> is_a: PSI:1000031 ! Model
>
> [Term]
>
> id: PSI:1000441
>
> name: Scan
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000442
>
> name: Spectrum
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000443
>
> name: Mass Analyzer
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000444
>
> name: m/z Separation Method
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000445
>
> name: Sequential m/z Separation Method
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000036
>
> name: Scan Mode
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_obsolete: true
>
>
> [Term]
>
> id: PSI:1000127
>
> name: Centroid Mass Spectrum
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_a: PSI:1000035 ! Peak Processing
>
> [Term]
>
> id: PSI:1000128
>
> name: Continuum Mass Spectrum
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_a: PSI:1000035 ! Peak Processing
>
>
> [Term]
>
> id: PSI:1000131
>
> name: Number Of Counts
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_a: PSI:1000043 ! Intensity Unit
>
> [Term]
>
> id: PSI:1000132
>
> name: Percent Of Base Peak
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_a: PSI:1000043 ! Intensity Unit
>
>
> [Term]
>
> id: PSI:1000138
>
> name: Percent
>
> def: "TODO: Add definition." [PSI:GPS]
>
> is_a: PSI:1000046 ! Energy Unit
>
>
> [Term]
>
> id: PSI:1000441
>
> name: Scan
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000442
>
> name: Spectrum
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
>
> [Term]
>
> id: PSI:1000443
>
> name: Mass Analyzer
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
>
> [Term]
>
> id: PSI:1000444
>
> name: m/z Separation Method
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
> [Term]
>
> id: PSI:1000445
>
> name: Sequential m/z Separation Method
>
> def: "TODO: Add definition." [PSI:GPS]
>
> relationship: part_of PSI:0000000 ! mzOntology
>
>
>
> Terms we decided not to add:
>
>
> - AnalyteIdentifier - same as Sample Name (PSI:1000002), and/or Sample
>
> Number (PSI:1000001)
>
> - BasePeakMz - same as Base Peak, PSI:1000210
>
>
> - InstrumentIdentifier. Same as InstrumentSerialNumber.
>
>
> _____________________________________________
> *From:* Eric Deutsch
> *Sent:* Monday, April 16, 2007 8:05 PM
> *To:* 'Pierre-Alain Binz'; 'Trish Whetzel'; 'Puneet Souda'; 
> 'psi...@li...'
> *Cc:* Eric Deutsch
> *Subject:* RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>
> Hi everyone, this is a reminder of the conference call Tuesday, 9am 
> PDT, 12n EDT, 4pm GMT. Agenda items are:
>
> - Review recent work on the CV (see attached list of items to discuss 
> from Pete)
>
> - Discuss required preparation for next week
>
>  << File: PSI_TermsReview_Merge.txt >>
>
> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>
> - Phone numbers:
>
>   + Germany: 08001012079
>
>   + Switzerland: 0800000860
>
>   + UK: 08081095644
>
>   + USA: 1-866-314-3683
>
>   + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
> Thanks,
>
> Eric
>
> _____________________________________________
> *From:* Eric Deutsch
> *Sent:* Monday, April 09, 2007 1:07 AM
> *To:* 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent Laursen; 
> psi...@li...
> *Cc:* Eric Deutsch
> *Subject:* PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>
> Hi everyone, here is a summary of the issues before us regarding 
> dataXML.  Please read it over and let's discuss at the conference call 
> on Tuesday. Call information:
>
> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>
> - Phone numbers:
>
>   + Germany: 08001012079
>
>   + Switzerland: 0800000860
>
>   + UK: 08081095644
>
>   + USA: 18663143683
>
>   + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
> --------------------------------------------------------------------------------------------------
>
> Open issues with dataXML
>
> - Need documentation of each element and attribute
>
>   Mike Coleman  2007-02-06
>
>   Agreed. Does Kent have some start of documentation from 
> current/previous XMLSpy docs?
>
> Eric will contact Kent directly
>
> - Need more specifics on the desired numerical formats (e.g., IEEE, etc.)
>
>   Mike Coleman  2007-02-06
>
>   To be discussed in Lyon
>
> - Should there be "count" attributes?
>
>   Frederik Levander  2007-02-06
>
>   This is useful for some parsers. Probably leave in place. Discuss in 
> Lyon
>
> - Should file index be within the file or in a separate file?
>
>   Frederik Levander  2007-02-06
>
>   The implementation of dataXML to be presented at Lyon will include 
> this information in the same file. Further discussion deferred to the 
> Lyon meeting The question was there: Should the file name / checksum 
> information be held in a separate file?
>
> - Encoded filename should be element content instead of an attribute, 
> so that CDATA could be used
>
>   Alex Masselot  2007-02-07
>
>   To be discussed in Lyon
>
> - Should controlled vocabulary term values also be element content 
> instead of attribute so that CDATA could be used?
>
>   Alex Masselot  2007-02-07
>
>   To be discussed in Lyon
>
> - How will we handle multiple charges for parent peak, and 
> fragmentation peaks?
>
>   Alex Masselot  2007-02-07
>
>   This is already handled -- mutliple cvParams of the same type can be 
> used to annotate one peak / spectrum.
>
> - How can we allow two cv terms to be linked, such as concept with 
> value and the associated units (a separate cv term). (e.g. "collision 
> energy"=35.0 & "energy units"="joules")
>
>   Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
>
>   Phil to post to list for further responses
>
> Phil suggested 2 possibilities: <annotation> and additional attributes
>
> Angel suggested doing the FuGE way. Maybe overkill? Difficult for 
> software to handle?
>
> Do we really need having both or could we encode the units within the 
> terms, e.g. "collision energy in joules"
>
> Most other relevant CVs don't seem to encode units as part of the term
>
> Defer this to Lyon? Try to include the CV folks in a conference call 
> during meeting
>
> Do we need to have specific types of relationships between linked 
> terms, like "has_units"?
>
> - People still wrinkle their nose when hearing the "dataXML" name.  We 
> have a suggestion on the floor to rename to "mzDataXML".  Comments?
>
> - Make sure dataXML web site is up to date as can be
>
> - DONE Add link to XMLSpy-generated documentation at:
>
>   
> _http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.html_
>
> - Get the indexing wrapper schema working properly
>
>   Jayson Falkner  2006-11-15
>
> - Make sure that Karl Klauser is invited to be involved
>
> Eric will send email.
>
> - Do we support properly the spectrum "library" use case?
>
>   Karl Klauser 2007-01-18
>
>   dataXML is supposed to be for MS instrument raw data, not 
> interpreted data, i.e. with assignments. That is what analysisXML is 
> intended for.
>
> Still open questions here. If analysisXML doesn't includes spectra, 
> this would be tricky.
>
> - Examine the mapping with MIAPE. Do we support everything MIAPE requires?
>
>   Pierre-Alain Binz  2007-03-30
>
>   This will be addressed in Lyon
>
> - Revisit the chromatogram use case and develop a good example
>
>
> Controlled Vocabulary Issues:
>
> Trish sent out a new version of the CV this morning.
>
> New terms from Dave Horn added
>
> Will start keeping and posting release notes
>
> Pete should start working on this new version now
>
> Pete, Trish, and I will iterate on CV a little and there will be 
> another ccall in 1 week exactly to discuss further
>
> We should post the OBO file soon on OBO.
>
> We will meet again in a week roughly, but Pete can't do next Tue 9am
>
> - DONE. Add hyperlink to the current CV on the web site
>
>   _http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo_
>
> - Should we change the ontology namespace to PSI-MS?
>
>   Trish Whetzel  2007-03-27
>
>   Was suggested in Washington already and we decided no?
>
> - What is the overlap/division between the PSI-MS CV, the main PSI CV, 
> OBI?
>
>   Trish Whetzel, Luisa Montecchi  2007-03-30
>
>   To be sorted out in a special working session in Lyon?
>
> - Should we even have an InstrumentIdentifier (local to lab) term at all?
>
>   Trish Whetzel  2007-03-19
>
> - What is required from vendors?
>
>   Pierre-Alain  2007-04-03
>
> - How do we deal with the common PSI CV?
>
>   Pierre-Alain  2007-04-03
>
> - What is the overlap with OBO ontology "ProPreo"?
>
>   ProPreo: A comprehensive proteomics data and process provenance ontology
>
>   _http://lsdis.cs.uga.edu/projects/glycomics/propreo/_
>
>   Eric Deutsch  2007-04-03
>
> Trish says there was a quick review of this ~ 8 months ago
>
> ProPreo is broader but not deep enough
>
> - Try to reconcile the latest instance document and the current PSI 
> ontology:
>
>   Trish Whetzel  2007-03-30
>
>   Eric Deutsch responded 2007-04-03
>
>   (full exchange not repro'ed here)
>
>   Pete or someone trying to resolve based on discussion thus far and 
> identify unresolved?
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

Hi everyone, here is a summary of discussion on the CV at today's call:

At the end of the call, we discussed the possibility of having Trish and
Pete (who cannot attended Lyon) (and possibly others) be on a conference
call for selected times during the meeting, specifically
- Monday 4:30p - 6:00p Lyon time for full CV session
- Tuesday 5:00p - 6:00p Lyon time for final MS CV discussion
Can this be arranged at the Lyon facilities?

Terms that need debate:

- msLevel - The term appears as Precursor Ion Scan (PSI:1000100),
Product Ion Scan (PSI:1000101) and Nth Generation Product Ion
(PSI:1000337). What term should we use for ms 4th, ms 5th and such? We
have to keep precursor ion and product ion. Terms such as  daughter ion
and parent ion are deprecated. We still use Fragment ion though. These
are some additional related terms that I could find in the CV.=20

Both mzXML and mzData had a "msLevel" *attribute*. The decision was made
to put msLevel as a CV term in dataXML.  However, if we add msLevel, it
appears there would be some redundancy with existing terms in the CV (as
above). Decide how to proceed in Lyon.

[Term]
id: PSI:1000364
name: Fragment Ion
def: "A product ion resulting from the dissociation of a precursor ion."
[PSI:GPS]
is_a: PSI:1000365 ! Ion

[Term]
id: PSI:1000344
name: Progeny Ion
def: "A charged product of a series of consecutive reactions that
includes product ions, 1st generation product ions, 2nd generation
product ions, etc. Given the sequential fragmentation scheme: M1+ ? M2+
? M3+ ? M4+ ? M5+ M4+ is the precursor ion of M5+, a 1st generation
product ion of M3+, a 2nd generation product ion of M2+ and a 3rd
generation product ion of M1+. " [PSI:GPS]
exact_synonym: "Progeny Fragment Ion" []
is_a: PSI:1000365 ! Ion

[Term]
id: PSI:1000342
name: Product Ion
def: "An ion formed as the product of a reaction involving a particular
precursor ion. The reaction can unimolecular dissociation, an
ion/molecule reaction, or involve simply a change in the number of
charges. The terms daughter ion and parent ion are not recommended."
[PSI:GPS]
is_a: PSI:1000365 ! Ion



- mzRangeStart, mzRangeStop
According to Eric it would be useful to have a start and stop rather
than a single mass range which can be confusing. I think we need all
three terms: mass range, mzRangeStart and mzRangeStop. Is there anyway
to do that?

Keep them as attributes instead? Discuss more in Lyon. Both previous
formats had them as separate attributes, not CV terms.

[Term]
id: PSI:1000313
name: Mass Range
def: "The limit of m/z over which a mass spectrometer can detect ions."
[PSI:GPS]
is_a: PSI:1000444 ! m/z Separation Method


- I dont know what is this term for?:

[Term]
id: PSI:1000104
name: None
def: "None." [PSI:GPS]
is_a: PSI:1000021 ! Reflectron State

History of this term unknown.  Maybe Randy knows? Eric will ask him.


- Instrument Name

i think Instrument name is same as model because Instrument's model name
is everything but the Vendor's name. Also, each instrument will be
defined, such as LTQ-FT LTQ Orbitrap. The definition of each model would
contain the vendor name. That means we are keeping Model as it is and
Instrument Name will not be used?

[Term]
id: PSI:1000463
name: Instrument
def: "Device which performs a measurement." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000031
name: Model
def: "Instrument's model name (everything but the vendor's name)"
[PSI:GPS]
relationship: part_of PSI:1000454 ! Instrument Additional Description

Use the term "InstrumentModel" and not "InstrumentName" or "Model"
Maybe make new term "InstrumentModel" and deprecate "Model" and will not
use "InstrumentName"
Bring up in Lyon, to find out what the recommendation is for tidying up
the ontology.


- Should we replace all ThermoFinnigan with Thermo Fisher Scientific
because the company name has changed?

Create a new vendor term "Thermo Fisher Scientific" instead of renaming
previous one.  The vendor for many existing years-old mass specs was
ThermoFinnigan at the time.  Maybe putting a date range in the
definitions would be helpful?


- LowestMzValue - Is this within a spectrum or within a experiment. A
clear definition is needed.=20

- HighestMzValue - Again what is the reference for this term. I have to
know what is it for in order                    to get a clear
definintion. =20

Lowest and highest observed values in a spectrum. Used by some software
instead of opening up all spectra.


- Scan Type - "Dictates the type of scan used to generate the spectrum.
Usually refers to the range but can also include linked, precursor,
product and neutral mass loss types of scan."

What is the difference between Scan Type and Scan Mode?

[Term]
id: PSI:1000036
name: Scan Mode
def: "TODO: Add definition." [PSI:GPS]
is_obsolete: true

Pete will research this more and report back.

Try to get Trish and Pete to the Monday 4:30 - 6:00, and maybe Tuesday
5:00 - 6:00p
Lyon is currently GMT+2
Encourage vendors to enter items via the term tracker including
definitions
Eric will email Pierre-Alain and others about joining in on Monday,
Tuesday


Terms to be added:


- We need to add:  LCQ Deca and LCQ Deca XP. Others are there.=20

[Term]
id: PSI:1000169
name: LCQ Deca XP Plus
def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000168
name: LCQ Classic
def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000167
name: LCQ Advantage
def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
is_a: PSI:1000031 ! Model


- Add InstrumentSerialNumber as a term. We are not using
InstrumentIdentifier because serial number is unique.

Okay.

- Add -FileFormatConversion as a term.

Used, e.g., to describe how ReAdW converts RAW to dataXML


- MaldiSpotIdentifier - sample spot, analyte spot or MALDIspot would be
a better term.=20


Terms whose definitions needs to be updated:

[Term]
id: PSI:1000441
name: Scan
def: "A function of the mass spectrometer in which it employs the mass
analyzer to generate the mass spectrum of a range of ions or a specific
ion" [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000036
name: Scan Mode
def: "TODO: Add definition." [PSI:GPS]
is_obsolete: true

-DataArrayContentType



[Term]
id: PSI:1000139
name: 4000 Q TRAP
def: "Applied Biosystems/MDS SCIEX Q 4000 TRAP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000140
name: 4700 Proteomic Analyzer
def: "Applied Biosystems/MDS SCIEX 4700 Proteomic Analyzer MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000141
name: APEX IV
def: "Bruker Daltonics APEX IV MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000142
name: APEX-Q
def: "Bruker Daltonics APEX-Q MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000143
name: API 150EX
def: "Applied Biosystems/MDS SCIEX API 150EX MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000144
name: API 150EX Prep
def: "Applied Biosystems/MDS SCIEX API 150EX Prep MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000145
name: API 2000
def: "Applied Biosystems/MDS SCIEX API 2000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000146
name: API 3000
def: "Applied Biosystems/MDS SCIEX API 3000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000147
name: API 4000
def: "Applied Biosystems/MDS SCIEX API 4000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000148
name: autoFlex II
def: "Bruker Daltonics autoFlex II MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000149
name: autoFlex TOF/TOF
def: "Bruker Daltonics autoFlex TOF/TOF MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000150
name: Auto Spec Ultima NT
def: "Waters AutoSpec Ultima NT MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000151
name: Bio TOF II
def: "Bruker Daltonics BioTOF II MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000152
name: Bio TOF Q
def: "Bruker Daltonics BioTOF Q MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000153
name: DELTA plusAdvantage
def: "ThermoFinnigan DELTAplusAdvantage MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000154
name: DELTAplusXP
def: "ThermoFinnigan DELTAplusXP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000155
name: ELEMENT2
def: "ThermoFinnigan ELEMENT2 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000156
name: esquire4000
def: "Bruker Daltonics esquire4000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000157
name: esquire6000
def: "Bruker Daltonics esquire6000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000158
name: Explorer
def: "IonSpec Explorer MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000159
name: GCT
def: "Waters GCT MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000160
name: HCT
def: "Bruker Daltonics HCT MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000161
name: HCT Plus
def: "Bruker Daltonics HCTPlus MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000162
name: HiRes ESI
def: "IonSpec HiResESI MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000163
name: HiRes MALDI
def: "IonSpec HiResMALDI MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000164
name: IsoPrime
def: "Waters IsoPrime MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000165
name: IsoProbe
def: "Waters IsoProbe MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000166
name: IsoProbe T
def: "Waters IsoProbe T MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000167
name: LCQ Advantage
def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000168
name: LCQ Classic
def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000169
name: LCQ Deca XP Plus
def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000170
name: M@LDI L
def: "Waters M@LDI L MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000171
name: M@LDI LR
def: "Waters M@LDI LR MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000172
name: MAT253
def: "ThermoFinnigan MAT253 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000173
name: MAT900XP
def: "ThermoFinnigan MAT900XP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000174
name: MAT900XP Trap
def: "ThermoFinnigan MAT900XP Trap MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000175
name: MAT95XP
def: "ThermoFinnigan MAT95XP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000176
name: MAT95XP Trap
def: "ThermoFinnigan MAT95XP Trap MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000177
name: microFlex
def: "Bruker Daltonics microFlex MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000178
name: microTOFLC
def: "Bruker Daltonics microTOFLC MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000179
name: Neptune
def: "ThermoFinnigan NEPTUNE MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000180
name: NG-5400
def: "Waters NG-5400 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000181
name: OMEGA
def: "IonSpec OMEGA MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000182
name: OMEGA-2001
def: "IonSpec OMEGA-2001 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000183
name: OmniFlex
def: "Bruker Daltonics OminFlex MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000184
name: Platform ICP
def: "Waters Platform ICP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000185
name: PolarisQ
def: "ThermoFinnigan PolarisQ MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000186
name: Proteomics Solution 1
def: "Applied Biosystems/MDS SCIEX Proteomics Solution 1 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000187
name: Q TRAP
def: "Applied Biosystems/MDS SCIEX Q TRAP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000188
name: Q-Tof micro
def: "Waters Q-Tof micro MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000189
name: Q-Tof Ultima
def: "Waters Q-Tof Ultima MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000190
name: QSTAR
def: "Applied Biosystems/MDS SCIEX QSTAR MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000191
name: Quattro micro
def: "Waters Quattro micro MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000192
name: Quattro UItima
def: "Waters Quattro Uitima MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000193
name: Surveyor MSQ
def: "ThermoFinnigan Surveyor MSQ MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000194
name: SymBiot I
def: "Applied Biosystems/MDS SCIEX SymBiot I MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000195
name: SymBiot XVI
def: "Applied Biosystems/MDS SCIEX SymBiot XVI MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000196
name: TEMPUS TOF
def: "ThermoFinnigan TEMPUS TOF MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000197
name: TRACE DSQ
def: "ThermoFinnigan TRACE DSQ MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000198
name: TRITON
def: "ThermoFinnigan TRITON MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000199
name: TSQ QUANTUM
def: "ThermoFinnigan TSQ QUANTUM MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000200
name: Ultima
def: "IonSpec Ultima MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000201
name: ultraFlex
def: "Bruker Daltonics ultraFlex MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000202
name: ultraFlex TOF/TOF
def: "Bruker Daltonics ultraFlex TOF/TOF MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000203
name: Voyager-DE PRO
def: "Applied Biosystems/MDS SCIEX Voyager-DE PRO MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000204
name: Voyager-DE STR
def: "Applied Biosystems/MDS SCIEX Voyager-DE STR MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000441
name: Scan
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000442
name: Spectrum
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000443
name: Mass Analyzer
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000444
name: m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000445
name: Sequential m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000036
name: Scan Mode
def: "TODO: Add definition." [PSI:GPS]
is_obsolete: true


[Term]
id: PSI:1000127
name: Centroid Mass Spectrum
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000035 ! Peak Processing

[Term]
id: PSI:1000128
name: Continuum Mass Spectrum
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000035 ! Peak Processing


[Term]
id: PSI:1000131
name: Number Of Counts
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000043 ! Intensity Unit

[Term]
id: PSI:1000132
name: Percent Of Base Peak
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000043 ! Intensity Unit


[Term]
id: PSI:1000138
name: Percent
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000046 ! Energy Unit


[Term]
id: PSI:1000441
name: Scan
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000442
name: Spectrum
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology


[Term]
id: PSI:1000443
name: Mass Analyzer
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology


[Term]
id: PSI:1000444
name: m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000445
name: Sequential m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology



Terms we decided not to add:


- AnalyteIdentifier - same as Sample Name (PSI:1000002), and/or Sample

Number (PSI:1000001)

- BasePeakMz - same as Base Peak, PSI:1000210


- InstrumentIdentifier. Same as InstrumentSerialNumber.





_____________________________________________
From: Eric Deutsch=20
Sent: Monday, April 16, 2007 8:05 PM
To: 'Pierre-Alain Binz'; 'Trish Whetzel'; 'Puneet Souda';
'psi...@li...'
Cc: Eric Deutsch
Subject: RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

Hi everyone, this is a reminder of the conference call Tuesday, 9am PDT,
12n EDT, 4pm GMT. Agenda items are:

- Review recent work on the CV (see attached list of items to discuss
from Pete)
- Discuss required preparation for next week
 << File: PSI_TermsReview_Merge.txt >>=20
MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT

- Phone numbers:
  + Germany: 08001012079
  + Switzerland: 0800000860
  + UK: 08081095644
  + USA: 1-866-314-3683
  + Generic international: +44 2083222500 (UK number)

access code: 297427

Thanks,
Eric


_____________________________________________
From: Eric Deutsch=20
Sent: Monday, April 09, 2007 1:07 AM
To: 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent Laursen;
psi...@li...
Cc: Eric Deutsch
Subject: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

Hi everyone, here is a summary of the issues before us regarding
dataXML.  Please read it over and let's discuss at the conference call
on Tuesday. Call information:

MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT

- Phone numbers:
  + Germany: 08001012079
  + Switzerland: 0800000860
  + UK: 08081095644
  + USA: 18663143683
  + Generic international: +44 2083222500 (UK number)

access code: 297427

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

Open issues with dataXML

- Need documentation of each element and attribute
  Mike Coleman  2007-02-06
  Agreed. Does Kent have some start of documentation from
current/previous XMLSpy docs?

Eric will contact Kent directly

- Need more specifics on the desired numerical formats (e.g., IEEE,
etc.)
  Mike Coleman  2007-02-06
  To be discussed in Lyon

- Should there be "count" attributes?
  Frederik Levander  2007-02-06
  This is useful for some parsers. Probably leave in place. Discuss in
Lyon

- Should file index be within the file or in a separate file?
  Frederik Levander  2007-02-06
  The implementation of dataXML to be presented at Lyon will include
this information in the same file. Further discussion deferred to the
Lyon meeting The question was there: Should the file name / checksum
information be held in a separate file?

- Encoded filename should be element content instead of an attribute, so
that CDATA could be used
  Alex Masselot  2007-02-07
  To be discussed in Lyon

- Should controlled vocabulary term values also be element content
instead of attribute so that CDATA could be used?
  Alex Masselot  2007-02-07
  To be discussed in Lyon

- How will we handle multiple charges for parent peak, and fragmentation
peaks?
  Alex Masselot  2007-02-07
  This is already handled - mutliple cvParams of the same type can be
used to annotate one peak / spectrum.

- How can we allow two cv terms to be linked, such as concept with value
and the associated units (a separate cv term). (e.g. "collision
energy"=3D35.0 & "energy units"=3D"joules")
  Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
  Phil to post to list for further responses

Phil suggested 2 possibilities: <annotation> and additional attributes
Angel suggested doing the FuGE way. Maybe overkill? Difficult for
software to handle?
Do we really need having both or could we encode the units within the
terms, e.g. "collision energy in joules"
Most other relevant CVs don't seem to encode units as part of the term
Defer this to Lyon? Try to include the CV folks in a conference call
during meeting
Do we need to have specific types of relationships between linked terms,
like "has_units"?

- People still wrinkle their nose when hearing the "dataXML" name.  We
have a suggestion on the floor to rename to "mzDataXML".  Comments?

- Make sure dataXML web site is up to date as can be

- DONE Add link to XMLSpy-generated documentation at:
=20
http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.htm
l

- Get the indexing wrapper schema working properly
  Jayson Falkner  2006-11-15

- Make sure that Karl Klauser is invited to be involved

Eric will send email.

- Do we support properly the spectrum "library" use case?
  Karl Klauser 2007-01-18
  dataXML is supposed to be for MS instrument raw data, not interpreted
data, i.e. with assignments. That is what analysisXML is intended for.

Still open questions here. If analysisXML doesn't includes spectra, this
would be tricky.

- Examine the mapping with MIAPE. Do we support everything MIAPE
requires?
  Pierre-Alain Binz  2007-03-30
  This will be addressed in Lyon

- Revisit the chromatogram use case and develop a good example


Controlled Vocabulary Issues:

Trish sent out a new version of the CV this morning.
New terms from Dave Horn added
Will start keeping and posting release notes
Pete should start working on this new version now
Pete, Trish, and I will iterate on CV a little and there will be another
ccall in 1 week exactly to discuss further
We should post the OBO file soon on OBO.

We will meet again in a week roughly, but Pete can't do next Tue 9am

- DONE. Add hyperlink to the current CV on the web site
  http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo

- Should we change the ontology namespace to PSI-MS?
  Trish Whetzel  2007-03-27
  Was suggested in Washington already and we decided no?

- What is the overlap/division between the PSI-MS CV, the main PSI CV,
OBI?
  Trish Whetzel, Luisa Montecchi  2007-03-30
  To be sorted out in a special working session in Lyon?

- Should we even have an InstrumentIdentifier (local to lab) term at
all?
  Trish Whetzel  2007-03-19

- What is required from vendors?
  Pierre-Alain  2007-04-03

- How do we deal with the common PSI CV?
  Pierre-Alain  2007-04-03

- What is the overlap with OBO ontology "ProPreo"?
  ProPreo: A comprehensive proteomics data and process provenance
ontology
  http://lsdis.cs.uga.edu/projects/glycomics/propreo/
  Eric Deutsch  2007-04-03

Trish says there was a quick review of this ~ 8 months ago
ProPreo is broader but not deep enough

- Try to reconcile the latest instance document and the current PSI
ontology:
  Trish Whetzel  2007-03-30
  Eric Deutsch responded 2007-04-03
  (full exchange not repro'ed here)
  Pete or someone trying to resolve based on discussion thus far and
identify unresolved?

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Trish W. <wh...@pc...>]

Hi Pete,

Thanks for the clarification. All sounds good, just trying to keep track 
of things.

Trish


>   I have not added new terms. These are the terms which you pulled out from 
> tiny1.DataXML0.11.filerev11.dataXML.xml  and tiny1.mzData1.05.xml instance 
> docs. I realized that some terms needed discussion while other could be added 
> to 1.7.4 obo file. There were also terms whose definitions needs to be 
> updated and then there are terms from the instance docs that we decided not 
> to add. I basically summarized the discussions we were having in emails about 
> these terms.
> It contains many of the terms that needed definitions, mostly mass spec 
> models and TODO terms that you had in 1.7.4 obo file. All the terms and 
> issues that  were under in discussionItemsAboutCV.txt are covered in 
> PSI_TermsReview_Merge.txt.
>
> Let me know if there is confusion or something that I missed. I just broke 
> them into categories:
>
> Terms that need debate:,  Terms to be added:, Terms whose definitions needs 
> to be updated: and Terms we decided not to add:
>
> Pete.
>
>
> Let me know
>
>
> Trish Whetzel wrote:
>> Hi Pete,
>> 
>> Did you add terms to the OBO file? I did not see any new terms added to the 
>> tracker.
>> 
>> Is the list attached here a further review of the terms that I sent 
>> questions on or are there new terms included in this list? At first glance, 
>> I am not sure how this list relates to the list that I sent to you and 
>> Eric.
>> 
>> Thanks,
>> Trish
>> 
>> 
>> 
>>> Hi everyone, this is a reminder of the conference call Tuesday, 9am PDT,
>>> 12n EDT, 4pm GMT. Agenda items are:
>>> 
>>> - Review recent work on the CV (see attached list of items to discuss
>>> from Pete)
>>> - Discuss required preparation for next week
>>> <<PSI_TermsReview_Merge.txt>>
>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>> 
>>> - Phone numbers:
>>>  + Germany: 08001012079
>>>  + Switzerland: 0800000860
>>>  + UK: 08081095644
>>>  + USA: 1-866-314-3683
>>>  + Generic international: +44 2083222500 (UK number)
>>> 
>>> access code: 297427
>>> 
>>> Thanks,
>>> Eric
>>> 
>>> 
>>> _____________________________________________
>>> From: Eric Deutsch
>>> Sent: Monday, April 09, 2007 1:07 AM
>>> To: 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent Laursen;
>>> psi...@li...
>>> Cc: Eric Deutsch
>>> Subject: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>>> 
>>> Hi everyone, here is a summary of the issues before us regarding
>>> dataXML.  Please read it over and let's discuss at the conference call
>>> on Tuesday. Call information:
>>> 
>>> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>>> 
>>> - Phone numbers:
>>>  + Germany: 08001012079
>>>  + Switzerland: 0800000860
>>>  + UK: 08081095644
>>>  + USA: 18663143683
>>>  + Generic international: +44 2083222500 (UK number)
>>> 
>>> access code: 297427
>>> 
>>> ------------------------------------------------------------------------
>>> --------------------------
>>> 
>>> Open issues with dataXML
>>> 
>>> - Need documentation of each element and attribute
>>>  Mike Coleman  2007-02-06
>>>  Agreed. Does Kent have some start of documentation from
>>> current/previous XMLSpy docs?
>>> 
>>> Eric will contact Kent directly
>>> 
>>> - Need more specifics on the desired numerical formats (e.g., IEEE,
>>> etc.)
>>>  Mike Coleman  2007-02-06
>>>  To be discussed in Lyon
>>> 
>>> - Should there be "count" attributes?
>>>  Frederik Levander  2007-02-06
>>>  This is useful for some parsers. Probably leave in place. Discuss in
>>> Lyon
>>> 
>>> - Should file index be within the file or in a separate file?
>>>  Frederik Levander  2007-02-06
>>>  The implementation of dataXML to be presented at Lyon will include
>>> this information in the same file. Further discussion deferred to the
>>> Lyon meeting The question was there: Should the file name / checksum
>>> information be held in a separate file?
>>> 
>>> - Encoded filename should be element content instead of an attribute, so
>>> that CDATA could be used
>>>  Alex Masselot  2007-02-07
>>>  To be discussed in Lyon
>>> 
>>> - Should controlled vocabulary term values also be element content
>>> instead of attribute so that CDATA could be used?
>>>  Alex Masselot  2007-02-07
>>>  To be discussed in Lyon
>>> 
>>> - How will we handle multiple charges for parent peak, and fragmentation
>>> peaks?
>>>  Alex Masselot  2007-02-07
>>>  This is already handled - mutliple cvParams of the same type can be
>>> used to annotate one peak / spectrum.
>>> 
>>> - How can we allow two cv terms to be linked, such as concept with value
>>> and the associated units (a separate cv term). (e.g. "collision
>>> energy"=35.0 & "energy units"="joules")
>>>  Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
>>>  Phil to post to list for further responses
>>> 
>>> Phil suggested 2 possibilities: <annotation> and additional attributes
>>> Angel suggested doing the FuGE way. Maybe overkill? Difficult for
>>> software to handle?
>>> Do we really need having both or could we encode the units within the
>>> terms, e.g. "collision energy in joules"
>>> Most other relevant CVs don't seem to encode units as part of the term
>>> Defer this to Lyon? Try to include the CV folks in a conference call
>>> during meeting
>>> Do we need to have specific types of relationships between linked terms,
>>> like "has_units"?
>>> 
>>> - People still wrinkle their nose when hearing the "dataXML" name.  We
>>> have a suggestion on the floor to rename to "mzDataXML".  Comments?
>>> 
>>> - Make sure dataXML web site is up to date as can be
>>> 
>>> - DONE Add link to XMLSpy-generated documentation at:
>>> 
>>> http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.htm
>>> l
>>> 
>>> - Get the indexing wrapper schema working properly
>>>  Jayson Falkner  2006-11-15
>>> 
>>> - Make sure that Karl Klauser is invited to be involved
>>> 
>>> Eric will send email.
>>> 
>>> - Do we support properly the spectrum "library" use case?
>>>  Karl Klauser 2007-01-18
>>>  dataXML is supposed to be for MS instrument raw data, not interpreted
>>> data, i.e. with assignments. That is what analysisXML is intended for.
>>> 
>>> Still open questions here. If analysisXML doesn't includes spectra, this
>>> would be tricky.
>>> 
>>> - Examine the mapping with MIAPE. Do we support everything MIAPE
>>> requires?
>>>  Pierre-Alain Binz  2007-03-30
>>>  This will be addressed in Lyon
>>> 
>>> - Revisit the chromatogram use case and develop a good example
>>> 
>>> 
>>> Controlled Vocabulary Issues:
>>> 
>>> Trish sent out a new version of the CV this morning.
>>> New terms from Dave Horn added
>>> Will start keeping and posting release notes
>>> Pete should start working on this new version now
>>> Pete, Trish, and I will iterate on CV a little and there will be another
>>> ccall in 1 week exactly to discuss further
>>> We should post the OBO file soon on OBO.
>>> 
>>> We will meet again in a week roughly, but Pete can't do next Tue 9am
>>> 
>>> - DONE. Add hyperlink to the current CV on the web site
>>>  http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo
>>> 
>>> - Should we change the ontology namespace to PSI-MS?
>>>  Trish Whetzel  2007-03-27
>>>  Was suggested in Washington already and we decided no?
>>> 
>>> - What is the overlap/division between the PSI-MS CV, the main PSI CV,
>>> OBI?
>>>  Trish Whetzel, Luisa Montecchi  2007-03-30
>>>  To be sorted out in a special working session in Lyon?
>>> 
>>> - Should we even have an InstrumentIdentifier (local to lab) term at
>>> all?
>>>  Trish Whetzel  2007-03-19
>>> 
>>> - What is required from vendors?
>>>  Pierre-Alain  2007-04-03
>>> 
>>> - How do we deal with the common PSI CV?
>>>  Pierre-Alain  2007-04-03
>>> 
>>> - What is the overlap with OBO ontology "ProPreo"?
>>>  ProPreo: A comprehensive proteomics data and process provenance
>>> ontology
>>>  http://lsdis.cs.uga.edu/projects/glycomics/propreo/
>>>  Eric Deutsch  2007-04-03
>>> 
>>> Trish says there was a quick review of this ~ 8 months ago
>>> ProPreo is broader but not deep enough
>>> 
>>> - Try to reconcile the latest instance document and the current PSI
>>> ontology:
>>>  Trish Whetzel  2007-03-30
>>>  Eric Deutsch responded 2007-04-03
>>>  (full exchange not repro'ed here)
>>>  Pete or someone trying to resolve based on discussion thus far and
>>> identify unresolved?
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Puneet S. <ps...@ch...>]

4:29 PM 4/16/2007


Terms that need debate:

- msLevel - The term appears as Precursor Ion Scan (PSI:1000100),  Product Ion Scan (PSI:1000101) and Nth Generation Product Ion (PSI:1000337). What term should we use for ms 4th, ms 5th and such? We have to keep precursor ion and product ion. Terms such as  daughter ion and parent ion are deprecated. We still use Fragment ion though. These are some additional related terms that I could find in the CV. 


[Term]
id: PSI:1000364
name: Fragment Ion
def: "A product ion resulting from the dissociation of a precursor ion." [PSI:GPS]
is_a: PSI:1000365 ! Ion

[Term]
id: PSI:1000344
name: Progeny Ion
def: "A charged product of a series of consecutive reactions that includes product ions, 1st generation product ions, 2nd generation product ions, etc. Given the sequential fragmentation scheme: M1+ ? M2+ ? M3+ ? M4+ ? M5+ M4+ is the precursor ion of M5+, a 1st generation product ion of M3+, a 2nd generation product ion of M2+ and a 3rd generation product ion of M1+. " [PSI:GPS]
exact_synonym: "Progeny Fragment Ion" []
is_a: PSI:1000365 ! Ion

[Term]
id: PSI:1000342
name: Product Ion
def: "An ion formed as the product of a reaction involving a particular precursor ion. The reaction can unimolecular dissociation, an ion/molecule reaction, or involve simply a change in the number of charges. The terms daughter ion and parent ion are not recommended." [PSI:GPS]
is_a: PSI:1000365 ! Ion



- mzRangeStart, mzRangeStop
According to Eric it would be useful to have a start and stop rather than a single mass range which can be confusing. I think we need all three terms: mass range, mzRangeStart and mzRangeStop. Is there anyway to do that?

[Term]
id: PSI:1000313
name: Mass Range
def: "The limit of m/z over which a mass spectrometer can detect ions." [PSI:GPS]
is_a: PSI:1000444 ! m/z Separation Method


- I dont know what is this term for?:

[Term]
id: PSI:1000104
name: None
def: "None." [PSI:GPS]
is_a: PSI:1000021 ! Reflectron State


- Instrument Name

i think Instrument name is same as model because Instrument's model name is everything but the Vendor's name. Also, each instrument will be defined, such as LTQ-FT LTQ Orbitrap. The definition of each model would contain the vendor name. That means we are keeping Model as it is and Instrument Name will not be used?

[Term]
id: PSI:1000463
name: Instrument
def: "Device which performs a measurement." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000031
name: Model
def: "Instrument's model name (everything but the vendor's name)" [PSI:GPS]
relationship: part_of PSI:1000454 ! Instrument Additional Description


- Should we replace all ThermoFinnigan with Thermo Fisher Scientific because the company name has changed?



- LowestMzValue - Is this within a spectrum or within a experiment. A clear definition is needed. 

- HighestMzValue - Again what is the reference for this term. I have to know what is it for in order                    to get a clear definintion.  

- Scan Type - "Dictates the type of scan used to generate the spectrum. Usually refers to the range but can also include linked, precursor, product and neutral mass loss types of scan."

What is the difference between Scan Type and Scan Mode?

[Term]
id: PSI:1000036
name: Scan Mode
def: "TODO: Add definition." [PSI:GPS]
is_obsolete: true

















Terms to be added:


- We need to add:  LCQ Deca and LCQ Deca XP. Others are there. 

[Term]
id: PSI:1000169
name: LCQ Deca XP Plus
def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000168
name: LCQ Classic
def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000167
name: LCQ Advantage
def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
is_a: PSI:1000031 ! Model


- Add InstrumentSerialNumber as a term. We are not using InstrumentIdentifier because serial number is unique.

- Add -FileFormatConversion as a term.




- MaldiSpotIdentifier - sample spot, analyte spot or MALDIspot would be a better term. 






















Terms whose definitions needs to be updated:

[Term]
id: PSI:1000441
name: Scan
def: "A function of the mass spectrometer in which it employs the mass analyzer to generate the mass spectrum of a range of ions or a specific ion" [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000036
name: Scan Mode
def: "TODO: Add definition." [PSI:GPS]
is_obsolete: true

-DataArrayContentType



[Term]
id: PSI:1000139
name: 4000 Q TRAP
def: "Applied Biosystems/MDS SCIEX Q 4000 TRAP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000140
name: 4700 Proteomic Analyzer
def: "Applied Biosystems/MDS SCIEX 4700 Proteomic Analyzer MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000141
name: APEX IV
def: "Bruker Daltonics APEX IV MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000142
name: APEX-Q
def: "Bruker Daltonics APEX-Q MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000143
name: API 150EX
def: "Applied Biosystems/MDS SCIEX API 150EX MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000144
name: API 150EX Prep
def: "Applied Biosystems/MDS SCIEX API 150EX Prep MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000145
name: API 2000
def: "Applied Biosystems/MDS SCIEX API 2000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000146
name: API 3000
def: "Applied Biosystems/MDS SCIEX API 3000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000147
name: API 4000
def: "Applied Biosystems/MDS SCIEX API 4000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000148
name: autoFlex II
def: "Bruker Daltonics autoFlex II MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000149
name: autoFlex TOF/TOF
def: "Bruker Daltonics autoFlex TOF/TOF MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000150
name: Auto Spec Ultima NT
def: "Waters AutoSpec Ultima NT MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000151
name: Bio TOF II
def: "Bruker Daltonics BioTOF II MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000152
name: Bio TOF Q
def: "Bruker Daltonics BioTOF Q MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000153
name: DELTA plusAdvantage
def: "ThermoFinnigan DELTAplusAdvantage MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000154
name: DELTAplusXP
def: "ThermoFinnigan DELTAplusXP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000155
name: ELEMENT2
def: "ThermoFinnigan ELEMENT2 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000156
name: esquire4000
def: "Bruker Daltonics esquire4000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000157
name: esquire6000
def: "Bruker Daltonics esquire6000 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000158
name: Explorer
def: "IonSpec Explorer MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000159
name: GCT
def: "Waters GCT MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000160
name: HCT
def: "Bruker Daltonics HCT MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000161
name: HCT Plus
def: "Bruker Daltonics HCTPlus MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000162
name: HiRes ESI
def: "IonSpec HiResESI MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000163
name: HiRes MALDI
def: "IonSpec HiResMALDI MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000164
name: IsoPrime
def: "Waters IsoPrime MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000165
name: IsoProbe
def: "Waters IsoProbe MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000166
name: IsoProbe T
def: "Waters IsoProbe T MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000167
name: LCQ Advantage
def: "ThermoFinnigan LCQ Advantage MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000168
name: LCQ Classic
def: "ThermoFinnigan LCQ Classic MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000169
name: LCQ Deca XP Plus
def: "ThermoFinnigan LCQ Deca XP Plus MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000170
name: M@LDI L
def: "Waters M@LDI L MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000171
name: M@LDI LR
def: "Waters M@LDI LR MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000172
name: MAT253
def: "ThermoFinnigan MAT253 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000173
name: MAT900XP
def: "ThermoFinnigan MAT900XP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000174
name: MAT900XP Trap
def: "ThermoFinnigan MAT900XP Trap MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000175
name: MAT95XP
def: "ThermoFinnigan MAT95XP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000176
name: MAT95XP Trap
def: "ThermoFinnigan MAT95XP Trap MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000177
name: microFlex
def: "Bruker Daltonics microFlex MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000178
name: microTOFLC
def: "Bruker Daltonics microTOFLC MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000179
name: Neptune
def: "ThermoFinnigan NEPTUNE MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000180
name: NG-5400
def: "Waters NG-5400 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000181
name: OMEGA
def: "IonSpec OMEGA MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000182
name: OMEGA-2001
def: "IonSpec OMEGA-2001 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000183
name: OmniFlex
def: "Bruker Daltonics OminFlex MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000184
name: Platform ICP
def: "Waters Platform ICP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000185
name: PolarisQ
def: "ThermoFinnigan PolarisQ MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000186
name: Proteomics Solution 1
def: "Applied Biosystems/MDS SCIEX Proteomics Solution 1 MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000187
name: Q TRAP
def: "Applied Biosystems/MDS SCIEX Q TRAP MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000188
name: Q-Tof micro
def: "Waters Q-Tof micro MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000189
name: Q-Tof Ultima
def: "Waters Q-Tof Ultima MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000190
name: QSTAR
def: "Applied Biosystems/MDS SCIEX QSTAR MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000191
name: Quattro micro
def: "Waters Quattro micro MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000192
name: Quattro UItima
def: "Waters Quattro Uitima MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000193
name: Surveyor MSQ
def: "ThermoFinnigan Surveyor MSQ MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000194
name: SymBiot I
def: "Applied Biosystems/MDS SCIEX SymBiot I MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000195
name: SymBiot XVI
def: "Applied Biosystems/MDS SCIEX SymBiot XVI MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000196
name: TEMPUS TOF
def: "ThermoFinnigan TEMPUS TOF MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000197
name: TRACE DSQ
def: "ThermoFinnigan TRACE DSQ MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000198
name: TRITON
def: "ThermoFinnigan TRITON MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000199
name: TSQ QUANTUM
def: "ThermoFinnigan TSQ QUANTUM MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000200
name: Ultima
def: "IonSpec Ultima MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000201
name: ultraFlex
def: "Bruker Daltonics ultraFlex MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000202
name: ultraFlex TOF/TOF
def: "Bruker Daltonics ultraFlex TOF/TOF MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000203
name: Voyager-DE PRO
def: "Applied Biosystems/MDS SCIEX Voyager-DE PRO MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000204
name: Voyager-DE STR
def: "Applied Biosystems/MDS SCIEX Voyager-DE STR MS" [PSI:GPS]
is_a: PSI:1000031 ! Model

[Term]
id: PSI:1000441
name: Scan
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000442
name: Spectrum
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000443
name: Mass Analyzer
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000444
name: m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000445
name: Sequential m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000036
name: Scan Mode
def: "TODO: Add definition." [PSI:GPS]
is_obsolete: true


[Term]
id: PSI:1000127
name: Centroid Mass Spectrum
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000035 ! Peak Processing

[Term]
id: PSI:1000128
name: Continuum Mass Spectrum
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000035 ! Peak Processing


[Term]
id: PSI:1000131
name: Number Of Counts
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000043 ! Intensity Unit

[Term]
id: PSI:1000132
name: Percent Of Base Peak
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000043 ! Intensity Unit


[Term]
id: PSI:1000138
name: Percent
def: "TODO: Add definition." [PSI:GPS]
is_a: PSI:1000046 ! Energy Unit


[Term]
id: PSI:1000441
name: Scan
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000442
name: Spectrum
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology


[Term]
id: PSI:1000443
name: Mass Analyzer
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology


[Term]
id: PSI:1000444
name: m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology

[Term]
id: PSI:1000445
name: Sequential m/z Separation Method
def: "TODO: Add definition." [PSI:GPS]
relationship: part_of PSI:0000000 ! mzOntology









Terms we decided not to add:


- AnalyteIdentifier - same as Sample Name (PSI:1000002), and/or Sample

Number (PSI:1000001)

- BasePeakMz - same as Base Peak, PSI:1000210


- InstrumentIdentifier. Same as InstrumentSerialNumber.

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

[Trish W. <wh...@pc...>]

Hi Pete,

Did you add terms to the OBO file? I did not see any new terms added to 
the tracker.

Is the list attached here a further review of the terms that I sent 
questions on or are there new terms included in this list? At first 
glance, I am not sure how this list relates to the list that I sent to you 
and Eric.

Thanks,
Trish


> Hi everyone, this is a reminder of the conference call Tuesday, 9am PDT,
> 12n EDT, 4pm GMT. Agenda items are:
>
> - Review recent work on the CV (see attached list of items to discuss
> from Pete)
> - Discuss required preparation for next week
> <<PSI_TermsReview_Merge.txt>>
> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>
> - Phone numbers:
>  + Germany: 08001012079
>  + Switzerland: 0800000860
>  + UK: 08081095644
>  + USA: 1-866-314-3683
>  + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
> Thanks,
> Eric
>
>
> _____________________________________________
> From: Eric Deutsch
> Sent: Monday, April 09, 2007 1:07 AM
> To: 'Pierre-Alain Binz'; Trish Whetzel; Puneet Souda; Kent Laursen;
> psi...@li...
> Cc: Eric Deutsch
> Subject: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT
>
> Hi everyone, here is a summary of the issues before us regarding
> dataXML.  Please read it over and let's discuss at the conference call
> on Tuesday. Call information:
>
> MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT
>
> - Phone numbers:
>  + Germany: 08001012079
>  + Switzerland: 0800000860
>  + UK: 08081095644
>  + USA: 18663143683
>  + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
> ------------------------------------------------------------------------
> --------------------------
>
> Open issues with dataXML
>
> - Need documentation of each element and attribute
>  Mike Coleman  2007-02-06
>  Agreed. Does Kent have some start of documentation from
> current/previous XMLSpy docs?
>
> Eric will contact Kent directly
>
> - Need more specifics on the desired numerical formats (e.g., IEEE,
> etc.)
>  Mike Coleman  2007-02-06
>  To be discussed in Lyon
>
> - Should there be "count" attributes?
>  Frederik Levander  2007-02-06
>  This is useful for some parsers. Probably leave in place. Discuss in
> Lyon
>
> - Should file index be within the file or in a separate file?
>  Frederik Levander  2007-02-06
>  The implementation of dataXML to be presented at Lyon will include
> this information in the same file. Further discussion deferred to the
> Lyon meeting The question was there: Should the file name / checksum
> information be held in a separate file?
>
> - Encoded filename should be element content instead of an attribute, so
> that CDATA could be used
>  Alex Masselot  2007-02-07
>  To be discussed in Lyon
>
> - Should controlled vocabulary term values also be element content
> instead of attribute so that CDATA could be used?
>  Alex Masselot  2007-02-07
>  To be discussed in Lyon
>
> - How will we handle multiple charges for parent peak, and fragmentation
> peaks?
>  Alex Masselot  2007-02-07
>  This is already handled - mutliple cvParams of the same type can be
> used to annotate one peak / spectrum.
>
> - How can we allow two cv terms to be linked, such as concept with value
> and the associated units (a separate cv term). (e.g. "collision
> energy"=35.0 & "energy units"="joules")
>  Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
>  Phil to post to list for further responses
>
> Phil suggested 2 possibilities: <annotation> and additional attributes
> Angel suggested doing the FuGE way. Maybe overkill? Difficult for
> software to handle?
> Do we really need having both or could we encode the units within the
> terms, e.g. "collision energy in joules"
> Most other relevant CVs don't seem to encode units as part of the term
> Defer this to Lyon? Try to include the CV folks in a conference call
> during meeting
> Do we need to have specific types of relationships between linked terms,
> like "has_units"?
>
> - People still wrinkle their nose when hearing the "dataXML" name.  We
> have a suggestion on the floor to rename to "mzDataXML".  Comments?
>
> - Make sure dataXML web site is up to date as can be
>
> - DONE Add link to XMLSpy-generated documentation at:
>
> http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.htm
> l
>
> - Get the indexing wrapper schema working properly
>  Jayson Falkner  2006-11-15
>
> - Make sure that Karl Klauser is invited to be involved
>
> Eric will send email.
>
> - Do we support properly the spectrum "library" use case?
>  Karl Klauser 2007-01-18
>  dataXML is supposed to be for MS instrument raw data, not interpreted
> data, i.e. with assignments. That is what analysisXML is intended for.
>
> Still open questions here. If analysisXML doesn't includes spectra, this
> would be tricky.
>
> - Examine the mapping with MIAPE. Do we support everything MIAPE
> requires?
>  Pierre-Alain Binz  2007-03-30
>  This will be addressed in Lyon
>
> - Revisit the chromatogram use case and develop a good example
>
>
> Controlled Vocabulary Issues:
>
> Trish sent out a new version of the CV this morning.
> New terms from Dave Horn added
> Will start keeping and posting release notes
> Pete should start working on this new version now
> Pete, Trish, and I will iterate on CV a little and there will be another
> ccall in 1 week exactly to discuss further
> We should post the OBO file soon on OBO.
>
> We will meet again in a week roughly, but Pete can't do next Tue 9am
>
> - DONE. Add hyperlink to the current CV on the web site
>  http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo
>
> - Should we change the ontology namespace to PSI-MS?
>  Trish Whetzel  2007-03-27
>  Was suggested in Washington already and we decided no?
>
> - What is the overlap/division between the PSI-MS CV, the main PSI CV,
> OBI?
>  Trish Whetzel, Luisa Montecchi  2007-03-30
>  To be sorted out in a special working session in Lyon?
>
> - Should we even have an InstrumentIdentifier (local to lab) term at
> all?
>  Trish Whetzel  2007-03-19
>
> - What is required from vendors?
>  Pierre-Alain  2007-04-03
>
> - How do we deal with the common PSI CV?
>  Pierre-Alain  2007-04-03
>
> - What is the overlap with OBO ontology "ProPreo"?
>  ProPreo: A comprehensive proteomics data and process provenance
> ontology
>  http://lsdis.cs.uga.edu/projects/glycomics/propreo/
>  Eric Deutsch  2007-04-03
>
> Trish says there was a quick review of this ~ 8 months ago
> ProPreo is broader but not deep enough
>
> - Try to reconcile the latest instance document and the current PSI
> ontology:
>  Trish Whetzel  2007-03-30
>  Eric Deutsch responded 2007-04-03
>  (full exchange not repro'ed here)
>  Pete or someone trying to resolve based on discussion thus far and
> identify unresolved?
>
>
>
>

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

NDoyOSBQTSA0LzE2LzIwMDcNCg0KDQpUZXJtcyB0aGF0IG5lZWQgZGViYXRlOg0KDQotIG1zTGV2
ZWwgLSBUaGUgdGVybSBhcHBlYXJzIGFzIFByZWN1cnNvciBJb24gU2NhbiAoUFNJOjEwMDAxMDAp
LCAgUHJvZHVjdCBJb24gU2NhbiAoUFNJOjEwMDAxMDEpIGFuZCBOdGggR2VuZXJhdGlvbiBQcm9k
dWN0IElvbiAoUFNJOjEwMDAzMzcpLiBXaGF0IHRlcm0gc2hvdWxkIHdlIHVzZSBmb3IgbXMgNHRo
LCBtcyA1dGggYW5kIHN1Y2g/IFdlIGhhdmUgdG8ga2VlcCBwcmVjdXJzb3IgaW9uIGFuZCBwcm9k
dWN0IGlvbi4gVGVybXMgc3VjaCBhcyAgZGF1Z2h0ZXIgaW9uIGFuZCBwYXJlbnQgaW9uIGFyZSBk
ZXByZWNhdGVkLiBXZSBzdGlsbCB1c2UgRnJhZ21lbnQgaW9uIHRob3VnaC4gVGhlc2UgYXJlIHNv
bWUgYWRkaXRpb25hbCByZWxhdGVkIHRlcm1zIHRoYXQgSSBjb3VsZCBmaW5kIGluIHRoZSBDVi4g
DQoNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAzNjQNCm5hbWU6IEZyYWdtZW50IElvbg0KZGVmOiAi
QSBwcm9kdWN0IGlvbiByZXN1bHRpbmcgZnJvbSB0aGUgZGlzc29jaWF0aW9uIG9mIGEgcHJlY3Vy
c29yIGlvbi4iIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAzNjUgISBJb24NCg0KW1Rlcm1dDQpp
ZDogUFNJOjEwMDAzNDQNCm5hbWU6IFByb2dlbnkgSW9uDQpkZWY6ICJBIGNoYXJnZWQgcHJvZHVj
dCBvZiBhIHNlcmllcyBvZiBjb25zZWN1dGl2ZSByZWFjdGlvbnMgdGhhdCBpbmNsdWRlcyBwcm9k
dWN0IGlvbnMsIDFzdCBnZW5lcmF0aW9uIHByb2R1Y3QgaW9ucywgMm5kIGdlbmVyYXRpb24gcHJv
ZHVjdCBpb25zLCBldGMuIEdpdmVuIHRoZSBzZXF1ZW50aWFsIGZyYWdtZW50YXRpb24gc2NoZW1l
OiBNMSsgPyBNMisgPyBNMysgPyBNNCsgPyBNNSsgTTQrIGlzIHRoZSBwcmVjdXJzb3IgaW9uIG9m
IE01KywgYSAxc3QgZ2VuZXJhdGlvbiBwcm9kdWN0IGlvbiBvZiBNMyssIGEgMm5kIGdlbmVyYXRp
b24gcHJvZHVjdCBpb24gb2YgTTIrIGFuZCBhIDNyZCBnZW5lcmF0aW9uIHByb2R1Y3QgaW9uIG9m
IE0xKy4gIiBbUFNJOkdQU10NCmV4YWN0X3N5bm9ueW06ICJQcm9nZW55IEZyYWdtZW50IElvbiIg
W10NCmlzX2E6IFBTSToxMDAwMzY1ICEgSW9uDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMzQyDQpu
YW1lOiBQcm9kdWN0IElvbg0KZGVmOiAiQW4gaW9uIGZvcm1lZCBhcyB0aGUgcHJvZHVjdCBvZiBh
IHJlYWN0aW9uIGludm9sdmluZyBhIHBhcnRpY3VsYXIgcHJlY3Vyc29yIGlvbi4gVGhlIHJlYWN0
aW9uIGNhbiB1bmltb2xlY3VsYXIgZGlzc29jaWF0aW9uLCBhbiBpb24vbW9sZWN1bGUgcmVhY3Rp
b24sIG9yIGludm9sdmUgc2ltcGx5IGEgY2hhbmdlIGluIHRoZSBudW1iZXIgb2YgY2hhcmdlcy4g
VGhlIHRlcm1zIGRhdWdodGVyIGlvbiBhbmQgcGFyZW50IGlvbiBhcmUgbm90IHJlY29tbWVuZGVk
LiIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDM2NSAhIElvbg0KDQoNCg0KLSBtelJhbmdlU3Rh
cnQsIG16UmFuZ2VTdG9wDQpBY2NvcmRpbmcgdG8gRXJpYyBpdCB3b3VsZCBiZSB1c2VmdWwgdG8g
aGF2ZSBhIHN0YXJ0IGFuZCBzdG9wIHJhdGhlciB0aGFuIGEgc2luZ2xlIG1hc3MgcmFuZ2Ugd2hp
Y2ggY2FuIGJlIGNvbmZ1c2luZy4gSSB0aGluayB3ZSBuZWVkIGFsbCB0aHJlZSB0ZXJtczogbWFz
cyByYW5nZSwgbXpSYW5nZVN0YXJ0IGFuZCBtelJhbmdlU3RvcC4gSXMgdGhlcmUgYW55d2F5IHRv
IGRvIHRoYXQ/DQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMzEzDQpuYW1lOiBNYXNzIFJhbmdlDQpk
ZWY6ICJUaGUgbGltaXQgb2YgbS96IG92ZXIgd2hpY2ggYSBtYXNzIHNwZWN0cm9tZXRlciBjYW4g
ZGV0ZWN0IGlvbnMuIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwNDQ0ICEgbS96IFNlcGFyYXRp
b24gTWV0aG9kDQoNCg0KLSBJIGRvbnQga25vdyB3aGF0IGlzIHRoaXMgdGVybSBmb3I/Og0KDQpb
VGVybV0NCmlkOiBQU0k6MTAwMDEwNA0KbmFtZTogTm9uZQ0KZGVmOiAiTm9uZS4iIFtQU0k6R1BT
XQ0KaXNfYTogUFNJOjEwMDAwMjEgISBSZWZsZWN0cm9uIFN0YXRlDQoNCg0KLSBJbnN0cnVtZW50
IE5hbWUNCg0KaSB0aGluayBJbnN0cnVtZW50IG5hbWUgaXMgc2FtZSBhcyBtb2RlbCBiZWNhdXNl
IEluc3RydW1lbnQncyBtb2RlbCBuYW1lIGlzIGV2ZXJ5dGhpbmcgYnV0IHRoZSBWZW5kb3IncyBu
YW1lLiBBbHNvLCBlYWNoIGluc3RydW1lbnQgd2lsbCBiZSBkZWZpbmVkLCBzdWNoIGFzIExUUS1G
VCBMVFEgT3JiaXRyYXAuIFRoZSBkZWZpbml0aW9uIG9mIGVhY2ggbW9kZWwgd291bGQgY29udGFp
biB0aGUgdmVuZG9yIG5hbWUuIFRoYXQgbWVhbnMgd2UgYXJlIGtlZXBpbmcgTW9kZWwgYXMgaXQg
aXMgYW5kIEluc3RydW1lbnQgTmFtZSB3aWxsIG5vdCBiZSB1c2VkPw0KDQpbVGVybV0NCmlkOiBQ
U0k6MTAwMDQ2Mw0KbmFtZTogSW5zdHJ1bWVudA0KZGVmOiAiRGV2aWNlIHdoaWNoIHBlcmZvcm1z
IGEgbWVhc3VyZW1lbnQuIiBbUFNJOkdQU10NCnJlbGF0aW9uc2hpcDogcGFydF9vZiBQU0k6MDAw
MDAwMCAhIG16T250b2xvZ3kNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAwMzENCm5hbWU6IE1vZGVs
DQpkZWY6ICJJbnN0cnVtZW50J3MgbW9kZWwgbmFtZSAoZXZlcnl0aGluZyBidXQgdGhlIHZlbmRv
cidzIG5hbWUpIiBbUFNJOkdQU10NCnJlbGF0aW9uc2hpcDogcGFydF9vZiBQU0k6MTAwMDQ1NCAh
IEluc3RydW1lbnQgQWRkaXRpb25hbCBEZXNjcmlwdGlvbg0KDQoNCi0gU2hvdWxkIHdlIHJlcGxh
Y2UgYWxsIFRoZXJtb0Zpbm5pZ2FuIHdpdGggVGhlcm1vIEZpc2hlciBTY2llbnRpZmljIGJlY2F1
c2UgdGhlIGNvbXBhbnkgbmFtZSBoYXMgY2hhbmdlZD8NCg0KDQoNCi0gTG93ZXN0TXpWYWx1ZSAt
IElzIHRoaXMgd2l0aGluIGEgc3BlY3RydW0gb3Igd2l0aGluIGEgZXhwZXJpbWVudC4gQSBjbGVh
ciBkZWZpbml0aW9uIGlzIG5lZWRlZC4gDQoNCi0gSGlnaGVzdE16VmFsdWUgLSBBZ2FpbiB3aGF0
IGlzIHRoZSByZWZlcmVuY2UgZm9yIHRoaXMgdGVybS4gSSBoYXZlIHRvIGtub3cgd2hhdCBpcyBp
dCBmb3IgaW4gb3JkZXIgICAgICAgICAgICAgICAgICAgIHRvIGdldCBhIGNsZWFyIGRlZmluaW50
aW9uLiAgDQoNCi0gU2NhbiBUeXBlIC0gIkRpY3RhdGVzIHRoZSB0eXBlIG9mIHNjYW4gdXNlZCB0
byBnZW5lcmF0ZSB0aGUgc3BlY3RydW0uIFVzdWFsbHkgcmVmZXJzIHRvIHRoZSByYW5nZSBidXQg
Y2FuIGFsc28gaW5jbHVkZSBsaW5rZWQsIHByZWN1cnNvciwgcHJvZHVjdCBhbmQgbmV1dHJhbCBt
YXNzIGxvc3MgdHlwZXMgb2Ygc2Nhbi4iDQoNCldoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl
biBTY2FuIFR5cGUgYW5kIFNjYW4gTW9kZT8NCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAwMzYNCm5h
bWU6IFNjYW4gTW9kZQ0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQU10NCmlz
X29ic29sZXRlOiB0cnVlDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KVGVybXMg
dG8gYmUgYWRkZWQ6DQoNCg0KLSBXZSBuZWVkIHRvIGFkZDogIExDUSBEZWNhIGFuZCBMQ1EgRGVj
YSBYUC4gT3RoZXJzIGFyZSB0aGVyZS4gDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMTY5DQpuYW1l
OiBMQ1EgRGVjYSBYUCBQbHVzDQpkZWY6ICJUaGVybW9GaW5uaWdhbiBMQ1EgRGVjYSBYUCBQbHVz
IE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDog
UFNJOjEwMDAxNjgNCm5hbWU6IExDUSBDbGFzc2ljDQpkZWY6ICJUaGVybW9GaW5uaWdhbiBMQ1Eg
Q2xhc3NpYyBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJt
XQ0KaWQ6IFBTSToxMDAwMTY3DQpuYW1lOiBMQ1EgQWR2YW50YWdlDQpkZWY6ICJUaGVybW9GaW5u
aWdhbiBMQ1EgQWR2YW50YWdlIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9k
ZWwNCg0KDQotIEFkZCBJbnN0cnVtZW50U2VyaWFsTnVtYmVyIGFzIGEgdGVybS4gV2UgYXJlIG5v
dCB1c2luZyBJbnN0cnVtZW50SWRlbnRpZmllciBiZWNhdXNlIHNlcmlhbCBudW1iZXIgaXMgdW5p
cXVlLg0KDQotIEFkZCAtRmlsZUZvcm1hdENvbnZlcnNpb24gYXMgYSB0ZXJtLg0KDQoNCg0KDQot
IE1hbGRpU3BvdElkZW50aWZpZXIgLSBzYW1wbGUgc3BvdCwgYW5hbHl0ZSBzcG90IG9yIE1BTERJ
c3BvdCB3b3VsZCBiZSBhIGJldHRlciB0ZXJtLiANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KVGVybXMgd2hvc2UgZGVmaW5pdGlvbnMgbmVlZHMgdG8gYmUgdXBk
YXRlZDoNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDA0NDENCm5hbWU6IFNjYW4NCmRlZjogIkEgZnVu
Y3Rpb24gb2YgdGhlIG1hc3Mgc3BlY3Ryb21ldGVyIGluIHdoaWNoIGl0IGVtcGxveXMgdGhlIG1h
c3MgYW5hbHl6ZXIgdG8gZ2VuZXJhdGUgdGhlIG1hc3Mgc3BlY3RydW0gb2YgYSByYW5nZSBvZiBp
b25zIG9yIGEgc3BlY2lmaWMgaW9uIiBbUFNJOkdQU10NCnJlbGF0aW9uc2hpcDogcGFydF9vZiBQ
U0k6MDAwMDAwMCAhIG16T250b2xvZ3kNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAwMzYNCm5hbWU6
IFNjYW4gTW9kZQ0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQU10NCmlzX29i
c29sZXRlOiB0cnVlDQoNCi1EYXRhQXJyYXlDb250ZW50VHlwZQ0KDQoNCg0KW1Rlcm1dDQppZDog
UFNJOjEwMDAxMzkNCm5hbWU6IDQwMDAgUSBUUkFQDQpkZWY6ICJBcHBsaWVkIEJpb3N5c3RlbXMv
TURTIFNDSUVYIFEgNDAwMCBUUkFQIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEg
TW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNDANCm5hbWU6IDQ3MDAgUHJvdGVvbWljIEFu
YWx5emVyDQpkZWY6ICJBcHBsaWVkIEJpb3N5c3RlbXMvTURTIFNDSUVYIDQ3MDAgUHJvdGVvbWlj
IEFuYWx5emVyIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rl
cm1dDQppZDogUFNJOjEwMDAxNDENCm5hbWU6IEFQRVggSVYNCmRlZjogIkJydWtlciBEYWx0b25p
Y3MgQVBFWCBJViBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltU
ZXJtXQ0KaWQ6IFBTSToxMDAwMTQyDQpuYW1lOiBBUEVYLVENCmRlZjogIkJydWtlciBEYWx0b25p
Y3MgQVBFWC1RIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rl
cm1dDQppZDogUFNJOjEwMDAxNDMNCm5hbWU6IEFQSSAxNTBFWA0KZGVmOiAiQXBwbGllZCBCaW9z
eXN0ZW1zL01EUyBTQ0lFWCBBUEkgMTUwRVggTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAw
MzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE0NA0KbmFtZTogQVBJIDE1MEVYIFBy
ZXANCmRlZjogIkFwcGxpZWQgQmlvc3lzdGVtcy9NRFMgU0NJRVggQVBJIDE1MEVYIFByZXAgTVMi
IFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6
MTAwMDE0NQ0KbmFtZTogQVBJIDIwMDANCmRlZjogIkFwcGxpZWQgQmlvc3lzdGVtcy9NRFMgU0NJ
RVggQVBJIDIwMDAgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpb
VGVybV0NCmlkOiBQU0k6MTAwMDE0Ng0KbmFtZTogQVBJIDMwMDANCmRlZjogIkFwcGxpZWQgQmlv
c3lzdGVtcy9NRFMgU0NJRVggQVBJIDMwMDAgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAw
MzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE0Nw0KbmFtZTogQVBJIDQwMDANCmRl
ZjogIkFwcGxpZWQgQmlvc3lzdGVtcy9NRFMgU0NJRVggQVBJIDQwMDAgTVMiIFtQU0k6R1BTXQ0K
aXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE0OA0KbmFt
ZTogYXV0b0ZsZXggSUkNCmRlZjogIkJydWtlciBEYWx0b25pY3MgYXV0b0ZsZXggSUkgTVMiIFtQ
U0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAw
MDE0OQ0KbmFtZTogYXV0b0ZsZXggVE9GL1RPRg0KZGVmOiAiQnJ1a2VyIERhbHRvbmljcyBhdXRv
RmxleCBUT0YvVE9GIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0K
W1Rlcm1dDQppZDogUFNJOjEwMDAxNTANCm5hbWU6IEF1dG8gU3BlYyBVbHRpbWEgTlQNCmRlZjog
IldhdGVycyBBdXRvU3BlYyBVbHRpbWEgTlQgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAw
MzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE1MQ0KbmFtZTogQmlvIFRPRiBJSQ0K
ZGVmOiAiQnJ1a2VyIERhbHRvbmljcyBCaW9UT0YgSUkgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJ
OjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE1Mg0KbmFtZTogQmlvIFRP
RiBRDQpkZWY6ICJCcnVrZXIgRGFsdG9uaWNzIEJpb1RPRiBRIE1TIiBbUFNJOkdQU10NCmlzX2E6
IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNTMNCm5hbWU6IERF
TFRBIHBsdXNBZHZhbnRhZ2UNCmRlZjogIlRoZXJtb0Zpbm5pZ2FuIERFTFRBcGx1c0FkdmFudGFn
ZSBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0KaWQ6
IFBTSToxMDAwMTU0DQpuYW1lOiBERUxUQXBsdXNYUA0KZGVmOiAiVGhlcm1vRmlubmlnYW4gREVM
VEFwbHVzWFAgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVy
bV0NCmlkOiBQU0k6MTAwMDE1NQ0KbmFtZTogRUxFTUVOVDINCmRlZjogIlRoZXJtb0Zpbm5pZ2Fu
IEVMRU1FTlQyIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rl
cm1dDQppZDogUFNJOjEwMDAxNTYNCm5hbWU6IGVzcXVpcmU0MDAwDQpkZWY6ICJCcnVrZXIgRGFs
dG9uaWNzIGVzcXVpcmU0MDAwIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9k
ZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNTcNCm5hbWU6IGVzcXVpcmU2MDAwDQpkZWY6ICJC
cnVrZXIgRGFsdG9uaWNzIGVzcXVpcmU2MDAwIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAw
MDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNTgNCm5hbWU6IEV4cGxvcmVyDQpk
ZWY6ICJJb25TcGVjIEV4cGxvcmVyIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEg
TW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNTkNCm5hbWU6IEdDVA0KZGVmOiAiV2F0ZXJz
IEdDVCBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0K
aWQ6IFBTSToxMDAwMTYwDQpuYW1lOiBIQ1QNCmRlZjogIkJydWtlciBEYWx0b25pY3MgSENUIE1T
IiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJ
OjEwMDAxNjENCm5hbWU6IEhDVCBQbHVzDQpkZWY6ICJCcnVrZXIgRGFsdG9uaWNzIEhDVFBsdXMg
TVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQ
U0k6MTAwMDE2Mg0KbmFtZTogSGlSZXMgRVNJDQpkZWY6ICJJb25TcGVjIEhpUmVzRVNJIE1TIiBb
UFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEw
MDAxNjMNCm5hbWU6IEhpUmVzIE1BTERJDQpkZWY6ICJJb25TcGVjIEhpUmVzTUFMREkgTVMiIFtQ
U0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAw
MDE2NA0KbmFtZTogSXNvUHJpbWUNCmRlZjogIldhdGVycyBJc29QcmltZSBNUyIgW1BTSTpHUFNd
DQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMTY1DQpu
YW1lOiBJc29Qcm9iZQ0KZGVmOiAiV2F0ZXJzIElzb1Byb2JlIE1TIiBbUFNJOkdQU10NCmlzX2E6
IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNjYNCm5hbWU6IElz
b1Byb2JlIFQNCmRlZjogIldhdGVycyBJc29Qcm9iZSBUIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBT
SToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNjcNCm5hbWU6IExDUSBB
ZHZhbnRhZ2UNCmRlZjogIlRoZXJtb0Zpbm5pZ2FuIExDUSBBZHZhbnRhZ2UgTVMiIFtQU0k6R1BT
XQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE2OA0K
bmFtZTogTENRIENsYXNzaWMNCmRlZjogIlRoZXJtb0Zpbm5pZ2FuIExDUSBDbGFzc2ljIE1TIiBb
UFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEw
MDAxNjkNCm5hbWU6IExDUSBEZWNhIFhQIFBsdXMNCmRlZjogIlRoZXJtb0Zpbm5pZ2FuIExDUSBE
ZWNhIFhQIFBsdXMgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpb
VGVybV0NCmlkOiBQU0k6MTAwMDE3MA0KbmFtZTogTUBMREkgTA0KZGVmOiAiV2F0ZXJzIE1ATERJ
IEwgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlk
OiBQU0k6MTAwMDE3MQ0KbmFtZTogTUBMREkgTFINCmRlZjogIldhdGVycyBNQExESSBMUiBNUyIg
W1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0KaWQ6IFBTSTox
MDAwMTcyDQpuYW1lOiBNQVQyNTMNCmRlZjogIlRoZXJtb0Zpbm5pZ2FuIE1BVDI1MyBNUyIgW1BT
STpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAw
MTczDQpuYW1lOiBNQVQ5MDBYUA0KZGVmOiAiVGhlcm1vRmlubmlnYW4gTUFUOTAwWFAgTVMiIFtQ
U0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAw
MDE3NA0KbmFtZTogTUFUOTAwWFAgVHJhcA0KZGVmOiAiVGhlcm1vRmlubmlnYW4gTUFUOTAwWFAg
VHJhcCBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0K
aWQ6IFBTSToxMDAwMTc1DQpuYW1lOiBNQVQ5NVhQDQpkZWY6ICJUaGVybW9GaW5uaWdhbiBNQVQ5
NVhQIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQpp
ZDogUFNJOjEwMDAxNzYNCm5hbWU6IE1BVDk1WFAgVHJhcA0KZGVmOiAiVGhlcm1vRmlubmlnYW4g
TUFUOTVYUCBUcmFwIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0K
W1Rlcm1dDQppZDogUFNJOjEwMDAxNzcNCm5hbWU6IG1pY3JvRmxleA0KZGVmOiAiQnJ1a2VyIERh
bHRvbmljcyBtaWNyb0ZsZXggTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2Rl
bA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE3OA0KbmFtZTogbWljcm9UT0ZMQw0KZGVmOiAiQnJ1
a2VyIERhbHRvbmljcyBtaWNyb1RPRkxDIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMx
ICEgTW9kZWwNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxNzkNCm5hbWU6IE5lcHR1bmUNCmRlZjog
IlRoZXJtb0Zpbm5pZ2FuIE5FUFRVTkUgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEg
ISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE4MA0KbmFtZTogTkctNTQwMA0KZGVmOiAi
V2F0ZXJzIE5HLTU0MDAgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0K
DQpbVGVybV0NCmlkOiBQU0k6MTAwMDE4MQ0KbmFtZTogT01FR0ENCmRlZjogIklvblNwZWMgT01F
R0EgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlk
OiBQU0k6MTAwMDE4Mg0KbmFtZTogT01FR0EtMjAwMQ0KZGVmOiAiSW9uU3BlYyBPTUVHQS0yMDAx
IE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDog
UFNJOjEwMDAxODMNCm5hbWU6IE9tbmlGbGV4DQpkZWY6ICJCcnVrZXIgRGFsdG9uaWNzIE9taW5G
bGV4IE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQpp
ZDogUFNJOjEwMDAxODQNCm5hbWU6IFBsYXRmb3JtIElDUA0KZGVmOiAiV2F0ZXJzIFBsYXRmb3Jt
IElDUCBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0K
aWQ6IFBTSToxMDAwMTg1DQpuYW1lOiBQb2xhcmlzUQ0KZGVmOiAiVGhlcm1vRmlubmlnYW4gUG9s
YXJpc1EgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0N
CmlkOiBQU0k6MTAwMDE4Ng0KbmFtZTogUHJvdGVvbWljcyBTb2x1dGlvbiAxDQpkZWY6ICJBcHBs
aWVkIEJpb3N5c3RlbXMvTURTIFNDSUVYIFByb3Rlb21pY3MgU29sdXRpb24gMSBNUyIgW1BTSTpH
UFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMTg3
DQpuYW1lOiBRIFRSQVANCmRlZjogIkFwcGxpZWQgQmlvc3lzdGVtcy9NRFMgU0NJRVggUSBUUkFQ
IE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDog
UFNJOjEwMDAxODgNCm5hbWU6IFEtVG9mIG1pY3JvDQpkZWY6ICJXYXRlcnMgUS1Ub2YgbWljcm8g
TVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQ
U0k6MTAwMDE4OQ0KbmFtZTogUS1Ub2YgVWx0aW1hDQpkZWY6ICJXYXRlcnMgUS1Ub2YgVWx0aW1h
IE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rlcm1dDQppZDog
UFNJOjEwMDAxOTANCm5hbWU6IFFTVEFSDQpkZWY6ICJBcHBsaWVkIEJpb3N5c3RlbXMvTURTIFND
SUVYIFFTVEFSIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rl
cm1dDQppZDogUFNJOjEwMDAxOTENCm5hbWU6IFF1YXR0cm8gbWljcm8NCmRlZjogIldhdGVycyBR
dWF0dHJvIG1pY3JvIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0K
W1Rlcm1dDQppZDogUFNJOjEwMDAxOTINCm5hbWU6IFF1YXR0cm8gVUl0aW1hDQpkZWY6ICJXYXRl
cnMgUXVhdHRybyBVaXRpbWEgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2Rl
bA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE5Mw0KbmFtZTogU3VydmV5b3IgTVNRDQpkZWY6ICJU
aGVybW9GaW5uaWdhbiBTdXJ2ZXlvciBNU1EgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAw
MzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDE5NA0KbmFtZTogU3ltQmlvdCBJDQpk
ZWY6ICJBcHBsaWVkIEJpb3N5c3RlbXMvTURTIFNDSUVYIFN5bUJpb3QgSSBNUyIgW1BTSTpHUFNd
DQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMTk1DQpu
YW1lOiBTeW1CaW90IFhWSQ0KZGVmOiAiQXBwbGllZCBCaW9zeXN0ZW1zL01EUyBTQ0lFWCBTeW1C
aW90IFhWSSBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1vZGVsDQoNCltUZXJt
XQ0KaWQ6IFBTSToxMDAwMTk2DQpuYW1lOiBURU1QVVMgVE9GDQpkZWY6ICJUaGVybW9GaW5uaWdh
biBURU1QVVMgVE9GIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0K
W1Rlcm1dDQppZDogUFNJOjEwMDAxOTcNCm5hbWU6IFRSQUNFIERTUQ0KZGVmOiAiVGhlcm1vRmlu
bmlnYW4gVFJBQ0UgRFNRIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwN
Cg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxOTgNCm5hbWU6IFRSSVRPTg0KZGVmOiAiVGhlcm1vRmlu
bmlnYW4gVFJJVE9OIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0K
W1Rlcm1dDQppZDogUFNJOjEwMDAxOTkNCm5hbWU6IFRTUSBRVUFOVFVNDQpkZWY6ICJUaGVybW9G
aW5uaWdhbiBUU1EgUVVBTlRVTSBNUyIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDAzMSAhIE1v
ZGVsDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMjAwDQpuYW1lOiBVbHRpbWENCmRlZjogIklvblNw
ZWMgVWx0aW1hIE1TIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDMxICEgTW9kZWwNCg0KW1Rl
cm1dDQppZDogUFNJOjEwMDAyMDENCm5hbWU6IHVsdHJhRmxleA0KZGVmOiAiQnJ1a2VyIERhbHRv
bmljcyB1bHRyYUZsZXggTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0K
DQpbVGVybV0NCmlkOiBQU0k6MTAwMDIwMg0KbmFtZTogdWx0cmFGbGV4IFRPRi9UT0YNCmRlZjog
IkJydWtlciBEYWx0b25pY3MgdWx0cmFGbGV4IFRPRi9UT0YgTVMiIFtQU0k6R1BTXQ0KaXNfYTog
UFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDIwMw0KbmFtZTogVm95
YWdlci1ERSBQUk8NCmRlZjogIkFwcGxpZWQgQmlvc3lzdGVtcy9NRFMgU0NJRVggVm95YWdlci1E
RSBQUk8gTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJOjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0N
CmlkOiBQU0k6MTAwMDIwNA0KbmFtZTogVm95YWdlci1ERSBTVFINCmRlZjogIkFwcGxpZWQgQmlv
c3lzdGVtcy9NRFMgU0NJRVggVm95YWdlci1ERSBTVFIgTVMiIFtQU0k6R1BTXQ0KaXNfYTogUFNJ
OjEwMDAwMzEgISBNb2RlbA0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDQ0MQ0KbmFtZTogU2Nhbg0K
ZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQU10NCnJlbGF0aW9uc2hpcDogcGFy
dF9vZiBQU0k6MDAwMDAwMCAhIG16T250b2xvZ3kNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDA0NDIN
Cm5hbWU6IFNwZWN0cnVtDQpkZWY6ICJUT0RPOiBBZGQgZGVmaW5pdGlvbi4iIFtQU0k6R1BTXQ0K
cmVsYXRpb25zaGlwOiBwYXJ0X29mIFBTSTowMDAwMDAwICEgbXpPbnRvbG9neQ0KDQpbVGVybV0N
CmlkOiBQU0k6MTAwMDQ0Mw0KbmFtZTogTWFzcyBBbmFseXplcg0KZGVmOiAiVE9ETzogQWRkIGRl
ZmluaXRpb24uIiBbUFNJOkdQU10NCnJlbGF0aW9uc2hpcDogcGFydF9vZiBQU0k6MDAwMDAwMCAh
IG16T250b2xvZ3kNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDA0NDQNCm5hbWU6IG0veiBTZXBhcmF0
aW9uIE1ldGhvZA0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQU10NCnJlbGF0
aW9uc2hpcDogcGFydF9vZiBQU0k6MDAwMDAwMCAhIG16T250b2xvZ3kNCg0KW1Rlcm1dDQppZDog
UFNJOjEwMDA0NDUNCm5hbWU6IFNlcXVlbnRpYWwgbS96IFNlcGFyYXRpb24gTWV0aG9kDQpkZWY6
ICJUT0RPOiBBZGQgZGVmaW5pdGlvbi4iIFtQU0k6R1BTXQ0KcmVsYXRpb25zaGlwOiBwYXJ0X29m
IFBTSTowMDAwMDAwICEgbXpPbnRvbG9neQ0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDAzNg0KbmFt
ZTogU2NhbiBNb2RlDQpkZWY6ICJUT0RPOiBBZGQgZGVmaW5pdGlvbi4iIFtQU0k6R1BTXQ0KaXNf
b2Jzb2xldGU6IHRydWUNCg0KDQpbVGVybV0NCmlkOiBQU0k6MTAwMDEyNw0KbmFtZTogQ2VudHJv
aWQgTWFzcyBTcGVjdHJ1bQ0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQU10N
CmlzX2E6IFBTSToxMDAwMDM1ICEgUGVhayBQcm9jZXNzaW5nDQoNCltUZXJtXQ0KaWQ6IFBTSTox
MDAwMTI4DQpuYW1lOiBDb250aW51dW0gTWFzcyBTcGVjdHJ1bQ0KZGVmOiAiVE9ETzogQWRkIGRl
ZmluaXRpb24uIiBbUFNJOkdQU10NCmlzX2E6IFBTSToxMDAwMDM1ICEgUGVhayBQcm9jZXNzaW5n
DQoNCg0KW1Rlcm1dDQppZDogUFNJOjEwMDAxMzENCm5hbWU6IE51bWJlciBPZiBDb3VudHMNCmRl
ZjogIlRPRE86IEFkZCBkZWZpbml0aW9uLiIgW1BTSTpHUFNdDQppc19hOiBQU0k6MTAwMDA0MyAh
IEludGVuc2l0eSBVbml0DQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwMTMyDQpuYW1lOiBQZXJjZW50
IE9mIEJhc2UgUGVhaw0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQU10NCmlz
X2E6IFBTSToxMDAwMDQzICEgSW50ZW5zaXR5IFVuaXQNCg0KDQpbVGVybV0NCmlkOiBQU0k6MTAw
MDEzOA0KbmFtZTogUGVyY2VudA0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQ
U10NCmlzX2E6IFBTSToxMDAwMDQ2ICEgRW5lcmd5IFVuaXQNCg0KDQpbVGVybV0NCmlkOiBQU0k6
MTAwMDQ0MQ0KbmFtZTogU2Nhbg0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQ
U10NCnJlbGF0aW9uc2hpcDogcGFydF9vZiBQU0k6MDAwMDAwMCAhIG16T250b2xvZ3kNCg0KW1Rl
cm1dDQppZDogUFNJOjEwMDA0NDINCm5hbWU6IFNwZWN0cnVtDQpkZWY6ICJUT0RPOiBBZGQgZGVm
aW5pdGlvbi4iIFtQU0k6R1BTXQ0KcmVsYXRpb25zaGlwOiBwYXJ0X29mIFBTSTowMDAwMDAwICEg
bXpPbnRvbG9neQ0KDQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwNDQzDQpuYW1lOiBNYXNzIEFuYWx5
emVyDQpkZWY6ICJUT0RPOiBBZGQgZGVmaW5pdGlvbi4iIFtQU0k6R1BTXQ0KcmVsYXRpb25zaGlw
OiBwYXJ0X29mIFBTSTowMDAwMDAwICEgbXpPbnRvbG9neQ0KDQoNCltUZXJtXQ0KaWQ6IFBTSTox
MDAwNDQ0DQpuYW1lOiBtL3ogU2VwYXJhdGlvbiBNZXRob2QNCmRlZjogIlRPRE86IEFkZCBkZWZp
bml0aW9uLiIgW1BTSTpHUFNdDQpyZWxhdGlvbnNoaXA6IHBhcnRfb2YgUFNJOjAwMDAwMDAgISBt
ek9udG9sb2d5DQoNCltUZXJtXQ0KaWQ6IFBTSToxMDAwNDQ1DQpuYW1lOiBTZXF1ZW50aWFsIG0v
eiBTZXBhcmF0aW9uIE1ldGhvZA0KZGVmOiAiVE9ETzogQWRkIGRlZmluaXRpb24uIiBbUFNJOkdQ
U10NCnJlbGF0aW9uc2hpcDogcGFydF9vZiBQU0k6MDAwMDAwMCAhIG16T250b2xvZ3kNCg0KDQoN
Cg0KDQoNCg0KDQoNClRlcm1zIHdlIGRlY2lkZWQgbm90IHRvIGFkZDoNCg0KDQotIEFuYWx5dGVJ
ZGVudGlmaWVyIC0gc2FtZSBhcyBTYW1wbGUgTmFtZSAoUFNJOjEwMDAwMDIpLCBhbmQvb3IgU2Ft
cGxlDQoNCk51bWJlciAoUFNJOjEwMDAwMDEpDQoNCi0gQmFzZVBlYWtNeiAtIHNhbWUgYXMgQmFz
ZSBQZWFrLCBQU0k6MTAwMDIxMA0KDQoNCi0gSW5zdHJ1bWVudElkZW50aWZpZXIuIFNhbWUgYXMg
SW5zdHJ1bWVudFNlcmlhbE51bWJlci4NCg0KDQoNCg==

Re: [Psidev-ms-dev] dataXML and spectral library support

[Pierre-Alain B. <pie...@is...>]

Thanks Karl for these proposals.
Timewise, I believe we can define and decide how to support library 
searches in the way you propose in Lyon.
Will you be available there (do you have the possibility to come) or in 
another way remotely in case?

Pierre-Alain


Karl Clauser wrote:
>
> Hi folks,
>
> >- Do we support properly the spectrum "library" use case?
>
>             dataXML is supposed to be for MS instrument raw data, not 
> interpreted data, i.e. with assignments. That is what analysisXML is 
> intended for.
>
> I do not espouse the view that dataXML should contain peptide 
> interpretation for individual MS/MS scans (db, de-novo, or otherwise). 
> dataXML is sensibly intended for spectral information, raw or 
> processed. Association of the interpretation information and the 
> individual spectrum in the dataXML file could come from analysisXML or 
> elsewhere.
>
>  
>
> The extent to which dataXML could usefully and easily support spectral 
> libraries is to facilitate that a dataXML file could contain a 
> collection of MS/MS spectra that may have been derived from one or 
> more LC/MS/MS runs. I personally envision that all spectra are at 
> least derived from the same type of instrument
>
> To effectively meet that objective the schema simply needs to support:
>
> 1.       A spectrum name as a string (I expect this would not contain 
> a full path but instead be more like a .dta or .pkl name: 
> runame.firstScanNum.LastScanNum.charge.pkl)
>
> 2.       Spectral parameters on a per spectrum basis: i.e. resolution, 
> dissociation mode, collision energy
>
> 3.       Index attribute expansion where there can be additional 
> attributes other than scan number in the index element: i.e. spectrum 
> Name, precursor m/z, precursor charge. These would be used for sorting 
> and rapid access to selectively retrieve individual scans. Personally 
> I favor the index as a separate file rather than appended to the end 
> as in mzXML.
>
>  
>
> --Karl
>
> ---------------------------------------------------
>
> Karl R. Clauser
>
> Research Scientist III
>
> Broad Institute of MIT and Harvard
>
> 7 Cambridge Center
>
> Cambridge, MA 02142
>
> Ph. 617-324-9719
>
> E-mail: cl...@br... <mailto:cl...@br...>
>
>  
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

[Psidev-ms-dev] dataXML and spectral library support

[Karl C. <cl...@br...>]

Hi folks,

>- Do we support properly the spectrum "library" use case?

            dataXML is supposed to be for MS instrument raw data, not
interpreted data, i.e. with assignments. That is what analysisXML is
intended for.

I do not espouse the view that dataXML should contain peptide interpretation
for individual MS/MS scans (db, de-novo, or otherwise). dataXML is sensibly
intended for spectral information, raw or processed. Association of the
interpretation information and the individual spectrum in the dataXML file
could come from analysisXML or elsewhere.

 

The extent to which dataXML could usefully and easily support spectral
libraries is to facilitate that a dataXML file could contain a collection of
MS/MS spectra that may have been derived from one or more LC/MS/MS runs. I
personally envision that all spectra are at least derived from the same type
of instrument

To effectively meet that objective the schema simply needs to support:

1.       A spectrum name as a string (I expect this would not contain a full
path but instead be more like a .dta or .pkl name:
runame.firstScanNum.LastScanNum.charge.pkl)

2.       Spectral parameters on a per spectrum basis: i.e. resolution,
dissociation mode, collision energy

3.       Index attribute expansion where there can be additional attributes
other than scan number in the index element: i.e. spectrum Name, precursor
m/z, precursor charge. These would be used for sorting and rapid access to
selectively retrieve individual scans. Personally I favor the index as a
separate file rather than appended to the end as in mzXML.

 

--Karl

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

Karl R. Clauser

Research Scientist III

Broad Institute of MIT and Harvard

7 Cambridge Center

Cambridge, MA 02142

Ph. 617-324-9719

E-mail: cl...@br...

 

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

Hi everyone, here are my notes from the ccall, thank's for attending.

Regards,
Eric

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

Open issues with dataXML

- Need documentation of each element and attribute
  Mike Coleman  2007-02-06
  Agreed. Does Kent have some start of documentation from
current/previous XMLSpy docs?

Eric will contact Kent directly

- Need more specifics on the desired numerical formats (e.g., IEEE,
etc.)
  Mike Coleman  2007-02-06
  To be discussed in Lyon

- Should there be "count" attributes?
  Frederik Levander  2007-02-06
  This is useful for some parsers. Probably leave in place. Discuss in
Lyon

- Should file index be within the file or in a separate file?
  Frederik Levander  2007-02-06
  The implementation of dataXML to be presented at Lyon will include
this information in the same file. Further discussion deferred to the
Lyon meeting The question was there: Should the file name / checksum
information be held in a separate file?

- Encoded filename should be element content instead of an attribute, so
that CDATA could be used
  Alex Masselot  2007-02-07
  To be discussed in Lyon

- Should controlled vocabulary term values also be element content
instead of attribute so that CDATA could be used?
  Alex Masselot  2007-02-07
  To be discussed in Lyon

- How will we handle multiple charges for parent peak, and fragmentation
peaks?
  Alex Masselot  2007-02-07
  This is already handled - mutliple cvParams of the same type can be
used to annotate one peak / spectrum.

- How can we allow two cv terms to be linked, such as concept with value
and the associated units (a separate cv term). (e.g. "collision
energy"=3D35.0 & "energy units"=3D"joules")
  Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
  Phil to post to list for further responses

Phil suggested 2 possibilities: <annotation> and additional attributes
Angel suggested doing the FuGE way. Maybe overkill? Difficult for
software to handle?
Do we really need having both or could we encode the units within the
terms, e.g. "collision energy in joules"
Most other relevant CVs don't seem to encode units as part of the term
Defer this to Lyon? Try to include the CV folks in a conference call
during meeting
Do we need to have specific types of relationships between linked terms,
like "has_units"?

- People still wrinkle their nose when hearing the "dataXML" name.  We
have a suggestion on the floor to rename to "mzDataXML".  Comments?

- Make sure dataXML web site is up to date as can be

- DONE Add link to XMLSpy-generated documentation at:
=20
http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.htm
l

- Get the indexing wrapper schema working properly
  Jayson Falkner  2006-11-15

- Make sure that Karl Klauser is invited to be involved

Eric will send email.

- Do we support properly the spectrum "library" use case?
  Karl Klauser 2007-01-18
  dataXML is supposed to be for MS instrument raw data, not interpreted
data, i.e. with assignments. That is what analysisXML is intended for.

Still open questions here. If analysisXML doesn't includes spectra, this
would be tricky.

- Examine the mapping with MIAPE. Do we support everything MIAPE
requires?
  Pierre-Alain Binz  2007-03-30
  This will be addressed in Lyon

- Revisit the chromatogram use case and develop a good example


Controlled Vocabulary Issues:

Trish sent out a new version of the CV this morning.
New terms from Dave Horn added
Will start keeping and posting release notes
Pete should start working on this new version now
Pete, Trish, and I will iterate on CV a little and there will be another
ccall in 1 week exactly to discuss further
We should post the OBO file soon on OBO.

We will meet again in a week roughly, but Pete can't do next Tue 9am

- DONE. Add hyperlink to the current CV on the web site
  http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo

- Should we change the ontology namespace to PSI-MS?
  Trish Whetzel  2007-03-27
  Was suggested in Washington already and we decided no?

- What is the overlap/division between the PSI-MS CV, the main PSI CV,
OBI?
  Trish Whetzel, Luisa Montecchi  2007-03-30
  To be sorted out in a special working session in Lyon?

- Should we even have an InstrumentIdentifier (local to lab) term at
all?
  Trish Whetzel  2007-03-19

- What is required from vendors?
  Pierre-Alain  2007-04-03

- How do we deal with the common PSI CV?
  Pierre-Alain  2007-04-03

- What is the overlap with OBO ontology "ProPreo"?
  ProPreo: A comprehensive proteomics data and process provenance
ontology
  http://lsdis.cs.uga.edu/projects/glycomics/propreo/
  Eric Deutsch  2007-04-03

Trish says there was a quick review of this ~ 8 months ago
ProPreo is broader but not deep enough

- Try to reconcile the latest instance document and the current PSI
ontology:
  Trish Whetzel  2007-03-30
  Eric Deutsch responded 2007-04-03
  (full exchange not repro'ed here)
  Pete or someone trying to resolve based on discussion thus far and
identify unresolved?

[Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

Hi everyone, here is a summary of the issues before us regarding
dataXML.  Please read it over and let's discuss at the conference call
on Tuesday. Call information:

MS-WG ccall Tuesday, 9am PDT, 12n EDT, 4pm GMT

- Phone numbers:
  + Germany: 08001012079
  + Switzerland: 0800000860
  + UK: 08081095644
  + USA: 18663143683
  + Generic international: +44 2083222500 (UK number)

access code: 297427

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

Open issues with dataXML

- Need documentation of each element and attribute
  Mike Coleman  2007-02-06
  Agreed. Does Kent have some start of documentation from
current/previous XMLSpy docs?

- Need more specifics on the desired numerical formats (e.g., IEEE,
etc.)
  Mike Coleman  2007-02-06
  To be discussed in Lyon

- Should there be "count" attributes?
  Frederik Levander  2007-02-06
  This is useful for some parsers. Probably leave in place. Discuss in
Lyon

- Should file index be within the file or in a separate file?
  Frederik Levander  2007-02-06
  The implementation of dataXML to be presented at Lyon will include
this information in the same file. Further discussion deferred to the
Lyon meeting The question was there: Should the file name / checksum
information be held in a separate file?

- Encoded filename should be element content instead of an attribute, so
that CDATA could be used
  Alex Masselot  2007-02-07
  To be discussed in Lyon

- Should controlled vocabulary term values also be element content
instead of attribute so that CDATA could be used?
  Alex Masselot  2007-02-07
  To be discussed in Lyon

- How will we handle multiple charges for parent peak, and fragmentation
peaks?
  Alex Masselot  2007-02-07
  This is already handled - mutliple cvParams of the same type can be
used to annotate one peak / spectrum.

- How can we allow two cv terms to be linked, such as concept with value
and the associated units (a separate cv term). (e.g. "collision
energy"=3D35.0 & "energy units"=3D"joules")
  Phil Jones  2007-02-27  (followup by Angel and Kent 02-28)
  Phil to post to list for further responses

- People still wrinkle their nose when hearing the "dataXML" name.  We
have a suggestion on the floor to rename to "mzDataXML".  Comments?

- Make sure dataXML web site is up to date as can be

- DONE Add link to XMLSpy-generated documentation at:
=20
http://gelbank.anl.gov/schema/documentations/dataXML0.11/dataXML0.11.htm
l

- Get the indexing wrapper schema working properly
  Jayson Falkner  2006-11-15

- Make sure that Karl Klauser is invited to be involved

- Do we support properly the spectrum "library" use case?
  Karl Klauser 2007-01-18
  dataXML is supposed to be for MS instrument raw data, not interpreted
data, i.e. with assignments. That is what analysisXML is intended for.

- Examine the mapping with MIAPE. Do we support everything MIAPE
requires?
  Pierre-Alain Binz  2007-03-30
  This will be addressed in Lyon

- Revisit the chromatogram use case and develop a good example


Controlled Vocabulary Issues:

- DONE. Add hyperlink to the current CV on the web site
  http://psidev.sourceforge.net/ms/xml/mzdata/psi-ms-cv-latest.obo

- Should we change the ontology namespace to PSI-MS?
  Trish Whetzel  2007-03-27
  Was suggested in Washington already and we decided no?

- What is the overlap/division between the PSI-MS CV, the main PSI CV,
OBI?
  Trish Whetzel, Luisa Montecchi  2007-03-30
  To be sorted out in a special working session in Lyon?

- Should we even have an InstrumentIdentifier (local to lab) term at
all?
  Trish Whetzel  2007-03-19

- What is required from vendors?
  Pierre-Alain  2007-04-03

- How do we deal with the common PSI CV?
  Pierre-Alain  2007-04-03

- What is the overlap with OBO ontology "ProPreo"?
  ProPreo: A comprehensive proteomics data and process provenance
ontology
  http://lsdis.cs.uga.edu/projects/glycomics/propreo/
  Eric Deutsch  2007-04-03

- Try to reconcile the latest instance document and the current PSI
ontology:
  Trish Whetzel  2007-03-30
  Eric Deutsch responded 2007-04-03
  (full exchange not repro'ed here)
  Pete or someone trying to resolve based on discussion thus far and
identify unresolved?

[Psidev-ms-dev] PSI Spring meeting in 25 days, don't forget to register

[Pierre-Alain B. <pie...@is...>]

Sorry if you get multiple posts, and please distribute to people who 
might be interested.

Dear all,

*The 2007 HUPO Proteomics Standards Initiative Spring Meeting in Lyon 
(France), April 23-25, is approaching*. Lyon is easily accessible from 
its own airport. It is less than an hour away from Geneva and Paris by 
plane and 2h by train.

According to the program and the number of current registrants, the PSI 
Spring Meeting promises to be a serious hands-on workshop. Many working 
groups plan to deliver matured UMLs, XMLs standards, MIAPE documents, 
Controlled Vocabularies and others for area where they are still 
formally missing.

Do not forget to register on the PSI website. Registration form 
available from the meeting page:  http://psidev.info/index.php?q=node/113
There are limited places in the rooms, and particularly for the social 
dinner (a cruise on the Lyon rivers), so be in time...

For more information about the current status of the PSI activities, and 
for you to register to working group mailing lists, visit the PSI 
website at http://psidev.info


Looking forward to meeting you in Lyon,

For the meeting organisation committee and the PSI Steering Group
Pierre-Alain Binz

[Psidev-ms-dev] today's PSI MS phonecall cancelled

[Pierre-Alain B. <pie...@is...>]

Dear all,
this is to mention that today's phone PSI MS conference is cancelled.
For the next one (and last before Lyon, please write your preferences 
on  http://www.doodle.ch/dpfxPyNT8kTj
Note that it is set to 9am PST (and not 8am as for the previous ones)

Cheers,
Pierre-Alain

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

[Psidev-ms-dev] Sean L Seymour/FOS/PEC is out of the office.

[Sean L S. <Sey...@ap...>]

I will be out of the office starting  03/20/2007 and will not return until
04/04/2007.

I may be able to respond to messages sent 3-21-07.
I will be completely unavailable from 3-22 to 3-29 on vacation and then
will be a at conference and checking email infrequently until 4-4-07.