psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] mzIdent opinion

[Chris T. <ch...@eb...>]

Hi to you all. Sorry for the double post if you get both...

After the release of mzData, we are now looking at mzIdent (a.k.a. 
mzProtID/mzAnalysis). I'd like to ask for opinions on something: Someone 
suggested a kind of dual functionality for mzIdent that goes something 
like; (1) use the format to 'wrap up' the data to be analysed (either by 
containment or reference -- either way search engines would still need 
to be able to read mzData) with the parameters to the search engine to 
be employed for the analysis; (2) after the search, add to the submitted 
file by appending the results of that search to it. Note: the file to 
which mzIdent refers could be an mzData file or anything else appropriate.

Also I'd think the format should be designed so that someone could _not_ 
use it this way, and could still just use it to capture the output as 
initially conceived (not impossible I'd say).

As initially conceived, mzIdent was to be specifically for the capture 
of the results of an analysis, relying on tool providers to do the 
grabbing of the (mz)data and parameters separately. I'd really like to 
hear thoughts on this idea though, before we go to far with it.

Cheers, Chris.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Chris Taylor (ch...@eb...)
  HUPO PSI: GPS -- psidev.sf.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Psidev-ms-dev] Using mzData in Software Applications

[Per <pe...@th...>]

Dear all,

as the project manager of, Proteios (http://www.proteios.org/) - a=20
bioinformatics software project in proteomics, I strongly greet the=20
standardization work for mzData. We are currently working on integrating=20
mzData in our (Proteios) data model.

Has anyone done this before - actually used mzData in a software applicatio=
n=20
(apart from validation and the like with standard XML tools)? Putting mzDat=
a=20
into practical use should be very much in the interest of PSI. Unfortunatel=
y=20
there are, in my opinion, a few things which cause (uneccessary?)=20
difficulties in an implementation.

=46irst I would suggest not using common programming language keywords (e.g=
=20
"float") as element/attribute names. This is a possible source of confusion=
=20
and makes simple mapping onto source code data structures more difficult.

Secondly, I wonder wether there is any pressing need for keeping two separa=
te=20
arrays in cases where the apparent meaning is rather one single array of=20
pairs (e.g. "intenArray", "mzArray"). The schema does not enforce the same=
=20
length on these two arrays. I also wonder what the purpose of the attribute=
=20
length is. Can't it be removed, since the length is implicitely given by th=
e=20
number of subelements? Consider the following excerpt from a valid(!) mzDat=
a=20
XML-file:

        <mzArray length=3D"15">
          <float>100</float>
          <float>500</float>
        </mzArray>
        <intenArray length=3D"7">
          <float>10</float>
          <float>100</float>
          <float>20</float>
        </intenArray>

Kind Regards,
Per G=E4rd=E9n

=2D-=20
Per G=E4rd=E9n
Lund Swegene Bioinformatics Platform
Complex Systems Division
Lund University
Sweden
=20
phone: +46 46 2229229
fax:=20
e-mail: pe...@th...=20
=20

[Psidev-ms-dev] Re: minor change requests

[Chris T. <ch...@eb...>]

Okay I'd like to just answer the points below. The schema will be 
available from Monday next week; CV dev is also proceeding. 
Documentation will follow shortly along with instance files a.s.a.p.


> + The "cvUserParamType" doesn't have explicit provision for storing a 
> double (it has string, int, float, time, URI). It would be very useful 
> for us if it included double. Maybe also the mzArrayBinaryType?

Double is now in there (note though that in the binary data the 
single/double-precision thing is covered by the specification of 
32/64-bit precision for the IEEE-754 'float').


> + "mzArrayBinaryType" really needs an attribute to say what endian the 
> data is stored in.

Now in there too as an attribute.


> + We would like to store information other than doubles in 
> "dataArrayBinary" - e.g. charge state. For 'safety' a type attribute 
> (plus endian) would be useful. We would like options for double, float, 
> int and boolean.

Okay here's something more cogent than I could have managed, that I got 
from someone else. It's pretty unequivocal...

"I'm a bit opposed to introducing other number formats to the base64 
encoded arrays. In principle integers and even boolean can be converted 
into IEEE floating points (although it seems, at least for boolean, 
terribly wasteful). And if we introduce other formats to the base64 
encoded arrays, we have to _very_ specific how these formats are encoded 
(e.g. how do Java, C++, C# and Perl handle integer or boolean internally 
-- I don't believe it's in the same way). To be absolutely sure we would 
need to provide implementations for these encodings for all sorts of 
programming languages and even we could (and would) run into problems as 
certain labs/vendors/etc. wouldn't like our implementation (or simply 
wouldn't know about) and come with their own (incompatible) 
implementation..."


> + It's probably been discussed before, but what will instrument vendors 
> do when they don't have the required information:
>    personType:  name, institution

Hopefully something meaningful (dept. head + company?); but if all else 
fails I believe there's a Dr Null Foobar, at the Cipher Institute whose 
name we can abuse ;)


