<div dir="ltr"><div><div><div>Jiri,<br></div><br></div><br><div><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 19, 2017 at 2:48 PM, 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 style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-m_4941240487079063577gmail-"> <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"><span><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/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><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-"><div><br></div></span><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></div></div></blockquote><div><br></div><div>If I understand the questions..<br></div><div>The coordsys model defines the &quot;CoordSys&quot; and &quot;AstroCoordSys&quot; objects.  These are collections of associated Frames which fully define a coordinate space.<br></div><div>In the cube model, I want to say: &quot;A DataProduct has one or more Coordinate system specifications, and the DataProduct owns its instances of CoordSys&quot;<br></div>To do that, I must show a composition relation from cube:DataProduct to the coordsys:CoordSys elements.<br></div><div class="gmail_quote">The vo-dml rules restrict limit how compositions are done, the proper method is what is shown in the cube model... this is the aggregation pattern described in the vo-dml spec.<br><br></div><div class="gmail_quote">The same is true for FrameMappings... the Cube has a collection of Transform definitions which convert data from one Frame to another... this is where they go.<br></div><div class="gmail_quote"><div><br></div><div>My impression is not that you object to the items per se, but rather that they are explicitly connected in the model.. that it would be sufficient to simply serialize a coordsys instance in my cube, and since CoordSys is a valid, modeled object, that is all I need to do.  If this is so.. what is lost is the ability to validate the data product.  How do I know if the instance has all the expected components?<br></div><div><br></div>To do what I think you are suggesting, would require a change to the VO-DML specification.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><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"><div class="gmail_extra"><div class="gmail_quote"><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"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div></div></div></div></blockquote><div><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-m_4941240487079063577gmail-"><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"><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><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 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></div></blockquote></span></span><div><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-"><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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></span><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><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-"><div> </div></span></div></div></div></blockquote><div><br>CoordSys is in the coordsys model:<br>  vodml-html : <a href="https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/STC2/prototype/coordsys/STCCoordSys-2.0.html" target="_blank">https://volute.g-vo.org/svn/<wbr>trunk/projects/dm/vo-dml/<wbr>models/STC2/prototype/<wbr>coordsys/STCCoordSys-2.0.html</a><br><br><div>There are 2 types<br></div><div>  CoordSys = collection of GenericFrames<br></div><div>  AstroCoordSys = extension of CoordSys with 0..1 Frame from each implemented domain.<br><br></div><div>Transforms are in the trans model:<br>  <a href="https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/STC2/prototype/trans/STCTrans-2.0.html" target="_blank">https://volute.g-vo.org/svn/<wbr>trunk/projects/dm/vo-dml/<wbr>models/STC2/prototype/trans/<wbr>STCTrans-2.0.html</a><br></div><div><br></div> </div><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-"><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-m_4941240487079063577gmail-"><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"><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></span><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></div></blockquote><div><br></div><div>It boils down to a collection of Coordinate-s, the Coordinate has reference back to the Frame/Axis metadata.<br></div><div> </div><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-"><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-m_4941240487079063577gmail-"><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"><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></span><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). <br></div></div></div></div></blockquote><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-"><div><br></div><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-m_4941240487079063577gmail-"><div><br></div><div><br></div><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"><span><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></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-m_-5932919569147512871gmail-m_-7684289776120948557gmail-m_4941240487079063577gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="gmail-m_-5932919569147512871gmail-m_-7684289776120948557gmail-m_4941240487079063577gmail-HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div></font></span></div></blockquote><div><br></div></span><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></div></div></blockquote><div><br></div><div>No.. I won&#39;t be there.<br></div><div>I agree we would benefit from some shared focus time.. perhaps we can arrange a time off-line to work this?<br></div><div>Mark<br><br></div><div><br><br> </div></div><br></div></div></div></div>