Re: [Psidev-qc-dev] QuaMeter ID-free mzQC example

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hej Wout,

Hm, I guess the only reason, why we introduced the "Fraction 
(QC:4000239)" is, that it is also a "is_a: QC:4000107 ! Column type". 
This is (should be!) mandatory for the column and, at least to my 
knowledge, you can only assign the types we created in the CV right now.

I am not too sure whether this should be the way to go, maybe discuss it 
in the next telco?

Best,
Julian

On 09.06.21 15:41, Bittremieux, Wout via Psidev-qc-dev wrote:
> Yes, as far as I read the spec both versions are compliant, as units for 
> table metrics don't really seem unambiguously described currently. 
> Possibly an oversight because we didn't have a proper example of this 
> yet? I think the second version is more in line with units for other 
> metric types though and is more descriptive. We'll need to properly 
> include this in the spec then.
> 
> One other comment is that I now used terms from the Unit Ontology as 
> units. There are also terms in our QC-CV that are the same except that 
> they're wrappers for those units to be used as table columns. See for 
> example "fraction (UO:0000191) 
> <https://github.com/bio-ontology-research-group/unit-ontology/blob/master/unit.obo#L2469>" 
> vs "Fraction (QC:4000239) 
> <https://github.com/HUPO-PSI/mzQC/blob/master/cv/qc-cv.obo#L1884>". I 
> have forgotten the previous discussion about this. What is the advantage 
> of introducing new CV terms for these units? *@Julian* maybe? To be able 
> to do a semantic check that these explicitly are column headers? I don't 
> really see a strong reason to have to duplicate CV terms when used as 
> column labels.
> 
> Best,
> Wout
> ------------------------------------------------------------------------
> *From:* David TABB <dav...@pa...>
> *Sent:* Wednesday, June 9, 2021 4:32
> *To:* Bittremieux, Wout <wbi...@he...>
> *Subject:* RE: QuaMeter ID-free mzQC example
> 
> Hi, Wout.  Very nice work!
> 
> The XIC-FWHM values are peak widths, measured in seconds.
> 
> Ratio rather than log ratio will be fine, since that’s what we have 
> available.  Of course, a 1:1 ratio is 1.0 in linear space rather than 
> 0.0 in log space, but c’est la vie.
> 
> I think of the precursor charge states as being a “proportion,” where 
> the sum of all equals 1.0 rather than a “percentage,” where the sum is 
> 100%, or a “fraction,” where the sum is arbitrary.  I think that level 
> of nuance is unnecessary to resolve for this example, though.
> 
> I like the variation where you include the unit types for each column in 
> the trailer, but do both of these formattings comply with the spec as 
> written?
> 
> Thank you,
> 
> Dave
> 
> *From:* Bittremieux, Wout via Psidev-qc-dev 
> <psi...@li...>
> *Sent:* Wednesday, June 9, 2021 2:31 AM
> *To:* psi...@li...
> *Subject:* [Psidev-qc-dev] QuaMeter ID-free mzQC example
> 
> Dear colleagues,
> 
> I have updated the mzQC example with QuaMeter ID-free metrics here: 
> https://gist.github.com/bittremieux/a3a43ce929e38fd0230005782f3c9725 
> <https://urldefense.com/v3/__https:/gist.github.com/bittremieux/a3a43ce929e38fd0230005782f3c9725__;!!JFdNOqOXpB6UZW0!_5wyaFE5AqXlNGS7vHPlkoz7VZM5nQpv_sePdYjmUqyoFjOH98anwTWamNToUEQ$>
> 
> Please check it out and provide any feedback.
> 
> I had a few open questions:
> 
>   * @Dave: I'm still missing the unit for metric "XIC-FWHM quantiles"
>     <https://urldefense.com/v3/__https:/github.com/HUPO-PSI/mzQC/blob/master/cv/qc-cv.obo*L212__;Iw!!JFdNOqOXpB6UZW0!_5wyaFE5AqXlNGS7vHPlkoz7VZM5nQpv_sePdYjmUqyoFjOH98anwTWaQKpTz5s$>.
>     What would be the correct unit there?
>   * Some of the metric values are "log ratios". I have now used "ratio"
>     as unit for these metrics because I couldn't find a log ratio term
>     in the Unit Ontology. Is this correct?
>   * Please have a look at the table metrics "MS2 known precursor charges
>     fractions" and "MS2 unknown and likely precursor charges fractions".
>     The column headers are terms from the Unit Ontology ("Charge state"
>     and "Fraction"), as also described in the specification document in
>     section 4.1.1 on page 11 ("table column type definitions"). This
>     defines the unit of the table's columns, as specified, but by not
>     explicitly including the term's accession and only using the name,
>     the link to a controlled vocabulary is lost in the mzQC file. Should
>     we maybe repeat the units for tables as a "unit" element as well?
>     For example, current:
> 
> {
> 
>      "accession": "QC:4000063",
> 
>      "name": "MS2 known precursor charges fractions",
> 
>      "value": {
> 
>          "Charge state": [
> 
>          "1",
> 
>          "2",
> 
>          "3",
> 
>          "4",
> 
>          "5",
> 
>          "6"
> 
>          ],
> 
>          "Fraction": [
> 
>          0,
> 
>          0.6830609999999999,
> 
>          0.305012,
> 
>          0.00844278,
> 
>          0.00134012,
> 
>          0.0021441999999999998
> 
>          ]
> 
>      }
> 
> }
> 
> Alternative:
> 
> {
> 
>      "accession": "QC:4000063",
> 
>      "name": "MS2 known precursor charges fractions",
> 
>      "value": {
> 
>          "Charge state": [
> 
>          "1",
> 
>          "2",
> 
>          "3",
> 
>          "4",
> 
>          "5",
> 
>          "6"
> 
>          ],
> 
>          "Fraction": [
> 
>          0,
> 
>          0.6830609999999999,
> 
>          0.305012,
> 
>          0.00844278,
> 
>          0.00134012,
> 
>          0.0021441999999999998
> 
>          ]
> 
>      },
> 
>      "unit": [
> 
>          {
> 
>              "accession": "MS:1000041",
> 
>              "name": "charge state"
> 
>          },
> 
>          {
> 
>              "accession": "UO:0000191",
> 
>              "name": "fraction"
> 
>          }
> 
>      ]
> 
> }
> 
> 	
> 	
> 
> Maybe the latter was our intention already, because "unit" is allowed to 
> be an array according to the JSON Schema and specification document. If 
> so, we should clarify in the specification document how table units 
> should be a list that matches the column order.
> 
> Thank you for having a look at these questions.
> 
> Best,
> 
> Wout
> 
> 
> 
> _______________________________________________
> Psidev-qc-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev
> 