psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] [Fwd: Re: PRODAC validator not checking polarity location]

[Lennart M. <len...@eb...>]

Hi Marc,


Excellent, that was my best guess at solving the issue as well, but it 
took me some more time to get there :D. We'll make sure to update ASAP.

Fredrik, we'll let you know when there is a new version!

Cheers,

lnnrt.

Marc Sturm wrote:
> Hi all,
> 
> the OpenMS validator allows only those terms listed in the mapping file. 
> However, terms from unknonwn CVs (those for which no mappnig rule 
> exists) are ignored.
> 
> Best,
>  Marc
> 
>> We've covered whether the mapping file should be a whitelist, a 
>> blacklist, or a combination on the list at some point. We decided that 
>> for the PSI CV it would be a whitelist (i.e. if it's not in the 
>> mapping file, it's not allowed) and for everything else it would be a 
>> blacklist (i.e. it won't flag terms from other CVs as errors, and 
>> presumably those terms will never show up in our mapping file).
>>
>> -Matt
>>
>>
>> Lennart Martens wrote:
>>  
>>> Hi Fredrik,
>>>
>>>
>>> There is a fundamental issue behind this I guess, but I'll attempt to 
>>> post to the list later on to resolve this.
>>>
>>> The main question here is whether you assume the mapping file defines 
>>> the lower boundary (which is what we do), or whether you assume that 
>>> it defines the upper boundary (as the OpenMS people do).
>>>
>>> Put in other words, we verify that the mzML file has at least what is 
>>> mandated in the mapping file, but we allow the use of additional 
>>> terms as well. The main reason for this is so anyone with a 
>>> homegrown, custom cv can include their own terms and still end up 
>>> with a valid document.
>>>
>>> The OpenMS validator seems to take the opposite approach: if it is 
>>> not in the mapping file it should not be there.
>>>
>>> So the erroneous scan polarity term is found by OpenMS, but ignored 
>>> by us; but a file with a custom CV term wil validate for us, but 
>>> maybe not for OpenMS.
>>>
>>> Now, we can nuance the situation - if you allow 'unknown' terms (e.g. 
>>> from a proprietary CV), but you do not allow terms that are known to 
>>> have another place reserved for them in the mapping file (such as the 
>>> scan polarity case). We're looking into developing this in an object 
>>> rule to test the concept, and it might well be that OpenMS does 
>>> things this way.
>>>
>>> But I'll also post to the list to get opinions and OpenMS feedback. 
>>> But I'll do that tomorrow.
>>>
>>>
>>> Cheers,
>>>
>>> lnnrt.
>>>
>>> Fredrik Levander wrote:
>>>    
>>>> Hi Lennart,
>>>>
>>>> Matt found a possible problem with the PSI/EBI validator. I thought 
>>>> it was us running an old version of the validator on the ProDaC web 
>>>> site, but now I tried with the latest jmzml and config files 
>>>> locally, and it doesn't complain if
>>>>
>>>> MS:1000130 - positive scan
>>>> is used under scan instead of under spectrum. The openMS validator 
>>>> flags this as an error. The test was done with small.pwiz.1.1.mzML. 
>>>> Do you have any idea of the reason for this? Maybe the term is 
>>>> passing if there are already terms fulfilling the rules for the 
>>>> element?
>>>>
>>>> Best Regards
>>>>
>>>> Fredrik
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> Subject:
>>>> Re: PRODAC validator not checking polarity location
>>>> From:
>>>> Jari Häkkinen <ja...@th...>
>>>> Date:
>>>> Fri, 24 Jul 2009 23:26:01 +0200
>>>> To:
>>>> Matthew Chambers <mat...@va...>
>>>>
>>>> To:
>>>> Matthew Chambers <mat...@va...>
>>>> CC:
>>>> Fredrik Levander <Fre...@im...>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Thanks for the report. Fredrik or me will look at the problem as 
>>>> soon as we are back in office.
>>>>
>>>>
>>>> Jari
>>>>
>>>>
>>>> Matthew Chambers wrote:
>>>>      
>>>>> I recently realized that most pwiz vendor readers were putting 
>>>>> polarity in scan instead of spectrum and that this was expressed in 
>>>>> files that had been verified by the PRODAC validator. That worries 
>>>>> me since there's no telling what other attributes it's not 
>>>>> checking. I ran the old file through the OpenMS validator and it 
>>>>> did catch the misplaced polarity terms.
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>>         
>>
>> ------------------------------------------------------------------------------ 
>>
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
>> 30-Day trial. Simplify your report design, integration and deployment 
>> - and focus on what you do best, core application coding. Discover 
>> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   

Re: [Psidev-ms-dev] [Fwd: Re: PRODAC validator not checking polarity location]

[Lennart M. <len...@eb...>]

Hi Matt,


Great! That instantly solves my problem in a simple way. Bless your 
excellent memory - keep this up, and you'll be bombarded secretary! :)


Cheers,

lnnrt.

Matthew Chambers wrote:
> We've covered whether the mapping file should be a whitelist, a 
> blacklist, or a combination on the list at some point. We decided that 
> for the PSI CV it would be a whitelist (i.e. if it's not in the mapping 
> file, it's not allowed) and for everything else it would be a blacklist 
> (i.e. it won't flag terms from other CVs as errors, and presumably those 
> terms will never show up in our mapping file).
> 
> -Matt
> 
> 
> Lennart Martens wrote:
>> Hi Fredrik,
>>
>>
>> There is a fundamental issue behind this I guess, but I'll attempt to 
>> post to the list later on to resolve this.
>>
>> The main question here is whether you assume the mapping file defines 
>> the lower boundary (which is what we do), or whether you assume that 
>> it defines the upper boundary (as the OpenMS people do).
>>
>> Put in other words, we verify that the mzML file has at least what is 
>> mandated in the mapping file, but we allow the use of additional terms 
>> as well. The main reason for this is so anyone with a homegrown, 
>> custom cv can include their own terms and still end up with a valid 
>> document.
>>
>> The OpenMS validator seems to take the opposite approach: if it is not 
>> in the mapping file it should not be there.
>>
>> So the erroneous scan polarity term is found by OpenMS, but ignored by 
>> us; but a file with a custom CV term wil validate for us, but maybe 
>> not for OpenMS.
>>
>> Now, we can nuance the situation - if you allow 'unknown' terms (e.g. 
>> from a proprietary CV), but you do not allow terms that are known to 
>> have another place reserved for them in the mapping file (such as the 
>> scan polarity case). We're looking into developing this in an object 
>> rule to test the concept, and it might well be that OpenMS does things 
>> this way.
>>
>> But I'll also post to the list to get opinions and OpenMS feedback. 
>> But I'll do that tomorrow.
>>
>>
>> Cheers,
>>
>> lnnrt.
>>
>> Fredrik Levander wrote:
>>> Hi Lennart,
>>>
>>> Matt found a possible problem with the PSI/EBI validator. I thought 
>>> it was us running an old version of the validator on the ProDaC web 
>>> site, but now I tried with the latest jmzml and config files locally, 
>>> and it doesn't complain if
>>>
>>> MS:1000130 - positive scan
>>> is used under scan instead of under spectrum. The openMS validator 
>>> flags this as an error. The test was done with small.pwiz.1.1.mzML. 
>>> Do you have any idea of the reason for this? Maybe the term is 
>>> passing if there are already terms fulfilling the rules for the element?
>>>
>>> Best Regards
>>>
>>> Fredrik
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Subject:
>>> Re: PRODAC validator not checking polarity location
>>> From:
>>> Jari Häkkinen <ja...@th...>
>>> Date:
>>> Fri, 24 Jul 2009 23:26:01 +0200
>>> To:
>>> Matthew Chambers <mat...@va...>
>>>
>>> To:
>>> Matthew Chambers <mat...@va...>
>>> CC:
>>> Fredrik Levander <Fre...@im...>
>>>
>>>
>>> Hi,
>>>
>>> Thanks for the report. Fredrik or me will look at the problem as soon 
>>> as we are back in office.
>>>
>>>
>>> Jari
>>>
>>>
>>> Matthew Chambers wrote:
>>>> I recently realized that most pwiz vendor readers were putting 
>>>> polarity in scan instead of spectrum and that this was expressed in 
>>>> files that had been verified by the PRODAC validator. That worries 
>>>> me since there's no telling what other attributes it's not checking. 
>>>> I ran the old file through the OpenMS validator and it did catch the 
>>>> misplaced polarity terms.
>>>>
>>>> Thanks,
>>>> Matt

Re: [Psidev-ms-dev] [Fwd: Re: PRODAC validator not checking polarity location]

[Marc S. <st...@in...>]

Hi all,

the OpenMS validator allows only those terms listed in the mapping file. 
However, terms from unknonwn CVs (those for which no mappnig rule 
exists) are ignored.

Best,
  Marc

> We've covered whether the mapping file should be a whitelist, a 
> blacklist, or a combination on the list at some point. We decided that 
> for the PSI CV it would be a whitelist (i.e. if it's not in the mapping 
> file, it's not allowed) and for everything else it would be a blacklist 
> (i.e. it won't flag terms from other CVs as errors, and presumably those 
> terms will never show up in our mapping file).
>
> -Matt
>
>
> Lennart Martens wrote:
>   
>> Hi Fredrik,
>>
>>
>> There is a fundamental issue behind this I guess, but I'll attempt to 
>> post to the list later on to resolve this.
>>
>> The main question here is whether you assume the mapping file defines 
>> the lower boundary (which is what we do), or whether you assume that 
>> it defines the upper boundary (as the OpenMS people do).
>>
>> Put in other words, we verify that the mzML file has at least what is 
>> mandated in the mapping file, but we allow the use of additional terms 
>> as well. The main reason for this is so anyone with a homegrown, 
>> custom cv can include their own terms and still end up with a valid 
>> document.
>>
>> The OpenMS validator seems to take the opposite approach: if it is not 
>> in the mapping file it should not be there.
>>
>> So the erroneous scan polarity term is found by OpenMS, but ignored by 
>> us; but a file with a custom CV term wil validate for us, but maybe 
>> not for OpenMS.
>>
>> Now, we can nuance the situation - if you allow 'unknown' terms (e.g. 
>> from a proprietary CV), but you do not allow terms that are known to 
>> have another place reserved for them in the mapping file (such as the 
>> scan polarity case). We're looking into developing this in an object 
>> rule to test the concept, and it might well be that OpenMS does things 
>> this way.
>>
>> But I'll also post to the list to get opinions and OpenMS feedback. 
>> But I'll do that tomorrow.
>>
>>
>> Cheers,
>>
>> lnnrt.
>>
>> Fredrik Levander wrote:
>>     
>>> Hi Lennart,
>>>
>>> Matt found a possible problem with the PSI/EBI validator. I thought 
>>> it was us running an old version of the validator on the ProDaC web 
>>> site, but now I tried with the latest jmzml and config files locally, 
>>> and it doesn't complain if
>>>
>>> MS:1000130 - positive scan
>>> is used under scan instead of under spectrum. The openMS validator 
>>> flags this as an error. The test was done with small.pwiz.1.1.mzML. 
>>> Do you have any idea of the reason for this? Maybe the term is 
>>> passing if there are already terms fulfilling the rules for the element?
>>>
>>> Best Regards
>>>
>>> Fredrik
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Subject:
>>> Re: PRODAC validator not checking polarity location
>>> From:
>>> Jari Häkkinen <ja...@th...>
>>> Date:
>>> Fri, 24 Jul 2009 23:26:01 +0200
>>> To:
>>> Matthew Chambers <mat...@va...>
>>>
>>> To:
>>> Matthew Chambers <mat...@va...>
>>> CC:
>>> Fredrik Levander <Fre...@im...>
>>>
>>>
>>> Hi,
>>>
>>> Thanks for the report. Fredrik or me will look at the problem as soon 
>>> as we are back in office.
>>>
>>>
>>> Jari
>>>
>>>
>>> Matthew Chambers wrote:
>>>       
>>>> I recently realized that most pwiz vendor readers were putting 
>>>> polarity in scan instead of spectrum and that this was expressed in 
>>>> files that had been verified by the PRODAC validator. That worries 
>>>> me since there's no telling what other attributes it's not checking. 
>>>> I ran the old file through the OpenMS validator and it did catch the 
>>>> misplaced polarity terms.
>>>>
>>>> Thanks,
>>>> Matt
>>>>         
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] [Fwd: Re: PRODAC validator not checking polarity location]

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

We've covered whether the mapping file should be a whitelist, a 
blacklist, or a combination on the list at some point. We decided that 
for the PSI CV it would be a whitelist (i.e. if it's not in the mapping 
file, it's not allowed) and for everything else it would be a blacklist 
(i.e. it won't flag terms from other CVs as errors, and presumably those 
terms will never show up in our mapping file).

-Matt


Lennart Martens wrote:
> Hi Fredrik,
>
>
> There is a fundamental issue behind this I guess, but I'll attempt to 
> post to the list later on to resolve this.
>
> The main question here is whether you assume the mapping file defines 
> the lower boundary (which is what we do), or whether you assume that 
> it defines the upper boundary (as the OpenMS people do).
>
> Put in other words, we verify that the mzML file has at least what is 
> mandated in the mapping file, but we allow the use of additional terms 
> as well. The main reason for this is so anyone with a homegrown, 
> custom cv can include their own terms and still end up with a valid 
> document.
>
> The OpenMS validator seems to take the opposite approach: if it is not 
> in the mapping file it should not be there.
>
> So the erroneous scan polarity term is found by OpenMS, but ignored by 
> us; but a file with a custom CV term wil validate for us, but maybe 
> not for OpenMS.
>
> Now, we can nuance the situation - if you allow 'unknown' terms (e.g. 
> from a proprietary CV), but you do not allow terms that are known to 
> have another place reserved for them in the mapping file (such as the 
> scan polarity case). We're looking into developing this in an object 
> rule to test the concept, and it might well be that OpenMS does things 
> this way.
>
> But I'll also post to the list to get opinions and OpenMS feedback. 
> But I'll do that tomorrow.
>
>
> Cheers,
>
> lnnrt.
>
> Fredrik Levander wrote:
>> Hi Lennart,
>>
>> Matt found a possible problem with the PSI/EBI validator. I thought 
>> it was us running an old version of the validator on the ProDaC web 
>> site, but now I tried with the latest jmzml and config files locally, 
>> and it doesn't complain if
>>
>> MS:1000130 - positive scan
>> is used under scan instead of under spectrum. The openMS validator 
>> flags this as an error. The test was done with small.pwiz.1.1.mzML. 
>> Do you have any idea of the reason for this? Maybe the term is 
>> passing if there are already terms fulfilling the rules for the element?
>>
>> Best Regards
>>
>> Fredrik
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: PRODAC validator not checking polarity location
>> From:
>> Jari Häkkinen <ja...@th...>
>> Date:
>> Fri, 24 Jul 2009 23:26:01 +0200
>> To:
>> Matthew Chambers <mat...@va...>
>>
>> To:
>> Matthew Chambers <mat...@va...>
>> CC:
>> Fredrik Levander <Fre...@im...>
>>
>>
>> Hi,
>>
>> Thanks for the report. Fredrik or me will look at the problem as soon 
>> as we are back in office.
>>
>>
>> Jari
>>
>>
>> Matthew Chambers wrote:
>>> I recently realized that most pwiz vendor readers were putting 
>>> polarity in scan instead of spectrum and that this was expressed in 
>>> files that had been verified by the PRODAC validator. That worries 
>>> me since there's no telling what other attributes it's not checking. 
>>> I ran the old file through the OpenMS validator and it did catch the 
>>> misplaced polarity terms.
>>>
>>> Thanks,
>>> Matt

[Psidev-ms-dev] Phone conf minutes 20090825

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthusiasts,


Please find attached the minutes of today's phone conference.


Cheers,

lnnrt.

Re: [Psidev-ms-dev] PSI-MSS WG call reminder

[Shofstahl, J. <jim...@th...>]

Eric,

I may be a little late for today's call.  I have another call from 7:30AM to 8:30AM.

Jim Shofstahl

From: Eric Deutsch [mailto:ede...@sy...]
Sent: Monday, August 24, 2009 11:51 PM
To: 'Mass spectrometry standard development'
Cc: 'Eric Deutsch'
Subject: [Psidev-ms-dev] PSI-MSS WG call reminder

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call will be Tuesday 8am PDT:

http://www.timeanddate.com/worldclock/fixedtime.html?day=25&month=8&year=2009&hour=16&min=0&sec=0&p1=136

08:00 San Francisco
11:00 New York
16:00 London
17:00 Geneva

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

access code: 297427

Agenda:
1) mzML 1.1.0
- Manuscript
- Outstanding items

----
2) MIAPE-MS revision
- Have revised document to discuss at HUPO

----
3) TraML development
- New version 0.9.0 posted at dev page:
  http://www.psidev.info/index.php?q=node/405

