Obscore: obs_id not null requirement

[Markus Demleitner]

Hi DAL,

On Mon, Mar 07, 2022 at 12:41:04PM -0800, Patrick Dowler wrote:
> ObsCore can have multiple result rows from the same "observation", eg with
> different calib_level, and iirc the purpose of obs_id is that that set of
> rows would have the same obs_id and thus users would know they are
> different "products" of the same observation (aka same photons messengers).
> 
> In practice, obs_id could be null if that were not the case, eg if every
> record was a different observation. I expect it could be OK for some
> records to have null and others have a value that occurred 1+ times in the
> table even within a single OsbCore as obs_id is a specific kind of "part of
> this group of records" and null(s) would mean "not part of a group".

Yes, that would be a very natural interpretation.

Is anyone still considering whether they have a use case that would
break if we dropped the NULL requirement on obs_id?  If not, would
anyone object if I drafted an erratum to the effect that we
over-required here?

> Having said that, this has a clear meaning to me because our ObsCore impl
> is a view on CAOM and CAOM is normalised wrt. this obs_id concept (where
> ObsCore is denormalised), but I expect it is not so simple to specify use
> of nulls here and clearly deal with other variations of underlying models.

I have to admit I don't quite get what you're saying here -- is this
a consideration that having obs_id non-NULL makes it easier to have
it as a view over larger DMs?  If so, I'd need a bit more
explanation: Is it that CAOM consumers had a more difficult time
consuming obscore?  But why would they even try to consume obscore?
Or am I speculating in the entirely wrong direction?

Thanks,

           Markus