Semantics Calls 6

The sixth edition of our telecon series took place on Monday, 2022-03-14, at 16:00 UTC. Here are the minutes:

VEPs (standing item)"> Current VEPs (standing item)

  • VEP-009 (datalink#progenitor) -- Francois want to restrict the concept to "science data" (e.g., for normal optical observations the raw, uncalibrated frame). One use case for separating out other progenigors would be "display the science data", which you might not want for calibration data. Markus is not convinced this is functionality is actually something a client would want to do in a debugging session. François is also offers that telling apart science and calibration data using semantics would be useful where human-readable descriptions are shoddily done, against which Markus points out that rather than complicating things in semantics, the data publishers should improve their descriptions in such cases. François will continue the discussion on the mailing list.
  • VEP-012 (date_role#Validated) -- Marco found the scope somewhat unclear. Markus will try to make that a bit more explicit in the VEP. Markus will also fix the Vocabulary URI and the date_role description. More importantly, the concerns about #Validated being not the best identifier for the concepts were shared. After some consideration, it was found that #Inspected conveys the intended meaning very well. Markus will write an updated VEP.

What are the meanings of facility_name and instrument in obscore, VODataService...?

Tamara has found unclear and partly conflicting definitions for what is supposed to be in facility and instrument in SSAP, Obscore, and VODataService. The was some discussion on this on the mailing list.

Proposal for resolution: Facility is the thing that collects messengers, instrument is what detects them. This would mean, essentially, we'll be saying facility would be analogous to FITS' TELESCOP.

Tamara would like to represent Observatory in that combo. Markus would just put in "2 Meter Schmidt at Byurakan" vs. "2 Meter Schmidt at Hamburg".

Markus and Tamara will work together to create a proposal for what might need to be changed in our standards to make that work based on Tamara's mail from February.

UCD List 1.5 progress

Mireille discusses progress towards UCD 1.5.

  • VEP-UCD-0001: stat.skewness, stat.kurtosis, stat.mad in progress --> vote to plan in UCD board
  • VEP-UCD-0003 pos.moc discussed on semantics; it is not clear there is a clear purpose for this. There is a suspicion this is more an xtype thing. Additionall, moc can be T-MOC, S-MOC or ST-MOCs, so UCD's role is perhaps more to say just what exactly to MOC represents.
  • VEP-UCD-0004 time.period.oscillation not fully discussed yet

  • VEP-UCD-0007 proposal for percentile. This is a request from ESO. This is in progress, currently discussed on the semantics list.
Let's try to close UCD 1.5 by shortly before the Interop and discuss the items during the Interop (perhaps using breakouts?)

UCD-related Errata for SSAP and SLAP progress

SSAP is instr.fov is done, https://wiki.ivoa.net/twiki/bin/view/IVOA/SSA-1_1-Err-2.

However: the new UCD pos.outline;instr.fov is inconsistent with obscore's pos.outline;obs.field; this ugly in principle but particularly because some SSA services can run on top of ObsTap services. Which do we prefer? Mireille will ask around on the semantics mailing list, but at least Markus strongly urges to accept the large installed base of Obscore and have an Erratum to our Erratum.

There's also meta.ref.url;meta.curation in SSAP, which is invalid because meta.curation is primary. A fix for that should also go in with the next SSAP Erratum.

Next up: SLAP use of em.line. Proposal: make it meta.id;em.line. There are also wonky UCDs in Appendix B, but perhaps there's no need to clean them up. Markus will write the Erratum.

The product-type vocabulary: Ready for Datalink RFC?

The purpose of this vocabulary still is to satisfy the two cases "send to the proper client" (mainly Datalink) and "find a specific sort of data" (e.g., in Obscore).

François wants to make sure we can represent the observable in there, too (e.g., velocity curve vs. photometric time series). Unless there's hidden traps, that should work by just introducing light-curve vs. velocity-curve or similar, but everyone is encouraged to think about cases we can't easily cover.

Let's try to disuss these last questions at interop.

arith.diff and arith.ratio in UCDs: Why are they S?

Postponed

FAIRsFAIR requirements and us

Postponed

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2022-03-15 - MarkusDemleitner
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback