Time Series Cube DM - IVOA Note
mdittmar at cfa.harvard.edu
Sat Feb 25 02:50:24 CET 2017
Can you make a statement about how you think this proposed arrangement
The Cube model has the following links to other models
a) Dataset - defines itself as an extension of ObsDataset
b) Coordsys - where coordinate system objects and the pattern for Frames
c) Coords - where the pattern for Coordinates is defined (and implemented
for several domains, but that is not important here)
d) Trans - where Transform mappings are defined.
NOTE: Coordsys, Coords and Trans are the component models of the STC2
Let's look closer at one of these:
You say that cube should not import Coords to identify what a Coordinate
is.. that it simply indicates that 'it has Coordinates'.
It currently says that an Observable is a coords:DerivedCoordinate .. which
is an abstract object restricted to
follow the pattern defined in that model. Any model can implement the
pattern and declare itself as that type of Coordinate,
and be instantly usable in a cube instance.
Without this explicit link, then one cannot validate across these
An instance would have
Element with role cube:DataAxis.observable
Instance with type <whatever implemented "Coordinate" type> ie:
But a validator cannot check if FluxCoord is actually a Coordinate... (I
could put a ds:Curation instance
there.. the role and the instance would be individually valid, but the
combination is nonsense).
With the link, a validator can see that the Instance must be a child of
and poll the spec:FluxCoord to see that it is.
And.. without the link, there is no binding the various implementations of
Coordinate to the pattern.
Interoperability would suffer because there would be no guarantee of
compatibility of different Coordinate types.
My code that understands the Coords pattern would have no hope of
understanding any portion of
independently defined Coordinates.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm