psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] TraML 0.9.4 draft released

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

I've updated the pwiz TraML implementation to 0.9.4 and validated the 
resulting example files against OpenMS (which revealed quite a few 
glitches in our output). I fixed almost all of them but I think there 
may be a glitch in the validator. The semantic validation seems to have 
stopped working (worked the first time then afterward just gave the 
below error) and I'm getting a non-sensical schema error.

*Validation against the schema:*
Validation error in file './files/tiny_miape.pwiz.traML' line 24 column 
18: element 'cvParam' is not allowed for content model '(cvParam,)' 
Failed: errors are listed above!

*Semantic validation:*
All reported errors are only reported once, in arbitrary order:

Error: Unexpected internal error (The value 'UO:0000269' was used but is not valid! Invalid CV identifier!)


The schema error seems to point at the first </Instrument> in:
<InstrumentList>
<Instrument id="LCQ">
<cvParam cvRef="MS" accession="MS:1000554" name="LCQ Deca" value=""/>
<cvParam cvRef="MS" accession="MS:1000529" name="instrument serial 
number" value="23433"/>
</Instrument>
<Instrument id="QTRAP">
<cvParam cvRef="MS" accession="MS:1000139" name="4000 Q TRAP" value=""/>
</Instrument>
</InstrumentList>

And there's no UO:0000269 in the mapping file or in my document. I have 
no idea where that's coming from. I'm attaching the document.

-Matt


On 3/31/2010 6:14 PM, Eric Deutsch wrote:
>
> Hi everyone, TraML version 0.9.4 has been posted at the development 
> web page:
>
> http://www.psidev.info/index.php?q=node/405
>
> The links to HTML documentation and examples files are all updated.
>
> Please examine the materials and respond.
>
> Major changes from 0.9.3:
>
> - <RetentionTime> is now permitted for each <Transition> and <Target>
>
> Please update your implementations and example files and validators 
> and report.
>
> I think the OpenMS implementation is already at 0.9.4, and the on-line 
> validator is up-to-date. It would be great if others would update 
> their implementations and do some testing.
>
> We have three example files posted on the dev page. This is the 
> minimum number required for submission, but it would be nice to 
> collect a few more. Please implement and generate some files if you can!
>
> Thanks,
>
> Eric
>
> ----------------------------------
>
> Eric Deutsch, Ph.D.
> Institute for Systems Biology
> 1441 North 34th Street
> Seattle WA 98103
> Tel: 206-732-1397
> Fax: 206-732-1260
> Email: ede...@sy... <mailto:ede...@sy...>
> WWW: http://www.systemsbiology.org/Senior_Research_Scientists/Eric_Deutsch
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>    

[Psidev-ms-dev] PSI-MSS WG call reminder <1 hr time shift!>

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

Hi everyone, I now have a conflicting meeting at the usual 8am timeslot, and
next week is ASMS, so I’d like to try to squeeze in the call one hour later.
I hope most participants can be tolerant of this.



So, the next PSI Mass Spectrometry Standards Working Group call will be
Tuesday 9am PDT:



http://www.timeanddate.com/worldclock/fixedtime.html?day=18&month=5&year=2010&hour=17&min=0&sec=0&p1=136



09:00 San Francisco

12:00 New York

15:00 London

18: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 has been reviewed and the comments addressed and resubmitted.

- The editors have come back and asked for the inclusion of a “tangible
example of an application" and then it will be acceptable for publication.
Response in progress.

- Matt has released and posted the updated 1.1.1 version of indexedmzML
schema: <indexList> name attribute will be enumerated to “spectrum” or
“chromatogram” to disallow other creative values

- Matt will update the example files to reference mzML 1.1.0 but indexedmzML
1.1.1

- New schema is posted on the web. The tiny file has been updated.

- Eric will update the web site announcing the change and update hyperlink

- How do we handle lock mass corrections?

- We should assemble list of calibrants and make them specific terms

- Bruker uses Lithium Formiate; others?

- Jim will find out what Thermo is using

- Jim will look at an old email and send out the information

- Matt will contact David Anderson and Mike Ashton and ask about a date in
lieu of checksum

- Need to test FAIMS support in mzML

- Other items?



----

2) MIAPE-MS revision

- Document is ready to be submitted, but..

- We need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- We can use the sample MIAPE-compliant mzML file

- Pierre-Alain will contact Juan-Pablo to see if he has some suitable
examples in Proteo-Red

- Pierre-Alain has received an example from Proteo-Red

- Richard will look into PRIDE to see if there may be a good example there

- Pierre-Alain is looking through PRIDE to find a good example.

- The last example would be a MIAPE compliant mzML document

- Looking in Peptidome might be an alternative for finding a nicely
annotated dataset

- Waiting to sync with MIAPE-MSI as well

- Keep working on our documents and when we’re ready, see if we should wait

- We also need to coordinate the creation of MIAPE-Quant

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out



----

3) TraML development

- New version 0.9.4 released and is available at
http://www.psidev.info/index.php?q=node/405

- Specification document is updated. Please examine. Is it ready for
submission?


http://www.peptideatlas.org/tmp/TraML/0.9.4/TraML_0.9.4.1_specificationDocument.doc

- Implementations? Please update to 0.9.4 and test

  - Matt will implement in ProteoWizard

  - Andreas will implement in OpenMS and update on-line validator

  - ISB implementation in ATAQS nearly done

  - Jim has an implementation but just will need to update to 0.9.4

  - David Cox at Sciex will test implement?

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304

- Manuscript is in preparation and will be sent out shortly



----

4) PSI session at World HUPO in Sydney

