utypes in ObsCore extension

[Bonnarel]

Discussion started after 2023-11-98 release

[Bonnarel]

As usual, I have utype quibbles; in particular, it looks funny if there suddenly are underscore-separated words in there ("Provenance.Observation.tracking_mode") where I think all other utypes (including some here) are CamelCase.

Also as usual, I don't think the column utypes here have any discernable function -- can't we just drop them altogether? I'd be willing to bet that nothing negative happens if we do. (yeah, we're doing something with the table utype, so that's different) -- MarkusDemleitner 2023-12-11

[Bonnarel]

Do you mean you do not want to use utypes for the extension table : 'ivoa.obs_radio' or also for 'ivoa.obscore'.

That sounds strange to me to omit utypes in the table for radio ( or time) extension . The quantities that are stored in the columns need to belong to some more general schema carrying the context. This should be understandable by humans and connect to existing concepts detailed in the data models.

If we would omit them in the table extension, then the role of the columns (or fields) cannot be compared to the one in ivoa.obscore .

The pecularity in Obscore DM is that this data model relies on some ideas and objects defined in Characterisation data model for the physical properties of a data set. But it does not re-use the full structure of those objects, only the main properties that help for data discovery.

I think the relationship between a column and a data model element is useful for clarification and consistence checking . The Obscore authors did not have in mind we would use MIVOT in ObsCore to carry this information in the tables, and further in the TAP response .

Up to now the utype is a light-weight annotation that is useful enough, and used in simple services and ObsTAP. It is not sure yet wether we would gain much in applying MIVOT , but it may be worth to exercise.

-- MireilleLouys 2023-12-13

[Bonnarel]

I don't want to make this a major point, but I cannot fail to notice that utypes do not have any operational role in either obscore nor obs_radio -- there is nothing any software does with them, or any functionality that wouldn't be available if they weren't there. To me, that mildly poses the question of why we bother with them.

We could discuss that in itself, but more pragmatically: do the utypes really help to link to that context? I mean, not even I know what to look up where when I see the string

Provenance.Observation.sky_scan_mode

-- and certainly no machine could do that; so, why not just state whatever context link there may be in the spec rather than bothering implementations and validators with it?

But my point was still a lot more trivial: I'm much rather drop that string altogether than quarrel whether that ought to be SkyScanMode, which I think would make it a bit more consistent with the other obscore utypes.

But feel free to drop the whole thread: While in general I much prefer it when what we require is something we actually need in a standard so it works (long version of that thought: https://blog.g-vo.org/requirements-and-validators.html) -- and that is certainly not true for the column utypes here --, I feel this isn't a good place to re-think age-old VO practices, either.

-- MarkusDemleitner 2023-12-14