psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] Lockmass / (Re)calibration data

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

Hi,

as discussed during the call today, there is some need to clarify 
on calibration and in particular on (waters) lockmass handling.

There are two possible scenarios to be distinguished:

1) The data exported to mzML has been recalibrated 
   by the instrument software or the converter, 
   and should say so with an according <dataProcessing> element.

2) If the calibration spectra are included in the raw data,
   either interleaved with the other spectra, or e.g. at the end 
   of the chromatographic run. They SHOULD be flagged as such, 
   because the could interfere with other processing steps. 
   This can be done with the CV parameter "calibration spectrum". 
   The value of this CV parameter usually describes the calibrant.

[Term]
id: MS:1000XXX
name: calibration spectrum
def: "Spectrum measured from known substance(s), to recalibrate other spectra in the measurement" [PSI:MS]
synonym: "lockmass spectrum" EXACT []
is_a: MS:1000499 ! spectrum attribute

3) Can someone with waters experience please suggest CV Terms 
   which are able to handle the waters functions ? I have no experience here.

Yours,
Steffen




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

Re: [Psidev-ms-dev] What to do about <RetentionTimeList>?

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

Hi everyone, after a discussion at today's call, we came to a conclusion
that maybe it would be best to attach the specification of local retention
times to the <Transition> (and <Target>) and all the others to <Peptide> (or
<Compound>). So we propose this:



<Peptide id="ADTHFLLNIYDQLR-M1" sequence="ADTHFLLNIYDQLR">

  <cvParam cvRef="MS" accession="MS:1000891" name="heavy labeled peptide"/>

  <cvParam cvRef="MS" accession="MS:1000893" name="peptide group label"
value="1"/>

  <ProteinRef ref="Q12149"/>

  <ProteinRef ref="ENSP00000332698"/>

  <RetentionTimeList>

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

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

    <!-- Local retention time moved below -->

  </RetentionTimeList>

</Peptide>



...



<Transition id="ADTHFLLNIYDQLR-M1-T1" peptideRef="ADTHFLLNIYDQLR-M1">

  <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:1000916" name="retention time window
lower offset" value="3.0" unitCvRef="UO" unitAccession="UO:0000031"
unitName="minute"/>

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

  </RetentionTime>

  <Precursor>

    <cvParam cvRef="MS" accession="MS:1000827" name="isolation window target
m/z" value="862.9467" unitCvRef="MS" unitAccession="MS:1000040"
unitName="m/z"/>

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

  </Precursor>

  ...

</Transition>



We would then enforce that the only <RetentionTime> specified under
<Transition> would be local retention time and there could only be one of
them. The same applies to <Target>.



It is true that if one has 5 transitions for 1 peptide, then one would need
to repeat the retention time 5 times. Perhaps a very small price to pay.



Presumably we would then explicitly disallow local retention time under
<Peptide>? Previously we did not explicitly prevent multiple local retention
times. This scheme would prevent that. Good or bad?



Thoughts on this proposed change?



Thanks,

Eric













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

> From: Fredrik Levander [mailto:fre...@im...]

> Sent: Tuesday, January 19, 2010 7:47 AM

> To: Mass spectrometry standard development

> Subject: Re: [Psidev-ms-dev] What to do about <RetentionTimeList>?

>

> I tend to agree with C too (even if is the least pretty solution). For

> inclusion lists and exclusion lists, there are several examples when

> the

> compund is not known, and in those cases it makes more sense to specify

> local retention time under <target>. For example Hoopmann et al 2009 in

> JPR.

> I cannot make the call today either.

>

> cheers

>

> Fredrik

>

> Andreas Bertsch skrev:

> > Hi all,

> >

> >

> >> one TraML issue that really does need to be solved is what to do

> about retention time.

> >>

> >> Currently, we have a <RetentionTimeList> structure that I think is

> quite nice, but it can only live under <Peptide> or <Compound>. The

> thinking was that the retention time is really an attribute of a

> peptide or compound rather than a transition, and should therefore ride

> with those. We also felt good about this because if there are multiple

> transitions per peptide (a common occurrence I would say), we only need

> to specify the information once. The tricky use case is a simple

> transition list that has just Q1, Q3, RT and nothing else. Maybe we

> don’t even know what the peptide or compound is. One could encode that

> now by setting up fake peptides as containers of the RT information.

> The sequence is a required attribute, so one would need to assign a

> sequence (like “UNKNOWN” perhaps). One could also imagine some

> diabolical case where one would want to specify a longer retention time

> window for 1 transition than another, both from the same peptide. If we

> wanted to support this kind of a list, we could fix this by allowing

> <RetentionTimeList> under <Transition> as well or instead.

> >>

> >> What do you think?

> >> A) Keep as is and insist that if RT is specified, one must specify

> the peptide or compound (might require data generators to insert false

> <Peptide> placeholders when the true peptide/compound is not known or

> should not be divulged; one might argue that if this strange case

> applies, the list will likely be useless to anyone else, so why bother

> with TraML)

> >> B) Move <RetentionTimeList> to <Transition> (increases flexibility

> for a few cases, but also increases redundancy in most cases)

> >> C) Also allow <RetentionTimeList> under <Transition> (allows

> flexibility for the few cases, and does not increase redundancy, but

> requires more complex software logic to allow a <Transition>

> <RetentionTimeList> to override its possible associated <Peptide>

> <RetentionTimeList>)

> >> And as touched on before, this same exact issue applies to the

> <Target> as well. It is even perhaps more problematic, because I would

> imagine that an inclusion list is even more likely to not have a known

> associated peptide than a transition.

> >> Comments?

> >>

> > Even though, it complicates the software processing of the files, I

> would prefer C), because it truly allows the specification of own

> retention times (and also windows) for each of the entries (transitions

> or inclusions/exclusions). I can think of several cases where this

> might be useful. This solution also would allow "unknown" compounds to

> be encoded in TraML. (Even conversion from tsv/csv file formats to

> TraML would be possible!).

> >

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

> >

> >

> >

> >

> >

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

> ---------

> > Throughout its 18-year history, RSA Conference consistently attracts

> the

