psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] PSI-MSS WG call deferred 1 week

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

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...]
*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...]
*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



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

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

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

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:Psi...@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
>   

[Psidev-ms-dev] New revision of TraML 0.9.2

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

Hi everyone, I have updated the TraML schema to version 0.9.2 based on
feedback and our discussion on Tuesday. Please find all new documents at:

 

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

 

Please try updating your test software to 0.9.2 and let me know how it goes.

 

Thanks!

Eric

 

 

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eric,<br>
<br>
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). <br>
<br>
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. <br>
<br>
So, we could keep the existing 'backbone' series, and just add new
losses terms?<br>
<br>
btw, have you relocated down south or maybe you are suggesting we need
terms:<br>
<br>
[Term]<br>
id: MS:123456<br>
name: frag: y'<br>
<br>
[Term]<br>
id: MS:987654<br>
name: all<br>
def: All imaginable losses. Only to be used with MS:123456...&nbsp; ;)<br>
<br>
David<br>
<br>
Eric Deutsch wrote:
<blockquote cite="mid:BFF277A2A9654142ADAB6EB90CC20B9A@fozzie"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
  <style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
  </style>
  <div class="Section1">
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Hi mzIdentMLers, I have a
question for y&#8217;all:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">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:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">&lt;interpretation&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">&nbsp; &lt;cvParam cvRef="MS"
accession="MS:1001222" name="frag: b ion - H2O"/&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">&nbsp; &lt;cvParam cvRef="MS"
accession="MS:1000903" name="product ion series ordinal"
value="9"/&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">&nbsp; &lt;cvParam cvRef="MS"
accession="MS:1000904" name="product ion m/z delta"
value="-0.43"/&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">&lt;/interpretation&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">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.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">From the CV, I find
something like this:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><img id="_x0000_i1025"
 src="cid:par...@ma..." height="402"
 width="251"><o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Now it seems like there
are at least a dozen losses that are
not super uncommon, including multiple losses. Going down the road
we&#8217;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:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">+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<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">So where I&#8217;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.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Thanks,<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Eric<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
  <pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
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.  <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/bobj-july">http://p.sf.net/sfu/bobj-july</a></pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Psidev-pi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Psi...@li...">Psi...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev">https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

<a class="moz-txt-link-abbreviated" href="mailto:dc...@ma...">dc...@ma...</a>
<a class="moz-txt-link-freetext" href="http://www.matrixscience.com">http://www.matrixscience.com</a>

Matrix Science Ltd. is registered in England and Wales
Company number 3533898</pre>
</body>
</html>

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

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

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...]
*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



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

[Psidev-ms-dev] MIAPE modules

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

Hi all,

Quick update on some MIAPE modules that may be of interest more widely, hence the cross posting.


-          MIAPE Gel Informatics module recently completed the PSI process so is now at a stable version 1.0.

-          MIAPE Column Chromatography completed the PSI process some time back, it has now had some minor cosmetic changes and additional reviews (which have changed the appendix slightly but no change to the content)

-          MIAPE Capillary electrophoresis is about to be submitted to the PSI process, and is relatively stable at v0.8

These three modules are available from here: http://www.psidev.info/miape/ and we are about to submit these to Nature Biotech by the end of this week. If you are listed as a co-author on any of these modules, please can you contact me by Thurs 19th Nov: if you have any comments or issues i.e. with your affiliation, if you would like to see the NBT correspondence that will actually appear if each module gets accepted (one paragraph plus a summary box of text), or finally if you do not wish to be a listed co-author - hopefully all authors have okayed this in the past.

Best wishes
Andy

[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=17
<http://www.timeanddate.com/worldclock/fixedtime.html?day=17&month=11&year=2
009&hour=16&min=0&sec=0&p1=136>
&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>
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>
http://www.psidev.info/index.php?q=node/304

 

 

Re: [Psidev-ms-dev] [proteowizard-support] from mzML to mzXML

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

Hi Silvia,

I think this is the first I've seen of mzML export from an ABI TOF/TOF 
database. MzML requires information about the source file, so there has 
been some consternation about how this should work for sources which are 
actually databases or directories. Someone just posted yesterday on the 
PSI-dev list about writing mzML from databases, but the ABI folks never 
did (which is surprising since they did post the nativeID format they 
wanted for the TOF/TOF). Hopefully that's one of the reasons it's still 
considered in beta. :)

The TOF/TOF case is actually the one we considered while developing 
mzML. We never had a great solution for it, but IIRC the one we settled 
on was that TOF/TOF was typically exported to T2D files and therefore 
the T2D files would be the source files. That doesn't apply for direct 
export from the database though. The reason mzML requires the source 
file information is so that it can store a checksum (SHA-1 hash) of the 
file so that authenticity and integrity of the source file can be proven 
at a later point (i.e. Did this XML file come from this RAW file? Yes, 
the checksums match.). Now that direct export from databases is looking 
likely, we will have to address this in the PSI working group: it may 
require a minor mzML revision. I think we will want to keep the checksum 
mechanism, but we will negotiate with database exporters to come up with 
a reasonable way to do it. After all, databases must have ways to verify 
their data integrity just like files do.

In the mean time, you can work around this issue by either using the 
mzML, or manually changing the parentFile after conversion to mzXML. If 
you open the XML in Wordpad or a better text editor, change:
<parentFile fileName="AK159/CNR Project folder\LC MALDI\VSMC\LC Anionica 
cationica VSMC 80C 10Ottobre08"
to
<parentFile fileName="AK159/CNR Project fo\LC MALDI\VSMC\LC Anionica 
cationica VSMC 80C 10Ottobre08.raw"

I added the .raw extension and deleted the corresponding number of 
characters from the word "folder." The total number of characters needs 
to stay the same in order to preserve the index.

Thanks,
-Matt


