Vocabularies in the VO 2 Proposed Recommendation: Request for Comments

Vocabularies in the VO, version 2, proposes formats and practices to manage hierarchical word lists that need consensus within the VO. See http://ivoa.net/rdf the vocabularies currently in use or under consideration.

Note that this is not “Semantics in the VO”, i.e., further applications of RDF (e.g., full ontologies) are by no means excluded by this specification.

Latest version of Vocabularies in the VO 2 can be found at:

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

A build of svn trunk that already includes fixes after reviewer comments is available at https://docs.g-vo.org/Vocabularies.pdf

Reference Interoperable Implementations

Vocabularies of the type described here are in use by several existing standards:

• Datalink (the semantics column)
• VOTable (TIMESYS time scales and reference positions)
• VOResource (relationship types, content levels, content types, date roles, prospectively the subject keywords)
• SimpleDALRegExt (under review: product types)
• VODataService (under review: messengers)

The code managing the RDF repository is available at https://volute.g-vo.org/svn/trunk/projects/semantics/voc-source

Implementations on the consumer side:

• stilts' VOTable validator uses vocabularies to check the TIMESYS attributes (this gives a simple example for how to deal with IVOA vocabularies in Java)
• pyVO will use the Datalink vocabulary for query expansion in the bysemantics method (https://github.com/astropy/pyvo/pull/241). This gives an example for how to use vocabularies from Python
• Sembarebro is an example for how to use vocabularies from Javascript (code)
• Another example for using IVOA vocabularies from python is the implementation of the gavo_vocmatch ADQL User Defined Function in DaCHS. See http://dc.g-vo.org/tap/capabilities for a definition of the UDF (Code, around line 526)
• A somewhat more complex use case is using the UAT hierarchy in mapping metadata, which again contains examples for vocabulary use in Python.

On processes defined:

• several VEPs have been run
• a PEN has been produced for vocabulary adoption: https://ivoa.net/documents/uat-as-upstream/20201117/ – it is probably a good idea to give this a brief look, too, when reviewing Vocabularies 2. Perhaps these Vocabularies 2 should give some constraints what must minimally be addressed in this kind of document

Plans for the consumer side:

• The RofR publishing registry validator should use the VOResource vocabularies; we expect this to happen during RFC.

Implementations Validators

The vocabulary process itself is in some sense self-validating because the input files are parsed and mangled. A “deeper” validation (“are these concepts any good?”; “can people work out from a description what is and what is not within the concept?”) is probably beyond what automated validators can do.

As to the external interface, common RDF validators can be used to check the syntactic correctness of our artefacts, for instance the W3C RDF validator.

---

---

Comments from the IVOA Community during RFC/TCG review period: 2021-03-22 through 2021-05-03

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

• Comment by CarloMariaZwoelf :
  • According to Section 5, the chairs will become de facto the curators of all the standard vocabularies (including orchestrating the VEPs workflows). In case of the external managed vocabularies the chairs also have the responsibility to keep the IVOA mirrors synchronized. This is strongly reshaping the roles of the chairs: passing from foster, coordinate and drive the WG discussions to consensus forming and issue-solving (as it is for other WGs/IGs) to something completely new, without a well defined framework. Alternative solutions to discuss and agree/disagree on may be:
    • Have some sort of advisory committee the way it was originally envisioned for UCDs
    • Entrust some defined institution with vocabulary stewardship
    • Make the Exec appoint a vocabulary steward personally, as with the document coordinator.
    • vocabulary stewardship should be personalised while the management of the VEP process remains the role of chairs?
  • Another point: as it was repeated several times, the role of IVOA is to promote standards, not to check/ensure the quality of what is distributed via the standards. This is up to the service-providers. In this case semantics is an exception: the quality checks and controls about what is distributed with a given standard (i.e. the set of vocabularies following the VOC2 standard) becomes the mission of the Semantics WG. Is this coherent with the "IVOA mission"?

---

---

Comments from TCG member during the RFC/TCG Review Period: 2021-03-22 through 2021-05-03

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

Applications Working Group

Data Access Layer Working Group

The spec is well thought out and a very good definition of how vocabularies should be defined and implemented. We note that sections 1 and 2 have quite complex sentence structure and recommend these be edited. This would enhance readability and accessibility of the standard.

We noted the following specific issues:

• Abstract - The mention of three flavours is confusing here. The mention of classes and properties should state that these are RDF, perhaps as "and the two strict hierarchies of RDF classes and RDF properties on the other" (like it's made explicit in §4).
• §1.1 - SKOS needs to be defined and/or cited
• §1.1 - last sentence misses main verb, like "... where several fields are defined, the values ..."
• §1.4 - expanding CURIE won't hurt here
• §2.1.2 - The intent of "They" in the last sentence is unclear
• §2.1.5 - Does VOResource v 1.0 and 1.1 need to be cited?
• §3.1 - how is the "email to Semantics notification" managed and advertised besides this text in par.5 in §3.1? I feel it's conflicting w.r.t. "the casual user"
• §3.2 - It would be good to state that you are defining desise here rather than using something that already exists.
  • maybe desise has to be quoted, slanted or else, being a tool/acronym-like
• §3.2 - In deprecated and preliminary, what does "mapped to a reserved value" mean? Should a specific value be provided here?
• §3.2 - Should the python example be in a non-normative subsection (like §4.2.2)?
• §4.1.1 - Should skos:exactMatch refer to §2.2.13?
• §4.1.2 - Is OpticalSource the best broader entry here? e.g. Most radio point sources are AGN
• §4.4 - ivoasem:vocflavour - Should may in "define what string may occur here" be stronger such as MUST or SHOULD?
• §4.4 - ivoasem:preliminary - "The object of triples using it is a blank node" - what does this mean?
  • same in ivoasem:deprecated
• §4.4 - ivoasem:useInstead - should there be a MUST or SHOULD linkage to deprecated? i.e. it MUST be present if a deprecated property is present and/or MUST NOT be present if deprecated is not present?
• §4.4.1 - Why are two rdf:Description elements used for the two properties (dc:created and ivoasem:vocFlavour) for relationship_type?
• §4.4.1 - How would these be used alongside the examples in §4.[123].2 ?
• §5.1 - Should there be a statement about removing ivoasem:preliminary when vocabulary is approved?
• §A.1 - Should all values be quoted? That would allow the standard csv separator of comma to be used and would make it easier to parse for other tooling.
• §A.2 - Are there any references you could use to cite the INI-style format definition?
• §A.3 - Should we be moving this to github now?
  • affects also §B
• §A - Should the tooling itself be described or referenced?
• §C - The"B1875.0" entry is missing a useInstead entry
• §D - It would be useful to have a "Changes from REC v1" section noting that this is a complete revision, just so people can trace the history.

-- JamesDempsey - 2021-05-10

Data Model Working Group

[changes in volute commit 5948 -- MarkusDemleitner - 2021-05-04]

I've a few comments that do not requires document changes:

• P6 The UCD-Vocab binding could be more detailed
  • I've added a few words to the effect that at this point, UCDs are not concerned by VocInVO2 and how they might become so in the future. -- MarkusDemleitner - 2021-05-04

• P7 I really appreciate the reading guide
• P10 Links between DM and vocab need further reflexions
  • That is true, but I think that ought to be done in the VO-DML document or perhaps in the mapping document. -- MarkusDemleitner - 2021-05-04

• General: How a client can retrieve the vocabulary a word refers to?
  A client getting BARYCENTER as TIMESYS@reflocation has no way to know that the word BARYCENTER is part of http://ivoa.net/rdf/refposition
  • The full resource URIs contain the vocabulary name; in the example, it's http://ivoa.net/rdf/refposition#reflocation, which immediately resolves. Individual standards can (and should) provide shortcuts. "Take the terms from vocabulary X" -- this is what VOTable and VOResource do -- then translates into "The RDF URI for t is X#t". Datalink says "absolutify relative URIs with http://www.ivoa.net/rdf/datalink/core", which is why the terms there look like "#calibration". Other standards might want to use the full URIs. Do you think something like this should be part of the document? If so, where? -- MarkusDemleitner - 2021-05-04

• P34 A3: is the volute URL supposed to survive Vocabukary 2.0
  • Well, it's non-normative. The trouble is that we still have no actual text on our github policies, and while that's not there I have a hard time just saying something like "put it on github". -- MarkusDemleitner - 2021-05-04

and a few non blocking suggestions from a novice reader

• P8 CURIE: a footnote (https://www.w3.org/TR/2010/NOTE-curie-20101216/) would help
  • Added a reference. -- MarkusDemleitner - 2021-05-04

• P14 2.3 RDF triples: a foornote (https://www.w3.org/TR/rdf-concepts/#section-triples) would help as well
  • Hm... I think Norman explains that a lot better in the little essay I'm referencing in the reading guide. I could make a footnote like "see p. 9 of Gray (2015)", but it's a slippery slope from there to explaining more and more of RDF proper, which is far beyond the scope of this document. Hence, I'd rather not. If you think it really helps, I will, though. Just holler. -- MarkusDemleitner - 2021-05-04

• P18 Examples of valid and non valid RDF URIs would help.
  • I have added a few examples of existing, recommended forms. I could be talked into listing a few bad ones, but I think that, really, only has a point to illustrate common pitfalls. Since I'm not aware of any of those at this point, I've not put in any yet. -- MarkusDemleitner - 2021-05-04

Approved
-- LaurentMichel - 2021-04-22

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Accept. -- MarkTaylor - 2021-03-20

Standards and Processes Committee

---

TCG Vote: TBD

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
KDIG
SSIG
Theory
TD
Ops	*
StdProc