[TRANSFORMS] - What is the scope of this work package?

[Doug Tody]

Hi David -

On Wed, 21 May 2003, David Berry wrote:
> 1) Transforming Quantities: given a Quantity, how do you transform it into
> some other system. This includes simple transformation between Units (e.g.
> Hz -> GHz), but also more complex transformations such as
> (frequency->wavelength), or even (topocentric frequency -> heliocentric
> radio velocity). How to structure these transformations depends very much
> on the eventual definition of a Quantity, so maybe we should defer
> discussion until the [QUANTITY] work package is developed further.

As we discussed in Cambridge (e.g. in the registry discussions), within the
VO framework per-se we probably want to fix the units to one or a very few
options, since the framework is not a user interface and we want to simplify
the programmatic interfaces between components.  Transforming quantities
is something that happens mainly at the boundaries of the system, e.g.,
in the data mediators, which map external data into a data model, or in an
application, applications framework, computational service, etc., where we
might need to transform the data model to some application-defined model,
or interact with the user.  These are the areas where a quantity transform
toolkit could be most useful.  The data models will need to define the
limited set of units permitted at the VO data model level, and might want
to comment on the issue of transforms to and from the data model.

It is not clear at this point to what extent we need transform components
at the level of the VO data models - except for the example of WCS.  A
good question is if we look at the data models if there are other examples
where it is useful to define such a transform independently of a data 
object.

 
> What is the place of WCS within the data model? A FITS file containing
> data will usually have a set of FITS-WCS headers. So do we need to
> consider WCS further? As I said in my Cambridge presentation, my opinion
> is that a toolkit approach to WCS would be much more scalable and easy to
> extend than the prescriptive approach embodied within the (excellent and
> extremely carefully though-out) recipes of the FITS-WCS papers. But the
> reality is that FITS-WCS is the currently accepted system for storing WCS
> by the majority (not all) of the astronomical community - so should the
> IVOA just adopt FITS-WCS for use through-out its data model?
> 
> Of course, it would be possible to convert a FITS-WCS representation into
> some form of a toolkit representation (the AST library does just that),
> but there would seem to be little point in doing this unless you then take
> advantage of the extra flexibility offered by the toolkit. But it would
> then be very easy to end up in a situation in which the resulting WCS
> uses features which are not representable within the recipes prescribed
> by FITS-WCS, making it hard, if not impossible, to go back to a FITS file.

We can't rely upon having WCS information only in external datasets such
as a FITS file.  We need to extract the metadata from external datasets and
represent it in a standard way within the VO, e.g., so that we can describe
candidate datasets in a VOtable without actually having to download the
associated data (as in SIA for example).  There will also be cases where
we pass actual datasets entirely in some XML-based representation of a
VO data model, e.g., for 1D spectra.

We need to leverage FITS WCS within the VO since so much work has gone into
it and it is so heavily used in actual data and data analysis software.
I think we should define an XML-based representation of the FITS WCS
data models, adopting the FITS WCS standards papers as the foundation
for the VO data model for WCS.  FITS WCS is probably the best example we
currently have of an abstract data model - it shouldn't matter whether
an actual WCS is represented in FITS keywords or in XML (except that it
will be easier in XML).

In defining the new FITS WCS standards we argued that the WCS object
should stand on its own independent of the association of a WCS with
any particular data object.  This concept should be preserved in the VO
representation.  We should be able to define a WCS as a self-contained
numerical transformation independent of any actual dataset, and then
associate it with zero, one, or more actual datasets to represent the
WCS part of a complex dataset.

WCS support should probably include support for spectral WCS - this exists
now in draft form.  We should consider using a VO version of this to
describe the WCS of 1D spectra for spectral data access.

To map FITS WCS into a VO data model we need a way to formally define 
data models in the VO (as Jonathan and the DM WG have been working on).
We need UCDs of some sort for the WCS elements or quantities.  We will
need a way to map a WCS data model into XML, e.g., into an associated
set of columns in a VOtable, or into a self-contained WCS resource stored
in a VOtable and associated with some other data elements in the same
VOtable.  

	- Doug