Silvia Rocchiccioli wrote:
> I have an Applied Biosystems 4800 MALDI TOF TOF analyzer. I obtain 
> mzML from every LC run containing all MS and MSMS information about 
> the run.
> mzML is created with "mzML_Exporter" beta version from Sean Seymour 
> (ABI) http://www.psidev.info/index.php?q=node/257.
>
> I tried to use ProteoWizard to convert mzML to mzXML. While mzMl with 
> seems.exe works well, the converted mzXML doesn't work give me a 
> warning message:
>
> ---------------------------
>> Unhandled Exception
>> ---------------------------
>> System.Exception: 
>> [Serializer_mzXML::translate_parentFileExtensionToSourceFileType] 
>> unknown file extension for parentFile "LC Anionica cationica VSMC 80C 
>> 10Ottobre08"
>>    in pwiz.CLI.msdata.MSDataFile..ctor(String path)
>>    in seems.OpenDataSourceDialog.listView_ItemSelectionChanged(Object 
>> sender, ListViewItemSelectionChangedEventArgs e)
>>    in 
>> System.Windows.Forms.ListView.OnItemSelectionChanged(ListViewItemSelectionChangedEventArgs 
>> e)
>>    in System.Windows.Forms.ListView.WmReflectNotify(Message& m)
>>    in System.Windows.Forms.ListView.WndProc(Message& m)
>>    in 
>> System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
>>    in 
>> System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
>>    in System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 
>> msg, IntPtr wparam, IntPtr lparam)
>> ---------------------------
>> OK  ---------------------------
>
> could you check my mzML format?....you find attached.
> Thank you
> Silvia

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

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

Hi everyone, I don’t think we have any burning issues that mandate a PSI MSS
WG call this week. Maybe we all can spend the hour working on some of the
todo items instead of talking about them. 8) Please post your progress.



A summary of the current state of things as I understand it:



mzML:

- Manuscript needs to be rewritten (Lennart)



MIAPE:

- Document needs to be revised based on discussion in Toronto and posted for
further discussion and release (Pierre-Alain and Eric)



TraML:

- Latest beta release 0.9.1 is available at:
http://www.psidev.info/index.php?q=node/405

- Implementations are actively sought

- ProteoWizard implementation (Matt)

- OpenMS implementation and on-line validator (Andreas)

- Final preparation of specification document for submission (Eric)

- Writing journal manuscript (Eric)

- Prepare and post some example TraML files (everyone)

- Email out question about <interpretation> problem (Eric)



Please chime in with additional items and let’s plan on discussing next
week.



Thanks!

Eric

[Psidev-ms-dev] mzML MD5 hash question

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

Hi,

I am not entirely sure if I am posting to the correct mailing list or not.
If I'm not posting to the correct place, can you please let me know where I
should be posting to?  Thanks.

Anyway, the MD5 hash required in the sourceFile node suggests that the only
valid source for mass spec data is a file. We are now building our software
around a database back-end and therefore we do not have files. 

We have URI's which we can generate for source locations inside the database
so we're planning to use these for the file location.  However, the concept
of generating an MD5 hash from a series of relational entities is a bit
weird.

Since the schema mandates that a hash be generated (MD5 or SHA1) what would
you suggest that we do?

Thanks,
Mike.

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




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

[Psidev-ms-dev] BioPortal 2.2 Release

[Trish W. <plw...@gm...>]

The BioPortal team is pleased to announce the release of BioPortal 2.2 (
http://bioportal.bioontology.org/). Release notes and known issues are
listed below.

New Features

   - Ontology Views


   - Views in BioPortal are subsets or other derivatives of ontologies in
      the repository that you can share with the community. You can
upload views
      for any ontology, and review them, add notes, create mappings,
and use REST
      Web services to access them programmatically.
      - A view can also serve as a mechanism to define value sets, which are
      quite useful in combination with the BioPortal ontology-term selection
      widget.
      - View generation and storage in BioPortal is the result of
      collaboration with Dr. Jim Brinkley’s group at the University of
Washington.
   - NCBO Resource Index
      - We have initiated automated indexing of the contents of public
      databases using ontology terms. The indexing is done using the
same workflow
      that drives the previously released Annotator web service. Currently we
      index the following public databases:  Array Express, Biositemaps,
      caNanoLab, Conserved Domain Database, ClinicalTrials.gov, DrugBank, Gene
      Expression Omnibus, Online Mendelian Inheritance in Man,
PharmGKB, Reactome,
      ResearchCrossroads (Grant funding database), Stanford Microarray
Database,
      UniProt KB, and WikiPathways.  The resulting annotations are
      accessible for browsing via the Resources tab corresponding to
any ontology
      concept. The annotations can also be accessed programmatically:
      http://www.bioontology.org/wiki/index.php/Resource_Index.
      - If you have recommendations on additional publicly accessible
      resources to index, let us know at su...@bi....
   - Search filter for Ontology Groups and Categories
      - You can now limit your search to ontologies from a certain group
      (e.g., OBO Foundry, caBIG) or ontologies in a certain category (e.g.,
      anatomy).


New REST Web Services

   - Services to access ontologies and ontology versions
      - List all Categories
      - List all Groups
      - Download by virtual ontology identifier
   - Services to access ontology views and ontology view versions
      - List all Views of all Ontologies (lists the latest version)
      - List all versions for a given View
   - Concept services
      - Get all concepts
   - Search service – parameter added to enable search within an ontology
   branch
   - Service to access the NCBO Resource Index

See http://www.bioontology.org/wiki/index.php/BioPortal_REST_services for
the full list of BioPortal REST Web services.


New Data:

   - Mapping data generated by the LOOM algorithm are now in BioPortal
   (close to 1 million new lexical-based mappings). See
   http://www.bioontology.org/wiki/index.php/LOOM for more details about
   this tool.
   - Selected UMLS ontologies are now available in BioPortal. Email
   su...@bi... to request loading of additional UMLS ontologies.



Known Issues:

   - The tree navigation shows ‘Too many children’ in cases where the number
   of siblings is greater than 500.




Trish Whetzel, PhD
Outreach Coordinator
The National Center for Biomedical Ontology
Ph: 650-721-2378
wh...@st...
http://www.bioontology.org




_______________________________________________
bioportal-announce mailing list
bio...@li...
https://mailman.stanford.edu/mailman/listinfo/bioportal-announce

[Psidev-ms-dev] TraML 0.9.1 posted

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

Hi everyone, I have posted the new version of TraML 0.9.1 including HTML
documentation, xsd, and one hand-edited example file.  Please examine
closely, try to implement, send your comments. I have not tried to run it
through the semantic validator. Would the semantic validator maintainers try
to validate this against the latest mapping file?



Thanks,

Eric

[Psidev-ms-dev] Converter for Hitachi .dat format?

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

Hi everyone, we got some files with a .dat filename extension that are from
a Hitachi linear ion trap-TOF instrument. Does anyone know of a way to
convert these to an open format? Matt or Darren, have any ProteoWizard folk
investigated converting Hitachi .dat files?



Thanks,

Eric

[Psidev-ms-dev] Notes of phone conference 20091027

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

Dear PSI-MS Enthusiasts,


Les notes, attached.


Cheers,

lnnrt.

Re: [Psidev-ms-dev] Addition of <targetList> to TraML?

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

Hi Andreas, attached is an updated example and xsd. Please look these over
and let us know what you think. And let's discuss at the call.

Thanks!
Eric


> -----Original Message-----
> From: Andreas Bertsch [mailto:be...@in...]
> Sent: Sunday, October 25, 2009 11:28 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Addition of <targetList> to TraML?
> 
> Hi Eric,
> 
> > Hi Andreas, can you provide a move complete definition of the
> > retention time window? I wouldn't think that a "window" is a
> > property of a peptide. It is rather a tolerance within which one
> > wants to look for a peptide? And it depends on your gradient, of
> > course. The window you use might well differ for a 30 min vs 90 mins
> > gradient, right?
> >
> > Maybe we would be better off putting the different retention times
> > in separated elements under a retentionTimeList. This might provide
> > some more specificity and flexibility with only minor additional
> > verbosity.
> Yes, separating retention time is a good idea. I also agree with the
> idea of Fredrik to use two terms to specify the retention time window.
> Maybe, we should document the way how asymmetric RT windows are
> handled to create lists, if only one symmetric RT window is allowed
> (like in QTrap 4000).
> 
> Maybe it is also a good idea to have a mandatory CV term that
> describes the source of the RT, which gives a hint about the
> reliability if more than one is present. E.g. database, prediction
> software, experimental...
> 
> Can you update the schema first, before we update the examples?
> Writing the files without a schema to validate, is like blind flying ;).
> 
> Cheers,
> A.
> 
> 
> 
> > So instead of what we have now:
> >
> >    <retentionTime predictedRetentionTimeSoftwareRef="SSRCalc3.0">
> >      <cvParam cvRef="MS" accession="MS:1000895" name="local
> > retention time" value="40.02" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >      <cvParam cvRef="MS" accession="MS:1000896" name="normalized>
> > retention time" value="38.43" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >      <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS
> > retention time normalization standard"/>
> >      <cvParam cvRef="MS" accession="MS:1000897" name="predicted
> > retention time" value="44.07" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >    </retentionTime>
> >
> > We might do:
> >
> >  <retentionTimeList>
> >    <retentionTime softwareRef="Skyline0.5">>
> >      <cvParam cvRef="MS" accession="MS:1000895" name="local
> > retention time" value="40.02" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >      <cvParam cvRef="MS" accession="MS:1000XXX" name="retention time
> > window" value="3.0" unitCvRef="UO" unitAccession="UO:0000031"
> > unitName="minute"/>
> >    </retentionTime>
> >    <retentionTime>
> >      <cvParam cvRef="MS" accession="MS:1000896" name="normalized
> > retention time" value="38.43" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >      <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS
> > retention time normalization standard"/>
> >    </retentionTime>
> >    <retentionTime softwareRef="SSRCalc3.0">
> >      <cvParam cvRef="MS" accession="MS:1000897" name="predicted
> > retention time" value="44.07" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >    </retentionTime>
> >
> > How does this strike y'all?
> >
> > Thanks,
> > Eric
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Andreas Bertsch [mailto:be...@in...]
> > > Sent: Wednesday, October 07, 2009 1:50 AM
> > > To: Mass spectrometry standard development
> > > Subject: Re: [Psidev-ms-dev] Addition of <targetList> to TraML?
> > >
> > > Hi Pierre-Alain,
> > >
> > > > I beleive that Retention time window restriction is also
> > applicable
> > > > here by adding a corresponding cvParam, right?
> > > The retention time information is stored at the compound and peptide
> > > entries, just the same mechanism as used in transition sections.
> > Here
> > > a snippet from the toy example:
> > >
> > > .....
> > >      <peptide id="ADTHFLLNIYDQLR-M1" proteinRef="Q12149">
> > >        <cvParam cvRef="MS" accession="MS:1000888" name="unmodified
> > > peptide sequence" value="ADTHFLLNIYDQLR"/>
> > >        <cvParam cvRef="MS" accession="MS:1000889" name="modified
> > > peptide sequence" value="ADTHFLLNIYDQLR[162.10111]"/>
> > > .....
> > >        <cvParam cvRef="MS" accession="MS:1001117" name="theoretical
> > > mass" value="1189.22" unitCvRef="UO" unitAccession="UO:0000221"
> > > unitName="dalton"/>
> > >        <retentionTime
> > predictedRetentionTimeSoftwareRef="SSRCalc3.0">
> > >          <cvParam cvRef="MS" accession="MS:1000895" name="local
> > > retention time" value="40.02" unitCvRef="UO" unitAccession="UO:
> > > 0000031" unitName="minute"/>
> > >          <cvParam cvRef="MS" accession="MS:1000896" name="normalized
> > > retention time" value="38.43" unitCvRef="UO" unitAccession="UO:
> > > 0000031" unitName="minute"/>
> > >          <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS
> > > retention time normalization standard"/>
> > >          <cvParam cvRef="MS" accession="MS:1000897" name="predicted
> > > retention time" value="44.07" unitCvRef="UO" unitAccession="UO:
> > > 0000031" unitName="minute"/>
> > >        </retentionTime>
> > >       ....
> > >     </peptide>
> > > ....
> > >
> > >
> > > So far there is now CV term to restrict the retention time window.
> > > However, we should add one.
> > >
> > > [Term]
> > > id: MS:XXXXXXXX
> > > name: retention time window
> > > def: "Retention time window of e.g. a compound" [PSI:PI]
> > > xref: value-type:xsd\:double "The allowed value-type for this CV
> > term."
> > > relationship: has_units UO:0000010 ! second
> > > relationship: has_units UO:0000031 ! minute
> > >
> > > I think it should be allowed as an attribute of a peptide or
> > compound,
> > > but also as a global setting, e.g. some instruments allow only the
> > > global setting of a retention time window
> 
> --
> 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
> 
> 
> 
> 
> 
> --------------------------------------------------------------------------
> ----
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

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

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

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



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



