psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] TraML 0.9.3 draft released

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

Hi everyone, TraML version 0.9.3 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.2:

- Elements CvList, Cv, CvParam now begin with lower case letter following
mzIdentML

- Precursor and Product m/z values now specified with MS:1000827

- Interpretation elements no longer have primary= attribute but have
required MS:1000926 attribute

- All elements now have a complexType definition

- I have attempted to use keys and keyRefs although they don't seem to be
working

 

Please update your implementations and example files and validators and
report.

 

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...
WWW: http://www.systemsbiology.org/Senior_Research_Scientists/Eric_Deutsch

 

[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=5&month=1&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 now in active preparation

- 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

- Andreas will add “Replaced-by” field to the obsoleted MaRiMba term

- Matt added new terms for ABI TOF/TOF T2D file format

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

- Other items?



----

2) MIAPE-MS revision

- Pierre-Alain has sent out the revised MIAPE-MS draft 2.94 document to the
list

- Everyone: Please examine MIAPE-MS 2.94 in Pierre-Alain Binz’s email on
2009-12-22 and respond with comments

- Deadline is Jan 12, after which the document will be submitted to the PSI
document process



----

3) TraML development

- Current version 0.9.2 is available at
http://www.psidev.info/index.php?q=node/405

- Version 0.9.3 about to be released

- Use Andreas’s suggestion to use 'isolation window target m/z', MS:1000827

- Eric will update the examples and mapping files for that.

- Eric will add term: “product interpretation rank”

- Matt suggest changing "frag: y ion" to "product: y ion"

- But Andreas points out that the “frag” is supposed to differentiate search
parameter from resulting

- Andreas will rephrase all the definitions for “frag: y ion” to be better

- Eric made a change to the 0.9.2 schema to make all elements be a
complexType definition

- Eric will release 0.9.3 as soon as these other additions are made

- Eric is having a problem with keys and keyrefs. They’re  not being
enforced

- Eric will send the problem to Matt who will look at it

- Fredrik sent out an inclusion list example. Everyone look and comment.

- Fredrik did use the 'isolation window target m/z' term. Update mapping
file

- Andreas also sent out an example

- Address Andreas’s suggestions in his email

- Matt asks if we should use lowercase CvParam like mzIdentML? Seems like
consensus to change CvParam -> cvParam, UserParam -> userParam

- Eric will send out new version 0.9.3

- Implementations?

  - Matt will implement in ProteoWizard

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

  - ISB implementation in ATAQS nearly done

  - Jim will implement as a test

  - David Cox at Sciex will test implement?

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

[Psidev-ms-dev] T2D format CV terms

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

Hi all,

I recall we planned to recommend T2D as the intermediate format for AB 
TOF TOF spectra, but ironically we have database-oriented terms for 
these spectra and no T2D-oriented terms:
MS:1001480
AB SCIEX TOF/TOF nativeID format
jobRun=xsd:nonNegativeInteger spotLabel=xsd:string 
spectrum=xsd:nonNegativeInteger.

MS:1001481
AB SCIEX TOF/TOF database
Applied Biosystems/MDS Analytical Technologies TOF/TOF instrument database.


Since there are plenty of T2D spectra floating in the wild (and we can 
actually get a SHA-1 checksum on them - we still haven't determined how 
to handle that for database spectra) I will add new terms to handle 
these today unless someone objects. I will use the same semantics as we 
use for Bruker FID since each T2D file is a single spectrum:
AB SCIEX TOF/TOF T2D nativeID format
file=xsd:IDREF.

AB SCIEX TOF/TOF T2D file
Applied Biosystems/MDS Analytical Technologies TOF/TOF instrument export 
format.

-Matt

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

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

Present: Pierre-Alain, Andreas, Matt, Mark, Jim



Agenda:

1) mzML 1.1.0

- Manuscript in preparation

- How do we handle lock mass corrections? Matt?

- Other items?

+ There is an ongoing discussion about restructuring the Unit Ontology.
Probably won’t affect us much

+ Saw in the wild a <indexList name=”chroms”> field. This should not be,
name can only be “spectrum” or “chromatogram”.

+ Matt will update mzML index schema to constraint this and release
indexedmzML 1.1.1

+ Also update the examples

+ Matt obsoleted duplicate MaRiMba term.

+ Andreas suggests adding a “Replaced-by” field. Andreas will add the field.



----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

- We need to work toward a new release of MIAPE-MS

- Pierre-Alain can present an updated document for comment?

+ Pierre-Alain has sent out to the whole list the revision (as well as
previous version)

+ Please all ready and send comments by Jan 12



----

3) TraML development

- Version 0.9.2 is available at http://www.psidev.info/index.php?q=node/405

- Implementations?

  - Matt will implement in ProteoWizard

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

  - ISB implementation in ATAQS nearly done

  - Jim will implement as a test

  - David Cox at Sciex will test implement?

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

- Maybe Andreas can help with inclusion/exclusion examples

- There are some mapping file validation errors that need to be fixed
(mapping file problems)

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

+ Use Andreas’s suggestion to use 'isolation window target m/z', MS:1000827

+ Eric will update the examples and mapping files for that.

+ Eric will add term: “product interpretation rank”

+ Matt suggest changing "frag: y ion" to "product: y ion"

+ But Andreas points out that the “frag” is supposed to differentiate search
parameter from resulting

+ Andreas will rephrase all the definitions for “frag: y ion” to be better

+ Eric made a change to the 0.9.2 schema to make all elements be a
complexType definition

+ Eric will release 0.9.3 as soon as these other additions are made

+ Eric is having a problem with keys and keyrefs. They’re  not being
enforced

+ Eric will send the problem to Matt who will look at it

+ Fredrik sent out an inclusion list example. Everyone look and comment.

+ Fredrik did use the 'isolation window target m/z' term. Update mapping
file

