STC2 Design

[Arnold Rots]

Dear DMers,

I have been working with Mark Cresitello-Dittmar, Omar Laurino, and
Gerard Lemson on the STC2 design. It has converged to a reasonable
degree and may be found at:

https://code.google.com/p/volute/source/browse/#svn%2Ftrunk%2Fprojects%2Fdm%2Fvo-dml%2Fmodels%2FSTC2%2F2015-05-04

The .ump file is not terribly useful, unless you have Altova UModel, but the
Doc and Diagrams directories will be more helpful.
Regarding Doc:
The documentation of the various elements is far from complete, but at least
there is a start.

The large diagram STC2 shows the elements that are of interest to the user,
displaying the packages they belong to, and the dependencies between the
packages. The other diagrams present the individual packages, some basic
VO-DML packages, and stcTypes - a package of types defined for STC (this
still
needs cleaning up - extending enumerations, removing old units).

Color coding
------------------
Packages: pale yellow
Classes: orange
DataTypes: yellow
Enumerations: pink
Tags (subsetting): gray
Generalizations: red
Compositions: blue
Associations: green
Package dependencies: magenta
Note that classes or datatypes copied from their own package into a package
that needs them are colored by the relation that pulls them in (red or
green).

The two basic packages are coordSystem and coords.
The latter clearly has a dependency on the former, but there is also a minor
dependency in the other direction since we have to allow a non-standard
reference position in the definition of the coordinate frames. Note that
this
does not constitute a circular dependency.

Coordinate Systems contain references to one or more Coordinate Frames.
Coordinates contain one or more typed coordinates.
However, neither the Coordinate System, not the container Coordinate are
required,
since typed coordinates directly reference corresponding coordinate frames.

A CoordSys consists of 0..* generic coordinate frames and an AstroCoordSys
is derived from it, optionally containing any of the five astronomical
coordinate
frames.
Temporal, spatial, spectral, redshift coordinate frames need a reference
position,
polarization does not.
Four polarization types are allowed: Stokes, circular, linear, and vector.

A coordinate is still a composite of a value, error (uncertainty), and
resolution.
Most of these components are typed as Quantities, meaning they include a
unit.
Since there is no mechanism to restrict units (to make sure they are
appropriate
for the coordinate value they are attached to), STC2 introduces the SKOS
concept
coordinateDomain which narrows the allowable scope as one travels down the
coordinate tree. The intent is to provide a context-independent mechanism
that
controls the scope of the units, rather than having to code those
restrictions
separately in each place they are used.
Spatial coordinates (position and space velocity) are not derived into
separate
1-D, 2-D, and 3-D varieties anymore; instead, the dimensioning is done
through
the datatypes used for their components. I realize that this presents a
risk for
incompatibilities, but it simplifies the model and an explicit dimension
attribute has
been added that is to be used to control this.
Generic coordinates are provided to allow inclusion of anything other than
the
five astronomical coordinate types, such as temparature, pressure, flux
density, etc.

No package depends on frameTransforms and it depends only on coordSystem.
It comes in two varieties: as part of a pixel frame (pixel frames have to
have a
mapping onto the real world) and as a class that operates between two real
world
coordinate frames. Note that in either case the transform is defined as a
mapping
between coordinate frames. That means that the frame needs to have all
information
needed to define that mapping.
There are two high-level design options for the transform.
The one presented in this design closely mirrors FITS WCS: a single set of
metadata
parameters specifies the full transformation/mapping/projection from one
coordinate
frame to another. Translating between it and FITS WCS header keywords is
straightforward.
An alternative design is presented by Mark in the image data model: the
frame
transformations are atomic (scale, translate, rotate, project) and one has
to string
those elements together to effect the full transformation. The FITS WCS
papers
explain how their compound transformations are constructed.
The choice between these two approaches is a bit of a toss-up (although
undoubtedly
there will be people on either side who will argue forcefully that one is
clearly superior
to the other). This, I think, is a matter for discussion.
Note that enumerated coordinate values are supported. Polarization is an
example
of an enumerated coordinate axis.

coordArea has a dependency on coordSystem and coords.
region has a dependency on coordArea and coord, for obvious reasons.

Enjoy!

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20150505/d2fb94e7/attachment.html>