- PSI will have a session. Presenters will be Eric, Juan Antonio, Henning.

- JuanAn maybe can’t go?

- Eric will present on the work of the group: mzML 1.1, TraML x.x, MIAPE-MS

- Abstract is accepted

- Other reports?

- Perhaps some of us try to meet at ASMS briefly?

- Note that there will be a Computational Mass Spectrometry/Bioinformatics
for MS meeting at ASMS

  - Wednesday, May 26th, 2010, 05:45-07:00pm Hall 2, Salt Palace Convention
Center

  - Featuring Alexey Nesvizhskii and David L. Tabb



----

5) Working with ASMS on controlled vocabulary

- no update



Next meeting:

- In 3 weeks? June 8?

Re: [Psidev-ms-dev] Strange validation issue

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

Apologies for the delayed reply.

We distribute the schemas with Mascot 2.3 because we can't guarantee 
that there will be an internet connection for validating the instance 
documents.  And yes, I recollect that they were taken from the 
repository rather than the official location. When we distribute the 
next Mascot patch, we'll distribute the index xsd without the space. I 
think this is a reasonable compromise and doesn't require any change 
from you.

And yes, one day, we'll update to a later version of Xerces...

Thanks,
David

Fredrik Levander wrote:
> Then the CVS version should be copied to the official location, which 
> could be done without version change.
> That would also imply that the change could be done to the _idx without 
> version change too then, since it was agreed as ok for the other schema?
> 
> Fredrik
> 
> On 2010-05-05 18:39, Matthew Chambers wrote:
>> The official location is
>> http://psidev.info/files/ms/mzML/xsd/mzML1.1.0.xsd . It still has the
>> spaces before .// . If Mascot's validator is working with 1.1, then it
>> isn't using the official location of the schema. It may be using the CVS
>> one directly.
>>
>> -Matt
>>
>>
>> On 5/5/2010 11:31 AM, Fredrik Levander wrote:
>>    
>>> Apparently the mzML 1.1 schema is fine, but the idx needs to have one
>>> space removed. Since it was recently updated to 1.1.1 it should be ok to
>>> update it once again? Maybe with version bump, even if it is not an
>>> actual functional schema change (more than for buggy software).
>>>
>>>     Fredrik
>>>
>>> On 2010-05-05 18:26, Matthew Chambers wrote:
>>>
>>>      
>>>> Ah, I see that the change actually was made in the XSD in the CVS repo
>>>> on 6/3/2009, but it was never propagated to the official location. I
>>>> guess perhaps we agreed to do a silent update at that time? I can't
>>>> remember the discussion in the call.
>>>>
>>>> -Matt
>>>>        
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>    
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> 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] Strange validation issue

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

Then the CVS version should be copied to the official location, which 
could be done without version change.
That would also imply that the change could be done to the _idx without 
version change too then, since it was agreed as ok for the other schema?

Fredrik

On 2010-05-05 18:39, Matthew Chambers wrote:
> The official location is
> http://psidev.info/files/ms/mzML/xsd/mzML1.1.0.xsd . It still has the
> spaces before .// . If Mascot's validator is working with 1.1, then it
> isn't using the official location of the schema. It may be using the CVS
> one directly.
>
> -Matt
>
>
> On 5/5/2010 11:31 AM, Fredrik Levander wrote:
>    
>> Apparently the mzML 1.1 schema is fine, but the idx needs to have one
>> space removed. Since it was recently updated to 1.1.1 it should be ok to
>> update it once again? Maybe with version bump, even if it is not an
>> actual functional schema change (more than for buggy software).
>>
>>     Fredrik
>>
>> On 2010-05-05 18:26, Matthew Chambers wrote:
>>
>>      
>>> Ah, I see that the change actually was made in the XSD in the CVS repo
>>> on 6/3/2009, but it was never propagated to the official location. I
>>> guess perhaps we agreed to do a silent update at that time? I can't
>>> remember the discussion in the call.
>>>
>>> -Matt
>>>        
> ------------------------------------------------------------------------------
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>    

Re: [Psidev-ms-dev] Strange validation issue

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

The official location is 
http://psidev.info/files/ms/mzML/xsd/mzML1.1.0.xsd . It still has the 
spaces before .// . If Mascot's validator is working with 1.1, then it 
isn't using the official location of the schema. It may be using the CVS 
one directly.

-Matt


On 5/5/2010 11:31 AM, Fredrik Levander wrote:
> Apparently the mzML 1.1 schema is fine, but the idx needs to have one
> space removed. Since it was recently updated to 1.1.1 it should be ok to
> update it once again? Maybe with version bump, even if it is not an
> actual functional schema change (more than for buggy software).
>
>    Fredrik
>
> On 2010-05-05 18:26, Matthew Chambers wrote:
>    
>> Ah, I see that the change actually was made in the XSD in the CVS repo
>> on 6/3/2009, but it was never propagated to the official location. I
>> guess perhaps we agreed to do a silent update at that time? I can't
>> remember the discussion in the call.
>>
>> -Matt

Re: [Psidev-ms-dev] Strange validation issue

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

Apparently the mzML 1.1 schema is fine, but the idx needs to have one 
space removed. Since it was recently updated to 1.1.1 it should be ok to 
update it once again? Maybe with version bump, even if it is not an 
actual functional schema change (more than for buggy software).

  Fredrik