> > world's best and brightest in the field, creating opportunities for

> Conference

> > attendees to learn about information security's most important issues

> through

> > interactions with peers, luminaries and emerging and established

> companies.

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

> > _______________________________________________

> > Psidev-ms-dev mailing list

> > Psi...@li...

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

> >

>

>

>

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

> -------

> Throughout its 18-year history, RSA Conference consistently attracts

> the

> world's best and brightest in the field, creating opportunities for

> Conference

> attendees to learn about information security's most important issues

> through

> interactions with peers, luminaries and emerging and established

> companies.

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

> _______________________________________________

> Psidev-ms-dev mailing list

> Psi...@li...

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

Re: [Psidev-ms-dev] What to do about <RetentionTimeList>?

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

I tend to agree with C too (even if is the least pretty solution). For 
inclusion lists and exclusion lists, there are several examples when the 
compund is not known, and in those cases it makes more sense to specify 
local retention time under <target>. For example Hoopmann et al 2009 in JPR.
I cannot make the call today either.

cheers

Fredrik

Andreas Bertsch skrev:
> Hi all,
>
>   
>> one TraML issue that really does need to be solved is what to do about retention time.
>>  
>> Currently, we have a <RetentionTimeList> structure that I think is quite nice, but it can only live under <Peptide> or <Compound>. The thinking was that the retention time is really an attribute of a peptide or compound rather than a transition, and should therefore ride with those. We also felt good about this because if there are multiple transitions per peptide (a common occurrence I would say), we only need to specify the information once. The tricky use case is a simple transition list that has just Q1, Q3, RT and nothing else. Maybe we don’t even know what the peptide or compound is. One could encode that now by setting up fake peptides as containers of the RT information. The sequence is a required attribute, so one would need to assign a sequence (like “UNKNOWN” perhaps). One could also imagine some diabolical case where one would want to specify a longer retention time window for 1 transition than another, both from the same peptide. If we wanted to support this kind of a list, we could fix this by allowing <RetentionTimeList> under <Transition> as well or instead.
>>  
>> What do you think?
>> A) Keep as is and insist that if RT is specified, one must specify the peptide or compound (might require data generators to insert false <Peptide> placeholders when the true peptide/compound is not known or should not be divulged; one might argue that if this strange case applies, the list will likely be useless to anyone else, so why bother with TraML)
>> B) Move <RetentionTimeList> to <Transition> (increases flexibility for a few cases, but also increases redundancy in most cases)
>> C) Also allow <RetentionTimeList> under <Transition> (allows flexibility for the few cases, and does not increase redundancy, but requires more complex software logic to allow a <Transition> <RetentionTimeList> to override its possible associated <Peptide> <RetentionTimeList>)
>> And as touched on before, this same exact issue applies to the <Target> as well. It is even perhaps more problematic, because I would imagine that an inclusion list is even more likely to not have a known associated peptide than a transition. 
>> Comments?
>>     
> Even though, it complicates the software processing of the files, I would prefer C), because it truly allows the specification of own retention times (and also windows) for each of the entries (transitions or inclusions/exclusions). I can think of several cases where this might be useful. This solution also would allow "unknown" compounds to be encoded in TraML. (Even conversion from tsv/csv file formats to TraML would be possible!).
>
> 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
>
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] What to do about <RetentionTimeList>?

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

Hi Matt,

> Isn't that partly why we have the Compound element? Can you think of a 
> use case where transitions would have retention time without being able 
> to associate them with some "unknown" compound element?
True, this would be even the better way I think. However, it does not solve the problem if two transitions (or include/exclusion entries) refer to the same compound/peptide but which should have different RTs or retention time windows. 

Cheers,
A.


>> Even though, it complicates the software processing of the files, I 
>> would prefer C), because it truly allows the specification of own 
>> retention times (and also windows) for each of the entries 
>> (transitions or inclusions/exclusions). I can think of several cases 
>> where this might be useful. This solution also would allow "unknown" 
>> compounds to be encoded in TraML. (Even conversion from tsv/csv file 
>> formats to TraML would be possible!).

--
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] What to do about <RetentionTimeList>?

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

Isn't that partly why we have the Compound element? Can you think of a 
use case where transitions would have retention time without being able 
to associate them with some "unknown" compound element?

-Matt


Andreas Bertsch wrote:
> Hi all,
>
>   
> Even though, it complicates the software processing of the files, I 
> would prefer C), because it truly allows the specification of own 
> retention times (and also windows) for each of the entries 
> (transitions or inclusions/exclusions). I can think of several cases 
> where this might be useful. This solution also would allow "unknown" 
> compounds to be encoded in TraML. (Even conversion from tsv/csv file 
> formats to TraML would be possible!).
> Cheers,
> A.
>
>   

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

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

Hi everyone,

> the next PSI Mass Spectrometry Standards Working Group call will be Tuesday 8am PDT: 
Unfortunately, I will not make it to the call today.

> 1) mzML 1.1.0
> - Manuscript now in active preparation
> - Matt will release updated 1.1.1 of indexedmzML schema: <indexList> name attribute will be enumerated to “spectrum” or “chromatogram”
> - Matt will update the example files to reference mzML 1.1.0 but indexedmzML 1.1.1
> - Andreas will add “Replaced-by” field to the obsoleted MaRiMba term
Done, committed with revision 1.131.

> - Matt added new terms for ABI TOF/TOF T2D file format
> - How do we handle lock mass corrections? Matt will make an example
> - Other items?

> 3) TraML development
> - Current version 0.9.3 is available at http://www.psidev.info/index.php?q=node/405
> - Matt suggest changing "frag: y ion" to "product: y ion"
> - But Andreas points out that the “frag” is supposed to differentiate search parameter from resulting
> - Andreas will rephrase all the definitions for “frag: y ion” to be better
Rephrased frag ion term definitions to e.g. " def: "Fragmentation information, type of product: y ion." [PSI:PI]" (revision 1.131). The OpenMS Validator is up-to-date (0.9.3). The OpenMS implementation supports the important things encoded in the format (reading and writing).

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] What to do about <RetentionTimeList>?

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

Hi all,

