Time Series Cube DM - IVOA Note
mdittmar at cfa.harvard.edu
Thu Feb 16 19:16:58 CET 2017
Thank you for sharing this.. I have read through the model part (up to
science cases) and am pleased to
see that there is a high degree of compatibility with the Cube
representation. So much so that I'm
confused about comments/objections regarding the cube model dependencies.
(most recent draft of the ndcube model which I'll make connections to
+ Figure 2 and 3
These nearly match cube model Section 4.2..
Time Series cube 'imports' DatsetDM ~= basically identifies it as a
referencing one (only 1?) TimeSeriesCube which is an extension of the
SparseCube data product.
+ Section 3.1
"because we use them as black boxes, it does not matter if these data
I'm not sure this is true.. or if it is, it is due to glossing over
o it looks like you're saying that a Time Series instance has
ObsDataset metadata as
described in 'the Dataset model'.. presumably any version thereof
o but you show the model import.. the vo-dml model import includes
the URL to a specific version
o and Figure 4 shows the cube relation of SparseCube with the
extends the Dataset:ObsDataset object..
It seems important for interoperability to have the explicit
relations so that V2.0 of models
can go through a vetting process before being acceptable/useable in
which use the V1.0.
+ Section 3.1.3
"We are not importing the whole VO-DML"
I'm not sure what this means.. are you saying that this it not
attempting to be fully vo-dml compliant?
+ Section 3.2.1: Cube DM
"however, it is not describing Image Cube DM (as could be erroneously
understood from the title)"
What? pixelated image data is covered by NDImage (section 6 of the
+ Section 3.2.3: Image DM
see above.. the cube model covers the full scope of Doug's Image
Cube model (2013)
+ Section 4/Figure 4
your description of the TimeSeriesCube aligns pretty well with the
SparseCube as it is..
I'm not sure it is necessary to 'override' the content (btw you could
just extend "PointDataProduct")
o the cube model SparseCube has a collecton of NDPoints (ie rows),
which contains a collection
of DataAxis, each referring to an instance of a measurement type
coordinate (value + errors)
* your representation and mine simply reverse the row/column order.
* in cube, the Observable is any instance of Coordinate which
follows the pattern described
in STC2-coords model. The modeling of that instance/domain does
NOT have to be in
any particular model.. so the Axis Domain DMs scenario you show
* But.. for interoperability sake, we do require them to use the
same pattern (by linking
Observable to the abstract coords:DerivedCoordinate which is
bound to a pattern)
+ Section 4.2.2
cube model does not have dependency on specifc axis domains any more
+ Section 4.2.3:
"it can go to the axis domain model through the model parameter of
?? is this describing how one would follow the vo-dml annotation to
find the axis/frame metadata?
On Tue, Feb 7, 2017 at 7:39 AM, Jiří Nádvorník <nadvornik.ji at gmail.com>
> there were calls to share this effort within the data modelling group,
> even when the primary interested is the TDIG.
> Please read the forwarded message.
> Kind regards,
> Jiri Nadvornik
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm