Menu
▾
▴
psidev-ms-dev
|
From: <ede...@sy...> - 2009-10-06 20:38:48
|
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>
|
|
From: Pierre-Alain B. <pie...@is...> - 2009-10-07 07:50:33
|
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 > |
|
From: Andreas B. <be...@in...> - 2009-10-07 08:50:32
|
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
|
|
From: <ede...@sy...> - 2009-10-21 00:06:32
|
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
|
|
From: Fredrik L. <Fre...@im...> - 2009-10-21 07:57:09
|
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 > |
|
From: Andreas B. <be...@in...> - 2009-10-26 06:28:13
|
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 |
|
From: Eric D. <ede...@sy...> - 2009-10-27 08:01:21
Attachments:
ToyExample1.traml
TraML0.9.1.xsd
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X