> one TraML issue that really does need to be solved is what to do about retention time.
>  
> Currently, we have a <RetentionTimeList> structure that I think is quite nice, but it can only live under <Peptide> or <Compound>. The thinking was that the retention time is really an attribute of a peptide or compound rather than a transition, and should therefore ride with those. We also felt good about this because if there are multiple transitions per peptide (a common occurrence I would say), we only need to specify the information once. The tricky use case is a simple transition list that has just Q1, Q3, RT and nothing else. Maybe we don’t even know what the peptide or compound is. One could encode that now by setting up fake peptides as containers of the RT information. The sequence is a required attribute, so one would need to assign a sequence (like “UNKNOWN” perhaps). One could also imagine some diabolical case where one would want to specify a longer retention time window for 1 transition than another, both from the same peptide. If we wanted to support this kind of a list, we could fix this by allowing <RetentionTimeList> under <Transition> as well or instead.
>  
> What do you think?
> A) Keep as is and insist that if RT is specified, one must specify the peptide or compound (might require data generators to insert false <Peptide> placeholders when the true peptide/compound is not known or should not be divulged; one might argue that if this strange case applies, the list will likely be useless to anyone else, so why bother with TraML)
> B) Move <RetentionTimeList> to <Transition> (increases flexibility for a few cases, but also increases redundancy in most cases)
> C) Also allow <RetentionTimeList> under <Transition> (allows flexibility for the few cases, and does not increase redundancy, but requires more complex software logic to allow a <Transition> <RetentionTimeList> to override its possible associated <Peptide> <RetentionTimeList>)
> And as touched on before, this same exact issue applies to the <Target> as well. It is even perhaps more problematic, because I would imagine that an inclusion list is even more likely to not have a known associated peptide than a transition. 
> Comments?
Even though, it complicates the software processing of the files, I would prefer C), because it truly allows the specification of own retention times (and also windows) for each of the entries (transitions or inclusions/exclusions). I can think of several cases where this might be useful. This solution also would allow "unknown" compounds to be encoded in TraML. (Even conversion from tsv/csv file formats to TraML would be possible!).

Cheers,
A.




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

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

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

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

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=19
<http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=1&year=20
10&hour=16&min=0&sec=0&p1=136> &month=1&year=2010&hour=16&min=0&sec=0&p1=136

 

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)

 

access code: 297427 #

 

Agenda:

1) mzML 1.1.0

- Manuscript now in active preparation

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

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

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

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

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

- Other items?

 

----

2) MIAPE-MS revision

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

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

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

 

----

3) TraML development

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

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

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

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

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

- Andreas also sent out an example

- What do we do about specifying retention times, i.e. where to allow
<RetentionTimeList> (see 1/14)

- Do we try to merge <Transition> and <Target>?

- Implementations?

  - Matt will implement in ProteoWizard

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

  - ISB implementation in ATAQS nearly done

  - Jim will implement as a test

  - David Cox at Sciex will test implement?

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

 

 

[Psidev-ms-dev] What to do about <RetentionTimeList>?

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

Hi everyone, one TraML issue that really does need to be solved is what to
do about retention time.



Currently, we have a <RetentionTimeList> structure that I think is quite
nice, but it can only live under <Peptide> or <Compound>. The thinking was
that the retention time is really an attribute of a peptide or compound
rather than a transition, and should therefore ride with those. We also felt
good about this because if there are multiple transitions per peptide (a
common occurrence I would say), we only need to specify the information
once. The tricky use case is a simple transition list that has just Q1, Q3,
RT and nothing else. Maybe we don’t even know what the peptide or compound
is. One could encode that now by setting up fake peptides as containers of
the RT information. The sequence is a required attribute, so one would need
to assign a sequence (like “UNKNOWN” perhaps). One could also imagine some
diabolical case where one would want to specify a longer retention time
window for 1 transition than another, both from the same peptide. If we
wanted to support this kind of a list, we could fix this by allowing
<RetentionTimeList> under <Transition> as well or instead.



What do you think?

A) Keep as is and insist that if RT is specified, one must specify the
peptide or compound (might require data generators to insert false <Peptide>
placeholders when the true peptide/compound is not known or should not be
divulged; one might argue that if this strange case applies, the list will
likely be useless to anyone else, so why bother with TraML)

B) Move <RetentionTimeList> to <Transition> (increases flexibility for a few
cases, but also increases redundancy in most cases)

C) Also allow <RetentionTimeList> under <Transition> (allows flexibility for
the few cases, and does not increase redundancy, but requires more complex
software logic to allow a <Transition> <RetentionTimeList> to override its
possible associated <Peptide> <RetentionTimeList>)



And as touched on before, this same exact issue applies to the <Target> as
well. It is even perhaps more problematic, because I would imagine that an
inclusion list is even more likely to not have a known associated peptide
than a transition.



Comments?



Would elution time be a better term than retention time?



Thanks,

Eric

Re: [Psidev-ms-dev] Is a <transition> a <target> with an additional <product> ?

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

Hi Steffen, Andreas, Fredrik, et al. thank you for this discussion on
Steffen's proposal. The history here is that we set out to create a format
for transitions only. The primary use cases all were for SRM experiments.
This has not yet been clearly written in the spec doc as you noted. But
then it was suggested that we could easily add inclusion/exclusion lists
as well. It seemed unclear to me that there would be much interest in
sharing inclusion lists (in my mind, transition lists have great reuse
potential, but inclusion lists far less so), but it seemed reasonable to
add this on to permit certain additional use cases as there was no
alternative and this would be the closest similar format. However, I, too,
am hesitant to complicate the <transition> design (and hinder validation,
e.g. how do you prevent transitions with no Q3 value?) by trying to fit
this additional potential use case into our current design.

Steffen, thank you for writing the use case section. I will insert this
into the spec doc and perhaps expand on it a bit.

If there are addition comments, please do speak up. Let's also entertain
this idea bit more on Tuesday's phone conference.

Thanks,
Eric