- Implementations?
- What do we do with the <interpretation> cvParams insufficiency problem?

[Psidev-ms-dev] PSI-MSS WG call reminder

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

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
will be Tuesday 8am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=25
<http://www.timeanddate.com/worldclock/fixedtime.html?day=25&month=8&year=20
09&hour=16&min=0&sec=0&p1=136> &month=8&year=2009&hour=16&min=0&sec=0&p1=136

 

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)

 

access code: 297427

 

Agenda:

1) mzML 1.1.0

- Manuscript

- Outstanding items

 

----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO

 

----

3) TraML development

- New version 0.9.0 posted at dev page:

  http://www.psidev.info/index.php?q=node/405

 

- Implementations?

- What do we do with the <interpretation> cvParams insufficiency problem?

 

 

 

Re: [Psidev-ms-dev] Errors in example files

[Marc S. <st...@in...>]

Hi,
> As I recall, the versioning discussion with the CV was about when to 
> increment the various fields and what it would mean when they increment. 
> It had nothing to do with the schema or mapping file versions. 
> Obsoleting a term in the CV increments the minor version IIRC, but that 
> doesn't mean that files using older CVs and thus legitimately using 
> those terms should break. ProteoWizard deals with obsolete terms by 
> marking them as such in the giant CVID enum we generate with each new CV:
> http://proteowizard.svn.sourceforge.net/viewvc/proteowizard/trunk/pwiz/pwiz/data/msdata/cv.hpp
> For dealing with term name changes (which are subminor version 
> increments) when reading files, we ignore the term name and just assign 
> the most current name to each term's accession number.
Name changes do not matter in our approach. The accession is mapped to a 
member. That is not problem.
>  With this design, 
> we can approximate supporting older CV versions. We used to leave out 
> obsolete terms in our cv.hpp and I changed that precisely for this 
> reason. :)
>
> You did an object mapping from the CV/schema to C++ classes? So you have 
> classes with lots of strongly typed fields that will very often not have 
> any legitimate value? Wasn't that one of the reasons we went with the CV 
> approach in the schema instead of a traditional attribute approach?
>   
OpenMS is older than mzML. Most of the meta data classes were written 
before mzData 1.0. We already had tons of code that uses all the meta 
data, thus, starting all over was no option :) I have merged the models 
of mzData, mzXML and mzML by hand. Missing meta has so far been only a 
minor problem....
> I can't see an option about using newer CV terms than the one your code 
> is compiled for than to download the newer CV either for a new compile 
> and release, or on the fly when you encounter an unknown accession 
> number. With pwiz we currently rely on the former approach: files with 
> newer CVs will probably break older pwiz versions.
Right now we update the file only for a new release as well. We'll see 
how that works out...