On 2010-05-05 18:26, Matthew Chambers wrote:
> Ah, I see that the change actually was made in the XSD in the CVS repo
> on 6/3/2009, but it was never propagated to the official location. I
> guess perhaps we agreed to do a silent update at that time? I can't
> remember the discussion in the call.
>
> -Matt
>
>
> On 5/5/2010 11:21 AM, Matthew Chambers wrote:
>    
>> Hi David,
>>
>> I'm sure we want to accommodate reasonable limitations on the schema due
>> to validation software bugs, but a change to a released schema might be
>> going too far. We should have gotten this into 1.1 (it was mentioned in
>> the next WG conference call notes), but it unfortunately got lost in the
>> ether. :(
>>
>> Is it a reasonable solution for people stuck with an affected version of
>> Xerces to simply catch and ignore the buggy error? Otherwise we'd be
>> looking at either changing the schema with no version bump (thus
>> violating our own guidelines) or bumping to mzML 1.1.1 and mzML_idx 1.1.2.
>>
>> -Matt
>>
>>
>> On 5/1/2009 6:27 AM, David Creasy wrote:
>>
>>      
>>> Hi,
>>>
>>> I've got a couple of issues with the example docs and schema not
>>> validating. The first is that we use a rather old version of Xerces.
>>> There's a known problem:
>>>
>>> http://marc.info/?l=xerces-c-dev&m=114345502019802&w=2
>>>
>>> The solution is simple, just change, for example:
>>> <xs:selector xpath=".//dx:spectrum | .//dx:chromatogram ...
>>>
>>> to
>>>
>>> <xs:selector xpath=".//dx:spectrum |.//dx:chromatogram ...
>>>
>>> (i.e. remove the space after the | )
>>>
>>> It's not so easy for us (and possibly others) to update to a later
>>> Xerces. There's quite a few occurrences of this, so if you could change
>>> them, that would be appreciated.
>>>
>>>
>>>        
>> ...
>>
>>      
>>> Cheers,
>>>
>>> David
>>>        
> ------------------------------------------------------------------------------
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>    

Re: [Psidev-ms-dev] Strange validation issue

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

Ah, I see that the change actually was made in the XSD in the CVS repo 
on 6/3/2009, but it was never propagated to the official location. I 
guess perhaps we agreed to do a silent update at that time? I can't 
remember the discussion in the call.

-Matt


On 5/5/2010 11:21 AM, Matthew Chambers wrote:
> Hi David,
>
> I'm sure we want to accommodate reasonable limitations on the schema due
> to validation software bugs, but a change to a released schema might be
> going too far. We should have gotten this into 1.1 (it was mentioned in
> the next WG conference call notes), but it unfortunately got lost in the
> ether. :(
>
> Is it a reasonable solution for people stuck with an affected version of
> Xerces to simply catch and ignore the buggy error? Otherwise we'd be
> looking at either changing the schema with no version bump (thus
> violating our own guidelines) or bumping to mzML 1.1.1 and mzML_idx 1.1.2.
>
> -Matt
>
>
> On 5/1/2009 6:27 AM, David Creasy wrote:
>    
>> Hi,
>>
>> I've got a couple of issues with the example docs and schema not
>> validating. The first is that we use a rather old version of Xerces.
>> There's a known problem:
>>
>> http://marc.info/?l=xerces-c-dev&m=114345502019802&w=2
>>
>> The solution is simple, just change, for example:
>> <xs:selector xpath=".//dx:spectrum | .//dx:chromatogram ...
>>
>> to
>>
>> <xs:selector xpath=".//dx:spectrum |.//dx:chromatogram ...
>>
>> (i.e. remove the space after the | )
>>
>> It's not so easy for us (and possibly others) to update to a later
>> Xerces. There's quite a few occurrences of this, so if you could change
>> them, that would be appreciated.
>>
>>      
> ...
>    
>> Cheers,
>>
>> David

Re: [Psidev-ms-dev] Strange validation issue

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

Hi David,

I'm sure we want to accommodate reasonable limitations on the schema due 
to validation software bugs, but a change to a released schema might be 
going too far. We should have gotten this into 1.1 (it was mentioned in 
the next WG conference call notes), but it unfortunately got lost in the 
ether. :(

Is it a reasonable solution for people stuck with an affected version of 
Xerces to simply catch and ignore the buggy error? Otherwise we'd be 
looking at either changing the schema with no version bump (thus 
violating our own guidelines) or bumping to mzML 1.1.1 and mzML_idx 1.1.2.

-Matt


On 5/1/2009 6:27 AM, David Creasy wrote:
> Hi,
>
> I've got a couple of issues with the example docs and schema not
> validating. The first is that we use a rather old version of Xerces.
> There's a known problem:
>
> http://marc.info/?l=xerces-c-dev&m=114345502019802&w=2
>
> The solution is simple, just change, for example:
> <xs:selector xpath=".//dx:spectrum | .//dx:chromatogram ...
>
> to
>
> <xs:selector xpath=".//dx:spectrum |.//dx:chromatogram ...
>
> (i.e. remove the space after the | )
>
> It's not so easy for us (and possibly others) to update to a later
> Xerces. There's quite a few occurrences of this, so if you could change
> them, that would be appreciated.
>    
...
> Cheers,
>
> David

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

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

Hi everyone, here are the notes from the telecon:



Present: Richard, Jim, Eric, Matt, Pierre-Alain,



1) mzML 1.1.0

- Manuscript has been revised and the revision sent out for comment. To be
resubmitted in 2 days.

- Matt will release updated 1.1.1 of indexedmzML schema: <indexList> name
attribute will be enumerated to “spectrum” or “chromatogram”

- Matt will update the example files to reference mzML 1.1.0 but indexedmzML
1.1.1

+ New schema is posted on the web. The tiny file has been updated.

+ Eric will update the web site announcing the change and update hyperlink

- How do we handle lock mass corrections?

- We should assemble list of calibrants and make them specific terms

- Bruker uses Lithium Formiate; others?

- Jim will find out what Thermo is using

+ Jim will look at an old email and send out the information

- Matt will contact David Anderson and Mike Ashton and ask about a date in
lieu of checksum

- Need to test FAIMS support in mzML

- Other items?



----

2) MIAPE-MS revision

- Document is ready to be submitted, but..

- We need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- We can use the sample MIAPE-compliant mzML file

- Pierre-Alain will contact Juan-Pablo to see if he has some suitable
examples in Proteo-Red

+ Pierre-Alain has received an example from Proteo-Red

- Richard will look into PRIDE to see if there may be a good example there

+ Pierre-Alain is looking through PRIDE to find a good example.

+ The last example would be a MIAPE compliant mzML document

+ Looking in Peptidome might be an alternative for finding a nicely
annotated dataset

- Waiting to sync with MIAPE-MSI as well

+ Keep working on our documents and when we’re ready, see if we should wait

+ We also need to coordinate the creation of MIAPE-Quant

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out



----

3) TraML development