(Note: Europe is off daylight savings time, but the US is still on it, so I
have opted to retain the usual time in Europe, but shifted the meeting 1
hour later in the US. I normally have a conflict at this time, but do not
tomorrow. I hope this is okay with most participants)



09:00 San Francisco

12:00 New York

16:00 London

17:00 Geneva



+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)



access code: 297427



Agenda:

1) mzML 1.1.0

- Manuscript

- Outstanding items



----

2) MIAPE-MS revision

- Revised document. Discuss changes.



----

3) TraML development

- Version 0.9.0 still posted at dev page:

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

- Proposal to add a new <targetList> module to TraML for ordinary inclusion
lists

- Addition of <retentionTimeList> construct

- Enhanced AA mass modification encoding

- Returning peptide sequence back to an attribute

- Add <proteinRef> as an element to allow multiple

- Split retention time window into “retention time start” and “retention
time end” cvParams

- Fredrik proposes to put local retention times under transition instead of
peptide/compound

- Andreas suggests a term for describing the source of an RT (prediction,
database, experimental…)

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

Re: [Psidev-ms-dev] Addition of <targetList> to TraML?

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

Hi Eric,

> Hi Andreas, can you provide a move complete definition of the  
> retention time window? I wouldn't think that a "window" is a  
> property of a peptide. It is rather a tolerance within which one  
> wants to look for a peptide? And it depends on your gradient, of  
> course. The window you use might well differ for a 30 min vs 90 mins  
> gradient, right?
>
> Maybe we would be better off putting the different retention times  
> in separated elements under a retentionTimeList. This might provide  
> some more specificity and flexibility with only minor additional  
> verbosity.
Yes, separating retention time is a good idea. I also agree with the  
idea of Fredrik to use two terms to specify the retention time window.  
Maybe, we should document the way how asymmetric RT windows are  
handled to create lists, if only one symmetric RT window is allowed  
(like in QTrap 4000).

Maybe it is also a good idea to have a mandatory CV term that  
describes the source of the RT, which gives a hint about the  
reliability if more than one is present. E.g. database, prediction  
software, experimental...

Can you update the schema first, before we update the examples?  
Writing the files without a schema to validate, is like blind flying ;).

Cheers,
A.



> So instead of what we have now:
>
>    <retentionTime predictedRetentionTimeSoftwareRef="SSRCalc3.0">
>      <cvParam cvRef="MS" accession="MS:1000895" name="local  
> retention time" value="40.02" unitCvRef="UO" unitAccession="UO: 
> 0000031" unitName="minute"/>
>      <cvParam cvRef="MS" accession="MS:1000896" name="normalized>  
> retention time" value="38.43" unitCvRef="UO" unitAccession="UO: 
> 0000031" unitName="minute"/>
>      <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS  
> retention time normalization standard"/>
>      <cvParam cvRef="MS" accession="MS:1000897" name="predicted  
> retention time" value="44.07" unitCvRef="UO" unitAccession="UO: 
> 0000031" unitName="minute"/>
>    </retentionTime>
>
> We might do:
>
>  <retentionTimeList>
>    <retentionTime softwareRef="Skyline0.5">>
>      <cvParam cvRef="MS" accession="MS:1000895" name="local  
> retention time" value="40.02" unitCvRef="UO" unitAccession="UO: 
> 0000031" unitName="minute"/>
>      <cvParam cvRef="MS" accession="MS:1000XXX" name="retention time  
> window" value="3.0" unitCvRef="UO" unitAccession="UO:0000031"  
> unitName="minute"/>
>    </retentionTime>
>    <retentionTime>
>      <cvParam cvRef="MS" accession="MS:1000896" name="normalized  
> retention time" value="38.43" unitCvRef="UO" unitAccession="UO: 
> 0000031" unitName="minute"/>
>      <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS  
> retention time normalization standard"/>
>    </retentionTime>
>    <retentionTime softwareRef="SSRCalc3.0">
>      <cvParam cvRef="MS" accession="MS:1000897" name="predicted  
> retention time" value="44.07" unitCvRef="UO" unitAccession="UO: 
> 0000031" unitName="minute"/>
>    </retentionTime>
>
> How does this strike y’all?
>
> Thanks,
> Eric
>
>
>
>
>
> > -----Original Message-----
> > From: Andreas Bertsch [mailto:be...@in...]
> > Sent: Wednesday, October 07, 2009 1:50 AM
> > To: Mass spectrometry standard development
> > Subject: Re: [Psidev-ms-dev] Addition of <targetList> to TraML?
> >
> > Hi Pierre-Alain,
> >
> > > I beleive that Retention time window restriction is also  
> applicable
> > > here by adding a corresponding cvParam, right?
> > The retention time information is stored at the compound and peptide
> > entries, just the same mechanism as used in transition sections.  
> Here
> > a snippet from the toy example:
> >
> > .....
> >      <peptide id="ADTHFLLNIYDQLR-M1" proteinRef="Q12149">
> >        <cvParam cvRef="MS" accession="MS:1000888" name="unmodified
> > peptide sequence" value="ADTHFLLNIYDQLR"/>
> >        <cvParam cvRef="MS" accession="MS:1000889" name="modified
> > peptide sequence" value="ADTHFLLNIYDQLR[162.10111]"/>
> > .....
> >        <cvParam cvRef="MS" accession="MS:1001117" name="theoretical
> > mass" value="1189.22" unitCvRef="UO" unitAccession="UO:0000221"
> > unitName="dalton"/>
> >        <retentionTime  
> predictedRetentionTimeSoftwareRef="SSRCalc3.0">
> >          <cvParam cvRef="MS" accession="MS:1000895" name="local
> > retention time" value="40.02" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >          <cvParam cvRef="MS" accession="MS:1000896" name="normalized
> > retention time" value="38.43" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >          <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS
> > retention time normalization standard"/>
> >          <cvParam cvRef="MS" accession="MS:1000897" name="predicted
> > retention time" value="44.07" unitCvRef="UO" unitAccession="UO:
> > 0000031" unitName="minute"/>
> >        </retentionTime>
> >       ....
> >     </peptide>
> > ....
> >
> >
> > So far there is now CV term to restrict the retention time window.
> > However, we should add one.
> >
> > [Term]
> > id: MS:XXXXXXXX
> > name: retention time window
> > def: "Retention time window of e.g. a compound" [PSI:PI]
> > xref: value-type:xsd\:double "The allowed value-type for this CV  
> term."
> > relationship: has_units UO:0000010 ! second
> > relationship: has_units UO:0000031 ! minute
> >
> > I think it should be allowed as an attribute of a peptide or  
> compound,
> > but also as a global setting, e.g. some instruments allow only the
> > global setting of a retention time window