-Marc

Re: [Psidev-ms-dev] Errors in example files

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

As I recall, the versioning discussion with the CV was about when to 
increment the various fields and what it would mean when they increment. 
It had nothing to do with the schema or mapping file versions. 
Obsoleting a term in the CV increments the minor version IIRC, but that 
doesn't mean that files using older CVs and thus legitimately using 
those terms should break. ProteoWizard deals with obsolete terms by 
marking them as such in the giant CVID enum we generate with each new CV:
http://proteowizard.svn.sourceforge.net/viewvc/proteowizard/trunk/pwiz/pwiz/data/msdata/cv.hpp
For dealing with term name changes (which are subminor version 
increments) when reading files, we ignore the term name and just assign 
the most current name to each term's accession number. With this design, 
we can approximate supporting older CV versions. We used to leave out 
obsolete terms in our cv.hpp and I changed that precisely for this 
reason. :)

You did an object mapping from the CV/schema to C++ classes? So you have 
classes with lots of strongly typed fields that will very often not have 
any legitimate value? Wasn't that one of the reasons we went with the CV 
approach in the schema instead of a traditional attribute approach?

I can't see an option about using newer CV terms than the one your code 
is compiled for than to download the newer CV either for a new compile 
and release, or on the fly when you encounter an unknown accession 
number. With pwiz we currently rely on the former approach: files with 
newer CVs will probably break older pwiz versions. But I'm open to 
implementing the on-the-fly CV downloading when it seems necessary. You 
don't have to have online access to support older CVs though. You can 
either archive all the CVs and ship them in a zip or something, or you 
can use a design like ours and make the current CV "all-inclusive" so as 
to support all previous CVs, including obsolete terms.