> -----Original Message-----
> From: Steffen Neumann [mailto:sne...@ip...]
> Sent: Wednesday, January 13, 2010 5:52 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Is a <transition> a <target> with an
> additional <product> ?
>
> On Wed, 2010-01-13 at 13:12 +0100, Andreas Bertsch wrote:
> > I agree with Fredrik. The costs for the simplifications are too high.
> Yes, it's not for free :-(
>
> > Separating the targets and transitions seems reasonable to me,
> because
> > these are to very different things.
> Are they ?
>
> Analytically yes, because you program the MS machine
> in different ways, either (auto-)MS/MS or SRM.
>
> Conceptionally no, because if I have observed a pair
> of precursor/product ions and use that as a hint that
> the predicted interpretation is true, no matter whether
> you have measured that by SRM or a normal QQQ
> or QqTOF tandemMS experiment. Granted, only the <precursor>
> information will not be enough for a usable <interpretation>.
>
> On the other hand, to analyse a normal tandemMS experiment,
> you could even specify multiple <product>s for one precursor,
> which you require for a sufficiently confident peptideRef="ABC".
> (If I saw that correctly from the traML schema, the current approach
>  is to create multiple <transition> to hold multiple <product>s)
>
> Again, I think I can be persuaded/convinced if there
> is a definition of use case(s) for traML, and my ideas
> fall well outside of it. Has anyone start that already ?
>
> > The subelements are reused for both of the lists, which is I think a
> > good trade-off between a light-weight schema and straight-forward
> > structure.
> And that even allows the mapping file to distinguish between
> a retention time inside a <transition> vs. a retention time
> in a <target>. But that should not be the main point.
>
> Yours,
> Steffen
>
> --
> IPB Halle                    AG Massenspektrometrie & Bioinformatik
> Dr. Steffen Neumann          http://www.IPB-Halle.DE
> Weinberg 3                   http://msbi.bic-gh.de
> 06120 Halle                  Tel. +49 (0) 345 5582 - 1470
>                                   +49 (0) 345 5582 - 0
> sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409
>
>
> -----------------------------------------------------------------------
> -------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Use Cases for traML

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

Hi,

after dwelling so much about use cases, here's what I can come up with,
guessing from the schema and some of my ideas, 
as a discussion base on this list and for the next telco.

Yours,
Steffen

1.3 Use cases
=============

[ - Mention TSV formats... ]

TraML is designed as a format to keep information needed to 
configure and perform MS experiments. This includes SRM/MRM experiments,
especially for quantitation, and MS/MS experiments e.g. for
identification.

1) A quantitation experiment is typically performed on a set 
of known proteins or compounds, and for each the instrument 
measures one or more transitions (defined as precursor/product pairs)
are measured. 

The definition for transitions have to be created 
(retrieved from spectral libraries or predicted from sequences) 
by external software. Information how those were predicted 
is stored as well.

Those transitions MAY be validated (measured) on one 
or more instruments, and the analytical configuration(s) 
are stored with the transition.

The TraML documents can be translated into vendor-dependent 
files suitable to create/configure an SRM/MRM experiment 
on a Triple-Quad, Ion Trap or other suitable mass spectrometer
using external software. Ideally, the machine configuration 
can be obtained or derived from the set of validated transitions.

2) A TraML file can describe an MS/MS experiment 
via the specification of targets as retention time windows 
and precursor mass both through inclusion- and exclusion lists.

The definition for targets for the inclusion/exclusion lists 
have to be created based on a preselection of known 
(un-)desired compounds or proteins retrieved from databases,
or (potentially unidentified) precursor mass and retention time windows 
measured during preceding profiling experiments.
In case of known proteins and compounds, they are annotated as well.

The TraML documents can then be translated into vendor-dependent 
files suitable to create/configure an MS/MS experiment 
on a Triple-Quad, QqTOF, Ion Trap other suitable mass spectrometer. 
Ideally, the machine configuration can be obtained or derived from the
set of validated transitions.

The list of targets is unrelated to the list of transitions,
and often only one of them is populated [True ?].

There will be limited support for the following use cases:
----------------------------------------------------------

The following use cases will not be supported in version 1 of TraML:
--------------------------------------------------------------------

- A TraML file can not describe neutral loss scans
  (We don't want to have <neutralLoss> as alternative 
  to the <precursor><product> pair...)

