<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 & 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 <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> 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>> I wonder also if some thoughts on the usage of the term "cube" applies<br>
> here, because in my mind using "cube" alongside (e.g.) "image" at the<br>
> same level in a vocabulary mixes up format and content concepts (I know<br>
> 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 ["the extension"]) 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'd argue it's a suitable reflection of the use of<br>
that term in the community -- and then it's, indeed, a thing roughly<br>
on the same level as an image.<br>
<br>
But you'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's not how people right now think about data sets, and I'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're right, usage it'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'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 "axis" or "observable" 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'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's point: <br>
<br>
On Tue, 10 Mar 2020 11:47:48 +0100, Laurent MICHEL wrote:<br>
> I'm not sure that catalog data sets fit well within the definition<br>
> of the measurements. A catalog is not necessarily derived from a<br>
> dataset (Obcore P29 makes that distinction)<br>
<br>
So... what do you suggest to fix this? The definition I'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 "original dataset" _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>