-Matt


Marc Sturm wrote:
> Hi all,
>   
>> I'm afraid you're jumping the gun a bit here. The documents you mention 
>> used older versions of the CV. It seems to be:
>> http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo?revision=1.84&view=markup
>> for PLGS and
>> http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo?revision=1.75&view=markup
>> for tiny.pwiz
>>
>> This version difference explains the validation problems you're seeing.
>>     
> I see the problem, but I'm not happy with it :(
>   
>>  
>> The integer value types were then obsoleted and the intensity term 
>> hadn't been renamed. It's up for debate whether these examples should be 
>> updated to use the newest CV, but the files are valid the way they are 
>> now. 
>>     
> If i remember the discussion in Turku right, we agreed on the following: 
> All changes must be backward-compatible within one version number. 
> Otherwise the (second/third) version number has to be incremented.
>   
>> It's good to catch this though because it's something a validator 
>> will have to deal with.You can't validate a file using an old CV 
>> against the newest CV and expect it to be error-free. 
>>     
> Allowing all CV version will lead hundreds of dialects. In contrast to 
> pwiz, OpenMS does not annotate the classes with arbitrary CV terms. We 
> have modelled the functionality of mzData, mzXML and mzML with classes 
> and fixed member variables. Thus, there is no way for us to support all 
> CV version. The pwiz approach supports all CV version, but the problem 
> arises later - programs using CV terms can never be sure which CV terms 
> to expect in certain class. My conclusion is that both pwiz and OpenMS 
> have really big problems to support all CV versions.
>   
>> At the same time, 
>> I expect you use some compile-time magic for the CV like we do in pwiz 
>> so supporting older versions of the CV could be troublesome. I'm not 
>> sure how to fix the problem, but I can diagnose it. :)
>>   
>>     
> Right! We cannot ship all intermediate CV version with OpenMS. 
> Downloading the CV version each time is not really an option either. 
> There is always proxy issues or you might have no internet connection.
>   
>> On another note, it was a pain in the ass to link up the CV version to 
>> the CVS version. We should definitely, definitely, definitely put RCS 
>> keywords in the OBO and mapping files so that we can match up the 
>> CVS/SVN revision to the OBO/mapping file itself. This will add a line like:
>> remark: $Id: psi-ms.obo 1.42 2009-08-14 22:12:04Z chambm $
>> to the OBO file and
>> <-- $Id: ms-mapping.xml 142 2009-08-14 22:12:04Z chambm $ -->
>> to the mapping file.
>>
>> Are there any objections to the RCS keywords?
>>   
>>     
> Nope.
>
> -Marc
>
>   
>> Marc Sturm wrote:
>>   
>>     
>>> Hi all,
>>>
>>> I updated our semantic validator and found that two example files are 
>>> not entirely valid:
>>>
>>> 1) plgs_example.mzML
>>>
>>> Error: CV term must have a unit: MS:1000042 - intensity
>>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>>> 'peak intensity'
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: CV term must have a unit: MS:1000042 - intensity
>>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>>> 'peak intensity'
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: CV term must have a unit: MS:1000042 - intensity
>>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>>> 'peak intensity'
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: CV term must have a unit: MS:1000042 - intensity
>>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>>> 'peak intensity'
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: CV term must have a unit: MS:1000042 - intensity
>>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>>> 'peak intensity'
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: CV term must have a unit: MS:1000042 - intensity
>>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>>> 'peak intensity'
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>>> the value type 'MS:1000521 ! 32-bit float'.
>>>
>>> 2) tiny.pwiz.1.1.mzML
>>>
>>> Error: CV term must have a unit: MS:1000042 - intensity
>>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>>> 'peak intensity'
>>>
>>> Best,
>>>   Marc
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>>> trial. Simplify your report design, integration and deployment - and focus on 
>>> what you do best, core application coding. Discover what's new with 
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>   
>>>     
>>>       
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>> trial. Simplify your report design, integration and deployment - and focus on 
>> what you do best, core application coding. Discover what's new with 
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] Errors in example files

[Marc S. <st...@in...>]