- New version 0.9.4 released and is available at
http://www.psidev.info/index.php?q=node/405

- Specification document is updated. Please examine. Is it ready for
submission?


http://www.peptideatlas.org/tmp/TraML/0.9.4/TraML_0.9.4.1_specificationDocument.doc

- Implementations? Please update to 0.9.4 and test

  - Matt will implement in ProteoWizard

  + Matt will get to it first think next week

  - Andreas will implement in OpenMS and update on-line validator

  - ISB implementation in ATAQS nearly done

  - Jim has an implementation but just will need to update to 0.9.4

 + Jim is almost done. Will get create metabolomics file with the software

  - David Cox at Sciex will test implement?

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304

- Manuscript is also in preparation



----

4) PSI session at World HUPO in Sydney

- PSI will have a session. Presenters will be Eric, Juan Antonio, Henning.

+ JuanAn maybe can’t go?

- Eric will present on the work of the group: mzML 1.1, TraML x.x, MIAPE-MS

- Other reports?

- Perhaps try to meet at ASMS briefly



----

5) Working with ASMS on controlled vocabulary

- no update



Next meeting:

- In 3 weeks? May 18?

+ Yes. May 18 8am PDT













*From:* Eric Deutsch [mailto:ede...@sy...]
*Sent:* Monday, April 26, 2010 4:43 PM
*To:* Mass spectrometry standard development
*Cc:* Eric Deutsch
*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=27&month=4&year=2010&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 has been revised and the revision sent out for comment. To be
resubmitted in 2 days.

- Matt will release updated 1.1.1 of indexedmzML schema: <indexList> name
attribute will be enumerated to “spectrum” or “chromatogram”

- Matt will update the example files to reference mzML 1.1.0 but indexedmzML
1.1.1

- How do we handle lock mass corrections? Matt will make an example

- We should assemble list of calibrants and make them specific terms

- Bruker uses Lithium Formiate; others?

- Jim will find out what Thermo is using

- Matt will contact David Anderson and Mike Ashton and ask about a date in
lieu of checksum

- Need to test FAIMS support in mzML

- Other items?



----

2) MIAPE-MS revision

- Need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- We can use the sample MIAPE-compliant mzML file

- Pierre-Alain will contact Juan-Pablo to see if he has some suitable
examples in Proteo-Red

- Richard will look into PRIDE to see if there may be a good example there

- Waiting to sync with MIAPE-MSI as well

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out



----

3) TraML development

- New version 0.9.4 released and is available at
http://www.psidev.info/index.php?q=node/405

- Specification document is updated. Please examine. Is it ready for
submission?


http://www.peptideatlas.org/tmp/TraML/0.9.4/TraML_0.9.4.1_specificationDocument.doc

- Implementations? Please update to 0.9.4 and test

  - Matt will implement in ProteoWizard

  - Andreas will implement in OpenMS and update on-line validator

  - ISB implementation in ATAQS nearly done

 - Jim has an implementation but just will need to update to 0.9.4

  - David Cox at Sciex will test implement?

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304

- Manuscript is also in preparation



----

4) PSI session at World HUPO in Sydney

- PSI will have a session. Presenters will be Eric, Juan Antonio, Henning.

- Eric will present on the work of the group: mzML 1.1, TraML x.x, MIAPE-MS

- Other reports?

- Perhaps try to meet at ASMS briefly



----

5) Working with ASMS on controlled vocabulary

- no update



Next meeting:

- In 3 weeks? May 18?

[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=27&month=4&year=2010&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 has been revised and the revision sent out for comment. To be
resubmitted in 2 days.

- Matt will release updated 1.1.1 of indexedmzML schema: <indexList> name
attribute will be enumerated to “spectrum” or “chromatogram”

- Matt will update the example files to reference mzML 1.1.0 but indexedmzML
1.1.1

- How do we handle lock mass corrections? Matt will make an example

- We should assemble list of calibrants and make them specific terms

- Bruker uses Lithium Formiate; others?

- Jim will find out what Thermo is using

- Matt will contact David Anderson and Mike Ashton and ask about a date in
lieu of checksum

- Need to test FAIMS support in mzML

- Other items?



----

2) MIAPE-MS revision

- Need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- We can use the sample MIAPE-compliant mzML file

- Pierre-Alain will contact Juan-Pablo to see if he has some suitable
examples in Proteo-Red

- Richard will look into PRIDE to see if there may be a good example there

- Waiting to sync with MIAPE-MSI as well

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out



----

3) TraML development

