ObsCore and extensions

[BONNAREL FRANCOIS gmail]

Juste un truc Mireille,

Le 20/01/2025 à 11:48, Mireille LOUYS via dm a écrit :
> 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 .


Si, si ils sont aussi dans Radio extension à ce jour. Voir section 4.4. 
C'est Baptiste qui avait insisté. (sasn doute il y a deux ans au moins)

Bonne soirée

François

> 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/fb55a7c4/attachment.htm>