Hi all,
> I'm afraid you're jumping the gun a bit here. The documents you mention 
> used older versions of the CV. It seems to be:
> http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo?revision=1.84&view=markup
> for PLGS and
> http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo?revision=1.75&view=markup
> for tiny.pwiz
>
> This version difference explains the validation problems you're seeing.
I see the problem, but I'm not happy with it :(
>  
> The integer value types were then obsoleted and the intensity term 
> hadn't been renamed. It's up for debate whether these examples should be 
> updated to use the newest CV, but the files are valid the way they are 
> now. 
If i remember the discussion in Turku right, we agreed on the following: 
All changes must be backward-compatible within one version number. 
Otherwise the (second/third) version number has to be incremented.
> It's good to catch this though because it's something a validator 
> will have to deal with.You can't validate a file using an old CV 
> against the newest CV and expect it to be error-free. 
Allowing all CV version will lead hundreds of dialects. In contrast to 
pwiz, OpenMS does not annotate the classes with arbitrary CV terms. We 
have modelled the functionality of mzData, mzXML and mzML with classes 
and fixed member variables. Thus, there is no way for us to support all 
CV version. The pwiz approach supports all CV version, but the problem 
arises later - programs using CV terms can never be sure which CV terms 
to expect in certain class. My conclusion is that both pwiz and OpenMS 
have really big problems to support all CV versions.
> At the same time, 
> I expect you use some compile-time magic for the CV like we do in pwiz 
> so supporting older versions of the CV could be troublesome. I'm not 
> sure how to fix the problem, but I can diagnose it. :)
>   
Right! We cannot ship all intermediate CV version with OpenMS. 
Downloading the CV version each time is not really an option either. 
There is always proxy issues or you might have no internet connection.
> On another note, it was a pain in the ass to link up the CV version to 
> the CVS version. We should definitely, definitely, definitely put RCS 
> keywords in the OBO and mapping files so that we can match up the 
> CVS/SVN revision to the OBO/mapping file itself. This will add a line like:
> remark: $Id: psi-ms.obo 1.42 2009-08-14 22:12:04Z chambm $
> to the OBO file and
> <-- $Id: ms-mapping.xml 142 2009-08-14 22:12:04Z chambm $ -->
> to the mapping file.
>
> Are there any objections to the RCS keywords?
>   
Nope.

-Marc

> Marc Sturm wrote:
>   
>> Hi all,
>>
>> I updated our semantic validator and found that two example files are 
>> not entirely valid:
>>
>> 1) plgs_example.mzML
>>
>> Error: CV term must have a unit: MS:1000042 - intensity
>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>> 'peak intensity'
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: CV term must have a unit: MS:1000042 - intensity
>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>> 'peak intensity'
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: CV term must have a unit: MS:1000042 - intensity
>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>> 'peak intensity'
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: CV term must have a unit: MS:1000042 - intensity
>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>> 'peak intensity'
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: CV term must have a unit: MS:1000042 - intensity
>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>> 'peak intensity'
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: CV term must have a unit: MS:1000042 - intensity
>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>> 'peak intensity'
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
>> the value type 'MS:1000521 ! 32-bit float'.
>>
>> 2) tiny.pwiz.1.1.mzML
>>
>> Error: CV term must have a unit: MS:1000042 - intensity
>> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
>> 'peak intensity'
>>
>> Best,
>>   Marc
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>> trial. Simplify your report design, integration and deployment - and focus on 
>> what you do best, core application coding. Discover what's new with 
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   
>>     
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] Errors in example files

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

Hi Marc,

I'm afraid you're jumping the gun a bit here. The documents you mention 
used older versions of the CV. It seems to be:
http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo?revision=1.84&view=markup
for PLGS and
http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo?revision=1.75&view=markup
for tiny.pwiz

This version difference explains the validation problems you're seeing. 
The integer value types were then obsoleted and the intensity term 
hadn't been renamed. It's up for debate whether these examples should be 
updated to use the newest CV, but the files are valid the way they are 
now. It's good to catch this though because it's something a validator 
will have to deal with. You can't validate a file using an old CV 
against the newest CV and expect it to be error-free. At the same time, 
I expect you use some compile-time magic for the CV like we do in pwiz 
so supporting older versions of the CV could be troublesome. I'm not 
sure how to fix the problem, but I can diagnose it. :)

On another note, it was a pain in the ass to link up the CV version to 
the CVS version. We should definitely, definitely, definitely put RCS 
keywords in the OBO and mapping files so that we can match up the 
CVS/SVN revision to the OBO/mapping file itself. This will add a line like:
remark: $Id: psi-ms.obo 1.42 2009-08-14 22:12:04Z chambm $
to the OBO file and
<-- $Id: ms-mapping.xml 142 2009-08-14 22:12:04Z chambm $ -->
to the mapping file.

Are there any objections to the RCS keywords?

-Matt


Marc Sturm wrote:
> Hi all,
>
> I updated our semantic validator and found that two example files are 
> not entirely valid:
>
> 1) plgs_example.mzML
>
> Error: CV term must have a unit: MS:1000042 - intensity
> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
> 'peak intensity'
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: CV term must have a unit: MS:1000042 - intensity
> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
> 'peak intensity'
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: CV term must have a unit: MS:1000042 - intensity
> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
> 'peak intensity'
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: CV term must have a unit: MS:1000042 - intensity
> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
> 'peak intensity'
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: CV term must have a unit: MS:1000042 - intensity
> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
> 'peak intensity'
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: CV term must have a unit: MS:1000042 - intensity
> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
> 'peak intensity'
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
> Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
> the value type 'MS:1000521 ! 32-bit float'.
>
> 2) tiny.pwiz.1.1.mzML
>
> Error: CV term must have a unit: MS:1000042 - intensity
> Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
> 'peak intensity'
>
> Best,
>   Marc
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] Errors in example files

[Marc S. <stu...@gm...>]

Hi all,

I updated our semantic validator and found that two example files are 
not entirely valid:

1) plgs_example.mzML

Error: CV term must have a unit: MS:1000042 - intensity
Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
'peak intensity'
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: CV term must have a unit: MS:1000042 - intensity
Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
'peak intensity'
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: CV term must have a unit: MS:1000042 - intensity
Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
'peak intensity'
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: CV term must have a unit: MS:1000042 - intensity
Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
'peak intensity'
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: CV term must have a unit: MS:1000042 - intensity
Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
'peak intensity'
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: CV term must have a unit: MS:1000042 - intensity
Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
'peak intensity'
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.
Error: Binary data array of type 'MS:1000516 ! charge array' cannot have 
the value type 'MS:1000521 ! 32-bit float'.

