VOTable issues for possible discussion at the Inter-operability meeting.

[Anita Richards]

>    <BINARY> tags, are something of a compromise and not really in the
>    spirit of XML.  Also, if the table is stored as a separate file in FITS
>    or binary format then there is always the possibility that the files
>    will become separated and one or the other will be lost.  In the future

????

I think that keeping the components of datasets together is a problem we
*have* to solve - any data set is only as good as its metadata as far as
the VO is concerned.  As many people have argued, we should use VOTable
and XML for what they do best, and that may in some cases be providing
wrappers to binary (FITS or other) data.

The VO cannot and should not hope to write software to handle every common
astronomical process, let alone rare ones.  So we will have to interface
to packages which in many cases want FITS - and the users will in many
cases want data which they can feed into their own packages which want
FITS.

These may seem to be contradictory statements, as some packages seem to
mangle or lose FITS headers and extension tables.  This can be because the
headers/extensions are sloppy, or because the package is sloppy.  The
solution to the former is to store the header etc. information as xml
(which means we will need access to a variety of FITS readers? Or can
Treeview or the relevant bits of it handle all the flavours we are likely
to need and output them as xml?)  The solution to the latter is to
deprecate the use of such packages in data processing centres which the VO
relies on - in my limited experience of STCSI, CHANDRA, radio data
processing using AIPS, nowadays readable FITS headers are passed intact or
added to as required (they may not have the information you want, but that
is a separate problem, the point here is that nothing should be lost).

Whatever, the VO should not lose bits of datasets in its custody!

> An additional issue, which I didn't mention in the paper, is how WCS
> information is to be represented in VOTables (though I suppose that this
> is a special case of defining semantic standards).  I think that there
> are two possible approaches:

...........
>
>   By comparison, the system for managing WCS information described in the
>   recently published FITS-WCS papers is a prescriptive system which
>   specifies precisely the steps which must be taken in transforming from
>   pixel coordinates to world coordinates. Very little freedom is allowed in
>   the overall form of the transformation. This approach developed as a
>   natural extension to the older "AIPS conventions" for storing WCS within
>   FITS headers. Indeed, consistency with the older conventions was one of
>   the stated goals for the new system.
......

Any 'standards' can never be frozen for all time.  But it will take
demonstrations on real data at the highest level of accuracy to convince
me that anything else works as well as the methods prescribed by Greisen
et al.
http://www.aoc.nrao.edu/~egreisen/index.html

   1.Representations of world coordinates in FITS by Greisen and
Calabretta (gzipped 92960
      bytes), or unzipped (244526 bytes) as Accepted: Volume 395, pages
1061-1075
   2.Representations of celestial coordinates in FITS by Calabretta and
Greisen (gzipped 238808
      bytes), or unzipped (761143 bytes) as Accepted: Volume 395, pages
1077-1122
   3.Representations of spectral coordinates in FITS by Greisen, Valdes,
Calabretta, and Allen
      (gzipped 180536 bytes), or unzipped (486217 bytes) 06-December-2002.

This may be another manifestation of the aips++ syndrome rearing its ugly
head - do we give astronomers what they want, or what programmers find
most convenient/elegant/interesting? But I will read the AST papers with
great interest.  (I am *not* saying that they aren't at the cutting edge
of accuracy, only that I don't know).


In any case we need to distinguish between what is needed for data
processing - which may be nasty clumsy operations but using software
someone else has already provided - and what is needed for metadata in the
Registry - which only has to be at a specified level of accuracy, and to
know what that level is - in which case if the Starlink packages or stuff
based on them work most efficiently, they should be used at that level.

Best wishes

Anita