- New version 0.9.4 released and is available at
http://www.psidev.info/index.php?q=node/405

- Specification document is updated. Please examine. Is it ready for
submission?


http://www.peptideatlas.org/tmp/TraML/0.9.4/TraML_0.9.4.1_specificationDocument.doc

- Implementations? Please update to 0.9.4 and test

  - Matt will implement in ProteoWizard

  - Andreas will implement in OpenMS and update on-line validator

  - ISB implementation in ATAQS nearly done

 - Jim has an implementation but just will need to update to 0.9.4

  - David Cox at Sciex will test implement?

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304

- Manuscript is also in preparation



----

4) PSI session at World HUPO in Sydney

- PSI will have a session. Presenters will be Eric, Juan Antonio, Henning.

- Eric will present on the work of the group: mzML 1.1, TraML x.x, MIAPE-MS

- Other reports?

- Perhaps try to meet at ASMS briefly



----

5) Working with ASMS on controlled vocabulary

- no update



Next meeting:

- In 3 weeks? May 18?

[Psidev-ms-dev] mzML 1.1.1_idx.xsd released

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

Hi all,

The updated index schema is finally live at 
http://psidev.info/files/ms/mzML/xsd/mzML1.1.1_idx.xsd and I have added 
a corresponding pwiz example file. I only did it for the tiny example 
since the update is trivial:
http://proteowizard.sourceforge.net/example_data/tiny.pwiz.1.1.1.mzML

-Matt

Re: [Psidev-ms-dev] Difference between purgatory / obsolete

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

This is indeed correct. Many terms in purgatory are perfectly reasonable
terms sometimes with good definitions, but are just unneeded by mzML. As
we move forward in tidying up our CV, all terms in purgatory should either
be moved to a correct location in the hierarchy and updated as appropriate
OR obsoleted. There are a number of terms in purgatory that should be
obsoleted, but some are good. What we lack is someone with the time to go
through and clean this all up. The ASMS folks might help us out with this.
Other volunteers are most welcome.

Regards,
Eric


> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: Thursday, April 08, 2010 7:45 AM
> To: psi...@li...
> Subject: Re: [Psidev-ms-dev] Difference between purgatory / obsolete
>
> We used purgatory as a development limbo. We may be at a sufficient
> stage of release where we can delete the purgatory terms entirely
> (which
> we will never do to properly obsoleted terms). I don't think purgatory
> and obsoletion should be considered overlapping concepts. I don't
> recall
> that there should be any mzML documents at or after 1.0 which use terms
> that are now in purgatory. I'd say a term that was NOT in purgatory in
> the 1.0 mapping file may be obsolete now, but it shouldn't be in
> purgatory.
>
> I think of supporting obsoletion like deprecation in a programming API.
> At some point in the future, support for those documents may be
> stopped.
> Perhaps we should have at least one converter which could upgrade the
> documents to replace the obsolete terms if the term has an official
> "replaced by" comment (or tag) and to delete the ones that were
> eliminated entirely. Or possibly handle those on a case by case basis
> (like when isolation window semantics changed from "lower bound/upper
> bound" to "target m/z/lower offset/upper offset").
>
> -Matt
>
>
> On 4/8/2010 3:32 AM, Steffen Neumann wrote:
> > Hi,
> >
> > I didn't come across a halfway formal definition / distinction
> between
> > OBSOLETE'ing stuff, and moving it to purgatory, although we had
> > a thread on this here last year ("Marking CV terms obsolete")
> >
> > Also I'd expect some process to make sure that stuff
> > shoved into purgatory really should be obsoleted at some stage.
> >
> > This has also implications on the validity of instance documents,
> > because files which have some cvParam which IS_A "something"
> > (where "something" is a MUST) are invalid once the cvParam
> > is moved from "something" to "purgatory", *unless it also retains*
> > the original IS_A "something".
> >
> > I found (grep -B 1 -A 1 "MS:1000479 ! purgatory" psi-ms.obo)
> > that there are Terms with a mix of:
> >
> > 	relationship: part_of MS:1000479 ! purgatory
> > 	is_obsolete: true
> >
> > 	relationship: part_of MS:1000479 ! purgatory
> > 	without is_obsolete
> >
> > 	is_a: MS:1000479 ! purgatory
> > 	without is_obsolete
> >
> > So:
> >
> > 1) Why do we use purgatory in first place ?
> >
> > 2) Do we want a policy whether and how the CV is cleansed
> >     and purgatory stuff marked OBSOLETE ?
> >
> > 3) How do we handle documents which become invalid
> >     with these changes ?
> >
> > 4) Should these definitions/processes
> >     become part of the spec documents ?
> >
> > Yours,
> > Steffen
> >
> >
>
> -----------------------------------------------------------------------
> -------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] CV update to 2.36.0

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

- removed duplicate xref for MS:1000041
- added term for FAIMS compensation voltage
- added term for XCMS software

-Matt

Re: [Psidev-ms-dev] Mappings for <Precursor>

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

Am Thursday, den 08.04.2010, 16:53 +0200 schrieb Fredrik Levander:
> MAY supply term MS:1000792 (isolation window attribute) (without 
> restrictions on number of occurencies)
Sounds good. I was afraid of cluttering the mappings.

> and the other terms can be added in when needed.
Yes, I don't think there is currently a need 
for "ion selection attribute"s.

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] Mappings for <Precursor>

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

Hi Steffen,

Wouldn't it do to add a
MAY supply term MS:1000792 (isolation window attribute) (without 
restrictions on number of occurencies)
in addition to the existing rules?
Then isolation target m/z is still required, and the other terms can be 
added in when needed.

