Fwd: Obscore: obs_id not null requirement

[BONNAREL FRANCOIS]

-------- Message transféré --------
Sujet : 	Re: Obscore: obs_id not null requirement
Date : 	Fri, 18 Mar 2022 16:26:41 +0100
De : 	BONNAREL FRANCOIS <francois.bonnarel at astro.unistra.fr>
Pour : 	Patrick Dowler <pdowler.cadc at gmail.com>, dal at ivoa.net



Hi all,
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.

When an observation encompass one single dataset, obs_id     and 
obs_publisher_did may seem redundant.

However looking for the number of datasets related to a single obs-id 
may help to distinguish simple and complex observations.

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)

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
Cheers
François
Le 15/03/2022 à 16:44, Patrick Dowler a écrit :
> On Mon, 14 Mar 2022 at 04:44, Markus Demleitner 
> <msdemlei at ari.uni-heidelberg.de> wrote:
>
>
>     On Mon, Mar 07, 2022 at 12:41:04PM -0800, Patrick Dowler wrote:
>     > 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?
>
>
> I guess what I am saying is that CAOM is normalised compared to 
> ObsCore: there is an
> "observation" table where obs_id is the primary key, another table 
> where obs_id is a
> foreign key, and the ObsCore view is a join of these two tables. So 
> obs_id is never null (fine)
> and the "part of this group" meaning in ObsCore has a very specific 
> meaning from the CAOM
> model (the relationship between those two tables aka relation between 
> those two
> classes). There are other ways to define "part of this group" that are 
> more vague than the meaning
> in CAOM and I wonder how tightly we need to define it.
>
> In CAOM, it is 1 Observation -> N Plane, where each plane is a 
> "product" (most common case is
> different calibration levels but sometimes different/alternate 
> processing) and it is a composition relation
> in the model. For users, it is the direct "these have the same 
> photons" meaning and that's more specific than
> "part of a group".
>
> I am certain this was the intent for obs_id when ObsCore was created. 
> The name (obs_id) implies the same
> 1 observation -> N ObsCore records.Do we need to define obs_id that 
> specifically or just vaguely? Vaguely
> doesn't really tell users what they can or should not do (eg they 
> should not stack two images with the same
> obs_id together if it is the same photons).
>
> hope that helps,
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
>
>
>
>
>     Thanks,
>
>                Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20220318/dd6c2d8d/attachment.html>