+ Andreas also sent out an example

+ Address Andreas’s suggestions in his email

+ Matt asks if we should use lowercase CvParam like mzIdentML? Seems like
consensus to change CvParam -> cvParam, UserParam -> userParam

+ Eric will send out new version 0.9.3



+ Meet again in two weeks Jan 5







*From:* Eric Deutsch [mailto:ede...@sy...]
*Sent:* Monday, December 21, 2009 4:28 PM
*To:* Mass spectrometry standard development
*Cc:* ede...@sy...; Mark Christiansen
*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=8&month=12&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 in preparation

- How do we handle lock mass corrections? Matt?

- Other items?



----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

- We need to work toward a new release of MIAPE-MS

- Pierre-Alain can present an updated document for comment?



----

3) TraML development

- Version 0.9.2 is available at http://www.psidev.info/index.php?q=node/405

- Implementations?

  - Matt will implement in ProteoWizard

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

  - ISB implementation in ATAQS nearly done

  - Jim will implement as a test

  - David Cox at Sciex will test implement?

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

- Maybe Andreas can help with inclusion/exclusion examples

- There are some mapping file validation errors that need to be fixed
(mapping file problems)

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

[Psidev-ms-dev] MIAPE MS to be revised

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

Hi all,
here is a revised version of MIAPE MS (2.95 so far)
This version had to be edited due to the following reasons:

- feedback for simplification and update for new instrumentation
- requirements from journal editors after meetings at HUPO-PSI and HUPO 
between PSI and journal editors
- coherence with mzML validation (quantitation aspects removed, to be 
placed in a nother separate document)

Here is a pdf version, and the preceeding one(2.24) as well for comparison.
Please note that the first page including the authors has to be updated. 
Those of you who feel they are missing or are willing to be removed 
please let me know.
Remember also that a reply to this email will go to the list. If you 
wish to send your comments to me, please make sure they are redirected 
correctly.

Please have a look at it. Feedback is required until January 12th. Then 
the document will go to a formal PSI review.

Best regards,

Pierre-Alain

[Psidev-ms-dev] TraML Include/Exclusion example

[Andreas B. <be...@in...>]

Hi all,

I've created a inclusion/exclusion example similar to Fredrik's one. Two proteins are used, BSA and p53. BSA peptides are excluded and p53 are in the inclusion target list. Don't ask for the biological sense ;).
http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/TraML/BSA_exclude_p53_include.traML

During the implementation a couple of questions came up.

Comments:
- The "ref" attribute of the element proteinRef should be 'required'
- Allow RetentionTime lists for inclusion/exclusion targets?
- cvParam at targetList must be present (enforced through the mapping file anyway), change from optional.
- Modification: 
  - Handle unkown modifications? (e.g. mapping for  MS:1001460 'unknown modification')
  - Handle modifications with unknown location (e.g. set location to '-1')
  - Location
    What does it mean if one Modification tag has more than one modification cvParam given? 
    (Either just allow single entries or document it, e.g. alternatives)
    What if the same location has several Modification entries? Alternatives?

Typos:
- InterpretationList: interprations -> interpretations 
- ConfigurationList: insutrument -> instrument

Cheers,
A.

--
Div. for Simulation of Biological Systems, WSI, University of Tuebingen
Room C322, Sand 14, 72076 Tuebingen, Germany
phone: +49-7071-29-70461 fax: +49-7071-29-5152
http://www-bs.informatik.uni-tuebingen.de

[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=8&month=12&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 in preparation

- How do we handle lock mass corrections? Matt?

- Other items?



----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

- We need to work toward a new release of MIAPE-MS

- Pierre-Alain can present an updated document for comment?



----

3) TraML development

- Version 0.9.2 is available at http://www.psidev.info/index.php?q=node/405

- Implementations?

  - Matt will implement in ProteoWizard

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

  - ISB implementation in ATAQS nearly done

  - Jim will implement as a test

  - David Cox at Sciex will test implement?

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

- Maybe Andreas can help with inclusion/exclusion examples

- There are some mapping file validation errors that need to be fixed
(mapping file problems)

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

[Psidev-ms-dev] traML inclusion list

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

Hi All,

Just uploaded an initial minimalistic traML inclusion list example at:
http://dev.thep.lu.se/fp6-prodac/browser/trunk/traml/Inclusion_Yeast.traML?format=raw

Some input on the following points would be welcome:
The file is generated based on searches in X!Tandem. There is no source 
file elements yet, would it be the X!Tandem results files, the peak list 
files, or both?
The used term for target m/z is 'isolation window target m/z', ok?
I did not include any evidence tags, even if the list is based on a 
certain FDR cutoff. Would MS:1001364, 'pep:global FDR', do?

Thanks

Fredrik

Re: [Psidev-ms-dev] TraML ion m/z and TraML::id attribute

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

I think it would be fine to reuse 'isolation window target m/z', 
MS:1000827, here. It is reflecting the target value for isolation, both 
for precursor and product.

Thanks

Fredrik

