Obscore 1.1 Erratum 3

alberto micol amicol.ivoa at googlemail.com
Fri Dec 9 11:17:11 CET 2022


Dear all,

At ESO, we map the ObCore obs_id to what we call the Observing Block identifier (explained below if you really want to know).
But the fact is that not all ESO telescopes use this Observing Block concept, APEX does not. 
For APEX we decided to set obs_id = ‘UNKNOWN’ as obs_id cannot be NULL. (NULL after all means UNKNOWN in DB speak.)

I would have preferred to allow NULL in that case. 

Using obs_id is really good to group together things according to data provider’s criteria,
but only if that it is really possible, not otherwise.

A client would, in the ESO APEX case, show always UNKNOWN in the obs_id, and that is tiring to the eye of the user;
it would be much more readable to the end user to show an empty cell instead.

Changing the obs_id to NULLable though could indeed be seen as a change of model, as advocated by François.
Being it a relaxation (and not a hardening) of a constraint, it probably does not require a change in version from ObsCore 1 to ObsCore 2.

Cheers,
Alberto

PS: To know more:

An Observing Block  (OB) is the fundamental observation unit, containing structured set of information and command to the telescope.
So, all data products constructed from observations taken as part of the same Observing Block have in the end the same ObsCore obs_id.
And data products constructed from multiple Observing Block get assign an obs_id which is the concatenation (comma separated) of the corresponding Observing Block IDs.

Example: a tile is constructed out of several paw print observations => both the tile and the paw prints all share the same obs_id.

—oOo---


More information about the dm mailing list