Subject: FITS-Tables-for-spectra

From: [email-masked] (Don Wells)
Date: Sun, 1 Apr 90 13:59:37 EDT

Dear Frank,

In your message to me [Date: Mon, 26 Mar 90 11:26:14 EST, From: (
FRANK GHIGO ) [email-masked], To:
[email-masked]] you ask

"...the question is, aside from the column(s) that contains a matrix,
can one put groups of numbers into other columns?  This would be
convenient in several cases, for example, the "descriptive origin"
could be in a single column with a format of 3E, the LO synthsizer
settings would be 6E.  But is this sort of thing allowed by the single
dish agreement?  (If it is required that all table rows can be
unpacked to classical FITS form, then a table column (except for the
matrix) becomes the value of a keyword, which can, at most, be a
complex item.)"

I am CC-ing my reply to DISHFITS because I believe that this is a
question of general interest.

The basic question raised here has a long history in the FITS
community, and opinions have always differed on it. At the time of the
Basic FITS Agreement (March 1979) Eric and I agreed to allow for the
multi-valued possibility by defining value fields to be in FTN-77
list-directed format, which defines a free-field syntax for lists of
elements. The design reviewers (April-May 1979) criticized this as
dangerously complicated and so the 1981 paper recommends a more rigid
style in practice, with semi-fixed columns and only one value per
header card, but it still permits the more powerful syntax in case we
ever need it.  My own perception is that nobody has made a compelling
case for multi-valued fields during the past eleven years, and I won't
recommend such usage myself until I hear such the case made
convincingly.

The question arose again during the 1-Nov-90 Green Bank meeting and
was repeatedly addressed in various ways. My suggestion that *sets* of
Basic-FITS files be encoded as 3-D-tables carried the implicit
implication that the keyword fields will be single-valued. So, the
literal answer to your question is that multiple LOs should be
multiple keywords, or else that they should be encoded in a character
string value for a proprietary keyword.

But that cannot be the ultimate answer, because people keep raising
the question year after year. It seems to me that there is not yet a
consensus on the general design question you are raising, a question
independent of the answer that applies to FITS as it now is.  Some
people, me included, believe that multi-valued keywords in this
context would violate normalization rules for design of relational
databases. I don't consider this claim, which I regard as still
unproven even though I myself believe it, as binding on us as
designers; rather I regard it as a cause for caution. I suggest that
it will be best for us to try very hard to cast all problems as
single-valued keywords, and add the additional layer of complexity
only when we are forced into it.

Regards,
Don 

Donald C. Wells, Associate Scientist | NSFnet: [email-masked] [192.33.115.2]
National Radio Astronomy Observatory | SPAN:   NRAO::DWELLS    [6654::]
Edgemont Road                        | BITnet: DWELLS@NRAO
Charlottesville, VA 22903-2475 USA   | UUCP:   ...!uunet!nrao.edu!dwells
Lat: 38:02.2N  Long: 78:31.1W        | Tel:+1-804-296-0277 Fax:+1-804-296-0278