[timeDomain: model for Time series] discussion on Timeseries Data model Note / ND-point .... or not ??? !!!

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Thu Aug 31 22:21:40 CEST 2017


All,

I am finally able to devote some time to the VO efforts, and have just been
reading through these discussions.
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 'concrete' and provided important feedback about what
is reasonable and usable.

Anyway.  My impression about the discussion...
1) NDPoint.
   One of the differences between Jiri'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 'event'.  I believe the
column-based approach looses this important relation.  Recall, the primary
use case for this is an Event List.

2) Errors
   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.

If the relation is a bit more broad, and the 'measure' 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.

If the data can not be described as a series of 'events'
  "at time T1, we measured these items"
  "this source, has these proprerties"
then the data is not a SparseCube.  I'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.

Mark

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170831/6d7c242e/attachment.html>


More information about the dal mailing list