- A TraML file can not describe arbitrary MS^n experiments where n >= 3.
  (We don't want nested <transitions> ...)

[But actually both would be desirable for a later revision,
 if TraML aims at describing MS experiments !]

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

Re: [Psidev-ms-dev] Is a <transition> a <target> with an additional <product> ?

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

On Wed, 2010-01-13 at 13:12 +0100, Andreas Bertsch wrote:
> I agree with Fredrik. The costs for the simplifications are too high.
Yes, it's not for free :-(

> Separating the targets and transitions seems reasonable to me, because
> these are to very different things.
Are they ? 

Analytically yes, because you program the MS machine 
in different ways, either (auto-)MS/MS or SRM.

Conceptionally no, because if I have observed a pair 
of precursor/product ions and use that as a hint that 
the predicted interpretation is true, no matter whether 
you have measured that by SRM or a normal QQQ 
or QqTOF tandemMS experiment. Granted, only the <precursor> 
information will not be enough for a usable <interpretation>.

On the other hand, to analyse a normal tandemMS experiment,
you could even specify multiple <product>s for one precursor,
which you require for a sufficiently confident peptideRef="ABC".
(If I saw that correctly from the traML schema, the current approach
 is to create multiple <transition> to hold multiple <product>s)

Again, I think I can be persuaded/convinced if there 
is a definition of use case(s) for traML, and my ideas 
fall well outside of it. Has anyone start that already ?

> The subelements are reused for both of the lists, which is I think a
> good trade-off between a light-weight schema and straight-forward
> structure.
And that even allows the mapping file to distinguish between 
a retention time inside a <transition> vs. a retention time 
in a <target>. But that should not be the main point.

Yours,
Steffen

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

Re: [Psidev-ms-dev] Is a <transition> a <target> with an additional <product> ?

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

On Wed, 2010-01-13 at 11:47 +0100, Fredrik Levander wrote:
> InterpretationList/Interpretation, now part of  Transition, would be 
> explaining different things for included ions and transitions, though.
The <nterpretation> would move into <product> then, 
because really it's describing the <precursor>:<product> interpretation.

> Even if such a change would simplify the XML schema which is good, I am 
> afraid that it would make reading of the documents a bit harder - you 
> would still like to distinguish between include targets and transitions.
What kind of format is TraML supposed to be ? The "Use Case" section 
of the documentation is pretty sparse so far. Where in the pipeline 
is TraML ? I'd need to know to avoid asking for something in traML 
it was never intended to do. 

Do you have a list of possible proteins/peptides you want to 
look for / quantitate ? And hence create a <transition> 
to be imported/converted into the machine software 
to run the SRM experiment ? So traML describes the settings 
for RT,Q1,Q3.  

With separate <transition> and <target>
there is a strong hint that it is designed for SRM capable 
machines only, i.e. *not* for QTOF. 

> Or are there any other practical advantages with merging of the two? 
With a unified <target> traML you can describe RT,Q1 and optionally Q3.
It'd make a much more universal description of MS experiments. 

> Note that targets in 
> the include list can already be annotated with peptide information - 
> actually they have to be, in order to have a retention time.
Which is another thing that struck me, why do I need 
the peptide information to store a retention time ? 

Depending on the Use Case I don't have peptide/compound information,
it might be that I am actually making the MSMS experiment 
to obtain that!

Yours,
Steffen



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

Re: [Psidev-ms-dev] Is a <transition> a <target> with an additional <product> ?

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

Hi Steffen,

I agree with Fredrik. The costs for the simplifications are too high. Separating the targets and transitions seems reasonable to me, because these are to very different things. The subelements are reused for both of the lists, which is I think a good trade-off between a light-weight schema and straight-forward structure.

Cheers,
A.

> I think your suggestion is fine and should be working. 
> InterpretationList/Interpretation, now part of  Transition, would be 
> explaining different things for included ions and transitions, though.
> 
> Even if such a change would simplify the XML schema which is good, I am 
> afraid that it would make reading of the documents a bit harder - you 
> would still like to distinguish between include targets and transitions, 
> I believe.  So in the end the current representation with separate 
> transition and target elements seems preferable to me. Or are there any 
> other practical advantages with merging of the two? Note that targets in 
> the include list can already be annotated with peptide information - 
> actually they have to be, in order to have a retention time.
>> 
>> maybe this suggestion drowned in the mail traffic 
>> that had accumulated over the holidays, 
>> so I'll bring this up again. 
>> 
>> The suggestion is to merge <transition> and <target>
>> into a single concept <target>, where the <product> is optional.
>> 
>> Comments ?
>>> this might be a bit provocative, but why are <transition> 
>>> and <target> separated ? 
>>> 
>>> Why not rename <transition> to <target>,
>>> and make the <product> optional ? This comes from 
>>> somebody who thinks of an MRM experiment 
>>> as a "degraded" tandemMS measurement (no offense meant).
>>> 
>>> If you run tandemMS on peptides, you might still 
>>> want to annotate the <TargetIncludeList> with 
>>> peptides etc, just as now the <transition>s.
>>> 
>>> To get rid of the multiple toplevel <*List>
>>> one could have a <TargetList role="include|exclude">,
>>> and the <TargetList> could have maxOccurs=2,
>>> but that could make life more difficult 
>>> for the semantic validators.

--
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] Is a <transition> a <target> with an additional <product> ?

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

Hi Steffen,

I think your suggestion is fine and should be working. 
InterpretationList/Interpretation, now part of  Transition, would be 
explaining different things for included ions and transitions, though.

Even if such a change would simplify the XML schema which is good, I am 
afraid that it would make reading of the documents a bit harder - you 
would still like to distinguish between include targets and transitions, 
I believe.  So in the end the current representation with separate 
transition and target elements seems preferable to me. Or are there any 
other practical advantages with merging of the two? Note that targets in 
the include list can already be annotated with peptide information - 
actually they have to be, in order to have a retention time.

Thanks

Fredrik


Steffen Neumann wrote:
> Hi,
>
> maybe this suggestion drowned in the mail traffic 
> that had accumulated over the holidays, 
> so I'll bring this up again. 
>
> The suggestion is to merge <transition> and <target>
> into a single concept <target>, where the <product> is optional.
>
> Comments ?
>
> Yours,
> Steffen
>
> On Tue, 2010-01-05 at 23:09 +0100, Steffen Neumann wrote:
>   
>> Hi,
>>
>> this might be a bit provocative, but why are <transition> 
>> and <target> separated ? 
>>
>> Why not rename <transition> to <target>,
>> and make the <product> optional ? This comes from 
>> somebody who thinks of an MRM experiment 
>> as a "degraded" tandemMS measurement (no offense meant).
>>
>> If you run tandemMS on peptides, you might still 
>> want to annotate the <TargetIncludeList> with 
>> peptides etc, just as now the <transition>s.
>>
>> To get rid of the multiple toplevel <*List>
>> one could have a <TargetList role="include|exclude">,
>> and the <TargetList> could have maxOccurs=2,
>> but that could make life more difficult 
>> for the semantic validators.
>>
>> Yours,
>> Steffen
>>
>>     
>
>
>   

Re: [Psidev-ms-dev] Is a <transition> a <target> with an additional <product> ?

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

Hi,

maybe this suggestion drowned in the mail traffic 
that had accumulated over the holidays, 
so I'll bring this up again. 

The suggestion is to merge <transition> and <target>
into a single concept <target>, where the <product> is optional.

Comments ?

Yours,
Steffen

On Tue, 2010-01-05 at 23:09 +0100, Steffen Neumann wrote:
> Hi,
> 
> this might be a bit provocative, but why are <transition> 
> and <target> separated ? 
> 
> Why not rename <transition> to <target>,
> and make the <product> optional ? This comes from 
> somebody who thinks of an MRM experiment 
> as a "degraded" tandemMS measurement (no offense meant).
> 
> If you run tandemMS on peptides, you might still 
> want to annotate the <TargetIncludeList> with 
> peptides etc, just as now the <transition>s.
> 
> To get rid of the multiple toplevel <*List>
> one could have a <TargetList role="include|exclude">,
> and the <TargetList> could have maxOccurs=2,
> but that could make life more difficult 
> for the semantic validators.
> 
> Yours,
> Steffen
> 


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

