<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Markus and all, <br>
<br>
One precision here, included in the text. <br>
<br>
Mireille<br>
<br>
<div class="moz-cite-prefix">Le 20/01/2025 à 09:56, Markus
Demleitner via dm a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20250120085615.m3fxpwzmryd34azn@victor">
<pre wrap="" class="moz-quote-pre">Dear Colleagues,
On Fri, Jan 17, 2025 at 02:48:19PM +0100, BONNAREL FRANCOIS gmail via dm wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">t_exp_min
t_exp_max
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">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
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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.
</pre>
</blockquote>
The idea used in the Time extension and radio extension notes is to
define a field in only one extension table . <br>
<br>
The Obscore extension note for radio data does not include <i>t_exp_min
, t_exp_max </i><br>
theses have been proposed in the Obscore Time extension . <br>
In the case of pulsar data , 2 extensions are needed : the radio
one and the time one .<br>
<br>
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). <br>
<br>
<blockquote type="cite"
cite="mid:20250120085615.m3fxpwzmryd34azn@victor">
<pre wrap="" class="moz-quote-pre">
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.</pre>
</blockquote>
in that case it breaks the interoperability that Obscore was
offering : <br>
the idea is one metadata keyword , one meaning , one value , one
type . <br>
<br>
<blockquote type="cite"
cite="mid:20250120085615.m3fxpwzmryd34azn@victor">
<pre wrap="" class="moz-quote-pre">
(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
</pre>
</blockquote>
My 2 cents , <br>
best , Mireille<br>
<br>
<pre class="moz-signature" cols="72">--
--
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</pre>
</body>
</html>