<div dir="ltr"><div class="gmail_extra">Hi Mark,<div><br></div><div>thank you for the response. My comments/answers below.</div><div><br></div><div><br></div><div class="gmail_quote">2017-03-16 17:19 GMT+01:00 CresitelloDittmar, Mark <span dir="ltr">&lt;<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</a>&gt;</span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div></span><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></div></div></div></blockquote><div><br></div><div>Thanks for the explanation. Now I understand - I will correct it in my document.</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class="gmail-"><br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><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></span><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></div></div></div></div></blockquote><div><br></div><div>Well then do I need to keep them as part of the Cube DM, can&#39;t we keep it only in those respective models? Also connected with the point I put below:</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div></div></div></div></blockquote><div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">    + 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><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><blockquote class="gmail_quote" style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div></blockquote></span><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>I understand the purpose of the FrameMappings and CoordSys entities but again I don&#39;t think we need to make them part of the Cube DM. I belive that the physical domain model itself (Photometry DM, STC, Probability DM, ...) should take care of their own FrameMappings and CoordSys objects (still, if it&#39;s possible, I encourage them to use the existing models (coordsys, trans).</div></div></div><div><br></div><div>Anyway, could you point me to the documents where those are specified? I didn&#39;t find it in your document and am not sure how exactly is that coordsys or trans defined.</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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.</div></div></div></div></blockquote><div><br></div><div>What exactly do you keep in the NDPoint then? Is it only a simple Coord, or does it contain some metadata?</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></blockquote><div><br></div><div>We need to draw this on a *sheet* and talk about it - I can think of multiple instantiations of the abstractions that you used above (some would actually be really close to the ones I want to make with the TimeSeriesCube DM).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class="gmail-"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><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></span><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.<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="gmail-HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div></font></span></div></blockquote><div><br></div><div>I agree we need to discuss these - we can on the Asterics meeting next week if you will be there, otherwise a video call where we can share our drawings would be also good.</div><div><br></div><div>Output of such discussion should be a model of the abstractions we are using *with* the actual examples of data that are instances of those abstractions. This is I feel the main source of my confusion as a reader of other IVOA DMs, the lack of direct example that puts away the shadiness and shortens up the discussions about it a lot.</div><div><br></div><div>Cheers,</div><div><br></div><div>Jiri</div></div><br></div></div>