<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Dear all,<br>
</p>
<br>
<div class="moz-cite-prefix">Le 14/07/2017 à 13:39, Jiří Nádvorník a
écrit :<br>
</div>
<blockquote cite="mid:009d01d2fc95$ebfe3d80$c3fab880$@gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<div class="WordSection1">
<p class="MsoNormal"><span>Hi,</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Thank you, see inline.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Jiri</span></p>
<p class="MsoNormal"><span> </span></p>
<div>
<div>
<div>
<p class="MsoNormal"><b><span>From:</span></b><span>
François Bonnarel
[<a class="moz-txt-link-freetext" href="mailto:francois.bonnarel@astro.unistra.fr">mailto:francois.bonnarel@astro.unistra.fr</a>] <br>
<b>Sent:</b> Thursday, July 13, 2017 11:52 PM<br>
<b>To:</b> Jiří Nádvorník
<a class="moz-txt-link-rfc2396E" href="mailto:nadvornik.ji@gmail.com"><nadvornik.ji@gmail.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:mireille.louys@unistra.fr">mireille.louys@unistra.fr</a>; <a class="moz-txt-link-abbreviated" href="mailto:dm@ivoa.net">dm@ivoa.net</a>;
<a class="moz-txt-link-abbreviated" href="mailto:voevent@ivoa.net">voevent@ivoa.net</a>; <a class="moz-txt-link-abbreviated" href="mailto:dal@ivoa.net">dal@ivoa.net</a><br>
<b>Subject:</b> Re: [timeDomain: model for Time
series] discussion on Timeseries Data model Note / how
are ND-Cube DM and Timeseries DM connected ?</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p> </p>
<p class="MsoNormal">Hi Jiri,<br>
Thanks for having given a look to these emails. This is a
very important discussion and we have to all agree on these
grounds before going to more TimeSeries specific features of
the model we need.</p>
<div>
<p class="MsoNormal">Le 13/07/2017 à 15:02, Jiří Nádvorník a
écrit :</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Hi Mireille,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thank you very much for the input. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Your diagram is almost correct, but I
believe that the relationship </p>
<p class="MsoNormal">TimeSeriesCube <is a >
NDCubeDM::SparseCubeDataset</p>
<p class="MsoNormal">Is not correct, even in the original
idea Mark Cresitello Ditmar had (please correct me here
if I’m wrong, Mark). The correct relationship is:</p>
<p class="MsoNormal">TimeSeriesCube <is a>
NDCubeDM::SparseCube and</p>
<p class="MsoNormal">NDCubeDM::SparseCube <is collected
by> NDCubeDM::SparseCubeDataset</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">As seen on the following image:</p>
<p class="MsoNormal"><img id="Obrázek_x0020_1"
src="cid:part1.7CA5157D.B7FAF6B9@astro.unistra.fr"
height="360" width="299"></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Meaning that the SparseCubeDataset is
describing a collection of data cubes, e.g., time series
data, e.g., light curves, *<b>not</b>* one cube, e.g.,
one time series, e.g., one light curve. If we agree that
we don’t need collections of time series (because they
can by themselves be multi-dimensional), we can change
it to <is a> relationship as you propose.</p>
</div>
</blockquote>
<p class="MsoNormal">OK. This is were we differ. I don't think
SparSecubedataset is made for tackling collections. My
interpretation of the ND-Cube diagram helped by MCD' text is
that SparSeCubeDataset inheritance from ObsDataSet contains
all generic metadata for a dataset which may be COMPLEX.
That is it contains : curation, provenance, identification,
characterisation.<br>
<br>
Such a SparseCubeDataset may contain one (simple dataset)
or several (complex dataset) "SparseCubes"<br>
<br>
Each of these SparseCube(s) contains ND-points where the
actual data are stored and inherits from the DataProduct
class the coordinate systems and mappings of the data to
physical coordinates.<br>
<br>
As Mireille said the "<i>dataproduct_type</i> " of your
TimeSeriesCube (or TimeSeriesDataSet) can only be inherited
from ObsDataSet through SparseCube Dataset and not from
DataProduct via SparseCube.<span></span></p>
<p class="MsoNormal"><b><i><span>[[Jiri Nadvornik]] Ha, so
this means that each row we see in ObsCore table is
describing a DataSet, meaning Spectrum <is a>
DataSet, Image <is a> DataSet, SED <is a>
DataSet, event <is a> Dataset, etc.? I can also
see a valid option dataproduct_type=cube in the
ObsCore document (<a moz-do-not-send="true"
href="http://www.ivoa.net/documents/ObsCore/20111028/REC-ObsCore-v1.0-20111028.pdf"><span>http://www.ivoa.net/documents/ObsCore/20111028/REC-ObsCore-v1.0-20111028.pdf</span></a>
)</span></i></b></p>
<p class="MsoNormal"><b><i><span> </span></i></b></p>
</div>
</div>
</blockquote>
<i><b>Yes that is it.</b></i><br>
<blockquote cite="mid:009d01d2fc95$ebfe3d80$c3fab880$@gmail.com"
type="cite">
<div class="WordSection1">
<div>
<p class="MsoNormal"><b><i><span>If the assumptions above are
correct, I concur that changing the relationship to
TimeSeries <is a> Cube <is a> DataSet is
not a bad idea. From my point of view, this can be
changed in the model rather easily – it will just
introduce a more tight coupling between DataSet and
TimeSeriesCube data model. TimeSeriesCube data model
will need to import everything from the DataSet DM and
if something changes in DataSet DM, it will need to
change in TimeSeriesCube DM too. In other words, new
major versions of DataSet DM will require new major
versions of TimeSeriesCube DM to follow.</span></i></b></p>
<p class="MsoNormal"><br>
</p>
</div>
</div>
</blockquote>
I think DataSet DM is made to be reused in different specific
contexts.<br>
<br>
Cheers<br>
François<br>
<blockquote cite="mid:009d01d2fc95$ebfe3d80$c3fab880$@gmail.com"
type="cite">
<div class="WordSection1">
<div>
<p class="MsoNormal"><br>
<br>
Cheers<br>
François<br>
<br>
<br>
<br>
<br>
</p>
<blockquote>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Now the Time series class is
described in the attached UML.pdf (please note that this
one is different from the original note, this version
was last updated after Shanghai Interop in May). Main
difference is that the TimeSerieCubeDM::CubeAxis custom
class was replaced just by a generic columnRef (yellow)
saying where can I find the data for this axis and that
axis is described by Quantity class (yellow). </p>
<p class="MsoNormal">The Quantity class indeed provides
the *<b>richer description*</b> on the cube axis (not
only the time axis). This is indeed correlated by
STC2.0::CoordMeasurement, but we got into conflict in
here, as we would like to use it not for describing only
*<b>uncertainties</b>* in the Measurement, but for
statistical distribution in the whole axis, that’s why
we are trying to create an abstraction above both
CharacterisationDM::ObservableAxis and
STC2.0::CoordMeasurement describing only the statistical
properties of both. The Quantity class is just a sketch
what could be described by it – the final solution would
be to store a mixture of gaussians in it, describing the
distribution in a generic way.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I completely agree with the rest – we
can discover TimeSeries data cubes by <i>dataproduct_type</i>
and <i>target_name, s_region, s_resol, t_min, t_max,
t_resol, em_min, em_max, em_resol, etc. </i>Attributes
right now.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">How to extend these Obscore discovery
parameters to discover time series by more details of
their axes, we need to agree on how the distribution of
values on them will be described in the time series.
From the data point of view, a *<b>mixture of gaussian</b>*
based abstraction above measurement uncertainties and
axis statistical distributions would be perfect, but I
don’t know whether we can provide that description for
any type of time series axis.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Cheers,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Jiri</p>
<div>
<div>
<div>
<p class="MsoNormal"><b>From:</b> <a
moz-do-not-send="true"
href="mailto:dm-bounces@ivoa.net">dm-bounces@ivoa.net</a>
[<a moz-do-not-send="true"
href="mailto:dm-bounces@ivoa.net">mailto:dm-bounces@ivoa.net</a>]
<b>On Behalf Of </b>Mireille Louys<br>
<b>Sent:</b> Wednesday, July 12, 2017 10:57 AM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:dm@ivoa.net">dm@ivoa.net</a>; <a
moz-do-not-send="true"
href="mailto:voevent@ivoa.net">voevent@ivoa.net</a>;
<a moz-do-not-send="true"
href="mailto:dal@ivoa.net">dal@ivoa.net</a><br>
<b>Subject:</b> [timeDomain: model for Time
series] discussion on Timeseries Data model Note /
how are ND-Cube DM and Timeseries DM connected ?</p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Dear DM and Time Domain followers,
<br>
<br>
I am trying, together with my CDS colleagues, to
recap on the various DMs available in the IVOA and
understand the possible links between the future Time
Series Model ( as sketched in Jiris's Note) and
existing DMs like ND-Cube and STC 2.<br>
<br>
Here is a graph proposed by Laurent Michel to clarify
the links in 3 main parts : </p>
<ul type="disc">
<li class="MsoNormal"><i>DataSetMetadata DM</i>, which
has the main ObsDataset Class ,</li>
<li class="MsoNormal"><i>ND-CubeDM</i>, which defines
a SparseCubedataset</li>
<li class="MsoNormal"><i>TimeSerieCubeDM</i>, which
highlights the special properties of a Cube
depending on a Time axis</li>
</ul>
<p class="MsoNormal">I think this is essential to
highlight the inheritance path between these 3 DM
building blocks: <br>
a TimeSeriesCube <is a >
NDCubeDM::SparseCubeDataset<br>
a NDCubeDM::SparseCubeDataset <is a >
DatasetMetadaDM::ObsDataset<br>
<br>
ObsDataset has a <i>dataproduct_type</i> attribute
which allows to discover all dataproducts of type '
timeseries'. <br>
this provides the container object for time-dependent
data.<br>
<br>
If we need to select <i>timeseries dataproducts</i>
according to some properties extracted from their data
we can:<br>
- reuse what Obscore DM provides to explain general
axes properties<br>
target_name, s_region, s_resol, t_min, t_max, t_resol,
em_min, em_max, em_resol, etc. are the basic
properties for discovery<br>
<br>
- provide a richer description of the TimeAxis and
ObservableAxis. <br>
For that , extracting a statistical profile from the
data contained in the Cube could do the job. <br>
this means to access and analyse the Data part in
ND-Cube , i. e the ND-Points gathered in a SparseCube
Object</p>
<p class="MsoNormal"><br>
<br>
I guess more properties can be exposed to qualify the
axes present in the Timeseries dataset , but for the
moment , I see some overlap of notions between <br>
CharacterisationDM::ObservableAxis,
STC2.0::CoordMeasurement (??) and
TimeSerieCubeDM::CubeAxis.<br>
<br>
This would be great if we could sort this out, <br>
but currently , I would appreciate your feedback on
the attached diagram , in order to proceed on the data
model structure. <br>
<br>
Cheers, Mireille ( after discussions together with
Laurent, François, Ada) <br>
<br>
</p>
<pre>-- </pre>
<pre>--</pre>
<pre>Mireille Louys</pre>
<pre>CDS Laboratoire Icube </pre>
<pre>Observatoire de Strasbourg Telecom Physique Strasbourg</pre>
<pre>11 rue de l'Université 300, Bd Sebastien Brandt CS 10413 </pre>
<pre>F- 67000-STRASBOURG F-67412 ILLKIRCH Cedex</pre>
<pre>tel: +33 3 68 85 24 34</pre>
</div>
</div>
</blockquote>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
<br>
</body>
</html>