Fredrik


Steffen Neumann skrev:
> Hi,
>
> we currently have for <Precursor> the cvParam Mapping Rules: 
>
> 	Path /TraML/TransitionList/Transition/Precursor
> 	MUST supply term MS:1000827 (isolation window target m/z) only once
> 	MAY supply term MS:1000041 (charge state) only once
> 	Path /TraML/TargetList/TargetIncludeList/Target/Precursor
> 	MUST supply term MS:1000827 (isolation window target m/z) only once
> 	MAY supply term MS:1000041 (charge state) only once
> 	Path /TraML/TargetList/TargetExcludeList/Target/Precursor
> 	MUST supply term MS:1000827 (isolation window target m/z) only once
> 	MAY supply term MS:1000041 (charge state) only once
>
> 1) We could just require one or more "isolation window attribute"s
>    http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS%3A1000792
>    which would also allow to put the lower/upper offset here.
>    Those offsets can be important if a too narrow window 
>    looses too much transmission, leading to poor ion intensities.
>
>    We'd lose the validation that someone might supply 
>    only those lower/upper offsets, and forget the actual "target m/z".
>
>    How'd we handle the "part_of MS:1000441 ! scan" in that case ?
>    Would that be a problem ?
>
>
> [Term]
> id: MS:1000792
> name: isolation window attribute
> def: "Isolation window parameter." [PSI:MS]
> is_a: MS:1000547 ! object attribute
> relationship: part_of MS:1000441 ! scan
>
> [Term]
> id: MS:1000455
> name: ion selection attribute
> def: "Ion selection properties that are associated with a value." [PSI:MS]
> is_a: MS:1000547 ! object attribute
> relationship: part_of MS:1000442 ! spectrum
>
>
>   

Re: [Psidev-ms-dev] Difference between purgatory / obsolete

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

We used purgatory as a development limbo. We may be at a sufficient 
stage of release where we can delete the purgatory terms entirely (which 
we will never do to properly obsoleted terms). I don't think purgatory 
and obsoletion should be considered overlapping concepts. I don't recall 
that there should be any mzML documents at or after 1.0 which use terms 
that are now in purgatory. I'd say a term that was NOT in purgatory in 
the 1.0 mapping file may be obsolete now, but it shouldn't be in purgatory.

I think of supporting obsoletion like deprecation in a programming API. 
At some point in the future, support for those documents may be stopped. 
Perhaps we should have at least one converter which could upgrade the 
documents to replace the obsolete terms if the term has an official 
"replaced by" comment (or tag) and to delete the ones that were 
eliminated entirely. Or possibly handle those on a case by case basis 
(like when isolation window semantics changed from "lower bound/upper 
bound" to "target m/z/lower offset/upper offset").

-Matt


On 4/8/2010 3:32 AM, Steffen Neumann wrote:
> Hi,
>
> I didn't come across a halfway formal definition / distinction between
> OBSOLETE'ing stuff, and moving it to purgatory, although we had
> a thread on this here last year ("Marking CV terms obsolete")
>
> Also I'd expect some process to make sure that stuff
> shoved into purgatory really should be obsoleted at some stage.
>
> This has also implications on the validity of instance documents,
> because files which have some cvParam which IS_A "something"
> (where "something" is a MUST) are invalid once the cvParam
> is moved from "something" to "purgatory", *unless it also retains*
> the original IS_A "something".
>
> I found (grep -B 1 -A 1 "MS:1000479 ! purgatory" psi-ms.obo)
> that there are Terms with a mix of:
>
> 	relationship: part_of MS:1000479 ! purgatory
> 	is_obsolete: true
>
> 	relationship: part_of MS:1000479 ! purgatory
> 	without is_obsolete
>
> 	is_a: MS:1000479 ! purgatory
> 	without is_obsolete
>
> So:
>
> 1) Why do we use purgatory in first place ?
>
> 2) Do we want a policy whether and how the CV is cleansed
>     and purgatory stuff marked OBSOLETE ?
>
> 3) How do we handle documents which become invalid
>     with these changes ?
>
> 4) Should these definitions/processes
>     become part of the spec documents ?
>
> Yours,
> Steffen
>
>    

Re: [Psidev-ms-dev] CV: charge state

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

Am Thursday, den 08.04.2010, 09:32 -0500 schrieb Matthew Chambers:
> It would be bad practice to have two terms with the same name or exact 
> synonym. 
Right. I'll not ask for "possible z", then.

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] CV: charge state

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

It would be bad practice to have two terms with the same name or exact 
synonym. I'll fix the duplicate xref.

-Matt


On 4/8/2010 4:27 AM, Steffen Neumann wrote:
> Hi,
>
> for the sake of consistency I'd suggest to add
>
> 	synonym: "z" EXACT []
>
> to MS:1000633. The Term MS:1000041 has a duplicate xref:
> which could be cleaned up.
>
> Yours,
> Steffen
>
> [Term]
> id: MS:1000633
> name: possible charge state
> def: "A possible charge state of the ion in a situation where the charge of an ion is known to be one of several possible values rather than a completely unknown value or determined to be a specific charge with reasonable certainty." [PSI:MS]
> xref: value-type:xsd\:int "The allowed value-type for this CV term."
> is_a: MS:1000455 ! ion selection attribute
>
> [Term]
> id: MS:1000041
> name: charge state
> def: "The charge state of the ion, single or multiple and positive or negatively charged." [PSI:MS]
> xref: value-type:xsd\:int "The allowed value-type for this CV term."
> is_a: MS:1000455 ! ion selection attribute
> synonym: "z" EXACT []
> xref: value-type:xsd\:int "The allowed value-type for this CV term."
>    