Eric Deutsch wrote:
>
> Ah, I see, so you'd like to see:
>
>  
>
> <Precursor>
>
>   <CvParam cvRef="MS" accession="MS:1000xxx" name="precursor m/z" 
> value="862.9467" unitCvRef="MS" unitAccession="MS:1000040" 
> unitName="m/z"/>
>
>   <CvParam cvRef="MS" accession="MS:1000041" name="charge state" 
> value="2"/>
>
> </Precursor>
>
> <Product>
>
>   <CvParam cvRef="MS" accession="MS:1000xxx" name="product m/z" 
> value="862.9467" unitCvRef="MS" unitAccession="MS:1000040" 
> unitName="m/z"/>
>
>   <CvParam cvRef="MS" accession="MS:1000041" name="charge state" 
> value="1"/>
>
> </Product>
>
>  
>
> Thanks,
>
> Eric
>
>  
>
>  
>
>  
>
> > -----Original Message-----
>
> > From: Matthew Chambers [mailto:mat...@va... 
> <mailto:mat...@va...>]
>
> > Sent: Thursday, December 17, 2009 2:28 PM
>
> > To: Mass spectrometry standard development
>
> > Subject: Re: [Psidev-ms-dev] TraML ion m/z and TraML::id attribute
>
> >
>
> > In our CV, the m/z term is a unit, not the name of the measurement. If
>
> > you recall, we had the same problem in mzML. We solved it by making
>
> > specific terms with m/z in the name, but not the whole name. So it
>
> > should be:
>
> >
>
> > <CvParam cvRef="MS" accession="xxx" name="<some kind of> m/z"
>
> > value="862.9467" unitCvRef="MS" unitAccession="MS:1000040"
>
> > unitName="m/z" />
>
> >
>
> >
>
> > -Matt
>
> >
>
> > Eric Deutsch wrote:
>
> > >> Also, the precursor and product elements use cvParams for m/z, but
>
> > just
>
> > >> like mzML's selectedIon elements, we can't use the m/z unit as the
>
> > main
>
> > >> term for this. We could either re-use selected ion m/z (awkward?) or
>
> > we
>
> > >> could add a new term.
>
> > >>
>
> > >
>
> > > Sorry, I'm not understanding this issue. Can you expand on this?
>
> > Currently
>
> > > we have:
>
> > >
>
> > > <Precursor>
>
> > >   <CvParam cvRef="MS" accession="MS:1000040" name="m/z"
>
> > value="862.9467"/>
>
> > >   <CvParam cvRef="MS" accession="MS:1000041" name="charge state"
>
> > > value="2"/>
>
> > > </Precursor>
>
> > >
>
> > > What's wrong with this and what are you proposing?
>
> > >
>
> > > Thanks,
>
> > > Eric
>
> > >
>
> > >
>
> >
>
> > -----------------------------------------------------------------------
>
> > -------
>
> > This SF.Net email is sponsored by the Verizon Developer Community
>
> > Take advantage of Verizon's best-in-class app development support
>
> > A streamlined, 14 day to market process makes app distribution fast and
>
> > easy
>
> > Join now and get one step closer to millions of Verizon customers
>
> > http://p.sf.net/sfu/verizon-dev2dev
>
> > _______________________________________________
>
> > Psidev-ms-dev mailing list
>
> > Psi...@li... 
> <mailto:Psi...@li...>
>
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

Re: [Psidev-ms-dev] TraML::Interpretation and Modification: - attributes as cvParams?

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

Eric Deutsch wrote:
 >
 > Okay, I'm fine with changing this to a CvParam. Instead of:
 >   <Interpretation primary="true">
 >     <CvParam cvRef="MS" accession="MS:1001220" name="frag: y ion"/>
 >     <CvParam cvRef="MS" accession="MS:1000903" name="product ion 
series ordinal" value="8"/>
 >     <CvParam cvRef="MS" accession="MS:1000904" name="product ion m/z 
delta" value="0.03"/>
 >   </Interpretation>
 >
 > We'll have:
 >   <Interpretation>
 >     <CvParam cvRef="MS" accession="MS:100xxxx" name="fragment 
interpretation rank" value="1"/>
 >     <CvParam cvRef="MS" accession="MS:1001220" name="frag: y ion"/>
 >     <CvParam cvRef="MS" accession="MS:1000903" name="product ion 
series ordinal" value="8"/>
 >     <CvParam cvRef="MS" accession="MS:1000904" name="product ion m/z 
delta" value="0.03"/>
 >   </Interpretation>
 >
 > Yes?
Looks great to me. On a related note, perhaps when we refactor the 
neutral loss terms related to "frag: y ion" we should rename those terms 
to be "product: y ion" because according to the IUPAC description of 
product ion, "fragment ion" is deprecated. Plus it would be more 
consistent with its sibling CvParams.


 > > For modification, I think that optional double-valued attributes are
 > > very annoying for an object model. How does a program test if the value
 > > is not set? It either needs a reference-centric implementation
 > > (Java/.NET but not C/C++) with null testing, or it needs an extra
 > > boolean attribute like "hasSomeValue".
 >
 > I’m not sure I understand the problem here.  Is the problem that the 
datatype is <double> and it’s optional? OR is it that it can be either 
monoisotopicMassDelta or averageMassDelta and really should
 > have one of the two, although maybe that information is not known. So 
either one or the other could be present. Or neither. But preferably not 
both. Although no major reason why not both...

Yes, the problem is that it's double and optional. Optional strings are 
fine, mandatory numerics are fine, but optional numerics are rather 
annoying in the object model. It's not a big issue. As for masses, I 
think both should be there unless one of them isn't known. MzIdentML 
requires both of them, so we could follow suit.


 > You want:
 >   <Modification location="1">
 >     <CvParam cvRef="MS" accession="MS:1000xxx" name="monoisotopic 
mass delta" value="15.994919"/>
 >     <CvParam cvRef="UNIMOD" accession="UNIMOD:35" name="Oxidation"/>
 >   </Modification>
Indeed, I think having the masses as CvParams is better. The semantic 
validator could also require the mass terms when a unimod term is 
present (presumably there are no unimod terms without a known formula 
and thus calculable masses?)


 > > Modification's optional location attribute could probably be mandatory.
 > > Or is it supposed to be omitted for terminal mods?
 > As far as I can see from the xsd and docs <Modification>’s location 
attribute is a required attribute. Am I misunderstanding?
Nevermind. I must have misread the XSD.

Thanks,
Matt

Re: [Psidev-ms-dev] TraML ion m/z and TraML::id attribute

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

Ah, I see, so you'd like to see:



<Precursor>

  <CvParam cvRef="MS" accession="MS:1000xxx" name="precursor m/z"
