Time Series Cube DM - IVOA Note

[Markus Demleitner]

Hi Mark,

On Mon, Apr 17, 2017 at 10:57:33AM -0400, CresitelloDittmar, Mark wrote:
> Do we have any comment on this alternative yet?
> We have proceeded with the coords/coordsys stuff assuming this approach,
> but I have not migrated the 'official' cube model and doc yet.
> 
> my utility now produces the timeseries example, along with the others
> (event list, images)
> I also added about 10 other specific cases which focus on a particular area:
> 
> #Position ICRS
> #Position FK4
> #Measure with Error 2D-Ellipse
> #Measure with Error 2D-Symmetric
> #Measure with Error 1D-Symmetric
> #Measure with Error 1D-ASymmetric
> #Time JD
> #Time MJD
> #Time Mission Ellapsed Time
> #Time DATE (datetime)
> 
> I'd like to bring these to the front, but don't like creating a bunch of
> 'alt' areas.

I think I like them much better than previous efforts, but of course
there are still quite a few things I'm not too fond of.  I'm now
serving time series with a draft annotation, too, inspired by your
examples, but different in many details and a few fundamental points.
For an example, see

http://dc.zah.uni-heidelberg.de/getproduct/k2c9vst/data/OGLE-2016-BLG-0064_VST_r_SDSS93.t

[Note that these are rough drafts that don't match any existing
VO-DML out there; this is mainly about the model outlines and
delineations; a perhaps more readable version of the actual
annotation in the DaCHS resource descriptor that generates this:
http://svn.ari.uni-heidelberg.de/svn/gavo/hdinputs/k2c9vst/q.rd, look
for <dm> elements].

I'd say the main things I'm currently doing differently include:

(1) I'd *much* prefer if value+error weren't part of STC and rather
could be pulled out of STC to have a DM of their own (in my example,
that's the fake ivoa:Measurement type).

(2) I never liked the separation of frames from the remaining
annotation in STC; I believe the original idea has been that you
could somehow re-use tuples of frames on the various axes, and I
doubt any savings (or functionalities?) possible with this are
proportional to the complication of having to go through references.
Hence, in my draft, the coordinates simply have a frame attribute,
done.  I'd even propose that just based on the type of the thing you
find in frame, clients should figure out the nature of the axis, and
you could get rid of verything in coordsys:domain except the frames
themselves.

(3) In ndcube:Cube, I'm using sequences of dependent and independent
rather than somehow packing them into Observable instances, and 
I'm directly annotating the columns rather than other DM annotations.

There are quite a few differences in the actual annotation, too (my
most ardent wish is to have dmrole just contain the role name to
preserve readability), but that's for mapping discussions.

Having said all this, I'm totally in favour of deciding on a "current
version" of STC and the ancillary DMs and putting them up...
somewhere :-)  Perhaps one could have a temporary section on the DM
wiki page with links to the current generated HTML docs for the bunch
of the DMs?


         -- Markus