[fitsmime] FITS Mime-Types for Mosaics

[Steve Allen]

On Fri 2002-12-06T15:09:59 -0500, Don Wells hath writ:
> I proposed the latter three categories with the idea that they would
> have the following meanings:

> * "application/fits-table" -- the primary content of the file is a
>                             *set* of tables (TABLEs and/or BINTABLEs).
>
> * "application/fits-image" -- the primary content of the file is a
>                             *set* of IMAGE extensions, but there may
>                             also be table extensions in the file.

I am not convinced of the utility of fits-table and fits-image
vs. simply fits.  If I encounter a fits-table file I do not
know whether to expect it to be an X-ray event list (which is
really an image) or a dump of somebody's database.  The former
is suitable for a pretty picture on the screen, and the latter
is not.  Without resorting to heuristics there is no way to know.

> More generally, I wonder whether fine-grain classification of our
> files might not be better achieved with a reserved keyword in the
> primary header.  The keyword would have value strings coded according
> to some convention.  Such a string could specify that an
> 'application/fits-image' file is an NOAO mosaic, or a DEIMOS mosaic,
> or some other scheme for using a set of IMAGE extensions (plus table
> extensions) to convey some sort of image data.  The same keyword, or
> maybe an analogous keyword, would be used in 'application/fits-table'
> files to say whether the content is a set of tables conveying an event
> list from a high energy experiment, with the schema conforming to some
> convention, or instead the content is a set of tables conveying radio
> aperture synthesis fringe visibilities in conformance with the
> FITS-IDI (Interferometer Data Interchange) convention.

I wholeheartedly endorse such a thing, but I see it as being outside
the scope of the MIME RFC because of the somewhat urgent needs of the
VO community to have some registered MIME types soon.  I would rather
not see the scope of the MIME RFC effort expand to require creation of
new FITS conventions first.

> Usually the client-side implementation of MIME codes is that one
> application code is associated with each code.  It seems to me that it
> should be possible to code a simple program which could decide the
> provenance and probable detailed type of a FITS file by examining the
> headers, even in the absence of a keyword such as the one discussed in
> the previous paragraph, and which could then decide which of a set of
> application programs will be used to process each individual file.
> The classification program would then invoke the proper application.

In the absence of a classification keyword with registered meaning
this is a nasty exercise in heuristics.  It can probably be done
pretty well, but one could equally well say that the "charset"
parameter for MIME types could be guessed by comparing the content of
the file with a sufficiently large database of sample text in various
languages.  I would rather not endorse such a scheme.

In short, I do not see that the fits-image and fits-table subtypes
provide anything useful beyond what is communicated by
application/fits.  The extra bit of classification does not remove the
need to apply a bunch of heuristics in order to figure out what to do
with the file.  It also requires webmasters to engage in a very tricky
classification scheme which is not well supported in the absence of
different file extensions for different MIME types.  I would prefer to
register application/fits and then start exerting effort within the
FITS community to develop some sort of internal keyword/value
registry.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93