--
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

Re: [Psidev-ms-dev] Addition of <targetList> to TraML?

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

Hi Eric and Andreas,

I think the retention time list makes sense and improves both 
readability and possibilities for giving predictions for more than one 
program. For the local retention time window I think it should instead 
be two terms, representing retention time start and retention time end.  
This would be analogous to the representation of all the window 
attributes in mzML, to avoid the general confusion windows and delta 
etc.  Also, Xcalibur inclusion lists specifies start and end times 
instead of the mid time, which allows asymmetric windows.
There is a possibility that someone would like to look for the same 
peptide but at different charge states in different time windows. Maybe 
not in practice, since they should elute at the same time, but maybe if 
one of the charge states is partially overlapping another peptide. With 
the current way of specifying retention time this would not work. Would 
anyone agree upon putting the predicted retention times at the 
peptide/compound level, and the actual retention times (local) used in 
the current setup in the target list? The target list would then be 
useful as is with an identical instrumental setup, while usage with 
another gradient would imply recalculation based on the values found 
under peptide.

Thanks

Fredrik


ede...@sy... wrote:
>
>  
>
> Hi Andreas, can you provide a move complete definition of the 
> retention time window? I wouldn't think that a "window" is a property 
> of a peptide. It is rather a tolerance within which one wants to look 
> for a peptide? And it depends on your gradient, of course. The window 
> you use might well differ for a 30 min vs 90 mins gradient, right?
>
>  
>
> Maybe we would be better off putting the different retention times in 
> separated elements under a retentionTimeList. This might provide some 
> more specificity and flexibility with only minor additional verbosity.
>
>  
>
> So instead of what we have now:
>
>  
>
>    <retentionTime predictedRetentionTimeSoftwareRef="SSRCalc3.0">
>
>      <cvParam cvRef="MS" accession="MS:1000895" name="local retention 
> time" value="40.02" unitCvRef="UO" unitAccession="UO:0000031" 
> unitName="minute"/>
>
>      <cvParam cvRef="MS" accession="MS:1000896" name="normalized> 
> retention time" value="38.43" unitCvRef="UO" 
> unitAccession="UO:0000031" unitName="minute"/>
>
>      <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS retention 
> time normalization standard"/>
>
>      <cvParam cvRef="MS" accession="MS:1000897" name="predicted 
> retention time" value="44.07" unitCvRef="UO" 
> unitAccession="UO:0000031" unitName="minute"/>
>
>    </retentionTime>
>
>  
>
> We might do:
>
>  
>
>  <retentionTimeList>
>
>    <retentionTime softwareRef="Skyline0.5">>
>
>      <cvParam cvRef="MS" accession="MS:1000895" name="local retention 
> time" value="40.02" unitCvRef="UO" unitAccession="UO:0000031" 
> unitName="minute"/>
>
>      <cvParam cvRef="MS" accession="MS:1000XXX" name="retention time 
> window" value="3.0" unitCvRef="UO" unitAccession="UO:0000031" 
> unitName="minute"/>
>
>    </retentionTime>
>
>    <retentionTime>
>
>      <cvParam cvRef="MS" accession="MS:1000896" name="normalized 
> retention time" value="38.43" unitCvRef="UO" 
> unitAccession="UO:0000031" unitName="minute"/>
>
>      <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS retention 
> time normalization standard"/>
>
>    </retentionTime>
>
>    <retentionTime softwareRef="SSRCalc3.0">
>
>      <cvParam cvRef="MS" accession="MS:1000897" name="predicted 
> retention time" value="44.07" unitCvRef="UO" 
> unitAccession="UO:0000031" unitName="minute"/>
>
>    </retentionTime>
>
>  
>
> How does this strike y’all?
>
>  
>
> Thanks,
>
> Eric
>
>  
>
>  
>
>  
>
>  
>
>  
>
> > -----Original Message-----
>
> > From: Andreas Bertsch [mailto:be...@in... 
> <mailto:be...@in...>]
>
> > Sent: Wednesday, October 07, 2009 1:50 AM
>
> > To: Mass spectrometry standard development
>
> > Subject: Re: [Psidev-ms-dev] Addition of <targetList> to TraML?
>
> >
>
> > Hi Pierre-Alain,
>
> >
>
> > > I beleive that Retention time window restriction is also applicable
>
> > > here by adding a corresponding cvParam, right?
>
> > The retention time information is stored at the compound and peptide
>
> > entries, just the same mechanism as used in transition sections. Here
>
> > a snippet from the toy example:
>
> >
>
> > .....
>
> >      <peptide id="ADTHFLLNIYDQLR-M1" proteinRef="Q12149">
>
> >        <cvParam cvRef="MS" accession="MS:1000888" name="unmodified
>
> > peptide sequence" value="ADTHFLLNIYDQLR"/>
>
> >        <cvParam cvRef="MS" accession="MS:1000889" name="modified
>
> > peptide sequence" value="ADTHFLLNIYDQLR[162.10111]"/>
>
> > .....
>
> >        <cvParam cvRef="MS" accession="MS:1001117" name="theoretical
>
> > mass" value="1189.22" unitCvRef="UO" unitAccession="UO:0000221"
>
> > unitName="dalton"/>
>
> >        <retentionTime predictedRetentionTimeSoftwareRef="SSRCalc3.0">
>
> >          <cvParam cvRef="MS" accession="MS:1000895" name="local
>
> > retention time" value="40.02" unitCvRef="UO" unitAccession="UO:
>
> > 0000031" unitName="minute"/>
>
> >          <cvParam cvRef="MS" accession="MS:1000896" name="normalized
>
> > retention time" value="38.43" unitCvRef="UO" unitAccession="UO:
>
> > 0000031" unitName="minute"/>
>
> >          <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS
>
> > retention time normalization standard"/>
>
> >          <cvParam cvRef="MS" accession="MS:1000897" name="predicted
>
> > retention time" value="44.07" unitCvRef="UO" unitAccession="UO:
>
> > 0000031" unitName="minute"/>
>
> >        </retentionTime>
>
> >       ....
>
> >     </peptide>
>
> > ....
>
> >
>
> >
>
> > So far there is now CV term to restrict the retention time window.
>
> > However, we should add one.
>
> >
>
> > [Term]
>
> > id: MS:XXXXXXXX
>
> > name: retention time window
>
> > def: "Retention time window of e.g. a compound" [PSI:PI]
>
> > xref: value-type:xsd\:double "The allowed value-type for this CV term."
>
> > relationship: has_units UO:0000010 ! second
>
> > relationship: has_units UO:0000031 ! minute
>
> >
>
> > I think it should be allowed as an attribute of a peptide or compound,
>
> > but also as a global setting, e.g. some instruments allow only the
>
> > global setting of a retention time window
>
> >
>
> > 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
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > -----------------------------------------------------------------------
>
> > -------
>
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>
> > is the only developer event you need to attend this year. Jumpstart
>
> > your
>
> > developing skills, take BlackBerry mobile applications to market and
>
> > stay
>
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>
> > http://p.sf.net/sfu/devconference
>
> > _______________________________________________
>
> > Psidev-ms-dev mailing list
>
> > Psi...@li... 
> <mailto:Psi...@li...>
>
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

