Semantics Session at the November 2021 Virtual InteropWed November 3, 2021, 15:00 UTC See InterOpNov2021 for connection infos.Schedule
Minutes | |||||||||||||||||||
Changed: | |||||||||||||||||||
< < | Please contribute at https://yopad.eu/p/interop-semantics | ||||||||||||||||||
> > | Product types | ||||||||||||||||||
Added: | |||||||||||||||||||
> > | (See slides above) | ||||||||||||||||||
Added: | |||||||||||||||||||
> > | 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. | ||||||||||||||||||
Added: | |||||||||||||||||||
> > | 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. | ||||||||||||||||||
Added: | |||||||||||||||||||
> > | Observation facilities | ||||||||||||||||||
Added: | |||||||||||||||||||
> > | (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. | ||||||||||||||||||
<--
|