Semantics Session at the November 2021 Virtual Interop

Wed November 3, 2021, 15:00 UTC

See InterOpNov2021 for connection infos.

Schedule

Minutes

Product types

(See slides above)

People remark there may be other considerations for data, e.g., whether it is sparse. But is there an actual use case for that in data discovery? If so, we could integrate such root concepts, but that would then lead to leaf concepts like sparse-spectral-cube or so. Let's see if such a thing is actually useful to any particular client.

There was a wish that the the initial product-type vocabulary should just contain the existing ObsCore terms so that we aren't also folding in multiple VEPs in the initial review; on the other hand, this is (technically) creating a new vocabulary, so at least Markus would be liberal when taking up new proposed terms, as long as people actually use them and they're plausible. At least these shouldn't have to wait until the vocabulary is accepted with Datalink (which could take a while). People can still shoot them down in review.

Observation facilities

(See slides above)

It's pointed out that there is a link to be done with the Spanish VO Filter Profile Service, http://svo2.cab.inta-csic.es/theory/fps/; this already exists in one of the lists. Of course, a simple way to bridge any vocabulary of instruments to the SVO profiles is if SVO just had the identifiers from that particular vocabulary in their table.

People discuss the additional problem that instruments move between facilities.

There's more trouble where, for instance, PDS may just have instrument_host = Mauna Kea - what identifier would we assign there? Could there be "approximations" for such cases?

Of course, the problem of granularity also exists on the part of the data providers: When they define their facility name in obscore, which name should they use: only indicate the telescope name? also include the observatory name? use a hyphen to separate names? use abbreviations?

But advanced use cases are looking more like requiring a full data model than a vocabulary. And that there's obvious links to provenance, so whatever happens here should be in sync with ProvDM. There, inside the provenance of an Observation ‘activity’, the configuration can be described with the elements involved: telescope, instruments, with coverage, technology etc .

Object types

(See slides above)

Given this is seeded through Simbad, this is largely missing solar system concepts; for that, IMCCE/ssodnet may be a good start: https://vo.imcce.fr/webservices/ssodnet/

We certainly don't want to force planetary complexity into SIMBAD. For small bodies in particular there are multiple types of partitions. There is a preliminary classification in EPN-Core. Keeping Solar System and Astrophysics separated is reasonable (e.g., in a separate solar system branch).

If we search for "stars", do we want to find the Sun? For reference, the UAT says no.

Oh, of course SIMBAD is not a simple tree - there are connections between the tree-organised nodes.

When discussing "classifications", there are various axes of classifiction - morphology, activity type, etc. This may indicate we need a more complex structure, or perhaps by the 80/20 we concentrate on what's scientifically the "most" relevant classification.