Re: [Psidev-ms-dev] amino acid modifications in TraML

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

> From: Andreas Bertsch [mailto:be...@in...]
>
> Dear mzTargetML community ;),
>
> during the implementation of the current draft version, some questions
> and comments came up.
>
> Cheers,
> A.
>
> 1. Currently, peptide modifications in traML are specified using the
> mass only. This can lead to ambiguous meanings.
>
>   <peptide id="ADTHFLLNIYDQLR-M1" proteinRef="Q12149">
>        <cvParam cvRef="MS" accession="MS:1000888" name="unmodified
> peptide sequence" value="ADTHFLLNIYDQLR"/>
>        <cvParam cvRef="MS" accession="MS:1000889" name="modified
> peptide sequence" value="ADTHFLLNIYDQLR[162.10111]"/>
>
> The same problem has been solved by the PI group in mzIdentML using
> the modification definitions of UniMod (snippet from the
> Macot_MSMS_example.mzid):
> .....
>   <Peptide id="peptide_3_9">
>        <peptideSequence>MSKPAGSTSRILDIPCK</peptideSequence>
>        <Modification location="0" monoisotopicMassDelta="127.063324">
>          <cvParam accession="UNIMOD:29" name="SMA" cvRef="UNIMOD" />
>        </Modification>
>        <Modification location="1" residues="M"
> monoisotopicMassDelta="15.994919">
>          <cvParam accession="UNIMOD:35" name="Oxidation"
> cvRef="UNIMOD" />
>          .....
>        </Modification>
>      </Peptide>
> .....
>
> If the modification itself is not known, the following term can be
> used (and is allowed in mzIdentML)
>
> [Term]
> id: MS:1001460
> name: unknown modification

A lot more cumbersome. But yes, I think this is probably better. I would
agree with this change.

> 2.  Modeling the peptide sequence using a CV term seems odd to me. I
> think this can be an attribute, or like in mzIdentML modeled as a
> subtag of peptide. The sequence must be given, I suppose, otherwise it
> can be modeled as a (unkown) compound.

Neutral on this. One reason for the current way of doing things was to
differentiate between modified and unmodified. With the above proposed
mechanism for modifications, this becomes less useful. The second reason
was mainly a general switch to everything as a CV term.

I'm happy to return to an attribute.

Other thoughts?

> 3 . Additionally, the proteinRef is not necessarily restricted to one
> single protein. There might be several proteins that contain that
> peptide and it should be possible to represent that. Make that a CV
> term?

This topic has surfaced before but never really dealt with well.

One reason to keep it an attribute is to insure proper reference to the
<protein> tag. That can't be done with a CV param (easily?).

One alternate possibility is to do something like:

<peptide id="ADTHFLLNIYDQLR-M1" sequence="ADTHFLLNIYDQLR">
  <proteinRef ref="Q12149">
  <proteinRef ref="P03934">
  <proteinRef ref="IPI00343833">
  <cvParam.....
</peptide>

With modification information:

<peptide id="ADTHFLLNIYDQLR-M1" sequence="ADTHFLLNIYDQLR">
  <proteinRef ref="Q12149">
  <proteinRef ref="P03934">
  <proteinRef ref="IPI00343833">
  <modification location="0" monoisotopicMassDelta="127.063324">
    <cvParam accession="UNIMOD:29" name="SMA" cvRef="UNIMOD"/>
  </modification>
  <modification location="1" residues="M"
monoisotopicMassDelta="15.994919">
    <cvParam accession="UNIMOD:35" name="Oxidation" cvRef="UNIMOD"/>
  </modification>
</peptide>

What do y'uns think of that?

Thanks,
Eric



>
>
> --
> 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
>
>
>
>
>
> -----------------------------------------------------------------------
> -------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Addition of <targetList> to TraML?

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

Hi Andreas, can you provide a move complete definition of the retention time
window? I wouldn't think that a "window" is a property of a peptide. It is
rather a tolerance within which one wants to look for a peptide? And it
depends on your gradient, of course. The window you use might well differ
for a 30 min vs 90 mins gradient, right?



