Semantics Session at the October 2022 Virtual Interop

Thu Oct 20, 2022, 13:30 UTC

See InterOpOct2022 for connection infos.

Schedule

Notes from the Discussions

VOUnits

Should ppm be a good unit after all? Admittedly there's ppm (and ppb) all over the place, of course, but there's rather strong feelings that they are factors rather than units. Some feel that ppm-ness perhaps doesn't need to be machine-readable, and if so, we shouldn't abuse the unit field. Partly, this goes back to the question of empty strings as valid units, because if these were good, one could write 0.01 instead of % and 1e-6 instead of ppm.

SD: For the remark on 'ppm': VOUnits was first set up by trying to take into account existing syntaxes in OGIP, CDS and FITS, and finding the best common ground. Astropy was not considered at the time (not sure how units were supported back then -2014). 'ppm' is not described in OGIP, CDS or FITS, as far as I remember, so was never considered for inclusion in vounits. But... CDS in fact allows (and uses) 'ppm' in VizieR, but it's not documented in the Catalogue standards (http://cds.u-strasbg.fr/doc/catstd.htx)!

NG: I recall that '%' was originally in ... FITS?, and so was intended to be included in VOUnits, but some last-minute questions of this sort meant it was dropped. So it's always been something of an anomaly, and at least part of the reluctance to admit 'ppm' is to avoid the anomaly 'spreading'!

BC pointed out that astropy does indeed understand ppm, but then qualified that: it only does that if the CDS syntax is enabled.

On FAIR vocabularies

On FAIR vocabularies, we believe most parts of machine actionability mentioned in the talk are really there already, and our deployments actually match W3C recommendations. Hence, we believe that FAIRsFAIR would be rather happy with that part.

What we indeed do not have yet is a machine-readable index page, and there are no links to previous and (and perhaps even) later versions of a vocabulary in any of the artefacts we produce, human- or machine readable. Also, there are no resolvable links to other IVOA elements (e.g., timescale mentions VOTable 1.4 in its human-readable description but has no link to https://www.ivoa.net/documents/VOTable/). However, for all of these the question really is: Who would need that for doing what?

There is substantial interest in linking provenance-like information (the VEPs for us) from terms; figuring out why a concept was created and what motivated it seems extremely helpful in cases of doubt, and that would clearly be particularly welcome for people coming from the outside. But alas, it seems there is no convention (i.e., property) for that (that we know of).

On the new UCDs

Could we make humidity perhaps a more general concept like "partial pressure" or "concentration" or "column density", which might help with so many other substances and in many other contexts? This is basically true for everything with “water" in the current proposal; "phys.atmos.mixingRatio” would be another example.

There is also rather widespread criticism of obs.X rather than phys.X – most of these quantities are fundamentaly physical, and there's not really a difference between a pressure (say) measured as a science result and one measured as an ambient condition. On the other hand, e.g., DIMM-related ones make more sense "obs” UCDs because they are very specific to our field's way of characterizing such things.

On the facility resolver/designation

How should one use attributes like ObsCore's facility_name and instrument_name for simulated instruments? At Rubin, there is a single facility_name, like "RubinObs", for both, but then two instrument_name values, e.g., "LSSTCam" and "LSSTCam-Sim". People need to be aware that a dataset is a simulation, of course, but they should also be able to find simulations by instrument name or instrument observations for simulations. So, having separate but somehow linked designations would be great.

At the Paris project, there is nothing decided on the Sim/Real instrument side. The question is probably related to naming facilities that do lab measurements useful for the interpretation of observations of other facilities (e.g., ice spectra vs. comet spectra).

There are some concerns about “outsourcing“ this to Wikidata. We certainly cannot do the work that has gone into Wikidata ourselves, so there is no question of insourcing collecting the facilities. But we can make a vocabulary (quite likely; some internal resource, anyway) from what we harvest from them which then adheres to our vocabulary standards.

Is there a relationship to the SVO filter service? It's not immediately in scope, in particular because at the moment, we are not tackling the even more complicated problem of instrument identifiers. But having some way of figuring out "filters in use at facility X" based on this should certainly be possible with a reasonable amount of work.

Who do we expect to maintain the whole thing? Well, we are hoping that the load of fixing wikidata entries can be shared between astro libraries, professional users, and the wikidata community.

What about telescopes decommissiond long ago? Wikidata will probably accept them as long as there is clear proof that the stuff once existed. And once there are properly published observations in professional archives, we believe they would even accept backyard telescopes.