Cheers, Chris.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Chris Taylor (ch...@eb...)
  HUPO PSI: GPS -- psidev.sf.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Psidev-ms-dev] mzData - minor change requests

[David C. <dc...@ma...>]

Hi,
I hear from Chris Taylor that there is the intention to "polish off" the 
mzData schema with all the proposed changes at the end of this month. 
Having looked a little more closely, we'd like to propose a further few 
minor changes...

+ The "cvUserParamType" doesn't have explicit provision for storing a 
double (it has string, int, float, time, URI). It would be very useful 
for us if it included double. Maybe also the mzArrayBinaryType?

+ "mzArrayBinaryType" really needs an attribute to say what endian the 
data is stored in.

+ We would like to store information other than doubles in 
"dataArrayBinary" - e.g. charge state. For 'safety' a type attribute 
(plus endian) would be useful. We would like options for double, float, 
int and boolean.

+ It's probably been discussed before, but what will instrument vendors 
do when they don't have the required information:
    personType:  name, institution


David

-- 
David Creasy
Matrix Science
8 Wyndham Place
London W1H 1PP
Tel +44 (0)20 7723 2142
Fax +44 (0)20 7725 9360

dc...@ma...
http://www.matrixscience.com


[Psidev-ms-dev] Roland Krause/Cellzome/DE is out of the office.

[<Rol...@ce...>]

I will be out of the office starting  20.02.2004 and will not return until
17.03.2005.

Please contact me via kr...@em...

[Psidev-ms-dev] New website and list

[Chris T. <ch...@eb...>]

Hi all. I am just putting the last bits of text on the new GPS (General 
Proteomics Standards) website -- the focus for all the stuff that isn't 
specific to the mzData format, or PPI. Topics include; MIAPE, the 
minimum reporting requirement for a proteomics experiment; PSI-OM and 
PSI-ML, the new data model and derived XML; PSI-Ont -- our chunk of the 
MGED Ontology (MO); plus general design principle, the comparability of 
various search engine scores and more.

While some documents and reports have yet to go up, the moderated (i.e. 
no spam, guaranteed) email discussion list relating to this area is now 
fully functional -- inter alia, it will be the place that I announce the 
completion of the website (i.e. all files and discussion documents up).

Rather than subscribe you all automatically (and sorry for the redundant 
mail if you already joined it), I thought it best to just alert you and 
offer the link:

https://lists.sourceforge.net/lists/listinfo/psidev-gps-dev/

Scroll down ^that^ page to find sign-up details. Please do sign up and 
keep an eye on the (slightly delayed, sorry) website once I announce its 
completion; things should move quite quickly now in several areas, and 
the more eyes on the ball as we go, the better we'll do.

Cheers, Chris.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Chris Taylor (ch...@eb...)
  HUPO PSI: GPS -- psidev.sf.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] Converting MS data into a XML format that comply with the PSI-MS schema

[Kai R. <kr...@eb...>]

Dear Troels,

the PSI-MS format contains not only the peak-list, but also additional=20=

information related to this experiment, such as instrument settings,=20
information on the precursor, administrative information such as user=20
name and information on the software that was processing this data.
We presented a converter with graphical user interface at the HUPO=20
conference in Montreal. However, due to many suggestions we received we=20=

changed the format and are now in the process of updating the=20
converter. This converter will in the beginning support only simple=20
formats such .dta and .pkl files, but will be continuously extend to=20
support more formats (we did a survey of what formats are commonly used=20=

and will work down this list). A first beta-release should be available=20=

around January/February and a release shortly after. Please check at=20
http://psi-dev.sf.net for news around this time.

Thanks
	Kai

On Tuesday, November 18, 2003, at 12:55 AM, Troels Zakarias Glahn=20
Kristiansen wrote:
> Hi
> =A0
> I would like to make some of my LC-MS/MS=A0data available for public=20=