Maybe we would be better off putting the different retention times in
separated elements under a retentionTimeList. This might provide some more
specificity and flexibility with only minor additional verbosity.



So instead of what we have now:



   <retentionTime predictedRetentionTimeSoftwareRef="SSRCalc3.0">

     <cvParam cvRef="MS" accession="MS:1000895" name="local retention time"
value="40.02" unitCvRef="UO" unitAccession="UO:0000031" unitName="minute"/>

     <cvParam cvRef="MS" accession="MS:1000896" name="normalized> retention
time" value="38.43" unitCvRef="UO" unitAccession="UO:0000031"
unitName="minute"/>

     <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS retention time
normalization standard"/>

     <cvParam cvRef="MS" accession="MS:1000897" name="predicted retention
time" value="44.07" unitCvRef="UO" unitAccession="UO:0000031"
unitName="minute"/>

   </retentionTime>



We might do:



 <retentionTimeList>

   <retentionTime softwareRef="Skyline0.5">>

     <cvParam cvRef="MS" accession="MS:1000895" name="local retention time"
value="40.02" unitCvRef="UO" unitAccession="UO:0000031" unitName="minute"/>

     <cvParam cvRef="MS" accession="MS:1000XXX" name="retention time window"
value="3.0" unitCvRef="UO" unitAccession="UO:0000031" unitName="minute"/>

   </retentionTime>

   <retentionTime>

     <cvParam cvRef="MS" accession="MS:1000896" name="normalized retention
time" value="38.43" unitCvRef="UO" unitAccession="UO:0000031"
unitName="minute"/>

     <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS retention time
normalization standard"/>

   </retentionTime>

   <retentionTime softwareRef="SSRCalc3.0">

     <cvParam cvRef="MS" accession="MS:1000897" name="predicted retention
time" value="44.07" unitCvRef="UO" unitAccession="UO:0000031"
unitName="minute"/>

   </retentionTime>



How does this strike y’all?



Thanks,

Eric











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

> From: Andreas Bertsch [mailto:be...@in...]

> Sent: Wednesday, October 07, 2009 1:50 AM

> To: Mass spectrometry standard development

> Subject: Re: [Psidev-ms-dev] Addition of <targetList> to TraML?

>

> Hi Pierre-Alain,

>

> > I beleive that Retention time window restriction is also applicable

> > here by adding a corresponding cvParam, right?

> The retention time information is stored at the compound and peptide

> entries, just the same mechanism as used in transition sections. Here

> a snippet from the toy example:

>

> .....

>      <peptide id="ADTHFLLNIYDQLR-M1" proteinRef="Q12149">

>        <cvParam cvRef="MS" accession="MS:1000888" name="unmodified

> peptide sequence" value="ADTHFLLNIYDQLR"/>

>        <cvParam cvRef="MS" accession="MS:1000889" name="modified

> peptide sequence" value="ADTHFLLNIYDQLR[162.10111]"/>

> .....

>        <cvParam cvRef="MS" accession="MS:1001117" name="theoretical

> mass" value="1189.22" unitCvRef="UO" unitAccession="UO:0000221"

> unitName="dalton"/>

>        <retentionTime predictedRetentionTimeSoftwareRef="SSRCalc3.0">

>          <cvParam cvRef="MS" accession="MS:1000895" name="local

> retention time" value="40.02" unitCvRef="UO" unitAccession="UO:

> 0000031" unitName="minute"/>

>          <cvParam cvRef="MS" accession="MS:1000896" name="normalized

> retention time" value="38.43" unitCvRef="UO" unitAccession="UO:

> 0000031" unitName="minute"/>

>          <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS

> retention time normalization standard"/>

>          <cvParam cvRef="MS" accession="MS:1000897" name="predicted

> retention time" value="44.07" unitCvRef="UO" unitAccession="UO:

> 0000031" unitName="minute"/>

>        </retentionTime>

>       ....

>     </peptide>

> ....

>

>

> So far there is now CV term to restrict the retention time window.

> However, we should add one.

>

> [Term]

> id: MS:XXXXXXXX

> name: retention time window

> def: "Retention time window of e.g. a compound" [PSI:PI]

> xref: value-type:xsd\:double "The allowed value-type for this CV term."

> relationship: has_units UO:0000010 ! second

> relationship: has_units UO:0000031 ! minute

>

> I think it should be allowed as an attribute of a peptide or compound,

> but also as a global setting, e.g. some instruments allow only the

> global setting of a retention time window

>

> 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

>

>

>

>

>

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

> -------

> Come build with us! The BlackBerry(R) Developer Conference in SF, CA

> is the only developer event you need to attend this year. Jumpstart

> your

> developing skills, take BlackBerry mobile applications to market and

> stay

> ahead of the curve. Join us from November 9 - 12, 2009. Register now!

> http://p.sf.net/sfu/devconference

> _______________________________________________

> Psidev-ms-dev mailing list

> Psi...@li...

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

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

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

Hi everyone, sorry for the late notice, but I cannot be at the PSI Mass
Spectrometry Standards Working Group call tomorrow. Let's cancel and discuss
progress next week instead.

 

Thanks,

Eric

 

 

[Psidev-ms-dev] amino acid modifications in TraML

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

Dear mzTargetML community ;),

during the implementation of the current draft version, some questions  
and comments came up.

Cheers,
A.

1. Currently, peptide modifications in traML are specified using the  
mass only. This can lead to ambiguous meanings.

  <peptide id="ADTHFLLNIYDQLR-M1" proteinRef="Q12149">
       <cvParam cvRef="MS" accession="MS:1000888" name="unmodified  
peptide sequence" value="ADTHFLLNIYDQLR"/>
       <cvParam cvRef="MS" accession="MS:1000889" name="modified  
peptide sequence" value="ADTHFLLNIYDQLR[162.10111]"/>