2) tiny.pwiz.1.1.mzML

Error: CV term must have a unit: MS:1000042 - intensity
Error: Name of CV term not correct: 'MS:1000042 - intensity' should be 
'peak intensity'

Best,
  Marc

Re: [Psidev-ms-dev] scanList example

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

Sorry David, I misspoke. Right now the schema does guarantee that 
spectrum::id is unique. I believe this won't be a problem in the future 
because we will always add a unique axis to the nativeID (like Waters 
RAW has function=x instead of "process=x scan=x" and pointing to the 
sourceFile). And since we currently don't have any cases where there are 
different nativeID formats for MS spectra (BAF/U2 is the only case and 
that's MS/UV), I think mzIdentML is fine to say it supports mzML. Thanks 
for forwarding the issues to the list, I don't know how many here are 
also subscribed to PI.

-Matt


David Creasy wrote:
> Hi,
> (Also from the pi list - just in case it gets lost here)
>
> The documentation should probably also say:
>
> "It is not valid for a user to combine multiple runs together into a 
> single mzML file"
> (Looking through the mailing list, there was some discussion about this 
> a year or so ago at which time it looks as though it was supported).
>
> and the statement referenced below that says:
>    External  documents may use this identifier together with the mzML
>    filename or accession to reference a particular spectrum.
>
> needs changing to say:
>
> "You can't simply point to the mzML with an id because that id is only 
> unique in the mzML when combined with the sourceFileRef."
>
>
> Thanks,
> David
>
> David Creasy wrote:
>   
>> Hi,
>>
>> It came up on the 'pi' list that the mzML documentation doesn't include 
>> anything about the 'merged=<index>' format.
>>
>> I may be missing something, but the only reference I can see to 'merged' 
>> is for <spectrum id= where it says:
>>
>> The native identifier for a spectrum. For unmerged native spectra or 
>> spectra from older open file formats, the format of the identifier is 
>> defined in the PSI-MS CV and referred to in the mzML header. External 
>> documents may use this identifier together with the mzML filename or 
>> accession to reference a particular spectrum.
>>
>> However, the plgs_example_1.1.0.mzML seems to make sense, so it's not a 
>> high priority.
>>
>>  From discussion on the pi list, I guess the documentation should also say:
>> "merged=<index>" is a valid id for ANY nativeID format.
>>
>> Thanks,
>> David
>>
>> Matt Chambers wrote:
>>     
>>> It looks good. I think we should stick with "merged=<index>" for the id 
>>> format, just because it's simpler to ignore the method of combination at 
>>> that level. Presumably the other scan elements will have their own scan 
>>> times in the final file? Can't think of anything else, good job! The 
>>> file makes perfect sense to me, this approach is leaps and bounds better 
>>> than previous attempts at showing merged scans.
>>>
>>> -Matt
>>>
>>>
>>> Fredrik Levander wrote:
>>>       
>>>> Hi All,
>>>>
>>>> I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
>>>> generated by conversion of a ProteinLynx Global Server file.
>>>>
>>>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML
>>>>
>>>> The file still has to go through semantic validation, but I was mainly 
>>>> wondering if anyone has opinions about how the spectrum/scan ids are 
>>>> written, (and if the file makes sense at all)?
>>>>
>>>> Regards
>>>>
>>>> Fredrik
>>>>
>>>>   
>>>>         
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>       
>
>   

Re: [Psidev-ms-dev] scanList example

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

Hi,
(Also from the pi list - just in case it gets lost here)

The documentation should probably also say:

"It is not valid for a user to combine multiple runs together into a 
single mzML file"
(Looking through the mailing list, there was some discussion about this 
a year or so ago at which time it looks as though it was supported).

and the statement referenced below that says:
   External  documents may use this identifier together with the mzML
   filename or accession to reference a particular spectrum.

needs changing to say:

"You can't simply point to the mzML with an id because that id is only 
unique in the mzML when combined with the sourceFileRef."


Thanks,
David

David Creasy wrote:
> Hi,
> 
> It came up on the 'pi' list that the mzML documentation doesn't include 
> anything about the 'merged=<index>' format.
> 
> I may be missing something, but the only reference I can see to 'merged' 
> is for <spectrum id= where it says:
> 
> The native identifier for a spectrum. For unmerged native spectra or 
> spectra from older open file formats, the format of the identifier is 
> defined in the PSI-MS CV and referred to in the mzML header. External 
> documents may use this identifier together with the mzML filename or 
> accession to reference a particular spectrum.
> 
> However, the plgs_example_1.1.0.mzML seems to make sense, so it's not a 
> high priority.
> 
>  From discussion on the pi list, I guess the documentation should also say:
> "merged=<index>" is a valid id for ANY nativeID format.
> 
> Thanks,
> David
> 
> Matt Chambers wrote:
>> It looks good. I think we should stick with "merged=<index>" for the id 
>> format, just because it's simpler to ignore the method of combination at 
>> that level. Presumably the other scan elements will have their own scan 
>> times in the final file? Can't think of anything else, good job! The 
>> file makes perfect sense to me, this approach is leaps and bounds better 
>> than previous attempts at showing merged scans.
>>
>> -Matt
>>
>>
>> Fredrik Levander wrote:
>>> Hi All,
>>>
>>> I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
>>> generated by conversion of a ProteinLynx Global Server file.
>>>
>>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML
>>>
>>> The file still has to go through semantic validation, but I was mainly 
>>> wondering if anyone has opinions about how the spectrum/scan ids are 
>>> written, (and if the file makes sense at all)?
>>>
>>> Regards
>>>
>>> Fredrik
>>>
>>>   
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

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

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

Re: [Psidev-ms-dev] scanList example

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

Hi,

It came up on the 'pi' list that the mzML documentation doesn't include 
anything about the 'merged=<index>' format.

I may be missing something, but the only reference I can see to 'merged' 
is for <spectrum id= where it says:

The native identifier for a spectrum. For unmerged native spectra or 
spectra from older open file formats, the format of the identifier is 
defined in the PSI-MS CV and referred to in the mzML header. External 
documents may use this identifier together with the mzML filename or 
accession to reference a particular spectrum.

However, the plgs_example_1.1.0.mzML seems to make sense, so it's not a 
high priority.

 From discussion on the pi list, I guess the documentation should also say:
"merged=<index>" is a valid id for ANY nativeID format.

Thanks,
David

Matt Chambers wrote:
> It looks good. I think we should stick with "merged=<index>" for the id 
> format, just because it's simpler to ignore the method of combination at 
> that level. Presumably the other scan elements will have their own scan 
> times in the final file? Can't think of anything else, good job! The 
> file makes perfect sense to me, this approach is leaps and bounds better 
> than previous attempts at showing merged scans.
> 
> -Matt
> 
> 
> Fredrik Levander wrote:
>> Hi All,
>>
>> I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
>> generated by conversion of a ProteinLynx Global Server file.
>>
>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML
>>
>> The file still has to go through semantic validation, but I was mainly 
>> wondering if anyone has opinions about how the spectrum/scan ids are 
>> written, (and if the file makes sense at all)?
>>
>> Regards
>>
>> Fredrik
>>
>>   
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

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

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

[Psidev-ms-dev] PSI-MSS WG call notes

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

Present: Lennart, Darren, Jim, Eric, Steffen, Matt, Pierre-Alain



1) mzML 1.1.0

