[Psidev-qc-dev] Upcoming teleconference 21/10

[Wout B. <wbi...@he...>]

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?