[Psidev-ms-dev] TraML: cosmetics

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

ConfigurationList	List of insutrument configurations used in the validation or optimization of the transitions
   -> fix instrument here
   -> Since <ConfigurationList> also appears in <Target>, I'd suggest 
      to remove "of the transitions" (is there a more general replacement ?)
      and also add "in the measurement, validation or optimization"

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-MSS WG call reminder

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

Hi,

Am Tuesday, den 06.04.2010, 08:40 -0700 schrieb Eric Deutsch:
> 3) TraML development
...
> - Additional example files
> + Steffen will generate an XCMS example and post

I created this example and it validates fine:
http://msbi.ipb-halle.de/~sneumann/xcmsTraML.xml

This is not yet final, I am waiting for the cvParam for xcms,
and all RT and m/z values are just dummies, 
so please don't copy this file somewhere where I can't update it :-)

I can supply a snippet of R code to produce the file on request, 
it's also not final yet, but will appear in xcms at a later stage.

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

[Psidev-ms-dev] CV: charge state

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

Hi,

for the sake of consistency I'd suggest to add 

	synonym: "z" EXACT []

to MS:1000633. The Term MS:1000041 has a duplicate xref: 
which could be cleaned up.

Yours,
Steffen

[Term]
id: MS:1000633
name: possible charge state
def: "A possible charge state of the ion in a situation where the charge of an ion is known to be one of several possible values rather than a completely unknown value or determined to be a specific charge with reasonable certainty." [PSI:MS]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1000455 ! ion selection attribute

[Term]
id: MS:1000041
name: charge state
def: "The charge state of the ion, single or multiple and positive or negatively charged." [PSI:MS]
xref: value-type:xsd\:int "The allowed value-type for this CV term."
is_a: MS:1000455 ! ion selection attribute
synonym: "z" EXACT []
xref: value-type:xsd\:int "The allowed value-type for this CV term."


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

[Psidev-ms-dev] Mappings for <Precursor>

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

Hi,

we currently have for <Precursor> the cvParam Mapping Rules: 

	Path /TraML/TransitionList/Transition/Precursor
	MUST supply term MS:1000827 (isolation window target m/z) only once
	MAY supply term MS:1000041 (charge state) only once
	Path /TraML/TargetList/TargetIncludeList/Target/Precursor
	MUST supply term MS:1000827 (isolation window target m/z) only once
	MAY supply term MS:1000041 (charge state) only once
	Path /TraML/TargetList/TargetExcludeList/Target/Precursor
	MUST supply term MS:1000827 (isolation window target m/z) only once
	MAY supply term MS:1000041 (charge state) only once

1) We could just require one or more "isolation window attribute"s
   http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS%3A1000792
   which would also allow to put the lower/upper offset here.
   Those offsets can be important if a too narrow window 
   looses too much transmission, leading to poor ion intensities.

   We'd lose the validation that someone might supply 
   only those lower/upper offsets, and forget the actual "target m/z".

   How'd we handle the "part_of MS:1000441 ! scan" in that case ?
   Would that be a problem ?

2) While I'm at it, we could allow "ion selection attribute"s
   instead of only "charge state", because that would also allow 
   the (somewhat obscure) term "possible charge state":
   http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS%3A1000455

I'd opt in favor of 1) and against 2).

Yours,
Steffen

[Term]
id: MS:1000792
name: isolation window attribute
def: "Isolation window parameter." [PSI:MS]
is_a: MS:1000547 ! object attribute
relationship: part_of MS:1000441 ! scan

[Term]
id: MS:1000455
name: ion selection attribute
def: "Ion selection properties that are associated with a value." [PSI:MS]
is_a: MS:1000547 ! object attribute
relationship: part_of MS:1000442 ! spectrum


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

[Psidev-ms-dev] Difference between purgatory / obsolete

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

Hi,

I didn't come across a halfway formal definition / distinction between 
OBSOLETE'ing stuff, and moving it to purgatory, although we had 
a thread on this here last year ("Marking CV terms obsolete")

Also I'd expect some process to make sure that stuff 
shoved into purgatory really should be obsoleted at some stage.

This has also implications on the validity of instance documents, 
because files which have some cvParam which IS_A "something" 
(where "something" is a MUST) are invalid once the cvParam 
is moved from "something" to "purgatory", *unless it also retains*
the original IS_A "something".

I found (grep -B 1 -A 1 "MS:1000479 ! purgatory" psi-ms.obo)
that there are Terms with a mix of:

	relationship: part_of MS:1000479 ! purgatory
	is_obsolete: true

	relationship: part_of MS:1000479 ! purgatory
	without is_obsolete

	is_a: MS:1000479 ! purgatory
	without is_obsolete

So: 

1) Why do we use purgatory in first place ?

2) Do we want a policy whether and how the CV is cleansed 
   and purgatory stuff marked OBSOLETE ?

3) How do we handle documents which become invalid 
   with these changes ?

4) Should these definitions/processes 
   become part of the spec documents ?

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

[Psidev-ms-dev] cvParam request for XCMS

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

Hi,

I'd like to ask for the following CV Term in PSI-MS:

[Term]
id: MS:1000xxx
name: XCMS
def: "Bioconductor package XCMS for preprocessing high-throughput, untargeted analyte profiling data" [PSI:MS]
is_a: MS:1001456 ! analysis software
is_a: MS:1001457 ! data processing software

Two more questions/comments:
1a) The def: "Analysis software." [PSI:MS]
    is somewhat unspecific. I'd expect this refers 
    to stuff for annotation and identification, i.e. the high-level stuff.

