[QUANTITY] Plea for pragmatism

[amicol at eso.org]

Quoting Doug Tody <dtody at nrao.edu>:


> Here is a first cut at the component data models needed for data
> characterization.  This is based on further development of our Cambridge
> etc. discussions.
> 
> Coverage / Characterization Component Data Models
> 
>     sky coverage
>         coverage on the sky, if applicable
>         e.g., a circular or rectangular region or aperture on the sky
> 	Can be used to estimate the WCS but the full WCS should be
> 	defined elsewhere.
> 
>     time coverage / bandpass
>         time of observation
>         refValue, hiValue, loValue, fillFactor
>         refValue is the mean time of observation, e.g., mid-point
> 
>     spectral bandpass
>         range of spectral frequencies in data
>         id, refValue, hiValue, loValue, units, fillFactor
>         id is user-defined bandpass name, e.g., "V", "SDSS_U", "K-Band",
> etc.
>         refValue is the characteristic frequency of the bandpass
> 
>     spatial bandpass
>         range of spatial frequencies in data
>         hiValue, loValue, units, fillFactor (no refValue)
>         loValue is also known as the spatial resolution
> 
>     flux bandpass
>         range of flux values in data
>         hiValue, loValue, units, fillFactor (no refValue)
>         loValue is also known as the limiting flux or magnitude
>         hiValue is saturation limit or maximum flux
> 
> ...

My way of looking at the coverage problem is to 
consider it as a description of how a given data product
samples the 5-D volume that you described above.

That is, coverage is to do not only with field of view but also with
resolution, and this true on all the 5 axes.

> Did I leave anything out?  Polarization perhaps, but that might be better
> dealt with elsewhere.

To answer you question I think that the missing info has
to do with the Errors associated on all those quantities, 
oops sorry, let me call them parameters not to confuse things here;
mainly I refer to the astro-spectro-photo-metric accuracy.
An image might be of interest to me because satisfies some coverage
criterion, but I might want to discard it because the astrometric
precision is not the one required for my study.

Hence: Coverage(how the 5D volume is sampled)+Errors.

What else ? The seeing. 
How the 5D volume is sampled is not enough ...
Resolution is intrinsic to the instrument/camera,
while the seeing has to do with the overall atmosphere+dome+optical design.
I don't like this since it's breaking the simmetry.

Hence: 5D volume + errors + seeing ?

Unless we replace "Resolution" with the covolution of Resolution and seeing.


The refValue/hiValue/loValue are a very good starting point,
the zero order approximation, we can certainly go further
and defines things like exposure maps etc, to describe more precisely
the coverage, but that can come later. The zero order approximation,
or "summary data model" as you call it,
will always be valid, as you were saying.

> The refValue/hiValue/loValue concept comes from the spectral bandpass
> model introduced in SIA.  From conversations with CVO I think they have
> a similar approach which adds fillFactor.  The refValue if any is the
> characteristic value.  The filling factor says something about how much
> of the hi/lo range specified is actually "covered".  For example, if an
> image does not contain valid data for the full region the fillFactor is
> less than 1.0.  If we combine a number of exposures the time coverage
> fill factor will be less than one.
> 
> The idea above is that concepts such as spatial resolution and limiting
> flux or magnitude might be better represented as hi/lo values in a more
> uniform bandpass model.
> 
> Other fundamental metadata required to describe a dataset includes the
> dataset identification (title, creator, creator dataset ID, publisher,
> publisher dataset ID, and so forth), and provenance information (where
> the data came from, e.g., virtual data description).
> 
> The priority order is roughly as presented above, although I would put
> dataset identification at the highest priority.
> 
> I don't think the actual "summary data models" required need to be much
> more complicated, in terms of numbers of attributes per model, than what
> I sketch out above.  If we add more detail later, e.g., a transfer curve
> for a spectral bandpass, or other more fine-grained modeling information,
> this can be done in such a way that the summary data model is still
> retained and still valid.
> 
> 	- Doug
> 

I think it should not be difficult to come up quickly with 
a simple data model to describe the coverage; and it will greatly
help the development in other WG, like DAL, VOQL and UCD.


Alberto