Time Series Cube DM - IVOA Note

[CresitelloDittmar, Mark]

Markus/All,

This is getting very Coords specific, so we may want to spawn a new thread
for discussion on this.

On Thu, Mar 16, 2017 at 7:03 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> <GROUP vodml-type="ivoa:Quantity">
>   <!-- all measurements (can) have errors, min/max vals, etc, so
>   there's no point separately modelling this in cube, stc,
>   photometry, etc.; let's have ivoa:Quantity for that. -->
>   <FIELDref vodml-role="value" ref="obs_date"/>
>   <FIELDref vodml-role="standard-deviation" ref="err_time"/>
>   <PARAM name="minimum" value="56493.339"/>
>   <PARAM name="maximum" value="56498.341"/>
>   <!-- which also does much of char:, without introducing 1000s of
>   utypes -->
> </GROUP>
>
> <snip>

> What's really missing at this point as far as standards are concerned
> is, as far as I know, ivoa:Quantity (or perhaps we should have a DM
> of its own?  I suspect Quantity will go through several revisions as
> it starts getting used).
>
> Can anyone summarise the state of Quantity modelling?  I always get a
> bit lost in all the artefacts in volute's dm branch...
>
> Cheers (and with apologies if this indeed comes a bit late),
>
>            Markus
>

As I mentioned in the last mail, this object corresponds to the coords
pattern ( value + errors ).
So.. IF we agree that a measurement is a measurement, and there is no need
to specialize by domain, then that model can be greatly simplified..
leaving the 'domain' specialization to the coordsys model (frames and
'values' within the coordinate space).

I mocked this model change and re-generated the sparse cube example using
this model spec.
see:
https://volute.g-vo.org/svn/trunk/projects/dm/CubeDM-1.0/examples/chandra_events_annotated_alt.vot
you can compare with the non '_alt' version.

The change is:
  coords model:
    + take the implementation under "Spatial" domain, where the 1,2,3D
implementations exist
    + make the coord value type 'coordsys:AbsoluteCoordinate'
    + rename it Coordinate1D, Coordinate2D, Coordinate3D
    + strip the entire domain package (all specializations of the
DerivedCoordinate by domain)

This change makes all derived/measured coordinates (value+error)
equivalent, with a specialized 'value' by domain.
They are specialized in the sense that they have specific
primitive/Quantity values, and refer to specific flavors of Frame axis...
that is all in the coordsys model.

By doing this, it enables the usage that Markus mentioned.  A 'coords'
savvy user can find all coordinates in the serialization regardless of the
product in which they reside (like cube or timeseries).

IF you think this is a valid usage of the annotated dataset, then I would
add it to the requirements for cube/stc and formalize this change.  Again,
personally, I think this would be a good move... it simplifies the coords
model without too much cost and enables what appears to be a reasonable
use-case.

Let me know what you think!
Mark

PS:  This set of objects... Quantity, DerivedCoordinate, AbsoluteCoordinate
gets down to the level of Quantity vs Measurement which has been a
long-discussed topic with little resolution.  In my view of things
   + Quantity (DataType) is a 'physical value', when you don't really care
what the Frame association is.
   + AbsoluteCoordinate (DataType) is essentially the primitive/Quantity
types when you care which Frame/axis is involved
   + DerivedCoordinate (ObjectType) is a 'measured' or 'calculated' value (
value + error ).  With these, we typically care about the Frame/axis
associations so it uses AbsoluteCoordinate for the 'value', and Quantity in
the Errors since the assumption is that the errors are in the same frame as
the value, though not necessarily in the same units.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170318/4c125871/attachment.html>