<div dir="ltr"><div>Jiri,<br><br></div>Thanks for the detailed response.. comments/responses below.<br><br><br><br><div><div><div><div class="gmail_extra"><div>On Mon, Mar 13, 2017 at 6:14 AM, Jiří Nádvorník <span dir="ltr">&lt;<a href="mailto:nadvornik.ji@gmail.com" target="_blank">nadvornik.ji@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><br><div style="font-size:12.8px"><span style="font-size:12.8px">@Mark Cressitello Dittmar</span><br></div><span class=""><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"> + Figure 2 and 3<br>      These nearly match cube model Section 4.2.. <br>      Time Series cube &#39;imports&#39; DatsetDM ~= basically identifies it as a SparseCubeDataset<br>      referencing one (only 1?) TimeSeriesCube which is an extension of the SparseCube data product.<br></blockquote><div style="font-size:12.8px"><br></div></span><div>We are indeed using Sparse Cube Dataset as a Time Series Cube is a subtype of Sparse Cube. The Dataset is a collection of such entities though and that means we can store 0..n Time Series Cube entities in the Sparse Cube Dataset we are using. <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px"> </div><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="">   + Section 3.1<br>      &quot;because we use them as black boxes, it does not matter if these data models change..&quot;<br>      I&#39;m not sure this is true.. or if it is, it is due to glossing over some details.<br>        o it looks like you&#39;re saying that a Time Series instance has ObsDataset metadata as <br>           described in &#39;the Dataset model&#39;.. presumably any version thereof<br></span><span class="">        o but you show the model import.. the vo-dml model import includes the URL to a specific version<br></span><span class="">        o and Figure 4 shows the cube relation of SparseCube with the SparseCubeDataset which <br>           extends the Dataset:ObsDataset object..<br></span><span class="">      It seems important for interoperability to have the explicit relations so that V2.0 of models<br>      can go through a vetting process before being acceptable/useable in subsequent models<br>      which use the V1.0.<br></span></blockquote><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Right, this was not spelled entirely correctly it seems. The idea is the if the Dataset or VO-DML model changes, we don&#39;t mind, because we are not extending these, we are not building anything on top of them that would break when these models change. Still, we are dependent on them as the Time Series Cube DM won&#39;t work without them, it&#39;s a dependency on their existence, not on their form.</div><div style="font-size:12.8px"><br></div></div></blockquote><div>OK<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px">Model import details:</div><div style="font-size:12.8px"><ul><li>Dataset DM - If it changes, we don&#39;t mind. We need to store a collection of our cubes, we leave the specification how to do so completely on the Dataset DM though.<br></li><li>VO-DML - We need it for annotating parts of serialization against the entities mentioned below. Anyway, we are dependent on existence of such mapping, not its syntax, as we are only adopting it and not trying to build something on top of it.</li><ul><li>Parts of the model (entities defined by the model)</li><li>The Data Model itself</li></ul></ul></div></div></blockquote><div>Not sure I understand the vo-dml statement.  Surely, if the vo-dml mapping syntax changes, you would need to change your annotation.  But yes.. you are using the syntax, not building on it.<br>OK<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px"><div>I feel this is a newer concept to the IVOA community and we need to make sure we understand it all in the same way. If I am dependent on an external model, that means the serialization of my data will change if that model changes. That doesn&#39;t mean, however, that I need to &quot;embed&quot; it into my data model, my data model is not changing if the on I am dependent on changes.</div></div></div></blockquote><div><br></div><div>Unless it changes at the interfaces..  If I am using element X from model M, and that element is changed, (as an extreme.. removed), your model may need to change to accommodate it.<br></div><div>Since that level of change in model M is not backward compatible, it would be a major version change in M.  Minor version changes in M would not require any update to your model.. True.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">      <br>   + Section 3.1.3<br>      &quot;We are not importing the whole VO-DML&quot;<br>      I&#39;m not sure what this means.. are you saying that this it not attempting to be fully vo-dml compliant?<br></blockquote><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div></span><div style="font-size:12.8px"><span style="font-size:12.8px">This means we <b>use</b> parts important for us, without trying to build on top of them. Effectively we are importing only parts of those models where we don&#39;t mind the syntax, only the semantics of what we are importing. We can discuss this on examples if needed.</span><br></div><span class=""><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div></span></div></blockquote>Yeah.. maybe that would be better.  I think the vocabulary here needs some adjusting.  There is nothing to import w.r.t. vo-dml annotation.  The spec will provide the syntax and you apply that in your serialization.<br><br> </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div style="font-size:12.8px"><span style="font-size:12.8px"></span></div><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">   + Section 3.2.1: Cube DM<br>      &quot;however, it is not describing Image Cube DM (as could be erroneously understood from the title)&quot;<br>      What?  pixelated image data is covered by NDImage (section 6 of the cube model)<br></blockquote><div style="font-size:12.8px"><br></div></span><div><span style="font-size:12.8px">That is maybe cause by my confusion. Is the data model defined in Figure 6 in  <a href="https://volute.g-vo.org/svn/trunk/projects/dm/CubeDM-1.0/doc/WD-CubeDM-1.0-20170203.pdf" target="_blank">IVOA N-Dimensional Cube Model</a></span><span style="font-size:12.8px"> the same one as described in this document <a href="http://wiki.ivoa.net/internal/IVOA/ImageDM/WD-ImageDM-20130812.pdf" target="_blank">IVOA Image Data Model</a> ?</span></div><span class=""><div style="font-size:12.8px"> </div><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">   + Section 3.2.3: Image DM<br>      see above..  the cube model covers the full scope of Doug&#39;s Image Cube model (2013)<br></blockquote><div><br></div></span><div>Same question -  is the Figure 6 in N-Dimensional Cube Model describing the same data model as Figure 2 in IVOA Image Data Model?</div><span class=""><div><br></div></span></div></blockquote><div><br></div><div>Yes.. the N-Dimensional Cube model is the continuation of that effort.. when I took over that project it was folded into the effort of extracting DatasetMetadata from these Product models and forming the family of Cube, Dataset, STC( coordsys, coords, trans ); and using vo-dml compliant modeling.   In that process, since the word &#39;Image&#39; invokes the &#39;pixelated image type&#39;, and the model covers a broader scope than that, it was renamed Cube.  The Cube model history includes the ImageDM iterations.<br></div><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div></div><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">   + Section 4/Figure 4<br>      your description of the TimeSeriesCube aligns pretty well with the SparseCube as it is..<br>      I&#39;m not sure it is necessary to &#39;override&#39; the content (btw you could just extend &quot;PointDataProduct&quot;)<br>      o the cube model SparseCube has a collecton of NDPoints (ie rows), which contains a collection <br>         of DataAxis, each referring to an instance of a measurement type coordinate (value + errors)<br>         * your representation and mine simply reverse the row/column order.<br>         * in cube, the Observable is any instance of Coordinate which follows the pattern described<br>           in STC2-coords model.  The modeling of that instance/domain does NOT have to be in <br>           any particular model.. so the Axis Domain DMs scenario you show works fine.<br>         * But.. for interoperability sake, we do require them to use the same pattern (by linking<br>           Observable to the abstract coords:DerivedCoordinate which is bound to a pattern)<br></blockquote><div><br></div></span><div>Yes, it is pretty similar - we used it as an inspiration and believe originally that we will just build upon it without changing it. Problems and difficulties listed beneath.</div><div><ol><li>Axis Domain models - physical meaning of the data in the axis of the data cube should not be part of the cube model. The Frame mappings and CoordSys entities taken from STC are also such domain models IMHO.</li></ol></div></div></blockquote><div>The cube model does not have any description of domain content.. (other than Pixel).<br></div><div>The Mappings and CoordSys objects are containers for pan-domain information defined in the respective models (coordsys, trans).<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li>Row/column inversion - this is a bigger difference than it seems on the first look. Logically we are storing the same information but I don&#39;t want to explicitely store a reference to an axis in every single point of the data cube. By this the Sparse Cube Model is IMHO saying that the data can be unordered and so we need to store the reference for every point? Doing it the other way around, the axis can just specify where I can find the axis coordinates in the data element of the cube, no matter how we serialize it.</li></ol></div></div></blockquote><div>I think the annotation should end up pretty similar, except that Row-based will sit in a grouping for the NDPoint object, while column based will not.<br></div><div>The axis reference is stored in the template next to the COLUMN spec.  Each iteration of the Template (table row) fills in the appropriate elements of the template.. in my case the values and errors of the DataAxis observables in an NDPoint.. in the column-based approach each iteration will fill in the next element of the the observables.. outside of an NDPoint.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li>What is the Observable entity&#39;s purpose in the diagram? Please explain..</li></ol></div></div></blockquote><div>Figure 2, 6, 7. Observable entity is a collection of Coordinates associated with the data product.  This is something to make sure is explained well.<br></div><div>The premise is that a DataProduct should OWN all of its coordinates/data.<br></div><div>The vo-dml rules for composition state that a class/object may not be in more than one composition relation.<br></div><div>  + so one does not make composition relations across models.<br></div><div>  + it defines an aggregation pattern to use  (as shown for DataProduct -&gt; Observable -&gt; DerivedObject ) for these situations<br><br>Since there are multiple types of Data Axis types, I modeled it this way.. where the DataProduct owns ALL its data (Observables), and the data axis types (DataAxis, DependentAxis) are organizational objects which refer to the instances of the same axis.<br><br></div><div>This could be organized differently.. having the Observables owned by the DataAxis (which is directly or indirectly owned by the DataProduct), and extend that for various types of axis.. adding constraints as needed.  The sub-classes of DataAxis would then each be in composition with some container (NDPoint, Voxel).  I don&#39;t know if this would be better/worse/indifferent.<br></div><div><br></div><div><span style="font-family:monospace,monospace">     &lt;DataAxis&gt; O---------- Cell  (constrain mult=1)<br></span></div><div><span style="font-family:monospace,monospace">         +              |__ DependentAxis (constrain mult=1)<br></span></div><div><span style="font-family:monospace,monospace">         |              |__ Column ?? <br></span></div><div><span style="font-family:monospace,monospace">         V  *<br></span></div><div><span style="font-family:monospace,monospace">     Observable<br>         |<br></span></div><div><span style="font-family:monospace,monospace">         V<br></span></div><div><span style="font-family:monospace,monospace">   coords:DerivedCoordiante<br></span></div><div><br> <br></div><div>I want to note one distinction.  The DataAxis here, is NOT the same as a coordinate space axis.<br></div><div>If I have a 3D cartesian Space, with coordinate axes x,y,z.. there is 1 DataAxis referring to a Position3D in that space.<br></div><div>I think this maps well to statements below.. where the &#39;Observable&#39; maybe need not be a DerivedCoordinate, but allow for complex objects like &quot;Spectrum&quot; <br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">    + Section 4.2.2<br><span style="font-size:12.8px">       cube model does not have dependency on specifc axis domains any more (since ~Nov)</span></blockquote><div><br></div></span><div>What about those FrameMappings and CoordSys entities? These are storing physical meaning of the data, not just describing the structure of the data (the data cube) itself.</div><span class=""><blockquote style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br></blockquote></span></div></blockquote><div><br>Yes, they are containers for storing the physical meaning of the data.  The content of a Cube or pixelated image is not devoid of physical meaning, if a sparse cube has data axes, each of these are of some physical quantity.. these elements allow you to describe that content without imposing restrictions about specific domains.<br></div><div><br></div><div> &lt;snip&gt;</div><br></div><div class="gmail_quote">So, I see we have 2 points of discussion for the cube model itself<br></div><div class="gmail_quote">  1) relation between Dataset and DataProduct<br></div><div class="gmail_quote">      Currently modeled as according to Section 3.. extend Dataset add reference to DataProduct == MyDataset<br></div><div class="gmail_quote"><br>      Alternates include:<br></div><div class="gmail_quote">        a) loose coupling<br></div><div class="gmail_quote">            verbal statement that MyDataset includes an instance of Dataset + instance of MyDataProduct<br></div><div class="gmail_quote">        b) referenced coupling<br></div><div class="gmail_quote">            MyDataSet == reference to Dataset + reference to MyDataProduct<br></div><div class="gmail_quote">            (allows validators to know what is expected, but allows flexibility w.r.t. Dataset flavor )<br></div><br></div><div class="gmail_extra">     I personally think a) is too loose, but b) might be a good way to go.. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">  2) relation of DataProduct, DataAxis and the &#39;Observable&#39;<br></div><div class="gmail_extra">      I haven&#39;t explored the alternative shown above very much, but like the possibility<br></div><div class="gmail_extra">      In the current relation, the DataProduct-Observable relation is a potential source of confusion to readers.<br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra">Mark<br><br></div></div></div></div></div>