The same problem has been solved by the PI group in mzIdentML using  
the modification definitions of UniMod (snippet from the  
Macot_MSMS_example.mzid):
.....
  <Peptide id="peptide_3_9">
       <peptideSequence>MSKPAGSTSRILDIPCK</peptideSequence>
       <Modification location="0" monoisotopicMassDelta="127.063324">
         <cvParam accession="UNIMOD:29" name="SMA" cvRef="UNIMOD" />
       </Modification>
       <Modification location="1" residues="M"  
monoisotopicMassDelta="15.994919">
         <cvParam accession="UNIMOD:35" name="Oxidation"  
cvRef="UNIMOD" />
         .....
       </Modification>
     </Peptide>
.....

If the modification itself is not known, the following term can be  
used (and is allowed in mzIdentML)

[Term]
id: MS:1001460
name: unknown modification

2.  Modeling the peptide sequence using a CV term seems odd to me. I  
think this can be an attribute, or like in mzIdentML modeled as a  
subtag of peptide. The sequence must be given, I suppose, otherwise it  
can be modeled as a (unkown) compound.

3 . Additionally, the proteinRef is not necessarily restricted to one  
single protein. There might be several proteins that contain that  
peptide and it should be possible to represent that. Make that a CV  
term?



--
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

Re: [Psidev-ms-dev] Addition of <targetList> to TraML?

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

Hi Pierre-Alain,

> I beleive that Retention time window restriction is also applicable  
> here by adding a corresponding cvParam, right?
The retention time information is stored at the compound and peptide  
entries, just the same mechanism as used in transition sections. Here  
a snippet from the toy example:

.....
     <peptide id="ADTHFLLNIYDQLR-M1" proteinRef="Q12149">
       <cvParam cvRef="MS" accession="MS:1000888" name="unmodified  
peptide sequence" value="ADTHFLLNIYDQLR"/>
       <cvParam cvRef="MS" accession="MS:1000889" name="modified  
peptide sequence" value="ADTHFLLNIYDQLR[162.10111]"/>
.....
       <cvParam cvRef="MS" accession="MS:1001117" name="theoretical  
mass" value="1189.22" unitCvRef="UO" unitAccession="UO:0000221"  
unitName="dalton"/>
       <retentionTime predictedRetentionTimeSoftwareRef="SSRCalc3.0">
         <cvParam cvRef="MS" accession="MS:1000895" name="local  
retention time" value="40.02" unitCvRef="UO" unitAccession="UO: 
0000031" unitName="minute"/>
         <cvParam cvRef="MS" accession="MS:1000896" name="normalized  
retention time" value="38.43" unitCvRef="UO" unitAccession="UO: 
0000031" unitName="minute"/>
         <cvParam cvRef="MS" accession="MS:1000902" name="H-PINS  
retention time normalization standard"/>
         <cvParam cvRef="MS" accession="MS:1000897" name="predicted  
retention time" value="44.07" unitCvRef="UO" unitAccession="UO: 
0000031" unitName="minute"/>
       </retentionTime>
      ....
    </peptide>
....


So far there is now CV term to restrict the retention time window.  
However, we should add one.

[Term]
id: MS:XXXXXXXX
name: retention time window
def: "Retention time window of e.g. a compound" [PSI:PI]
xref: value-type:xsd\:double "The allowed value-type for this CV term."
relationship: has_units UO:0000010 ! second
relationship: has_units UO:0000031 ! minute

I think it should be allowed as an attribute of a peptide or compound,  
but also as a global setting, e.g. some instruments allow only the  
global setting of a retention time window

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

Re: [Psidev-ms-dev] Addition of <targetList> to TraML?

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

I beleive that Retention time window restriction is also applicable here 
by adding a corresponding cvParam, right?

Pierre-Alain

ede...@sy... wrote:
>
> Hi everyone, it has been proposed to add to TraML the capability to 
> encode ordinary inclusion lists and exclusions lists. Here is what we 
> currently envision. Comments? Suggestions?
>
>  
>
> <transitionList>
>
> …
>
> </transitionList>
>
> <targetList>
>
>   <cvParam cvRef="MS" accession="MS:100XXXX" name="includes supersede 
> excludes"/>
>
>   <targetIncludeList>
>
>     <target id=”PEPTIDEC2+” peptideRef=”PEPTIDEC”>
>
>       <precursor>
>
>         <cvParam cvRef="MS" accession="MS:1000040" name="m/z" 
> value="862.9467"/>
>
>         <cvParam cvRef="MS" accession="MS:1000211" name="charge 
> number" value="2"/>
>
>       </precursor>
>
>       <configurationList>…</configurationList>
>
>     </target>
>
>     …
>
>   </targetIncludeList>
>
>   <targetExcludeList>
>
>     <target id=”PEPTIDEM3+” peptideRef=”PEPTIDEM”>
>
>         <cvParam cvRef="MS" accession="MS:1000040" name="m/z" 
> value="698.3443"/>
>
>         <cvParam cvRef="MS" accession="MS:1000211" name="charge 
> number" value="3"/>
>
>       <configurationList>…</configurationList>
>
>     </target>
>
>     …
>
>   </targetExcludeList>
>
> </targetList>
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] Addition of <targetList> to TraML?

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

Hi everyone, it has been proposed to add to TraML the capability to encode
ordinary inclusion lists and exclusions lists. Here is what we currently
envision. Comments? Suggestions?



<transitionList>

…

</transitionList>

<targetList>

  <cvParam cvRef="MS" accession="MS:100XXXX" name="includes supersede
excludes"/>

  <targetIncludeList>

    <target id=”PEPTIDEC2+” peptideRef=”PEPTIDEC”>

      <precursor>

        <cvParam cvRef="MS" accession="MS:1000040" name="m/z"
value="862.9467"/>

        <cvParam cvRef="MS" accession="MS:1000211" name="charge number"
value="2"/>

      </precursor>

      <configurationList>…</configurationList>

    </target>

    …

  </targetIncludeList>

  <targetExcludeList>

    <target id=”PEPTIDEM3+” peptideRef=”PEPTIDEM”>

        <cvParam cvRef="MS" accession="MS:1000040" name="m/z"
value="698.3443"/>

        <cvParam cvRef="MS" accession="MS:1000211" name="charge number"
value="3"/>

      <configurationList>…</configurationList>

    </target>

    …

  </targetExcludeList>

</targetList>