<div dir="ltr"><div><div><div><div><div><div><div><div>Jiri,<br><br></div>Thank you for sharing this.. I have read through the model part (up to science cases) and am pleased to <br></div>see that there is a high degree of compatibility with the Cube representation.  So much so that I&#39;m <br></div>confused about comments/objections regarding the cube model dependencies.<br><br></div><div><br></div>Some comments:<br></div>   <a href="https://volute.g-vo.org/svn/trunk/projects/dm/CubeDM-1.0/doc/WD-CubeDM-1.0-20170203.pdf">https://volute.g-vo.org/svn/trunk/projects/dm/CubeDM-1.0/doc/WD-CubeDM-1.0-20170203.pdf</a> <br></div>   (most recent draft of the ndcube model which I&#39;ll make connections to below)<br><br></div>   + Figure 2 and 3<br><div><div>      These nearly match cube model Section 4.2.. <br></div><div>      Time Series cube &#39;imports&#39; DatsetDM ~= basically identifies it as a SparseCubeDataset<br></div><div>      referencing one (only 1?) TimeSeriesCube which is an extension of the SparseCube data product.<br><br></div><div>   + Section 3.1<br></div><div>      &quot;because we use them as black boxes, it does not matter if these data models change..&quot;<br><br></div><div>      I&#39;m not sure this is true.. or if it is, it is due to glossing over some details.<br></div><div>        o it looks like you&#39;re saying that a Time Series instance has ObsDataset metadata as <br></div><div>           described in &#39;the Dataset model&#39;.. presumably any version thereof<br></div><div>        o but you show the model import.. the vo-dml model import includes the URL to a specific version<br></div><div>        o and Figure 4 shows the cube relation of SparseCube with the SparseCubeDataset which <br></div><div>           extends the Dataset:ObsDataset object..<br></div><div><br></div><div>      It seems important for interoperability to have the explicit relations so that V2.0 of models<br></div><div>      can go through a vetting process before being acceptable/useable in subsequent models<br></div><div>      which use the V1.0.<br></div><div>      <br></div><div>   + Section 3.1.3<br></div><div>      &quot;We are not importing the whole VO-DML&quot;<br></div><div>      I&#39;m not sure what this means.. are you saying that this it not attempting to be fully vo-dml compliant?<br><br></div><div>   + Section 3.2.1: Cube DM<br></div><div>      &quot;however, it is not describing Image Cube DM (as could be erroneously understood from the title)&quot;<br></div><div>      What?  pixelated image data is covered by NDImage (section 6 of the cube model)<br><br></div><div>   + Section 3.2.3: Image DM<br></div><div>      see above..  the cube model covers the full scope of Doug&#39;s Image Cube model (2013)<br><br></div><div>   + Section 4/Figure 4<br></div><div>      your description of the TimeSeriesCube aligns pretty well with the SparseCube as it is..<br></div><div>      I&#39;m not sure it is necessary to &#39;override&#39; the content (btw you could just extend &quot;PointDataProduct&quot;)<br><br></div><div>      o the cube model SparseCube has a collecton of NDPoints (ie rows), which contains a collection <br></div><div>         of DataAxis, each referring to an instance of a measurement type coordinate (value + errors)<br></div><div>         * your representation and mine simply reverse the row/column order.<br></div><div>         * in cube, the Observable is any instance of Coordinate which follows the pattern described<br></div><div>           in STC2-coords model.  The modeling of that instance/domain does NOT have to be in <br></div><div>           any particular model.. so the Axis Domain DMs scenario you show works fine.<br></div><div>         * But.. for interoperability sake, we do require them to use the same pattern (by linking<br></div><div>           Observable to the abstract coords:DerivedCoordinate which is bound to a pattern)<br></div><br></div>    + Section 4.2.2<br></div>       cube model does not have dependency on specifc axis domains any more (since ~Nov)<br><div><div><div><div><br></div><div>    + Section 4.2.3:<br></div><div>       &quot;it can go to the axis domain model through the model parameter of that axis&quot; <br></div><div>       ??  is this describing how one would follow the vo-dml annotation to find the axis/frame metadata?<br><br></div><br><div>Mark<br><br></div><div><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 7, 2017 at 7:39 AM, Jiří Nádvorník <span dir="ltr">&lt;<a target="_blank" href="mailto:nadvornik.ji@gmail.com">nadvornik.ji@gmail.com</a>&gt;</span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">Hello,<div><br><div>there were calls to share this effort within the data modelling group, even when the primary interested is the TDIG. </div><div><br></div><div>Please read the forwarded message.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Jiri Nadvornik</div><br></div></div></blockquote></div></div></div></div></div></div></div></div>