value="862.9467" unitCvRef="MS" unitAccession="MS:1000040" unitName="m/z"/>

  <CvParam cvRef="MS" accession="MS:1000041" name="charge state" value="2"/>

</Precursor>

<Product>

  <CvParam cvRef="MS" accession="MS:1000xxx" name="product m/z"
value="862.9467" unitCvRef="MS" unitAccession="MS:1000040" unitName="m/z"/>

  <CvParam cvRef="MS" accession="MS:1000041" name="charge state" value="1"/>

</Product>



Thanks,

Eric







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

> From: Matthew Chambers [mailto:mat...@va...]

> Sent: Thursday, December 17, 2009 2:28 PM

> To: Mass spectrometry standard development

> Subject: Re: [Psidev-ms-dev] TraML ion m/z and TraML::id attribute

>

> In our CV, the m/z term is a unit, not the name of the measurement. If

> you recall, we had the same problem in mzML. We solved it by making

> specific terms with m/z in the name, but not the whole name. So it

> should be:

>

> <CvParam cvRef="MS" accession="xxx" name="<some kind of> m/z"

> value="862.9467" unitCvRef="MS" unitAccession="MS:1000040"

> unitName="m/z" />

>

>

> -Matt

>

> Eric Deutsch wrote:

> >> Also, the precursor and product elements use cvParams for m/z, but

> just

> >> like mzML's selectedIon elements, we can't use the m/z unit as the

> main

> >> term for this. We could either re-use selected ion m/z (awkward?) or

> we

> >> could add a new term.

> >>

> >

> > Sorry, I'm not understanding this issue. Can you expand on this?

> Currently

> > we have:

> >

> > <Precursor>

> >   <CvParam cvRef="MS" accession="MS:1000040" name="m/z"

> value="862.9467"/>

> >   <CvParam cvRef="MS" accession="MS:1000041" name="charge state"

> > value="2"/>

> > </Precursor>

> >

> > What's wrong with this and what are you proposing?

> >

> > Thanks,

> > Eric

> >

> >

>

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

> -------

> This SF.Net email is sponsored by the Verizon Developer Community

> Take advantage of Verizon's best-in-class app development support

> A streamlined, 14 day to market process makes app distribution fast and

> easy

> Join now and get one step closer to millions of Verizon customers

> http://p.sf.net/sfu/verizon-dev2dev

> _______________________________________________

> Psidev-ms-dev mailing list

> Psi...@li...

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

Re: [Psidev-ms-dev] TraML ion m/z and TraML::id attribute

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

In our CV, the m/z term is a unit, not the name of the measurement. If 
you recall, we had the same problem in mzML. We solved it by making 
specific terms with m/z in the name, but not the whole name. So it 
should be:

<CvParam cvRef="MS" accession="xxx" name="<some kind of> m/z" value="862.9467" unitCvRef="MS" unitAccession="MS:1000040" unitName="m/z" />


-Matt

Eric Deutsch wrote:
>> Also, the precursor and product elements use cvParams for m/z, but just
>> like mzML's selectedIon elements, we can't use the m/z unit as the main
>> term for this. We could either re-use selected ion m/z (awkward?) or we
>> could add a new term.
>>     
>
> Sorry, I'm not understanding this issue. Can you expand on this? Currently
> we have:
>
> <Precursor>
>   <CvParam cvRef="MS" accession="MS:1000040" name="m/z" value="862.9467"/>
>   <CvParam cvRef="MS" accession="MS:1000041" name="charge state"
> value="2"/>
> </Precursor>
>
> What's wrong with this and what are you proposing?
>
> Thanks,
> Eric
>   
>

Re: [Psidev-ms-dev] TraML::Interpretation and Modification: - attributes as cvParams?

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

Hi Matt, comments/questions below...



> From: Matthew Chambers [mailto:mat...@va...]

>

> I suggest the Interpretation::primary and Modification::*MassDelta

> attributes be changed to cvParams.

>

> The primary attribute could still be

> a boolean, but I also suggest that it change to a rank. If it was a

> rank, multiple interpretations could be rank 1, which seems to me to be

