<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 <strike>photons</strike> messengers).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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". <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 7 Mar 2022 at 09:56, 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">Dear DAL, dear Ops,<br>
<br>
[Ops: I'm cc-ing you because I'm linking to a praise of validation,<br>
while the thread leading up to this is perhaps not very relevant to<br>
you; discussion on obs_id should probably happen on DAL exclusively]<br>
<br>
On Fri, Mar 04, 2022 at 11:43:29AM +0000, Mark Taylor wrote:<br>
> I'm not generally in favour of MUST rather than SHOULD constraints<br>
> for non-NULL column values, on the grounds that data producers<br>
> who don't have sensible values to put in there may end up giving<br>
> useless or nonsense values just to comply with the standards,<br>
> which doesn't provide value to anybody.<br>
> <br>
> However, it may be that the best answer to Markus's problem is<br>
> for me to drop that taplint query, which could be reasonable.<br>
> The intention is that taplint doesn't place unreasonable demands<br>
> on the services that it validates, and I'm happy to take advice<br>
> in cases where that's not happening.<br>
<br>
When I tried to compose an answer to this this morning, I quickly<br>
realised it was turning into a philosophical piece. Which I then<br>
turned into a blog post this afternoon:<br>
<<a href="https://blog.g-vo.org/requirements-and-validators.html" rel="noreferrer" target="_blank">https://blog.g-vo.org/requirements-and-validators.html</a>><br>
<br>
The TL;DR would be: Thanks, but no thanks.<br>
<br>
Let's figure out whether we really have to require obs_id to be<br>
non-NULL. If we find a reason for that, I'll bite the bullet and<br>
make the taplint query fast. If we don't, let's drop the requirement<br>
(I volunteer for writing an erratum, which should be quick and easy<br>
after we've done the thinking here).<br>
<br>
Thanks,<br>
<br>
Markus<br>
</blockquote></div>