Re: [Psidev-ms-dev] Missed PSI-MS WG call - my fault

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

Dear Lennart, your contribution to the group has been very important to
getting mzML finished and implemented and we are grateful for your efforts.
We, of course, understand that your new position requires a lot of time, and
your stepping down gives us an opportunity to promote someone with more time
to devote to the working group. We certainly welcome, and indeed hope for,
your continued participation in our efforts.

No worries on the phone conference.

Best regards,
Eric


On Wed, Jan 6, 2010 at 12:40 AM, Lennart Martens
<len...@ug...>wrote:

> Dear PSI-MS Enthusiasts,
>
>
> The missed call yesterday is entirely my fault, and I very humbly
> apologize.
>
> I failed to pick up on Eric's email in time, and since the extremely
> efficient back-up people at EBI are still on holiday, this time there
> was nobody to cover for my obvious mistake.
>
> With that said, I think I have to draw the right conclusions and step
> down as secretary of the PSI-MS Working Group - I have to admit that I
> have been nearly completely useless for the past few months anyway.
>
> I'm very happy to have had the opportunity to help further the
> development and release of mzML, and I think the entire workgroup can be
> very proud of this achievement! Furthermore, ongoing work on TraML
> promises to continue this success story! I still intend to work with
> Eric to get an mzML manuscript draft ready for all of you to comment on,
> as I feel that I should at least finish this task before fully
> chickening out.
>
> But I guess that meanwhile you guys need to pick a new secretary, to get
> things moving again for you. As I said above, I'm afraid I've become
> little more than dead weight to the group over the last few months.
>
> I'll of course continue to eavesdrop on this list, and will contribute
> where possible in the future, but most likely through people in my group
> rather than contributing directly (which is probably for the best :)).
>
>
>
> Sorry once again for the botched phone conference!
>
>
> Cheers,
>
> lnnrt.
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

[Psidev-ms-dev] Missed PSI-MS WG call - my fault

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

Dear PSI-MS Enthusiasts,


The missed call yesterday is entirely my fault, and I very humbly apologize.

I failed to pick up on Eric's email in time, and since the extremely 
efficient back-up people at EBI are still on holiday, this time there 
was nobody to cover for my obvious mistake.

With that said, I think I have to draw the right conclusions and step 
down as secretary of the PSI-MS Working Group - I have to admit that I 
have been nearly completely useless for the past few months anyway.

I'm very happy to have had the opportunity to help further the 
development and release of mzML, and I think the entire workgroup can be 
very proud of this achievement! Furthermore, ongoing work on TraML 
promises to continue this success story! I still intend to work with 
Eric to get an mzML manuscript draft ready for all of you to comment on, 
as I feel that I should at least finish this task before fully 
chickening out.

But I guess that meanwhile you guys need to pick a new secretary, to get 
things moving again for you. As I said above, I'm afraid I've become 
little more than dead weight to the group over the last few months.

I'll of course continue to eavesdrop on this list, and will contribute 
where possible in the future, but most likely through people in my group 
rather than contributing directly (which is probably for the best :)).



Sorry once again for the botched phone conference!


Cheers,

lnnrt.

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

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

Hi Andreas, Fredrik, Steffen, et al. thank you for updating, examining,
and posting these problems.

I have just updated the various files for TraML 0.9.3 (forgive me for not
increasing the version number)

Changes:
- Added many datatype definitions to the CV
- Fixed attribute 'unitcvRef' to 'unitCvRef' for consistency
- Updated the documentation based on Steffen's comments. Note that the
documentation still has unfinished parts.

Open issues:
- Steffen mentioned retention time for inclusion lists. This may still be
a problem. Targets may refer to peptides and peptides may have retention
time information. However, the use case where one has an inclusion list
without reference to a peptide still does not allow a retention time. We
probably need to think about that some more.

So, please update and examine the latest posted files.

Thank you!
Eric


> -----Original Message-----
> From: Andreas Bertsch [mailto:be...@in...]
> Sent: Tuesday, January 05, 2010 3:58 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] TraML 0.9.3 draft released
>
> Hi Eric,
>
> > Hi everyone, TraML version 0.9.3 has been posted at the development
> web page:
> >
> > http://www.psidev.info/index.php?q=node/405
> >
> > The links to HTML documentation and examples files are all updated.
> >
> > Please examine the materials and respond.
> >
> > Major changes from 0.9.2:
> > - Elements CvList, Cv, CvParam now begin with lower case letter
> following mzIdentML
> > - Precursor and Product m/z values now specified with MS:1000827
> > - Interpretation elements no longer have primary= attribute but have
> required MS:1000926 attribute
> > - All elements now have a complexType definition
> > - I have attempted to use keys and keyRefs although they don't seem
> to be working
> >
> > Please update your implementations and example files and validators
> and report.
> I have updated the definitions of the fragmentation information terms
> and added the 'replaced_by' field to the obsoleted MaRiMba term in the
> ontology file. The OpenMS validator is also up to date. Unfortunately,
> it now reports more errors, concerning allowed values of some CV terms.
> Most of them should be added (Remember if the psi-ms.obo file contains
> a xref with the value-type the value MUST be present, and MUST NOT
> otherwise). I added value-types to the terms reported by Fredrik.
>
> - The attribute 'unitcvRef' should be 'unitCvRef', as it is in mzML and
> mzIdentML
> - Value-type fields should be added to some terms, I can fix that if
> you want.
>
> Unfortunately, I will not be able to attend the call today.
>
> 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
>
>
>
>
>
> -----------------------------------------------------------------------
> -------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Is a <transition> a <target> with an additional <product> ?

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

Hi,

this might be a bit provocative, but why are <transition> 
and <target> separated ? 

Why not rename <transition> to <target>,
and make the <product> optional ? This comes from 
somebody who thinks of an MRM experiment 
as a "degraded" tandemMS measurement (no offense meant).

