STC2 Model and VO-DML Issues

[Markus Demleitner]

Dear DMers,

On Sat, Oct 31, 2015 at 10:28:54PM -0400, Arnold Rots wrote:
> We have recently had some discussions on VO-DML in the context
> the the STC2 model, that Mark suggested should be summarized to
> the DM list to entice larger participation.
> 
> The current version of the STC2 model is now posted on:
> https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/STC2/2015-10-30/

Just as an aside from the current volute operator, and publicly
because Arnold is just following a practice I've seen in multiple
ongoing DM efforts: Since this is a version-controlled repository,
you're doing everyone a favour if you avoid dated subdirectories (or
files with names having dates) and just overwrite existing data.
What's text becomes easily diffable, and even for binary stuff it's
easier to follow the provenance without explicit "release"
subdirectories.  If you actually want those, please use tags.

> As reported yesterday, the following action items have been resolved:
> - Transformations are done in atomic fashion, following the AST style
> - Gerard has a scrippt that will process the XMI file
> The following actions are in progress:
> - Complete the enumerations of standard frames and standard positions
>    This is trivial and quick
> - Complete the in-model documentation
>    Most description boxes in the documentation are still empty
> - Investigate (and experiment with) defining specialized coordinates
>    through subsetting. A first attempt is contained in the Specialized
>    package; but it is not clear this is worthwhile.

I'm still dreaming we might fast-track what's probably relatively
straightforward and what is, at the same time, most urgent in terms
of properly annotating coordinate sets in VOTables, by splitting
out transformations, exotic coordinate systems, and the like to
different models.  With VO-DML, composition of these shouldn't
be much of a problem.

I distinctly remember that at one point we had collected STC use
cases on the wiki, which I believe could be a guideline as to where
to split -- unfortunately, I can't seem to find it any more.  If
anyone comes across it, I think it should be linked from
http://wiki.ivoa.net/twiki/bin/view/IVOA/STC.  

Since I can't find it now, here's a brief version of what we clearly
should have had ready and in use by the time of VOTable 1.2 (2010,
depreciation of COOSYS) and thus is over-over-overdue now: Basic
metadata for spherical coordindate systems.  As a baseline of what
should be expressable I offer:

  lat/lon (and errors) or Point (combined lat/lon), parallax or distance
  proper motion RA/dec (and errors), radial velocity
  epoch, frame (with equinox as required), refpoint of lat/lon
  mean epoch of RA/dec in the case of reduced positions (though that
  could arguably be in provenance's domain)

where a single table can have multiple such structures (e.g., ICRS
and galactic coordinates).  That would fix VOTable, if we keep at it,
perhaps six years after we broke it, and having worked out the
details of the annotations in this manageable case would help a lot
speeding up the process for more complicated cases (non-spherical
coordindates, spectral and redshift, transformations, etc).

A division of concerns as proposed here has been rather successful in
cases (think TAP, ADQL, VOSI, UWS) before, and I'd much rather work
on such a manageable model than at the behemoth that the
current monolithic model is.

There's nothing wrong with keeping activity on transformations, pixel
coordinates, and all kinds of other frills if we really must have
them for the Image DM, but the sheer size of the WCS papers makes me
deeply worried that trying to plough through that entire domain will
further delay the basic, STC-in-VOTable-style annotations, perhaps in
the end to irrelevance as people give up and just make do with COOSYS
again.

And one more question on a single issue:

> - Collaborating with whoever (if anyone) is working on the Units model
>    The issue is the mechanism to restrict units according to context;
>    STC2 includes such a mechanism, but this needs to be done in
>    consultation

What's the rationale behind that?  Wouldn't physics determine that?
Or is the intention to specify something like "proper motions are
always in rad/s"?

Cheers,

        Markus