<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><div dir="ltr" class="gmail_attr"><span class="gmail_default" style="font-size:small"></span>On Mon, 14 Mar 2022 at 04:44, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Mon, Mar 07, 2022 at 12:41:04PM -0800, Patrick Dowler wrote:<br>
> Having said that, this has a clear meaning to me because our ObsCore impl<br>
> is a view on CAOM and CAOM is normalised wrt. this obs_id concept (where<br>
> ObsCore is denormalised), but I expect it is not so simple to specify use<br>
> of nulls here and clearly deal with other variations of underlying models.<br>
<br>
I have to admit I don't quite get what you're saying here -- is this<br>
a consideration that having obs_id non-NULL makes it easier to have<br>
it as a view over larger DMs? If so, I'd need a bit more<br>
explanation: Is it that CAOM consumers had a more difficult time<br>
consuming obscore? But why would they even try to consume obscore?<br>
Or am I speculating in the entirely wrong direction?</blockquote><div><br></div><div>I guess what I am saying is that CAOM is normalised compared to ObsCore: there is an <br></div><div>"observation" table where obs_id is the primary key, another table where obs_id is a <br></div><div>foreign key, and the ObsCore view is a join of these two tables. So obs_id is never null (fine)</div><div>and the "part of this group" meaning in ObsCore has a very specific meaning from the CAOM</div><div>model (the relationship between those two tables aka relation between those two <br></div><div>classes). There are other ways to define "part of this group" that are more vague than the meaning <br></div><div>in CAOM and I wonder how tightly we need to define it.</div><div><br></div><div></div><div>In CAOM, it is 1 Observation -> N Plane, where each plane is a "product" (most common case is<br></div><div>different calibration levels but sometimes different/alternate processing) and it is a composition relation <br></div><div>in the model. For users, it is the direct "these have the same photons" meaning and that's more specific than <br></div><div>"part of a group". <br></div><div><br></div><div>I am certain this was the intent for obs_id when ObsCore was created. The name (obs_id) implies the same</div><div>1 observation -> N ObsCore records.Do we need to define obs_id that specifically or just vaguely? Vaguely <br></div><div>doesn't really tell users what they can or should not do (eg they should not stack two images with the same <br></div><div>obs_id together if it is the same photons).<br></div><div><br></div><div>hope that helps,</div><div><br></div><div>--<br><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><span class="gmail_default" style="font-size:small"></span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
<br>
Markus<br>
</blockquote></div></div>