psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] New mzML accession IDs

[Mike A. <Mik...@kr...>]

Hi,

I would like to make a number of amendments to the mzML controlled vocabulary for the Shimadzu products.

Please rename:

MS:1000602 (Shimadzu Biotech instrument model") to read "Shimadzu Corporation MALDI-TOF instrument model". The name and definition can both read the same.

MS:1001557 (Shimadzu Biotech software) to read "Shimadzu Corporation software". The name and definition can both read the same.

In addition to these modifications I would also like to create the following accession IDs:

Name: MALDI Solutions LC-MALDI
Def: Software for automated LC-MALDI analysis and reporting
is_a: MS:1001455 ! acquisition software
is_a: MS:1001456 ! analysis software
is_a: MS:1001457 ! data processing software
is_a: MS:1001557 ! Shimadzu Corporation software

Name: Shimadzu MALDI-7090
Def: Shimadzu Corporation MALDI-7090: MALDI-TOF
is_a: MS:1000602 ! Shimadzu Corporation MALDI-TOF instrument model

Thanks,
Mike.

Mike Ashton
Head of Software

Kratos Analytical Ltd.
Wharfside, Trafford Wharf Road, Manchester M17 1GP.
Tel: +44 (0) 161 888 4400 Ext 329
Fax: +44 (0) 161 888 4401
Company Number 563161. Registered in England. Registered Offices as above.


________________________________________________________________________
This e-mail has been scanned for all viruses by Claranet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.claranet.co.uk
________________________________________________________________________

Re: [Psidev-ms-dev] Dead URL on http://www.psidev.info/mzml/

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

Hi,
thx for pointing this,
I have updated the link (and a few others as well)
Pierre-Alain

On 11/4/2013 3:07 PM, Nils Hoffmann wrote:
> Hi,
> that must have happened while I adapted the source code organization 
> of the validator to maven standards. Sorry for the inconvenience,
> I did not notice there were external links to the file.
>
> Cheers,
> Nils
>
> Am 04.11.2013 15:02, schrieb Fredrik Levander:
>> The link should probably be updated to this URI:
>> https://svn.code.sf.net/p/psidev/svn/psi/mzml/validator/src/main/resources/ms-mapping.xml
>>
>> The file is identical to the one that was deleted in revision 603.
>>
>> cheers
>>
>> Fredrik
>>
>> On 2013-11-04 14:19, Jones, Andy wrote:
>>>
>>> "Latest mapping file 
>>> <https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml>, 
>>> which defines where certain controlled vocabulary terms may be used 
>>> in a document." This URL is dead,
>>>
>>> Cheers
>>>
>>> Andy
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development platform that
>> developers love is also attractive to malware creators. Download this white
>> paper to learn more about secure code signing practices that can help keep
>> Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> -- 
> Nils Hoffmann                                   phone:    +49-521-106-4342
> Bielefeld University                            room:             U10-144
> Faculty of Technology, Genome Informatics
> P.O. Box 10 01 31
> 33501 Bielefeld, Germany
> http://www.cebitec.uni-bielefeld.de/~hoffmann
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

-- 
Pierre-Alain Binz, PhD
Project Manager
Swiss-Prot group
SIB Swiss Institute of Bioinformatics
Michel-Servet 1
CH-1211 Geneva 4
Switzerland

Re: [Psidev-ms-dev] Dead URL on http://www.psidev.info/mzml/

[Nils H. <nil...@ce...>]

Hi,
that must have happened while I adapted the source code organization of
the validator to maven standards. Sorry for the inconvenience,
I did not notice there were external links to the file.

Cheers,
Nils

Am 04.11.2013 15:02, schrieb Fredrik Levander:
> The link should probably be updated to this URI:
> https://svn.code.sf.net/p/psidev/svn/psi/mzml/validator/src/main/resources/ms-mapping.xml
>
> The file is identical to the one that was deleted in revision 603.
>
> cheers
>
> Fredrik
>
> On 2013-11-04 14:19, Jones, Andy wrote:
>>
>> "Latest mapping file
>> <https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml>,
>> which defines where certain controlled vocabulary terms may be used
>> in a document." This URL is dead,
>>
>> Cheers
>>
>> Andy
>>
>
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev


-- 
Nils Hoffmann                                   phone:    +49-521-106-4342
Bielefeld University                            room:             U10-144
Faculty of Technology, Genome Informatics
P.O. Box 10 01 31
33501 Bielefeld, Germany
http://www.cebitec.uni-bielefeld.de/~hoffmann

Re: [Psidev-ms-dev] Dead URL on http://www.psidev.info/mzml/

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

The link should probably be updated to this URI:
https://svn.code.sf.net/p/psidev/svn/psi/mzml/validator/src/main/resources/ms-mapping.xml

The file is identical to the one that was deleted in revision 603.

cheers

Fredrik

On 2013-11-04 14:19, Jones, Andy wrote:
>
> "Latest mapping file 
> <https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml>, 
> which defines where certain controlled vocabulary terms may be used in 
> a document." This URL is dead,
>
> Cheers
>
> Andy
>

[Psidev-ms-dev] Dead URL on http://www.psidev.info/mzml/

[Jones, A. <And...@li...>]

"Latest mapping file<https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml>, which defines where certain controlled vocabulary terms may be used in a document." This URL is dead,
Cheers
Andy

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

Hi everyone, thank you for the discussion. We should take a poll at some
point to gather as much input as possible.

It is true that there is no schema change and it would not be technically
necessary to call numpressed files version 1.2.

However, it seems to me that it might be considered inappropriate by many
to introduce and even promote a new compression scheme that older readers
cannot know about or handle at all until they receive a significant
update, and blithely retain the version number 1.1.

At the time when we release this officially, there will be several
implementations already, but there will also be a lot of software that
does not support it. If we don't bump the version number, we would be in a
situation where a new kind of mzML 1.1 would arrive in field and there
would be lots of software that could not read *that kind of mzML 1.1*. It
seems aesthetically preferable to me to have lots of software that cannot
read *mzML 1.2*, and be in a position to encourage them to update to 1.2.

It has been pointed out that several extant readers can't even handle
1.1's zlib compression. This is true, but this is an indication that they
don't fully support the standard as it has been used for many years, and
is a different problem. What we're doing here is explicitly introducing
something new that hasn't been seen before and is not backwards
compatible.

Think about it and we should have a poll soon to see how everyone feels. I
clearly lean toward the 1.2 side, but am happy to go the other way if that
is the consensus.

Regards,
Eric


-----Original Message-----
From: Fredrik Levander [mailto:Fre...@im...]
Sent: Thursday, October 24, 2013 8:02 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

Initially we also thought that it would be just fine to add the new
Numpress terms to the CV and go. However, a concern that was raised is
that a reader software that used to be able to read all mzML 1.1 files,
suddenly cannot anymore with these files. Well, interpretation of other
new CV terms could be a problem for mzML reading software that are
supposed to be able to read mzML - but it is usually not that critical.
So that's the argument for a minor schema change: causing schema aware
software to report a more specific error instead of just failing to read
the binaries properly (old files should also validate OK with the new
schema so that there is only one schema to handle for reading software).
However, if everyone is fine with keeping schema intact, and just accept
the possibility to add new compression methods to the CV, that could be
just fine. An addendum to the mzML documentation about compression may
still be useful, though.

Thanks,

Fredrik

On 2013-10-24 16:38, Matt Chambers wrote:
> Sorry, I haven't been checking this list lately...
>
> I totally agree with Steffen (except MSNumPress is a compression of the
> binary data which then must be encoded in base64, which always bloats
> the data by ~33% no matter what compression you've done).
>
> But there are still readers that don't handle zlib compressed mzML or
> mzXML, and the only way those readers should be properly dealing with
> that is through the existing CV mechanism. A bigger concern (because I
> think most readers fall into this category) is for readers that have an
> offline and/or hard-coded version of the CV (like pwiz) that has to be
> kept in sync. Old versions of pwiz won't be able to recognize the new CV
> terms. Looking up new unknown terms online is a long-standing missing
> feature in pwiz, but unfortunately it's still not likely to get added
> soon. I'm not sure how many of the other offline-CV readers have an
> online component yet but I suspect not many.
>
> -Matt
>
>
> On 10/23/2013 2:21 PM, Steffen Neumann wrote:
>> Hi,
>>
>>> A feasible solution is that files that use any new compression scheme
>>> are marked as mzML 1.2.
>>>
>> I am a bit hesitant to support bumping the schema version
>> just for a new encoding of the base64 data:
>>
>> If you have some raw -> mzML converter that had a command line switch
>> whether to num(com)press or not, would that writer need to support
>> both XSD versions and decide between uncompressed mzML-1.1
>> and numpressed mzML-1.2 based on that command line switch ?
>> That doesn't make sense, and writer software would likely
>> write mzML-1.2 compressed or not.
>>
>> Even if the XSD is identical, old 1.1 software that checks
>> the mzML version will fail, even if the mzML-1.2 files
>> contain uncompressed data.
>>
>> All sensible software should look at the cvParams describing
>> the encoding in the <binary>. So please why is it insufficient to
>> just use the already existing MS-numpress terms in the CV ?
>>
>>
http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS:100057
2&termName=binary%20data%20compression%20type
>>
>> 	<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" />
>> 	<cvParam cvRef="MS" accession="MS:1002312" name="MS-Numpress
linear prediction compression" />
>> 	<binary>...</binary>
>>
>>> However, readers that haven't implemented support
>>> for this compression method will break.
>> Yes. and Readers that have not implemented mzML-1.2 will do as well.
>> A reader *must* look for compression cvParams before decoding,
>> and if they encounter something unexpected (i.e. not "no compression"
>> nor "zlib" they should throw some "unknown compression scheme"
>> exception). Or did I miss something ?
>>
>>> However, it would be possible to allow for double compression, i.e.
>>> the use of both numpress and zlib on a binary array, and that would
>>> require a change in the mapping file.
>> Why does that require a change in the mapping ? Even if we'd allow
>> two compression schemes, just having two cvParams won't be specific
>> enough:
>>
>> 	<cvParam cvRef="MS" accession="MS:..." name="zlib" />
>> 	<cvParam cvRef="MS" accession="MS:..." name="MS-numpress" />
>>
>> Which order do you use ? First numpress, then zlib or the other way
around ?
>> (ok, that's obvious here...) but otherwise you would not know the
order.
>> Because we (hope we'd) only have few "sanctioned" compression schemes
and combinations,
>> I'd suggest to encode that in the cvParam, e.g. either
"MS-numpress-zlib"
>> or "zlib-MS-numpress" just as an example.
>> Yours,
>> Steffen
>>
>
>
--------------------------------------------------------------------------
----
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
> the latest Intel processors and coprocessors. See abstracts and register
>
>
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktr
k
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev


--------------------------------------------------------------------------
----
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktr
k
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

Initially we also thought that it would be just fine to add the new 
Numpress terms to the CV and go. However, a concern that was raised is 
that a reader software that used to be able to read all mzML 1.1 files, 
suddenly cannot anymore with these files. Well, interpretation of other 
new CV terms could be a problem for mzML reading software that are 
supposed to be able to read mzML - but it is usually not that critical. 
So that's the argument for a minor schema change: causing schema aware 
software to report a more specific error instead of just failing to read 
the binaries properly (old files should also validate OK with the new 
schema so that there is only one schema to handle for reading software). 
However, if everyone is fine with keeping schema intact, and just accept 
the possibility to add new compression methods to the CV, that could be 
just fine. An addendum to the mzML documentation about compression may 
still be useful, though.

Thanks,

Fredrik

On 2013-10-24 16:38, Matt Chambers wrote:
> Sorry, I haven't been checking this list lately...
>
> I totally agree with Steffen (except MSNumPress is a compression of the
> binary data which then must be encoded in base64, which always bloats
> the data by ~33% no matter what compression you've done).
>
> But there are still readers that don't handle zlib compressed mzML or
> mzXML, and the only way those readers should be properly dealing with
> that is through the existing CV mechanism. A bigger concern (because I
> think most readers fall into this category) is for readers that have an
> offline and/or hard-coded version of the CV (like pwiz) that has to be
> kept in sync. Old versions of pwiz won't be able to recognize the new CV
> terms. Looking up new unknown terms online is a long-standing missing
> feature in pwiz, but unfortunately it's still not likely to get added
> soon. I'm not sure how many of the other offline-CV readers have an
> online component yet but I suspect not many.
>
> -Matt
>
>
> On 10/23/2013 2:21 PM, Steffen Neumann wrote:
>> Hi,
>>
>>> A feasible solution is that files that use any new compression scheme
>>> are marked as mzML 1.2.
>>>
>> I am a bit hesitant to support bumping the schema version
>> just for a new encoding of the base64 data:
>>
>> If you have some raw -> mzML converter that had a command line switch
>> whether to num(com)press or not, would that writer need to support
>> both XSD versions and decide between uncompressed mzML-1.1
>> and numpressed mzML-1.2 based on that command line switch ?
>> That doesn't make sense, and writer software would likely
>> write mzML-1.2 compressed or not.
>>
>> Even if the XSD is identical, old 1.1 software that checks
>> the mzML version will fail, even if the mzML-1.2 files
>> contain uncompressed data.
>>
>> All sensible software should look at the cvParams describing
>> the encoding in the <binary>. So please why is it insufficient to
>> just use the already existing MS-numpress terms in the CV ?
>>
>> http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS:1000572&termName=binary%20data%20compression%20type
>>
>> 	<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" />
>> 	<cvParam cvRef="MS" accession="MS:1002312" name="MS-Numpress linear prediction compression" />
>> 	<binary>...</binary>
>>
>>> However, readers that haven't implemented support
>>> for this compression method will break.
>> Yes. and Readers that have not implemented mzML-1.2 will do as well.
>> A reader *must* look for compression cvParams before decoding,
>> and if they encounter something unexpected (i.e. not "no compression"
>> nor "zlib" they should throw some "unknown compression scheme"
>> exception). Or did I miss something ?
>>
>>> However, it would be possible to allow for double compression, i.e.
>>> the use of both numpress and zlib on a binary array, and that would
>>> require a change in the mapping file.
>> Why does that require a change in the mapping ? Even if we'd allow
>> two compression schemes, just having two cvParams won't be specific
>> enough:
>>
>> 	<cvParam cvRef="MS" accession="MS:..." name="zlib" />
>> 	<cvParam cvRef="MS" accession="MS:..." name="MS-numpress" />
>>
>> Which order do you use ? First numpress, then zlib or the other way around ?
>> (ok, that's obvious here...) but otherwise you would not know the order.
>> Because we (hope we'd) only have few "sanctioned" compression schemes and combinations,
>> I'd suggest to encode that in the cvParam, e.g. either "MS-numpress-zlib"
>> or "zlib-MS-numpress" just as an example.
>> Yours,
>> Steffen
>>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

Sorry, I haven't been checking this list lately...

I totally agree with Steffen (except MSNumPress is a compression of the 
binary data which then must be encoded in base64, which always bloats 
the data by ~33% no matter what compression you've done).

But there are still readers that don't handle zlib compressed mzML or 
mzXML, and the only way those readers should be properly dealing with 
that is through the existing CV mechanism. A bigger concern (because I 
think most readers fall into this category) is for readers that have an 
offline and/or hard-coded version of the CV (like pwiz) that has to be 
kept in sync. Old versions of pwiz won't be able to recognize the new CV 
terms. Looking up new unknown terms online is a long-standing missing 
feature in pwiz, but unfortunately it's still not likely to get added 
soon. I'm not sure how many of the other offline-CV readers have an 
online component yet but I suspect not many.

-Matt


On 10/23/2013 2:21 PM, Steffen Neumann wrote:
> Hi,
>
>> A feasible solution is that files that use any new compression scheme
>> are marked as mzML 1.2.
>>
> I am a bit hesitant to support bumping the schema version
> just for a new encoding of the base64 data:
>
> If you have some raw -> mzML converter that had a command line switch
> whether to num(com)press or not, would that writer need to support
> both XSD versions and decide between uncompressed mzML-1.1
> and numpressed mzML-1.2 based on that command line switch ?
> That doesn't make sense, and writer software would likely
> write mzML-1.2 compressed or not.
>
> Even if the XSD is identical, old 1.1 software that checks
> the mzML version will fail, even if the mzML-1.2 files
> contain uncompressed data.
>
> All sensible software should look at the cvParams describing
> the encoding in the <binary>. So please why is it insufficient to
> just use the already existing MS-numpress terms in the CV ?
>
> http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS:1000572&termName=binary%20data%20compression%20type
>
> 	<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" />
> 	<cvParam cvRef="MS" accession="MS:1002312" name="MS-Numpress linear prediction compression" />
> 	<binary>...</binary>
>
>> However, readers that haven't implemented support
>> for this compression method will break.
> Yes. and Readers that have not implemented mzML-1.2 will do as well.
> A reader *must* look for compression cvParams before decoding,
> and if they encounter something unexpected (i.e. not "no compression"
> nor "zlib" they should throw some "unknown compression scheme"
> exception). Or did I miss something ?
>
>> However, it would be possible to allow for double compression, i.e.
>> the use of both numpress and zlib on a binary array, and that would
>> require a change in the mapping file.
> Why does that require a change in the mapping ? Even if we'd allow
> two compression schemes, just having two cvParams won't be specific
> enough:
>
> 	<cvParam cvRef="MS" accession="MS:..." name="zlib" />
> 	<cvParam cvRef="MS" accession="MS:..." name="MS-numpress" />
>
> Which order do you use ? First numpress, then zlib or the other way around ?
> (ok, that's obvious here...) but otherwise you would not know the order.
> Because we (hope we'd) only have few "sanctioned" compression schemes and combinations,
> I'd suggest to encode that in the cvParam, e.g. either "MS-numpress-zlib"
> or "zlib-MS-numpress" just as an example.
> Yours,
> Steffen
>

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

Hi,

> A feasible solution is that files that use any new compression scheme
> are marked as mzML 1.2.
> 
I am a bit hesitant to support bumping the schema version 
just for a new encoding of the base64 data:

If you have some raw -> mzML converter that had a command line switch 
whether to num(com)press or not, would that writer need to support 
both XSD versions and decide between uncompressed mzML-1.1 
and numpressed mzML-1.2 based on that command line switch ? 
That doesn't make sense, and writer software would likely 
write mzML-1.2 compressed or not.

Even if the XSD is identical, old 1.1 software that checks 
the mzML version will fail, even if the mzML-1.2 files 
contain uncompressed data.

All sensible software should look at the cvParams describing 
the encoding in the <binary>. So please why is it insufficient to 
just use the already existing MS-numpress terms in the CV ?

http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS:1000572&termName=binary%20data%20compression%20type

	<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" />
	<cvParam cvRef="MS" accession="MS:1002312" name="MS-Numpress linear prediction compression" />
	<binary>...</binary>

> However, readers that haven't implemented support
> for this compression method will break.

Yes. and Readers that have not implemented mzML-1.2 will do as well.
A reader *must* look for compression cvParams before decoding,
and if they encounter something unexpected (i.e. not "no compression" 
nor "zlib" they should throw some "unknown compression scheme"
exception). Or did I miss something ?

> However, it would be possible to allow for double compression, i.e.
> the use of both numpress and zlib on a binary array, and that would
> require a change in the mapping file.

Why does that require a change in the mapping ? Even if we'd allow 
two compression schemes, just having two cvParams won't be specific 
enough:

	<cvParam cvRef="MS" accession="MS:..." name="zlib" />
	<cvParam cvRef="MS" accession="MS:..." name="MS-numpress" />

Which order do you use ? First numpress, then zlib or the other way around ?
(ok, that's obvious here...) but otherwise you would not know the order.
Because we (hope we'd) only have few "sanctioned" compression schemes and combinations,
I'd suggest to encode that in the cvParam, e.g. either "MS-numpress-zlib" 
or "zlib-MS-numpress" just as an example.
> 
Yours,
Steffen

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

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

Hi All,

As much of the discussion has been going on off list I thought that I 
could give some background, and also a proposal:

We have developed lightweight numerical compression schemes for binary 
mass spectrometry data intended for compressing the binary arrays in 
mzML. They reduce the file sizes quite dramatically, while still 
maintaining the mzML file in text format. There is already support for 
these compression methods in several tools, and more will follow soon. 
We intend to submit a manuscript describing the compression and 
implementations shortly. Java and C++ libraries can be found here: 
https://github.com/fickludd/ms-numpress/.
If anyone is interested in implementing support for the compression in 
your tool, please contact me and we can provide some input.  There are 
also some implementations which haven't made it to the public versions yet.

The files produced are schematically and semantically valid mzML 1.1.0, 
since the compression methods are defined for the binary arrays using 
ontology terms that are in the current PSI ontology. However, readers 
that haven't implemented support for this compression method will break. 
So there is need to consider this within the mzML standard to prevent a 
mess. The files which use new compression methods should be flagged in 
some way more than the ontology version.

A feasible solution is that files that use any new compression scheme 
are marked as mzML 1.2. An addendum to the mzML documentation should 
describe this new feature. The schema and mapping file wouldn't need any 
updates, except for the version number. However, it would be possible to 
allow for double compression, i.e. the use of both numpress and zlib on 
a binary array, and that would require a change in the mapping file. 
While we wouldn't use double compression in our lab (mzML.gz with 
numpressed binaries is still more efficient when it comes to size), it 
could be good to leave the door open for that as others may want to. So 
we propose an increased mzML version and possibly an updated mapping 
file. mzML files that are not compressed should still be indicated as 1.1.0.

There may well be other binary compression methods that are efficient 
and easy to implement, and if a new mzML version is released, it should 
include support for these. We do want stability when it comes to 
standard formats and no short term changes. It would therefore be good 
to have a public document process with a fixed deadline, sometime next 
year, and anyone can propose compression methods to be included in this 
new mzML version. For evaluating compression methods  we could supply 
test files from different vendors and instrument types used in our 
manuscript, which can be used for benchmarking. If too many different 
compression methods are proposed, the PSI may choose the subset of 
methods that best facilitates different use-cases, while striving to 
minimize the complexity of the standard.

There are also possibilities to represent mzML and other PSI formats in 
binary format, as is done efficiently in mz5, or in more brief text 
formats amenable to compression. However, I would propose to leave that 
to a separate process.

Thanks,

Fredrik

On 2013-10-22 21:16, Eric Deutsch wrote:
>
> PSI MS/PI telecall on numpress mzML compression
>
> Present: Juan Antonio, Andy, Eric, Brian, Fredrik, Johan, Mathias,
>
> - Reviewed the top summary document
>
>   o is missing mz5 zlib
>
>   o also show an mzMLdelta
>
>   o numAllzlib .gz
>
> - Brian added a bit of code to ProteoWizard to limit a potential too 
> high loss. If the actual observed loss exceeds a settable threshold, 
> the spectrum is written uncompressed.
>
> - mz5 files > ~2 GB cannot be read by Pwiz due to a bug. Johann will 
> report
>
> - It does seem from the readspeed figure, mzML with numpress still 
> doesn't compete so well with mz5
>
> - Andy wonders if there are optimizations in the XML parsing. Are many 
> objects being created and discarded during reading?
>
> - Maximum observed delta error across all test files was 0.002 ppm
>
> - Johann has imzML code for ProteoWizard. If he can develop a good 
> patch for the very latest trunk of proteowizard, Brian could probably 
> apply it quickly.
>
> - Andy broaches the concern that if we are going to open the door to 
> lossy compression, maybe we can do a whole lot better. Before the PSI 
> approves any specific approach, we should do some more homework to 
> make sure that anyone currently working on this problem is heard and 
> can contribute and we officially approve the best approach. We don't 
> want to be in a possible where we release one version and then a year 
> from now have another much better compression version.
>
> We will follow up my email and schedule another call.
>
> Thanks,
>
> Eric
>
> *From:*Eric Deutsch [mailto:Eri...@sy... 
> <mailto:Eri...@sy...>]
> *Sent:* Monday, October 21, 2013 8:05 PM
> *To:* Mass spectrometry standard development; 
> psi...@li... 
> <mailto:psi...@li...>
> *Cc:* Eric Deutsch
> *Subject:* RE: PSI MS call Tuesday: compression
>
> Hi everyone, just a reminder that we will have a PSI MS/PI WG 
> teleconference to discuss mzML data compression and related topics in 
> 12 hr.
>
> 08:00 San Francisco
>
> 11:00 New York
>
> 16:00 London
>
> 17:00 Geneva
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-832-8490
>
> Generic international: +44 2083222500 (UK number)
>
> access code: 297427 #
>
> *From:*Eric Deutsch [mailto:ede...@sy... 
> <mailto:ede...@sy...>]
> *Sent:* Friday, October 18, 2013 3:39 PM
> *To:* Mass spectrometry standard development; 
> psi...@li... 
> <mailto:psi...@li...>
> *Cc:* Eric Deutsch
> *Subject:* PSI MS call Tuesday: compression
>
> Hi everyone, let's have a PSI MS/PI WG teleconference call Tuesday at 
> the usual time.
>
> We will have a discussion about the ongoing numpress work to 
> dramatically improve the compression options for mzML.
>
> 08:00 San Francisco
>
> 11:00 New York
>
> 16:00 London
>
> 17:00 Geneva
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-832-8490
>
> Generic international: +44 2083222500 (UK number)
>
> access code: 297427 #
>

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

Hi Mathias, I do not have this information at hand. We certainly would need
to come up with this soon. The code and what documentation there is so far
is at:

https://github.com/fickludd/ms-numpress

Maybe Johan has some additional documentation?

Thanks,
Eric


> -----Original Message-----
> From: Mathias Walzer [mailto:wa...@in...]
> Sent: Tuesday, October 22, 2013 8:35 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] PSI MS call Tuesday: compression
>
> Hi Eric,
>
> we, the openMS guys (foremost those working with swath files) are eager
> to make use of such a neat compression. To assist in making the right
> calls when plugging in the lib(s) to our mzML infrastructure in OpenMS
> I was hoping to get some insights during the call. Does one of these
> doc's you were talking about contain where numpress hooks into the mzML
> schema? What modes are envisaged, at which point the cv terms are
> supposed to come into play ans so on.
> If so, can you send me the respective files?
> No OpenMS developer is actively working on mzML right now on a regular
> basis. So integration time into OpenMS will take some time. It would be
> great to have a head start, before you get this finalized.
>
> Cheers,
> Viele Grüße,
> --
> Mathias Walzer
>
> University of Tuebingen
> Wilhelm Schickard Institute for Computer Science
> Division for Applied Bioinformatics
> Room C313, Sand 14, D-72076 Tuebingen
>
> phone:  +49 (0)7071-29 70437 and +49 (0)7071-29 87649
> fax:  +49 (0)7071-29 5152
>
> Diese Nachricht ist 100% biologisch abbaubar!
>
>
>
>
>
> ----- Original Message -----
> From: "Eric Deutsch" <Eri...@sy...>
> To: "Mass spectrometry standard development" <psidev-ms-
> de...@li...>, psi...@li...
> Cc: "Eric Deutsch" <ede...@sy...>
> Sent: Tuesday, 22 October, 2013 5:04:59 AM
> Subject: Re: [Psidev-ms-dev] PSI MS call Tuesday: compression
>
>
>
>
>
> Hi everyone, just a reminder that we will have a PSI MS/PI WG
> teleconference to discuss mzML data compression and related topics in
> 12 hr.
>
>
>
> 08:00 San Francisco
>
> 11:00 New York
>
> 16:00 London
>
> 17:00 Geneva
>
>
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-832-8490
>
>
>
> Generic international: +44 2083222500 (UK number)
>
>
>
> access code: 297427 #
>
>
>
>
>
>
>
>
>
>
> From: Eric Deutsch [mailto: ede...@sy... ]
> Sent: Friday, October 18, 2013 3:39 PM
> To: Mass spectrometry standard development; psidev-pi-
> de...@li...
> Cc: Eric Deutsch
> Subject: PSI MS call Tuesday: compression
>
>
>
> Hi everyone, let’s have a PSI MS/PI WG teleconference call Tuesday at
> the usual time.
>
>
>
> We will have a discussion about the ongoing numpress work to
> dramatically improve the compression options for mzML.
>
> 08:00 San Francisco
>
> 11:00 New York
>
> 16:00 London
>
> 17:00 Geneva
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-832-8490
>
> Generic international: +44 2083222500 (UK number)
>
> access code: 297427 #
>
>
>
>
> -----------------------------------------------------------------------
> -------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.cl
> ktrk
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
> -----------------------------------------------------------------------
> -------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.cl
> ktrk
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Failing link to an import specification element

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

Hi Filippo, it appears that the location is now:

https://svn.code.sf.net/p/psidev/svn/psi/mzml/validator/src/main/resources/ms-mapping.xml

Can someone familiar with the validator code say whether this apparent
change in URL is alarming and a mistake or whether I should just fix the
hyperlink? And is the quoted one above indeed the new reference?

Thanks,
Eric


-----Original Message-----
From: Filippo Rusconi [mailto:fil...@u-...]
Sent: Tuesday, October 22, 2013 7:22 AM
To: psi...@li...
Subject: [Psidev-ms-dev] Failing link to an import specification element

Greetings,

at page http://www.psidev.info/index.php?q=node/257

the link
https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml

in line "- Latest mapping file, which defines where certain controlled
vocabulary terms may be used in a document."

does not lead to anywhere.

Please, fix that link so that we can peruse the file's contents again.

Thank you,

Filippo Rusconi

-- 
Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu
Researcher at CNRS and Debian Developer

my massXpert software: http://www.massxpert.org
~~~~
my book: http://www.lavoisier.fr/livre/notice.asp?id=3LKW2OAR2KROWZ
         (http://e.lavoisier.fr/flip_book/show/24495)
~~~~
my lab website: http://pagesperso.lcp.u-psud.fr/rusconi/wiki/pmwiki.php
~~~~
my photographs: http://filippo.rusconi.free.fr/fineartphotoblog

Laboratoire de Chimie Physique - UMR CNRS 8000
Bât. 349 --- Faculté des sciences d'Orsay
Université Paris Sud
15, avenue Jean Perrin
F-91400 ORSAY
Tel : +33 (0)1 69 15 76 04 -- Fax : +33 Fax 33 (0)1 69 15 61 88


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

PSI MS/PI telecall on numpress mzML compression



Present: Juan Antonio, Andy, Eric, Brian, Fredrik, Johan, Mathias,



- Reviewed the top summary document

  o is missing mz5 zlib

  o also show an mzMLdelta

  o numAllzlib .gz



- Brian added a bit of code to ProteoWizard to limit a potential too high
loss. If the actual observed loss exceeds a settable threshold, the
spectrum is written uncompressed.



- mz5 files > ~2 GB cannot be read by Pwiz due to a bug. Johann will report



- It does seem from the readspeed figure, mzML with numpress still doesn’t
compete so well with mz5

- Andy wonders if there are optimizations in the XML parsing. Are many
objects being created and discarded during reading?



- Maximum observed delta error across all test files was 0.002 ppm



- Johann has imzML code for ProteoWizard. If he can develop a good patch
for the very latest trunk of proteowizard, Brian could probably apply it
quickly.



- Andy broaches the concern that if we are going to open the door to lossy
compression, maybe we can do a whole lot better. Before the PSI approves
any specific approach, we should do some more homework to make sure that
anyone currently working on this problem is heard and can contribute and we
officially approve the best approach. We don’t want to be in a possible
where we release one version and then a year from now have another much
better compression version.



We will follow up my email and schedule another call.



Thanks,

Eric







*From:* Eric Deutsch [mailto:Eri...@sy...]
*Sent:* Monday, October 21, 2013 8:05 PM
*To:* Mass spectrometry standard development;
psi...@li...
*Cc:* Eric Deutsch
*Subject:* RE: PSI MS call Tuesday: compression



Hi everyone, just a reminder that we will have a PSI MS/PI WG
teleconference to discuss mzML data compression and related topics in 12 hr.



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-832-8490



Generic international: +44 2083222500 (UK number)



access code: 297427 #







*From:* Eric Deutsch [mailto:ede...@sy...]
*Sent:* Friday, October 18, 2013 3:39 PM
*To:* Mass spectrometry standard development;
psi...@li...
*Cc:* Eric Deutsch
*Subject:* PSI MS call Tuesday: compression



Hi everyone, let’s have a PSI MS/PI WG teleconference call Tuesday at the
usual time.



We will have a discussion about the ongoing numpress work to dramatically
improve the compression options for mzML.

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-832-8490

Generic international: +44 2083222500 (UK number)

access code: 297427 #

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

[Mathias W. <wa...@in...>]

Hi Eric, 

we, the openMS guys (foremost those working with swath files) are eager to make use of such a neat compression. To assist in making the right calls when plugging in the lib(s) to our mzML infrastructure in OpenMS I was hoping to get some insights during the call. Does one of these doc's you were talking about contain where numpress hooks into the mzML schema? What modes are envisaged, at which point the cv terms are supposed to come into play ans so on.
If so, can you send me the respective files? 
No OpenMS developer is actively working on mzML right now on a regular basis. So integration time into OpenMS will take some time. It would be great to have a head start, before you get this finalized.

Cheers,
Viele Grüße,
--
Mathias Walzer

University of Tuebingen
Wilhelm Schickard Institute for Computer Science
Division for Applied Bioinformatics
Room C313, Sand 14, D-72076 Tuebingen

phone:  +49 (0)7071-29 70437 and +49 (0)7071-29 87649
fax:  +49 (0)7071-29 5152

Diese Nachricht ist 100% biologisch abbaubar!





----- Original Message -----
From: "Eric Deutsch" <Eri...@sy...>
To: "Mass spectrometry standard development" <psi...@li...>, psi...@li...
Cc: "Eric Deutsch" <ede...@sy...>
Sent: Tuesday, 22 October, 2013 5:04:59 AM
Subject: Re: [Psidev-ms-dev] PSI MS call Tuesday: compression





Hi everyone, just a reminder that we will have a PSI MS/PI WG teleconference to discuss mzML data compression and related topics in 12 hr. 



08:00 San Francisco 

11:00 New York 

16:00 London 

17:00 Geneva 



+ Germany: 08001012079 

+ Switzerland: 0800000860 

+ UK: 08081095644 

+ USA: 1-866-832-8490 



Generic international: +44 2083222500 (UK number) 



access code: 297427 # 










From: Eric Deutsch [mailto: ede...@sy... ] 
Sent: Friday, October 18, 2013 3:39 PM 
To: Mass spectrometry standard development; psi...@li... 
Cc: Eric Deutsch 
Subject: PSI MS call Tuesday: compression 



Hi everyone, let’s have a PSI MS/PI WG teleconference call Tuesday at the usual time. 



We will have a discussion about the ongoing numpress work to dramatically improve the compression options for mzML. 

08:00 San Francisco 

11:00 New York 

16:00 London 

17:00 Geneva 

+ Germany: 08001012079 

+ Switzerland: 0800000860 

+ UK: 08081095644 

+ USA: 1-866-832-8490 

Generic international: +44 2083222500 (UK number) 

access code: 297427 # 




------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Failing link to an import specification element

[Filippo R. <fil...@u-...>]

Greetings,

at page http://www.psidev.info/index.php?q=node/257

the link
https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml

in line "- Latest mapping file, which defines where certain controlled
vocabulary terms may be used in a document."

does not lead to anywhere.

Please, fix that link so that we can peruse the file's contents again.

Thank you,

Filippo Rusconi

-- 
Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu
Researcher at CNRS and Debian Developer

my massXpert software: http://www.massxpert.org
~~~~
my book: http://www.lavoisier.fr/livre/notice.asp?id=3LKW2OAR2KROWZ
         (http://e.lavoisier.fr/flip_book/show/24495)
~~~~
my lab website: http://pagesperso.lcp.u-psud.fr/rusconi/wiki/pmwiki.php
~~~~
my photographs: http://filippo.rusconi.free.fr/fineartphotoblog

Laboratoire de Chimie Physique - UMR CNRS 8000
Bât. 349 --- Faculté des sciences d'Orsay
Université Paris Sud
15, avenue Jean Perrin
F-91400 ORSAY
Tel : +33 (0)1 69 15 76 04 -- Fax : +33 Fax 33 (0)1 69 15 61 88

[Psidev-ms-dev] New version 3.55.0 of psi-ms.obo

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

Dear proteomics community,

attached there's the new release 3.55.0 of
the psi-ms.obo file. It contains new terms for
the MZmine and Maltcms frameworks.

In addition most of the purgatory terms are obsoleted
now, some moved to other branches and 10 terms are still
left in the purgatory branch, because these terms are still
referenced by other terms.


Changed CV terms in version 3.55.0 of psi-ms.obo:
=================================================
************ Moved from purgatory --> measurement method
[Term]
id: MS:1000205
name: selected ion monitoring
def: "The operation of a mass spectrometer in which the intensities of
several specific m/z values are recorded rather than the entire mass
spectrum." [PSI:MS]
synonym: "MIM" RELATED []
synonym: "Multiple Ion Monitoring" EXACT []
synonym: "SIM" EXACT []
is_a: MS:1000596 ! measurement method

************ Moved from purgatory --> measurement method
[Term]
id: MS:1000206
name: selected reaction monitoring
def: "Data acquired from specific product ions corresponding to m/z
selected precursor ions recorded via multiple stages of mass
spectrometry. Selected reaction monitoring can be performed in time or
in space." [PSI:MS]
synonym: "MRM" RELATED []
synonym: "Multiple Reaction Monitoring" RELATED []
synonym: "SRM" EXACT []
is_a: MS:1000596 ! measurement method

************ Now under ion type
[Term]
id: MS:1000368
name: metastable ion
def: "An ion that is formed with internal energy higher than the
threshold for dissociation but with a lifetime great enough to allow it
to exit the ion source and enter the mass spectrometer where it
dissociates before detection." [PSI:MS]
is_a: MS:1002343 ! ion stability type

************ Now under ion type
[Term]
id: MS:1000378
name: stable ion
def: "An ion with internal energy sufficiently low that it does not
rearrange or dissociate prior to detection in a mass spectrometer." [PSI:MS]
is_a: MS:1002343 ! ion stability type

************ Now under ion type
[Term]
id: MS:1000379
name: unstable ion
def: "An ion with sufficient energy to dissociate within the ion
source." [PSI:MS]
is_a: MS:1002343 ! ion stability type

************ Corrected error in definition: mzData --> mzML
[Term]
id: MS:1000544
name: Conversion to mzML
def: "Conversion of a file format to Proteomics Standards Initiative
mzML file format." [PSI:MS]
is_a: MS:1000530 ! file format conversion

************ Renamed: gas -> gaseous sample state
[Term]
id: MS:1000048
name: gaseous sample state
def: "State if the sample is in gaseous form." [PSI:MS]
is_a: MS:1000003 ! sample state

************ Renamed: liquid -> liquid sample state
[Term]
id: MS:1000049
name: liquid sample state
def: "State if the sample is in liquid form." [PSI:MS]
is_a: MS:1000003 ! sample state

************ Renamed: solid -> solid sample state
[Term]
id: MS:1000050
name: solid sample state
def: "State if the sample is in solid form." [PSI:MS]
is_a: MS:1000003 ! sample state


************ OBSOLETED PURGATORY TERMS
MS:1000002	sample name	
MS:1000010	analyzer type	
MS:1000023	isolation width	
MS:1000054	chromatography	
MS:1000097	constant neutral mass loss	
MS:1000098	multiple ion monitoring
MS:1000100	precursor ion scan	
MS:1000101	product ion scan	
MS:1000155	ELEMENT2	
MS:1000214	electron energy obsolete	
MS:1000244	consecutive reaction monitoring	
MS:1000292	mass spectrograph obsolete
MS:1000295	mattauch-herzog geometry	
MS:1000296	nier-johnson geometry	
MS:1000297	paul ion trap
MS:1000299	quistor
MS:1000313	scan m/z range?	
MS:1000323	constant neutral loss scan	
MS:1000324	constant neutral gain scan	
MS:1000338	nth generation product ion scan	
MS:1000352	secondary electron	
MS:1000425	ion energy loss spectrum	
MS:1000454	instrument additional description	
MS:1000461	additional description	
MS:1000479	purgatory	
MS:1000552	maldi spot identifier	
MS:1001051	multiple enzyme combination rules
MS:1001115	scan number(s)
MS:1001213	search result details
MS:1001326	add_others


************************************************************
************ TERMS STILL IN THE PURGATORY BRANCH
The following 10 terms are still in the purgatory branch.
It was not possible to obsolete them, because other terms
still refer to them:

ID			name							
	referenced by
=============================================================
MS:1000268 mass spectrometry
	MS:1000020 scanning method
	MS:1000263 isotope ratio mass spectrometry
MS:1000293 mass spectrometer
	MS:1000226 molecular beam mass spectrometry
	MS:1000238 accelerator mass spectrometry
	MS:1000256 high-field asymmetric waveform ion mobility spectrometry
	MS:1000260 ion kinetic energy spectrometry
	MS:1000261 ion mobility spectrometry
	MS:1000267 mass analyzed ion kinetic energy spectrometry
	MS:1000269 mass spectrometry/mass spectrometry
	MS:1000277 residual gas analyzer
	MS:1000287 time-of-flight mass spectrometer
	MS:1000289 double-focusing mass spectrometer
	MS:1000290 hybrid mass spectrometer
	MS:1000298 prolate traochoidal mass spectrometer
	MS:1000301 sector mass spectrometer
	MS:1000302 tandem mass spectrometer
	MS:1000303 transmission quadrupole mass spectrometer
	MS:1000306 dynamic mass spectrometry
MS:1000329 linked scan
	MS:1000330 linked scan at constant b/e
	MS:1000331 Linked Scan at Constant E2/V
	MS:1000332 Linked Scan at Constant B2/E
	MS:1000333 Linked Scan at Constant B[1-(E/E0)]^1/2 / E
MS:1000365 ion?
	MS:1000437 ion reaction
	MS:1000506 ion role
	MS:1000507 ion attribute
	MS:1000508 ion chemical type
MS:1000444 m/z Separation Method
	MS:1000234 mass resolving power(already obsolete)
	MS:1000305 cyclotron motion
	MS:1000314 mass selective axial ejection
	MS:1000315 mass selective instability
	MS:1000316 mathieu stability diagram
	MS:1000317 orthogonal extraction
	MS:1000318 resonance ion ejection
MS:1000445 sequential m/z separation method
	MS:1000270 multiple stage mass spectrometry
	MS:1000321 2E Mass Spectrum
	MS:1000334 MS/MS in Time
	MS:1000335 MS/MS in Space
	MS:1000336 neutral loss
MS:1000459 spectrum instrument description
	MS:1000037 polarity (already obsolete)
MS:1000013 resolution type
	MS:1000088 constant
	MS:1000089 proportional
MS:1000017 scan function
	MS:1000090 mass scan
	MS:1000091 selected ion detection
MS:1000020 scanning method
	MS:1000498 full scan
	MS:1000791 enhanced resolution scan (already obsolete)


************************************************************
************ TERMS OVERLAPPING WITH INCLUDED ONTOLOGIES
B. In order to ensure non-orthogonality (redundancy)
   between the CV terms and its imports, the following
   terms in psi-ms.obo were made obsolete. Please use
   the corresponding terms from the unit.obo resp.
   PATO.obo instead.

ID in psi-ms.obo name in unit.obo ID in unit.obo name in unit.obo
=================================================================
MS:1000212       dalton           UO:0000221     dalton		
MS:1000137       electron volt    UO:0000266     electronvolt		
MS:1000046       energy unit      UO:0000111     energy unit		
MS:1000464       mass unit        UO:0000002     mass unit		
MS:1000038       minute           UO:0000031     minute		
MS:1000039       second           UO:0000010     second		
MS:1000550       time unit        UO:0000003     time unit		
MS:1000460       unit             UO:0000000     unit

ID in psi-ms.obo name in unit.obo ID in PATO.obo name in PATO.obo
=================================================================
MS:1000095       linear           PATO:0001199   linear
MS:1000037       polarity         PATO:0002186   polarity
MS:1000843       wavelength       PATO:0001242   wavelength


New CV terms in version 3.55.0 of psi-ms.obo:
=============================================
[Term]
id: MS:1002342
name: MZmine
def: "A framework for differential analysis of mass spectrometry data."
[PMID:16403790, PMID:20650010]
is_a: MS:1001456 ! analysis software
is_a: MS:1001457 ! data processing software

[Term]
id: MS:1002343
name: ion stability type
def: "Stability type of the ion." [PSI:PI]
is_a: MS:1000365 ! ion?

[Term]
id: MS:1002344
name: Maltcms
def: "Modular Application Toolkit for Chromatography Mass-Spectrometry
is an application framework mainly for developers." [PSI:PI,
http://maltcms.sf.net]
is_a: MS:1001456 ! analysis software
is_a: MS:1001457 ! data processing software

Best Regards,
Gerhard

-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
Bioinformatics / Biostatistics
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.049a
Universitätsstraße 150
D-44801 Bochum

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

Re: [Psidev-ms-dev] PSI MS call Tuesday: compression

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

Hi everyone, just a reminder that we will have a PSI MS/PI WG
teleconference to discuss mzML data compression and related topics in 12 hr.



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-832-8490



Generic international: +44 2083222500 (UK number)



access code: 297427 #







*From:* Eric Deutsch [mailto:ede...@sy...]
*Sent:* Friday, October 18, 2013 3:39 PM
*To:* Mass spectrometry standard development;
psi...@li...
*Cc:* Eric Deutsch
*Subject:* PSI MS call Tuesday: compression



Hi everyone, let’s have a PSI MS/PI WG teleconference call Tuesday at the
usual time.



We will have a discussion about the ongoing numpress work to dramatically
improve the compression options for mzML.

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-832-8490

Generic international: +44 2083222500 (UK number)

access code: 297427 #

Re: [Psidev-ms-dev] CV term correction in psi-ms_3.55_rc2.obo

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

Hi Nils, thank you for reporting this. Looks like a cut'n'paste error.
Gerhard, would you fix this in the next opportunity?

Thanks,
Eric


> -----Original Message-----
> From: Nils Hoffmann [mailto:nil...@ce...]
> Sent: Monday, October 21, 2013 2:07 AM
> To: Mass spectrometry standard development
> Subject: [Psidev-ms-dev] CV term correction in psi-ms_3.55_rc2.obo
>
> Hi,
> I just came across this seemingly erroneous definition in the latest
> obo
> file from
> http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-
> ms/mzML/controlledVocabulary/psi-ms.obo
>
> The definition is also present in the latest psi-ms_3.55_rc2.obo file.
>
> [Term]
> id: MS:1000544
> name: Conversion to mzML
> def: "Conversion of a file format to Proteomics Standards Initiative
> mzData file format." [PSI:MS]
> is_a: MS:1000530 ! file format conversion
>
> I think, the "def:" part should read (with mzData replaced by mzML):
>
> def: "Conversion of a file format to Proteomics Standards Initiative
> mzML file format." [PSI:MS]
>
>
> Sincerely,
> Nils
>
> --
> Nils Hoffmann                                   phone:    +49-521-106-
> 4342
> Bielefeld University                            room:             U10-
> 144
> Faculty of Technology, Genome Informatics
> P.O. Box 10 01 31
> 33501 Bielefeld, Germany
> http://www.cebitec.uni-bielefeld.de/~hoffmann
>
>
> -----------------------------------------------------------------------
> -------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.cl
> ktrk
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] CV term correction in psi-ms_3.55_rc2.obo

[Nils H. <nil...@ce...>]

Hi,
I just came across this seemingly erroneous definition in the latest obo
file from
http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo

The definition is also present in the latest psi-ms_3.55_rc2.obo file.

[Term]
id: MS:1000544
name: Conversion to mzML
def: "Conversion of a file format to Proteomics Standards Initiative mzData file format." [PSI:MS]
is_a: MS:1000530 ! file format conversion

I think, the "def:" part should read (with mzData replaced by mzML):

def: "Conversion of a file format to Proteomics Standards Initiative mzML file format." [PSI:MS]


Sincerely,
Nils

-- 
Nils Hoffmann                                   phone:    +49-521-106-4342
Bielefeld University                            room:             U10-144
Faculty of Technology, Genome Informatics
P.O. Box 10 01 31
33501 Bielefeld, Germany
http://www.cebitec.uni-bielefeld.de/~hoffmann

[Psidev-ms-dev] PSI MS call Tuesday: compression

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

Hi everyone, let’s have a PSI MS/PI WG teleconference call Tuesday at the
usual time.



We will have a discussion about the ongoing numpress work to dramatically
improve the compression options for mzML.

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-832-8490

Generic international: +44 2083222500 (UK number)

access code: 297427 #

[Psidev-ms-dev] PSI MS call Tuesday: compression

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

Hi everyone, let’s have a PSI MS/PI WG teleconference call Tuesday at the
usual time.



We will have a discussion about the ongoing numpress work to dramatically
improve the compression options for mzML.

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-832-8490

Generic international: +44 2083222500 (UK number)

access code: 297427 #

[Psidev-ms-dev] Workshop mzTab for Metabolomics

[Oliver K. <oli...@un...>]

Dear all,

The imminent release of the mzTab 1.0 specification[1]
primarily aims to capture results of proteomics experiments.

We would like to invite interested parties to a 

	one-day mzTab4Metabolomics Workshop 

in early 2014. We'd like to improve the representation 
of Metabolomics and Small-Molecule Identification and 
Quantification in mzTab, which will hopefully lead to 
a quick release of mzTab 1.1. 

The location is very likely to be in Germany in Tuebingen, 
and to agree on a date we have set up a doodle poll [2].
The workshop is another step towards coordination of standards 
between the proteomics and metabolomics communities and we 
would appreciate your participation.

Yours,
Oliver Kohlbacher and Steffen Neumann


[1] http://www.psidev.info/mztab
[2] http://doodle.com/g2engt85ua87gg4n


---
Oliver Kohlbacher (oli...@un...)
Professor, Applied Bioinformatics, Center for Bioinformatics Tuebingen
 & Dept. of Computer Science, University of Tuebingen
Director, Quantitative Biology Center
phone: +49-7071-29-70457   http://KohlbacherLab.org 

vCard at: http://abi.inf.uni-tuebingen.de/People/kohlbach/vCard

[Psidev-ms-dev] Release candidate 3.55.0_rc2

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

Dear proteomics community,

attached there's the release candidate 3.55.0_rc2 of
the psi-ms.obo file. It contains new terms for
the MZmine and Maltcms frameworks.

In addition most of the purgatory terms are obsoleted
now, some moved to other branches and 10 terms are still
left in the purgatory branch, because these terms are still
referenced by other terms.


Changed CV terms in version 3.55.0_rc2 of psi-ms.obo:
=====================================================
************ Moved from purgatory --> measurement method
[Term]
id: MS:1000205
name: selected ion monitoring
def: "The operation of a mass spectrometer in which the intensities of
several specific m/z values are recorded rather than the entire mass
spectrum." [PSI:MS]
synonym: "MIM" RELATED []
synonym: "Multiple Ion Monitoring" EXACT []
synonym: "SIM" EXACT []
is_a: MS:1000596 ! measurement method

************ Moved from purgatory --> measurement method
[Term]
id: MS:1000206
name: selected reaction monitoring
def: "Data acquired from specific product ions corresponding to m/z
selected precursor ions recorded via multiple stages of mass
spectrometry. Selected reaction monitoring can be performed in time or
in space." [PSI:MS]
synonym: "MRM" RELATED []
synonym: "Multiple Reaction Monitoring" RELATED []
synonym: "SRM" EXACT []
is_a: MS:1000596 ! measurement method

************ Now under ion type
[Term]
id: MS:1000368
name: metastable ion
def: "An ion that is formed with internal energy higher than the
threshold for dissociation but with a lifetime great enough to allow it
to exit the ion source and enter the mass spectrometer where it
dissociates before detection." [PSI:MS]
is_a: MS:1002343 ! ion type

************ Now under ion type
[Term]
id: MS:1000378
name: stable ion
def: "An ion with internal energy sufficiently low that it does not
rearrange or dissociate prior to detection in a mass spectrometer." [PSI:MS]
is_a: MS:1002343 ! ion type

************ Now under ion type
[Term]
id: MS:1000379
name: unstable ion
def: "An ion with sufficient energy to dissociate within the ion
source." [PSI:MS]
is_a: MS:1002343 ! ion type

************ Renamed: gas -> gaseous sample state
[Term]
id: MS:1000048
name: gaseous sample state
def: "State if the sample is in gaseous form." [PSI:MS]
is_a: MS:1000003 ! sample state

************ Renamed: liquid -> liquid sample state
[Term]
id: MS:1000049
name: liquid sample state
def: "State if the sample is in liquid form." [PSI:MS]
is_a: MS:1000003 ! sample state

************ Renamed: solid -> solid sample state
[Term]
id: MS:1000050
name: solid sample state
def: "State if the sample is in solid form." [PSI:MS]
is_a: MS:1000003 ! sample state


************ OBSOLETED PURGATORY TERMS
MS:1000002	sample name	
MS:1000010	analyzer type	
MS:1000023	isolation width	
MS:1000054	chromatography	
MS:1000097	constant neutral mass loss	
MS:1000098	multiple ion monitoring
MS:1000100	precursor ion scan	
MS:1000101	product ion scan	
MS:1000155	ELEMENT2	
MS:1000214	electron energy obsolete	
MS:1000244	consecutive reaction monitoring	
MS:1000292	mass spectrograph obsolete
MS:1000295	mattauch-herzog geometry	
MS:1000296	nier-johnson geometry	
MS:1000297	paul ion trap
MS:1000299	quistor
MS:1000313	scan m/z range?	
MS:1000323	constant neutral loss scan	
MS:1000324	constant neutral gain scan	
MS:1000338	nth generation product ion scan	
MS:1000352	secondary electron	
MS:1000425	ion energy loss spectrum	
MS:1000454	instrument additional description	
MS:1000461	additional description	
MS:1000479	purgatory	
MS:1000552	maldi spot identifier	
MS:1001051	multiple enzyme combination rules
MS:1001115	scan number(s)
MS:1001213	search result details
MS:1001326	add_others


************************************************************
************ TERMS STILL IN THE PURGATORY BRANCH
The following 10 terms are still in the purgatory branch.
It was not possible to obsolete them, because other terms
still refer to them:

ID			name							
	referenced by
=============================================================
MS:1000268 mass spectrometry
	MS:1000020 scanning method
	MS:1000263 isotope ratio mass spectrometry
MS:1000293 mass spectrometer
	MS:1000226 molecular beam mass spectrometry
	MS:1000238 accelerator mass spectrometry
	MS:1000256 high-field asymmetric waveform ion mobility spectrometry
	MS:1000260 ion kinetic energy spectrometry
	MS:1000261 ion mobility spectrometry
	MS:1000267 mass analyzed ion kinetic energy spectrometry
	MS:1000269 mass spectrometry/mass spectrometry
	MS:1000277 residual gas analyzer
	MS:1000287 time-of-flight mass spectrometer
	MS:1000289 double-focusing mass spectrometer
	MS:1000290 hybrid mass spectrometer
	MS:1000298 prolate traochoidal mass spectrometer
	MS:1000301 sector mass spectrometer
	MS:1000302 tandem mass spectrometer
	MS:1000303 transmission quadrupole mass spectrometer
	MS:1000306 dynamic mass spectrometry
MS:1000329 linked scan
	MS:1000330 linked scan at constant b/e
	MS:1000331 Linked Scan at Constant E2/V
	MS:1000332 Linked Scan at Constant B2/E
	MS:1000333 Linked Scan at Constant B[1-(E/E0)]^1/2 / E
MS:1000365 ion?
	MS:1000437 ion reaction
	MS:1000506 ion role
	MS:1000507 ion attribute
	MS:1000508 ion chemical type
MS:1000444 m/z Separation Method
	MS:1000234 mass resolving power(already obsolete)
	MS:1000305 cyclotron motion
	MS:1000314 mass selective axial ejection
	MS:1000315 mass selective instability
	MS:1000316 mathieu stability diagram
	MS:1000317 orthogonal extraction
	MS:1000318 resonance ion ejection
MS:1000445 sequential m/z separation method
	MS:1000270 multiple stage mass spectrometry
	MS:1000321 2E Mass Spectrum
	MS:1000334 MS/MS in Time
	MS:1000335 MS/MS in Space
	MS:1000336 neutral loss
MS:1000459 spectrum instrument description
	MS:1000037 polarity (already obsolete)
MS:1000013 resolution type
	MS:1000088 constant
	MS:1000089 proportional
MS:1000017 scan function
	MS:1000090 mass scan
	MS:1000091 selected ion detection
MS:1000020 scanning method
	MS:1000498 full scan
	MS:1000791 enhanced resolution scan (already obsolete)


************************************************************
************ TERMS OVERLAPPING WITH INCLUDED ONTOLOGIES
B. In order to ensure non-orthogonality (redundancy)
   between the CV terms and its imports, the following
   terms in psi-ms.obo were made obsolete. Please use
   the corresponding terms from the unit.obo resp.
   PATO.obo instead.

ID in psi-ms.obo name in unit.obo ID in unit.obo name in unit.obo
=================================================================
MS:1000212       dalton           UO:0000221     dalton		
MS:1000137       electron volt    UO:0000266     electronvolt		
MS:1000046       energy unit      UO:0000111     energy unit		
MS:1000464       mass unit        UO:0000002     mass unit		
MS:1000038       minute           UO:0000031     minute		
MS:1000039       second           UO:0000010     second		
MS:1000550       time unit        UO:0000003     time unit		
MS:1000460       unit             UO:0000000     unit

ID in psi-ms.obo name in unit.obo ID in PATO.obo name in PATO.obo
=================================================================
MS:1000095       linear           PATO:0001199   linear
MS:1000037       polarity         PATO:0002186   polarity
MS:1000843       wavelength       PATO:0001242   wavelength


New CV terms in version 3.55.0_rc2 of psi-ms.obo:
=================================================
[Term]
id: MS:1002342
name: MZmine
def: "A framework for differential analysis of mass spectrometry data."
[PMID:16403790, PMID:20650010]
is_a: MS:1001456 ! analysis software
is_a: MS:1001457 ! data processing software

[Term]
id: MS:1002343
name: ion type
def: "A framework for differential analysis of mass spectrometry data."
[PSI:PI]
is_a: MS:1000365 ! ion?

[Term]
id: MS:1002344
name: Maltcms
def: "Modular Application Toolkit for Chromatography Mass-Spectrometry
is an application framework mainly for developers." [PSI:PI,
http://maltcms.sf.net]
is_a: MS:1001456 ! analysis software
is_a: MS:1001457 ! data processing software

Best Regards,
Gerhard

-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
Bioinformatics / Biostatistics
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.049a
Universitätsstraße 150
D-44801 Bochum

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

Re: [Psidev-ms-dev] Release candidate 3.55.0_rc1 of psi-ms.obo

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

Yes it made me nervous for the same reason, but pwiz is using the UO versions of all these units. In 
fact, these units were actually obsoleted a long time ago. Something like 2008.

The PATO ones are more complicated. We have to consider the term relationships as well as the 
definitions and names. In this case, solid/gas/liquid are sample states:

[Term]
id: MS:1000048
name: gas
def: "State if the sample is in gaseous form." [PSI:MS]
is_a: MS:1000003 ! sample state

You can't just replace that with the PATO term, and AFAIK there's no way to simply add a relationship of the existing PATO term to one of the terms in our CV. But we can rename the term to "gaseous sample state" to distinguish it from simplify the generic quality of matter of being gaseous.

Does this make sense?

-Matt


On 9/27/2013 11:40 AM, Eri...@sy... wrote:
> Hi Gerhard, many thanks for working on this. This is a big step toward
> tidying up the CV. I think this is all good, except I'm a little nervous
> about the units. However, I checked recent TraML and mzML files and they
> don't seem to be using any of the units in the MS CV. They're all using
> the UO, so that's good. I'm a little concerned, but have not reason to
> stop this step.
>
> Would someone check some recent mzIdentML and mzQuantML files to make sure
> we're not still using these unit terms in the MS CV while producing these
> documents?
>
> Thanks,
> Eric
>
>
>
> ************************************************************
> ************ TERMS OVERLAPPING WITH INCLUDED ONTOLOGIES
> B. In order to ensure non-orthogonality (redundancy)
>     between the CV terms and its imports, the following
>     terms in psi-ms.obo were made obsolete. Please use
>     the corresponding terms from the unit.obo resp.
>     PATO.obo instead.
>
> ID in psi-ms.obo name in unit.obo ID in unit.obo name in unit.obo
> =================================================================
> MS:1000212       dalton           UO:0000221     dalton
> MS:1000137       electron volt    UO:0000266     electronvolt
>
> MS:1000046       energy unit      UO:0000111     energy unit
>
> MS:1000464       mass unit        UO:0000002     mass unit
> MS:1000038       minute           UO:0000031     minute
> MS:1000039       second           UO:0000010     second
> MS:1000550       time unit        UO:0000003     time unit
> MS:1000460       unit             UO:0000000     unit
>
> ID in psi-ms.obo name in unit.obo ID in PATO.obo name in PATO.obo
> =================================================================
> MS:1000048       gas              PATO:0001737   gaseus configuration
> MS:1000095       linear           PATO:0001199   linear
> MS:1000049       liquid           PATO:0001735   liquid configuration
> MS:1000037       polarity         PATO:0002186   polarity
> MS:1000050       solid            PATO:0001736   solid configuration
> MS:1000843       wavelength       PATO:0001242   wavelength
>
>
> New CV terms in version 3.55.0_rc1 of psi-ms.obo:
> =================================================
> [Term]
> id: MS:1002342
> name: MZmine
> def: "A framework for differential analysis of mass spectrometry data."
> [PMID:16403790, PMID:20650010]
> is_a: MS:1001456 ! analysis software
> is_a: MS:1001457 ! data processing software
>
> Best Regards,
> Gerhard
> --
> ---
> Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
> Bioinformatics / Biostatistics
> Medizinisches-Proteom-Center (MPC)
> Ruhr-Universität Bochum
> Zentrum für klinische Forschung I (ZKF I)
> E.049a
> Universitätsstraße 150
> D-44801 Bochum
>
> Phone:	+49(0)234/32-21006
> Fax:	+49(0)234/32-14554
> Email:	Ger...@ru...
> Web:	http://www.medizinisches-proteom-center.de
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

Re: [Psidev-ms-dev] ion chemical type in the CV

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

Hi Steffen, thank you for posting. I cannot answer your questions directly,
and would encourage others to respond to the questions.



But I will note that the whole ion type set of terms such as dimeric ion
and adduct ion are all in purgatory under "ion?". I believe this is there
because they seemed like fine terms, but we had no need of them in the
formats at the time and so they were put in purgatory until such a time as
when their use could be discovered or they were obsoleted.



These terms do not appear to be on Gerhard's chopping block, although I'm
not sure why.



Steffen, if you want to use them, we should extract them from purgatory and
organize them nicely somewhere.



Finally, this doesn’t seem right:

>    <cvParam cvRef="MS" accession="MS:1000353" name="adduct ion"
value="Na"/>

>    or as a child term, maybe even with the mass difference:

>    <cvParam cvRef="MS" accession="MS:1000XXX" name="Na+ adduct"
value="22.989218"  unitName="Dalton" unitCvRef="UO" />



But I’m not quite sure what to suggest. The second should somehow be a
“mass” term. As for the first... I suspect that the term “adduct ion” is
intended as an “adjective” to describe an ion otherwise encoded. It is a
“type”. And the term is not intended to encode the ion composition.



Maybe you can elaborate a little where in which format you’re trying to
encode information and give the whole context. Or hopefully someone else
can understand and respond to your question better..



Thanks,

Eric









> -----Original Message-----

> From: Steffen Neumann [mailto:sne...@ip...]

> Sent: Friday, September 27, 2013 4:38 AM

> To: psi...@li...

> Subject: [Psidev-ms-dev] ion chemical type in the CV

>

> Hi,

>

> I am currently looking at how to annotate ions,

> specifically in -- but not limited to -- metabolomics.

>

> The CV already has a branch of terms:

> http://www.ebi.ac.uk/ontology-<http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS%3A1000508&termName=ion%20chemical%20type#>

> lookup/browse.do?ontName=MS&termId=MS%3A1000508&termName=ion%20chemical<http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS%3A1000508&termName=ion%20chemical%20type#>

> %20type#<http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS%3A1000508&termName=ion%20chemical%20type#>

>

> 1) Am I correct in that

>

>   MS:1000361 dimeric ion          is_a  MS:1000358 cluster ion

>   MS:1000375 protonated molecule  is_a  MS:1000353 adduct ion

>

> 2) Am I correct that an [2M+Na]+ is both an MS:1000353 adduct ion

>    and also a MS:1000361 dimeric ion ?

>

> 3) Would it be better to annotate the kind of Adduct as

>    <cvParam cvRef="MS" accession="MS:1000353" name="adduct ion"

> value="Na"/>

>    or as a child term, maybe even with the mass difference:

>    <cvParam cvRef="MS" accession="MS:1000XXX" name="Na+ adduct"

> value="22.989218"  unitName="Dalton" unitCvRef="UO" />

>

> Yours,

> Steffen

>

> --

> IPB Halle                    AG Massenspektrometrie & Bioinformatik

> Dr. Steffen Neumann          http://www.IPB-Halle.DE

> Weinberg 3                   http://msbi.bic-gh.de

> 06120 Halle                  Tel. +49 (0) 345 5582 - 1470

>                                   +49 (0) 345 5582 - 0

> sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

>

>

> -----------------------------------------------------------------------

> -------

> October Webinars: Code for Performance

> Free Intel webinars can help you accelerate application performance.

> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the

> most from

> the latest Intel processors and coprocessors. See abstracts and

> register >

> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.cl<http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk>

> ktrk<http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk>

> _______________________________________________

> Psidev-ms-dev mailing list

> Psi...@li...

> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev