<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Markus, Marjolein,</div>
<div class="moz-cite-prefix">Thanks you for reading the document
carefully and providing feedback.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I address here the f_min/f_max point
where I will explain why we introduced that and why I persist to
think it is to be kept. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 18/12/2023 à 09:07, Marjolein
Verkouter a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:64A2BC7E-CD82-4886-8683-E00557DA27A2@jive.eu">
<pre class="moz-quote-pre" wrap="">
- I would advocate (very) strongly to not record the same information (em_min/max, f_min/max) in the same table but make it easy to query on energy, wavelength, or frequency by adding convenience functions, such as Markus proposes at some point. For the raw table information let's stick to one (1) physics representation.
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-cite-prefix">Le 11/12/2023 à 13:46, Markus
Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20231211124653.53xl6evbwqovmflw@victor">
<pre class="moz-quote-pre" wrap="">
(1) The longer I think about them, the less I like f_min and f_max. If
you look at use case 1.3: "range inside the 1 to 1.5 Ghz band" -- and
then people have to write f_min > 1000 AND f_max < 1500 and thus do
some conversion anyway, and to the relatively random unit MHz on top.
Please let's reconsider this; I have sympathies for not wanting to
write the λ-ν conversions manually, but if
1 = ivo_interval_overlaps(
em_min, em_max,
ivo_specconv(1.5, "GHz", "m"),
ivo_specconv(1, "GHz", "m"))
doesn't work for you, let's think again and figure out something that's
less verbose. But let's not define something parallel to em_min and
em_max with an even more random unit than m.</pre>
</blockquote>
<p>and t Mark Kettenis Markus answered</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:20231211124653.53xl6evbwqovmflw@victor">
<pre class="moz-quote-pre" wrap=""><blockquote type="cite"><pre
class="moz-quote-pre" wrap=""></pre><blockquote type="cite"
style="color: #007cff;"><pre class="moz-quote-pre" wrap="">as using "Mhz" but f_resolution as using "kHz"). We do need to retain
f_resolution though as em_res_power simply varies too much for
low-frequency observations that span a large fractional bandwidth.
Radio observations typically have a fixed frequency reolution (and
therefore varying resolving power) across the band.
</pre></blockquote><pre class="moz-quote-pre" wrap="">For the record, I totally see the f_resolution agenda, but I'd
mildly advocate Hz as its unit. That's for intellectual economy
("um... was it kilohertz? ...megahertz? ...gigahertz?") and
because I feel writing f_resolution<30 isn't so much better than
writing f_resolution<30e3 as to justify memorising SI prefixes.</pre></blockquote>
</pre>
</blockquote>
<p><br>
</p>
<p>Yes I think it's reasonable to use the same unit, Hz for all the
frequency fields. We will change that in the draft.</p>
<p> That's much simpler than to find the right multiple for any
quantity and sub domain. You are right!</p>
<p><br>
</p>
<p>As for the frequency characterization, I would advocate :</p>
<p>Why are we building an ObsCore extension for radio data ?</p>
<p>We are indeed speaking of data discovery.</p>
<p>"core ObsCore" metadata help to discover any kind of datasets in
any spectral domain. But in the radio domain some specificities
are not well enough taken into account by the standard.</p>
<p>And this is specifically the case for raw data (visibilities in
the radio case) <br>
</p>
<p>The consequence is that the result of a query is only roughly
matching some of the discovery tasks.</p>
<p>The basic idea with the ObsCore extensions is the same than the
one we enhanced by creating some Optional fields in the original
ObsCore. Not forcing anything but ALLOWING to add details in order
to better tackle some specific needs.</p>
<p>When the CSP identified the rather low uptake of VO service in
the radio domain and defined the goal to fix that as an IVOA
priority, and when in parallel the Euro-VO Asterics project
(+ESCAPE) held several sessions around this, the first thing we
heard from many/many radio astronomers and potential users was :</p>
<p>"Hahh, gosh .... Wavelengths !!!"</p>
<p>After explaining these colleagues why we definitely needed a
common language for everybody and why wl is the minimal lingua
franca, we also considered to provide them with a couple of
additional fields useful for them.</p>
<p>In practice I imagine many radio archives start by storing their
metadata in frequencies and transform them into wavelengths using
functions, views or whatever to be consistent with ObsCore.<br>
</p>
<p>So for sure conversion udf probably exist anyway. But this is
implementation.</p>
<p>But If we provide an extension, then this extension should be
easy to use for queries and for metadata visualisation for the
users. And also for client developers.</p>
<p>Nobody is forced to use a radio extension. But if people are in
the spirit of using it then this has to be easy and readable for
them.</p>
<p>Last thing : if we have a parameter based interface to ObsCore
(and extensions) in a near future (see
:<a class="moz-txt-link-freetext" href="https://github.com/ivoa-std/DAP">https://github.com/ivoa-std/DAP</a>), frequency characterization will
be provided with an optional parameter and with standard column
names anyway. <br>
</p>
<p> <br>
</p>
<p>Cheers</p>
<p>François<br>
</p>
<p><br>
</p>
<p> <br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p></p>
</body>
</html>