<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi Markus,</div><div class="gmail_default" style="font-family:monospace">thank you for the clarification on the first two points</div><div class="gmail_default" style="font-family:monospace">I raised (obscore+EPN &amp; SimpleDALRegExt-attached reviewing).</div></div><div><br></div><div><div class="gmail_default" style="font-family:monospace">About...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><span class="gmail_default" style="font-family:monospace"></span>Il giorno mar 10 mar 2020 alle ore 13:14 Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; ha scritto:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Mar 10, 2020 at 11:56:36AM +0100, Molinaro, Marco wrote:<br>&gt; I wonder also if some thoughts on the usage of the term &quot;cube&quot; applies<br>
&gt; here, because in my mind using &quot;cube&quot; alongside (e.g.) &quot;image&quot; at the<br>
&gt; same level in a vocabulary mixes up format and content concepts (I know<br>
&gt; this already works in obscore).<br>
<br>
Yes -- while I think honing the definitions is a good idea, I guess<br>
we should try to keep the concepts (as in: the set of real-world<br>
things [&quot;the extension&quot;]) as they are actually being used.<br>
<br>
Saying that a cube is three or more dimensions may be a bit<br>
arbitrary, but I&#39;d argue it&#39;s a suitable reflection of the use of<br>
that term in the community -- and then it&#39;s, indeed, a thing roughly<br>
on the same level as an image.<br>
<br>
But you&#39;re right, we are mixing dimensionality (cube) with properties<br>
of the observable (image) with properties of the axes (time series,<br>
spectrum).  In an ideal world, these would be considered separately.<br>
But that&#39;s not how people right now think about data sets, and I&#39;m<br>
not sure I can see a major problem with this.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">Maybe you&#39;re right, usage it&#39;s there.</div><div class="gmail_default" style="font-family:monospace">Still for filtering/discovery it may raise issues in the future</div><div class="gmail_default" style="font-family:monospace">and we&#39;re going registry here, which is slightly more difficult</div><div class="gmail_default" style="font-family:monospace">than dataset annotation to change later on.</div><div class="gmail_default" style="font-family:monospace">I mean, if I want a specific &quot;axis&quot; or &quot;observable&quot; cube, I can</div><div class="gmail_default" style="font-family:monospace">rely on o_ucd or else, true...but not in the registry.<br></div><div class="gmail_default" style="font-family:monospace">But maybe I&#39;m getting ahead of a non existent issue here...</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And, also from this thread, Laurent&#39;s point: <br>
<br>
On Tue, 10 Mar 2020 11:47:48 +0100, Laurent MICHEL wrote:<br>
&gt; I&#39;m not sure that catalog data sets fit well within the definition<br>
&gt; of the measurements.  A catalog is not necessarily derived from a<br>
&gt; dataset (Obcore P29 makes that distinction)<br>
<br>
So... what do you suggest to fix this?  The definition I&#39;m currently<br>
proposing is<br>
<br>
  A set of derived measurements obtained from a particular original<br>
  dataset.  The prototypical example would be a list of sources<br>
  extracted from an image.<br>
<br>
What would you like to see changed?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">Does it have to be &quot;original dataset&quot; _singular_?</div><div class="gmail_default" style="font-family:monospace"></div><div class="gmail_default" style="font-family:monospace">   Marco</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
         -- Markus<br>
</blockquote></div><br clear="all"><div><br></div>-- <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 040 3199 152</span><br></div></div></div></div></div></div></div>