If you run tandemMS on peptides, you might still 
want to annotate the <TargetIncludeList> with 
peptides etc, just as now the <transition>s.

To get rid of the multiple toplevel <*List>
one could have a <TargetList role="include|exclude">,
and the <TargetList> could have maxOccurs=2,
but that could make life more difficult 
for the semantic validators.

Yours,
Steffen

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

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

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

On Tue, 2010-01-05 at 00:12 -0800, Eric Deutsch wrote:

> Please examine the materials and respond.

- The header line still refers to 0.9.2
- The documents mentions analysisXML in 2.2, 
  with an invalid URL.

- <Target> (include and exclude, for that matter) 
  doesn't have the notion of an m/z window:
  1) You might be not interested in everything below 200Da
  2) Depending on the instrument it might be necessary 
  to use broader isolation windows for sufficient 
  product ion intensities.
  
- <Target> (include and exclude, for that matter) 
  doesn't have the notion of <RetentionTime> to 
  (optionally) restrict a RT (window)

- 3.30 says "Precursor (Q1) of the transition" should add "target"

- <configuration> could allow an isolation width, 
  as an alternative to the mz min/max I mentioned above.
  mzML had some lengthy min/max vs. width discussions last year ...

- The name "Tra(nsition)ML" suggests that the format is 
  for (TripleQuad) MRM experiments. For "1.3 Use Cases" I'd like to add
  more explicitly the description of a tandemMS (and MS^n) run.

  To me, TraML can also describe a "method" for an MS run.
  For Bruker QTof, such a description lives in files such as 
  method.m/microTOFQAcquisition.method, but they're (so far)
  quite undocumented.

Yours,
Steffen

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

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

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

Pity about the constant interruptions, though. I doubt a customer services
representative is coming...

Sorry folks, it looks like we can't get the call system started, so we'll
have to postpone the call until another day. I'll follow up with an email.

Thanks,
Eric


> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: Tuesday, January 05, 2010 8:07 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call reminder
>
> At least the wait music is nice.
>
> -Matt
>
>
> Eric Deutsch wrote:
> >
> > Hi everyone, the next PSI Mass Spectrometry Standards Working Group
> > call will be Tuesday 8am PDT:
> >
> >
> >
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?day=5&month=1&year
> =2010&hour=16&min=0&sec=0&p1=136
> >
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=5&month=1&yea
> r=2010&hour=16&min=0&sec=0&p1=136>
> >
> >
> >
> > 08:00 San Francisco
> >
> > 11:00 New York
> >
> > 16:00 London
> >
> > 17:00 Geneva
> >
> >
> >
> > + Germany: 08001012079
> >
> > + Switzerland: 0800000860
> >
> > + UK: 08081095644
> >
> > + USA: 1-866-314-3683
> >
> > Generic international: +44 2083222500 (UK number)
> >
> >
> >
> > access code: 297427 #
> >
> >
> >
> > Agenda:
> >
> > 1) mzML 1.1.0
> >
> > - Manuscript now in active preparation
> >
> > - Matt will release updated 1.1.1 of indexedmzML schema: <indexList>
> > name attribute will be enumerated to "spectrum" or "chromatogram"
> >
> > - Matt will update the example files to reference mzML 1.1.0 but
> > indexedmzML 1.1.1
> >
> > - Andreas will add "Replaced-by" field to the obsoleted MaRiMba term
> >
> > - Matt added new terms for ABI TOF/TOF T2D file format
> >
> > - How do we handle lock mass corrections? Matt will make an example
> >
> > - Other items?
> >
> >
> >
> > ----
> >
> > 2) MIAPE-MS revision
> >
> > - Pierre-Alain has sent out the revised MIAPE-MS draft 2.94 document
> > to the list
> >
> > - Everyone: Please examine MIAPE-MS 2.94 in Pierre-Alain Binz's email
> > on 2009-12-22 and respond with comments
> >
> > - Deadline is Jan 12, after which the document will be submitted to
> > the PSI document process
> >
> >
> >
> > ----
> >
> > 3) TraML development
> >
> > - Current version 0.9.2 is available at
> > http://www.psidev.info/index.php?q=node/405
> >
> > - Version 0.9.3 about to be released
> >
> > - Use Andreas's suggestion to use 'isolation window target m/z',
> > MS:1000827
> >
> > - Eric will update the examples and mapping files for that.
> >
> > - Eric will add term: "product interpretation rank"
> >
> > - Matt suggest changing "frag: y ion" to "product: y ion"
> >
> > - But Andreas points out that the "frag" is supposed to differentiate
> > search parameter from resulting
> >
> > - Andreas will rephrase all the definitions for "frag: y ion" to be
> better
> >
> > - Eric made a change to the 0.9.2 schema to make all elements be a
> > complexType definition
> >
> > - Eric will release 0.9.3 as soon as these other additions are made
> >
> > - Eric is having a problem with keys and keyrefs. They're  not being
> > enforced
> >
> > - Eric will send the problem to Matt who will look at it
> >
> > - Fredrik sent out an inclusion list example. Everyone look and
> comment.
> >
> > - Fredrik did use the 'isolation window target m/z' term. Update
> > mapping file
> >
> > - Andreas also sent out an example
> >
> > - Address Andreas's suggestions in his email
> >
> > - Matt asks if we should use lowercase CvParam like mzIdentML? Seems
> > like consensus to change CvParam -> cvParam, UserParam -> userParam
> >
> > - Eric will send out new version 0.9.3
> >
> > - Implementations?
> >
> >   - Matt will implement in ProteoWizard
> >
> >   - Andreas will implement in OpenMS and update on-line validator
> >
> >   - ISB implementation in ATAQS nearly done
> >
> >   - Jim will implement as a test
> >
> >   - David Cox at Sciex will test implement?
> >
> > - Are we ready to update validator page?:
> > http://www.psidev.info/index.php?q=node/304
> >
> >
> >
> >
> >
>
> -----------------------------------------------------------------------
> -------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

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

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

At least the wait music is nice.

-Matt


