gzipped images in SIAP 1.0 (fwd)

[Doug Tody]

On Thu, 31 May 2007, Anita M. S. Richards wrote:

> There is a 4th case which I had assumed was essentially non-VO-accessible, and
> that is where the archive contains images (and possibly all sorts of other
> things) in an archive file, e.g. some Spitzer data are gzipped tar archives.
> Guy's suggestion makes me wonder if VOSpace could possibly cope with that
> although thre would be two other requisits:
> 
> a) In order to find the data in the first place, the metadata would have to be
> stored in a database or some other accessible form (I am not sure if a
> fine-grained registry would do).  This buzzes one of the bees in my bonnet,
> that directly interrogating FITS headers is sooo C20; SIAP has to grow up and
> be able to provide a SIAP-like response but based on metadata and possibly
> more complicated processes (at the data provider end).

This issue of returning an image with other associated non-image
information came up in the SIA V2 session in Beijing.  The idea
floated at the time was for the queryData to return two records per
image in such a case, one for only the image (any client can deal with
this), and the other for the "full" set of data, e.g., a tar or zip
containing the image plus some unspecified provider-specific auxiliary
information.  An alternative might be to return a FITS MEF containing
this information if we want something a bit more fully defined.
We could certainly do this, but depending upon how it is done, it is
not clear how a client application would deal with what comes back.

Regarding directly interrogating FITS headers - I am not sure what
you mean by that Anita.  Surely a good SIAP implementation, even for
SIAP V1.0, extracts the header metadata into a DBMS and uses this to
process queries?  Most SIAP implementations that I have seen already
do this.  With SIAP V2, we will have much richer metadata, similar
to what is available now for SSAP (Char etc.), and this approach will
become even more essential.

	- Doug