> a reasonable use case (it's a reason NOT to use a transition).



Okay, I'm fine with changing this to a CvParam. Instead of:

  <Interpretation primary="true">

    <CvParam cvRef="MS" accession="MS:1001220" name="frag: y ion"/>

    <CvParam cvRef="MS" accession="MS:1000903" name="product ion series
ordinal" value="8"/>

    <CvParam cvRef="MS" accession="MS:1000904" name="product ion m/z delta"
value="0.03"/>

  </Interpretation>

We'll have:

  <Interpretation>

    <CvParam cvRef="MS" accession="MS:100xxxx" name="fragment interpretation
rank" value="1"/>

    <CvParam cvRef="MS" accession="MS:1001220" name="frag: y ion"/>

    <CvParam cvRef="MS" accession="MS:1000903" name="product ion series
ordinal" value="8"/>

    <CvParam cvRef="MS" accession="MS:1000904" name="product ion m/z delta"
value="0.03"/>

  </Interpretation>

Yes?





> For modification, I think that optional double-valued attributes are

> very annoying for an object model. How does a program test if the value

> is not set? It either needs a reference-centric implementation

> (Java/.NET but not C/C++) with null testing, or it needs an extra

> boolean attribute like "hasSomeValue".



I’m not sure I understand the problem here.  Is the problem that the
datatype is <double> and it’s optional? OR is it that it can be either
monoisotopicMassDelta or averageMassDelta and really should have one of the
two, although maybe that information is not known. So either one or the
other could be present. Or neither. But preferably not both. Although no
major reason why not both...



So taking a stab..



Instead of:

  <Modification location="1" monoisotopicMassDelta="15.994919">

    <CvParam cvRef="UNIMOD" accession="UNIMOD:35" name="Oxidation"/>

  </Modification>

You want:

  <Modification location="1">

    <CvParam cvRef="MS" accession="MS:1000xxx" name="monoisotopic mass
delta" value="15.994919"/>

    <CvParam cvRef="UNIMOD" accession="UNIMOD:35" name="Oxidation"/>

  </Modification>



??



> Modification's optional location attribute could probably be mandatory.

> Or is it supposed to be omitted for terminal mods?



As far as I can see from the xsd and docs <Modification>’s location
attribute is a required attribute. Am I misunderstanding?





> -Matt

>

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

> -------

> Return on Information:

> Google Enterprise Search pays you back

> Get the facts.

> http://p.sf.net/sfu/google-dev2dev

> _______________________________________________

> Psidev-ms-dev mailing list

> Psi...@li...

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

Re: [Psidev-ms-dev] TraML ion m/z and TraML::id attribute

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

Thanks for working on this, Matt! Comments below. The changes will appear
in 0.9.3 to appear shortly.

> Hi,
>
> I'm updating pwiz's TraML model to 0.9.2 and I've got some comments.
>
> I think we need a document-level id attribute which potentially will be
> LSID just like mzML, but at least can be used to identify a document in
> some fashion.

Okay, added.

> Also, the precursor and product elements use cvParams for m/z, but just
> like mzML's selectedIon elements, we can't use the m/z unit as the main
> term for this. We could either re-use selected ion m/z (awkward?) or we
> could add a new term.

Sorry, I'm not understanding this issue. Can you expand on this? Currently
we have:

<Precursor>
  <CvParam cvRef="MS" accession="MS:1000040" name="m/z" value="862.9467"/>
  <CvParam cvRef="MS" accession="MS:1000041" name="charge state"
value="2"/>
</Precursor>

What's wrong with this and what are you proposing?

Thanks,
Eric


> -Matt
>
> -----------------------------------------------------------------------
> -------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML_idx's IndexType::name attribute

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

On Mon, Dec 14, 2009 at 1:17 PM, Matthew Chambers <
mat...@va...> wrote:

> What makes you say that? Can the validator even validate that attributes
> have certain string values? And as we agreed in Turku, mapping file
> changes constitute a version bump for mzML. We just never decided how to
> handle the index wrapper schema.
>
>
Apologies I was not at Turku and admittedly did not read the summary notes
too carefully. I say it should be validator issue (in preference to a XML
schema change) to avoid a schema's version number change. In light of this
information,  it clearly will, so a schema level change is preferable.

-a



> -Matt
>
>
> Angel Pizarro wrote:
> > sounds like an issue for the validator. -a
> >
> >
> > On Fri, Dec 11, 2009 at 5:16 PM, Matthew Chambers
> > <mat...@va...
> > <mailto:mat...@va...>> wrote:
> >
> >     Hello mzML fans,
> >
> >     Apparently, Mass++ is writing indexed mzML files (yay!), but it
> >     uses an
> >     unexpected "chroms" name to identify the chromatogram index
> >     (boo!). The
> >     mzML_idx XSD does not specify what are the possible values for that
> >     attribute. Obviously, it's impossible to write a reader that uses
> >     indexes if the indexes have been written with arbitrary names. It's
> of
> >     course possible to ignore the index in these cases, but we should nip
> >     this issue in the bud. We can release 1.1.1 to add the restriction.
> >     MzML.xsd wouldn't even change, just mzML_idx.xsd. Which leads to the
> >     question of whether we should bump mzML's version or not if only
> >     the idx
> >     wrapper changes...
> >
> >     -Matt
> >
> >
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility

Re: [Psidev-ms-dev] mzML_idx's IndexType::name attribute

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

What makes you say that? Can the validator even validate that attributes 
have certain string values? And as we agreed in Turku, mapping file 
changes constitute a version bump for mzML. We just never decided how to 
handle the index wrapper schema.

-Matt


Angel Pizarro wrote:
> sounds like an issue for the validator. -a
>
>
> On Fri, Dec 11, 2009 at 5:16 PM, Matthew Chambers 
> <mat...@va... 
> <mailto:mat...@va...>> wrote:
>
>     Hello mzML fans,
>
>     Apparently, Mass++ is writing indexed mzML files (yay!), but it
>     uses an
>     unexpected "chroms" name to identify the chromatogram index
>     (boo!). The
>     mzML_idx XSD does not specify what are the possible values for that
>     attribute. Obviously, it's impossible to write a reader that uses
>     indexes if the indexes have been written with arbitrary names. It's of
>     course possible to ignore the index in these cases, but we should nip
>     this issue in the bud. We can release 1.1.1 to add the restriction.
>     MzML.xsd wouldn't even change, just mzML_idx.xsd. Which leads to the
>     question of whether we should bump mzML's version or not if only
>     the idx
>     wrapper changes...
>
>     -Matt
>
>

Re: [Psidev-ms-dev] mzML_idx's IndexType::name attribute

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

sounds like an issue for the validator. -a


On Fri, Dec 11, 2009 at 5:16 PM, Matthew Chambers <
mat...@va...> wrote:

> Hello mzML fans,
>
> Apparently, Mass++ is writing indexed mzML files (yay!), but it uses an
> unexpected "chroms" name to identify the chromatogram index (boo!). The
> mzML_idx XSD does not specify what are the possible values for that
> attribute. Obviously, it's impossible to write a reader that uses
> indexes if the indexes have been written with arbitrary names. It's of
> course possible to ignore the index in these cases, but we should nip
> this issue in the bud. We can release 1.1.1 to add the restriction.
> MzML.xsd wouldn't even change, just mzML_idx.xsd. Which leads to the
> question of whether we should bump mzML's version or not if only the idx
> wrapper changes...
>
> -Matt
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility

[Psidev-ms-dev] mzML_idx's IndexType::name attribute

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

Hello mzML fans,

Apparently, Mass++ is writing indexed mzML files (yay!), but it uses an 
unexpected "chroms" name to identify the chromatogram index (boo!). The 
mzML_idx XSD does not specify what are the possible values for that 
attribute. Obviously, it's impossible to write a reader that uses 
indexes if the indexes have been written with arbitrary names. It's of 
course possible to ignore the index in these cases, but we should nip 
this issue in the bud. We can release 1.1.1 to add the restriction. 
MzML.xsd wouldn't even change, just mzML_idx.xsd. Which leads to the 
question of whether we should bump mzML's version or not if only the idx 
wrapper changes...

-Matt

[Psidev-ms-dev] TraML::Interpretation and Modification: - attributes as cvParams?

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

I suggest the Interpretation::primary and Modification::*MassDelta 
attributes be changed to cvParams. The primary attribute could still be 
a boolean, but I also suggest that it change to a rank. If it was a 
rank, multiple interpretations could be rank 1, which seems to me to be 
a reasonable use case (it's a reason NOT to use a transition).

For modification, I think that optional double-valued attributes are 
very annoying for an object model. How does a program test if the value 
is not set? It either needs a reference-centric implementation 
(Java/.NET but not C/C++) with null testing, or it needs an extra 
boolean attribute like "hasSomeValue".

Modification's optional location attribute could probably be mandatory. 
Or is it supposed to be omitted for terminal mods?

-Matt

[Psidev-ms-dev] TraML ion m/z and TraML::id attribute

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

Hi,

I'm updating pwiz's TraML model to 0.9.2 and I've got some comments.

I think we need a document-level id attribute which potentially will be 
LSID just like mzML, but at least can be used to identify a document in 
some fashion.

Also, the precursor and product elements use cvParams for m/z, but just 
like mzML's selectedIon elements, we can't use the m/z unit as the main 
term for this. We could either re-use selected ion m/z (awkward?) or we 
could add a new term.

-Matt

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

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

+ Present: Fredrik, Jim, Eric, Pierre-Alain



1) mzML 1.1.0

- Manuscript in preparation

- How do we handle lock mass corrections? Matt?

+ Jim will also try to find some lock-mass correction data

- Other items?



----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

- We need to work toward a new release of MIAPE-MS

- Pierre-Alain can present an updated document for comment?

+ This was sent out for comment and briefly discussed. Fredrik

+ Fredrik asks about the MS1 for each MS2 requirement

+ Recipients have 1 week to make comments and then edited document will be
send to whole list for further comment



----

3) TraML development

