<div dir="ltr"><div><div><div><div><div><div>All,<br><br></div>I am finally able to devote some time to the VO efforts, and have just been reading through these discussions.<br></div>Maybe someone could summarize for me what the current state is.  I would like to get back to iterating through example serializations as that seemed to make things more &#39;concrete&#39; and provided important feedback about what is reasonable and usable.<br><br></div><div>Anyway.  My impression about the discussion...<br></div><div>1) NDPoint.<br></div>   One of the differences between Jiri&#39;s approach in the Note, and the Cube model is that my model has this element which, as Francois noted, is primarily to associate a set of Observables as being related.  The NDPoint collects data axes (time, pos, energy, mag ).  Each instance of NDPoint is a set of values which describe a single &#39;event&#39;.  I believe the column-based approach looses this important relation.  Recall, the primary use case for this is an Event List.<br><br></div>2) Errors<br></div>   The Observables in the cube model are STC CoordMeasure instances, which include the measured value, associated error, and frame reference.   The error modeling to date is assuming a 1-1 association of the value to its error (eg Value +/- Error ).  The modeling of errors in STC2 is very extensible and targets the most common error types.  It is very compatible to have a separate effort take place to model other sorts of errors ( statistical distributions ) and extend the base STC-2 error class.<br></div><div><br>If the relation is a bit more broad, and the &#39;measure&#39; itself is a statistical distribution kind of thing, then what you are describing is not an Observable.  This sort of thing I expected might come up with simulated data (when we think about bringing SimDM and Cube more in line with each other.. (they are quite compatible)).  If this is the case, we we should define a different kind of DataAxis which better facilitates the statistical/mathematical nature of the measurement.<br></div><div><div><div><div><div><br></div><div>If the data can not be described as a series of &#39;events&#39;<br></div><div>  &quot;at time T1, we measured these items&quot;<br></div><div>  &quot;this source, has these proprerties&quot;<br></div><div>then the data is not a SparseCube.  I&#39;m under the impression that most time series do fit this description, but if there are some which do not, we should evaluate an example to see if it needs a different sort of DataProduct.<br><br></div><div>Mark<br></div><div><br><div><div>​</div></div></div></div></div></div></div></div>