> download in a format that complys with the PSI-MS format.
> I am however not really sure about how you have envisaged that the=20
> data should be presented.
> Is the format only meant for presenting peak list files or is it=20
> intended that 'raw' data can be contained as well (it is the size of=20=

> the files, I'm concerned about)?
> =A0
> Are there any available tools for converting either peak list files or=20=

> 'raw' files into the correct xml format (pkl-files and raw files=20
> generated from masslynx 4.0)?
> =A0
> I hope the questions make sense.
> =A0
> Cheers
> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Troels
> =A0
> Troels Zakarias Glahn Kristiansen
> Johns Hopkins University, School of Medicine
> Institute of Genetic Medicine
> 2-130 Jefferson Street Building
> 600 N. Wolfe Street
> Baltimore, MD 21287
> =A0
> Tel. 443 287 3527
> Fax. 410 502 7543
> Email: za...@jh...
> =A0
> =A0
> =A0
>
--
Real cats don't need names.
But they often get called them.
"Yaargeroffoutofityarbastard" does nicely.
         Terry Pratchett - The Unadulterated Cat

*********************************************************************
* email: kr...@eb...                                           *
* fon +44 (0)1223 494434 fax +44 (0)1223 494468                     *
* EMBL Outstation - EBI (European Bioinformatics Institute)         *
* Wellcome Trust Genome Campus                                      *
* Hinxton, Cambridge                                                *
* CB10 1SD, United Kingdom                                          *
*********************************************************************

[Psidev-ms-dev] Converting MS data into a XML format that comply with the PSI-MS schema

[Troels Z. G. K. <za...@jh...>]

Hi

I would like to make some of my LC-MS/MS data available for public =
download in a format that complys with the PSI-MS format.=20
I am however not really sure about how you have envisaged that the data =
should be presented.
Is the format only meant for presenting peak list files or is it =
intended that 'raw' data can be contained as well (it is the size of the =
files, I'm concerned about)?

Are there any available tools for converting either peak list files or =
'raw' files into the correct xml format (pkl-files and raw files =
generated from masslynx 4.0)?

I hope the questions make sense.

Cheers
            Troels

Troels Zakarias Glahn Kristiansen
Johns Hopkins University, School of Medicine
Institute of Genetic Medicine
2-130 Jefferson Street Building
600 N. Wolfe Street
Baltimore, MD 21287

Tel. 443 287 3527
Fax. 410 502 7543
Email: za...@jh...

[Psidev-ms-dev] PSI-MS mzData schema updated

[Kai R. <kr...@eb...>]

Hi,

Randy phoned today and we could agree on a new version of the mzData 
schema. :-) I checked it into our sourceforge CVS repository. You can 
download the schema and have a look at the auto-generated documentation 
at:
http://psidev.sourceforge.net/ms/xml/mzdata/
I will update the examples as soon as possible...
This schema doesn't split the information of one collection into 
primary (mass and intensity data) and secondary data (e.g. labels) any 
more, which made the conversion process cumbersome and with large 
data-sets nigh impossible.
Besides resolving this issue, also some renaming of elements took place 
to make the schema easier to understand and easier to generate code 
from.

Regards
	Kai

PS: if no other issue crop up, this should be more or less the final 
version of the schema.
--
Real cats don't need names.
But they often get called them.
"Yaargeroffoutofityarbastard" does nicely.
         Terry Pratchett - The Unadulterated Cat

*********************************************************************
* email: kr...@eb...                                           *
* fon +44 (0)1223 494434 fax +44 (0)1223 494468                     *
* EMBL Outstation - EBI (European Bioinformatics Institute)         *
* Wellcome Trust Genome Campus                                      *
* Hinxton, Cambridge                                                *
* CB10 1SD, United Kingdom                                          *
*********************************************************************

[Psidev-ms-dev] PSI MS group updates

[Weimin Z. <we...@eb...>]

Dear Colleagues,

Please go to http://psidev.sourceforge.net/ms/docs/mid-2003.sum.html to get
some updates of our latest activities.
Please continue to share with us your comments, ideas and suggestions.

Have a nice summer.

Weimin Zhu

[Psidev-ms-dev] ASMS

[Tomer, K. (NIH/NIEHS) <to...@ni...>]

At the Versailles meeting, mention was made of the possibility of a PSI
meeting being held in conjunction with the ASMS meeting in June in Montreal.
Is there one planned?

Regards,

Ken 
Kenneth Tomer, Ph.D.
Leader Mass Spectrometry Group
Laboratory of Structural Biology
NIEHS/NIH
MD F0-03
PO Box 12233
R.T.P., NC 27709
(919) 541-1966

[Psidev-ms-dev] TEsting2

[Henning H. <hh...@eb...>]

[Psidev-ms-dev] Test

[Henning H. <hh...@eb...>]

[Psidev-ms-dev] TEst

[Henning H. <hh...@eb...>]