- Version 0.9.2 is available at http://www.psidev.info/index.php?q=node/405

- Implementations?

  - Matt will implement in ProteoWizard

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

+ Andreas is almost done with OpenMS implementation

+ OpenMS on-line validator is updated

  - ISB implementation in ATAQS nearly done

+ Done. Eric will send out a few examples

  - Jim will implement as a test

+ Jim will send out a metabolomics example

  - David Cox at Sciex will test implement?

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

+ PSI-PI folks seemed amenable to the proposed change although they probably
can’t easily change mzIdentML now. However, new mechanism can probably be
parallel in the CV with the old mechanism and TraML can implement the new
mechanism and mzIdentML could update in the future.

- Maybe Andreas can help with inclusion/exclusion examples

+ Fredrik will also provide some inclusion list examples from Proteios

- There are some mapping file validation errors that need to be fixed
(mapping file problems)

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



+ Next call Tue Dec 22 at the same time.







*From:* Eric Deutsch [mailto:ede...@sy...]
*Sent:* Monday, December 07, 2009 11:27 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=8&month=12&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 in preparation

- How do we handle lock mass corrections? Matt?

- Other items?



----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

- We need to work toward a new release of MIAPE-MS

- Pierre-Alain can present an updated document for comment?



----

3) TraML development

- Version 0.9.2 is available at http://www.psidev.info/index.php?q=node/405

- Implementations?

  - Matt will implement in ProteoWizard

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

  - ISB implementation in ATAQS nearly done

  - Jim will implement as a test

  - David Cox at Sciex will test implement?

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

- Maybe Andreas can help with inclusion/exclusion examples

- There are some mapping file validation errors that need to be fixed
(mapping file problems)

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

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

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

I won't make the call today. I haven't finished the pwiz updates, but I 
hope to do that this week.

-Matt


Eric Deutsch wrote:
>
> Hi everyone, the next PSI Mass Spectrometry Standards Working Group 
> call will be Tuesday 8am PDT:
>
>  
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=8&month=12&year=2009&hour=16&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=8&month=12&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 in preparation
>
> - How do we handle lock mass corrections? Matt?
>
> - Other items?
>
>  
>
> ----
>
> 2) MIAPE-MS revision
>
> - Discussion with journal editors was Monday. Results are in.
>
> - We need to work toward a new release of MIAPE-MS
>
> - Pierre-Alain can present an updated document for comment?
>
>  
>
> ----
>
> 3) TraML development
>
> - Version 0.9.2 is available at 
> http://www.psidev.info/index.php?q=node/405
>
> - Implementations?
>
>   - Matt will implement in ProteoWizard
>
>   - Andreas will implement in OpenMS and update on-line validator
>
>   - ISB implementation in ATAQS nearly done
>
>   - Jim will implement as a test
>
>   - David Cox at Sciex will test implement?
>
> - What do we do with the <interpretation> cvParams insufficiency problem?
>
> - Maybe Andreas can help with inclusion/exclusion examples
>
> - There are some mapping file validation errors that need to be fixed 
> (mapping file problems)
>
> - Are we ready to update validator page?: 
> http://www.psidev.info/index.php?q=node/304
>

