<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-forward-container"><br>
<br>
-------- Message transféré --------
<table class="moz-email-headers-table" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Sujet :
</th>
<td>Re: Obscore: obs_id not null requirement</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date : </th>
<td>Fri, 18 Mar 2022 16:26:41 +0100</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">De : </th>
<td>BONNAREL FRANCOIS
<a class="moz-txt-link-rfc2396E" href="mailto:francois.bonnarel@astro.unistra.fr"><francois.bonnarel@astro.unistra.fr></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Pour : </th>
<td>Patrick Dowler <a class="moz-txt-link-rfc2396E" href="mailto:pdowler.cadc@gmail.com"><pdowler.cadc@gmail.com></a>,
<a class="moz-txt-link-abbreviated" href="mailto:dal@ivoa.net">dal@ivoa.net</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Hi all,</div>
<div class="moz-cite-prefix">When an observation encompass several
datasets the obs_id is used to select all datasets belonging to
the same observation as Pat and Mireille said.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">When an observation encompass one
single dataset, obs_id and obs_publisher_did may seem
redundant.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">However looking for the number of
datasets related to a single obs-id may help to distinguish
simple and complex observations.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I find this cleaner than doing the
same using the obs_id = null criterium. How can we be sure that
the "null" value is for the good reason (as staed by Mireille)<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">And as Pat states it is easier to use
this obs_id field to join to other non ObsCire table where we
could have other observation metadata</div>
<div class="moz-cite-prefix">Cheers</div>
<div class="moz-cite-prefix">François<br>
</div>
<div class="moz-cite-prefix">Le 15/03/2022 à 16:44, Patrick Dowler
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAFK8nrqKjAMHSnuJ6WHFvm12zgnatZKtm04fMobAhdVUJDPbjw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default">
<div dir="ltr" class="gmail_attr"><span
class="gmail_default"></span>On Mon, 14 Mar 2022 at
04:44, Markus Demleitner <<a
href="mailto:msdemlei@ari.uni-heidelberg.de"
moz-do-not-send="true" class="moz-txt-link-freetext">msdemlei@ari.uni-heidelberg.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"><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>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"></span><br>
</div>
<blockquote class="gmail_quote"> <br>
Thanks,<br>
<br>
Markus<br>
</blockquote>
</div>
</div>
</blockquote>
<p><br>
</p>
</div>
</body>
</html>