Eric Deutsch wrote:
>
> Hi everyone, the next PSI Mass Spectrometry Standards Working Group 
> call will be Tuesday 8am PDT:
>
>  
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=5&month=1&year=2010&hour=16&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=5&month=1&year=2010&hour=16&min=0&sec=0&p1=136>
>
>  
>
> 08:00 San Francisco
>
> 11:00 New York
>
> 16:00 London
>
> 17:00 Geneva
>
>  
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-314-3683
>
> Generic international: +44 2083222500 (UK number)
>
>  
>
> access code: 297427 #
>
>  
>
> Agenda:
>
> 1) mzML 1.1.0
>
> - Manuscript now in active preparation
>
> - Matt will release updated 1.1.1 of indexedmzML schema: <indexList> 
> name attribute will be enumerated to “spectrum” or “chromatogram”
>
> - Matt will update the example files to reference mzML 1.1.0 but 
> indexedmzML 1.1.1
>
> - Andreas will add “Replaced-by” field to the obsoleted MaRiMba term
>
> - Matt added new terms for ABI TOF/TOF T2D file format
>
> - How do we handle lock mass corrections? Matt will make an example
>
> - Other items?
>
>  
>
> ----
>
> 2) MIAPE-MS revision
>
> - Pierre-Alain has sent out the revised MIAPE-MS draft 2.94 document 
> to the list
>
> - Everyone: Please examine MIAPE-MS 2.94 in Pierre-Alain Binz’s email 
> on 2009-12-22 and respond with comments
>
> - Deadline is Jan 12, after which the document will be submitted to 
> the PSI document process
>
>  
>
> ----
>
> 3) TraML development
>
> - Current version 0.9.2 is available at 
> http://www.psidev.info/index.php?q=node/405
>
> - Version 0.9.3 about to be released
>
> - Use Andreas’s suggestion to use 'isolation window target m/z', 
> MS:1000827
>
> - Eric will update the examples and mapping files for that.
>
> - Eric will add term: “product interpretation rank”
>
> - Matt suggest changing "frag: y ion" to "product: y ion"
>
> - But Andreas points out that the “frag” is supposed to differentiate 
> search parameter from resulting
>
> - Andreas will rephrase all the definitions for “frag: y ion” to be better
>
> - Eric made a change to the 0.9.2 schema to make all elements be a 
> complexType definition
>
> - Eric will release 0.9.3 as soon as these other additions are made
>
> - Eric is having a problem with keys and keyrefs. They’re  not being 
> enforced
>
> - Eric will send the problem to Matt who will look at it
>
> - Fredrik sent out an inclusion list example. Everyone look and comment.
>
> - Fredrik did use the 'isolation window target m/z' term. Update 
> mapping file
>
> - Andreas also sent out an example
>
> - Address Andreas’s suggestions in his email
>
> - Matt asks if we should use lowercase CvParam like mzIdentML? Seems 
> like consensus to change CvParam -> cvParam, UserParam -> userParam
>
> - Eric will send out new version 0.9.3
>
> - Implementations?
>
>   - Matt will implement in ProteoWizard
>
>   - Andreas will implement in OpenMS and update on-line validator
>
>   - ISB implementation in ATAQS nearly done
>
>   - Jim will implement as a test
>
>   - David Cox at Sciex will test implement?
>
> - Are we ready to update validator page?: 
> http://www.psidev.info/index.php?q=node/304
>
>  
>
>  
>

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

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

Hi Eric,

> Hi everyone, TraML version 0.9.3 has been posted at the development web page:
>  
> http://www.psidev.info/index.php?q=node/405
>  
> The links to HTML documentation and examples files are all updated.
>  
> Please examine the materials and respond.
>  
> Major changes from 0.9.2:
> - Elements CvList, Cv, CvParam now begin with lower case letter following mzIdentML
> - Precursor and Product m/z values now specified with MS:1000827
> - Interpretation elements no longer have primary= attribute but have required MS:1000926 attribute
> - All elements now have a complexType definition
> - I have attempted to use keys and keyRefs although they don’t seem to be working
>  
> Please update your implementations and example files and validators and report.
I have updated the definitions of the fragmentation information terms and added the 'replaced_by' field to the obsoleted MaRiMba term in the ontology file. The OpenMS validator is also up to date. Unfortunately, it now reports more errors, concerning allowed values of some CV terms. Most of them should be added (Remember if the psi-ms.obo file contains a xref with the value-type the value MUST be present, and MUST NOT otherwise). I added value-types to the terms reported by Fredrik.

- The attribute 'unitcvRef' should be 'unitCvRef', as it is in mzML and mzIdentML
- Value-type fields should be added to some terms, I can fix that if you want.

Unfortunately, I will not be able to attend the call today.

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] TraML 0.9.3 draft released

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

Hi,

I've updated the inclusion list example, found at the same URL as 
before. For some reason the openMS validator complains about protein 
accession (MS:1000885) and local retention time (MS:1000895) having 
values. Is this due to some mapping file or ontology issues? I cannot 
spot anything strange, but maybe someone else can explain this?

Thanks

Fredrik

Eric Deutsch wrote:
>
> Hi everyone, TraML version 0.9.3 has been posted at the development 
> web page:
>
> http://www.psidev.info/index.php?q=node/405
>
> The links to HTML documentation and examples files are all updated.
>
> Please examine the materials and respond.
>
> Major changes from 0.9.2:
>
> - Elements CvList, Cv, CvParam now begin with lower case letter 
> following mzIdentML
>
> - Precursor and Product m/z values now specified with MS:1000827
>
> - Interpretation elements no longer have primary= attribute but have 
> required MS:1000926 attribute
>
> - All elements now have a complexType definition
>
> - I have attempted to use keys and keyRefs although they don’t seem to 
> be working
>
> Please update your implementations and example files and validators 
> and report.
>
> Thanks,
>
> Eric
>
> ----------------------------------
>
> Eric Deutsch, Ph.D.
> Institute for Systems Biology
> 1441 North 34th Street
> Seattle WA 98103
> Tel: 206-732-1397
> Fax: 206-732-1260
> Email: ede...@sy... <mailto:ede...@sy...>
> WWW: http://www.systemsbiology.org/Senior_Research_Scientists/Eric_Deutsch
>