Menu
▾
▴
psidev-qc-dev
|
From: Tabb, D. P. <dt...@su...> - 2016-11-01 16:34:09
|
Hi, all! We had such a lot of interesting topics that arose during our meeting in April. Now that we are rapidly approaching the submission of our group announcement whitepaper (courtesy of consistent labors by Wout Bittremieux), I wanted to check in on various other questions that arose during Ghent: 1) Mathias, you received a lot of feedback on the qcML format at our meeting. Could you describe the nature of changes that you have already made to the format along with the set of topics that still need addressing in the months to come? 2) Reza, we have talked about various partners in the metabolomics community who may be assisting us as we move forward with our work. Could you identify the primary people who will be most closely connected with the quality control effort? 3) All, I spoke with a researcher who was tightly associated with the development of SWATH technologies (a type of DIA). He was interested in seeing QC tools for the SWATH platform. Could someone help me remember his name? I'd like to see if that group has already roughed out some metrics in the DIA space. 4) Wout, thank you for your persistence in the announcement white paper (https://www.overleaf.com/5671898jfvtyd). In the month and a half together at Cape Town that we have remaining, I hope to get a better grip on the iMonDB (https://bitbucket.org/proteinspector/imondb/wiki/Home) framework. Thanks! Dave Tabb |
|
From: Reza S. <rez...@eb...> - 2016-11-01 16:58:58
|
Hi Dave, > On 1 Nov 2016, at 12:57, Tabb, David, Prof <dt...@su...> <dt...@su...> wrote: > > Hi, all! > > We had such a lot of interesting topics that arose during our meeting in April. Now that we are rapidly approaching the submission of our group announcement whitepaper (courtesy of consistent labors by Wout Bittremieux), I wanted to check in on various other questions that arose during Ghent: > > 1) Mathias, you received a lot of feedback on the qcML format at our meeting. Could you describe the nature of changes that you have already made to the format along with the set of topics that still need addressing in the months to come? > 2) Reza, we have talked about various partners in the metabolomics community who may be assisting us as we move forward with our work. Could you identify the primary people who will be most closely connected with the quality control effort? I can bring this up in the next MSI Data Standards TG telecon, and ask who would be interested in assisting. Separately, I can suggest names that are working on QC related routines. How about industry? They are usually interest in QC so can try approach them too? or do we need to coordinate it. Best Wishes, Reza > 3) All, I spoke with a researcher who was tightly associated with the development of SWATH technologies (a type of DIA). He was interested in seeing QC tools for the SWATH platform. Could someone help me remember his name? I’d like to see if that group has already roughed out some metrics in the DIA space. > 4) Wout, thank you for your persistence in the announcement white paper (https://www.overleaf.com/5671898jfvtyd <https://www.overleaf.com/5671898jfvtyd>). In the month and a half together at Cape Town that we have remaining, I hope to get a better grip on the iMonDB (https://bitbucket.org/proteinspector/imondb/wiki/Home <https://bitbucket.org/proteinspector/imondb/wiki/Home>) framework. > > Thanks! > Dave Tabb > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi_______________________________________________ <http://sdm.link/xeonphi_______________________________________________> > Psidev-qc-dev mailing list > Psi...@li... <mailto:Psi...@li...> > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev <https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev> |
|
From: Tenzer, S. <te...@un...> - 2016-11-02 08:17:32
|
Hi everybody, it could be that you spoke with Pedro Navarro (he was in my group at this time, but now unfortunately has moved on and joined Thermo as a programmer). For QC for SWATH-MS, in my opinion, it would be great to get in contact with George Rosenberger (ros...@im...<mailto:ros...@im...>) or Hannes Röst (hr...@st...<mailto:hr...@st...>), both are bioinfomaticians and experts in SWATH-MS. If you agree, I could of course invite them to contribute. Jörg Kuharev (Postdoc in my group) and I would be happy to contribute metrics for HDMSE/UDMSE (ion-mobility based DIA approaches). Best wishes, Stefan Univ.-Prof. Dr. rer. nat. Stefan Tenzer ______________________________________________ UNIVERSITÄTSMEDIZIN der Johannes Gutenberg-Universität Institut für Immunologie Core Facility für Massenspektrometrie Gebäude 708 Langenbeckstr. 1, 55131 Mainz www.immunologie-mainz.de<http://www.immunologie-mainz.de> Telefon: +49 (0) 6131 17-6199 Telefax: +49 (0) 6131 17-6202 E-mail: te...@un... Am 01.11.2016 um 13:57 schrieb Tabb, David, Prof <dt...@su...<mailto:dt...@su...>> <dt...@su...<mailto:dt...@su...>>: Hi, all! We had such a lot of interesting topics that arose during our meeting in April. Now that we are rapidly approaching the submission of our group announcement whitepaper (courtesy of consistent labors by Wout Bittremieux), I wanted to check in on various other questions that arose during Ghent: 1) Mathias, you received a lot of feedback on the qcML format at our meeting. Could you describe the nature of changes that you have already made to the format along with the set of topics that still need addressing in the months to come? 2) Reza, we have talked about various partners in the metabolomics community who may be assisting us as we move forward with our work. Could you identify the primary people who will be most closely connected with the quality control effort? 3) All, I spoke with a researcher who was tightly associated with the development of SWATH technologies (a type of DIA). He was interested in seeing QC tools for the SWATH platform. Could someone help me remember his name? I’d like to see if that group has already roughed out some metrics in the DIA space. 4) Wout, thank you for your persistence in the announcement white paper (https://www.overleaf.com/5671898jfvtyd). In the month and a half together at Cape Town that we have remaining, I hope to get a better grip on the iMonDB (https://bitbucket.org/proteinspector/imondb/wiki/Home) framework. Thanks! Dave Tabb ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi_______________________________________________ Psidev-qc-dev mailing list Psi...@li...<mailto:Psi...@li...> https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev |
|
From: Mathias W. <wa...@in...> - 2016-11-08 12:41:19
|
Dear all, Yes, as Dave pointed out there was quite some discussion and I agree this would be a good point to start with planning for the next parts of development. Though one thing I'd like to point out is that these were on-the-fly changes to explore the feasibility. In the following, I will summarize the feedback including changes, without taking sides (hopefully). I guess to keep length in reasonable measures, in a follow-up mail, I will sketch up a proposed schema working plan and further discussion points. As a side note, I've been in contact with George and Hannes about QC for openSWATH previously. Let me see if I can dig up our correspondence and give you a summary. A major point of feedback was going towards the attachment construct. Having a quality parameter calculated, which result in more than a single value would have worked the way that the XML element of the parameter would have contained only the cv term to classify the parameter and one or more attachment elements, like a table or a plot, referring to the quality parameter element. >From the feedback, preferred was to just leave it all with the parameter. This is now reflected in the development draft as nested content element, which can contain any. This leads to the second part of feedback about attachment element, that having base64 or lists of values (i.e. tables) would be insufficient. That is why there is now 'any'. A similar point of feedback was concerning the structure, over whether a separate structure for quality parameters of sets of files would be necessary. Here, no development draft changes were made, yet. Which brings me to an interesting side question @Wout, how do you handle such input in iMonDB like the type of run or any experiment structure that might influence how to calculate the statistics for quality assessment over the course of measurement acquisitions? Another point of the feedback was the reluctance accepting that the information of how to display the qcML may be contained in the file. (I.e. a stylesheet, removing the implicit necessity for a dedicated viewer program.) This however, remained in the development draft, as non-mandatory element tucked away in the outermost end of the schema. Next point and the last point of discussion in Ghent was to explore the different types of quality parameters or rather their result types to get a better grasp on how to adequately model the schema. Which resulted in the collection on GitHub (https://github.com/HUPO-PSI/qcML-development/blob/master/cv/qc-metric-collection.md). There was no time to discuss, but I wish we had, was regarding the source file(s) denomination of a calculated metric. Right now, there is no explicit element denominating the source of the data. And a very last point would be the naming of the elements, which was not addressed in particular, but I had a feeling this was a source of confusion at some points in time. Maybe we should put this under scrutiny as well. The overall structure of the schema is simple enough, maybe there is a better nomenclature to follow. best, mths ----- Original Message ----- From: "Stefan Tenzer" <te...@un...> To: "David Tabb, Prof <dt...@su...>" <dt...@su...> Cc: "Joerg Kuharev" <ku...@un...>, psi...@li... Sent: Wednesday, 2 November, 2016 9:17:22 AM Subject: Re: [Psidev-qc-dev] qcML format evolution Hi everybody, it could be that you spoke with Pedro Navarro (he was in my group at this time, but now unfortunately has moved on and joined Thermo as a programmer). For QC for SWATH-MS, in my opinion, it would be great to get in contact with George Rosenberger ( ros...@im... ) or Hannes Röst ( hr...@st... ), both are bioinfomaticians and experts in SWATH-MS. If you agree, I could of course invite them to contribute. Jörg Kuharev (Postdoc in my group) and I would be happy to contribute metrics for HDMSE/UDMSE (ion-mobility based DIA approaches). Best wishes, Stefan Univ.-Prof. Dr. rer. nat. Stefan Tenzer ______________________________________________ UNIVERSITÄTSMEDIZIN der Johannes Gutenberg-Universität Institut für Immunologie Core Facility für Massenspektrometrie Gebäude 708 Langenbeckstr. 1, 55131 Mainz www.immunologie-mainz.de Telefon: +49 (0) 6131 17-6199 Telefax: +49 (0) 6131 17-6202 E-mail: te...@un... Am 01.11.2016 um 13:57 schrieb Tabb, David, Prof < dt...@su... > < dt...@su... >: Hi, all! We had such a lot of interesting topics that arose during our meeting in April. Now that we are rapidly approaching the submission of our group announcement whitepaper (courtesy of consistent labors by Wout Bittremieux), I wanted to check in on various other questions that arose during Ghent: 1) Mathias, you received a lot of feedback on the qcML format at our meeting. Could you describe the nature of changes that you have already made to the format along with the set of topics that still need addressing in the months to come? 2) Reza, we have talked about various partners in the metabolomics community who may be assisting us as we move forward with our work. Could you identify the primary people who will be most closely connected with the quality control effort? 3) All, I spoke with a researcher who was tightly associated with the development of SWATH technologies (a type of DIA). He was interested in seeing QC tools for the SWATH platform. Could someone help me remember his name? I’d like to see if that group has already roughed out some metrics in the DIA space. 4) Wout, thank you for your persistence in the announcement white paper ( https://www.overleaf.com/5671898jfvtyd ). In the month and a half together at Cape Town that we have remaining, I hope to get a better grip on the iMonDB ( https://bitbucket.org/proteinspector/imondb/wiki/Home ) framework. Thanks! Dave Tabb ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi_______________________________________________ Psidev-qc-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Psidev-qc-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev |
|
From: Mathias W. <wa...@in...> - 2016-11-08 16:14:24
|
Dear all,
as promised here how I'd propose a schema working plan and first discussion points.
But maybe first the current design main points from the top:
Right now, we compile calculated metrics results as QualityParameters, structured under either a particular run or a set of runs. Also given can be the software that calculated the metrics or other metadata, all cv controlled. Each parameter is under cv control as well, describing the metric. The results are stored in a subelement of the parameter.
Now what I'd consider lead questions for our schema development (in suggested order of discussion and also from schema core outwards):
How do our metrics look like? ('XML-any' seems like a hard task to maintain tool-compatibility) Is our list on GitHub complete enough to start with? Would it be beneficial to also add examples to each metric?
How do we want our metrics to be represented? All defined by one cv term (hence creating an elaborate hierarchy of cv terms) or a combination of several (can we design cv terms that atomic to allow building block like features or does this hamper understanding the implications of a metric)?
Do we need to change the nomenclature for intelligibility?
Where to put additional data? A plot for instance. Or a distribution. For visualization, we probably do not want it to be necessary to re-read the whole source data again.
Do we ditch the possibility to flag results in a report? (The schema right now gives the qcML producing software the possibility to reflect in the file if a flag was raised - on whichever thresholds the user has set)
Should we change (flatten) the hierarchy? (i.e. the way metrics are categorized in per run or per set)
How to link source data? Leave it as a quality parameter of a run/set or build in dedicated elements.
What do we need to concisely present the metric (for visualization or further automated processing)? This circles back to the first question, 2nd iteration :)
These questions should take up on the feedback points from Ghent and guide us in improving the schema to a version to start building software around. But did I miss any particulars only common in metabolomics? And shall we have a regular telco/hangouts/... (bi- or tri-weekly)?
best,
mths
----- Original Message -----
From: "Mathias Walzer" <wa...@in...>
To: psi...@li...
Sent: Tuesday, 8 November, 2016 1:41:04 PM
Subject: Re: [Psidev-qc-dev] qcML format evolution
Dear all,
Yes, as Dave pointed out there was quite some discussion and I agree this would be a good point to start with planning for the next parts of development. Though one thing I'd like to point out is that these were on-the-fly changes to explore the feasibility.
In the following, I will summarize the feedback including changes, without taking sides (hopefully).
I guess to keep length in reasonable measures, in a follow-up mail, I will sketch up a proposed schema working plan and further discussion points.
As a side note, I've been in contact with George and Hannes about QC for openSWATH previously. Let me see if I can dig up our correspondence and give you a summary.
A major point of feedback was going towards the attachment construct.
Having a quality parameter calculated, which result in more than a single value would have worked the way that the XML element of the parameter would have contained only the cv term to classify the parameter and one or more attachment elements, like a table or a plot, referring to the quality parameter element.
>From the feedback, preferred was to just leave it all with the parameter. This is now reflected in the development draft as nested content element, which can contain any.
This leads to the second part of feedback about attachment element, that having base64 or lists of values (i.e. tables) would be insufficient. That is why there is now 'any'.
A similar point of feedback was concerning the structure, over whether a separate structure for quality parameters of sets of files would be necessary. Here, no development draft changes were made, yet. Which brings me to an interesting side question @Wout, how do you handle such input in iMonDB like the type of run or any experiment structure that might influence how to calculate the statistics for quality assessment over the course of measurement acquisitions?
Another point of the feedback was the reluctance accepting that the information of how to display the qcML may be contained in the file. (I.e. a stylesheet, removing the implicit necessity for a dedicated viewer program.) This however, remained in the development draft, as non-mandatory element tucked away in the outermost end of the schema.
Next point and the last point of discussion in Ghent was to explore the different types of quality parameters or rather their result types to get a better grasp on how to adequately model the schema. Which resulted in the collection on GitHub (https://github.com/HUPO-PSI/qcML-development/blob/master/cv/qc-metric-collection.md).
There was no time to discuss, but I wish we had, was regarding the source file(s) denomination of a calculated metric. Right now, there is no explicit element denominating the source of the data.
And a very last point would be the naming of the elements, which was not addressed in particular, but I had a feeling this was a source of confusion at some points in time. Maybe we should put this under scrutiny as well. The overall structure of the schema is simple enough, maybe there is a better nomenclature to follow.
best,
mths
----- Original Message -----
From: "Stefan Tenzer" <te...@un...>
To: "David Tabb, Prof <dt...@su...>" <dt...@su...>
Cc: "Joerg Kuharev" <ku...@un...>, psi...@li...
Sent: Wednesday, 2 November, 2016 9:17:22 AM
Subject: Re: [Psidev-qc-dev] qcML format evolution
Hi everybody,
it could be that you spoke with Pedro Navarro (he was in my group at this time, but now unfortunately has moved on and joined Thermo as a programmer).
For QC for SWATH-MS, in my opinion, it would be great to get in contact with George Rosenberger ( ros...@im... ) or Hannes Röst ( hr...@st... ), both are bioinfomaticians and experts in SWATH-MS.
If you agree, I could of course invite them to contribute.
Jörg Kuharev (Postdoc in my group) and I would be happy to contribute metrics for HDMSE/UDMSE (ion-mobility based DIA approaches).
Best wishes,
Stefan
Univ.-Prof. Dr. rer. nat. Stefan Tenzer
______________________________________________
UNIVERSITÄTSMEDIZIN
der Johannes Gutenberg-Universität
Institut für Immunologie
Core Facility für Massenspektrometrie
Gebäude 708
Langenbeckstr. 1, 55131 Mainz
www.immunologie-mainz.de
Telefon: +49 (0) 6131 17-6199
Telefax: +49 (0) 6131 17-6202
E-mail: te...@un...
Am 01.11.2016 um 13:57 schrieb Tabb, David, Prof < dt...@su... > < dt...@su... >:
Hi, all!
We had such a lot of interesting topics that arose during our meeting in April. Now that we are rapidly approaching the submission of our group announcement whitepaper (courtesy of consistent labors by Wout Bittremieux), I wanted to check in on various other questions that arose during Ghent:
1) Mathias, you received a lot of feedback on the qcML format at our meeting. Could you describe the nature of changes that you have already made to the format along with the set of topics that still need addressing in the months to come?
2) Reza, we have talked about various partners in the metabolomics community who may be assisting us as we move forward with our work. Could you identify the primary people who will be most closely connected with the quality control effort?
3) All, I spoke with a researcher who was tightly associated with the development of SWATH technologies (a type of DIA). He was interested in seeing QC tools for the SWATH platform. Could someone help me remember his name? I’d like to see if that group has already roughed out some metrics in the DIA space.
4) Wout, thank you for your persistence in the announcement white paper ( https://www.overleaf.com/5671898jfvtyd ). In the month and a half together at Cape Town that we have remaining, I hope to get a better grip on the iMonDB ( https://bitbucket.org/proteinspector/imondb/wiki/Home ) framework.
Thanks!
Dave Tabb ------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi_______________________________________________
Psidev-qc-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Psidev-qc-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev
|
|
From: Bittremieux W. <wou...@ua...> - 2016-11-17 06:49:27
Attachments:
signature.asc
|
Hi Mathias, Thank you for the detailed state of affairs. Concerning your iMonDB question, I don't have any notion of a 'set' in there, I only store data on the level of individual runs. There is however the possibility for the user to specify custom metadata through the GUI, which is stored as key-value pairs. Based on the metadata and combinations thereof the data can be filtered for the visualization. Also, currently I represent all metrics as summary statistics over the entire run, consisting of mean, median, standard deviation, quartiles, ... Therefore the discussion on how to represent single and multiple values is very relevant, but I'm not sure what would be the ideal solution. Also, it could be interesting not to discard the full data in favor of only summary statistics to for example investigate and optimize the performance of individual scans. But this is only interesting idea at the moment, not something I'm actively working on. You can find the current iMonDB database schema here <https://bitbucket.org/proteinspector/imondb/wiki/Database>, although this will be transformed to match the new qcML format once it has been specified. Regards, Wout > On 08 Nov 2016, at 18:14, Mathias Walzer <wa...@in...> wrote: > > Dear all, > > as promised here how I'd propose a schema working plan and first discussion points. > > But maybe first the current design main points from the top: > Right now, we compile calculated metrics results as QualityParameters, structured under either a particular run or a set of runs. Also given can be the software that calculated the metrics or other metadata, all cv controlled. Each parameter is under cv control as well, describing the metric. The results are stored in a subelement of the parameter. > > Now what I'd consider lead questions for our schema development (in suggested order of discussion and also from schema core outwards): > > How do our metrics look like? ('XML-any' seems like a hard task to maintain tool-compatibility) Is our list on GitHub complete enough to start with? Would it be beneficial to also add examples to each metric? > > How do we want our metrics to be represented? All defined by one cv term (hence creating an elaborate hierarchy of cv terms) or a combination of several (can we design cv terms that atomic to allow building block like features or does this hamper understanding the implications of a metric)? > > Do we need to change the nomenclature for intelligibility? > > Where to put additional data? A plot for instance. Or a distribution. For visualization, we probably do not want it to be necessary to re-read the whole source data again. > > Do we ditch the possibility to flag results in a report? (The schema right now gives the qcML producing software the possibility to reflect in the file if a flag was raised - on whichever thresholds the user has set) > > Should we change (flatten) the hierarchy? (i.e. the way metrics are categorized in per run or per set) > > How to link source data? Leave it as a quality parameter of a run/set or build in dedicated elements. > > What do we need to concisely present the metric (for visualization or further automated processing)? This circles back to the first question, 2nd iteration :) > > These questions should take up on the feedback points from Ghent and guide us in improving the schema to a version to start building software around. But did I miss any particulars only common in metabolomics? And shall we have a regular telco/hangouts/... (bi- or tri-weekly)? > > best, > mths > > ----- Original Message ----- > From: "Mathias Walzer" <wa...@in...> > To: psi...@li... > Sent: Tuesday, 8 November, 2016 1:41:04 PM > Subject: Re: [Psidev-qc-dev] qcML format evolution > > Dear all, > > Yes, as Dave pointed out there was quite some discussion and I agree this would be a good point to start with planning for the next parts of development. Though one thing I'd like to point out is that these were on-the-fly changes to explore the feasibility. > > In the following, I will summarize the feedback including changes, without taking sides (hopefully). > I guess to keep length in reasonable measures, in a follow-up mail, I will sketch up a proposed schema working plan and further discussion points. > As a side note, I've been in contact with George and Hannes about QC for openSWATH previously. Let me see if I can dig up our correspondence and give you a summary. > > A major point of feedback was going towards the attachment construct. > Having a quality parameter calculated, which result in more than a single value would have worked the way that the XML element of the parameter would have contained only the cv term to classify the parameter and one or more attachment elements, like a table or a plot, referring to the quality parameter element. > From the feedback, preferred was to just leave it all with the parameter. This is now reflected in the development draft as nested content element, which can contain any. > This leads to the second part of feedback about attachment element, that having base64 or lists of values (i.e. tables) would be insufficient. That is why there is now 'any'. > > A similar point of feedback was concerning the structure, over whether a separate structure for quality parameters of sets of files would be necessary. Here, no development draft changes were made, yet. Which brings me to an interesting side question @Wout, how do you handle such input in iMonDB like the type of run or any experiment structure that might influence how to calculate the statistics for quality assessment over the course of measurement acquisitions? > > Another point of the feedback was the reluctance accepting that the information of how to display the qcML may be contained in the file. (I.e. a stylesheet, removing the implicit necessity for a dedicated viewer program.) This however, remained in the development draft, as non-mandatory element tucked away in the outermost end of the schema. > > Next point and the last point of discussion in Ghent was to explore the different types of quality parameters or rather their result types to get a better grasp on how to adequately model the schema. Which resulted in the collection on GitHub (https://github.com/HUPO-PSI/qcML-development/blob/master/cv/qc-metric-collection.md). > > There was no time to discuss, but I wish we had, was regarding the source file(s) denomination of a calculated metric. Right now, there is no explicit element denominating the source of the data. > > And a very last point would be the naming of the elements, which was not addressed in particular, but I had a feeling this was a source of confusion at some points in time. Maybe we should put this under scrutiny as well. The overall structure of the schema is simple enough, maybe there is a better nomenclature to follow. > > > best, > mths > > ----- Original Message ----- > From: "Stefan Tenzer" <te...@un...> > To: "David Tabb, Prof <dt...@su...>" <dt...@su...> > Cc: "Joerg Kuharev" <ku...@un...>, psi...@li... > Sent: Wednesday, 2 November, 2016 9:17:22 AM > Subject: Re: [Psidev-qc-dev] qcML format evolution > > > Hi everybody, > > > it could be that you spoke with Pedro Navarro (he was in my group at this time, but now unfortunately has moved on and joined Thermo as a programmer). > > > For QC for SWATH-MS, in my opinion, it would be great to get in contact with George Rosenberger ( ros...@im... ) or Hannes Röst ( hr...@st... ), both are bioinfomaticians and experts in SWATH-MS. > If you agree, I could of course invite them to contribute. > > > Jörg Kuharev (Postdoc in my group) and I would be happy to contribute metrics for HDMSE/UDMSE (ion-mobility based DIA approaches). > > > > > Best wishes, > > > Stefan > > > > > > > Univ.-Prof. Dr. rer. nat. Stefan Tenzer > ______________________________________________ > > UNIVERSITÄTSMEDIZIN > der Johannes Gutenberg-Universität > Institut für Immunologie > Core Facility für Massenspektrometrie > Gebäude 708 > Langenbeckstr. 1, 55131 Mainz > www.immunologie-mainz.de > > Telefon: +49 (0) 6131 17-6199 > Telefax: +49 (0) 6131 17-6202 > E-mail: te...@un... > > > Am 01.11.2016 um 13:57 schrieb Tabb, David, Prof < dt...@su... > < dt...@su... >: > > > > > > Hi, all! > > We had such a lot of interesting topics that arose during our meeting in April. Now that we are rapidly approaching the submission of our group announcement whitepaper (courtesy of consistent labors by Wout Bittremieux), I wanted to check in on various other questions that arose during Ghent: > > 1) Mathias, you received a lot of feedback on the qcML format at our meeting. Could you describe the nature of changes that you have already made to the format along with the set of topics that still need addressing in the months to come? > 2) Reza, we have talked about various partners in the metabolomics community who may be assisting us as we move forward with our work. Could you identify the primary people who will be most closely connected with the quality control effort? > 3) All, I spoke with a researcher who was tightly associated with the development of SWATH technologies (a type of DIA). He was interested in seeing QC tools for the SWATH platform. Could someone help me remember his name? I’d like to see if that group has already roughed out some metrics in the DIA space. > 4) Wout, thank you for your persistence in the announcement white paper ( https://www.overleaf.com/5671898jfvtyd ). In the month and a half together at Cape Town that we have remaining, I hope to get a better grip on the iMonDB ( https://bitbucket.org/proteinspector/imondb/wiki/Home ) framework. > > Thanks! > Dave Tabb ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi_______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev |
|
From: Tabb, D. P. <dt...@su...> - 2016-11-30 13:05:24
|
Hi, Stefan. Yes, I would really appreciate it if you could put me in contact with either of both of these researchers. I would like to frame some specific examples of metrics that would be appropriate to measurement in DIA/SWATH for the revision of Wout's manuscript introducing our group. For example, the distribution of "cycle time" that is required for the instrument to repeat a set of SWATHs would seem an appropriate metric for evaluating one of these experiments. I would imagine this to vary in response to the number of ions exiting from LC-ESI at a particular moment in time. A blocked column might lead to suddenly longer cycle times, I would think. If we can be more specific about the way QC metrics could inform us of SWATH quality, I think we'll have a good case to make in that space. I will write with Karl Clauser about the case of iTRAQ next. I will also take a look at some of the R libraries that have been produced in support of SRM QC. Thanks, Dave From: Tenzer, Stefan [mailto:te...@un...] Sent: Wednesday, 02 November 2016 10:17 To: Tabb, David, Prof <dt...@su...> Cc: psi...@li...; Kuharev, Joerg Subject: Re: [Psidev-qc-dev] qcML format evolution Hi everybody, it could be that you spoke with Pedro Navarro (he was in my group at this time, but now unfortunately has moved on and joined Thermo as a programmer). For QC for SWATH-MS, in my opinion, it would be great to get in contact with George Rosenberger (ros...@im...<mailto:ros...@im...>) or Hannes Röst (hr...@st...<mailto:hr...@st...>), both are bioinfomaticians and experts in SWATH-MS. If you agree, I could of course invite them to contribute. Jörg Kuharev (Postdoc in my group) and I would be happy to contribute metrics for HDMSE/UDMSE (ion-mobility based DIA approaches). Best wishes, Stefan Univ.-Prof. Dr. rer. nat. Stefan Tenzer ______________________________________________ UNIVERSITÄTSMEDIZIN der Johannes Gutenberg-Universität Institut für Immunologie Core Facility für Massenspektrometrie Gebäude 708 Langenbeckstr. 1, 55131 Mainz www.immunologie-mainz.de<http://www.immunologie-mainz.de> Telefon: +49 (0) 6131 17-6199 Telefax: +49 (0) 6131 17-6202 E-mail: te...@un...<mailto:te...@un...> Am 01.11.2016 um 13:57 schrieb Tabb, David, Prof <dt...@su...<mailto:dt...@su...>> <dt...@su...<mailto:dt...@su...>>: Hi, all! We had such a lot of interesting topics that arose during our meeting in April. Now that we are rapidly approaching the submission of our group announcement whitepaper (courtesy of consistent labors by Wout Bittremieux), I wanted to check in on various other questions that arose during Ghent: 1) Mathias, you received a lot of feedback on the qcML format at our meeting. Could you describe the nature of changes that you have already made to the format along with the set of topics that still need addressing in the months to come? 2) Reza, we have talked about various partners in the metabolomics community who may be assisting us as we move forward with our work. Could you identify the primary people who will be most closely connected with the quality control effort? 3) All, I spoke with a researcher who was tightly associated with the development of SWATH technologies (a type of DIA). He was interested in seeing QC tools for the SWATH platform. Could someone help me remember his name? I'd like to see if that group has already roughed out some metrics in the DIA space. 4) Wout, thank you for your persistence in the announcement white paper (https://www.overleaf.com/5671898jfvtyd). In the month and a half together at Cape Town that we have remaining, I hope to get a better grip on the iMonDB (https://bitbucket.org/proteinspector/imondb/wiki/Home) framework. Thanks! Dave Tabb ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi_______________________________________________ Psidev-qc-dev mailing list Psi...@li...<mailto:Psi...@li...> https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev |
|
From: Mathias W. <wa...@in...> - 2017-02-07 19:25:10
|
Hi all, as the last two post were closely related to new metrics, I'll create a new thread for metrics ([Psidev-qc-dev] metrics) and forward (repost) the respective posts. Now, as no feedback whatsoever about the changes (after last spring meeting, that is > 0.7) reached me, I will go ahead and make this a pre-release on which we can base our next step on - metrics development and refinement. But keep in mind that it is pretty hard to define a community standard format without feedback. I'd like to take this opportunity to paraphrase my latter question > And shall we have a regular telco/hangouts/... (bi- or tri-weekly)? We should have a regular teleconference. We can use google hangouts or, after consulting with Juanan , the EBI 0800 telco system for that. I will circulate date suggestions soon. I added a visual review to github a while back for folks to make it easier to express their ideas/opinions on the _next iteration_ of schema evolution. (https://github.com/HUPO-PSI/qcML-development/tree/master/schema/v0_0_9) best, Mathias |
|
From: walzer <wa...@in...> - 2017-02-15 12:16:07
|
Dear all, you may have seen the activity on github regarding the metrics definitions as implemented in one way or the other by previous software and the mailing list thread about new metrics. My suggestion would be, that we have our first telco next week or the following to discuss the metrics and their representation. What about the following dates? Tue. 21.02. - 14.00 CEST Tue. 21.02. - 18.00 CEST (hangouts only) Wed 22.02. - 14.00 CEST Wed 22.02. - 18.00 CEST (hangouts only) Mon. 27.02. - 14.00 CEST Mon 27.02. - 18.00 CEST (hangouts only) Tue 28.02. - 14.00 CEST I would suggest also to have the discussion via hangouts, alternatively via EBI teleconference system (however there, someone has to be physically at EBI, which excludes the evening dates). If you want to participate, please take the doodle (http://doodle.com/poll/bv36kwe3hfmgwm8v) so we can find a date that fits most. If you cannot make any of the dates, please let me know. best, Mathias On 07.02.2017 19:24, Mathias Walzer wrote: > Hi all, > > as the last two post were closely related to new metrics, I'll create > a new thread for metrics ([Psidev-qc-dev] metrics) and forward > (repost) the respective posts. > > Now, as no feedback whatsoever about the changes (after last spring > meeting, that is > 0.7) reached me, I will go ahead and make this a > pre-release on which we can base our next step on - metrics > development and refinement. But keep in mind that it is pretty hard to > define a community standard format without feedback. > > I'd like to take this opportunity to paraphrase my latter question > > And shall we have a regular telco/hangouts/... (bi- or tri-weekly)? > > We should have a regular teleconference. We can use google hangouts > or, after consulting with Juanan, the EBI 0800 telco system for that. > I will circulate date suggestions soon. > > I added a visual review to github a while back for folks to make it > easier to express their ideas/opinions on the _next iteration_ of > schema evolution. > (https://github.com/HUPO-PSI/qcML-development/tree/master/schema/v0_0_9) > > > > best, > > Mathias > |
|
From: Mathias W. <wa...@in...> - 2017-02-07 20:05:57
|
Dear all, let's discuss new QC metrics and definition refinement of old ones here. We might start here: There are some interesting new developments: There is the Mass-Up framework ( http://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-015-0752-4 ) for Maldi TOF QC, see Davids post on Quality control in Mass-Up And also new developments from the metabolomics side with msPurity (http://pubs.acs.org/doi/abs/10.1021/acs.analchem.6b04358) For labelled experiments, Spectrum Mill is using quality control metrics proven on CPTAC breast cancer proteome dataset (http://www.nature.com/nature/journal/v534/n7605/abs/nature18003.html , see Karl Clausers Re: [Psidev-qc-dev] HUPO PSI Quality Control Working Group post with the SpectrumMill documentation attached) Or, which would be much to my delight, revise the collection of more general LC-MS/MS metrics already in use in qcML (https://github.com/mwalzer/qcML-development/blob/feature/QC-CV-Metric_overview/cv/qc-metric-collection.md). So to the matter, how do you think do any metrics from the above fit in our CV definition schema? Would some need generalisation for the sake of minimising redundancy/overlap, or on the other side are some not specific enough? Do you have a great metric that is missing in our discussions? best, Mathias |
|
From: walzer <wa...@in...> - 2017-02-20 14:53:09
|
Dear all, as interest in a telco is not putting doodle or me in a difficult spot to pick a date, maybe a little digest of the newest metrics we could discuss, will kindle some more interest (http://doodle.com/poll/bv36kwe3hfmgwm8v). CPTAC labeling QC We haven't touched upon QC for labeling techniques, and the CPTAC study considerations seem like a good start (thanks to Karl Clauser). Summarised, these would cover ideally the completeness of labellings (counting the number of labeled vs. unlabeled termini) Also, considering the S/N of not only all spectra (as we would now with MS2-2) but also of only those with reporter ions seems to be a good idea. MassUP - QC MassUp covers base with a number of metrics that also we use (e.g. the name of the sample, number of spectra, min. Mass, max. Mass, avg. Masses, ...) but also ask for a classas label of the sample - as already mentioned this is highly interesting to bring the experimental design into the loop to do proper QC for a set of several measurements.They also define POPXX as a the number of peaks with Percentage of Presence- so I am not that familiar with MALDI, but it seems to be a a good idea in general to also look at the replication success on a spectrum and peaks level! though I am not sure which kind of peaks they are considering in this MALID setting with MassUp analysis. msPurity Lawson et al. published an interesting metric to assist with spectral library search result assessments in metabolomics. The metric assesses the purity of the precursor producing a tandem spectrum. Having more than just the targeted ion species in your selection for fragmentation messes with the lookup of your spectrum in a library with (assumedly) pure spectra. But I think this is also useful in other context, at least I come across some mixed spectra sometimes, especially when sample abundance or ionisation yield is low and the fill times go up to the max. set. They calculate this metric as a ratio of precursor intensity and sum. intensity of the respective isolation window. As I read it, it is assumed that the highest peak in the isolation window is the targeted precursor peak, and it's intensity for the MS2 is interpolated from the intensity in the neighboring MS1. I think it would also be good to have a classification of analysis metrics and acquisition metrics. I think it came up in Ghent, but our metrics list was not long enough to make such separations. This goes in the same direction as what Robert was saying in his mail, that there might be as well a lot of good/reliable results in bad runs. After all, often times analysis algorithms are robust enough to navigate around bits of bad data. The ID(free) classification goes in that direction, but I think analysis metrics would comprise more. best, Mathias On 07.02.2017 21:05, Mathias Walzer wrote: > Dear all, > > let's discuss new QC metrics and definition refinement of old ones here. We might start here: > > There are some interesting new developments: > There is the Mass-Up framework ( http://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-015-0752-4 ) for Maldi TOF QC, see Davids post on Quality control in Mass-Up > > And also new developments from the metabolomics side with msPurity (http://pubs.acs.org/doi/abs/10.1021/acs.analchem.6b04358) > > For labelled experiments, Spectrum Mill is using quality control metrics proven on CPTAC breast cancer proteome dataset (http://www.nature.com/nature/journal/v534/n7605/abs/nature18003.html , see Karl Clausers Re: [Psidev-qc-dev] HUPO PSI Quality Control Working Group post with the SpectrumMill documentation attached) > > Or, which would be much to my delight, revise the collection of more general LC-MS/MS metrics already in use in qcML (https://github.com/mwalzer/qcML-development/blob/feature/QC-CV-Metric_overview/cv/qc-metric-collection.md). > > So to the matter, how do you think do any metrics from the above fit in our CV definition schema? Would some need generalisation for the sake of minimising redundancy/overlap, or on the other side are some not specific enough? > Do you have a great metric that is missing in our discussions? > > best, > Mathias > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-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