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:
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
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
- 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
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
No particular comment from GWS. it is good for me.
--
GiulianoTaffoni - 2022-12-07
Very useful standard for the Registry. No particular comment. --
RenaudSavalle - 2022-12-07
No particular comment from Semantics WG --
CarloMariaZwoelf - 2022-12-12
Yes looks good. --
MarkTaylor - 2022-10-05
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>-->