- Outstanding items

  - Still no decision on the version attribute business

  + Proposal is to say in the spec doc that the schemaLocation says
mzML1.1.0.xsd

  - Policy for source directories: finalize and document

  + Eric will write this in the spec

  - proposal to add terms “m/z precision array” and “intensity precision
array”: def number of significant digits

  + Eric will do this

  + Should there a more global way of specifying the resolution?

- Manuscript

+ No news yet

- BioPortal is now automatically pulling our CV from CVS. See:
http://bioportal.bioontology.org/ontologies?filter=PSI

- Our CV is now on OLS as well

- Terms from Kalhardt

  Change: fourier transform ion cyclotron resonance mass spectrometer

  To: fourier transform ion cyclotron resonance analyzer

+ Add below that: quadrupole FTICR? Ask for clairifcation

+ Pierre-Alain will follow up and determine what changes there should be.

+ Lennart will label old Mass Spec CV as Obsolete

+ As a result of investigating the CV, it turns out the analyzer section can
do with a thorough read-through. Matt will give it a look

+ Matt will update the ion trap portion of the CV

+ What about FTICR? Should that be under cyclotron?





----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO

+ Sandra has sent out a survey to PSI folks for feedback before sending out
to editors

+ If you haven’t received this email and want to, email Pierre-Alain

+ touches are being done on the MIAPE document





----

3) TraML development

- New version 0.9.0 posted at dev page:

  http://www.psidev.info/index.php?q=node/405



- Significant updates

  - Most everything is a cvParam

  - “transition predicted from consensus spectrum ion trap” split into two
terms

  - Added sourceFileList from mzML?

  - HTML doc, spec doc, toy example, mapping file, CV all updated

- Implementations?

- What do we do with the <interpretation> cvParams?



Next call in two weeks







*From:* ede...@sy... [mailto:ede...@sy...]
*Sent:* Monday, August 10, 2009 3:22 PM
*To:* Mass spectrometry standard development
*Cc:* ede...@sy...
*Subject:* PSI-MSS WG call reminder



Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
will be Tuesday 8am PDT:



http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=8&year=2009&hour=16&min=0&sec=0&p1=136



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)



access code: 297427



Agenda:

1) mzML 1.1.0

- Outstanding items

  - Still no decision on the version attribute business

  - Policy for source directories: finalize and document

  - proposal to add terms “m/z precision array” and “intensity precision
array”: def number of significant digits

- Manuscript

- BioPortal is now automatically pulling our CV from CVS. See:
http://bioportal.bioontology.org/ontologies?filter=PSI



----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO



----

3) TraML development

- New version 0.9.0 posted at dev page:

  http://www.psidev.info/index.php?q=node/405



- Significant updates

  - Most everything is a cvParam

  - “transition predicted from consensus spectrum ion trap” split into two
terms

  - Added sourceFileList from mzML?

  - HTML doc, spec doc, toy example, mapping file, CV all updated

- Implementations?

- What do we do with the <interpretation> cvParams?

Re: [Psidev-ms-dev] Changes to PSIMS CV

[Kallhardt M. <Mar...@bd...>]

Hi,

The first description is it.

I will try to post  a more descriptive definition to the obo entry.

 

 

Best Regards,

i.A. Marius Kallhardt

 

Software Developer

Bruker Daltonik GmbH (Bremen)

Phone:  +49 (0) 421 2205 467

Fax:  +49 (0) 421 2205 305

Mail: mar...@bd... <mailto:mar...@bd...> 

 

 

 

From: Pierre-Alain Binz [mailto:pie...@is...] 
Sent: Dienstag, 11. August 2009 17:19
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Changes to PSIMS CV

 

Hi Marius,
to understand better the issue here can you precise the following:: 

does quadrupole fticr describes 
- a hybrid instrument quadrupole analyser followed by an fticr analyser
- a quadrupole architecture that precises the term fticr (in that case
this is describing one single analyser)

best regards
Pierre-Alain

Bruker Daltonik GmbH
--------------------------------------------------------

Fahrenheitstrasse 4
28359 Bremen
Germany 

Permoserstrasse 15
04318 Leipzig
Germany
Geschaftsfuhrer
Frank Laukien, Ph. D.
Gerd Hulso
Sebastian Meyer-Plath
Stefan Ruge
Ian Sanders, Ph. D.
Dr. Michael Schubert
Sitz der Gesellschaft
Bremen 

Handelsregister 
Amtsgericht Bremen
HRB 8150
www.bdal.de


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

Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich fur die ordnungsgema?e, vollstandige und verzogerungsfreie Ubertragung der Nachricht. 
Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestatigt wird.
Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. 
The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax.

Bruker Daltonik GmbH------------------------------Fahrenheitstrasse 428359 Bremen, Germany Permoserstrasse 1504318 Leipzig, Germany Geschaftsfuhrer: Frank Laukien, Ph. D., Gerd Hulso, Sebastian Meyer-Plath, Stefan Ruge,    Ian Sanders, Ph. D., Dr. Michael Schubert Sitz der Gesellschaft: Bremen Handelsregister Amtsgericht Bremen: HRB 8150 www.bdal.de
------------------------------------------------------------Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich fur die ordnungsgema?e, vollstandige und verzogerungsfreie Ubertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestatigt wird.Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax.

Re: [Psidev-ms-dev] PSI logo ?