[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=8
<http://www.timeanddate.com/worldclock/fixedtime.html?day=8&month=12&year=20
09&hour=16&min=0&sec=0&p1=136>
&month=12&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 in preparation

- How do we handle lock mass corrections? Matt?

- Other items?

 

----

2) MIAPE-MS revision

- Discussion with journal editors was Monday. Results are in.

- We need to work toward a new release of MIAPE-MS

- Pierre-Alain can present an updated document for comment?

 

----

3) TraML development

- Version 0.9.2 is available at
<http://www.psidev.info/index.php?q=node/405>
http://www.psidev.info/index.php?q=node/405

- Implementations?

  - Matt will implement in ProteoWizard

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

  - ISB implementation in ATAQS nearly done

  - Jim will implement as a test

  - David Cox at Sciex will test implement?

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

- Maybe Andreas can help with inclusion/exclusion examples

- There are some mapping file validation errors that need to be fixed
(mapping file problems)

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

 

 

Re: [Psidev-ms-dev] [Psidev-pi-dev] splitting series and loss concepts in CV

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

Hi Matt,

The cardinality of cvParam is set to exactly 1 in the XSD. Since, this was IonType, it seemed to make sense that something can only have exactly one "type". I see there is value in the proposed change but it would require a chance to the mzid XSD. Overall I'm not that keen to change the XSD unless we have a killer bug or a major feature upgrade, since we are all currently working on implementations and I'd like to see the results over those efforts before asking for people to change their code.
Cheers
Andy




> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: 24 November 2009 15:30
> To: psi...@li...; Mass spectrometry standard
> development
> Subject: Re: [Psidev-ms-dev] [Psidev-pi-dev] splitting series and loss concepts in
> CV
> 
> Would it break the schema or the mapping file? Not much of a semantic
> difference there since we've agreed that the schema and mapping file are
> joined for versioning purposes, but I'm just curious if you've
> restricted cvParam cardinality from the xsd.
> 
> -Matt
> 
> 
> Jones, Andy wrote:
> >
> > Hi all,
> >
> >
> >
> > I agree this seems like a sensible suggestion, unfortunately this
> > would require a change in the mzid schema if we adopt it...
> >
> >
> >
> > IonType is currently only allowed to have one cvParam:
> >
> >
> >
> >               <IonType index="6 2" charge="1">
> >                 <cvParam cvRef="PSI-MS" accession="MS:1001233"
> > name="frag: y ion - NH3"/>
> >                 <FragmentArray values="825.2 242.8 " Measure_ref="m_mz"/>
> >                 <FragmentArray values="76 417" Measure_ref="m_intensity"/>
> >                 <FragmentArray values="-0.2829 -0.3703"
> > Measure_ref="m_error"/>
> >               </IonType>
> >
> >
> >
> > As I understand it, the suggestion is to have the following:
> >
> >
> >
> >               <IonType index="6 2" charge="1">
> >                 <cvParam cvRef="PSI-MS" accession=" " name="frag: y ion"/>
> >
> > <cvParam cvRef="PSI-MS" accession=" " name="loss of NH3”/>
> >                 <FragmentArray values="825.2 242.8 " Measure_ref="m_mz"/>
> >                 <FragmentArray values="76 417" Measure_ref="m_intensity"/>
> >                 <FragmentArray values="-0.2829 -0.3703"
> > Measure_ref="m_error"/>
> >               </IonType>
> >
> >
> >
> > This would be a very minor update to the schema since it would not
> > break existing files, but we haven’t yet agreed a strategy for updates
> > – there are obviously pros / cons to making these kind of minor
> > changes. Martin also identified a couple of missing primary/foreign
> > key constraints that we could update at the same time. Any opinions?
> >
> > Cheers
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *From:* David Creasy [mailto:dc...@ma...]
> > *Sent:* 18 November 2009 12:29
> > *To:* Eric Deutsch
> > *Cc:* psi...@li...; 'Mass spectrometry standard
> > development'
> > *Subject:* Re: [Psidev-pi-dev] splitting series and loss concepts in CV
> >
> >
> >
> > Hi Eric,
> >
> > We had assumed that the losses/gains that accompany a modification are
> > currently defined as as part of the modification definition. In
> > theory, this cuts down the combinations a little. (However, even this
> > doesn't help define which loss/gain is actually being recorded).
> >
> > A split as you suggest sounds like a very good idea to me. We
> > obviously can't get rid of the existing CV terms, but we can mark them
> > as obsolete (or deprecated?). I don't think that any change is
> > required to the mzIdentML schema or to the validator, but we would
> > need to update examples and documentation at the next mzIdentML rev.
> >
> > So, we could keep the existing 'backbone' series, and just add new
> > losses terms?
> >
> > btw, have you relocated down south or maybe you are suggesting we need
> > terms:
> >
> > [Term]
> > id: MS:123456
> > name: frag: y'
> >
> > [Term]
> > id: MS:987654
> > name: all
> > def: All imaginable losses. Only to be used with MS:123456...  ;)
> >
> > David
> >
> > Eric Deutsch wrote:
> >
> > Hi mzIdentMLers, I have a question for y’all:
> >
> >
> >
> > We have tried to reuse some mzIdentML bits in TraML and have hit a
> > potential snag. This is in a section where we provide information
> > about the interpretation of a peak. We have something like this:
> >
> >
> >
> > <interpretation>
> >
> >   <cvParam cvRef="MS" accession="MS:1001222" name="frag: b ion - H2O"/>
> >
> >   <cvParam cvRef="MS" accession="MS:1000903" name="product ion series
> > ordinal" value="9"/>
> >
> >   <cvParam cvRef="MS" accession="MS:1000904" name="product ion m/z
> > delta" value="-0.43"/>
> >
> > </interpretation>
> >
> >
> >
> > This is meant to indicate the peak that is being referenced may be
> > interpreted (among more than one possible interpretation sometimes) as
> > being 0.43 Da away from the predicted m/z of the b9 ion with a single
> > water loss. This often comes from a spectrum library which tends to
> > identify peaks in this way.
> >
> >
> >
> > From the CV, I find something like this:
> >
> >
> >
> > Now it seems like there are at least a dozen losses that are not super
> > uncommon, including multiple losses. Going down the road we’re going,
> > there will be a combinatorial explosion of terms if we aim to be
> > complete. For example, some things that the SpectraST code can deal
> > with when identifying peaks in addition to single water and ammonia loss:
> >
> >
> >
> > +18 is water gain. -34 is -NH3/-NH3, -35 is -NH3/-H2O and -36 is
> > -H2O/-H2O. -44 is -CO2, -45 is -HCONH2 and -46 is -HCOOH. There is
> > also -64, -82 for -HOSCH3 and -HOSCH3/-H2O -- these are common when
> > there is an oxidized methionine. Then there is -91 for CAM-cysteine
> > and -80, -98 and -116 for phosphates
> >
> >
> >
> > So where I’m going with this is: can we split these two concept
> > categories and split the series (b,y,z, etc.) from the losses that
> > could be incurred? Obviously this will impact mzIdentML.
> >
> >
> >
> > Thanks,
> >
> > Eric
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > 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-pi-dev mailing list
> > Psi...@li... <mailto:Psidev-pi-
> de...@li...>
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-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... <mailto:dc...@ma...>
> > http://www.matrixscience.com
> >
> > Matrix Science Ltd. is registered in England and Wales
> > Company number 3533898
> > ------------------------------------------------------------------------
> >
> > ------------------------------------------------------------------------------
> > 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-pi-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-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] PSI-MSS WG call deferred 1 week

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

