Vocabularies in the VO 2.1 Proposed Recommendation: Request for Comments

This is a Request for Comments on a minor update on Vocabularies in the VO, just updating the procedural appendices A, B, and C. The remaining material is unchanged.

Latest version of VocInVO 2.1 can be found at:

• https://ivoa.net/documents/Vocabularies/20220801/

See also the source code at https://github.com/ivoa-std/vocinvo

Reference Interoperable Implementations

No changes to the machine-readable aspects; hence, see VocabulariesV20RFC.

Implementations Validators

No changes to (potentially) validatable content; hence, see VocabulariesV20RFC.

---

---

Comments from the IVOA Community during RFC/TCG review period: 2022-09-20 through 2022-11-01

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

---

---

Comments from TCG member during the RFC/TCG Review Period: 2022-09-20 through 2022-11-01

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

The Vocabularies in the VO 2.1 PR only fixes a terminology issue in the text when a vocabulary ends up being recommended and aligns description of the tooling and machinery of vocabularies maintenance with current solutions in use.

The PR has gone through a thorough review by TCG and community. TCG review and vote has been provided and cast; thus TCG coordination is fine in approving this PR to move on the REC path for Exec evaluation.

-- JanetEvans - 2022-12-21 -- MarcoMolinaro - 2023-01-11

Applications Working Group

It looks good in general. A few comments:

A: Should the title of Appendix A say 2022 instead of 2019 (and same for the first sentenced). I don't know exactly if and what has changed in the appendix.

• Good catch, thanks. Fixed in PR. -- MarkusDemleitner – 2022-12-14

A2: Is the draft field still necessary if the VEP are dealt with in PRs?

• Oh, that's metadata for entire vocabularies, which are not dealt with through PRs (as such): A draft vocabulary is part of the Vocabulary repo's main branch. The machinery turns this "draft" key into all sorts of markup and in particular marks all its terms as preliminary (see the vocabulary index or, say, https://www.ivoa.net/rdf/object-type/2020-10-06/object-type.html). So, yes, we still need it. -- MarkusDemleitner – 2022-12-14

C1: I too think that the VEP process is a bit overly complicated. Since separate lists of approved and abandoned VEPs already exist, maintainers could pre-assign a VEP number to authers so that they can name the file properly in the initial PR and avoid C2 all together. These VEPs are not frequent so I see no difficulty in keeping track of the pre-assigned numbers with the Twiki page. The proposed process currently works too, but a simpler one makes it less prone to errors.

• Hm… but wouldn't C1 (what's done by the submitters) become even more complicated if they had to allocate VEP numbers themselves? The main complication here is a result of the fork-and-merge scheme. I'd be open to switching to branch-and-merge (i.e., giving VEP authors commit privileges to the VEP repo on request), but this has to be weighed against the fact that (for now) we do fork-and-merge for all our remaining standards development. So, for consistency I'd say we ought to keep it like this until we reconsider our stance on fork-and-merge for our standards development (which would be material for ivoatexDoc). At least until then, I'd much rather have the complexity of VEP number assignment in C2 (the vocabulary steward's job) rather than C1 (the submitter's job) -- MarkusDemleitner – 2022-12-14
  • Users don't need access to the VEP repo to issue PRs - they can do it from their own forks -- AdrianDamian - 2022-12-14

-- AdrianDamian - 2022-12-13

Data Access Layer Working Group

- Appendix C1: The phrase "prepared to accept the privacy cost involved with working through github" in the first sentence is extraneous and doesn't add anything to the standard.

• Well… I admit I can't resist a quip now and then when I had better resist the temptation. I've taken it out in PR #3. -- MarkusDemleitner 2022-12-12

- Appendix C2: It seems the process would be simpler if you had the proposer request a VEP number and rename their file before raising the PR. Is this possible?

• Perhaps it would, but I'd rather not rely on roundtrips that might take a long time and then might lead to race conditions. Also, the VEP merge will be only be done by the vocabulary steward; making the procedure a bit harder for them is I think justified if it makes things simpler for the submitters that may have quite a bit less git(hub)-fu. -- MarkusDemleitner 2022-12-12

Otherwise looks good to me.

-- JamesDempsey - 2022-12-12

Data Model Working Group

Looks good, a few minor questions and comments that do not require any change

- Appendix A1: Is there some advice about the capitatisation or the term. My feeling is that lower case should be encouraged.

• True, although that probably should be done in Sect. 4. I thought there already was a recommendation for lower-case-and-dashes (it can't be a requirement because sometimes we need to be compatible with other standards like Datacite), but I can't seem to find it now, either. If more people would like this to be explicit, I'm not be against writing a sentence or two to this effect into Sect. 4, even though it's a bit of out of scope for this simple update. -- MarkusDemleitner - 2022-10-13

- Appendix A1: Are the multiline description supported (with \n)

• Not in implementation (which does not evaluate escapes), and I don't see where it would make sense; an lf would just be folded into whitespace in processing, as there is no significant whitespace in any of these items. -- MarkusDemleitner - 2022-10-13

- Appendix C: The git cookbook is very welcome, but a little bit discouraging

• Yeah, I know. I liked the simple subversion processes better, too. But pressure for fork-and-merge in the IVOA was too strong, and I was the only one arguing in favour of considering more liberal policies. So, I don't think we have a lot of choice here. We could still say "If you want to write a VEP, ask for write privileges on the VEP repo and then just branch". But I'd only do that if sufficiently many people signalled they'd argue in favour that model when it is contested. -- MarkusDemleitner - 2022-10-13

- in general: I do not see the rationale for having 2 distinct GitHub repositories (Vocab + VEP)

• They serve totally different purposes and have totally different audiences. The VEPs repo is for the general public (i.e., those who write VEPs) and actually part of the standards process; it will be forked and cloned widely (or so I hope). The repo with the vocabularies is just a tool for the vocabulary managers to do their job and should only be cloned by them (and perhaps by people writing entirely new vocabularies). Think of it as the source code of http://www.ivoa.net/rdf. -- MarkusDemleitner - 2022-10-13

-- LaurentMichel - 2022-10-13

Thanks for the answers, no need to change the text for so minor comments.

-- LaurentMichel - 2022-10-18

Grid & Web Services Working Group

No particular comment from GWS. it is good for me.

-- GiulianoTaffoni - 2022-12-07

Registry Working Group

Very useful standard for the Registry. No particular comment. -- RenaudSavalle - 2022-12-07

Semantics Working Group

No particular comment from Semantics WG -- CarloMariaZwoelf - 2022-12-12

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Yes looks good. -- MarkTaylor - 2022-10-05

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee

---

TCG Vote : 2022-11-01 through 2022-11-XX

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

Group	Yes	No	Abstain	Comments
TCG	*
Apps	*
DAL	*
DM	*
GWS	*
Registry	*
Semantics	*
DCP
Edu
KDIG
Ops	*
Radio
SSIG
Theory
TD
<nop>StdProc

---

<!--</p> <ul> <li> <ul> <li> Set ALLOWTOPICRENAME =<span class="WYSIWYG_PROTECTED"> TWikiAdminGroup </span> </li> </ul></li> </ul>-->