[Henning H. <hen...@go...>]

Just sent it to Steffen in high resolution.


Steffen Neumann wrote:
> Hi,
>
> I am looking for the PSI logo for the IMSC poster
> in either a decent resolution or as vector graphics.
>
> Anyone got a pointer or a copy ?
>
> HUPO I found here: http://www.hupo.org/overview/logos/
>
> Yours,
> Steffen
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] Changes to PSIMS CV

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

Hi Marius,
to understand better the issue here can you precise the following::

does quadrupole fticr describes
- a hybrid instrument quadrupole analyser followed by an fticr analyser
- a quadrupole architecture that precises the term fticr (in that case 
this is describing one single analyser)

best regards
Pierre-Alain

Kallhardt Marius wrote:
>
> Hello from Bremen,
>
>  
>
> I have some changes for the psi-ms.obo, is it OK if sent an attachment 
> to the whole mailing list or should I sent it to a specific email address?
>
> It is mainly new terms for Bruker Daltonics instruments and some 
> [is_a] relationship changes ("subgroups" for our instrument series).
>
>  
>
> Another proposal (open for discussion here) is the including of an 
> "ftms" subgroup -- [is_a: MS:1000443 ! mass analyzer type].
>
> This would change [id: MS:1000079,  name: fourier transform ion 
> cyclotron resonance] to a [is_a: ID:XXXXXXX ! ftms].
>
> Then we'd like to add [id: ID:XXXXXXX, name: quadrupole fourier 
> transform ion cyclotron resonance, is_a: ID:XXXXXXX ! ftms] (for our 
> FTMSs).
>
>  
>
> Best Regards,
>
> i.A. Marius Kallhardt
>
>  
>
> Software Developer
>
> Bruker Daltonik GmbH (Bremen)
>
> Phone:  +49 (0) 421 2205 467
>
> Fax:  +49 (0) 421 2205 305
>
> Mail: mar...@bd... <mailto:mar...@bd...>
>
>  
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] PSI logo ?

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

Hi,

I am looking for the PSI logo for the IMSC poster
in either a decent resolution or as vector graphics.

Anyone got a pointer or a copy ?

HUPO I found here: http://www.hupo.org/overview/logos/

Yours,
Steffen

[Psidev-ms-dev] PSI-MSS WG call reminder

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

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
will be Tuesday 8am PDT:



http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=8&year=2009&hour=16&min=0&sec=0&p1=136



08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)



access code: 297427



Agenda:

1) mzML 1.1.0

- Outstanding items

  - Still no decision on the version attribute business

  - Policy for source directories: finalize and document

  - proposal to add terms “m/z precision array” and “intensity precision
array”: def number of significant digits

- Manuscript

- BioPortal is now automatically pulling our CV from CVS. See:
http://bioportal.bioontology.org/ontologies?filter=PSI



----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO



----

3) TraML development

- New version 0.9.0 posted at dev page:

  http://www.psidev.info/index.php?q=node/405



- Significant updates

  - Most everything is a cvParam

  - “transition predicted from consensus spectrum ion trap” split into two
terms

  - Added sourceFileList from mzML?

  - HTML doc, spec doc, toy example, mapping file, CV all updated

- Implementations?

- What do we do with the <interpretation> cvParams?

[Psidev-ms-dev] PSI-MSS WG call cancelled

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

Hi everyone, we were inquorate last week and I'm afraid this week I cannot
make it. Let's regroup next week with a PSI-MSS WG meeting for sure.
Hopefully there will be plenty of things to talk about by then.

 

Regards,

Eric

 

 

[Psidev-ms-dev] mzML 1.1 viewer for windows

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

Just FYI, I have updated InsilicosViewer
(http://www.insilicos.com/Insilicos_Viewer.html) to use the latest
ProteoWizard code for support of mzML 1.1 .

 

Many thanks and mad respect to the ProteoWizard team for all the effort
they're putting into making mzML a successful standard by creating a robust,
tested, and multi-platform reference implementation.

 

Brian

Re: [Psidev-ms-dev] Changes to PSIMS CV

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

Hi Marius, the list probably won't accept such a large attachment. Why don't
you send the obo file to me directly and then post to the list the
differences and proposed new terms.

 

The ftms changes sound okay to me, but maybe someone more familiar with
these kinds of instruments could weigh in.

 

Regards,

Eric

 

 

  _____  

From: Kallhardt Marius [mailto:Mar...@bd...] 
Sent: Tuesday, July 28, 2009 11:35 PM
To: Mass spectrometry standard development
Subject: [Psidev-ms-dev] Changes to PSIMS CV

 

Hello from Bremen,

 

I have some changes for the psi-ms.obo, is it OK if sent an attachment to
the whole mailing list or should I sent it to a specific email address?

It is mainly new terms for Bruker Daltonics instruments and some [is_a]
relationship changes ("subgroups" for our instrument series).

 

Another proposal (open for discussion here) is the including of an "ftms"
subgroup - [is_a: MS:1000443 ! mass analyzer type].

This would change [id: MS:1000079,  name: fourier transform ion cyclotron
resonance] to a [is_a: ID:XXXXXXX ! ftms].

Then we'd like to add [id: ID:XXXXXXX, name: quadrupole fourier transform
ion cyclotron resonance, is_a: ID:XXXXXXX ! ftms] (for our FTMSs).

 

Best Regards,

i.A. Marius Kallhardt

 

Software Developer

Bruker Daltonik GmbH (Bremen)

Phone:  +49 (0) 421 2205 467

Fax:  +49 (0) 421 2205 305

Mail: mar...@bd...

 

[Psidev-ms-dev] PSI-MS out in new OLS

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthusiasts,


The Ontology Lookup Service (OLS) has been updated to a new and 
excisting version, which -amongst others- means that the PSI-MS CV is 
loaded in it.

So if you need a quick browse through the CV, you can now do it here:

http://www.ebi.ac.uk/ols

Additionally, the OLS webservice can now also be used to query terms as 
well, implying that the Java mzML validator developed by EBI can be 
reconfigured to use the OLS instead of a static downloaded file as well.

Those of you who are interested in the latter can contact me for details 
to enter in the corresponding config file (no code changes or 
recompilation required) - but I'm sure some of you will be able to 
figure it out yourselves (all other CVs are effectively already loaded 
through OLS, so you can copy-paste and simply change the ontology name, 
which can be found on the OLS website).


Cheers,

lnnrt.