<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi all , <br>
We also have another use case where <i>obs_id</i> represents the
observation identifier from which a data product comes from. <br>
<br>
when applying Obscore to discover radio visibility data , we provide
access to visibility chunks , having a unique <i>obs_publisher_did</i>
<br>
and they share the same <i>obs_id</i> . <br>
it is a way to identify when a set of data products share the same
'progenitor' observation, even if this one is not accessible by the
service.<br>
<br>
suppose 2 different service curators expose HST reprocessed data : <br>
they would have different <i>obs_publisher_did</i> , minted by each
curator , but could refer to the same <i>obs_id</i> in the data
provider collection.<br>
<br>
when the ObsCore spec was discussed , we had in mind this would be
easy to fill in the <i>obs_id</i> in any case <br>
, because the data provider can always use the same id for both
fields : <i>obs_publisher_did </i>, and <i>obs_id</i> for the
first round of published data.<br>
<br>
I do not see today how I could interpret obs_id = NULL unambiguously
: <br>
- missing data ? I don't know the origin of this data ?<br>
- primary data ? but we have calib_level to mention it more
precisely , etc ... <br>
<br>
What would this mean provided it is part of the mandatory keywords
of ObsTAP?<br>
<br>
my 2 cents, <br>
best wishes , Mireille<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Le 07/03/2022 à 21:41, Patrick Dowler a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAFK8nrqyRAcQ80q5eQY26kSYPB43cMfhOy9tfZiQag939pt_6g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
--
Mireille Louys, MCF (Associate Professor)
Centre de données CDS IPSEO, Images, Laboratoire Icube
Observatoire de Strasbourg Telecom Physique Strasbourg
11 rue de l'Université 300, Bd Sebastien Brandt CS 10413
F- 67000-STRASBOURG F-67412 ILLKIRCH Cedex
Tel: +33 3 68 85 24 34</pre>
</body>
</html>