gzipped images in SIAP 1.0

[Rob Seaman]

Roy Williams wrote:

> It seems to me that the problem is not with the MIME labeling, but  
> with the undocumented plasticity of FITS.
>
> You can use a FITS file for a radio data cube or for a table of the  
> Kings and Queens of England. I don't think we can expect the MIME  
> type to cover all that complexity.

Indeed - there is an impedance mismatch between the complexity of  
FITS and the simplicity of MIME.  There is no room in MIME for subtle  
distinctions to be drawn.

> When a machine client reads a FITS file, it needs is a way to scan  
> the FITS header and understand what it is and how to read it.

The strictly structural FITS metadata is well in hand.  I admire your  
hubris at wanting to build a registry of distinct dialects of FITS,  
but that is a question of science metadata, not simply whether a file  
represents an image or not.

> Suppose each FITS file has a special keyword IVORN, whose value is  
> a registry call number (ivo://...) that defines a "local FITS  
> type". When we dereference the IVORN, we get the metadata:
>
> -- Special keywords and their meaning (eg this comes from the Pink  
> Galaxy Survey pipeline version 1.2).

Works for me.

> -- Which interfaces are implemented (eg. this is a tile-compressed  
> image

Already expressed within FITS.

> + this has the WCS keywords,

Already expressed within FITS.

> this is a table of Monarchs).

...and where is the ontology for conveying to a machine what a  
"Monarch" is?  Having succeeded at this, one presumes conveying the  
semantics of a table of same is straightforward.

> -- What is the calibration model.

A load the FITS community should shoulder themselves.  Add value to  
the FITS, don't work around (and thus enable) prior limitations.

> -- Services that can take a Pink Galaxy Survey file and give you  
> the darks and flats and weather report and seeing etc etc

A classic VO use case.

Rob