ObsCore and extensions

[Mireille LOUYS]

Hi Markus and all,

One precision here, included in the text.

Mireille

Le 20/01/2025 à 09:56, Markus Demleitner via dm a écrit :
> Dear Colleagues,
>
> On Fri, Jan 17, 2025 at 02:48:19PM +0100, BONNAREL FRANCOIS gmail via dm wrote:
>>> t_exp_min
>>> t_exp_max
>> It could be useful for time series outside the radio domain,  right. It's in
>> the proposal for time extension too. I am  not sure if it's useful outside
>> time series. I let Mireille and other Time extension authors comment on this
> Ah, hm... this point made me think.  What happens if the same column
> is present in multiple extensions?  I frankly would have hoped that
> we can avoid that and carefully design the different extensions such
> that only concepts specific to the the extension will be part of it.
The idea used in the Time extension and radio extension notes is to 
define a field in only one extension table .

The Obscore extension note for radio data does not include /t_exp_min , 
t_exp_max /
theses have been proposed in the Obscore Time extension .
In the case of pulsar data , 2 extensions are needed  : the radio one 
and the time one .

Then we can use queries using the natural join as proposed by Mark 
Kettenis at the last interop in the radio session ( see Mark's 
presentation).

> Realistically, this will not be possible; people interested in an
> extension will in general want to be able to do with one extension or
> two at the max, and they in particular will not want to wait for
> updates of other extensions, let alone Obscore itself.
>
> The question is what to do then.  I see two possible ways out:
>
> (a) use different column names.  But sure, it would suck if the upper
> limit of exposure times of the artifacts within a data product (say)
> had different names in radio, time domain, and high energy,
> respectively.
in that case it breaks the interoperability that Obscore was offering :
the idea is one metadata keyword , one meaning , one value , one type .

>
> (b) make it a strict validation requirement that the values in
> different extensions compare exactly equal (which may not be an easy
> feat for floating point numbers).  If we do that, our NATURAL JOIN
> recipe for pulling in the extension will automatically do the right
> thing.
>
> Opinions?  Alternatives?
>
>           -- Markus
>
My 2 cents ,
best , Mireille

-- 
--
Mireille Louys,  MCF (Associate Professor)
Centre de données CDS		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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250120/7fff71db/attachment.htm>