Fine for me
Pierre-Alain

Eric Deutsch wrote:
>
> Hi everyone, due to a schedule change, I cannot host this week’s 
> conference call. Let’s defer until next week.  Pierre-Alain, can we 
> discuss the MIAPE-MS revision next week? We are making progress here 
> on our TraML implementation. Any other bits on progress on that front 
> to report?
>
>  
>
> Thanks,
>
> Eric
>
>  
>
>  
>
>  
>
> *From:* Eric Deutsch [mailto:ede...@sy... 
> <mailto:ede...@sy...>]
> *Sent:* Tuesday, November 17, 2009 8:40 AM
> *To:* Mass spectrometry standard development
> *Cc:* Eric Deutsch
> *Subject:* PSI-MSS WG call notes
>
>  
>
> Present: Matt, Eric, Pierre-Alain
>
>  
>
> 1) mzML 1.1.0
>
> - Manuscript in preparation
>
> - Were Shimadzu items handled?
>
> + Matt will add Shimadzu Biotech software & MALDI solutions
>
> - Other items?
>
> + What about lock mass data?
>
> + Add a “lock-mass corrected spectrum” term that can be added to each 
> scan if appropriate? Matt will send proposal
>
>  
>
> + Summary of msconvert support for conversion to mzML. Latest summary:
>
>    http://proteowizard.sourceforge.net/technical/formats/
>
> + 5 major vendors fully supported. Missing: ABI TOF-TOF, Shimadzu, Hitachi
>
>  
>
> ----
>
> 2) MIAPE-MS revision
>
> - Discussion with journal editors happened in Toronto.
>
> - We need to work toward a new release of MIAPE-MS
>
> + Pierre-Alain will make revisions and present document to WG for 
> discussion by Dec 1
>
>  
>
> ----
>
> 3) TraML development
>
> - Version 0.9.1 is available at 
> http://www.psidev.info/index.php?q=node/405
>
> - Should we switch to first-letter capital for all elements as seems 
> to be the custom everywhere else in PSI except mzML?
>
> - Aim to submit specification to document process by end of November
>
> - Implementations?
>
>   - Matt will implement in ProteoWizard by end of November?
>
>   - Andreas will implement in OpenMS and update on-line validator
>
>   - ISB implementation in ATAQS nearly done
>
>   - Jim will implement as a test
>
>   - David Cox at Sciex will test implement?
>
> - What do we do with the <interpretation> cvParams insufficiency problem?
>
> - Maybe Andreas can help with inclusion/exclusion examples
>
> - There are some mapping file validation errors that need to be fixed 
> (mapping file problems)
>
> + Eric will fix these issues
>
> - Are we ready to update validator page?: 
> http://www.psidev.info/index.php?q=node/304
>
>  
>
>  
>
> *From:* Eric Deutsch [mailto:ede...@sy... 
> <mailto:ede...@sy...>]
> *Sent:* Monday, November 16, 2009 11:45 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=17&month=11&year=2009&hour=16&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=17&month=11&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 in preparation
>
> - Were Shimadzu items handled?
>
> - Other items?
>
>  
>
> ----
>
> 2) MIAPE-MS revision
>
> - Discussion with journal editors was Monday. Results are in.
>
> - We need to work toward a new release of MIAPE-MS
>
>  
>
> ----
>
> 3) TraML development
>
> - Version 0.9.1 is available at 
> http://www.psidev.info/index.php?q=node/405
>
> - Should we switch to first-letter capital for all elements as seems 
> to be the custom everywhere else in PSI except mzML?
>
> - Aim to submit specification to document process by end of November
>
> - Implementations?
>
>   - Matt will implement in ProteoWizard
>
>   - Andreas will implement in OpenMS and update on-line validator
>
>   - ISB implementation in ATAQS nearly done
>
>   - Jim will implement as a test
>
>   - David Cox at Sciex will test implement?
>
> - What do we do with the <interpretation> cvParams insufficiency problem?
>
> - Maybe Andreas can help with inclusion/exclusion examples
>
> - There are some mapping file validation errors that need to be fixed 
> (mapping file problems)
>
> - Are we ready to update validator page?: 
> http://www.psidev.info/index.php?q=node/304
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>