<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Thanks Markus, Baptiste, Ada (direct email),</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">indeed I should look better into the time series Note.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">The doubt that I still have (that applies also when</div><div class="gmail_default" style="font-family:monospace">using the dynamic-spectrum as the datatype) is about</div><div class="gmail_default" style="font-family:monospace">the user experience (at the obscore/epncore discovery</div><div class="gmail_default" style="font-family:monospace">stage) when they see a spectral axis ranging 237-2695MHz</div><div class="gmail_default" style="font-family:monospace">but actually getting back what are actually multiple</div><div class="gmail_default" style="font-family:monospace">1D, single frequency, time series (time axis is sampled</div><div class="gmail_default" style="font-family:monospace">uniformly, no troubles there), sparsely distributed over</div><div class="gmail_default" style="font-family:monospace">the range band.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I do trust applications to read correctly the FITS bintables</div><div class="gmail_default" style="font-family:monospace">(or whatever other format we might come up), but I wonder</div><div class="gmail_default" style="font-family:monospace">if the sparse em would be confusing.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Since it's not an urgent matter, if we (local group)</div><div class="gmail_default" style="font-family:monospace">progress on this by the time of June, I might try to</div><div class="gmail_default" style="font-family:monospace">provide a quick report there.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thanks again!</div><div class="gmail_default" style="font-family:monospace">Cheers</div><div class="gmail_default" style="font-family:monospace">    Marco</div><div class="gmail_default" style="font-family:monospace"><br></div></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Il giorno mar 25 mar 2025 alle ore 12:25 Baptiste Cecconi via semantics <<a href="mailto:semantics@ivoa.net">semantics@ivoa.net</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I Marco, <div><br></div><div>if I understand well, you have 3 dynamic-spectra (each having 6 spectral channels).</div><div>The <a href="http://www.ivoa.net/rdf/product-type#dynamic-spectrum" target="_blank">http://www.ivoa.net/rdf/product-type#dynamic-spectrum</a> data product should applicable. </div><div><br></div><div>In epncore, this should be no problem to describe the spectral axis. Nothing prevents to have sparse spectral axes in the datasets. </div><div><br></div><div>Cheers</div><div>Baptiste</div><div><br><div><br><blockquote type="cite"><div>Le 24 mars 2025 à 09:47, Markus Demleitner via semantics <<a href="mailto:semantics@ivoa.net" target="_blank">semantics@ivoa.net</a>> a écrit :</div><br><div><div>Hi Marco,<br><br>On Fri, Mar 21, 2025 at 06:26:59PM +0100, Molinaro, Marco via semantics wrote:<br><blockquote type="cite">for a "heritage data" project we have a set of observations<br>that consist of time series of nearly monochromatic RHCP & LHCP<br>radio fluxes of the full disk Sun.<br><br>Unfortunately the files they are stored in (FITS bintables)<br>contain:<br>- the 6 individual observational frequencies, sparse from 237Mhz to 2.7GHz<br>- for each of them 3 time series: LHCP, RHCP and the sum of them (full flux)<br><br>This leads us to describe them, no matter if in obscore or epncore,<br>as 6 separate time series records referencing the same FITS dataset,<br>because we are unable to describe the sparse "em" axes.<br></blockquote><br>Well, as long as the time axis is sampled uniformly, there is nothing<br>that would keep you from having just one time series with 18 columns,<br>and I believe clients like SPLAT would do a reasonable job displaying<br>them.<br><br>If the time axis is not sampled uniformly over all frequencies, I<br>think I'd go for per-frequency time series with one column each for<br>the three observation modes.<br><br>All that is based on what I think will make this data easy to work<br>with with generic VO tools, completely independently of the<br>underlying physics and in particular community practice.  Therefore:<br><br><blockquote type="cite">Or maybe Radio, HE, TD IGs have some insight on this.<br></blockquote><br>I'd frankly ask Solar System first (and its vice chair already<br>confesses he can't help here).  I'd say *if* there's some dominant<br>practice in the community, whatever format that calls for is what I'd<br>serve up by default; and then I'd attach a datalink that yields<br>SDM-compliant tables with Ada blocks (:-)<br><<a href="http://ivoa.net/documents/Notes/LightCurveTimeSeries/index.html" target="_blank">http://ivoa.net/documents/Notes/LightCurveTimeSeries/index.html</a>><br>for interoperability beyond that community.<br><br>Consider this as not much more than my 2 cents, though.<br><br>        -- Markus<br><br></div></div></blockquote></div><br></div></div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="monospace">Marco Molinaro</font></div><div><font face="monospace">INAF - Istituto Nazionale di AstroFisica</font></div><div><font face="monospace">Osservatorio Astronomico di Trieste</font></div><div><font face="monospace">email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a></font></div><div><span style="font-family:monospace">tel. [+39] 333 33 20 564 [also Telegram]</span><br></div></div></div></div></div></div></div>