Re: [Psidev-qc-dev] HUPO-PSI communication of quality parameters

[Tabb, D. P. [<dt...@su...>]

Hi, Meena.

Rather than aiming for comprehensive support for mzQC in MSstats from the word "go," I would suggest we try a pilot implementation of mzQC in MSstats first.  An item that is very high on my wishlist is to see a workflow for targeted quantitation supporting mzQC from our very first release, and of course you have already developed one in MSstats.  From a look at the quick reference at http://msstats.org/msstatsqc/, it appears you emphasize four metrics for the analytes in question:

  *   Retention Time
  *   Total Peak Area
  *   Full Width at Half Maximum
  *   Peak Asymmetry

Are these metrics always computed one peptide at a time, or does the software routinely target a number of peptides from a predefined set?  Does it work from a Skyline document to determine which transitions are to be monitored?  I understand that the reference ranges for these metrics are determined on the basis of a guide set, so necessarily one would want to store that information along with the experimental metrics.

I believe that a first step for us is to understand the structure of quality metrics output by your targeted quant module.  If it's a simple table where each row is peptide and each column is one of the four fields above, that's obviously not going to be very stressful to model.  We have also made provision to report distributions, for example the quartiles of total peak area.  With that output structure in hand, we would guide you in defining the metrics within our controlled vocabulary and prototype what kind of text we would expect in the corresponding JSON.  Does that sound like a good point of entry?

I see as well that you have implemented a variety of ways to visualize and analyze the QC data (longitudinal control charts, decision maps, river and radar plots, change points).  How specifically have these been coded to reflect the data structures of MSstats itself?  Would it be possible for your code to be modified to read mzQC objects created by other tools, such as QuaMeter IDFree?  This type of interoperability is a big motivator for us in creating a standard QC communication format.

Thanks so much!
Dave

On 4/30/2019 9:48 PM, Choi, Meena wrote:
Hi David,

First of all, I'm sorry for my late response. We started two weeks course from yesterday and are getting settled :)

Timo from OpenMS tean also reminded me. Yes, I'm happy to join. Thank you for inviting me.
Please let me know what I should do next.

Thank you!
- Meena

On Tue, Apr 23, 2019 at 5:12 AM Tabb, David, Prof [dt...@su...<mailto:dt...@su...>] <dt...@su...<mailto:dt...@su...>> wrote:

Hi, Meena.  I hope that you enjoyed a good holiday weekend!


I am writing in connection with my work on mzQC, a file format for communicating quality information about biological mass spec data.  Our working group for mzQC formed after the 2016 HUPO-PSI Workshop at Ghent.  Our goal is to design a format for passing qc data from metric generation tools (like QuaMeter IDFree) to metric analysis tools (like outlier detectors) and metric storage databases.  Wouldn't it be nice to be able to perform outlier detection from many different metric generators?  At first, we intended to use an XML-based format, like qcML, but we have shifted to a lightweight JSON format instead.


When we publish mzQC, we want to have a well-established "ecosystem" of tools that can speak the mzQC format.  Your MSstats toolkit already has a solid track record, so we would love to work with you to enable mzQC output.  We're just about done with the file specification, so the course to that implementation would probably look like this:


1) Together we select a particular analysis workflow to adapt for this purpose (MSstats can handle lots of different types of experiments, so we might select a most common route to model in the first case).

2) We add terms to our controlled vocabulary that relate to the different metrics that your software outputs.

3) Your team adds the JSON output capability, and we ensure our mzQC readers can validate the JSON your code outputs.


Would something like this be feasible in the next twelve months or so?


I know that's it's always hard to find the time for features like this, but we hope that our work on streamlining the format requirements will make this a relatively easy task.


Thanks,
Dave

[http://cdn.sun.ac.za/100/ProductionFooter.jpg]<https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sun.ac.za%2Fenglish%2Fabout-us%2Fstrategic-documents&data=02%7C01%7Cm.choi%40northeastern.edu%7Cfd154f97e4e14e33d6b108d6c7cbc599%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C636916075355905673&sdata=10H4TcLX19NaJM%2F3I25WnU9dWLzVTNuekj8WLvkUqfo%3D&reserved=0>

The integrity and confidentiality of this email are governed by these terms. Disclaimer<https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sun.ac.za%2Femaildisclaimer&data=02%7C01%7Cm.choi%40northeastern.edu%7Cfd154f97e4e14e33d6b108d6c7cbc599%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C636916075355905673&sdata=KHMJBCXK%2FV5WG1ZAgCKcrpY7Et4BWRPLlkxr1b%2B2Ojc%3D&reserved=0>
Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende bepalings bereël. Vrywaringsklousule<https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sun.ac.za%2Femaildisclaimer&data=02%7C01%7Cm.choi%40northeastern.edu%7Cfd154f97e4e14e33d6b108d6c7cbc599%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C636916075355905673&sdata=KHMJBCXK%2FV5WG1ZAgCKcrpY7Et4BWRPLlkxr1b%2B2Ojc%3D&reserved=0>


--
Meena Choi
Associate Research Scientist
Khoury College of Computer Sciences
Northeastern University