Menu
▾
▴
psidev-qc-dev — PSI-QC working group mailinglist
You can subscribe to this list here.
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
(14) |
Jul
|
Aug
(11) |
Sep
|
Oct
(4) |
Nov
(15) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2017 |
Jan
(1) |
Feb
(9) |
Mar
(2) |
Apr
(2) |
May
(6) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(15) |
Oct
(9) |
Nov
(5) |
Dec
(7) |
| 2018 |
Jan
(5) |
Feb
(7) |
Mar
(3) |
Apr
(15) |
May
(5) |
Jun
(4) |
Jul
(4) |
Aug
(2) |
Sep
(4) |
Oct
(8) |
Nov
(6) |
Dec
(7) |
| 2019 |
Jan
(7) |
Feb
(2) |
Mar
(4) |
Apr
(7) |
May
(5) |
Jun
(6) |
Jul
(11) |
Aug
(5) |
Sep
(4) |
Oct
(7) |
Nov
(3) |
Dec
(4) |
| 2020 |
Jan
(5) |
Feb
(5) |
Mar
(8) |
Apr
(3) |
May
(5) |
Jun
(3) |
Jul
(9) |
Aug
(2) |
Sep
(2) |
Oct
(3) |
Nov
(5) |
Dec
(4) |
| 2021 |
Jan
(3) |
Feb
(4) |
Mar
(2) |
Apr
(4) |
May
(5) |
Jun
(9) |
Jul
(4) |
Aug
(8) |
Sep
(5) |
Oct
(3) |
Nov
(2) |
Dec
(2) |
| 2022 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
(4) |
Jun
(5) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(2) |
Nov
(5) |
Dec
|
| 2023 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(2) |
May
(11) |
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(2) |
| 2024 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(2) |
Jun
(5) |
Jul
(6) |
Aug
(2) |
Sep
(1) |
Oct
(7) |
Nov
(3) |
Dec
(1) |
| 2025 |
Jan
(3) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Wout B. <wbi...@he...> - 2021-02-17 01:02:00
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday February 17, at 15h00 GMT (15h00 London, 16h00 Western Europe, 7h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) Agenda items: - Go over the agenda for the PSI Spring Meeting. Discuss whether to include a slot for a discussion with Steffen Neumann on semantic metabolomics (unfortunately not funded by ELIXIR)? - Address SC review of the specification document. Please communicate other agenda items to the mailing list. Best, Wout |
|
From: David T. <dav...@pa...> - 2021-02-09 16:16:30
|
Hi, all.
I've received this email reflecting three PSI-SC reviews of our mzQC specification. They've asked that we make some alterations to the document *prior to* its public evaluation period.
I thought the review had been encrypted in the P7S attachment, but the comments appear to be in the email thread itself.
Thanks,
Dave
From: Psi-sc <psi...@eb...> On Behalf Of Martin Eisenacher
Sent: Thursday, February 4, 2021 12:01 PM
To: 'PSI steering committee' <ps...@eb...>
Subject: [Psi-sc] INFO: mzQC SC review
Dear PSI steering group,
just for information:
>From my experience it was a rather vivid SC review of mzQC, I think this
reflects the high impact of such a standard later and what is therefore
expected also in the next review phase.
Some of the SC review comments should be answered BEFORE further
public and invited review and some would profit from potentially
more / other opinions DURING the next review phase. The separation
between both is sometimes not so clear.
I tried (in separate mail to the authors) to mark the comments the
authors should address from my point of view BEFORE the next
phase with "!!!" and decided to have a "mix" between
minor and major restart of the DocProc (as described in the DocProc
definition).
That means that the authors should send their changes / comments for the !!!
to the three specific reviewers (Steffen, Juanan and me) and we should give
our OK before I go on to the next phase (that is quicker than a full restart).
The other comments could be answered later together with the comments
of invited and public review.
Best regards
Martin
--
PD DR. MARTIN EISENACHER
Department Leader
DEPARTMENT Medical Bioinformatics
Medizinisches Proteom-Center
Medical Faculty
&
Medical Proteome Analysis
Center for Proteindiagnostics (PRODI)
Building PRODI E2.269 | Gesundheitscampus 4 | D-44801 Bochum
Fon +49 (0)234 32-18104 | Fax +49 (0)234 32-14496
E-mail mar...@ru...<mailto:mar...@ru...>
www.medizinisches-proteom-center.de<http://www.medizinisches-proteom-center.de/>
[cid:image001.jpg@01D6FAED.772EB070]
Von: Psi-sc <psi...@eb...<mailto:psi...@eb...>> Im Auftrag von Martin Eisenacher
Gesendet: Dienstag, 2. Februar 2021 17:41
An: 'PSI steering committee' <ps...@eb...<mailto:ps...@eb...>>
Betreff: [Psi-sc] REMINDER: new DocProc submission mzQC - 30 days steering group review
Dear PSI steering group,
this is a last-minute reminder that the deadline for the PSI SC review of mzQC
is near (tomorrow).
Having a quick look I saw comments from Juan-Antonio and Steffen,
which could be sufficent already as discussed before.
Bye from Bochum
Martin
--
PD DR. MARTIN EISENACHER
Department Leader
DEPARTMENT Medical Bioinformatics
Medizinisches Proteom-Center
Medical Faculty
&
Medical Proteome Analysis
Center for Proteindiagnostics (PRODI)
Building PRODI E2.269 | Gesundheitscampus 4 | D-44801 Bochum
Fon +49 (0)234 32-18104 | Fax +49 (0)234 32-14496
E-mail mar...@ru...<mailto:mar...@ru...>
www.medizinisches-proteom-center.de<http://www.medizinisches-proteom-center.de/>
[cid:image001.jpg@01D6FAED.772EB070]
Von: Psi-sc <psi...@eb...<mailto:psi...@eb...>> Im Auftrag von Martin Eisenacher
Gesendet: Montag, 4. Januar 2021 17:36
An: PSI steering committee <ps...@eb...<mailto:ps...@eb...>>
Betreff: [Psi-sc] new DocProc submission mzQC - 30 days steering group review
Dear PSI steering group,
there has been a DocProc submission by the Quality Control
working group with a new recommendation, the mzQC format.
Purpose of the format (excerpt from the spec. doc.):
"This document defines the mzQC file format to report and exchange quality-related information
for a mass spectrometry experiment, associated analysis results, or collections thereof.
The mzQC specification defines a simple yet versatile file format with a hierarchical structure
to store quality metrics, thereby providing support for general quality control, (automated)
decision making, visualisation efforts, and easy persistence and exchange of all of the above.
The format and its specification are realized in the widespread JavaScript Object
Notation (JSON) that can be easily implemented in software to produce or consume
mzQC files. The mzQC format is complemented by the Quality Control Controlled
Vocabulary (QC CV), which includes formal definitions of relevant quality metrics.
The combination of the clear, human-readable syntax of the mzQC format and the
rich semantic information associated with quality metrics stored in the QC CV
provides powerful mechanisms to interpret, store, and enable reuse of quality control
data."
It is a file format, but not XML, which is explained / motivated in an own section.
Some examples and - more descriptive - companion documents are linked from
the spec. doc.
There are three "reference implementations" mentioned (two python, one R).
Specification document: attached and https://github.com/HUPO-PSI/mzQC/tree/master/doc
Examples: https://github.com/HUPO-PSI/mzQC/tree/master/doc/examples
Aims of the 30 days steering group review phase are repeated after the end of the mail.
I checked the submission and have some comments to the
submitters already (see also track changes / comments in the attached spec. doc.):
- table of content with only 2 levels would be better readable
- "Implementations" may be own section (e.g. after pending issues) such as in PSI-MI or mzTab-M
- 1.1: address rule-based validation in JSON? (see comment in .docx)
- explicitly mention specific QC samples and blanks also for Proteomics experiments (section 3.1)?
- I could imagine that somewhere it is explicitly stated (and explained), that the format itself
a) does not make any quality metrics mandatory, even not for specific use cases; and
b) the format itself does - of course - not judge whether the experiment was of "sufficient", "good", or "bad" quality.
And that at least a) can than be concretized by users/ journals / repositories (e.g. "PRIDE basic QC metrics").
These comments should at least be considered before the following 60-days public
and expert review phase.
Please send further feedback (and suggestions for expert reviewers)
until Wednesday, February 3rd, 2021.
Best regards
Martin Eisenacher (PSI Editor)
Aims of the SG review phase:
"[Check:]
1. That it is well formed - that is, it is presented in accordance with the templates and is clearly written.
2. That it is of an appropriate technical standard - that is, it is sufficiently detailed and clearly described to enable its suitability as a PSI MIAPE or Recommendation document to be assessed, and that it is correct in the sense that it doesn't contain obvious errors.
3. That it doesn't present additional problems for the PSI that should be addressed before the specification enters a public review phase. For example, any overlap with an existing PSI specification or a specification in another standards body might be considered to be such an issue.
At the end of this 30-days review period the PSI Editor will determine, based on feedback from the Steering Group, whether the document should proceed to a 60-day public comment period or be returned to the submitter
"
--
PD DR. MARTIN EISENACHER
Department Leader
DEPARTMENT Medical Bioinformatics
Medizinisches Proteom-Center
Medical Faculty
&
Medical Proteome Analysis
Center for Proteindiagnostics (PRODI)
Building PRODI E2.269 | Gesundheitscampus 4 | D-44801 Bochum
Fon +49 (0)234 32-18104 | Fax +49 (0)234 32-14496
E-mail mar...@ru...<mailto:mar...@ru...>
www.medizinisches-proteom-center.de<http://www.medizinisches-proteom-center.de/>
[http://www.ruhr-uni-bochum.de/cd/extern/logo/Logo_RUB_BLAU_srgb.jpg]
|
|
From: Wout B. <wbi...@he...> - 2021-02-03 02:40:45
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday February 3, at 15h00 GMT (15h00 London, 16h00 Western Europe, 7h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) Agenda items: - Determine PSI Meeting schedule. - Update of the internal review feedback. - Continue discussion on how to encode supersets? See the discussion on Slack and PR 112. Please communicate other agenda items to the mailing list. Best, Wout |
|
From: David T. <dav...@pa...> - 2021-01-28 15:04:22
|
Hi, all! First off, I am writing from my new work email address. I've removed my sun.ac.za from the list so I don't duplicate messages. Yesterday the HUPO-PSI Steering Committee reviewed the current state of the agenda for the HUPO-PSI annual meeting (https://docs.google.com/spreadsheets/d/13vBlgsI00AL5Py66uNStY6BACqhiLVgUriZjvjguTco/edit#gid=1021763599). I have some proposals for our group to review: 1. Have you registered for the meeting? It will take place during March 22-26. The time slot on each day runs from 16:00 Central European Time to 21:00 CET (for translations, see the agenda). The meeting will be electronic, just last like year. This is where you register: http://psidev.info/hupo-psi-meeting-2021 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpsidev.info%2Fhupo-psi-meeting-2021&data=04%7C01%7C%7C006b61505e504d028f4e08d8afdec253%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637452718673336622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qKizOWCo0j938gIpIm9eSJ08%2BqjTvj1mJk6qfLxxhig%3D&reserved=0> 2. At present, the Quality Control track is anticipated to have its own slot for the entirety of the meeting (at least until the plenary at the start of Friday). The topics we're discussing are currently BLANK! One might think your chair had his attention elsewhere! I propose the following as topics to slot into the schedule: * Discussion of feedback from document process on mzQC format specification * Charting a manuscript design for introducing mzQC format * Discussion of current and future implementations of mzQC * Charting a manuscript to demonstrate minimal information about proteomics quality control (along with a list of fields that everyone should be able to populate) * Discerning the need for continuing our working group as a separate HUPO-PSI track for 2022 and beyond 3. There is a remote possibility that my brother will use his passport to visit me in Paris. The week he has proposed is March 22-26. I'll keep you posted. Dumping this on Mathias at the eleventh hour would be rude of me. Thanks, Dave |
|
From: Walzer <wa...@eb...> - 2021-01-20 13:17:44
|
Dear all, another agenda item that I think we should briefly discuss is the relations design in our obo. There has been some development in psi-ms-cv which I think we could align ourselves to/weigh in on: https://github.com/HUPO-PSI/psi-ms-CV/pull/50 please have a quick look, speak soon, mths On 20/01/2021 03:42, Wout Bittremieux via Psidev-qc-dev wrote: > Dear colleagues, > > We have our next teleconference tomorrow, Wednesday January 20, at > 15h00 GMT (15h00 London, 16h00 Western Europe, 8h00 San Diego). > Note that this is one hour later than our previous timeslot. > > You can connect to our teleconference on Zoom through the > following link: > https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 > (Password: 012575) > > Agenda items: > > - Update on the review process (if already available). > - Go over the multi-run example created by Chris > (https://github.com/cbielow/mzQC/blob/master/doc/set-of-runs.mzQC.md). > - CV > - PR 102 (https://github.com/HUPO-PSI/mzQC/pull/102): new CV terms. > - PR 103 (https://github.com/HUPO-PSI/mzQC/pull/113): value types. > - Discuss paper publication strategy. > > Please communicate other agenda items to the mailing list. > > Best, > Wout > > > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev -- Mathias Walzer European Bioinformatics Institute (EMBL-EBI) Wellcome Trust Genome Campus, Hinxton, Cambridge, UK Office: +44 (0)1223 494 2610 E-mail: wa...@eb... |
|
From: Wout B. <wbi...@he...> - 2021-01-20 03:55:02
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday January 20, at 15h00 GMT (15h00 London, 16h00 Western Europe, 8h00 San Diego). Note that this is one hour later than our previous timeslot. You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) Agenda items: - Update on the review process (if already available). - Go over the multi-run example created by Chris (https://github.com/cbielow/mzQC/blob/master/doc/set-of-runs.mzQC.md). - CV - PR 102 (https://github.com/HUPO-PSI/mzQC/pull/102): new CV terms. - PR 103 (https://github.com/HUPO-PSI/mzQC/pull/113): value types. - Discuss paper publication strategy. Please communicate other agenda items to the mailing list. Best, Wout |
|
From: Bielow, C. <Chr...@fu...> - 2020-12-11 20:21:42
|
Dear all, Wout, Mathias and me figured we should meet the upcoming Wednesday at 7am San Diego time (4pm London, 5pm Berlin) to celebrate the submission (which will happen on Sunday). So bring some virtual beer, but we warned that once we stop drinking, we might actually go on to discuss future tasks 😊 Cheers Chris -----Original Message----- From: Walzer <wa...@eb...> Sent: Wednesday, December 2, 2020 10:29 AM To: Tabb, David, Prof [dt...@su...] <dt...@su...>; psi...@li... Subject: Re: [Psidev-qc-dev] Upcoming teleconference 02/12 Hi Dave, if the 120-Raw demo is in PRIDE (and she can put the software into a container) I could chip in and do the compute on our cluster here at EBI. best, mths On 02/12/2020 06:14, Tabb, David, Prof [dt...@su...] wrote: > Hi, folks. > > I asked Marina Kriek about producing an mzQC from QuaMeter IDFree. While that code has been rescued from her SUN office computer, it hasn't yet been built on her home workstation. As a result, we don't have the current version 120-RAW outlier demo set to show. She hopes to get it building this weekend, but then there are some CV and Spec changes she needs to incorporate... > > I will not be on the call today, so I am grateful as always for our co-chair! > > Thanks, > Dave > > -----Original Message----- > From: Wout Bittremieux via Psidev-qc-dev > <psi...@li...> > Sent: Wednesday, December 2, 2020 7:32 AM > To: psi...@li... > Subject: [Psidev-qc-dev] Upcoming teleconference 02/12 > > CAUTION: This email originated from outside the Stellenbosch University network. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Dear colleagues, > > We have our next teleconference tomorrow, Wednesday December 2, at 15h00 GMT (15h00 London, 16h00 Western Europe, 17h00 Cape Town, 7h00 San Diego). > Note that this is one hour later than our usual timeslot! > > You can connect to our teleconference on Zoom through the following link: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuche > alth.zoom.us%2Fj%2F92419363577%3Fpwd%3DWVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz0 > 9&data=04%7C01%7C%7Ce59215f34b6b4ff9675a08d89687a367%7Ca6fa3b030a3 > c42588433a120dffcd348%7C0%7C0%7C637424856614150926%7CUnknown%7CTWFpbGZ > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > D%7C1000&sdata=cgS7hJ9WSiKN%2FBSyEelPSnKT4UgTEFEH1GMeBlQcxhg%3D&am > p;reserved=0 > (Password: 012575) > > Agenda items: > > - Final call for comments on the specification document before initiating the document process! > - Example files: Update on the status of example files generated by different tools. > - Companion documents: Which ones do we already have? Do they need to be updated to be in line with the specification document? Which additional companion documents do we need (see specification document page 31-32)? > > Please communicate other agenda items to the mailing list. > > Best, > Wout > > > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.sourceforge.net%2Flists%2Flistinfo%2Fpsidev-qc-dev&data=04%7C01% > 7C%7Ce59215f34b6b4ff9675a08d89687a367%7Ca6fa3b030a3c42588433a120dffcd3 > 48%7C0%7C0%7C637424856614150926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata= > 822zNDd2VdLwvMtLJbXUD4lXsThtXxfT8gsOX3NVH2w%3D&reserved=0 > [https://cdn.sun.ac.za/100/ProductionFooter.jpg]<https://www.sun.ac.za > /english/about-us/strategic-documents> > > The integrity and confidentiality of this email are governed by these > terms. Disclaimer<https://www.sun.ac.za/emaildisclaimer/default.aspx> > Die integriteit en vertroulikheid van hierdie e-pos word deur die > volgende bepalings bereël. > Vrywaringsklousule<https://www.sun.ac.za/emaildisclaimer/default.aspx> > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev -- Mathias Walzer European Bioinformatics Institute (EMBL-EBI) Wellcome Trust Genome Campus, Hinxton, Cambridge, UK Office: +44 (0)1223 494 2610 E-mail: wa...@eb... _______________________________________________ Psidev-qc-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev |
|
From: Walzer <wa...@eb...> - 2020-12-02 09:29:10
|
Hi Dave, if the 120-Raw demo is in PRIDE (and she can put the software into a container) I could chip in and do the compute on our cluster here at EBI. best, mths On 02/12/2020 06:14, Tabb, David, Prof [dt...@su...] wrote: > Hi, folks. > > I asked Marina Kriek about producing an mzQC from QuaMeter IDFree. While that code has been rescued from her SUN office computer, it hasn't yet been built on her home workstation. As a result, we don't have the current version 120-RAW outlier demo set to show. She hopes to get it building this weekend, but then there are some CV and Spec changes she needs to incorporate... > > I will not be on the call today, so I am grateful as always for our co-chair! > > Thanks, > Dave > > -----Original Message----- > From: Wout Bittremieux via Psidev-qc-dev <psi...@li...> > Sent: Wednesday, December 2, 2020 7:32 AM > To: psi...@li... > Subject: [Psidev-qc-dev] Upcoming teleconference 02/12 > > CAUTION: This email originated from outside the Stellenbosch University network. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Dear colleagues, > > We have our next teleconference tomorrow, Wednesday December 2, at 15h00 GMT (15h00 London, 16h00 Western Europe, 17h00 Cape Town, 7h00 San Diego). > Note that this is one hour later than our usual timeslot! > > You can connect to our teleconference on Zoom through the following link: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuchealth.zoom.us%2Fj%2F92419363577%3Fpwd%3DWVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09&data=04%7C01%7C%7Ce59215f34b6b4ff9675a08d89687a367%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637424856614150926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cgS7hJ9WSiKN%2FBSyEelPSnKT4UgTEFEH1GMeBlQcxhg%3D&reserved=0 > (Password: 012575) > > Agenda items: > > - Final call for comments on the specification document before initiating the document process! > - Example files: Update on the status of example files generated by different tools. > - Companion documents: Which ones do we already have? Do they need to be updated to be in line with the specification document? Which additional companion documents do we need (see specification document page 31-32)? > > Please communicate other agenda items to the mailing list. > > Best, > Wout > > > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fpsidev-qc-dev&data=04%7C01%7C%7Ce59215f34b6b4ff9675a08d89687a367%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637424856614150926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=822zNDd2VdLwvMtLJbXUD4lXsThtXxfT8gsOX3NVH2w%3D&reserved=0 > [https://cdn.sun.ac.za/100/ProductionFooter.jpg]<https://www.sun.ac.za/english/about-us/strategic-documents> > > The integrity and confidentiality of this email are governed by these terms. Disclaimer<https://www.sun.ac.za/emaildisclaimer/default.aspx> > Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende bepalings bereël. Vrywaringsklousule<https://www.sun.ac.za/emaildisclaimer/default.aspx> > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev -- Mathias Walzer European Bioinformatics Institute (EMBL-EBI) Wellcome Trust Genome Campus, Hinxton, Cambridge, UK Office: +44 (0)1223 494 2610 E-mail: wa...@eb... |
|
From: Tabb, D. P. [<dt...@su...> - 2020-12-02 06:14:42
|
Hi, folks. I asked Marina Kriek about producing an mzQC from QuaMeter IDFree. While that code has been rescued from her SUN office computer, it hasn't yet been built on her home workstation. As a result, we don't have the current version 120-RAW outlier demo set to show. She hopes to get it building this weekend, but then there are some CV and Spec changes she needs to incorporate... I will not be on the call today, so I am grateful as always for our co-chair! Thanks, Dave -----Original Message----- From: Wout Bittremieux via Psidev-qc-dev <psi...@li...> Sent: Wednesday, December 2, 2020 7:32 AM To: psi...@li... Subject: [Psidev-qc-dev] Upcoming teleconference 02/12 CAUTION: This email originated from outside the Stellenbosch University network. Do not click links or open attachments unless you recognize the sender and know the content is safe. Dear colleagues, We have our next teleconference tomorrow, Wednesday December 2, at 15h00 GMT (15h00 London, 16h00 Western Europe, 17h00 Cape Town, 7h00 San Diego). Note that this is one hour later than our usual timeslot! You can connect to our teleconference on Zoom through the following link: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuchealth.zoom.us%2Fj%2F92419363577%3Fpwd%3DWVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09&data=04%7C01%7C%7Ce59215f34b6b4ff9675a08d89687a367%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637424856614150926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cgS7hJ9WSiKN%2FBSyEelPSnKT4UgTEFEH1GMeBlQcxhg%3D&reserved=0 (Password: 012575) Agenda items: - Final call for comments on the specification document before initiating the document process! - Example files: Update on the status of example files generated by different tools. - Companion documents: Which ones do we already have? Do they need to be updated to be in line with the specification document? Which additional companion documents do we need (see specification document page 31-32)? Please communicate other agenda items to the mailing list. Best, Wout _______________________________________________ Psidev-qc-dev mailing list Psi...@li... https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fpsidev-qc-dev&data=04%7C01%7C%7Ce59215f34b6b4ff9675a08d89687a367%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637424856614150926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=822zNDd2VdLwvMtLJbXUD4lXsThtXxfT8gsOX3NVH2w%3D&reserved=0 [https://cdn.sun.ac.za/100/ProductionFooter.jpg]<https://www.sun.ac.za/english/about-us/strategic-documents> The integrity and confidentiality of this email are governed by these terms. Disclaimer<https://www.sun.ac.za/emaildisclaimer/default.aspx> Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende bepalings bereël. Vrywaringsklousule<https://www.sun.ac.za/emaildisclaimer/default.aspx> |
|
From: Wout B. <wbi...@he...> - 2020-12-02 06:00:49
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday December 2, at 15h00 GMT (15h00 London, 16h00 Western Europe, 17h00 Cape Town, 7h00 San Diego). Note that this is one hour later than our usual timeslot! You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) Agenda items: - Final call for comments on the specification document before initiating the document process! - Example files: Update on the status of example files generated by different tools. - Companion documents: Which ones do we already have? Do they need to be updated to be in line with the specification document? Which additional companion documents do we need (see specification document page 31-32)? Please communicate other agenda items to the mailing list. Best, Wout |
|
From: Tabb, D. P. [<dt...@su...> - 2020-11-24 11:35:23
|
Hi, folks. When I saw this paragraph from the ProForma specification, I realized it related to a conversation on our most recent phone call: "Since ProForma MAY be used to represent both peptidoforms and proteoforms, there is currently no limit in its maximum length. Line breaks MUST NOT be used. However, non-ASCII characters are also allowed since non-ASCII characters can be included in the supported ontologies and controlled vocabularies (CVs). " Worth noting for the ASCII discussion. DT [https://cdn.sun.ac.za/100/ProductionFooter.jpg]<https://www.sun.ac.za/english/about-us/strategic-documents> The integrity and confidentiality of this email are governed by these terms. Disclaimer<https://www.sun.ac.za/emaildisclaimer/default.aspx> Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende bepalings bereël. Vrywaringsklousule<https://www.sun.ac.za/emaildisclaimer/default.aspx> |
|
From: Wout B. <wbi...@he...> - 2020-11-19 02:03:48
|
Dear colleagues, You can find the meeting notes of today's teleconference here: https://github.com/HUPO-PSI/mzQC/blob/master/meeting_notes/20201118_telco.md Our next teleconference will be on Wednesday December 2, 2020 at **15h00 GMT** (note that this is one hour later than usual). I want to reiterate what was mentioned this morning: we are very close to being able to initiate the PSI document process. We will try to start this within the next 1.5 week, so I would like to request that everyone has a final thorough look at the specification process before the Thanksgiving weekend next week: https://docs.google.com/document/d/132F3MBgDJgtFlXxDZhpJ1oHGbKL8pT6dk9fvL55L5_M/edit?usp=sharing I currently have only two minor comments for Mathias to address (update figure 1 and clarify a single sentence), so I think we are very close! Following up on our discussion from this morning, we should also create new example files. I have updated the relevant issue #11 (https://github.com/HUPO-PSI/mzQC/issues/11). Could people try to come up with the following example files or indicate any issues otherwise: - single input file (QC-Calculator @mwalzer) - multiple input files (PTXQC @cbielow: derived from MaxQuant's proteins.txt file). - metabolomics (@rsalek) Possible extra files? - QuaMeter (@dtabb73) - Yamato / SwaMe (@PaulBrack) Thank you everyone for your valiant efforts. Best, Wout On 17/11/2020 18:26, Wout Bittremieux via Psidev-qc-dev wrote: > Dear colleagues, > > We have our next teleconference tomorrow, Wednesday November 18, at > 14h00 GMT (14h00 London, 15h00 Western Europe, 16h00 Cape Town, 6h00 San > Diego). > > You can connect to our teleconference on Zoom through the > following link: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuchealth.zoom.us%2Fj%2F92419363577%3Fpwd%3DWVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09&data=04%7C01%7Cwout.bittremieux%40uantwerpen.be%7C87d55b4b499941685f5008d88b6979c6%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637412632876171562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AjdU8FJMz4Ih4cxcbTSsy21aeSfq%2BAdqFjCl1SlEXYI%3D&reserved=0 > > (Password: 012575) > > Agenda items: > > - Companion documents: Which one do we already have > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHUPO-PSI%2FmzQC%2Ftree%2Fmaster%2Fspec_doc%2Fcompanion_docs&data=04%7C01%7Cwout.bittremieux%40uantwerpen.be%7C87d55b4b499941685f5008d88b6979c6%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637412632876171562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eemJgISORrAFJ8biBRJrOjdNwWZ%2FTJGE4eNp2iIT2PI%3D&reserved=0)? > Do they need to be updated to be in line with the specification > document? Which additional companion documents do we need (see > specification document page 31-32)? > > - Example files: Provide example files covering various scenarios and > use cases. Generate with tools and/or craft by hand. What is the status? > > - Specification document & CV: Follow-up on discussion points raised > last week and comments in the specification document. > > Please communicate other agenda items to the mailing list. > > Best, > Wout > > > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fpsidev-qc-dev&data=04%7C01%7Cwout.bittremieux%40uantwerpen.be%7C87d55b4b499941685f5008d88b6979c6%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637412632876171562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fQVBArelB%2BFEzZQ5PVJBCFMPfmO6%2FBWlUpnZ1Db0p2U%3D&reserved=0 > |
|
From: Wout B. <wbi...@he...> - 2020-11-18 02:27:04
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday November 18, at 14h00 GMT (14h00 London, 15h00 Western Europe, 16h00 Cape Town, 6h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) Agenda items: - Companion documents: Which one do we already have (https://github.com/HUPO-PSI/mzQC/tree/master/spec_doc/companion_docs)? Do they need to be updated to be in line with the specification document? Which additional companion documents do we need (see specification document page 31-32)? - Example files: Provide example files covering various scenarios and use cases. Generate with tools and/or craft by hand. What is the status? - Specification document & CV: Follow-up on discussion points raised last week and comments in the specification document. Please communicate other agenda items to the mailing list. Best, Wout |
|
From: Wout B. <wbi...@he...> - 2020-11-06 02:56:01
|
Dear colleagues, We have our next teleconference tomorrow, Friday November 6, at 14h00 GMT (14h00 London, 15h00 Western Europe, 16h00 Cape Town, 6h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) Agenda items: Following up on our discussion from two weeks ago, there are still a few issues to work out related to the CV. Please check Mathias' work in PR 102 (https://github.com/HUPO-PSI/mzQC/pull/102) and the discussion on the PSI Slack. Please communicate other agenda items to the mailing list. Best, Wout |
|
From: Wout B. <wbi...@he...> - 2020-10-20 23:48:52
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday October 21, at 14h00 GMT (15h00 London, 16h00 Western Europe, 16h00 Cape Town, 17h00 Turkey, 7h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) I think we are very close to completing the specification document, so I propose we work on the few outstanding issues to finalize that. - Link: https://docs.google.com/document/d/132F3MBgDJgtFlXxDZhpJ1oHGbKL8pT6dk9fvL55L5_M/edit?usp=sharing - Critically read the specification document prior to the meeting and leave comments about sections that need to be improved. - Section 5.2 on the QC-CV needs to be updated with the latest CV information _after the open PRs about the CV have been addressed_. Conflicting information about the CV between the specification document and PRs that haven't been merged yet confused both me and Chris. See also below my comments about the CV that I first shared to the mailing list two weeks ago. - If we have time: think about examples listed in the appendix. Please communicate other agenda items to the mailing list. Best, Wout --- Original questions about the CV from October 7: > I did some additional work on the specification document, and I have a few questions about the CV (to be made clear in section 5.2): > > - Can someone please refresh my mind what the difference between "corresponding list" and "table" is? Conceptually they both seem to represent the same kind of data, although one is the transpose of the other. Currently "table" seems to not be used in the CV, while "corresponding list" is marked as "obsolete" in PR 102 (and is missing from the table in section 7). Should everything be "table" instead? > > - We also don't have a CV term of the "matrix" type yet. Can we include an example? > > - For the current CV on `master` the value types are specified in XML style using "xref: value-type:xsd\:int" format. I presume this is to be replaced by the "has_units" relationship instead? > > Given this incompleteness and inconsistencies, can we prioritize work on the CV to have at least the final format, even if not all metrics are ready for inclusion yet? Is anything currently still blocking merging the relevant PRs? |
|
From: Wout B. <wbi...@he...> - 2020-10-08 00:25:23
|
Dear colleagues, You can find the notes of today's meeting here: https://github.com/HUPO-PSI/mzQC/blob/master/meeting_notes/20201007_telco.md I did some additional work on the specification document, and I have a few questions about the CV (to be made clear in section 5.2): - Can someone please refresh my mind what the difference between "corresponding list" and "table" is? Conceptually they both seem to represent the same kind of data, although one is the transpose of the other. Currently "table" seems to not be used in the CV, while "corresponding list" is marked as "obsolete" in PR 102 (and is missing from the table in section 7). Should everything be "table" instead? - We also don't have a CV term of the "matrix" type yet. Can we include an example? - For the current CV on `master` the value types are specified in XML style using "xref: value-type:xsd\:int" format. I presume this is to be replaced by the "has_units" relationship instead? Given this incompleteness and inconsistencies, can we prioritize work on the CV to have at least the final format, even if not all metrics are ready for inclusion yet? Is anything currently still blocking merging the relevant PRs? Thank you everyone for your continued efforts. Best, Wout On 06/10/2020 19:21, Wout Bittremieux via Psidev-qc-dev wrote: > Dear colleagues, > > We have our next teleconference tomorrow, Wednesday October 7, at 14h00 > GMT (15h00 London, 16h00 Western Europe, 16h00 Cape Town, 17h00 Turkey, > 7h00 San Diego). > > You can connect to our teleconference on Zoom through the > following link: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuchealth.zoom.us%2Fj%2F92419363577%3Fpwd%3DWVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09&data=02%7C01%7Cwout.bittremieux%40uantwerpen.be%7C20557f6c1dea49080f8808d86a6a9529%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637376353739944571&sdata=qGt2t9UO5xzhR%2F9Ze4IOOJiqdC4iSFoAaYidHrhsw%2Fg%3D&reserved=0 > > (Password: 012575) > > I propose the following agenda items: > > # Specification document > > I've gone through (part of) the specification document again and tried > to make some things clearer and improve legibility. It would be useful > if people could have a look at the specification document before the > call and especially check the comments. > > Here are some of the major topics to discuss: > > - Is the switch from XML to JSON (section 2.1) sufficiently motivated > and is the introduction to JSON sufficient/too detailed/not detailed > enough? > - Difference between mzQC and qcML (section 5.1): This needs to be very > convincing to warrant a new file format. > - Is the QC CV adequately and correctly described (section 5.3)? > - Special note to Julian: there are a few outstanding comments that > require your attention. > - Should we include an example of a correct CV term request or is > this not necessary in this document? > - Please check whether the text on CV term creation is more clear > now, as it was remarked last time that this was hard to understand. I'm > not sure whether the text on values is fully correct and would > appreciate a close check thereof. > - Do we need to provide detailed information about the value types > the CV terms can take? I think yes. For example, in the CV example I've > added now, the type is `corresponding lists`, but this is not explained > anywhere. > - Additionally, more information on the `is_a` and `relationship` > links is probably useful. > - Important! We need to make sure that all information about the CV is > up to date, as some changes happened since the initial version of the > specification document. > > # Metrics that can't be directly traced back to a raw file (Chris) > > Chris asked a question on Slack about how to store metrics that don't > directly refer to a raw file. > > # State of mzqc-pylib (Mathias) > > Chris and Yasset have inquired as to the status of mzqc-pylib. > > # CV requests (Julian) > > Several issues open requesting new CV terms. > > > Please communicate other agenda items to the mailing list. > > Best, > Wout > > > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fpsidev-qc-dev&data=02%7C01%7Cwout.bittremieux%40uantwerpen.be%7C20557f6c1dea49080f8808d86a6a9529%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637376353739944571&sdata=WJJJAvBvurrPD0F0IMvCKzmLqKWN6Bj0HbN7GLyKnfI%3D&reserved=0 > |
|
From: Wout B. <wbi...@he...> - 2020-10-07 02:41:53
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday October 7, at 14h00 GMT (15h00 London, 16h00 Western Europe, 16h00 Cape Town, 17h00 Turkey, 7h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) I propose the following agenda items: # Specification document I've gone through (part of) the specification document again and tried to make some things clearer and improve legibility. It would be useful if people could have a look at the specification document before the call and especially check the comments. Here are some of the major topics to discuss: - Is the switch from XML to JSON (section 2.1) sufficiently motivated and is the introduction to JSON sufficient/too detailed/not detailed enough? - Difference between mzQC and qcML (section 5.1): This needs to be very convincing to warrant a new file format. - Is the QC CV adequately and correctly described (section 5.3)? - Special note to Julian: there are a few outstanding comments that require your attention. - Should we include an example of a correct CV term request or is this not necessary in this document? - Please check whether the text on CV term creation is more clear now, as it was remarked last time that this was hard to understand. I'm not sure whether the text on values is fully correct and would appreciate a close check thereof. - Do we need to provide detailed information about the value types the CV terms can take? I think yes. For example, in the CV example I've added now, the type is `corresponding lists`, but this is not explained anywhere. - Additionally, more information on the `is_a` and `relationship` links is probably useful. - Important! We need to make sure that all information about the CV is up to date, as some changes happened since the initial version of the specification document. # Metrics that can't be directly traced back to a raw file (Chris) Chris asked a question on Slack about how to store metrics that don't directly refer to a raw file. # State of mzqc-pylib (Mathias) Chris and Yasset have inquired as to the status of mzqc-pylib. # CV requests (Julian) Several issues open requesting new CV terms. Please communicate other agenda items to the mailing list. Best, Wout |
|
From: Wout B. <wbi...@he...> - 2020-09-16 17:51:17
|
Dear colleagues, You can find the meeting notes of today's teleconference here: https://github.com/HUPO-PSI/mzQC/blob/master/meeting_notes/20200916_telco.md Please note that our next meeting will be *October 7, 2020*. Best, Wout On 15/09/2020 19:40, Wout Bittremieux via Psidev-qc-dev wrote: > Dear colleagues, > > We have our next teleconference tomorrow, Wednesday September 16, at > 14h00 GMT (15h00 London, 16h00 Western Europe, 16h00 Cape Town, 17h00 > Turkey, 7h00 San Diego). > > You can connect to our teleconference on Zoom through the > following link: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuchealth.zoom.us%2Fj%2F92419363577%3Fpwd%3DWVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09&data=02%7C01%7Cwout.bittremieux%40uantwerpen.be%7C08037f6781fa40099e6408d859f0a530%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637358237404894027&sdata=%2BRT1leLMXbOOVW7yroXZJknqFlBqIBmIIj6uWFCu1pQ%3D&reserved=0 > > (Password: 012575) > > Based on our action items from last month I propose the following agenda > items: > > - Specification document: check comments that need to be addressed > - Companion documents: status update > - Elevator pitch for PIs (Wout; unfortunately no progress) > - Metabolomics example mzQC file (Reza) > - Instructions to request CV metric (Julian) > - CV: open issues with CV requests > > Please communicate other agenda items to the mailing list. > > Best, > Wout > > > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fpsidev-qc-dev&data=02%7C01%7Cwout.bittremieux%40uantwerpen.be%7C08037f6781fa40099e6408d859f0a530%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637358237404894027&sdata=QXF2CfOplIEgcln3NKTlTLfMeMiHzlRYUEpBBC80U44%3D&reserved=0 > |
|
From: Wout B. <wbi...@he...> - 2020-09-16 03:28:39
|
Dear colleagues, We have our next teleconference tomorrow, Wednesday September 16, at 14h00 GMT (15h00 London, 16h00 Western Europe, 16h00 Cape Town, 17h00 Turkey, 7h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) Based on our action items from last month I propose the following agenda items: - Specification document: check comments that need to be addressed - Companion documents: status update - Elevator pitch for PIs (Wout; unfortunately no progress) - Metabolomics example mzQC file (Reza) - Instructions to request CV metric (Julian) - CV: open issues with CV requests Please communicate other agenda items to the mailing list. Best, Wout |
|
From: Tabb, D. P. [<dt...@su...> - 2020-08-19 14:28:38
|
Marina has provided the attached example of mzQC, as exported from SwaME (from SWATH data). Thanks, Dave |
|
From: Wout B. <wbi...@he...> - 2020-08-19 04:14:48
|
Dear colleagues, Apologies for the late reminder. We have our next teleconference tomorrow, Wednesday August 19, at 14h00 GMT (15h00 London, 16h00 Western Europe, 16h00 Cape Town, 17h00 Turkey, 7h00 San Diego). You can connect to our teleconference on Zoom through the following link: https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 (Password: 012575) I missed the previous call and considering that it's the summer holidays I don't know whether we'll have everyone on the call, but I'd like to propose the following agenda items. - JSON format change to remove cvRef: https://github.com/HUPO-PSI/mzQC/pull/104 - Specification document status: https://docs.google.com/document/d/132F3MBgDJgtFlXxDZhpJ1oHGbKL8pT6dk9fvL55L5_M/edit - Additional documentation status: https://github.com/HUPO-PSI/mzQC/tree/schema-v0_1_1/spec_doc/companion_docs Please communicate other agenda items to the mailing list. Best, Wout |
|
From: Walzer <wa...@eb...> - 2020-07-30 09:00:56
|
Dear all, if no-one objects until the weekend, I will go ahead and realise a PR merge from branch v0.1.1 to our main branch which includes the proposed changes (in short, remove the cvRef). I already made the changes to a specification document version and the mzqc-pylib and it's looking good (https://github.com/bigbio/mzqc-pylib/tree/v0.1.1). all the best, stay safe everyone, mths On 17/07/2020 10:13, Walzer wrote: > I'll try to break down the problem in order to know what possible > solutions there are and what their implications (i.e. us imposing > certain rules or creating control mechanisms) are. And also for the > benefit of those who are not familiar with the issue we're facing, > everyone else can jump directly to the alternatives > > So we have (at the very end of a mzQCdocument) an element that > indicates which particular controlled vocabularies are used > > ``` > > 'controlledVocabularies': [ > > { 'name': 'Proteomics Standards Initiative Quality Control Ontology', > > 'ref': 'QC', > > 'uri': > 'https://github.com/HUPO-PSI/qcML-development/blob/master/cv/v0_1_0/qc-cv.obo', > > 'version': '0.1.0'}, > > { 'name': 'Proteomics Standards Initiative ' > > 'Mass Spectrometry Ontology', > > 'ref': 'MS', > > 'uri': 'https://github.com/HUPO-PSI/psi-ms-CV/blob/master/psi-ms.obo', > > 'version': '4.1.7'} > > ] > > ``` > > Then, preceding, we have a direct 'instantiation' of a CV term as a > metric in a mzQCdocument. That is, picking an accession of one of the > controlled vocabularies mentioned with a reference to the latter (and > fitting it with a 'value'). > > ``` > > {'cvRef': 'QC', 'accession': QC:4000160, 'name': 'ID ratio', 'value': > 0.4644882527680259} > > ``` > > 1. > > This means one could potentially use multiple versions of a > controlled vocabulary without any clashes. > > 2. > > Consuming such a mzQCmeans retrieving terms is a two-step process > (1. get the ref to the controlled vocabularies with terms > (accessions) of interest, 2. then get the metrics that match > reference and accession). > > 3. > > A json-path query 'might' yield terms from different versions (or > completely wrong ones if the namespaces, the part in front of a > colon and the accession number, conflict, but that should not happen > with established controlled vocabularies. Rather, that danger would > come from homebrew CVs, which puts it out of our scope) > > 4. > > A DB query would require a look-up table. > > 5. > > Controlled vocabulary versions wouldn't mean much anymore, we'd have > to bump the version with each addition. > > There are some alternatives: > > Remove the 'ref' and make the 'accession' a PURL. Implications are: > > 1. > > We would need to have our (and all 3rdparty ones!) controlled > vocabulary registered and timely updated for new entries. > > 2. > > Retrieval would require a network connection > > 3. > > The retrieval response for different 3rdparty controlled > vocabularies is far from homogenous and I could not find any > documentation on the structure of the response (compare > http://purl.obolibrary.org/obo/MS_1002358with > http://purl.obolibrary.org/obo/STATO_0000237) > > Remove the 'ref' and reform accession to obo purl (as opposed to term > purl), a separator (# in url-speak this denotes a 'fragment') and the > regular accession as found in the controlled vocabulary. Implications > are: > > 1. > > We'd still need all the controlled vocabularies registered > > 2. > > Each metric would get lengthy > > Remove the 'ref' and forget about the purl altogether. Implications are: > > 1. > > We allow the use of only one version of a controlled vocabulary > within any given mzQCdocument > > 2. > > Any 3rdparty controlled vocabulary mustn't overlap in its accessions > with any other used controlled vocabulary, and the term namespace > becomes an essential part. > > 3. > > A json query for a particular metric can be made with one step and > only leaves open the issue of terms unavailable in a certain version > which we can avoid by not deleting any. > > Now some deliberations: > > * > > Do we want anyone to allow use of multiple versions of a controlled > vocabulary? - Assuming, no definitions change between versions, this > leaves only deprecated/deleted terms. This would mean that there > would be a problem in the future only if term would 'disappear', > implicating we should only deprecate terms but leave them in, which > I think is in accordance with how controlled vocabulary terms are > supposed to work anyways. > > * > > How would we deal with definition amendments (e.g. adding a unit > formalisation where there was none before)? We should probably > strive for adding 'fully defined'metrics only. That means the > version given in a mzQCdocument is to be interpreted as 'this > version or above'. > > * > > Do we know how obolibrarypurls work? The retrieval seems messy and > are there supposed to be versions? A 'guaranteed' own namespace > would be beneficial in any way. > > * > > We cannot control which controlled vocabularies are going to be used > and therefore have no control over: > > o > > The purl having a common structure (to parse the accession and > retrieve the term offline) > > o > > There even being a purl > > o > > Online retrieval of term is a nice-to-have, but involves some > considerable technical maintenance burden. > > * > > We could also build some integration tests for our .obo PRs to make > a best effort to keep downwards compatibility and compatibility with > usual-suspect 3rdparty controlled vocabularies. > > Overall, I am in agreement with Wout and think we would not lose much > by getting rid of the 'ref' and we would gain clarity with how our > controlled vocabulary accessions are supposed to work. Which is as > unique keys withing the space of all obolibrarycontrolled > vocabularies. Still we'd need to make sure we get our own accession > namespace ('QC:…'). Making the 'used controlled vocabulary' section > of the mzQCschema a list is a technically very valid point, which if > I remember correctly we agreed upon already, and I'll make sure this > is reflected in the schema json in the repository. Maybe we can get > the accession issue sorted in a timely manner if everyone who has > doubts or (dis)agrees with the possible solutions mails in response > and we can come to an agreement before the next call. > > best, > > mths > > On 15/07/2020 03:26, Wout Bittremieux via Psidev-qc-dev wrote: >> Unfortunately I won't be able to join the call because I'm >> co-chairing the CompMS session at ISMB the whole day. (*Maybe* I'll >> be able to join the first 10 minutes.) Final preparations for this >> have taken up quite some time in the past two weeks as well, so >> unfortunately I haven't yet had the time to contribute further to the >> specification document. >> >> I've been thinking about using PURLs or CV references to link quality >> metrics to CVs, and I'm starting to favor something that was >> suggested two weeks ago: to stick to the old format, but reserve CV >> namespaces for the most commonly used CVs. So that would be "QC" for >> our CV, "MS" for the MS CV, and "UO" for the unit ontology. These >> cover the majority of use cases I think, and if we identify other >> commonly used CVs we can still add those as well. >> >> The advantage of this is that it's possible to efficiently query >> terms in these CVs, because the CV keys are fixed. So they >> essentially function the same way as the PURLS, without the need of >> actually having to use PURLs. For other CVs that aren't reserved a >> two-query solution will still be needed, but considering that such >> queries should be rare I don't consider that too much of a problem. >> A further advantage is that we can avoid the somewhat clunky PURL >> specification, don't depend on an external service, and (very >> importantly imo!) don't require web lookups to the PURL service (i.e. >> essential for doing stuff in firewalled compute environments). >> >> A small disadvantage would be that to validate these reserved CV keys >> we'd need to add explicit functionality in the mzQC Python library to >> do so. But this is hardly a showstopper. >> >> This solution seems to somewhat give us the best of both worlds I >> think. It's also nice that we don't need to change the JSON schema. >> (Although we should probably still change the CV references in the >> JSON schema from a dictionary to a list.) >> The only thing would be to clearly document this behavior and the >> reserved CV keys in the specification document. >> >> I think we should also adapt and explicitly document some best >> practices that were discussed in function of adapting PURLs: that CV >> terms are final and can only ever be deprecated (i.e. an accession >> will always point to the same CV term) and that we should document an >> official CV versioning scheme. >> >> Let me know if I've overlooked something here. >> >> Best, >> Wout >> >> On 14/07/2020 19:05, Wout Bittremieux wrote: >>> Dear colleagues, >>> >>> This is a reminder that our next teleconference is scheduled for >>> Wednesday, July 15, at 14h00 GMT (15h00 London, 16h00 Western >>> Europe, 16h00 Cape Town, 17h00 Turkey, 7h00 San Diego). >>> >>> You can connect to our teleconference on Zoom through the >>> following link: >>> https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09 >>> (Password: 012575) >>> >>> I'd like propose the following agenda items: >>> >>> - Update on finalization of specification document >>> (https://docs.google.com/document/d/132F3MBgDJgtFlXxDZhpJ1oHGbKL8pT6dk9fvL55L5_M/edit). >>> >>> - New CV requests for PTXQC via mailing list >>> (https://sourceforge.net/p/psidev/mailman/message/37059772/). >>> @Chris: Is this not covered yet? >>> - Continue discussion on CV references / PURLs in mzQC schema >>> (https://github.com/HUPO-PSI/mzQC/pull/103). >>> >>> Thanks, >>> Wout >> >> >> >> _______________________________________________ >> Psidev-qc-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev > > > > _______________________________________________ > Psidev-qc-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev -- Mathias Walzer European Bioinformatics Institute (EMBL-EBI) Wellcome Trust Genome Campus, Hinxton, Cambridge, UK Office: +44 (0)1223 494 2610 E-mail: wa...@eb... |
|
From: Walzer <wa...@eb...> - 2020-07-17 09:13:59
|
I'll try to break down the problem in order to know what possible
solutions there are and what their implications (i.e. us imposing
certain rules or creating control mechanisms) are. And also for the
benefit of those who are not familiar with the issue we're facing,
everyone else can jump directly to the alternatives
So we have (at the very end of a mzQCdocument) an element that indicates
which particular controlled vocabularies are used
```
'controlledVocabularies': [
{ 'name': 'Proteomics Standards Initiative Quality Control Ontology',
'ref': 'QC',
'uri':
'https://github.com/HUPO-PSI/qcML-development/blob/master/cv/v0_1_0/qc-cv.obo',
'version': '0.1.0'},
{ 'name': 'Proteomics Standards Initiative '
'Mass Spectrometry Ontology',
'ref': 'MS',
'uri': 'https://github.com/HUPO-PSI/psi-ms-CV/blob/master/psi-ms.obo',
'version': '4.1.7'}
]
```
Then, preceding, we have a direct 'instantiation' of a CV term as a
metric in a mzQCdocument. That is, picking an accession of one of the
controlled vocabularies mentioned with a reference to the latter (and
fitting it with a 'value').
```
{'cvRef': 'QC', 'accession': QC:4000160, 'name': 'ID ratio', 'value':
0.4644882527680259}
```
1.
This means one could potentially use multiple versions of a
controlled vocabulary without any clashes.
2.
Consuming such a mzQCmeans retrieving terms is a two-step process
(1. get the ref to the controlled vocabularies with terms
(accessions) of interest, 2. then get the metrics that match
reference and accession).
3.
A json-path query 'might' yield terms from different versions (or
completely wrong ones if the namespaces, the part in front of a
colon and the accession number, conflict, but that should not happen
with established controlled vocabularies. Rather, that danger would
come from homebrew CVs, which puts it out of our scope)
4.
A DB query would require a look-up table.
5.
Controlled vocabulary versions wouldn't mean much anymore, we'd have
to bump the version with each addition.
There are some alternatives:
Remove the 'ref' and make the 'accession' a PURL. Implications are:
1.
We would need to have our (and all 3rdparty ones!) controlled
vocabulary registered and timely updated for new entries.
2.
Retrieval would require a network connection
3.
The retrieval response for different 3rdparty controlled
vocabularies is far from homogenous and I could not find any
documentation on the structure of the response (compare
http://purl.obolibrary.org/obo/MS_1002358with
http://purl.obolibrary.org/obo/STATO_0000237)
Remove the 'ref' and reform accession to obo purl (as opposed to term
purl), a separator (# in url-speak this denotes a 'fragment') and the
regular accession as found in the controlled vocabulary. Implications are:
1.
We'd still need all the controlled vocabularies registered
2.
Each metric would get lengthy
Remove the 'ref' and forget about the purl altogether. Implications are:
1.
We allow the use of only one version of a controlled vocabulary
within any given mzQCdocument
2.
Any 3rdparty controlled vocabulary mustn't overlap in its accessions
with any other used controlled vocabulary, and the term namespace
becomes an essential part.
3.
A json query for a particular metric can be made with one step and
only leaves open the issue of terms unavailable in a certain version
which we can avoid by not deleting any.
Now some deliberations:
*
Do we want anyone to allow use of multiple versions of a controlled
vocabulary? - Assuming, no definitions change between versions, this
leaves only deprecated/deleted terms. This would mean that there
would be a problem in the future only if term would 'disappear',
implicating we should only deprecate terms but leave them in, which
I think is in accordance with how controlled vocabulary terms are
supposed to work anyways.
*
How would we deal with definition amendments (e.g. adding a unit
formalisation where there was none before)? We should probably
strive for adding 'fully defined'metrics only. That means the
version given in a mzQCdocument is to be interpreted as 'this
version or above'.
*
Do we know how obolibrarypurls work? The retrieval seems messy and
are there supposed to be versions? A 'guaranteed' own namespace
would be beneficial in any way.
*
We cannot control which controlled vocabularies are going to be used
and therefore have no control over:
o
The purl having a common structure (to parse the accession and
retrieve the term offline)
o
There even being a purl
o
Online retrieval of term is a nice-to-have, but involves some
considerable technical maintenance burden.
*
We could also build some integration tests for our .obo PRs to make
a best effort to keep downwards compatibility and compatibility with
usual-suspect 3rdparty controlled vocabularies.
Overall, I am in agreement with Wout and think we would not lose much by
getting rid of the 'ref' and we would gain clarity with how our
controlled vocabulary accessions are supposed to work. Which is as
unique keys withing the space of all obolibrarycontrolled vocabularies.
Still we'd need to make sure we get our own accession namespace
('QC:…'). Making the 'used controlled vocabulary' section of the
mzQCschema a list is a technically very valid point, which if I remember
correctly we agreed upon already, and I'll make sure this is reflected
in the schema json in the repository. Maybe we can get the accession
issue sorted in a timely manner if everyone who has doubts or
(dis)agrees with the possible solutions mails in response and we can
come to an agreement before the next call.
best,
mths
On 15/07/2020 03:26, Wout Bittremieux via Psidev-qc-dev wrote:
> Unfortunately I won't be able to join the call because I'm co-chairing
> the CompMS session at ISMB the whole day. (*Maybe* I'll be able to
> join the first 10 minutes.) Final preparations for this have taken up
> quite some time in the past two weeks as well, so unfortunately I
> haven't yet had the time to contribute further to the specification
> document.
>
> I've been thinking about using PURLs or CV references to link quality
> metrics to CVs, and I'm starting to favor something that was suggested
> two weeks ago: to stick to the old format, but reserve CV namespaces
> for the most commonly used CVs. So that would be "QC" for our CV, "MS"
> for the MS CV, and "UO" for the unit ontology. These cover the
> majority of use cases I think, and if we identify other commonly used
> CVs we can still add those as well.
>
> The advantage of this is that it's possible to efficiently query terms
> in these CVs, because the CV keys are fixed. So they essentially
> function the same way as the PURLS, without the need of actually
> having to use PURLs. For other CVs that aren't reserved a two-query
> solution will still be needed, but considering that such queries
> should be rare I don't consider that too much of a problem.
> A further advantage is that we can avoid the somewhat clunky PURL
> specification, don't depend on an external service, and (very
> importantly imo!) don't require web lookups to the PURL service (i.e.
> essential for doing stuff in firewalled compute environments).
>
> A small disadvantage would be that to validate these reserved CV keys
> we'd need to add explicit functionality in the mzQC Python library to
> do so. But this is hardly a showstopper.
>
> This solution seems to somewhat give us the best of both worlds I
> think. It's also nice that we don't need to change the JSON schema.
> (Although we should probably still change the CV references in the
> JSON schema from a dictionary to a list.)
> The only thing would be to clearly document this behavior and the
> reserved CV keys in the specification document.
>
> I think we should also adapt and explicitly document some best
> practices that were discussed in function of adapting PURLs: that CV
> terms are final and can only ever be deprecated (i.e. an accession
> will always point to the same CV term) and that we should document an
> official CV versioning scheme.
>
> Let me know if I've overlooked something here.
>
> Best,
> Wout
>
> On 14/07/2020 19:05, Wout Bittremieux wrote:
>> Dear colleagues,
>>
>> This is a reminder that our next teleconference is scheduled for
>> Wednesday, July 15, at 14h00 GMT (15h00 London, 16h00 Western
>> Europe, 16h00 Cape Town, 17h00 Turkey, 7h00 San Diego).
>>
>> You can connect to our teleconference on Zoom through the
>> following link:
>> https://uchealth.zoom.us/j/92419363577?pwd=WVp5Q3FXNU9vaVdJT0ZNRllXWlN3Zz09
>> (Password: 012575)
>>
>> I'd like propose the following agenda items:
>>
>> - Update on finalization of specification document
>> (https://docs.google.com/document/d/132F3MBgDJgtFlXxDZhpJ1oHGbKL8pT6dk9fvL55L5_M/edit).
>>
>> - New CV requests for PTXQC via mailing list
>> (https://sourceforge.net/p/psidev/mailman/message/37059772/). @Chris:
>> Is this not covered yet?
>> - Continue discussion on CV references / PURLs in mzQC schema
>> (https://github.com/HUPO-PSI/mzQC/pull/103).
>>
>> Thanks,
>> Wout
>
>
>
> _______________________________________________
> Psidev-qc-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-qc-dev
--
Mathias Walzer
European Bioinformatics Institute (EMBL-EBI)
Wellcome Trust Genome Campus, Hinxton, Cambridge, UK
Office: +44 (0)1223 494 2610
E-mail: wa...@eb...
|
1 message has been excluded from this view by a project administrator.
