Some documentation for a metadata-tree

[Anita Richards]

Apologies for these belated comments on the meta-data tree and the IDHA
model:

Question - in StorageMapping, that is 'mapping' in the semantic sense,
e.g. mapping metadata to content, not in the imaging sense?

I also feel it would be useful to generalise the model slightly.
This is in the context of just serving images at the present, but it
should cover all types of image?  For the future, it would be nice to have
to make minimal changes for extension to spectra and non-image data, too.

1)

Currently, the 'top right corner' of the IDHA data model explicitly
contains
'Telescope'
'Insrument' is equipped with 'Filter',
and 'Camera', 'Digitising_Machine', 'Detector'.

'Telescope' - Bob/notBob's document uses 'Facility' which allows for more
generality, although in practice are most people comforatble with using
telescope to mean an array, neutrino detector etc?

Filter:
Could you include 'bandpass_restriction' or something without restricting
it to act at that stage, as the bandpass is set in different domains at
different stages and not necessarily by a filter - although perhaps
'filter' can be used to cover frequency restriction/bandpass calibration
at any stage e.g. in the correlator or in the final image production. So I
think the point here is that it should reference the bandpass, either via
a pointer to a standard filter label (Cousins etc?) or to an algorithm, or
just to a numerical or label definition of a frequency/wavelength/energy
interval. And it should be able to be associated with any
post-telescope stage (within this corner!)

Camera etc.:
There are many other routes from telescope to the output image, if that
is what this bit means (sorry if I ahve misunderstood).  In fact in some
cases a pre-image data product is stored (see 2).  I think that it is
impossible to break the process down into a *large* number of comparable
stages for all domains, even just for the commonest data in our Science
Cases.  In fact I think that we need just two stages:
Instrument (which would cover things like the configuration of the VLA or
the mode of Chandra)
Data_capture (which covers cameras, correlators etc. etc.)
and then the necessary engineering details can be linked as appropriate.

It might be useful to describe the nature and format of the data products
here (see next point) - although this overlaps with 'Coding'.

2)
Some facilities store e.g. event lists (Chandra) or calibrated visibility
data (MERLIN) as the primary product.  These (may) make some images
available, but in order to access the whole archive, further processing is
needed.  This might be done at the VO's request by the archive or by an
intermediate data warehouse etc. but the VO model will need to be able to
allow for this step, and it would be helpful if it at least recognised
storage formats (event lists, visibilities etc.) even if the archive etc.
was responsible for translating the requested image specifications into
the necessary maniuplation of visibility data or whatever.

This suggests that:

Lower right:
There should be an intermediate stage before stored image, such as
'ImageAccess' to allow for the above to be described - at the very least,
if in fact only ready-made images are used, the user might still like to
know what the image could be broken down into, e.g. separate time-frames
for coadded optical images; visibility curves/radio light curves etc. etc.
Thus at the least this should allow for a description of the native data
type and the neams of conversion to images.

Maybe this is covered by 'LinktoPixels' but in that case it should be
'LinktoData' for data where the pixelisation is an afterthought.

Lower left:
'ImageList' may not be a list of images as such, but of regions which
could be imaged.  Would 'ImageRegion' be better (and this also allows for
completeness of coverage etc.. to be in the description)


(Sorry, I am not sure if 'ImagesTimeSeries' means images taken separealy
at differnet times (e.g. multi-epoch monitoring) or to images constructed
from time-series data (e.g. Chandra))

3)
AstrometricReduction and PhotometricReduction should cover the accuracy of
the data? but there also need to be Resolution; this is not the same as
the pixel size for non-CCD data.  This is partly a proprty of the
instrument and partly a porperty of the data processing.

Thanks

Anita


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).