1b) The def: "Conversion software." [PSI:MS] 
    is quite narrow. I'd think that baseline correction, 
    peak picking etc. would also qualify as processing,
    not just format conversion

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-MSS WG call reminder

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

Present: Richard, Matt, Steffen, Eric



1) mzML 1.1.0

- Manuscript has been reviewed and generally positive. Reviewers concerns
can be addressed. In progress.

+ Lennart did a first pass at responding to the reviewers

+ Eric is trying to finish

- Matt will release updated 1.1.1 of indexedmzML schema: <indexList> name
attribute will be enumerated to “spectrum” or “chromatogram”

+ Richard will get password from JuanAn and make the update

- Matt will update the example files to reference mzML 1.1.0 but indexedmzML
1.1.1

+ Waiting for schema to be posted

- How do we handle lock mass corrections? Someone will make an example

- We should assemble list of calibrants and make them specific terms

- Bruker uses Lithium Formiate; others?

- Jim will find out what Thermo is using

+ No progress on lock mass corrections

- Matt will contact David Anderson and Mike Ashton and ask about a date in
lieu of checksum

+ They are looking into hashing objects. No resolution yet.

- Need to test FAIMS support in mzML

+ Eric will work with those generating some data at ISB

- Add term for “compensation voltage” to support FAIMS data

+ Matt will add the proposed term

- Other items?



----

2) MIAPE-MS revision

- Need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- We can use the sample MIAPE-compliant mzML file

- Pierre-Alain will contact Juan-Pablo to see if he has some suitable
examples in Proteo-Red

- Richard will look into PRIDE to see if there may be a good example there

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out

+ Ask Pierre-Alain about the mzML MIAPE-MS mapping file



----

3) TraML development

- New version 0.9.4 released and is available at
http://www.psidev.info/index.php?q=node/405

- Specification document is updated. Please examine. Is it ready for
submission?


http://www.peptideatlas.org/tmp/TraML/0.9.4/TraML_0.9.4.1_specificationDocument.doc

- Implementations? Please update to 0.9.4 and test

  - Matt will implement in ProteoWizard

  + Matt will try to finish this in the next 3 weeks

  - Andreas will implement in OpenMS and update on-line validator

  - ISB implementation in ATAQS nearly done

  - Jim has an implementation but just will need to update to 0.9.4

  - David Cox at Sciex will test implement?

+ Eric will ping Jim and David

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304

- Manuscript is also in preparation

- Additional example files

+ Steffen will generate an XCMS example and post





----

4) PSI workshop in Seoul

- Andy Jones presented the report.

- Other reports?

- Perhaps try to meet at ASMS briefly



----

5) Working with ASMS on controlled vocabulary

- Eric is coordinating with David Sparkman and others related to ASMS who
will contribute to our CV as the single standard CV

- Eric will update this email list with activities and non-trivial changes

+ No progress for the moment. They will meet at ASMS in June



Next meeting:

- In 3 weeks? Apr 27?

+ Yes, Tue Apr 27 8am PDT (in 3 weeks)

+ Possible CPTAC conflict







*From:* Eric Deutsch [mailto:ede...@sy...]
*Sent:* Monday, April 05, 2010 9:46 AM
*To:* Mass spectrometry standard development
*Cc:* Eric Deutsch
*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=6&month=4&year=2010&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 has been reviewed and generally positive. Reviewers concerns
can be addressed. In progress.

- Matt will release updated 1.1.1 of indexedmzML schema: <indexList> name
attribute will be enumerated to “spectrum” or “chromatogram”

- Matt will update the example files to reference mzML 1.1.0 but indexedmzML
1.1.1

- How do we handle lock mass corrections? Matt will make an example

- We should assemble list of calibrants and make them specific terms

- Bruker uses Lithium Fromiate; others?

- Jim will find out what Thermo is using

- Matt will contact David Anderson and Mike Ashton and ask about a date in
lieu of checksum

- Need to test FAIMS support in mzML

- Add term for “compensation voltage” to support FAIMS data

- Other items?



----

2) MIAPE-MS revision

- Need to have 3 examples to go along with a document submission

- Until we provide the examples, it is not officially in the document
process

- We can use the sample MIAPE-compliant mzML file

- Pierre-Alain will contact Juan-Pablo to see if he has some suitable
examples in Proteo-Red

- Richard will look into PRIDE to see if there may be a good example there

- When officially in the process, send out submitted document to journal
editors and everyone else to get the word out



----

3) TraML development

- New version 0.9.4 released and is available at
http://www.psidev.info/index.php?q=node/405

- Specification document is updated. Please examine. Is it ready for
submission?


http://www.peptideatlas.org/tmp/TraML/0.9.4/TraML_0.9.4.1_specificationDocument.doc

- Implementations? Please update to 0.9.4 and test

  - Matt will implement in ProteoWizard

  - Andreas will implement in OpenMS and update on-line validator

  - ISB implementation in ATAQS nearly done

 - Jim has an implementation but just will need to update to 0.9.4

  - David Cox at Sciex will test implement?

- Are we ready to update validator page?:
http://www.psidev.info/index.php?q=node/304

- Manuscript is also in preparation



----

4) PSI workshop in Seoul

- Andy Jones presented the report.

- Other reports?

- Perhaps try to meet at ASMS briefly



----

5) Working with ASMS on controlled vocabulary

- Eric is coordinating with David Sparkman and others related to ASMS who
will contribute to our CV as the single standard CV

- Eric will update this email list with activities and non-trivial changes



Next meeting:

- In 3 weeks? Apr 27?